상태유지(Stateful) vs 무상태(Stateless)

● 상태유지(Stateful)

• 웹서버가 사용자(브라우저)의 상태 client(쿠키)와 server(세션)의 정보를 기억하고 있다가 유용한 정보로 활용한다는 의미이다.
• 클라이언트에서 다른 클라이언트로, 또는 서버에서 특정 클라이언트로 메시지를 전송할 수 있다.
• 서버에서 클라이언트 세션을 유지할 필요가 없을 때 서버 리소스를 절약할수 있는 장점이 있다.
• Stateful방식은 하나의 서버가 1만명의 클라이언트를 처리할 능력이 있을 경우 그보다 많은 수의 클라이언트가 몰리면 이미 연결된 1만명의 클라이언트 중 일부가 빠진 만큼 다음 클라이언트가 처리된다.
• 하지만 Stateless 방식은 순간 접속 요청 인원을 기준으로 처리함으로 클라이언트가 몰려도 할당된 처리량이 끝나면 다음 처리가 가능하다.

● 무상태(Stateless)

• 웹서버 통신(http) 특성상 사용자(브라우저)의 이전 상태 client(쿠키)와 server(세션) 정보를 기록하지 않는 접속이란 의미이다.
• 클라이언트가 데이터를 전송할 때마다 연결하고 바로 끊어버리는 방식이다.
• Stateless 서비스는 가용성을 제공하기 위해서 여분의 인스턴스를 추가하고 로드벨런스를 사용한다.

쿠키 세션 유무에 따른 웹서버 통신 방식

● Stateful 서비스

• 기능상 Stateful 방식이 강력하고 편리하다.
• Stateless의 모든 기능은 Stateful 방식으로 구현 가능하지만 그 반대는 아니다.
• Stateless의 단점은 매 요청 시마다 상태 정보를 전달해야 하기 때문에 그만큼 네트워크 리소스를 소비한다.
• 또한, 서버 쪽에서는 메시지 처리하기 위한 사전 작업이 필요하다. 예를 들면 http 통신방식에 client의 요청은 서로 완전 독립적이고 이전 요청에 의존적이지 않는다.
• 따라서 각각 요청은 server가 처리할 수 있도록 하기 위한 모든 정보를 제공해야 한다.
• 그러나 Stateful 서비스에 있어서 가용성을 제공하기 위해서는 여분의 인스턴스와 '로드 벨런스'로 충분하지 않는다. 즉 Stateful 한 서버의 상태 정보를 구현하기 복잡하다.

● Stateful 통신 구조의 한계

• Session의 한계 : 서버에 무리가 간다.
• Scale out의 문제 : 서버 확장이 어려움
• 플랫폼 다양화 : web, mobile 요청 처리 어려움
• CSRF의 문제 : 세션 보안 문제
• CORS의 문제 : 도메인 리소스 문제
• REST API : Staless 지향

● 요악

• Stateful 방식은 기능 구현상 편하지만 상태를 계속 가지고 있기 때문에 캐시의 활용도가 떨어지고 매 요청마다 같은 데이터를 데이터베이스에 전송하는 것처럼 서버에 부담을 줄 수 있다.
• Stateless 방식은 매 요청 시마다 상태 정보를 저장해야 하기 때문에 네트워크 리소스를 서버 쪽에서 소모해야 하고 상태 값 저장 기능을 위한 사전작업이 필요하지만 caching, load balancing, scale-out에 용이하다.
• MMORPG와 같이 대규모 사용자가 실시간으로 전투할 때 고성능의 처리능력과 안정성이 보장되어야 하므로 Stateful Server가 적합하다.
• 실시간 연동이 상대적으로 덜 필요한 웹 서버는 네트워크 비용을 줄이기 위한 Stateless Server가 적합하다. 서비스 형태의 특성을 고려하여 택하면 된다.

https://junshock5.tistory.com/83

Stateful, Stateless (웹서버 통신 방식)