HTTP 웹 기본 지식 - Stateful, Stateless

Statefult, Stateless

HTTP의 또다른 중요한 특징 중 하나는, 무상태 프로토콜을 지향한다는 것이다.
이것을 영어로는 Stateless라고 한다.

Stateless는 서버가 클라이언트의 상태를 보존하지 않는 것을 의미한다.

Statefue은 상태를 유지한다는 것이고, Stateless는 상태를 유지하지 않는다는 것이다.

먼저 Stateful예제를 보자.

위와같은 상황이 있다고 가정해보자.

그런데 점원이 중간에 바뀌면 어떻게 될까?

Stateful이면 점원이 바뀌어도 점원은 클라이언트가 노트북을 보냇다는 상태를 유지한다.

그리고 고객이 2개구매한다고 했을 때도, 이 고객은 노트북을 구매하고싶어한다는 상태를 유지해서 알고 있는 것이다.

그리고 신용카드로 구매한다고 했을 때도, 노트북과 2개 라는 것이 상태가 유지되서 알고있는 상태로 점원은 신용카드 상태도 받게되는 것이다.

 

이번에는 무상태 stateless인 경우를 생각해보자.

Stateless인 경우에는,위의 예제와 같다.

고객에게 고객의 상태에 대한 책임을 넘긴 것 처럼 보여진다.

만약에 중간에 점원이 바뀌면 어떻게 될까?

Stateless에서는 점원이 중간에 바뀐것과 안바뀐 것의 차이가 없다!!!

Stateful에서는 중간에 다른 점원으로 바뀌면 Context가 사라져서 장애가날 수 있다.

Stateless에서는 중간에 다른 점원으로 바뀌어도 Context가 고객에게 있기 때문에 점원이 바뀌어도 상관이 없다.

즉, Stateless(무상태)에서는 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

다시말해, Stateless(무상태)는 응답 서버를 쉽게 바꿀 수 있다. 이는 곧 무한한 서버 증설이 가능함을 의미한다.

 

이것을 그림으로 살펴보면, 위와 같다.

Stateful은 항상 같은 서버가 유지되어야 한다.

Stateful에서 중간에 서버가 장애가 나면 어떻게 될까?

클라이언트 A는 결제를 처음부터 다시 해야 할 것이다.

그런데 Stateless는 애초에 클라이언트가 서버에 요청할 때부터 필요한 데이터를 다 담아서 보낸다.
그러면 서버는 상태를 보관하지 않고, 필요한 응답만 한다.

이것의 장점은

만약에 중간에 서버1번이 장애가 나도, 서버2로 교체해도 그대로 서비스를 할 수 있다.

 

Stateless는 스케일 아웃 이라고 해서 "수평 확장에 유리" 하다는 장점이 있다.

예를 들어서 ,
만약에 Stateless로 설계를 하면 어떤 이벤트를 진행할 때, 트래픽이 몰리면 백엔드에서 장비를 늘려서 서버를 자유롭게 늘릴 수 있다.

 

하지만 Stateless도 한계가 있다. 모든것을 무상태로 설계할 수는 없다. 그리고 데이터를 너무 많이 보낸다는 단점도 있다.

예를 들어서 로그인이 필요없는 단순한 화면은 무상태로 설계할 수 있겠지만,

로그인과 같이 상태를 유지해야 하는 경우에는 무상태로 설계할 수 없다.
이러한 경우에는 일반적으로 브라우저 쿠기와 서버 세션 등을 사용해서 상태유지(Stateful)한다.

이러한 한계점을 받아들이고, 상태유지는 최소한만 사용해야 한다.