Stateful과 Stateless
Http의 특징 중 Stateful과 Stateless에 대해 알아보자.
Stateful(상태 유지)
Stateful(상태 유지)란, 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하는 것을 뜻 합니다. 클라이언트가 연결을 끊을 때 까지 서버와 클라이언트는 계속 연결되어있다.
예를 들어 살펴보자.
- 자전거 판매를 하는 서버 X
- 자전거 사려는 클라이언트 A
다음과 같은 상태에서 Stateful 상태는 어떻게 작동되는지 알아보자.
클라이언 A는 서버 X에게 자전거의 조건들, 요구사항들을 하나 씩 전달하고, 서버는 그에 맞춰 작동한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
A : 자전거 사려합니다.
X : 자전거 옵션을 선택해주세요. (A가 저전거 사려하는 것을 기억)
A : 휠과 바디는 검정색, 안정은 흰색으로 해주세요.
X : 배송은 어디로 해드릴까요? (자전거의 옵션과 A가 자전거 사려는 것을 기억)
A : 집으로 해주세요.
X : 결제는 어떻게 도와드릴까요? (자전거의 옵션, A가 자전거를 사려는 것, 배송은 집이라는 것을 기억)
A : 카드로 하겠습니다.
X : 결제가 완료되었습니다. (위 모든 사용자가 요구했던 사항을 기억)
이와 같이 X 서버는 사용자가 이전 요청을 모두 기억한다는 것을 알 수 있고, 이러한 상황을 Stateful(상태 유지)라고 한다.
하지만 여기엔 큰 문제가 있다. 바로 서버 X가 바뀌었을 때 문제가 발생한다.
서버 X에게 문제가 생겨 서버 Y 로 바뀌었다고 가정하자.
그럼 위의 대화는 다음과 같이 진행된다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
A : 자전거 사려합니다.
X : 자전거 옵션을 선택해주세요.
A : 휠과 바디는 검정색, 안정은 흰색으로 해주세요.
Y : 뭘요????
A : 집으로 해주세요.
Z : 예??
A : 카드로 하겠습니다.
Y : ????????
이와 같이 서버가 변경되었을 때 그 전 서버가 가지고 있던 클라이언트의 상태가 소실된다.
Statesless(무상태)
Statesless는 클라이언트가 요청을 보내고 그 요청을 리턴했을 때 서버가 종료된다.
위와 같은 똑같은 예제로 Statesless에 대해 알아보자.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
A : 자전거 사려합니다.
X : 자전거 옵션을 선택해주세요. (서버는 아무것도 기억하지 않음)
A : 자전거를 사려합니다. 휠과 바디는 검정색, 안정은 흰색으로 해주세요.
Y : 배송은 어디로 해드릴까요? (서버는 아무것도 기억하지 않음)
A : 자전거를 사려합니다. 휠과 바디는 검정색, 안정은 흰색으로 해주세요. 집으로 해주세요.
Z : 결제는 어떻게 도와드릴까요? (서버는 아무것도 기억하지 않음)
A : 자전거를 사려합니다. 휠과 바디는 검정색, 안정은 흰색으로 해주세요. 집으로 해주세요. 카드로 하겠습니다.
X : 결제가 완료되었습니다. (서버는 아무것도 기억하지 않음)
이와 같이 이전의 클라이언트의 요청(상태)를 유지하지 않는 것이 핵심이다. 만약 새로운 서버가 들어와도 기존의 로직을 그대로 구현하고 있다면 이전의 사용자 요청이 어떤지에 관계없이 처리가 가능하다. 즉, 스케일 아웃(수평확장)이 유리하다.
장점 : 서버의 확장성이 높기 때문에 대량의 트래픽 발생 시에도 대처를 수월하게 할 수 있습니다.
단점 : 클라이언트의 요청에 상대적으로 Stateful 보다 더 많은 데이터가 소모됩니다.
정리
기본적으로 Statesless로 설계하는 것을 지향해야한다. 하지만 모든 것을 Statesless로 설계할 수는 없다.
로그인을 예로 들자면, 로그인이 필요없는 단순한 서비스의 경우 무상태로 설계 가능하지만, 로그인같은 경우 상태를 유지해야되기 때문에 Stateful로 설계해야한다.
출처)