배경

• 콘서트 티켓팅에 입장하면 좌석 정보 뿐만 아니라, 콘서트와 관련된 부가적인 정보도 함께 노출이 된다.
• 만약 수만명이 해당 정보에 대해 조회를 요청하여 바로 DB로 향하는 경우 서버가 죽을 위험이 있다.
• 콘서트에 대한 정보는 갱신이 자주 이루어지지 않고 여러 사용자가 조회하기에 캐싱의 대상으로 적절하다.

캐시 대상

• 콘서트 조회 시 잘 변경되지 않는 조회 데이터 파악
  • 콘서트 정보 (GET /api/v1/concerts/{concertId})
  • 콘서트 회차 정보 (GET /api/v1/concerts/{concertId}/concertSchedules/{concertScheduleId})

캐싱 위치 비교

• 글로벌
  • Redis는 이미 대기열 기능으로 사용 중이며, 역인덱스를 걸어 여러 조회 API에서 레디스를 활발히 사용중이다.
  • 하지만, 콘서트 상세 조회처럼 트래픽이 몰리는 캐시를 글로벌 단독으로 처리하기에는 이미 대기열/역인덱스로 부하가 심한 Redis에 조회 트래픽까지 끼얹는 셈이라 병목이 더 커질 것으로 우려된다.
• 로컬
  • 반대로 로컬 캐시 단독으로 처리하면, 스케일 아웃된 환경에서 각 인스턴스 간 정합성이 불일치하는 경우가 발생한다.
• 로컬 + 글로벌
  • 로컬을 L1으로, 로컬 미스인 경우 글로벌을 조회하도록 하는 구성이다.
  • 즉, 로컬(L1)에서 대부분의 트래픽을 흡수하는 1차 방어선을 두고, 캐시 정보의 원천은 글로벌(L2)에 두어 2차 방어 역할을 하도록 하는 것이다.

스템피드 방어 및 고려사항

대응