[Redis] 성능 트러블슈팅 가이드: slowlog, 메모리 증가, 핫키, 캐시 적중률 증상별 원인과 대응

[Redis] 성능 트러블슈팅 가이드: slowlog, 메모리 증가, 핫키, 캐시 적중률 증상별 원인과 대응

Redis는 빠른 만큼 한 번 느려지면 그게 바로 서비스 전체 지연으로 번져요. "API가 갑자기 느려졌는데 Redis 때문인가?", "메모리가 계속 차는데 왜지?" 같은 상황에서 백엔드 개발자가 어디를 봐야 하는지를 증상별로 정리해요.

각 증상마다 지표와 대응을 짚고 깊은 내용은 시리즈의 해당 글로 연결해요. 이 글은 Redis 시리즈의 진단 허브예요.

01. Redis 성능 트러블슈팅, 순서는 측정 → 좁히기 → 대응

증상이 무엇이든 순서는 같아요. 지표로 측정하고 증상 패턴으로 원인을 좁혀요. 원인에 맞는 대응을 해요.

Redis는 INFO 명령 하나로 대부분의 상태를 줘요. 모니터링 도구도 보통 이걸 긁어요. 백엔드 입장에서 챙길 지표는 이래요.

• latency / slowlog — 느린 명령 기록. 응답 지연의 첫 단서예요.
• used_memory / maxmemory — 메모리 사용량. 상한에 가까워지면 위험 신호예요.
• evicted_keys — eviction으로 쫓겨난 키 수. 늘면 메모리 압박이에요.
• hit rate — 캐시 적중률(keyspace_hits / (keyspace_hits + keyspace_misses)). 낮으면 캐시가 일을 못 하는 거예요.
• connected_clients / ops per sec — 연결 수와 처리량.

느린 명령과 빅키 찾는 법

느린 명령은 SLOWLOG GET으로 바로 봐요. 어떤 명령이 얼마나 걸렸는지 기록돼 있어요. 메모리를 먹는 빅키는 redis-cli의 분석 옵션으로 찾아요.

# 느린 명령 최근 기록
redis-cli SLOWLOG GET 10

# 자료구조별 가장 큰 키 샘플링
redis-cli --bigkeys

# 특정 키의 메모리 사용량
redis-cli MEMORY USAGE mykey

--bigkeys는 전체를 스캔하며 각 타입의 가장 큰 키를 알려줘요(운영에서도 비교적 안전하게 돌아가요). 핫키 탐지용 <code>redis-cli --hotkeys</code>도 있는데 maxmemory-policy가 LFU 계열일 때만 동작해요. 이 둘이면 "무엇이 느리고 무엇이 메모리를 먹는가"의 90%는 잡혀요. 진단은 거의 항상 여기서 시작해요.

함정 하나 — MONITOR는 조심해요. 모든 명령을 실시간으로 보여줘서 진단에 유용해 보이지만 그 자체가 Redis에 상당한 부하를 줘요. 운영에서 오래 켜두면 진단하려다 장애를 만들어요. 짧게만 쓰거나 피하는 게 좋아요.

02. 증상: 응답이 느려졌어요

Redis가 느려지는 가장 흔한 원인은 무거운 명령이에요. Redis는 싱글스레드라, 한 명령이 오래 걸리면 그 뒤 모든 요청이 대기해요.

• O(N) 명령 — KEYS *나 큰 컬렉션 전체 조회가 전부를 멈춰요. KEYS는 운영에서 절대 쓰지 말고 SCAN으로 바꿔요.
• 빅키(big key) — 한 키에 값이 수십만 개 들어 있으면 그걸 다루는 명령이 느려져요. 큰 자료구조를 잘게 쪼개요.
• 무거운 Lua — 긴 스크립트가 Redis를 붙잡아요. 짧게 유지해요.

O(N) 명령과 빅키가 응답 지연의 양대 원인이에요. 자료구조 설계는 자료구조 활용 글에, Lua 주의는 트랜잭션·Lua 글에 있어요.

진단의 갈림길이 되는 함정 — 느려진 원인이 Redis 안이 아니라 밖일 수도 있어요. slowlog는 Redis가 명령을 실행한 시간만 재거든요. 그래서 slowlog는 깨끗한데 애플리케이션에서는 느리게 느껴지면, 커넥션 풀 대기나 네트워크 지연을 의심해요. 이 분기를 먼저 가르면 엉뚱한 곳을 튜닝하는 일이 없어져요.

