Stateless/Stateful 이란?
서버 사이드와 클라이언트 사이드간 통신에서 서버가 클라이언트가 요청한 내용을 기억하고 있는지 아닌지를 나타낸다고 생각하면 된다.
- State(상태) : 서버와 클라이언트의 통신 기록
Stateful
- 클라이언트가 요청한 내용을 서버가 기억하고 있다.
- 클라이언트와 서버의 세션 State 를 기억하고 있다가 서버는 연속되는 클라이언트의 요청에 세션 State 를 기반으로 응답한다.
ex) 편의점에서 1+1 음료를 구매한다.
<클라이언트> xxx 음료 하나 계산해 주세요.
<서버> 5000원 입니다.
--- 1분뒤 클라이언트는 편의점에 재 방문해 동일 음료를 하나 더 구매한다.
<클라이언트> xxx 음료 하나 계산해 주세요.
<서버> 네. 1분전에 음료 구매해 주셨는데 1+1 행사 상품이라 무료로 가져가시면 됩니다.- 이처럼 서버는 클라이언트의 이전 State(대화 기록) 을 저장해 놓았다가 클라이언트의 다른 요청에 이전 세션 State 를 참고해 응답한다.
장점
- 서버가 클라이언트의 요청을 기억하고 있음으로 요청 처리 성능면에서는 우수 할 수 있다.
단점
- 하지만, 우리는 하나의 클라이언트-서버를 사용하는 것이 아니다. 위 편의점 예제에서 1분만에 서버가 변경되었다고 생각해보자. 그럼 서버는 1+1 제품이라도 이전 요청을 알지 못하니 다시 계산을 할 것이다.(세션 상태를 가지고 있지 않다.)
- 이렇게 각 서버가 전담하는 클라이언트가 명확히 구별되 버림으로 유연성이 떨어지게 된다.
Stateless
- 클라이언가 요청한 내용을 서버는 기억하지 않는다.
- 요청한 내용을 서버는 매번 처음 요청 받는 것 처럼 응답한다.
ex) 편의점에서 1+1 음료를 구매한다.
<클라이언트> xxx 음료 하나 계산해 주세요.
<서버> 5000원 입니다.
--- 1분뒤 클라이언트는 편의점에 재 방문해 동일 음료를 하나 더 구매한다.
<클라이언트> xxx 음료 하나 계산해 주세요.
<서버> 5000원 입니다.
--- 만약 1+1 음료를 받고 싶다면.
<클라이언트> xxx 음료 하나 계산해주세요. 그런데 이 음료 1+1 인가요?
<서버> 네. 1+1 행사 상품이라 무료로 가져가시면 됩니다.- 서버는 클라이언트가 이전에 어떠한 행동을 했는지 기억하지 않고 독립적으로 응답하게 된다.
장점
- 서버와 클라이언트는 독립적으로 요청-응답 을 처리하기 때문에 서버가 변경되거나 클라이언트가 변경되어도 동일한 응답을 처리 할 수 있게 된다.
- 이에 따라 유연성이 증가하게 되고, Scaling 처리도 유연하게 대응 할수 있다.
단점
- Stateful 과 반대로 클라이언트가 전송해야 하는 요청 컨텍스트 양이 증가한다.
Statless 를 더 많이 사용하는 이유.
- 우리가 만드는 서비스들은 유연해야 하고 Scaling 가능해야 한다.
- 상태를 유지한다는 것을 서버가 기억하고 있는 것 자체가 서버에 부하이다.
- HTTP 와 REST 역시 모두 Statless 로 통신하고 있다.
그렇다면 Stateful 은 사용하지 않는가?
- 그렇지않다. 모든 아키텍처와 기술들이 그렇듯이 적절한 곳에 사용되어 질 수 있다. Stateful 은 상태 정보를 기억해야 하는 로그인 과 같은 정보를 유지해야 하는 경우 사용 될 수 있다. 하지만, 로그인 정보를 서버에서 매번 기억하는 것은 부담스럽다.(위에 말한 것 처럼)
- 이에 대한 대책으로는 로그인 정보에 대한 기억으로 Stateless 를 사용하되 JWT 토큰 과 같은 토근 인증 방식을 사용하여 클라이언트가 내가 인증된 사용자 임을 알려주는 방식이 있을 수 있다.
