피드로 돌아가기
Dev.toDatabase
원문 읽기
Postgres Materialized View 도입으로 Leaderboard p99 800ms에서 16ms로 단축
How the Events Table That Looked Right Killed Our Queue
AI 요약
Context
Postgres NOTIFY 기반의 이벤트 버스 구조에서 초당 400건 이상의 트래픽 발생 시 8KB 버퍼 제한으로 인한 메시지 백로그 및 iowait 40% 초과 문제 발생. 분산 메시지 큐인 Kafka와 Pulsar 도입을 시도했으나, Consumer Group Rebalance로 인한 데이터 누락 및 Disk Quota 관리 실패로 시스템 불안정성 가중.
Technical Solution
- Distributed Bus를 제거하고 Postgres 내부 저장 패턴을 변경한 데이터 중심 설계 회귀
- TimescaleDB의 Continuous Materialized View를 도입하여 1초 단위 Tumble Window 기반의 집계 구조 설계
- Background Worker 대신
REFRESH MATERIALIZED VIEW CONCURRENTLY를 통한 동기적 뷰 갱신으로 데이터 일관성 확보 - Logical Decoding 기반의 스냅샷 재사용을 통해 리더보드 쿼리를 단순 Index-only Scan으로 최적화
- 30일 Retention Policy를 적용한
drop_chunks설정으로 스토리지 비대화 방지 - Idempotency Key(event_id + player_id) 도입을 통해 분산 큐 사용 시 발생했던 Phantom Score 문제 해결
실천 포인트
- 분산 메시지 큐 도입 전 Rebalance 주기와 Disk Quota에 따른 가용성 영향도 평가 - 실시간 집계 필요 시 Materialized View와 Index-only Scan 조합의 성능 검토 - 인프라 변경 전 실제 운영 트래픽을 반영한 24시간 이상 Load Test 수행 - 테이블 락 방지를 위해 Materialized View 갱신 시 반드시 CONCURRENTLY 옵션 검토