[의사결정] 좋아요 데이터 영속성을 어떻게 보장할 것 인가?

[wlgns12370]

좋아요 데이터 영속성 문제

---

문제 정의

현재 좋아요 카운트는 Redis ZSet(like:ranking)에만 저장됩니다.
Redis는 인메모리 저장소이기 때문에 아래 상황에서 데이터가 소멸합니다.

• Redis 프로세스 재시작
• Redis 서버 장애
• OOM으로 인한 데이터 eviction

현재 서버 기동 시 BoothLikeWarmupRunner가 모든 부스를 score 0으로 초기화하고 있으나, 이는 기존 좋아요 수를 복구하지 못합니다. Redis가 재시작되면 모든 좋아요 수가 0으로 리셋됩니다.

---

영향 범위

• GET /api/v1/booths/{booth-id} — likeCount 0으로 표시
• GET /api/v1/booths/ranking — 모든 부스 동점(0) 처리

---

해결 방향

DB 동기화 스케줄러 도입

Redis의 좋아요 카운트를 주기적으로 DB에 flush하여 영속성 확보.
서버 기동 시 Warmup을 DB 기반으로 변경하여 Redis 재시작 후에도 복구 가능하도록 구성.

[현재]
like 요청 → Redis ZINCRBY → (끝)

[목표]
like 요청 → Redis ZINCRBY → (주기적) → DB flush
서버 기동  → DB 조회 → Redis 초기화 (score 복구)

구현 계획

순서	작업	비고
1	DB에 like_count 컬럼 추가 (booth 테이블)	Flyway 마이그레이션
2	@Scheduled 스케줄러 구현	Redis → DB 주기적 동기화
3	BoothLikeWarmupRunner 수정	DB 값으로 Redis 초기화

---

논의 필요 사항

• 동기화 주기: 얼마나 자주 flush할지 (1분, 5분, 10분?)
• 장애 허용 범위: Redis 장애 시 최대 몇 분치 데이터 손실까지 허용할지

[jhssong]

동기화 주기는 최대 5분을 넘지 않아야 된다고 생각합니다. 좋아요가 정산 시스템만큼 strict할 필요는 없지만, 랭킹에 민감한만큼 5분이 넘어가면 유실 시 사용자가 체감하는 역체감이 커질 것 같습니다.

트래픽이 몰리는 피크 시간대에는 데이터 유실의 영향이 더 크므로 1분 주기로 설정하고 평시에는 주기를 5분까지 늘려 리소스를 효율화하는 전략이 적절해 보입니다.