한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

게임 렉 백서 › L12 데이터베이스

캐시 스탬피드 Cache stampede / thundering herd

원인 ID db-cache-stampede · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

그림과 실험이 있는 원본 카드로 열기 →

인기 데이터의 캐시가 동시에 만료되면 수천 개 요청이 한꺼번에 DB로 몰립니다.

왜 Redis 등에 저장된 인기 데이터가 동시에 만료 → 그러면 같은 데이터를 다시 만들려는 요청이 DB로 한꺼번에 몰림 → 화면에서는 DB 과부하로 여러 기능이 줄줄이 느려지거나 멈춤

증상
입력 지연, 멈춤, 접속 불가·무한 로딩
요인
정체, 지연
누가 겪나
서버 전체
언제
일정한 주기로, 사람이 몰릴 때
담당
주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일
만료 시각을 무작위로 분산, 한 요청만 갱신하고 나머지는 옛 값 사용.
인프라팀 할 일
Redis 재시작·장애 때 캐시가 통째로 비지 않게 복제본·자동 전환 구성, 캐시가 비어도 버틸 DB 여유 확인.
그래프에서는
일정 주기로 튐 · 캐시 적중률, DB 초당 쿼리 수
확인할 곳
Redis INFO의 keyspace_hits·keyspace_misses(적중률), expired_keys, 재시작 여부(uptime_in_seconds)를 DB 초당 쿼리 수와 겹쳐 보고, 그 순간 DB에서 같은 쿼리가 동시에 몇 개 도는지(MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity) 셈
이러면 맞음
캐시 미스가 한순간 치솟는 시각에 DB 쿼리 수가 함께 솟고 동시에 도는 쿼리 대부분이 같은 데이터를 읽는 같은 쿼리임. 인기 키의 만료 주기나 Redis 재시작 시각과 겹침
이러면 아님
캐시 미스는 평소와 같은데 DB 쿼리만 늘면 로그인 폭주(db-login-storm)나 배치(db-batch)
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
Redis가 재시작되거나 장애로 캐시가 통째로 비어도 같은 일이 생깁니다. 캐시를 믿고 DB를 작게 잡아 둔 구조일수록 위험합니다.

출처

  1. Scaling Memcache at Facebook (NSDI '13) USENIX
    자주 쓰는 키가 무효화되면 많은 읽기가 DB로 몰리는 thundering herd, 리스(한 클라이언트만 갱신)·옛 값 반환으로 막음, 캐시가 빈 클러스터는 따로 예열
  2. Optimal Probabilistic Cache Stampede Prevention VLDB Endowment
    인기 항목이 만료되면 여러 요청이 동시에 재생성하는 캐시 스탬피드, 만료 전에 확률적으로 미리 갱신해 막음
  3. High availability with Redis Sentinel Redis
    주 서버가 죽으면 복제본을 승격하는 자동 전환
  4. INFO Redis
    keyspace_hits·keyspace_misses(키 조회 성공·실패 수), expired_keys(만료된 키 수), uptime_in_seconds(시작 뒤 지난 시간)
  5. SHOW PROCESSLIST Statement MySQL
    세션마다 실행 중인 문장(Info)과 현재 상태에 머문 시간(Time, 초)
  6. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    pg_stat_activity: 세션마다 지금 실행 중인 쿼리(query)

함께 보면 좋은 원인

같은 층: L12 데이터베이스

같은 증상(입력 지연)의 다른 층 원인

그림과 실험이 있는 원본 카드 보기