피드로 돌아가기
Dev.toBackend
원문 읽기
Bloom Filter 제거 및 Redis Hash 전환으로 비용 86% 절감 및 p99 220ms 달성
A Week in the Life of a Treasure Hunt Engine that Almost Went Off the Rails
AI 요약
Context
Black-Friday 기간 1.2M 유저 유입 및 100k Concurrent Players 대응을 위한 Treasure Hunt 엔진 설계 상황. 초기 RedisBloom 도입 시 Session Churn(분당 2.1회)으로 인한 잦은 재생성과 False Positive 급증(1%→12%)이 Aurora DB 부하 가중 및 예산 초과(37% 상승)를 유발한 구조.
Technical Solution
- RedisBloom 모듈을 제거하고 단순 Redis Hash 기반의 session:{uid}:{event_id} 구조로 전환하여 O(1) 조회 성능 확보
- 30초 Sliding TTL 설정을 통한 Memory Bounded 상태 유지 및 Memory Usage 48GiB 제한으로 OOM 방지
- Redis Session Store의 Persistence 비활성화를 통한 쓰기 오버헤드 제거 및 DynamoDB 기반 Idempotent 보상 체계로 데이터 정합성 보완
- Aurora PostgreSQL의 직접 조회를 줄이기 위해 Treasure List를 Append-only DynamoDB로 이전하여 Hot Path 읽기 최적화
- EventBridge Pipe를 활용해 30초 주기로 Aurora 단일 Row를 업데이트하는 비동기 갱신 구조 설계
- Redis Write(1ms)와 Aurora Conditional Write(30ms)를 조합한 최적화된 Write Path 구축
실천 포인트
- High-churn 세션 모델링 시 Poisson Process($\lambda$) 기반의 세션 교체율 시뮬레이션 수행 여부 검토 - 확률적 자료구조(Bloom Filter 등) 도입 시, 데이터 갱신 주기와 False Positive 증가가 하위 저장소(DB)에 미치는 영향 분석 - 서비스 특성에 따라 데이터 유실이 허용되는 임시 세션 저장소의 Persistence 설정 해제 검토 - Read-heavy Hot Path의 경우, 관계형 DB 대신 NoSQL(DynamoDB 등)의 Primary Key 조회를 통한 부하 분산 설계 적용