[주요 개념] Stateful 과 Stateless

들어가기 앞서,

• Stateful과 Stateless는, 클라이언트와 서버간의 네트워크 통신이 어떻게 이루어지는지에 대한 개념입니다.

세션 상태 및 세션 정보란?

• Stateful 과 Stateless 의 개념을 이해하기 위해선, 세션 상태와 세션 정보에 대한 개념을 알아야합니다.
• 세션 상태
  • 클라이언트와 서버간 통신 인증이 된 상태를 의미합니다.
  • 인증된 상태에서 데이터 송수신이 가능합니다.
• 세션 정보
  • 한 세션 내에서, 클라이언트가 서버에 전송할 데이터 정보를 의미합니다.
  • 서버는 세션 유지 시간이 지나거나, 클라이언트가 전송하려했던 데이터를 모두 수신할 때까지 클라이언트와의 세션 상태를 유지합니다.

Stateful

• 세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 방식입니다.
• 예제
  • 온라인 뱅킹
    • 은행(서버)은 고객(클라이언트)의 인증 정보(세션 상태)와 결제 내역(세션 정보)을 가지고 있습니다.
• 장점
  • 서버는 클라이언트의 세션 정보를 저장하므로, 갑자기 통신이 중단되더라도 중단된 곳부터 다시 시작할 수 있습니다.
• 단점
  • 확장성이 좋지 않습니다.
    • 클라이언트의 세션 정보가 새로 scale out 된 서버에 저장 되어 있지 않습니다.
    • 따라서, scale out 시, 클라이언트의 세션 정보를 새로운 서버에 옮겨주는 등의 부수적인 관리가 요구되므로, 확장성이 좋지 않습니다.

Stateless

• 서버가 클라이언트의 세션 상태 및 세션 정보를 저장하지 않는 방식입니다.
  • 즉, 요청에 대한 응답만 처리하는 방식입니다.
  • 각 통신은 선행되거나 후속으로 따라오는 통신과 관련이 없습니다.
  • 클라이언트가 송신하려 했던 모든 데이터가 서버쪽에 수신 되었는지 확인하지 않습니다.
• 예제
  • 온라인 검색(검색창에 질문을 입력하고 엔터키를 누르는 형식)
    • 검색창에 질문을 입력하다가 요청이 중단되어도, 다시 검색하면 됩니다.
• 장점
  • 확장성이 좋습니다.
    • 서버가 클라이언트의 세션 상태 및 세션 정보를 저장하지 않기 때문에, 확정성이 좋습니다.
• 단점
  • 서버가 세션 상태 및 세션 정보를 저장하지 않기 때문에, 클라이언트 측에서 송신할 데이터의 양이 많아집니다.

Stateful 추가 예제

• 자전거를 사려는 클라이언트 A 와 자전거를 판매하는 서버 B 가 있으며, A 가 B 의 자전거를 산다고 가정해봅시다.
  • A : 자전거 사려합니다.
  • B : 자전거 커스텀 재료를 골라주세요. (자전거를 사려한다는 것을 기억한다.)
  • A : 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요.
  • B : 배송은 어디로 해드릴까요? (자전거를 사려했다는 것을 기억하고 있다.)
  • A : 집으로 보내주세요.
  • B : 결제는 무엇으로 해드릴까요? (자전거를 사려했다는 것, 커스텀을 어떻게 했는지 알고 있다.)
  • A : 카드로 결제할게요
  • B : 결제 완료 되었습니다. (위의 모든 사용자가 요구했던 사항을 기억하고 있다.)
• 지극히 정상적인 대화처럼 보이며, 자전거를 판매하는 B 서버는 사용자의 이전 요청을 모두 기억하며 진행한다는 것을 알 수 있습니다.
• 이것이 바로 상태 유지입니다.
• 하지만 여기엔 함정이 있습니다.
• 바로 판매하는 서버 B 가 바뀔 경우입니다.
• 만약, 대규모의 트래픽이 몰려들어서 서버를 긴급하게 늘렸다고 생각해봅시다.
• 그러면, 판매자 서버가 B 가 아닌 증가된 어떤 서버 C 가 될 수도 있습니다.
• 그렇게 된다면, 서로간의 대화는 다음과 같이 진행됩니다.
  • A : 자전거 사려합니다.
  • B : 자전거 커스텀 재료를 골라주세요
  • A : 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요.
  • B : 예?
  • A : 집으로 보내주세요.
  • B : 예?
  • A : 카드로 결제할게요
  • B : 예?
• 이게 바로 상태 유지의 문제입니다.
• 이를 해결하기 위해 무상태가 등장합니다.

Stateless 추가 예제

• 동일하게, 자전거를 사려는 클라이언트 A 와 자전거를 판매하는 서버 B 가 있으며, A 가 B 의 자전거를 산다고 가정해봅시다.
  • A : 자전거 사려합니다.
  • B : 자전거 커스텀 재료를 골라주세요. (서버는 아무것도 기억하지 않는다.)
  • A : 자전거 사려합니다. 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요.
  • B : 배송은 어디로 해드릴까요? (서버는 아무것도 기억하지 않는다.)
  • A : 자전거 사려합니다. 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요. 배송은 집으로 보내주세요.
  • B : 결제는 무엇으로 해드릴까요? (서버는 아무것도 기억하지 않는다.)
  • A : 자전거 사려합니다. 휠은 검정색, 핸들은 검정색, 바디는 흰색, 안장은 흰색으로 해주세요. 배송은 집으로 보내주세요. 결제는 카드로 결제할게요
  • B : 결제 완료 되었습니다. (서버는 이제 요청을 처리한다.)
• 이게 바로 무상태입니다.
• 이전의 클라이언트의 요청을 유지하지 않는다는게 핵심입니다.
• 무상태는 기존의 서버가 혼잡해져서 새로운 서버를 가져다 놓아도, 계속 일을 처리할 수 있습니다.
• 단점은 클라이언트가 하고자하는 최종 목적을 위해, 전달해야하는 내용이 많아진다는 것입니다.

참고

• https://www.redhat.com/ko/topics/cloud-native-apps/stateful-vs-stateless
• https://swdevelopment.tistory.com/144
• https://irostub.github.io/web/stateful-stateless/
• https://jjy0821.tistory.com/36
• https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-서비스와-HTTP-및-REST