03. 증상: 메모리가 계속 차요

used_memory가 계속 늘면 키가 정리되지 않는 거예요. 원인은 보통 이래요.

• TTL 누락 — 캐시성 키에 만료를 안 둔 거예요. 안 지워지고 쌓여요.
• 빅키 — 한 키가 메모리를 통째로 먹는 경우예요.
• eviction 발생 — evicted_keys가 늘면 이미 상한에 닿아 키를 쫓아내는 중이에요.

대응은 TTL을 빠짐없이 걸고 빅키를 찾아 쪼개요. eviction 정책은 용도에 맞게(캐시는 LRU·LFU) 두는 거예요. 특히 캐시와 세션·분산락을 한 Redis에 섞고 allkeys eviction을 켜면 세션·락이 지워지는 사고가 나요. 메모리·eviction은 메모리 정책과 고가용성 글에서 다뤘어요.

04. 증상: 특정 키만 부하가 몰려요 (핫키)

전체 부하는 괜찮은데 특정 키 하나에 요청이 집중되면 핫키예요. 인기 상품, 전체 공지처럼 모두가 보는 키에서 생겨요. 그 키를 맡은 처리가 병목이 돼요.

대응은 두 가지예요. 그 키를 여러 개로 분산하거나, 아주 자주 읽히는 키는 애플리케이션 로컬 캐시를 앞에 둬서 Redis 호출 자체를 줄여요(2-tier). 로컬 캐시는 캐싱 글에서 다뤘어요.

05. 증상: 연결이 막히거나 타임아웃 나요

connected_clients가 치솟거나 타임아웃이 늘면 연결 쪽 문제예요. 커넥션 풀이 작아 고갈됐거나, Redis가 느려져 연결이 안 풀리는 거예요.

먼저 Redis 자체가 느린지(slowlog)부터 보고 느리지 않은데 막히면 풀 크기와 타임아웃을 조정해요. 그리고 타임아웃을 반드시 둬서 Redis가 느려져도 요청이 무한정 매달리지 않게 해요. 연결·타임아웃 설정은 Spring Data Redis 설정 글에 있어요.

06. 증상: 캐시 적중률이 낮아요

hit rate가 낮으면 캐시를 깔았는데 DB를 자꾸 치는 거예요. 캐시 효과가 안 나는 거죠. 원인은 보통 이래요.

• TTL이 너무 짧음 — 채우자마자 만료되면 매번 미스예요.
• 캐시 키 설계 문제 — 키가 너무 잘게 갈려 재사용이 안 돼요.
• 캐시 관통 — 없는 데이터를 반복 조회해 미스가 쌓여요.

TTL을 적절히 늘리고 키를 재사용되게 설계해요. 관통은 null 캐싱·Bloom Filter로 막아요. 캐시 전략과 관통·스탬피드는 캐시 스탬피드와 3대 장애 글에 있어요.

07. 진단 순서, INFO와 slowlog부터

증상이 무엇이든 순서는 같아요. INFO로 전반(메모리·연결·hit rate)을 보고 slowlog로 느린 명령을 짚어요. 빅키 분석으로 메모리를 먹는 키를 찾아요. "측정 → 느린 명령·빅키 찾기 → 대응"이 골격이에요. 추측으로 설정부터 만지면 엉뚱한 데를 고쳐요.

증상별 빠른 참조

Redis 성능 이슈는 INFO·slowlog·메모리 지표로 측정하고 증상별로 좁혀 대응하는 거예요. 막힐 때 스스로 물어볼 한 줄은 이거예요. "지금 보이는 게 어느 증상이고 그 증상은 어디를 가리키나?" 느리면 O(N) 명령·빅키를, 메모리가 차면 TTL·빅키·eviction을, 특정 키에 부하가 몰리면 핫키 분산을, 연결이 막히면 풀·타임아웃을, 적중률이 낮으면 TTL·키 설계를 봐요. Redis는 싱글스레드라 무거운 명령 하나가 전체를 멈춘다는 걸 기억하면 진단이 빨라져요.

증상 관점에서 묶은 진단 허브이니, 더 깊게는 Spring Data Redis 설정·캐싱·자료구조·메모리·고가용성 글로 들어가요.

출처: Redis — Optimization · Redis — SLOWLOG