- Stateless
- 웹서버 통신(http) 특성상 사용자(브라우저)의 이전 상태 client(쿠키) or server(세션) 정보를 기록하지 않는 접속이란 의미입니다.
- 브라우저가 데이터를 전송할 때마다 연결하고 바로 끊어버리는 방식입니다.
- Stateless 서비스는 가용성을 제공하기 위해서 여분의 인스턴스를 추가하고 로드 벨런스를 사용합니다.
- Stateful
- 웹서버가 사용자(브라우저)의 상태 client(쿠기) or server(세션) 정보를 기억하고 있다가 유용한 정보로써 활용한다는 의미입니다.
- 클라이언트에서 다른 클라이언트로, 또는 서버에서 특정 클라이언트로 메시지를 전송할 수 있습니다.
- 서버에서 클라이언트 세션을 유지할 필요가 없을 때 서버 리소스를 절약하는 장점이 있습니다.
- Stateful 방식은 하나의 서버가 1만 명의 1만 명의 클라이언트를 처리할 능력이 있을 때 그보다 많은 수의 클라이언트가 몰리면 이미 연결된 1만 명의 클라이언트 중 일부가 빠져야 다음 클라이언트가 처리됩니다.
- 하지만 Stateless 방식은 순간 접속 요청 인원을 기준으로 하므로 많은 클라이언트가 몰려도 할당된 처리량이 끝나면 다음 처리가 가능합니다.
쿠키 or 세션 유무에 따른 웹서버 통신 방식
- Stateful 서비스
- 기능상 Stateful 방식이 강력하고 편리합니다.
- Stateless의 모든 기능은 Stateful 방식으로도 구현이 가능하지만 그 반대는 아닙니다.
- Stateless의 단점은 매 요청 시마다 상태 정보를 전달해야 하기 때문에 그만큼 네트워크 리소스를 소비해야 합니다.
- 또한, 서버 쪽에서는 메시지 처리하기 위한 사전 작업이 필요합니다. 예를 들면 http 통신방식에 client의 요청은 서로 완전히 독립적이고 이전 요청에 의존적이지 않습니다.
- 따라서 각각의 요청은 server가 처리할 수 있도록 하기 위한 모든 정보를 제공해야 합니다.
- 그러나 Stateful 서비스에 있어서 가용성을 제공하기 위해서는 여분의 인스턴스와 '로드 벨런스'로 충분하지 않습니다. 즉 Stateful 한 서버의 상태 정보를 구현하기 복잡합니다.
- Stateful 통신 구조의 한계
- 1. Session의 한계 : 서버의 무리가 감
- 2. Scale out의 문제 : 서버 확장이 어려움
- 3. 플랫폼 다양화 : web, mobile 요청 처리 어려움
- 4. CSRF의 문제 : 세션 보안 문제
- 5. CORS의 문제 : 도메인 리소스 문제
- 6. REST API : Stateless 지향
- 결론
- stateful 방식은 기능 구현상 편하지만 상태를 계속해서 가지고 있기 때문에 캐시의 활용도가 떨어지고
매 요청마다 같은 데이터를 데이터베이스에 전송하는 것처럼 서버에 부담을 줄 수 있습니다.
- stateless 방식은 매 요청 시마다 상태 정보를 저장해야 하기 때문에 네트워크 리소스를 서버 쪽에서 소모해야 하고 상태 값 저장 기능을 위한 사전 작업이 필요하지만 caching, load balancing, scale-out에 용이합니다.
- MMOPRG와 같이 대규모 사용자가 실시간으로 전투할 때 고성능의 처리능력과 안정성이 보장되어야 하므로
Stateful Server가 적합합니다.
- 실시간 연동이 상대적으로 덜 필요한 웹 서버는 네트워크 비용을 줄이기 위한 Stateless Server가 적합합니다.
서비스하는 형태의 특성을 고려하여 stateful or stateless 방식을 채택해야 합니다.