클라이언트 서버 구조 및 Stateful&Stateless

클라이언트-서버 구조

Request(요청,클라이언트), Response(응답,서버) 구조를 말함.

 -> 대부분의 비즈니스 로직은 서버에서 담당(보안적 우수). 이후 완료된 결과를 클라에게 Response하는 방식의 구조

 -> 역할을 분리할 수 있다는 장점이 있음.

 

Stateless

Stateless서버는 서버가 클라이언트의 상태를 보존하지 않는 것.

서버의 확장성(스케일 아웃)이 높지만(비교적 간단하다는 의미), 클라이언트의 추가 데이터 전송이 필요.

 -> 클라이언트의 이전 행동을 모르니 매번 클라이언트측에서 추가행동을 이전의 행동을포함해 보내야함.

 

Stateless서버는 클라이언트의 요청을 매번 DB에서 값을 읽어온 후 처리한 뒤, DB에 기록하고 서버 메모리에는 들고있지 않음.

 -> 물론 아예 무상태를 유지하는게 아닌 최소한의 상태 유지는 사용한다고 함(로그인등)

 

즉 Stateless(웹서버)는 클라이언트의 상태를 유지하지 않기때문에 Scale-out이 간단하다는 장점이 존재함.

다만 Stateful서버에 비해 매번 DB에 접근해야한다는 점에서 상대적으로 속도가 느림(처리속도 및 응답성.)

Stateful

Stateful서버는 서버가 클라이언트의상태를 보존한다는 것.

 -> 게임서버는 대부분 Stateful서버.(MMORPG,FPS등등) 

 -> 많은 유저들이 서버에 접속해 실시간 상호작용을 서버에서 빠르게 처리 후 많은 클라이언트들에게 뿌려줘야함.

 -> 클라이언트의 정보를 서버 메모리에 들고있으므로 클라이언트측에서는 이전행동에 대한 추가 데이터는 필요하지않음.

 

즉 위와 같은 이유로 Stateful서버는 빠른 처리를 위해 매번 DB에서 값을 읽어오는 방식이 아닌, 서버에서 메모리를 들고 있는 방식이기에 (물론 최종 처리 후 값은 DB에 기록은 해야함) Stateless서버에 비해 속도가 빠름.(처리속도,응답성)

다만 Stateless서버에 비해 상대적으로 Scale-out이 힘든 구조.

 -> 서버에서 메모리를 들고있기때문에, 다른 B,C서버에 해당 클라이언트의 정보를 들고있다면 정합성이 무너질 수 있음.

 -> 물론 서버에서 데이터가 최신화가 되어 다른 서버에게도 통지를 해주는등 여러 방법이 있겠지만, 구조적 어려움이나 개발 난이도 상승 그리고 속도저하등의 문제가 있지 않을까 싶다. (최근에는 레디스라는 인메모리 DB를 통해 속도 저하의 문제는 어느정도 해결되지 않았나 싶다)

 

 

 

게임 서버의 2가지 기술 [1 / 4], 실시간 게임서버 (Stateful) 와 비동기 게임서버 (Stateless) – 프로카데미, 게임서버 개발 이야기 (procademy.co.kr)

김영한님의 HTTP강의