Stateful / Stateless 차이점
Stateful (상태유지)
상태 유지라 함은 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미한다.
클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는데 있어, 서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태이다.
대표적으로 홈페이지에서 한번 로그인을 하면 페이지를 이동해도 로그인이 풀리지않고 계속 유지되는 것이 바로 서버가 클라이언트의 상태를 유지(기억)하고 있으니까 가능한 것이다.
클라이언트의 정보를 기억한다라는 말은 어딘가에 정보를 저장하고 통신할때마다 읽는다는 뜻이다.
이러한 정보들은 일반적으로 브라우저의 쿠키(Cookie)에 저장되거나, 서버의 세션(Session) 메모리에 저장되어 상태를 유지하게 된다.
Stateful 통신 예시
1
2
3
4
5
6
7
8
고객: 이 노트북 얼마인가요?
점원A: 100만원 입니다. **(노트북 상태 유지)**
고객: 2개 구매하겠습니다.
점원A: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?**(노트북, 2개 상태 유지)**
고객: 신용카드로 구매하겠습니다.
점원A: 200만원 결제 완료되었습니다. **(노트북, 2개, 신용카드 상태 유지)**
대화를 보면 판매하는 점원 A는 사용자의 이전 요청을 모두 기억하며 진행한다는 것을 알 수 있다.
이것이 상태 유지이며 사람 입장에서는 지극히 정상적인 대화 처럼 보인다.
하지만 여기엔 함정이 있다. 바로 판매하는 점원A 가 중간에 바뀔 경우 이다.
만약 대량의 트래픽(고객)이 몰려들어서 서버(점원)를 긴급하게 늘렸다고 가정해보면, 판매자 점원A 가 아닌 증설된 어떤 점원 B가 구매과정을 대신 이어받게 될 수도 있다.
다음은 고객과 통신하고 있는 점원A 가 중간에 점원 B와 점원 C로 바뀌었을 경우의 상황이다.
1
2
3
4
5
6
7
8
고객: 이 노트북 얼마인가요?
점원A: 100만원 입니다.
고객: 2개 구매하겠습니다.
점원B: ? 무엇을 2개 구매하시겠어요?
고객: 신용카드로 구매하겠습니다.
점원C: ? 무슨 제품을 몇 개 신용카드로 구매하시겠어요?
Stateful 문제점
위에서 상태를 유지한다는 함은, 서버에서 클라이언트의 상태 정보를 저장하고 있다고 말했었다.
stateful의 문제점은 해당 서버가 멈추거나 여러 이유로 해당 서버가 못쓰게 되어 다른 서버를 사용해야 할때 발생한다.
왜냐하면 새로운 서버에서는 이전 서버에서 가지고 있던 상태값들을 가지고 있지 않기 때문이다.
위의 예시로 설명하자면, 점원 A는 고객의 요청 상태를 유지하고 있다. 하지만 중간에 점원A가 정상적인 작동을 하지 못하는 경우가 발생했을 때, 고객은 일을 처음부터 다시 해야한다.
또한 Stateful 방식은 하나명의 점원이 1만 명의 클라이언트를 처리할 능력이 있을 때 그보다 많은 수의 클라이언트가 몰리면, 이미 연결된 1만 명의 클라이언트 중 일부가 빠져야 다음 클라이언트가 처리된다는 한계가 있다.
당연히 클라이언트 상태들을 들고 있으니 용량 한계가 존재하기 때문이다.
Stateful한 프로토콜
대표적인 Stateful 구조를 따르는 프로토콜로 TCP의 3-way handshaking 과정을 예를 들수가 있다.
클라이언트는 서버에 SYN(접속 요청 메세지)를 전송하고 SYN_SENT 상태가 된다.
서버는 SYN 요청을 받고, 클라이언트에 요청을 수락하는 SYN/ACK를 전송하고 SYN_RECEIVED 상태가 된다.
클라이언트는 서버에게 수락 확인으로 ACK를 또 보내고, 수신 받은 서버는 ESTABLISHED 상태가 된다.
세션 ‘상태’가 ESTABLISHED 가 됨으로써, 서버와 클라이언트는 서로 데이터를 주고 받을 수 있는 상태가 된다.
이렇게 TCP는 세션 ‘상태’에 따라 서버의 응답이 달라지게 되는 Stateful 하다고 말할수 있는 것이다.
Stateless (무상태)
무상태는 반대로 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미한다.
Stateless 구조에서 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행하며, 상태 관리는 전적으로 클라이언트에게 책임이 있는 것이다.
즉, 클라이언트와 서버간의 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보내는 것이 무상태 구조이다.
서버는 단순히 받아서 응답만 해주기 때문에 상태 유지에 대한 부하가 현저히 줄어들게 된다.
Stateless 통신 예시
1
2
3
4
5
6
7
8
고객: 이 **노트북** 얼마인가요?
점원: 100만원 입니다.
고객: **노트북 2개** 구매하겠습니다.
점원: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?
고객: **노트북 2개를 신용카드**로 구매하겠습니다.
점원: 200만원 결제 완료되었습니다
위의 대화에서 처럼 무상태 통신은 고객과 점원사이에 필요한 모든 상태 정보들은 고객에서 가지고 있다가 점원과 소통할때 데이터를 실어 보내는 것이다.
서버는 단순히 받아서 응답만 해주기 때문에 상태 유지에 대한 부하가 현저히 줄어들게 된다.
또한 상태를 보관하지 않아 서버 1에 문제가 생겨 서버 2가 이어 받아도 응답하는데 있어 문제도 없다.
그래서 대량의 트래픽 발생 시에도 서버 확장을 통해 대처를 수월하게 할 수 있다는 장점도 있다. (stateful과 달리 서버가 바뀌어서도 정확한 응답에 문제가 없으니까)
Stateless 문제점
무상태의 단점으로는 클라이언트의 요청에 상대적으로 Stateful 보다 더 많은 데이터가 소모되게 된다는 점이다.
매번 요청할때마다 자신의 부가정보를 줘야한다.
물론 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들면 좋다.
하지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는 서비스는 상태를 유지하지 않으면 로그인이 풀려버린다.
따라서 모든 것을 무상태로 설계할 수 없다. 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용하는 것이 베스트이다.
Stateless한 프로토콜
대표적인 Stateless 프로토콜로는 UDP와 HTTP 를 들 수 있다. (HTTP 통신 기본이 무상태)
무상태에선 브라우저는 데이터를 전송할 때마다 연결하고 바로 끊어버리게 된다.
UDP를 예로 들어 보자면, UDP는 TCP와 달리 handshaking 과정을 통해 연결 세션을 인증하는 절차를 수행하지 않고, 세션 상태에 관계 없이 그냥 무작정 보내 버린다.
그래서 서버쪽은 클라이언트와의 세션 정보를 저장하는 과정을 거치지 않아, 클라이언트가 송신한 데이터가 수신되었는지 확인하지도 않으며 클라이언트와의 세션 상태에 관계없이 요청에 대한 응답만을 수행하게 된다.
즉, Client와의 세션 정보를 Server가 저장하지 않는다는 점에서 Stateless 하다고 말할 수 있는 것이다.
📑 참고 자료