'MSA 하자고? ' : 인기 보관소 Top5 캐시 설계기

MSA 하자고..??

이번 글에서는 MSA 환경에서 인기 보관소 Top5 데이터를 효율적으로 캐싱하기 위해 어떤 고민을 했고, 어떻게 해결했는지 공유해 보려고 합니다.

1. 문제 상황

진행중인 프로젝트의 홈 화면에는 인기 보관소 Top5를 보여주는 기능이 있습니다.
홈화면에 있는 기능이기 때문에 데이터는 자주 조회되고, 사용자 수가 많아질수록 DB 부하도 커집니다.
처음에는 Caffeine 로컬 캐시를 적용해서 성능을 개선했지만, MSA 환경(여러 서버 인스턴스)에서의 문제를 고려하고자 재설계를 진행하였습니다.

발견한 문제들

• 인스턴스별 데이터 불일치
• 각 서버가 독립적으로 캐시를 가지다 보니 데이터가 서로 달라짐
• 재시작 시 캐시 초기화
• 서버가 재시작되면 캐시가 비어 DB 쿼리가 폭증
• 캐시 무효화 어려움
• 한 인스턴스에서 데이터가 바뀌어도 다른 인스턴스는 예전 데이터를 계속 사용

2. 요구사항

이 문제를 해결하려면 캐시에 다음 조건들이 필요했습니다.

1. 여러 인스턴스가 최신 데이터를 공유할 것
2. 로컬 캐시의 빠른 조회 성능은 유지할 것
3. 데이터는 1시간 주기로 갱신
4. 장애 상황에서도 서비스가 끊기지 않을 것

3. 기존 구조의 한계

기존 구조는 단순했습니다.

이 방식은 단일 인스턴스에서는 빠르지만,
MSA 환경에서는 캐시 일관성이 깨지고, 재시작 시 DB 부하가 급격히 늘어날 수 있다는 문제가 있었습니다.

4. 개선 아이디어: 로컬 캐시 + Redis Pub/Sub

그래서 최종적으로 선택한 구조는 Caffeine + Redis Pub/Sub 하이브리드 캐시입니다.

구조

1. 로컬 캐시(Caffeine): 초고속 조회
2. Redis 캐시: 중앙 저장소, 여러 인스턴스 공유
3. Redis Pub/Sub: 캐시 무효화 메시지 전달
4. 스케줄러: 1시간마다 인기 Top5 계산 후 Redis + 로컬 캐시에 저장

조회 동작 흐름

5. 장애 대응 전략

• Redis 장애 → 로컬 캐시 miss 시 DB 직접 조회
• 인스턴스 재시작 → Redis에서 데이터 가져와 로컬 캐시에 채움
• 캐시 미스 연쇄 방지 → Redis를 1차 채널로 활용해 DB 부하 최소화

6. 이 설계를 선택한 이유

• 성능 + 일관성: 로컬 캐시로 빠른 응답, Redis로 데이터 동기화
• 확장성: 인스턴스 수가 늘어나도 일관성 유지
• 운영 편의성: 스케줄러와 Pub/Sub로 캐시 갱신 자동화
• 안정성: 장애 시에도 데이터 접근 경로가 보장됨

7. 기대 효과

• 인기 보관소 조회 속도 대폭 향상
• DB 부하 감소, 트래픽 급증에도 안정적
• 여러 인스턴스 간 데이터 불일치 문제 해결

마무리

MSA 환경에서 캐시를 설계할 때는 성능, 일관성, 장애 대응을 모두 고려해야 합니다. 이번 경험을 통해 레디스의 활용성 로칼캐시의 한계점 등을 공부할 수 있었습니다.