문제 18 — 게임 서버 배포 전략: Blue-Green·Canary·Rolling과 상태 유지 서버의 제약

일반적인 무상태(stateless) 웹 API 서버는 Blue-Green, Canary, Rolling 같은 배포 전략으로 무중단 배포를 비교적 쉽게 달성한다. 그러나 실시간 게임 서버는 월드 상태·플레이어 세션·인메모리 상태를 오래 유지하는 stateful 서버라는 점에서 같은 전략을 그대로 적용하기 어렵다. 다음에 답하라.

1. Blue-Green, Canary, Rolling Update 각각의 핵심 개념과 차이를 설명하라. 무엇을 기준으로 트래픽을 전환하며, 롤백은 각각 어떻게 이뤄지는가?

2. 위 세 전략은 공통적으로 "기존 인스턴스와 새 인스턴스가 동시에 트래픽을 받는 기간"을 전제로 한다. 무상태 HTTP 서버에서는 이것이 자연스러운 이유를 설명하라(요청 단위로 어느 인스턴스가 처리해도 결과가 동일하다는 성질과 연결하여).

3. 상태를 유지하는 실시간 게임 서버(예: 하나의 프로세스가 특정 월드/룸의 세션·인메모리 상태를 계속 들고 있는 구조)에서 위 배포 전략을 그대로 적용하면 생기는 문제를 설명하라. 특히:

   • 이미 접속한 클라이언트를 새 버전 인스턴스로 어떻게 옮길 것인가(연결 드레이닝과 인스턴스 이관의 어려움)?
   • 게임 도중 프로세스를 재시작하면 인메모리 월드 상태가 사라지는 문제를 어떻게 다룰 것인가(무중단 재시작이 어려운 이유)?
   • 배포 전략이 클라이언트-서버 프로토콜/데이터 버전 호환성과 왜 강하게 묶이는가(신·구 버전이 동시에 떠 있는 기간 동안 프로토콜이 호환돼야 하는 문제)?

4. 위 제약들을 고려했을 때, 실시간 게임 서버가 실무에서 흔히 택하는 절충안을 두 가지 이상 제시하라(예: 룸/매치 단위 드레이닝 후 교체, 신규 접속만 새 버전으로 유도, 정기 점검 시간을 이용한 전체 교체, 상태 외부화 등). 각 방식의 장단점을 간단히 설명하라.