Mar 23, 2026

마지막 업데이트 Mar 31, 2026

Redis Slowlog 가이드

Redis가 느릴 때 가장 흔한 실수는 network부터 의심하는 것입니다. 실제로는 한두 개 command 패턴이 서버에서 생각보다 훨씬 많은 일을 하고 있는 경우가 많고, 그걸 가장 빨리 보여주는 도구가 SLOWLOG입니다.

핵심은 간단합니다. 먼저 SLOWLOG로 server-side에서 비싼 command가 있는지 확인하고, 그다음 이슈가 command shape인지, big key인지, 아니면 persistence나 host-level noise 같은 더 넓은 latency 문제인지를 갈라야 합니다. SLOWLOG 자체가 모든 답을 주지는 않지만, 올바른 분기를 주는 도구입니다.

`SLOWLOG`가 실제로 알려주는 것

Redis SLOWLOG는 설정된 threshold를 넘긴 server-side command 실행 시간을 기록합니다.

이 점이 중요합니다. SLOWLOG는 end-to-end latency 도구가 아닙니다. client round trip, network delay, 사용자 체감 전체를 재지 않습니다. 대신 더 좁고 실전적인 질문에 답합니다. 어떤 command가 Redis 입장에서 비쌌는가를 보여주는 것입니다.

slowlog에 자주 잡히는 패턴

1. oversized key나 큰 collection을 건드리는 command

command 자체는 평범하지만 data shape 때문에 비싸질 수 있습니다.

2. 넓게 훑는 scan 계열이나 wide operation

큰 set, hash, list, sorted set 위에서 범위를 크게 잡는 연산이 자주 보입니다.

3. Lua script나 한 번에 너무 많은 일을 하는 compound work

script 하나가 팀이 생각한 것보다 훨씬 많은 작업을 숨기고 있을 수 있습니다.

4. incident 내내 반복되는 하나의 command family

보통 신호는 한 번의 dramatic한 outlier가 아니라 같은 패턴이 계속 반복되는 것입니다.

먼저 볼 명령

redis-cli SLOWLOG LEN
redis-cli SLOWLOG GET 10
redis-cli INFO commandstats

이 세 개를 같이 봐야 recent entry와 command family별 전체 비중을 같이 이해할 수 있습니다.

실전 점검 순서

1. `SLOWLOG GET`으로 최근 entry를 봅니다

한 번 튄 값보다 패턴을 찾는 것이 중요합니다.

2. 반복되는 command family를 찾습니다

한 번 느린 호출은 noise일 수 있지만, 같은 family가 반복되면 운영 문제일 가능성이 큽니다.

3. 그 command가 건드리는 data shape를 확인합니다

이 지점에서 Redis Big Keys와 자연스럽게 이어집니다. 많은 slow command는 사실 data shape 문제입니다.

4. command cost와 broader latency를 분리합니다

SLOWLOG는 조용한데도 Redis가 느리다면 persistence, host latency, system-level factor를 의심해야 합니다.

이 분기는 Redis Persistence Latency와 Redis Latency Spikes에서 더 직접적으로 다룹니다.

5. Redis 설정을 건드리기 전에 app 패턴을 바꿀 수 있는지 봅니다

애플리케이션이 계속 비싼 command 패턴을 보내면 server tuning만으로는 incident가 끝나지 않습니다.

분기를 쉽게 해주는 간단한 예시

반복적으로 HGETALL, LRANGE, ZRANGE가 큰 collection 위에서 보인다면 문제는 command shape와 data size 조합일 가능성이 큽니다.

반대로 slowlog가 거의 비어 있는데 사용자 체감 latency는 계속 튄다면 다음 질문은 아래로 넘어가야 합니다.

persistence window가 있었는가
host가 noisy했는가
swapping이 있었는가
network round trip이 과도했는가

이 차이를 빨리 잡는 것이 SLOWLOG의 가치입니다.

패턴을 찾은 뒤 무엇을 바꿔야 하나

특정 command family가 지배적일 때

호출 빈도를 줄이거나, 한 번에 만지는 데이터를 줄이거나, access pattern을 바꿔야 합니다.

실제 문제가 big key일 때

oversized key나 collection을 쪼개서 command가 매번 처리하는 양을 줄여야 합니다.

slowlog가 조용할 때

command 탓을 멈추고 persistence, system latency, host pressure 쪽으로 넘어가야 합니다.

incident checklist

Redis가 느릴 때는 아래 순서가 좋습니다.

recent slowlog entry를 본다
반복되는 command family를 찾는다
key와 data shape를 확인한다
broader latency 증상과 비교한다
랜덤한 server tuning보다 app pattern 변경을 먼저 본다

실전 감각 하나

dramatic한 slowlog entry 하나는 흥미로울 수 있지만, 운영 pain을 설명하는 것은 보통 반복 패턴입니다.

그래서 가장 유용한 질문은 “가장 느린 command가 무엇이었지?”보다 “어떤 비싼 작업이 계속 반복되고 있지?”입니다.

같이 보면 좋은 비교 하나

반복되는 command family를 찾았다면, 그 패턴이 사용자 체감 slowdown window와 겹치는지도 확인하세요.

이 비교를 하면 아래 둘을 구분할 수 있습니다.

객관적으로 비싼 command
비싸면서 incident의 직접 원인이 된 command

모든 slowlog entry가 outage의 root cause는 아니기 때문에 이 차이가 중요합니다.

FAQ

Q. `SLOWLOG`는 network latency도 보여주나요?

아니요. server-side command 실행 시간만 보여줍니다.

Q. 가장 먼저 봐야 할 것은 무엇인가요?

반복되는 비싼 command와 그 command가 건드리는 key 또는 data structure입니다.

Q. `SLOWLOG`가 거의 비어 있는데도 latency가 높으면 어떻게 해야 하나요?

persistence, system latency, broader Redis timing 이슈를 봐야 합니다.

Q. 왜 한 번의 slow entry보다 패턴이 더 중요한가요?

운영 incident는 보통 한 번의 outlier보다 반복되는 작업에서 생기기 때문입니다.

먼저 읽어볼 가이드

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