백엔드
캐시를 적용하기 까지의 험난한 길 (TPS 1만 안정적으로 서비스하기)
두줄요약
약관 서버의 DB 부하를 줄이기 위해 Redis 캐시와 강한 일관성 전략을 적용했습니다. 캐시 무효화 실패와 이벤트 순서 문제는 트랜잭션 동기화와 정책으로 해결했습니다.
문제 상황
- 약관 서버의 TPS가 평균 1만, 최대 2만까지 증가하며 DB 조회 부하가 심각해진 상황
- Strong Consistency가 필요한 약관 동의 여부 특성상 단순 복제 DB 분산은 선택 불가
원인 분석
- 조회 중심 트래픽에서 DB 의존도가 높아 캐시 부재 시 부하 집중
- 캐시 무효화와 외부 이벤트 처리 순서가 어긋나면 이전 버전 응답 가능성 존재
- Commit 전후의 짧은 시간 차이로 잘못된 캐시 재적재와 조회 불일치 발생 가능성
해결 방법
- Redis 캐시와 Look-aside 전략 적용으로 조회 부하 분산
@EntityListener와@TransactionalEventListener(AFTER_COMMIT)로 커밋 이후 캐시 Evict 수행- 캐시 Evict 실패 시 Circuit Breaker를 Force Open하여 DB 기준 응답으로 방어
- Kafka 이벤트는 캐시 Evict 이후 발행되도록 트랜잭션 동기화와 순서 제어 적용
주의할 점
- 캐시 적용보다 Strong Consistency 보장이 우선
- 캐시 무효화 실패 시 자동 복구보다 오탐 응답 방지가 더 중요
- 커밋 완료 전후의 극히 짧은 구간도 정책으로 정의해 해석 기준을 명확히 설정
적용해볼 점
- 조회 위주 서비스의 캐시 전략은 데이터 변경 빈도와 일관성 요구사항부터 검토
- 기술적 예외 구간은 코드뿐 아니라 운영 정책으로 단순화 가능
- 캐시 도입 후 모니터링과 장애 시나리오 점검을 상시 수행