이 글의 목차

Redis Hot Key는 큰 값이 아니라 특정 키에 요청이 몰리는 문제입니다. 전체 캐시 적중률이 높고 메모리에 여유가 있어도 한 키를 담당하는 노드가 바빠지면 지연이 늘 수 있습니다. 키 크기, 요청 빈도, 명령 비용과 응답 바이트를 따로 확인해야 합니다.

기본 개념은 Redis Hot Key 문제 설명을 참고하세요. 여기서는 redis-cli --hotkeys 실행 조건과, 측정 후 로컬 캐시·키 분산을 선택하는 기준을 다룹니다.

Hot Key와 Big Key를 구분

구분관측 대상대표 영향
Hot Key높은 접근 빈도한 노드의 명령·네트워크 부하 집중
Big Key큰 값 또는 많은 원소큰 전송, 메모리, 명령 처리 비용
느린 명령명령별 처리 시간다른 요청 대기 증가

세 가지는 겹칠 수 있습니다. 작은 설정 값이 초당 여러 번 읽혀 hot key가 될 수 있고, 거의 읽지 않는 큰 목록은 big key일 수 있습니다. 가장 큰 키를 줄였는데 지연이 그대로라면 접근 빈도와 실제 명령을 확인하세요.

—hotkeys는 LFU 조건이 있습니다

Redis CLI 공식 문서는 --hotkeys가 maxmemory-policy가 LFU인 경우에 동작한다고 설명합니다. 운영 환경에서 확인 가능한 권한과 연결 옵션을 갖춘 뒤 정책부터 읽으세요. Redis CLI hot keys 안내

Terminal window
redis-cli CONFIG GET maxmemory-policy
# 현재 정책이 allkeys-lfu 또는 volatile-lfu 등 LFU일 때
redis-cli --hotkeys -i 0.1

인증·TLS·호스트 옵션은 실제 연결에 맞게 추가해야 합니다. 명령 예시는 기본 로컬 연결을 가정합니다. 스캔은 운영 부하를 발생시킬 수 있으므로 실행 시간과 지연을 함께 관측하세요.

진단 도구를 쓰려고 운영 eviction 정책을 바로 바꾸지는 마세요. LFU로 바꾸면 메모리 한도에 도달했을 때 제거하는 키 선택이 달라집니다. 특히 캐시와 중요한 상태를 섞어 저장한 환경에서는 정책 변경의 영향이 큽니다. 정책 변경 없이 애플리케이션 측 샘플링을 먼저 사용할 수도 있습니다.

LFU 카운터는 정확한 기간별 요청 수가 아닙니다. 샘플링·감쇠가 개입한 지표를 일별 호출 통계처럼 읽으면 안 됩니다. 새로 관측을 시작한 환경의 짧은 결과를 장기간의 최다 요청 키로 확정하기도 어렵습니다.

Cluster면 노드별로 확인하세요

단일 키의 슬롯을 다른 샤드로 옮겨도 그 키의 요청이 여러 샤드로 자동 분할되는 것은 아닙니다. Redis의 관측 안내도 키가 하나의 샤드에 속한다는 점과 키 샘플링 방법을 설명합니다. Redis 관측·Hot Key 안내

Cluster에서 한 노드의 결과만 보고 전체를 결론내리지 마세요. 트래픽을 받는 각 primary의 CPU, 명령량, 네트워크 바이트, 지연을 비교하고 문제 노드의 키를 확인합니다. 관리형 제품은 명령 접근과 지표 제공 방식이 다를 수 있으니 지원되는 관측 기능을 확인하세요.

앱의 Redis 호출 단계에서 짧은 기간 샘플링하면 키별 읽기·쓰기 비중을 구분하기 쉽습니다. 고객 ID·세션 토큰이 포함된 원본 키를 로그에 무제한 기록하지 말고, 키 패턴이나 별도 식별 방식으로 집계하세요. 샘플 확률과 관측 시간도 기록해야 전체 요청량을 추정할 때 혼동이 적습니다.

