Stateful / Stateless

개발을 하고 사이트를 구현하다보면 단순히 개발 지식만 알고있어야 하는게 아니라 그외의 부가적인 지식들도 알고있어야 한다.

네트워크가 그 중 하나라고 생각한다.

네트워크 개념 중 자주 언급되는 기본적인 개념인 Stateful 과 Stateless 에 대해서 정리해보자

---

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

네트워크 프로토콜이라고 봐도 무방하다.

 

해당 개념들을 정리하기에 앞서 우선 Session 에 대한 개념을 조금은 알 필요가 있다.

 

• Session이란
  • 일정 시간동안 같은 사용자(정확하게 브라우저를 말한다)로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술. 즉, 방문자가 웹서버에 접속해 있는 상태를 하나의 단위로 보고 세션이라고 칭한다

• Session 상태
  • 클라이언트와 서버간 통신 인증이 된 상태를 의미한다.
  • 인증된 상태에서 데이터 송수신이 가능하다.
• Session 정보
  • 한 세션 내에서, 클라이언트가 서버에 전송할 데이터 정보를 의미한다.
  • 서버는 세션 유지 시간이 지나거나, 클라이언트가 전송하려했던 데이터를 모두 수신할 때까지 클라이언트와의 세션 상태를 유지한다.

 

 

Stateful (상태 유지)

• 세션이 종료될 때까지, 클라이언트의 세션 정보를 저장하는 네트워크 프로토콜.
• 예시
  • TCP 프로토콜
    • TCP는 클라이언트와 서버간 3-way handshaking(연결 확정, 데이터 전송, 연결 종결)로 이루어져있다.
    • 클라이언트와 서버간 연결 확정 후, 데이터를 전송하고, 데이터 전송이 끝나면 연결이 종결된다.
  • 온라인 뱅킹
    • 은행(서버)은 고객(클라이언트)의 인증 정보(세션 상태)와 결제 내역(세션 정보)을 가지고 있다.
• 장점
  • 서버는 클라이언트의 세션 정보를 저장하므로, 갑자기 통신이 중단되더라도 중단된 곳부터 다시 시작할 수 있다.
• 단점
  • 확장성이 좋지 않다.
    • 클라이언트의 세션 정보가 새로 scale out 된 서버에 저장 되어 있지 않다.
    • 따라서, scale out 시, 클라이언트의 세션 정보를 새로운 서버에 옮겨주는 등의 부수적인 관리가 요구되므로, 확장성이 좋지 않다.

 

 

Stateless (무상태)

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

 

 

 

Stateful / Stateless 예시

▶ 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는 이 무상태를 특징으로 기본적으로 가지고 있다.

특별한 일이 없다면 무상태를 지향해야하며 정말 필요한 경우에만 상태 유지를 해야한다.