캐시 3대 문제

최근에 레디스에 대해 정리하고 , 사이드 프로젝트에서 캐싱 관련 작업을 하던 도중 인사이트를 얻기 위해서 자료를 찾아보고 있었습니다. 자료를 찾아보니 흔히 캐시 3대 문제라고 하는 문제가 있습니다.

그 종류는

• Cache Penetration
• Cache Avalanche
• Hot Key Problem

해당 내용을 정리해보고 싶어 글을 쓰게 되었습니다

---

1. Cache Penetration (캐시 관통)

 

Cache Penetration은 캐시를 아예 뚫고 지나가는 문제입니다.

원래 캐시는 이렇게 동작해야 합니다.

요청이 들어오면 먼저 캐시에서 찾고 → 있으면 캐시에서 바로 반환하고
                                 → 없으면 DB에서 가져온 다음 캐시에 저장

 

근데 여기서 문제가 생깁니다. 만약 DB에도 없는 데이터를 요청하면 어떻게 될까?

 

DB에서 데이터를 조회 할 때 null이 돌아오는데, 이 반환값 null은 캐시에 저장할 게 없다고 생각해서 그냥 버립니다.

 

그러면 다음에 똑같은 요청이 오면?

캐시에 없으니까 또 DB 조회합니다. 또 null, 또 버리고, 또 조회... 이게 반복됩니다.

공격자가 이 허점을 이용해서 id=-99999 같이 절대 존재할 수 없는 키로 수천만 번 요청을 보내면, 모든 요청이 DB로 직행해서 DB가 터져버립니다.

 

해결책 3가지

1. Null value 캐싱:
   DB에서 없다고 나와도 "이 키는 없음"이라는  null 정보를 캐시에 짧은 시간(예: 5분) 동안 저장합니다.
   그러면 이후에 같은 요청이 와도 캐시에서 "없음"을  돌려주고 DB는 건드리지 않습니다.
2. Bloom Filter:
   DB 조회 전에 "이 키가 DB에 존재할 가능성이 있는가?"를 아주 빠르게 판단하는 자료구조입니다.확실히 없는 키라면 DB 조회 자체를 막아버립니다.
3. 입력값 검증:
   애초에 요청 자체에서 비정상적인 키(음수 ID, 너무 긴 문자열 등)를 필터링해서 서버에 도달하지 못하게 막습니다.

---

2. Cache Avalanche (캐시 눈사태)

 

Cache Avalanche는 이름 그대로 눈사태처럼 한꺼번에 무너지는 문제입니다.

한번 상상을 해보면 ...

서버를 처음 켤 때 모든 캐시 키를 한꺼번에 올렸습니다. 상품 목록, 배너, 인기 글, 사용자 정보... 전부 TTL을 3600초(1시간)로 설정했습니다. 

이렇게 되면 정확히 1시간 뒤에 수천 개의 캐시 키가 동시에 만료됩니다. 이 순간 사용자 요청은 그대로 들어오는데, 캐시에는 아무것도 없으니 전부 DB로 향합니다. DB는 갑자기 수천 배의 쿼리를 받고 터져버리고, 사이트 전체가 다운됩니다.

 

해결책 4가지

• TTL에 랜덤값 추가: 3600초가 아니라 3600 + random(0~600) 같이 만료 시간을 분산합니다. 동시에 만료되는 키 수를 줄여서 DB 부하가 점진적으로 발생하게 만듭니다.
• Cache warming (사전 갱신): 캐시가 만료되기 전에 백그라운드에서 미리 데이터를 갱신합니다. 사용자가 캐시 미스를 경험하지 않도록 합니다.
• 서킷 브레이커: DB가 과부하 상태일 때 추가 요청을 일시적으로 차단하거나 기본값을 반환해서 DB가 회복할 시간을 줍니다.
• Redis 고가용성 구성: Redis Sentinel이나 Cluster를 사용해서 캐시 서버가 죽어도 자동으로 다른 서버로 전환되게 합니다.

---

3. Hot Key Problem (핫 키 문제)

Hot Key Problem은 특정 데이터 하나에 트래픽이 미친 듯이 몰리는 문제입니다.

쇼핑몰에서 아이폰 신상품이 출시되거나, 유명인이 특정 게시물을 공유하거나, 스포츠 경기 중계가 시작될 때를 생각해 보면,

갑자기 수십만 명이 동시에 같은 데이터를 요청합니다.

Redis는 클러스터 구성 시 여러 노드에 데이터를 분산하는데, product:iphone 키는 해시 알고리즘에 따라 딱 하나의 노드(예: Node A)에 저장됩니다. 수십만 요청이 전부 Node A로 집중되니 Node A는 CPU 100%가 되어 응답을 못 하거나 죽어버리고, Node B, C는 멀쩡히 놀고 있는 불균형이 생깁니다.

 

해결책 4가지

• 로컬 캐시 (L1 캐시): 각 애플리케이션 서버의 메모리에 핫 키 데이터를 잠깐 저장합니다. 같은 서버에 오는 요청은 Redis에 가지 않아도 되니 Redis 부하가 확 줄어요. 단, 데이터 일관성 관리가 필요합니다.
• 키 복제 분산: product:iphone:shard_1, product:iphone:shard_2, product:iphone:shard_3처럼 같은 데이터를 여러 키로 복제해서 다른 노드에 분산 저장합니다. 요청 시 랜덤으로 하나를 선택해 조회하면 트래픽이 여러 노드로 나뉩니다.
• Read Replica 추가: Redis 마스터 노드에 읽기 전용 복제본을 여러 개 만들어서 읽기 요청을 분산합니다. 특히 읽기 비중이 압도적으로 높은 경우에 효과적입니다.
• 핫 키 실시간 감지 + 자동 대응: 초당 접근 횟수를 모니터링해서 임계치를 넘는 키가 감지되면 자동으로 로컬 캐시나 복제 전략으로 전환합니다.

---

세 가지 문제 한눈에 비교

 

 

세 문제를 구분하는 가장 쉬운 방법은 "무엇이 DB를 때리는가?"로 기억하면 됩니다.

• Cache Penetration: 없는 데이터를 찾는 요청들이 DB를 때린다
• Cache Avalanche: 캐시가 한꺼번에 비워지면서 모든 정상 요청이 DB를 때린다
• Hot Key: 하나의 캐시 키가 너무 인기 있어서 그 키를 담당하는 노드가 터진다

실무에서는 이 세 가지가 겹쳐서 발생하기도 하니, 시스템 설계 단계부터 TTL 전략, Bloom Filter 적용 여부, 로컬 캐시 레이어 구성을 함께 고려하는 게 중요합니다.