웹서버의 통신 방식
HTTP 엔 여러 특징이 있는데 그 중 중요한 특징으로 무상태(Stateless)와 상태유지(Stateful)이 있다.
무상태(Stateless)
무상태(Stateless) - 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미한다.
- 장점 : 서버의 확장성이 높기 때문에 대량의 트래픽 발생 시에도 대처를 수월하게 할 수 있다.
- 단점 : 클라이언트의 요청에 상대적으로 Stateful 보다 더 많은 데이터가 소모된다.
상태유지(Stateful)
상태유지(Stateful) - 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미한다. 단순히 말하면 클라이언트의 이전 요청이 서버에 전달 되었을 때, 클라이언트의 다음 요청이 이전 요청과 관계가 이어지는 것을 의미한다.
- 장점 : 기능상 Stateful방식이 강력하고 편리하다
- 단점 : 매 요청시 마다 상태 정보를 전달해야 하기 때문에 그만큼 네트워크 리소스를 소비해야 하고, 서버에 무리, 서버의 확장성, 보안등 여러 문제점이 있다
예시
★ Stateful 통신
- 신발 판매를 하는 서버 X
- 신발을 사려는 클라이언트 A
A : 자전거 사려합니다
X : 자전거 커스텀 재료를 골라주세요 (자전거를 사려한다는 것을 기억한다)A : 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요
X : 배송은 어디로 해드릴까요? (자전거를 사려했다는 것을 기억하고 있다)A : 집으로 보내주세요
X : 결제는 무엇으로 해드릴까요? (자전거를 사려했다는 것, 커스텀을 어떻게 했는지 알고 있다)A : 카드로 결제할게요
X : 결제 완료 되었습니다. (위의 모든 사용자가 요구했던 사항을 기억하고 있다)대화를 보면 판매하는 X서버는 사용자의 이전 요청을 모두 기억하며 진행한다는 것을 알 수 있습니다.
이것이 상태 유지이며 지극히 정상적인 대화 처럼 보입니다.
하지만 여기엔 함정이 있습니다.
바로 판매하는 서버 X가 바뀔 경우입니다.
만약 대량의 트래픽이 몰려들어서 서버를 긴급하게 늘렸다고 생각해보면, 판매자 서버 X가 아닌 증가된 어떤 서버 Y가 될 수도 있습니다. 현실에서도 마트에서 너무 바쁘면 담당자가 바뀌기도 하죠? 같은 의미로 생각할 수 있습니다.다음은 X가 바뀌었을 경우의 상황입니다.
서로간의 대화는 다음과 같이 진행됩니다.A : 자전거 사려합니다
X : 자전거 커스텀 재료를 골라주세요A : 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요
Y : 네? 어떤걸 말씀하시는거죠?A : 집으로 보내주세요
Z : ?A : 카드로 결제할게요
X : 네?말이 안통합니다.
이게 바로 상태 유지의 문제입니다. 이러한 문제를 해결하기 위해 무상태가 등장하죠.★ Stateless 통신
상태 유지를 이해했다면 무상태는 생각보다 쉽게 이해할 수 있습니다.
- 자전거 판매를 하는 서버 X,
- 대체 가능한 서버 Y, Z
- 자전거 사려는 클라이언트 A
A : 자전거 사려합니다.
X : 자전거 커스텀 재료를 골라주세요. (서버는 아무것도 기억하지 않는다)A : 자전거를 사려합니다. 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요.
Y : 배송은 어디로 해드릴까요? (서버는 아무것도 기억하지 않는다)A : 자전거를 사려합니다. 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요. 배송은 집으로 보내주세요.
Z : 결제는 무엇으로 해드릴까요? (서버는 아무것도 기억하지 않는다)A : 자전거를 사려합니다. 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요. 배송은 집으로 보내주세요. 결제는 카드로 할게요.
Y : 결제 완료 되었습니다. (서버는 들어온 요청을 처리한다)이전의 클라이언트의 요청(상태)을 유지하지 않는 서버. 그것이 핵심입니다.
무상태는 기존의 서버가 혼잡해져서 새로운 서버를 가져다 놓아도 기존의 비즈니스 로직을 그대로 구현하고 있다면 이전의 사용자 요청이 어떤지에 관계없이 계속 일을 처리할 수 있습니다.
단점은 클라이언트가 하고자하는 최종 목적을 위해 지나는 과정마다 점점 전달해야하는 내용이 많아진다는 것입니다.
HTTP는 이 무상태를 특징으로 기본적으로 가지고 있습니다.
특별한 일이 없다면 무상태를 지향해야하며 정말 필요한 경우에만 상태 유지를 해야합니다.
결론
stateful 방식은 기능 구현상 편하지만 상태를 계속해서 가지고 있기 때문에 캐시의 활용도가 떨어지고매 요청마다 같은 데이터를 데이터베이스에 전송하는 것처럼 서버에 부담을 줄 수 있습니다.
stateless 방식은 매 요청 시마다 상태 정보를 저장해야 하기 때문에 네트워크 리소스를 서버 쪽에서 소모해야 하고 상태 값 저장 기능을 위한 사전 작업이 필요하지만 caching, load balancing, scale-out에 용이합니다.
MMOPRG와 같이 대규모 사용자가 실시간으로 전투할 때 고성능의 처리능력과 안정성이 보장되어야 하므로
Stateful Server가 적합합니다.실시간 연동이 상대적으로 덜 필요한 웹 서버는 네트워크 비용을 줄이기 위한 Stateless Server가 적합합니다.
서비스하는 형태의 특성을 고려하여 stateful or stateless 방식을 채택해야 합니다.HTTP는 Statelss한 성격을 가진 '프로토콜'
REST는 Stateless한 성격을 가진 '설계 구조'
이다.
참고 자료
