Stateless & Connectionless

HTTP의 특징 중 2가지이다.

 

1. Stateless (클라이언트와 서버 사이의 상태를 유지하지 않는 것)

클라이언트가 현재 무엇을 사고 싶은지, 어떤 지불방법을 했는지 등등 고객의 상태를 저장하지 않음으로써 자원을 아낌

그렇기 때문에, 매번, 고객의 상태 및 정보를 request를 날릴 때마다, 알려줘야 한다.

자원의 낭비는 막을 수 있지만, 데이터를 너무 많이 보내게 됨.

: 로그인이 필요 없는 단순한 서비스 소개 화면 등은 stateless로 구현

but, 로그인 같은 것은 stateful로 구현해야 한다.

하지만, 로그인한 사용자의 경우는 로그인했다는 상태를 서버에 유지

일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지

-> 매번, 브라우저 쿠키에서의 정보를 서버로 보내고 서버에서는 받은 정보를 서버의 세션과 동일한지 체크

 

*Scale out  수평 확장에 유리하다. 같은 기능을 하는 서버를 여러 개 둘 수 있고 어떠한 서버에서도 처리가 가능

 

Q. 이렇게 쿠키와 서버 세션이 없을 경우, stateless하기 때문에, 매번 아이디와 비밀번호를 request할 때 요청해야 하고,

이는 계속 DB 접근을 필요로 한다. 보통의 세션은 HDD, SDD와 같은 보조기억장치에 보관하게 된다. (서버 분산이 필요한 경우 DB에서 관리하기도 한다.)

But, HDD, SDD는 메모리(램)에 비해 터무니 없이 느림...

그런데 모든 데이터는 기본적으로 램에 적재되어야만 CPU가 처리할 수 있다.

그래서 세션파일을 메모리에 적재하는 프로세스가 계속 발생하게 됨.

 

이 때 세션에서 관리하는 데이터가 많으면 많을수록 데이터를 램에 적재하는 프로세스는 계속 무거워진다.

서버에서는 이런 작업이 수천번 이상 이루어질 수 있는데 이 횟수가 늘어나면 늘어날수록 비효율적이 된다.

그래서 가급적 서버는 클라이언트에 관한 정보를 들고 있지 않는 게 자원적으로 좋다고 하는 것

 

(예를들면 상품 리스트를 보기 위해 클릭이 세번 필요한 A가 있고, 한번 필요한 B 사이트가 .있다고 하겠습니다. 천명의 고객이 A사이트를 이용하면 리스트 이동까지 총 3천번의 클릭이 필요합니다. 그 중간 클릭 과정도 계속 서버에서 데이터를 요청받아야 한다고 생각하면 최소 3천번의 리퀘스트가 발생합니다. B사이트는 반면에 최소 1천번의 데이터를 요청하겠지요. 요점은 사소한 차이도 누적되면 어마어마한 차이가 난다는 것입니다)

 

 

 

2. Connectionless ( TCP/IP 커넥션 연결을 지속하지 않는다는 것)

클라이언트의 연결을 유지하기 위한 IP주소나 Port 정보들을 저장하지 않음으로써 서버 자원을 효율적으로 사용.

요청 및 응답이 끝나면 TCP/IP 연결을 종료 시켜 버림

매번 TCP/IP 연결을 새로 맺어야 한다.

지금은 HTTP 지속 연결(persistent connections)로 문제 해결

: Pesistence Connection은 연관된 요청들이 연속해서 들어올 경우에는 연결을 종료하지 않고 연결을 유지하다가, 일련의 연관 요청들이 모두 종료된 후에 연결을 종료하는 방식(특정 시간까지 연결을 유지, 보통 60초)

 

 

 

 

***** 더 생각해봐야 할 문제!!!

스테이리스를 기억하자

(서버 개발자들이 어려워하는 업무)

- 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽

ex) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록

ex) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 -> 수만명 동시 요청

 

====> 최대한 stateless하게 만들어야 한다.

그렇게 해야 같은 시간에 대용량 트래픽이 발생하는 경우, 서버를 확 증설해서 대응이 가능함.

무상태로 있을 수 있는 것은 무상태로, (like 처음 시작 정적 페이지)

 

예를 들어서 네이버 같은 곳에서 베너를 선택해보면, 해당 사이트의 홈페이지로 바로 이동하는 것이 아니라 특별한 이벤트 페이지로 연결되는 경우를 종종 볼 수 있습니다. 이런 부분이 대부분 정적 페이지로 보시면 됩니다. 이런 정적 페이지는 로그인도 필요없고, 정적인 HTML을 그대로 출력하는 경우가 많습니다.

-> 높은 트래픽이 예상될 때 정적 페이지로 일차적으로 랜딩시키면 일순간 몰린 사용자들에게 정적 페이지를 우선 보여줌으로써 특정 액션을 하는 시점을 분산시키는 것이 목적

*** 특정 액션을 하는 시점을 분산? 결국에는 같은 시간대에 들어가고 싶은 하는 사람들이기에 미리 준비해서

시간이 되었을 때 들어가려고 할 텐데 효과가 있을까?

 

***접속량이 많은 경우, 대기열을 부여하는 경우가 많이 있는데, 서버를 여러 대 사용할 경우, 대기인원의 순서 동기화가 어떻게 이루어지는지? -> 대기열은 완전히 다른 방식으로 이루짐. 보통 별도의 대기열을 관리하는 서버를 두고 거기서 대기열 순서를 다 관리한다.

 

***로직을 처리하는 서버는 여러 대여도 중심 DB는 하나일 텐데 트랜잭션을 할 때 병목이 발생하지 않는지?

-> 충분히 발생할 수 있으며, 이런 문제를 해결하기 위해 여러 가지 대응 방안이 있다.

1. 데이터베이스 샤딩

2. 비동기 큐를 활용한 데이터 저장