이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
이론적으로 설명하는 것보다 예제를 통해서, 쉽게 이해해보자!!
=> 점원 B는 A와 나눈 대화를 모르고, C는 B와 A와 나눈 대화를 모른다.
=>이렇게 서버가 클라이언트의 상태를 보존하지 않는 것을 Stateless라고 한다.
=> 만약, 서버가 클라이언트의 모든 상태를 보존한다면, Stateful이 되는 거다.
=> 이거 너무 당연한 말 아닌가 싶을 거다. 그런데, 이게 상당히 큰 차이를 만든다.
정리해보자!!
점원이 한 명과 소통한다면, 상태 유지도 상관없다.
그러나, 문제는 점원이 바뀌었을 때. 이전 점원과 한 대화를 전혀 모른다.
그렇기 때문에, 고객이 점원에게 필요한 데이터를 다 그때그때 넘긴다면, 한 명의 점원과 대화를 하든, 여러 명의 점원들과 대화를 하든 원활한 소통이 가능하다.
이게 클라이언트 - 서버 아키텍쳐에서는 엄청난 확장성을 가져온다.
거의 무한 증식을 할 수 있다.
=> 갑자기 클라이언트 요청이 확 들어와도, 무상태에서는 서버 증설하고 아무데나 들어오면 되기 때문에 서버의 무한 증식이 가능하다. 즉, 무상태는 서버의 응답 서버를 쉽게 바꿀 수 있다.
상태 유지
만약에, 서버에 결제 요청을 한다고 하면,
=> 이렇게 장애가 나면, 클라이언트A 는 처음부터 결제를 다시 진행해야 한다.
무상태
그러나, 무상태는 클라이언트가 애초에 요청할 때부터 필요한 데이터를 다 담아서 보낸다.
=> 소통하던 서버1이 갑자기 에러가 나도, 클라이언트A의 요청을 다른 서버로 보내면 그만이다.
=> 서버2 입장에서는 서버1 과 하던 일을 알아야할 필요가 없다. 왜냐면, 알아야될 모든 정보는 클라이언트A가 보내주니까...
- 이렇게 서버를 무한 증식하는 것을 "스케일 아웃" 혹은 "수평 확장"이라고 부른다.
예를 들어서, 블랙 FRIDAY 같은 빅 이벤트가 있으면, 서버를 수 만대로 늘려버릴 수가 있다.
무상태성의 한계
그러나, 모든 상황을 무상태성으로 설계할 수는 없다.
예를 들어서, "이벤트 소개" 같은 단순한 페이지는 무상태로써 최적의 케이스이다.
그러나, "로그인" 같은 경우는 로그인 했다는 상태를 유지해야 한다. 즉, 무상태가 되면, 로그인이 풀리기 때문에 서비스에 문제가 생긴다.
일반적으로는, 브라우져의 쿠기와 서버의 세션을 조합해서 로그인 상태를 유지하는 기능을 사용한다.
그럼에도, "상태유지"는 정~말~ 최소한으로만 사용해야 한다. 꼭 필요한 경우에만 어쩔 수없이 사용해야 한다.
또한, 무상태성의 단점이 하나가 더 있다.
바로 서버에 데이터를 너무 많이 보낸다.
"노트북 2개를 신용카드로 구매하겠습니다" vs "신용카드로 구매하겠습니다"
전송된 데이터양의 차이가 있다.
로그인은 왜 "무상태(stateless)"일 수 없나요??
다음 시간에는 "비연결성"에 대해서 알아보자!!
