안정적인 게임 서버를 위한 출시 전 점검표

평균이 아니라 피크와 실패를 시험합니다

평균 동시 접속만으로는 출석 보상, 이벤트 시작, 대규모 푸시 직후의 요청 집중을 설명할 수 없습니다. 실제 이벤트 패턴을 재현해 CPU, 큐 대기, 데이터베이스 잠금과 타임아웃을 함께 관찰합니다.

특히 정각에 시작하는 이벤트는 위험합니다. 모든 사용자가 같은 초에 같은 요청을 보내기 때문에 평소의 몇 배가 아니라 몇십 배의 순간 부하가 발생합니다. 시작 시각을 사용자별로 분산하거나 진입을 단계적으로 여는 방법을 설계 단계에서 검토해야 합니다.

• 정각 이벤트와 출석 보상의 순간 집중 재현
• 로그인 폭주 시의 인증 경로 부하
• 부하 시험에서 함께 관찰할 지표 목록

의존 서비스의 재연결을 검증합니다

데이터베이스, Redis, 메시지 큐가 몇 초 끊겼다가 돌아올 때 연결 풀과 재시도가 정상 복구되는지 확인합니다. 무한 재시도는 장애를 키울 수 있으므로 백오프, 서킷 브레이커, 쓰기 중단 기준을 둡니다.

복구 직후가 오히려 더 위험한 경우가 많습니다. 끊긴 동안 쌓인 요청이 한꺼번에 몰리면서 이제 막 돌아온 데이터베이스를 다시 무너뜨립니다. 재연결 시 유입을 서서히 늘리는 장치가 필요합니다.

• 연결 풀 고갈
• 중복 소비와 순서 역전
• 부분 실패 시 보상 트랜잭션
• 복구 직후의 요청 폭주 완화

데이터베이스는 대개 가장 먼저 무너집니다

서버를 늘려도 데이터베이스가 하나면 병목은 그대로입니다. 느린 쿼리 하나가 연결을 점유하면 전체 요청이 대기하고, 그 대기가 타임아웃으로 바뀌면서 재시도가 몰려 상황이 악화됩니다. 출시 전에 느린 쿼리 로그를 켜고 인덱스가 실제로 쓰이는지 실행 계획으로 확인해야 합니다.

쓰기가 집중되는 테이블은 별도로 설계합니다. 랭킹, 로그, 재화 변동처럼 갱신이 잦은 데이터는 트랜잭션 범위를 최소화하고, 필요하면 큐를 통해 비동기로 처리하는 편이 안전합니다.

• 느린 쿼리 로그와 실행 계획 확인
• 트랜잭션 범위와 잠금 시간 최소화
• 쓰기 집중 테이블의 분리 또는 비동기 처리

로그·지표·알림을 하나의 사건으로 묶습니다

요청 ID, 사용자·서버 샤드, 배포 버전을 공통 필드로 남기면 고객 문의에서 서버 지표까지 같은 사건을 추적할 수 있습니다. 알림에는 임계값뿐 아니라 담당자와 첫 대응 문서를 연결합니다.

알림이 너무 많으면 없는 것과 같습니다. 실제로 사람이 행동해야 하는 것만 알림으로 보내고, 나머지는 대시보드에 남기는 기준을 세워야 합니다. 대응하지 않아도 되는 알림이 반복되면 진짜 장애 알림도 함께 무시됩니다.

• 요청 ID·배포 버전의 공통 필드화
• 행동이 필요한 알림과 참고용 지표의 분리
• 알림마다 담당자와 1차 대응 문서 연결

복구 절차는 장애 전에 연습해 둡니다

백업이 있다는 사실과 복구할 수 있다는 사실은 다릅니다. 실제로 복원해 본 적이 없으면 장애 상황에서 처음 시도하게 되고, 그때 백업이 손상되었거나 복원에 예상보다 긴 시간이 걸린다는 것을 알게 됩니다. 주기적으로 복원을 실제로 수행해 소요 시간을 측정해야 합니다.

롤백 경로도 마찬가지입니다. 새 버전에 문제가 있을 때 이전 버전으로 돌아가는 절차가 문서로 있고, 데이터 스키마가 그 롤백을 허용하는지 확인되어 있어야 합니다.

• 정기 복원 훈련과 소요 시간 측정
• 스키마 변경이 롤백을 막지 않는지 확인
• 장애 시 판단 권한과 연락 체계

자주 묻는 질문