[Web] Stateful vs. Stateless 서비스

 

1. Stateful Service

Stateful '구조'는 Server와 Client간 세션의 'State(상태)'에 기반하여 Client에 response를 보냅니다.

이를 위해 서버 사이드에 '클라이언트와 서버의 동작, 세션 상태 정보'를 저장한다.

TCP

대표적인 Stateful 구조를 따르는 프로토콜로 TCP가 있다. 

TCP의 3-way handshaking 과정을 생각해보면, Server와 Client는 3-way handshaking 과정에서 SYN과 SYNACK을 주고 받으며, 양단간 세션 '상태'를 established한 '상태'로 만든다.

세션 '상태'가  established가 되면 client와 server는 데이터를 주고 받을 수 있다. 이렇게 TCP는 세션 '상태'에 따라 Server의 응답이 달라지는 Stateful 프로토콜이다.

TCP의 데이터 전송과정도 확인해 보자.

server는 client로부터 송신된 패킷헤더를 파싱하여 앞으로 수신해야할 데이터의 크기(window), sequence 번호 등을 저장한다. 그리고 해당 크기의 데이터가 모두 수신 될 때까지 client와의 세션을 유지한다. 이 과정에서 server는 앞으로 수신할 데이터의 크기, sequence 번호 등과 같이 client와의 세션 정보를 저장하게 됩니다. 

 

TCP (출처 : https://brunch.co.kr/@lars/1)

따라서 TCP는

1. 연결 확정
2. 데이터 전송
3. 연결 종결

이라는 TCP handshaking 과정을 통해 연결되며, 데이터를 전송해 Client와의 세션 정보를 server에 저장하고, 세션 상태에 기반한 server의 응답이 달라진다는 점에서 Stateful 하다고 말할 수 있다.

Stateful Service

Stateful Service는 이러한 Stateful한 특성, 1. 세션 정보를 server에 저장, 2. 세션 'State(상태)'에 따른 응답 을 만족하도록 설계된 서비스 구조 이다.

Stateful Service Architecture

 

위와 같은 Stateful Service 구조를 생각해 보자. ClientA 의 요청이 로드밸런서를 통해 임의의 서버(Server #1)에 전달되면 Server#1 에는 ClientA 의 세션 정보가 저장된다. 

그러나 로드밸런서에 연결된 다른 server, 그림의 경우 Server#2, 에는 해당 ClientA에 대한 정보가 없으므로 Server#2는 Client A와의 세션 인증을 처음부터 다시 해야할 필요가 있다. 이러한 redundant한 작업을 없애기 위해 ClientA의 요청은 Server#1을 향해 유지되도록 관리가 필요하다. → Sticky Session

서버 2개 이상 세션 불일치 해결하기

 

2. Stateless Service

Stateless '구조'는 server의 응답이 client와의 세션 '상태'와 독립적이다.

Stateless 구조에서 server는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 세션 관리는 client에게 책임이 있다. 따라서 이러한 Stateless 구조는 client와의 세션 정보를 기억할 필요가 없으므로, 이러한 정보를 서버에 저장하지 않는다.

세션(상태)와 무관한 응답을 하게 설계된 서비스 구조.
대신 필요에 따라 외부 DB에 저장하여 관리 할 수 있다. → Session Server

 

UDP

  TCP vs. UDP (출처 : https://www.muvi.com/wiki/udpuser-datagram-protocol.html)

대표적인 Stateless 프로토콜로는 UDP와 HTTP 등이 있다. 

UDP를 중점적으로 살펴보자. UDP는 TCP와 달리 handshaking 과정을 통해 연결 세션을 인증하는 절차를 수행하지 않는다. 세션 상태에 관계 없이 단순히 데이터그램을 source에서 destination 쪽으로 전송하며, client가 송신하려 했던 모든 데이터가 server쪽에 수신 되었는지 확인하지 않는다. 따라서 server쪽은 client와의 세션 정보를 전혀 저장하지 않는다.

따라서 UDP는 Client와의 세션 상태에 관계없이 요청에 대한 응답만을 수행한다. 또한 Client와의 세션 정보를 server가 저장하지 않는다는 점에서 Stateless 하다고 말할 수 있다.

Stateless Service

Stateless Service는 이러한 Stateless한 특성, 1. 세션 정보를 server에 저장하지 않음, 2. 세션 'State(상태)'에 무관한 응답 을 만족하도록 설계된 서비스 구조이다. 

Stateless Service Architecture

위와 같은 Stateless 서비스 구조를 생각해 보자. Client A의 요청이 로드밸런서를 통해 Server #1 으로 전달 되었다고 가정할 때, Stateful 서비스 구조에서는 server에 직접 ClientA와의 세션 정보를 저장했지만 Stateless 서비스 구조에서는 이 정보를  server에 저장하지 않고, 외부 DB에 저장한다. → Session Server

따라서 ClientA의 요청이 Server#2로 전달 되더라도, Server#2는 DB를 통해 ClientA 정보에 접근 가능하다. 
이러한 Stateless 구조에서는 ClientA의 요청을 Server#1에만 유지되도록 관리할 필요가 없다. 

 

3. Stateless Service의 장점

Statelss 구조가 Stateful 구조 대비 갖는 몇가지 장점들로 인해 최근의 웹서비스 구조는 모두 Stateless 구조 기반을 따르고 있다. 

그렇다면 Stateless Service가 어떤 점에서 유리할까? 여러가지 이유가 있겠지만, stateless 구조의 가장 큰 이점은 바로 Scaling이 자유롭다는 것이다. 

트래픽의 급증으로 서버가 scale out된 상황을 생각 해보자. 

Scaling Out of Stateful Service / Scaling Out of Stateless Service

• Stateful 서비스의 경우,
  • client의 세션 정보가 새로 scale out된 서버에 저장 되어 있지 않다
  • 따라서 세션 정보를 옮겨주는 등의 부수적인 관리가 요구된다.
• Stateless 서비스의 경우,
  • 어차피 server는 client 세션 관리를 하지 않으므로, 걱정할 필요가 없다!

scaling은 최근 웹 서비스들이 요구하는 중요한 기능이다. serverless 구조의 서비스 구현에서는 필수적이기 때문에 최근 웹 서비스 트렌드 동향에 발맞춰, scaling이 자유로운 Stateless 서비스 구조가 각광받고 있다. 

 

4. Stateless Service

stateless service를 검색하면 나오는 연관 검색어들이 HTTP, REST 이다.

HTTP는 Stateless한 프로토콜이다.

REST(Representational State Transfer)는 '구조(Architecture)' 의 이름이고, HTTP 프로토콜 상에 구현된 Resource Oriented Architecture(ROA) 설계 구조이다.

정리

HTTP와 REST 모두 Stateless한 성격을 가진 녀석들이며,
HTTP는 Statelss한 성격을 가진 '프로토콜'REST는 Stateless한 성격을 가진 '설계 구조' 이다.

 

참고

• https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%99%80-HTTP-%EB%B0%8F-REST
• https://kils-log-of-develop.tistory.com/609