Mar 23, 2026

마지막 업데이트 Mar 31, 2026

Redis Latency Spikes 가이드

Redis latency spike는 하나의 문제처럼 보이지만 실제로는 서로 다른 원인이 겹쳐 있는 경우가 많습니다. 어떤 때는 느린 command가 원인이고, 어떤 때는 Redis는 빠른데 host나 network baseline이 이미 나쁜 경우도 있습니다. 또 어떤 때는 persistence, memory pressure, swapping이 특정 시간대에 pause를 만들기도 합니다.

핵심은 간단합니다. command 자체가 느린지, 환경 baseline이 나쁜지, network path가 문제인지, 아니면 persistence나 memory 쪽 부작용인지 먼저 갈라서 봐야 합니다. 이 분기만 제대로 해도 엉뚱한 튜닝으로 시간을 버릴 가능성이 크게 줄어듭니다.

먼저 latency 원인을 네 갈래로 나눠 보세요

Redis latency는 보통 아래 네 갈래 중 하나 또는 여러 개가 겹쳐서 발생합니다.

비싼 Redis command
host나 runtime 환경의 intrinsic latency
network와 client round trip 지연
persistence, memory pressure, swapping 부작용

이 분기를 초반에 하지 않으면 거의 모든 대응이 추측이 됩니다. command 튜닝으로 host jitter를 해결할 수는 없고, network path를 손봐도 big key delete가 비싼 문제는 그대로 남습니다.

느린 command는 전체 그림의 일부일 뿐입니다

느린 command는 흔한 원인이기 때문에 SLOWLOG는 여전히 가장 먼저 볼 도구 중 하나입니다.

하지만 slowlog가 깨끗하다고 해서 Redis가 건강하다는 뜻은 아닙니다. spike는 아래처럼 다른 곳에서도 충분히 생길 수 있습니다.

persistence 중 fork나 rewrite 작업
noisy virtualization이나 host-level jitter
memory pressure와 swapping
client의 과도한 round trip

그래서 latency incident는 한 가지 원인만 가정하지 말고 분기해야 합니다.

event 단서가 필요하면 latency monitor를 같이 보세요

Redis는 이런 상황을 위해 latency monitoring 기능을 제공합니다.

실전에서는 아래 정도부터 시작하면 충분합니다.

redis-cli CONFIG SET latency-monitor-threshold 100
redis-cli LATENCY LATEST
redis-cli LATENCY HISTORY command
redis-cli LATENCY DOCTOR

애플리케이션 로그만으로는 특정 query path와 바로 연결되지 않는 spike를 볼 때 특히 유용합니다. 팀이 “가끔씩 p95가 튄다”거나 “몇 분 동안 cache가 랜덤하게 느려진다”라고 말할 때 latency monitor가 첫 단서를 주는 경우가 많습니다.

intrinsic latency와 network를 무시하면 안 됩니다

Redis 문서도 운영체제, hypervisor, network가 이미 깔고 가는 baseline latency를 만든다고 강조합니다.

아래 질문을 같이 해보세요.

Redis가 noisy한 가상화 환경 위에 있지는 않은가
client와 Redis 사이 거리가 너무 멀지는 않은가
sequential round trip이 너무 많지는 않은가
pipelining으로 줄일 수 있는 왕복 비용은 없는가

가끔은 Redis 자체가 아니라 주변 경로가 느린 것입니다. 이 차이를 못 잡으면 Redis 리소스만 늘리고도 문제는 그대로 남습니다.

persistence, swapping, memory pressure는 ugly spike를 만듭니다

Redis latency는 아래 상황에서 특히 나빠집니다.

memory가 빠듯할 때
kernel이 swap을 사용할 때
persistence fork나 rewrite가 traffic과 겹칠 때
disk 동작이 느려지거나 불안정할 때

spike가 save나 rewrite 시점과 겹친다면 Redis Persistence Latency를 같이 봐야 합니다. memory도 함께 오르고 있다면 Redis Memory Usage High가 더 직접적인 다음 글입니다.

즉, 보이는 증상은 Redis latency여도 운영 원인은 Redis 바깥쪽 시스템 작업일 수 있습니다.

big key는 평범한 command를 spike generator로 만듭니다

큰 key 하나만 있어도 평범한 read, write, delete, expire, rewrite 비용이 예상보다 훨씬 커질 수 있습니다.

그래서 팀 입장에서는 “Redis가 랜덤하게 튄다”라고 느끼지만 실제로는:

특정 key family가 너무 커졌고
특정 feature가 그 family를 burst로 건드렸고
평범한 command가 갑자기 비싸진

상황인 경우가 많습니다.

spike가 특정 feature나 key family에 묶여 보인다면 Redis Big Keys가 가장 좋은 다음 분기입니다.

실전 점검 순서

incident 중이라면 아래 순서가 안전합니다.

SLOWLOG를 본다
latency monitor event를 본다
spike timing을 persistence와 save window와 비교한다
memory pressure나 swapping이 있는지 본다
host나 network baseline이 이미 높은지 확인한다

이 순서가 timeout이나 Redis 설정을 무작정 바꾸는 것보다 실제 원인에 더 빨리 닿습니다.

첫 10분에 볼 명령은 이 정도면 충분합니다

redis-cli SLOWLOG GET 10
redis-cli LATENCY LATEST
redis-cli INFO memory
redis-cli INFO persistence
redis-cli INFO stats

이 출력은 따로따로 보지 말고 같이 읽는 게 좋습니다. slowlog가 무겁게 잡히면 command cost 쪽으로, slowlog는 깨끗한데 persistence activity가 보이면 다른 층으로 분기해야 합니다. memory pressure와 latency event가 같이 보이면 broader resource issue일 가능성이 큽니다.

팀이 자주 놓치는 부분

latency spike는 혼합 incident인 경우가 많습니다.

예를 들면:

특정 command family가 느려지고
host baseline도 원래 noisy했고
persistence window가 peak를 더 악화시키는

식입니다.

이럴 때 원인을 하나만 찾으려 하면 incident가 실제보다 더 미스터리하게 보입니다. Redis가 동시에 피해자이자 기여자가 되는 셈입니다.

계속 던져야 할 질문 하나

spike를 볼 때 “어떤 command가 느렸지?”만 묻지 말고 “어느 층이 먼저 느려졌지?”를 같이 물어보세요.

이 질문이 아래를 갈라줍니다.

Redis execution 문제
환경 baseline 문제
persistence나 memory 부작용 문제

이 차이가 실제 병목을 고치는 것과 겉으로 보이는 증상만 만지는 것의 차이를 만듭니다.

FAQ

Q. Redis latency spike는 항상 Redis command 때문인가요?

아니요. networking, 운영체제, swapping, persistence side effect 때문에도 발생할 수 있습니다.

Q. 가장 빠른 첫 단계는 무엇인가요?

SLOWLOG를 보고, 같은 incident window의 latency monitor event와 비교하는 것입니다.

Q. 언제 big key를 의심해야 하나요?

특정 feature, 특정 key family, 특정 command path 주변에서 spike가 반복될 때입니다.

Q. slowlog가 깨끗한데도 Redis가 느릴 수 있나요?

네. persistence, host latency, memory pressure만으로도 눈에 보이는 spike가 생길 수 있습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.