인기 상품의 캐시가 만료되자 여러 서버가 동시에 같은 데이터를 DB에서 읽습니다. 중복 조회와 사용자 대기를 어떻게 줄이나요?

캐시 스탬피드는 인기 키가 만료되는 순간 여러 요청이 동시에 원본을 읽고 같은 값을 채우면서 부하가 DB로 몰리는 현상입니다. 먼저 같은 키의 채우기를 합치고, 채우기 작업이 실패하거나 오래 걸릴 때 대기 상한을 둡니다. 프로세스 하나의 동일 작업 합치기(singleflight)만으로 여러 인스턴스의 중복을 제거할 수는 없습니다.

채우기 작업을 합치고 회복시킨다

한 프로세스에서 첫 요청 하나만 DB를 읽고 뒤따른 요청이 결과를 기다리게 할 수 있습니다. 성공하면 결과를 공유하고 실패하면 대기자가 영원히 남지 않게 다음 호출자의 재획득과 timeout을 허용합니다. 첫 호출자의 취소를 공유 작업에 그대로 묶으면 그 연결이 끊길 때 다른 요청도 실패하므로 채우기 수명과 응답 수명을 분리할지 정합니다.

인스턴스가 10개면 각 인스턴스의 한 작업씩 최대 10회 조회가 남습니다. 더 줄이려면 공유 lease나 캐시의 원자적 set-if-absent를 검토할 수 있지만 분산 조정 자체가 병목이 됩니다. 소유자가 죽어도 대기자가 영원히 멈추지 않도록 lease 만료·재획득·세대 검사를 함께 둡니다.

신선도와 부하의 절충

상품 설명처럼 오래됨을 허용하면 stale-while-revalidate로 기존 값을 먼저 주고 뒤에서 갱신해 지연을 줄입니다. 권한·재고에는 오래된 값이 잘못된 결정을 만들 수 있어 적용하지 않습니다. TTL 지터는 많은 키가 동시에 만료되는 집단 폭발은 줄이지만 하나의 핫키 문제는 혼자 해결하지 못합니다.

핫키의 읽기를 복제·결과 캐시로 나눌 수는 있지만 잔액처럼 순서와 원자성이 필요한 쓰기를 무작정 쪼개면 안 됩니다. 부모 요청 전체의 원본 동시성 예산, DB 연결 풀, 실패 시 재시도 예산도 별도로 제한합니다. 검증은 동일 키 집중, 채우기 지연·실패·프로세스 종료를 주입해 원본 호출 수와 p99 대기, stale 비율, lease 만료 뒤 중복을 측정합니다. 성공은 적중률이 아니라 DB가 감당 가능한 호출량에서 신선도와 지연 계약을 지키는 것입니다.

공유 작업과 대기자의 수명

한 키에 1,000개 요청이 몰리면 원본 조회를 하나로 합쳐도 기다리는 요청 1,000개의 메모리와 연결은 남습니다. 키별 대기자 수와 전체 대기 상한을 두고, 각 대기자는 자신의 deadline이 끝나면 빠져나오게 해야 합니다. 공유 작업은 독립된 제한 시간으로 끝내고, 대기자가 모두 없어지면 취소할지 캐시를 채우기 위해 계속할지 정합니다. 취소를 지원하지 않는 DB 호출은 응답을 포기해도 실제 완료까지 동시 실행 예산을 점유합니다.

실패 결과를 즉시 공유하고 엔트리를 지운 뒤 다음 요청이 바로 재시도하면 빠른 실패 폭주가 반복될 수 있습니다. 짧은 실패 캐시나 재시도 지연을 둘 수 있지만 일시적인 부재와 권한 거절, 저장소 장애를 같은 결과로 저장하지 않습니다. stale 값을 제공하는 경우에도 허용 최대 나이를 별도로 두어 원본이 계속 실패할 때 무한히 오래된 결과를 주지 않겠습니다.

분산 lease가 만료되면 옛 채우기와 새 채우기가 동시에 진행할 수 있습니다. lease 소유자 토큰을 비교해서 자기 lease만 해제하고, 캐시에 결과를 게시할 때도 세대나 데이터 버전을 검사합니다. lease로 원본 호출을 줄이는 것과 오래된 결과를 거절하는 것은 별도 목적입니다.