로컬 캐시가 적합한 조건

로컬 캐시는 Redis를 읽기 전에 각 앱 프로세스의 메모리에서 값을 재사용합니다. 요청이 많은 읽기 값에 효과적일 수 있지만, 변경 후 오래된 값이 남는 문제를 설계해야 합니다.

데이터검토 방향확인할 조건
짧은 지연을 허용하는 공개 설정짧은 TTL 로컬 캐시갱신·누락 시 fallback
사용자별 결과범위를 포함한 캐시 키사용자·테넌트 분리
실시간 권한·차단 상태원본 확인 또는 엄격한 무효화오래된 허용 상태의 위험
큰 응답용량 상한과 제거 정책프로세스별 중복 메모리

Redis의 client-side caching은 무효화 메시지 등 관련 기능을 제공합니다. 직접 만든 TTL 캐시와 같다고 가정하지 말고 클라이언트 지원·연결 복구·무효화 처리를 확인하세요. Redis client-side caching

가상의 20개 앱 프로세스가 각각 10MiB 값을 보관하면 값만으로 약 200MiB가 됩니다. 요청 수가 줄었어도 앱 메모리가 크게 늘 수 있습니다. TTL뿐 아니라 최대 항목 수와 바이트 상한을 두고, 동시 만료 후 재조회가 몰리지 않도록 요청 합치기도 검토하세요.

키 복제와 읽기 레플리카의 한계

읽기 전용에 가까운 값을 config:0~config:7처럼 복제해 분산하면 여러 키로 읽기 부하를 나눌 수 있습니다. 하지만 모든 복제본을 어떻게 갱신할지, 한 복제본만 오래된 경우를 어떻게 발견할지 설계해야 합니다. Redis Cluster의 hash tag가 모든 키를 같은 슬롯에 묶는지도 확인하세요.

레플리카 읽기도 선택지가 될 수 있으나 복제 지연과 읽기 일관성 요구를 검토해야 합니다. 쓰기 직후 반드시 최신 값을 읽어야 하는 경로에 무작정 적용하면 결과가 달라질 수 있습니다. 쓰기가 집중된 카운터와 읽기가 집중된 정적 값은 해결 전략도 다릅니다.

적용 전후 측정할 지표

키별 호출 감소만 보고 성공을 선언하지 마세요. 변경 전후 같은 요청 조건에서 다음을 비교합니다.

  • 문제 노드의 CPU·명령량·응답 바이트.
  • 앱의 p95·p99 지연과 오류율.
  • 로컬 캐시 적중률·메모리·무효화 지연.
  • 오래된 값이 실제 응답에 사용되는 시간.
  • 캐시 장애·재시작 직후 원본 조회량.

로컬 캐시를 비웠을 때 갑자기 Redis나 DB가 과부하되는지도 시험해야 합니다. 정상 상태의 평균 지연만 개선한 변경은 장애 시 동작을 설명하지 못합니다. 동시 재조회는 Thundering Herd와 singleflight에서 이어서 다룹니다.

자주 묻는 질문

—bigkeys로 Hot Key도 찾을 수 있나요?

값의 크기와 접근 빈도는 다른 지표입니다. 큰 키를 찾는 결과만으로 가장 자주 호출되는 키를 확정할 수 없습니다.

샤드를 늘리면 단일 Hot Key가 해결되나요?

단일 키의 요청은 자동으로 여러 키로 나뉘지 않습니다. 데이터·읽기 경로를 바꾸거나 프로세스 내 재사용 등 요청 감소 방식을 검토해야 합니다.

로컬 캐시 TTL을 길게 하면 무조건 좋은가요?

원본 호출은 줄일 수 있지만 오래된 값의 유지 시간도 길어집니다. 데이터별 허용 지연과 무효화 방식을 먼저 정하세요.

참고 자료

2026년 10월 8일 문서 확인. 수치는 설명용 예시이며 벤치마크 결과가 아닙니다.

#Redis#분산시스템#성능최적화#캐시
← 전체 글로 돌아가기