Redis + AOF + Distributed Storage: 주의할 만한 벤치마크

Source: Dev.to

Overview

우리는 로컬 SSD SAS와 Longhorn을 통해 9가지 구성에서 AOF 영속성을 테스트했습니다. 결과는 명확합니다.

프로덕션 마이그레이션을 위한 캐싱 레이어를 베어‑메탈 Kubernetes에 설계하면서, 겉보기엔 단순해 보이지만 비용이 많이 드는 질문에 직면했습니다: Redis AOF 영속성을 Longhorn 분산 스토리지에 두어야 할까요?

Redis 문서는 힌트를 제공하지만, 직관과 문서가 프로덕션 데이터와 동일하지는 않습니다. 그래서 우리는 redis‑benchmark를 사용해 스토리지 백엔드, 영속성 설정, 데이터셋 크기를 다양하게 조합한 아홉 가지 구성에서 실험하고 영향을 직접 측정했습니다.

결과는 명확하며, 특히 한 숫자는 모든 설계자에게 재고할 만한 이유를 제공합니다.

테스트 구성

모든 테스트는 전체적으로 동일한 매개변수를 사용했습니다:

requests:    50,000
clients:     20 parallel
payload:     180,000 bytes (~180 KB)
pipeline:    keep-alive=1
thread:      single‑threaded

180 KB 페이로드는 의도된 값이며, 이는 벤치마크 대상인 실제 프로덕션 워크로드의 현실적인 캐시 객체 크기를 반영합니다. 일반적인 벤더 벤치마크에서 자주 보이는 마이크로‑페이로드 테스트와는 다릅니다.

테스트된 아홉 가지 환경

SET 처리량: 핵심 발견

로드가 걸린 상태에서 쓰기 가능한 캐시에 가장 중요한 지표는 SET 처리량입니다.

핵심 요약:

• AOF 비활성화된 로컬 SSD SAS: 7,696 SET RPS, p99 ≈ 5 ms.
• AOF 활성화된 Longhorn: 537 SET RPS, p99 ≈ 202 ms.

이는 14.3배의 처리량 차이와 39배의 p99 지연 시간 차이를 의미합니다—동일한 애플리케이션 코드, 동일한 Redis 버전, 동일한 클라이언트를 사용했음에도 불구하고. Longhorn에서 최악의 단일 SET 지연 시간은 903 ms에 달했습니다.

The AOF Wall on Local Storage

Even on fast local SSD SAS, AOF incurs a heavy penalty.

대략 20× p99 지연시간 페널티가 로컬 SSD SAS에서 AOF 때문에 발생하며, 튜닝으로는 큰 개선이 없습니다:

Baseline:  102.5 ms p99
Tuning 1:  105.9 ms p99
Tuning 2:  112.4 ms p99  ← actually got worse

왜?
appendfsync everysec 옵션을 사용한 AOF는 최소 1초에 한 번 fsync()를 강제합니다. 180 KB 페이로드를 처리하는 바쁜 단일 스레드 Redis 인스턴스에서는 그 fsync 정지가 지연 시간 예산을 지배합니다. 이를 튜닝으로 극복할 수 없습니다.

Source:

왜 Longhorn이 AOF를 재앙으로 만드는가

Longhorn은 Kubernetes용 분산 블록 스토리지 시스템으로, 내구성을 위해 데이터를 노드 간에 복제합니다. 이는 제어된 쓰기 패턴을 가진 워크로드에 잘 맞지만, Redis AOF는 연속적이고, 작으며, 지연에 민감합니다:

• 각 AOF 추가는 Longhorn 컨트롤러로 네트워크를 통해 전송됩니다.
• 컨트롤러는 N개의 복제본에 쓰기를 복제한 뒤에야 응답을 보냅니다.
• Redis는 그 응답을 받은 뒤에 fsync 확인을 받습니다.
• Redis는 단일 스레드이므로, 그 라운드‑트립을 기다리는 동안 블로킹됩니다.

결과: 모든 SET 명령이 네트워크 라운드‑트립 및 다중 복제본 쓰기 확인 비용을 부담합니다. 180 KB 페이로드에서는 페널티가 급격히 커집니다.

Redis 문서에서는 다음과 같이 경고합니다:

“NFS 마운트와 같이 I/O 경로에 네트워크 지연이 있는 스토리지에 AOF/RDB 파일을 저장하지 마십시오.”

