문제 22 — 게임 로그·텔레메트리 파이프라인 설계

동시 접속 20만, 서버 인스턴스 500대 규모의 실시간 게임을 운영한다. 다음을 모두 처리해야 한다.

• 개발자가 장애를 추적하는 디버그/에러 로그
• 재화 지급·소모, 아이템 생성/삭제를 추적하는 감사(audit) 로그 — 고객 문의(CS)와 어뷰징 조사, 회계 대사에 쓰인다
• 밸런싱·LiveOps 분석을 위한 행동 텔레메트리 — 퀘스트 진행, 전투 결과, 상점 노출/클릭 등 초당 수백만 이벤트

현재는 모든 로그를 게임 서버 프로세스에서 동기적으로 파일에 쓰고 있고, 틱 루프가 로그 I/O 때문에 튀는 현상과 디스크가 차서 서버가 죽는 사고가 반복되고 있다. 파이프라인을 새로 설계하라.

1. 로그 종류별 요구사항 정의: 위 세 종류를 내구성(유실 허용 여부), 지연(실시간성), 보존 기간, 조회 패턴, 정확성 기준으로 비교하라. 특히 "재화 감사 로그는 절대 유실하면 안 된다"와 "전투 텔레메트리는 0.1% 유실을 감수한다"가 각각 어떤 구현 차이로 이어지는지 설명하라.

2. 수집 경로 설계: 게임 서버 프로세스 내 비동기 버퍼 → 로컬 에이전트 → 메시지 브로커(Kafka 등) → 저장소 각 단계의 역할과 실패 모드를 설명하라. 각 단계에서 배치, 압축, 백프레셔(backpressure) 를 어떻게 다룰 것인가? 버퍼가 가득 찼을 때 (a) 드롭 (b) 블로킹 (c) 디스크 스풀 중 무엇을 언제 고르겠는가?

3. 무손실이 필요한 로그의 보장 방법: 재화 감사 로그에 대해 at-least-once / exactly-once / 멱등성을 어떻게 설계하겠는가? 게임 서버가 갑자기 죽어도 유실이 없으려면 어디에 먼저 써야 하는지, 그리고 그것이 게임 로직의 응답 지연에 어떤 영향을 주는지 논하라. 트랜잭션 아웃박스(outbox) 패턴이 여기 어떻게 적용되는가?

4. 스키마와 파티셔닝: 이벤트 스키마를 어떻게 정의·진화시킬 것인가(스키마 레지스트리, 하위/상위 호환 규칙, 필드 추가/삭제/타입 변경)? Kafka 파티셔닝 키로 플레이어 ID를 쓸 때와 시간/랜덤을 쓸 때의 장단점과 핫 파티션 문제를 논하라.

5. 저장 계층과 조회: 핫 데이터(최근 7일, 대시보드·실시간 알림)와 콜드 데이터(1년치, 배치 분석)를 각각 어떤 저장소·포맷으로 둘 것인가? 컬럼 지향 포맷(Parquet)과 OLAP 엔진(ClickHouse 등)이 왜 적합한지, 파티셔닝·압축·보존 정책을 어떻게 설계할지 설명하라. 메트릭 / 로그 / 트레이스의 역할 분담과 카디널리티 폭발 문제도 함께 논하라.

6. 운영 제약: 개인정보(PII)와 보존 정책(GDPR 삭제 요청 등)을 파이프라인에서 어떻게 다룰 것인가? 그리고 로그가 게임 틱 루프 성능을 갉아먹지 않게 하려면 코드 레벨에서 무엇을 지켜야 하는가(할당, 문자열 포맷팅, 락, 샘플링, 로그 레벨 동적 조정)?