우리가 흔히 쓰는 HTTP 프로토콜은 stateless 한 architecture 이다. stateless 와 stateful 한 architecture 를 비교해보자.
Stateful vs Stateless
stateful
- 웹 서버가 세션 정보를 서버에 저장한다.
- 클라이언트 세션 상태에 따른 응답을 한다.
stateless
- 서버의 응답이 클라이언트의 세션 상태와 독립적이다.
- 서버는 클라이언트 세션에 무관한 응답을 준다.
- 서버는 단순히 요청이 오면 응답만 해주고, 세션에 대한 관리책임은 클라이언트에게 있다.
- 서버는 단순히 응답만 해주면 되기 때문에 클라이언트의 세션정보를 기억할 필요가 없으므로 이 정보를 따로 서버에 저장하지 않는다.
- 따라서 매 통신마다 모든 정보를 담아서 보내주어야 한다.
- user validation 같은 경우, 유저 인증정보(주로 토큰형식)를 외부 DB에 따로 정보 저장한다.
Stateless Service, why better than Stateful Service?
Why Stateless?
- stateful 의 경우 클라이언트가 일단 서버에 접속하면 특정 서버와 계속해서 연결 상태에서 있어야 되는데 이 부분을 관리하는데 cost 가 많이 든다.
- 하지만 stateless 인 경우 클라이언트와 서버의 연결 고리가 없기 때문에 요청을 보낼 때마다 아무 서버나 서비스할 수 있는 구조이기이다. 따라서 웹 서버를 확장한다고 했을 때 고려해야 할 부분이 줄어든다.
우리가 stateless 를 이해하기 위해서 게임을 예시로 들면 매우 잘 와닿을 것이다.
- stateless 서버는 서버의 오류가 발생 하여도 일부 유저,일부 기능에만 문제가 생긴다.
- 모든 데이터는 DB 기준으로 처리 하기 때문에 서버 다운의 롤백이 없다. 서버가 터졌을 때 유저 데이터가 날아가지 않는 것 처럼 말이다.
- 서버의 분산 처리가 용이하다. 왜냐면 서버에 클라이언트 세션을 저장하지 않기 때문이다.
여기서 stateless 서버의 장점 중 가장 중요하다고 생각되는 부분은 바로
--> 트래픽 급증에 따른 서버 확장(server scaling out) 이다.
Server Scaling out for stateful service :
만약 특정 서버에 클라이언트 세션을 저장한다고 생각해보자.
-
client의 세션 정보가 새로 확장된 서버에 저장 되어 있지 않다.
-
따라서 세션 정보를 새로 확장된 서버로 옮겨주는 등의 부수적 cost 가 발생한다.
Server scaling out for Stateless Service
- 서버는 클라이언트 세션 관리를 하지 않고 외부 DB 에서 필요한 정보만 따로 관리를 하기 때문에, 서버 확장 시 이런 점을 고려할 필요가 없다.
wrap-up
따라서 요즘 시대에 stateless 한 architecture 를 사용하는 HTTP 프로토콜을 사용하는 것은 위에서 설명한 매우 많은 이점 덕분이라고 생각할 수 있다.
Reference
[Stateful/Stateless] Stateful vs. Stateless 서비스와 HTTP 및 REST
Stateful and Stateless Applications Best Practices and Advantages
https://www.xenonstack.com/insights/stateful-and-stateless-applications/
Backend Developer