Longhorn은 사실상 네트워크 복제 볼륨입니다. 우리의 벤치마크는 이 경고를 수치화합니다: 최대 지연 903 ms, p99 202 ms.

GET 성능

Read latency는 지속성 설정에 거의 영향을 받지 않는데, 이는 GET이 AOF 로그에 쓰기를 하지 않기 때문입니다.

Longhorn은 AOF‑활성 로컬 스토리지와 비교했을 때 GET 성능을 크게 저하시키지 않으며, 병목 현상이 지속성 쓰기 경로에 있음을 확인합니다.

PING 지연: 기준선

PING throughput shows the overhead when no persistence is involved.

흥미롭게도, Longhorn에서의 PING 성능은 기준선 로컬 AOF‑on보다 더 좋습니다. Longhorn에 의한 페널티는 Redis가 실제로 AOF 로그에 기록해야 할 때만 나타나며—이는 병목 현상이 일반적인 Longhorn I/O 오버헤드가 아니라 영속성 쓰기 경로임을 확인시켜 줍니다.

Source: …

권장 아키텍처

위 결과를 바탕으로 내구성을 필요로 하는 쓰기‑중심 캐시의 올바른 아키텍처는 다음과 같습니다:

1. Redis를 로컬 고성능 SSD(또는 NVMe) 스토리지에 실행한다.
2. 캐시 계층에서는 AOF를 비활성화하고, 내구성이 필요할 경우 주기적인 RDB 스냅샷에 의존한다.
3. AOF가 필요하다면, AOF 파일을 로컬 디스크에 마운트하고 Longhorn, NFS 등과 같은 네트워크 복제 볼륨에는 두지 않는다.
4. 관심사를 분리한다:
   • 핫 캐시 레이어에는 Redis(또는 다른 인‑메모리 스토어)를 사용한다.
   • 영구 레이어에는 전통적인 데이터베이스나 내구성을 갖춘 키‑값 스토어를 사용한다.
5. fsync 지연시간을 모니터링(latency monitor in Redis)하여 appendfsync 정책이 숨은 병목이 되지 않도록 한다.

분리‑내구성 설계

핫 경로 (Primary)

• Redis (AOF 비활성화)
• RDB 스냅샷만 사용, 관대한 임계값 적용 (예: save 3600 1)
• SSD SAS에 로컬 경로 저장
• 결과: 7,600+ SET RPS, p99 지연시간 5 ms 이하

복구 경로 (Replica)

• Primary의 Redis 복제본
• RDB‑전용 스냅샷을 영구 스토리지에 저장 (여기서는 Longhorn 사용 가능 – 스냅샷 쓰기는 드물고 급증 형태)
• 핫 쓰기 경로에 포함되지 않음

이 구성은 전체 쓰기 처리량을 유지하면서 p99 지연시간을 5 ms 이하로 제공하고, 복제본의 주기적인 스냅샷을 통해 내구성을 보장합니다. Primary가 실패할 경우 최대 한 번의 RDB 스냅샷 간격만큼의 데이터가 손실되며, 이는 대부분의 캐시 워크로드에서 허용 가능한 수준입니다.

모든 쓰기에 대해 진정한 내구성이 필요하다면(캐시에서는 드물지만) 올바른 해결책은 다른 도구이며, 분산 스토리지에 AOF를 사용하는 Redis는 적합하지 않습니다.

요약

AOF‑on‑Longhorn과 AOF‑off‑local 사이의 14배 처리량 차이는 설정 문제가 아니라 아키텍처 불일치입니다. 느린 영속성을 가진 빠른 캐시를 구축하는 것은 모순이며, 이 수치가 이를 증명합니다.

환경 세부 정보

• Redis 버전: 7.x
• 스토리지 백엔드:
  • 로컬‑path 프로비저너 (SSD SAS)
  • Kubernetes 1.31 위의 Longhorn 1.6
• redis‑benchmark 매개변수: -n 50000 -c 20 -d 180000 --keepalive 1
• 모드: 싱글‑스레드 ( --threads 플래그 없음)
• 데이터셋: 기본 상태에서는 비어 있음; 로드 테스트에서는 375,795개의 키

Kubernetes에서 Redis 아키텍처에 대한 질문이 있나요? 아래에 댓글을 남겨 주세요.

— Iwan Setiawan, Hybrid Cloud & Platform Architect · portfolio.kangservice.cloud