Stateless와 Stateful

이전에 NDC2021에서 <쿠키런: 킹덤> 서버 아키텍쳐 뜯어먹기!에서 나온 stateful 서버와 stateless 서버에 대해 얘기해보려 한다.

간단히 쿠키런에 stateful한 서버를 구현하기 위한 방식들에 대해 설명해주셨다.

Stateless 서버

서버가 유저의 상태를 저장하고 있지 않는다.

필요할 경우 매번 DB 혹은 캐시에서 불러와서 요청을 처리한다.

Stateful 서버

서버가 유저의 상태를 저장하고 있는다.

유저의 요청은 서버에 저장된 상태를 바탕으로 처리된다.

Stateless 서버와 Stateful 서버의 구분은 다소 모호한 부분이 있기 때문에 이때에 발표에서는 위와 같은 발표로 두 서버를 정의하고 발표가 진행되었다.

클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하는 것을 의미한다.

간단한 예시를 들어보자.

어떤 RPG 게임 서버와 게임을 이용하는 클라이언트가 있다고 치자.

클라이언트 : 캐릭터 생성 버튼 클릭

서버 : 캐릭터 생성을 시작합니다.

클라이언트 : 캐릭터 눈은 파란색으로, 머리카락은 갈색으로 만들어주세요

서버 : 캐릭터 직업은 어떻게 지정하시겠습니까? (유저의 캐릭터 생성 요청 상태값 유지)

클라이언트 : 궁수로 해주세요.

서버 : 속성은 뭘로 하시겠습니까? (유저의 캐릭터 생성 요청 상태값 유지)

클라이언트 : 물로 할래요.

서버 : 캐릭터 생성이 완료되었습니다. (유저의 캐릭터 생성 요청 모든 상태값 기억 후 전송)

그러나 이러한 요청 과정에서 중간에 트래픽이나, 유저의 환경 문제로 서버가 변경되는 경우 상태 값이 그대로 전달되지 못하는 문제가 발생할 수도 있다. 따라서 이러한 문제를 해결하기 위해 무상태가 나오게 된다.

http에는 무상태(Stateless)라는 특징이 있다.

상태가 없다는 것은, 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않는 것을 의미한다.

장점 : 서버의 확장성이 높기 대문에 대량의 트래픽 발생 시에도 쉽게 대처가 가능

단점 : 클라이언트의 요청에 상대적으로 Stateful 서버보다 더 많은 데이터가 소모

위의 Stateful 상황에서 서버는 아무것도 기억하지 않고,

서버 : 캐릭터 생성이 완료되었습니다.

의 최종 데이터 전달 시점에서 서버는 들어온 요청을 처리하게 된다.

이전의 클라이언트의 요청(상태)을 유지하지 않고 있기 때문에 기존의 서버가 혼잡해져서 다른 서버로 대체되더라도 기존의 비즈니스 로직을 그대로 구현하고 있다면 이전의 사용자 요청에 상관없이 계속해서 일을 처리할 수 있다.

단점으로는 클라이언트가 하고자하는 최종 목적을 위해 지나는 과정마다 전달해야할 내용이 많아진다는 것이다.

참고자료