Mar 23, 2026

마지막 업데이트 Mar 30, 2026

Redis persistence latency: RDB, AOF에서 먼저 확인할 것들

Redis latency spike가 save나 rewrite 시점에 나타난다면, 문제는 특정 명령 하나보다 persistence 작업이 CPU, disk, memory pressure, fork 비용과 충돌하는 데 있을 수 있습니다.

짧게 말하면, 먼저 latency spike가 BGSAVE, AOF write, rewrite activity와 겹치는지 확인하고, 명령 자체가 느린 문제와 persistence 쪽 지연을 분리해서 봐야 합니다.

먼저 persistence latency와 slow command를 구분하세요

Redis가 느려 보이는 이유는 크게 두 가지일 수 있습니다.

명령 자체가 비싼 경우
persistence 작업이 system-level pause나 I/O pressure를 만드는 경우

둘은 함께 올 수도 있지만 같은 문제는 아닙니다. 이 둘을 섞으면 command를 튜닝해야 할 곳에서 persistence를 바꾸거나, 반대로 durability tradeoff를 조정해야 할 곳에서 query만 보고 있게 됩니다.

persistence가 latency에 영향을 주는 이유

RDB snapshot, AOF append, background rewrite는 모두 시스템 자원과 상호작용합니다.

즉 Redis latency가 항상 “느린 명령 하나” 때문은 아닙니다. durability와 background maintenance 비용이 보이는 경우도 많습니다.

persistence 관련 latency spike를 만드는 흔한 이유

1. background save가 이미 바쁜 workload와 겹침

서버가 이미 압박을 받는 상태에서 save나 rewrite가 추가되면 눈에 띄는 latency로 이어질 수 있습니다.

2. AOF append와 fsync 동작이 write pressure를 키움

더 안전한 durability 설정이 실제 트래픽 아래에서는 더 큰 write cost를 만들 수 있습니다.

3. disk나 host 성능이 실제 병목임

Redis 설정이 크게 잘못되지 않았어도 host storage나 system latency가 나쁘면 persistence 비용이 바로 드러납니다.

4. fork와 background 작업이 pause처럼 보이는 증상을 만듦

persistence activity는 개별 명령이 느리지 않아도 fork나 rewrite 구간 주변에서 spike로 보이는 경우가 많습니다.

5. 팀이 다른 계층만 보고 있음

timing상 persistence window가 명확한데도 command pattern만 붙잡고 있는 경우가 자주 있습니다.

실전 점검 순서

1. latency spike가 정확히 언제 나는지 확인하세요

가장 먼저 timing을 봐야 합니다. spike가 save나 rewrite window와 반복해서 맞물리면 persistence가 우선 후보입니다.

2. 같은 시간대의 persistence 상태를 비교하세요

아래 명령이 기본입니다.

redis-cli INFO persistence
redis-cli LATENCY LATEST
redis-cli CONFIG GET appendonly

같은 incident window에서 background save나 rewrite 상태, Redis가 보고한 latency event를 함께 보세요.

3. `SLOWLOG`에도 반복되는 비싼 명령이 있는지 확인하세요

SLOWLOG는 조용한데 save/rewrite 시점에만 latency가 튄다면, query shape보다 persistence가 더 강한 후보입니다.

명령 쪽 조사는 Redis slowlog guide와 함께 보면 됩니다.

4. host와 disk 상태를 같이 보세요

persistence 문제는 종종 인프라 문제이기도 합니다. host가 약하거나 I/O가 제한되어 있으면 Redis persistence가 그 약점을 그대로 드러냅니다.

5. 다음 수정이 durability 설정인지, 인프라인지, workload timing인지 결정하세요

이 분기가 핵심입니다. Redis config를 바꿔야 할 때도 있고, host를 바꿔야 할 때도 있고, save window와 heavy workload의 겹침을 줄여야 할 때도 있습니다.

패턴을 찾은 뒤 어떻게 바꿀지

save나 rewrite overlap이 주원인인 경우

heavy workload와 persistence-heavy operation이 겹치지 않도록 조정하는 방법을 먼저 생각해야 합니다.

AOF 설정이 핵심 tradeoff인 경우

현재 durability 선택이 실제 latency budget에 맞는지 다시 봐야 합니다.

host가 문제인 경우

Redis tuning만의 문제가 아니라 인프라 병목으로 접근해야 합니다.

command도 같이 비싼 경우

그때는 혼합 incident이므로 Redis slowlog guide가 같은 조사 경로 안에 들어와야 합니다.

빠른 체크리스트

Redis latency spike가 persistence activity 주변에서 보일 때는 아래 순서가 좋습니다.

spike timing을 확인한다
save와 rewrite activity와 비교한다
SLOWLOG에서 반복되는 비싼 명령이 있는지 본다
disk와 host 상태를 확인한다
persistence tuning, 인프라 수정, command 수정 중 어디가 다음 액션인지 결정한다

FAQ

Q. RDB snapshot이 Redis latency에 영향을 줄 수 있나요?

그렇습니다. Redis 공식 문서도 persistence를 latency 원인 중 하나로 봅니다.

Q. 항상 `SLOWLOG`부터 봐야 하나요?

유용하지만, latency가 persistence window와 맞물린다면 그것만으로는 부족합니다.

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

같은 incident window의 latency timing과 INFO persistence 상태를 비교하는 것입니다.

Q. `SLOWLOG`가 비어 있어도 Redis가 느릴 수 있나요?

그렇습니다. persistence, system latency, I/O pressure만으로도 체감 지연이 생길 수 있습니다.

먼저 읽어볼 가이드

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