# Redis Hot Key 문제: 한 놈에게만 몰리는 트래픽을 분산시키는 법
Table of Contents
“Redis 노드를 10대나 늘렸는데 왜 느리죠?”
분산 시스템을 운영하다 보면 흔히 겪는 미스터리입니다. Redis 클러스터에 노드를 추가하면 전체 처리량(Throughput)은 늘어나야 정상입니다. 하지만 특정 상황에서는 노드를 아무리 늘려도 성능이 제자리걸음일 때가 있습니다.
범인은 바로 **Hot Key(핫키)**입니다. Redis 클러스터는 데이터를 여러 노드에 쪼개서 저장(Sharding)합니다. 하지만 **“특정 키 하나”**에만 초당 수만 건의 요청이 몰린다면 어떨까요? 그 키를 담당하는 단 하나의 노드만 죽어라 일하고, 나머지 노드들은 놀게 됩니다.
이 “단 하나의 노드”가 병목이 되어 전체 서비스의 응답 속도를 깎아먹습니다. 이것이 바로 Hot Key 문제입니다.
Hot Key가 발생하는 시나리오
- 유명 셀럽의 게시글: 팔로워 100만 명인 유저가 글을 쓰면, 그 글을 조회하려는 요청(
post:12345)이 폭주합니다. - 실시간 랭킹: 게임이나 커머스에서
daily_ranking이라는 하나의 키를 모든 유저가 조회합니다. - 선착순 이벤트: “아이폰 100원 딜”이 열리면
product:iphone:stock키에 엄청난 트래픽이 집중됩니다.
Hot Key 탐지 방법
범인을 잡으려면 증거가 필요합니다.
1. redis-cli --hotkeys
Redis 4.0부터 지원하는 기능입니다. LFU(Least Frequently Used) 정책이 켜져 있어야 정확한 결과를 얻을 수 있습니다.
redis-cli --hotkeys이 명령어는 전체 키를 스캔하면서 자주 액세스 된 키를 리포트해줍니다. (주의: 운영 중인 서버에 부하를 줄 수 있으니 조심해서 사용해야 합니다)
2. MONITOR 명령어 (위험!)
실시간으로 들어오는 모든 명령어를 볼 수 있지만, 성능을 심각하게 저하시키므로 프로덕션에서는 절대 금물입니다. 아주 짧게 1초만 찍어보고 끄는 식이라면 모를까, 권장하지 않습니다.
3. 클라이언트 측 로깅
가장 안전한 방법입니다. Redis 클라이언트(Java, Go, Node.js 등)에서 “어떤 키를 조회했는지” 카운팅해서 별도의 모니터링 시스템(Prometheus, Datadog)으로 보냅니다.
해결 전략: Hot Key를 식히는 법
1. 로컬 캐시 (Local Cache) 활용
가장 강력한 해결책입니다. Redis로 가기 전에 **애플리케이션 메모리(Ehcache, Caffeine, Node-cache)**에 데이터를 한 번 더 캐싱하는 겁니다.
- 장점: 네트워크를 타지 않으므로 엄청나게 빠릅니다. Redis 부하가 0이 됩니다.
- 단점: 서버 간 데이터 불일치(Consistency) 문제가 생길 수 있습니다. 서버 A는 ‘품절’을 보여주는데, 서버 B는 ‘재고 있음’을 보여줄 수 있죠.
- Tip: TTL(만료 시간)을 아주 짧게(예: 1~3초) 잡으세요. 3초 정도의 불일치는 대부분의 서비스에서 허용 가능합니다.
2. 읽기 분산 (Read Replicas)
Redis Cluster는 기본적으로 Master 노드에서만 읽기/쓰기를 수행합니다. 하지만 READONLY 모드를 켜면 Replica 노드에서도 읽기가 가능합니다. Hot Key 조회 요청을 여러 Replica로 분산시키면 부하를 줄일 수 있습니다.
3. 키 쪼개기 (Key Sharding)
쓰기(Write) 요청까지 많다면 로컬 캐시로는 부족합니다. 키 자체를 여러 개로 쪼개야 합니다.
예를 들어 product:12345 키에 요청이 몰린다면, product:12345:1, product:12345:2,… product:12345:N 처럼 N개의 복제본을 만듭니다.
- 데이터 쓸 때: N개의 키에 모두 업데이트합니다.
- 데이터 읽을 때:
random(1, N)을 골라서 하나만 조회합니다.
이렇게 하면 트래픽이 N개의 키로 분산되므로, 여러 노드에 골고루 부하를 나눌 수 있습니다.
마치며
Hot Key 문제는 “스케일 아웃(Scale-out)하면 해결되겠지”라는 순진한 기대를 배신하는 골치 아픈 녀석입니다. 결국 분산 시스템의 딜레마인 “정합성(Consistency) vs 성능(Performance)” 사이에서 타협점을 찾아야 합니다.
실시간성이 조금 떨어져도 된다면 로컬 캐시를, 데이터가 무조건 정확해야 한다면 키 쪼개기나 샤딩 전략을 고민해보세요. 여러분의 Redis가 비명을 지르기 전에 미리 소화기를 준비해두는 것이 현명합니다.
