Redis 지연 시간 벤치마크: HotKV와 Valkey, Dragonfly 비교

이 Redis 지연 시간 벤치마크는 고정된 요청 속도에서 HotKV, Redis, Valkey, Dragonfly가 응답하는 데 걸리는 시간을 측정합니다. 이전 벤치마크는 처리량을 측정했는데, 한 독자께서 처리량이 전부는 아니라고 정확히 짚어 주셨습니다. 그래서 부하를 일정하게 유지하고 단계별로 높이면서, 각 단계에서 중앙값(p50)과 99번째 백분위수(p99)를 기록했습니다. pub/sub 전달 시간도 함께 측정했습니다.

요약. AWS에서 진행한 이 Redis 지연 시간 벤치마크에서 HotKV와 Dragonfly는 모두 초당 160만 GET을 유지했고, I/O 스레드 8개의 Redis는 약 80만, I/O 스레드 8개의 Valkey는 약 40만, 단일 스레드 Redis와 Valkey는 약 20만을 유지했습니다. 초당 20만에서 160만 요청 구간에서 HotKV의 p99는 0.59~0.76 ms였고, Dragonfly는 0.71~1.48 ms였습니다. 부하가 가벼울 때는 멀티스레드 제품들이 p99에서 비겼고, pub/sub 전달도 비겼습니다.

고정 속도로 Redis 지연 시간 벤치마크를 한 이유

처리량 테스트는 서버를 한계까지 몰아붙인 뒤 얼마나 처리했는지를 보고합니다. 이것만으로는 요청 하나가 얼마나 기다리는지 알기 어렵습니다. 지연 시간 테스트는 클라이언트가 초당 보내는 요청 수를 고정하고 각 요청에 걸린 시간을 측정합니다. 그러면 서버가 다른 제품과 같은 부하를 받으므로 시간을 비교할 수 있습니다.

이런 테스트에는 함정이 있습니다. memtier_benchmark는 폐쇄 루프 도구라서, 클라이언트는 응답을 받은 뒤에야 다음 요청을 보냅니다. 서버가 따라가지 못하면 클라이언트는 그저 더 적게 보내고, 보낸 요청의 지연 시간은 실제보다 좋아 보입니다. 그래서 달성한 속도가 요청한 속도의 97퍼센트 이상일 때만 그 단계를 유지한 것으로 셉니다. 이 조건을 통과하지 못한 단계는 표에 "NS"(유지 못함)로 표시하고 지연 시간은 보여 주지 않습니다.

테스트 내용

머신

• 서버와 부하 생성기. eu-south-2a의 AWS 클러스터 배치 그룹에 있는 c8a.12xlarge 인스턴스(AMD EPYC 9R45, 48코어, SMT 없음, 96 GiB, 22.5 Gbit/s 네트워크)이며 OS는 Ubuntu 24.04입니다. 한 인스턴스가 부하 생성기를, 다른 한 인스턴스가 서버를 실행했습니다.
• 제품은 한 번에 하나씩. 각 제품은 서버에서 단독으로 실행했으므로 겹치는 것도, 네트워크를 공유하는 것도 없었습니다. 모든 서버 프로세스는 CPU 0~39에 고정했고, 영속성과 보호 모드는 껐습니다.

제품

• HotKV 0.3.0, 40스레드.
• Dragonfly 2.0.2, 프로액터 스레드 40개.
• Redis 8.10.3과 Valkey 9.1.3. 각각 기본 단일 스레드 설정과 --io-threads 8 설정으로 두 번 실행했습니다.

각 실행의 시작 명령줄과 CONFIG GET 실시간 출력은 결과와 함께 저장했습니다.

부하와 절차

데이터 집합은 256바이트 값을 가진 키 1,000,000개이고, 파이프라인 깊이는 1이라서 각 요청이 자신의 응답을 기다립니다. 부하는 GET만 쓴 경우와 쓰기 1에 읽기 10을 섞은 경우입니다. 각 단계는 20초씩 두 번 실행했고, 두 실행의 평균을 보고합니다. memtier_benchmark는 연결별 속도 제한을 사용했고 HDR 히스토그램을 기록했습니다. 연결 수는 두 가지를 시험했습니다.

• 816개 연결(연결 34개짜리 스레드 24개). 속도는 초당 20,000에서 240만 요청까지입니다.
• 48개 연결(연결 12개짜리 스레드 4개). 속도는 초당 300,000 요청까지입니다. 그 이상에서는 각 연결이 응답을 받는 만큼만 보낼 수 있어서 48개 연결로는 속도에 도달할 수 없습니다.

결과

연결 수별 GET 표가 먼저 나오고, 그다음 pub/sub입니다.

연결 816개

각 칸은 GET의 p50 / p99(밀리초)입니다. "NS"는 유지하지 못했다는 뜻이며, 실제로 도달한 속도는 괄호 안에 적었습니다. 하이픈은 그 제품의 측정이 이미 멈췄다는 뜻입니다.

혼합 부하도 같은 양상이었습니다. 초당 20만에서 160만 요청 구간에서 HotKV의 p99는 0.54~0.75 ms였고, 각 제품이 유지할 수 있었던 지점은 GET과 같았습니다. 모든 데이터는 결과 폴더에 있습니다.

단일 스레드 행을 읽는 방법

연결 816개에서 단일 스레드 Redis와 Valkey의 중앙값 1.6~3 ms는 정상 상태의 지연 시간이 아닙니다. 속도 제한을 쓰면 memtier_benchmark는 816개 연결을 같은 순간에 한꺼번에 보냅니다. 단일 스레드 서버는 이 816개 요청의 폭주를 하나씩 처리해야 하므로, 요청의 중앙값에는 대기열에서의 순번이 포함됩니다. 이 효과를 없애려고 아래의 48개 연결 테스트를 진행했습니다.

연결 48개

칸의 의미는 위와 같고 GET만 다룹니다.

pub/sub 전달 시간

발행에서 구독자에게 전달되기까지의 시간을 발행자 64개, 구독자 100개, 128바이트 페이로드로 pubsub-sub-bench를 사용해 측정했습니다. 각 메시지는 구독자 한 명에게 전달됩니다. 칸은 p50 / p99(밀리초)입니다.

모든 제품이 같은 범위에서 전달했습니다. 가장 높은 부하에서는 단일 스레드 제품의 중앙값이 더 높아서, HotKV의 0.11 ms에 비해 0.51 ms와 0.57 ms였습니다.

pubsub-sub-bench도 패치해야 했습니다. 이 도구는 밀리초 단위의 발행 시각과 마이크로초 단위의 수신 시각을 비교하고 있었습니다. 패치는 결과 폴더에 있습니다.

결과가 보여 주는 것

표는 높은 부하에서는 HotKV와 Dragonfly가 앞서고, 가벼운 부하에서는 비기며, 단일 스레드 Redis와 Valkey에는 상한이 있음을 보여 줍니다.

HotKV와 Dragonfly는 초당 160만 요청까지 낮은 꼬리를 유지했습니다

둘 다 연결 816개에서 초당 160만 GET을 유지했고 중앙값은 0.28 ms였습니다. HotKV의 p99는 초당 20만 요청부터 0.59~0.76 ms였습니다. Dragonfly는 0.71~1.48 ms였고, 160만에서는 두 제품이 비슷했습니다(0.64 ms와 0.71 ms). I/O 스레드를 쓴 Redis와 Valkey는 더 낮은 부하에서 속도를 유지하지 못했고, 단일 스레드 Redis와 Valkey는 약 26만에서 유지하지 못했습니다.

가벼운 부하에서는 멀티스레드 제품들이 비깁니다

연결 48개, 초당 300,000 요청까지의 구간에서 HotKV, Dragonfly, I/O 스레드 8개의 Redis는 모두 p99가 약 0.27 ms였습니다. 중앙값은 HotKV가 가장 낮아서 초당 100,000 요청부터 0.08~0.09 ms였고, Dragonfly는 0.08~0.10 ms였습니다. 0.01 ms 차이는 구성의 다른 부분이 만들 수 있는 범위 안이므로 우위라고 주장하지 않습니다.

단일 스레드 Redis와 Valkey는 초당 약 23만에서 한계에 이르렀습니다

연결 48개에서 중앙값은 약 0.2 ms, p99는 0.35~0.43 ms였고, 초당 300,000 요청은 유지하지 못했습니다(약 231,000과 233,000). 이 하드웨어와 이 부하에서 스레드 하나의 상한입니다. 그래서 Redis와 Valkey는 보통 여러 프로세스나 클러스터로 실행하며, 클러스터 벤치마크에서도 그렇게 했습니다.

한계

위에 적은 버전과 구성에 대한 HotKV Ltd의 측정입니다. 이 제품들의 다른 버전, 구성, 부하에 대한 주장이 아닙니다.

테스트 구성

• 서버 한 대, 부하 생성기 한 대. 단계마다 두 번 반복했고, 한 세트의 머신을 하루에 사용했습니다. 머신 간 또는 날짜 간 편차는 측정하지 않았습니다.
• 우리가 고른 구성. Redis와 Valkey는 기본 단일 스레드 설정과 --io-threads 8로 실행했고, 그 이상의 튜닝은 하지 않았습니다. 다른 설정은 수치를 바꿀 수 있습니다. 여기의 어떤 설정이 특정 제품에 불리하다고 생각하시면 알려 주세요. 확인한 뒤 결과를 공개하겠습니다.
• 도구의 폭주 효과. 연결 816개에서는 memtier_benchmark 속도 제한의 동작 방식 때문에 단일 스레드 제품의 중앙값이 부풀려졌습니다. 위에서 설명한 대로입니다.

측정하지 않은 것

• 데이터. 더 큰 값이나 치우친 값, 키당 메모리, 영속성. 모든 서버에서 영속성은 꺼져 있었습니다.
• 모드. 클러스터 모드, 샤딩된 pub/sub, TLS, 복제, 장애 조치.
• pub/sub 팬아웃. 하나의 메시지를 여러 구독자에게 보내는 경우.

Redis, Valkey, Dragonfly는 각 소유자의 상표입니다. 측정한 소프트웨어를 식별하기 위해서만 언급하며, 후원, 보증, 제휴를 의미하지 않습니다.

직접 재현하기

스윕 스크립트, 각 서버의 시작 명령줄과 실시간 설정, pubsub-sub-bench 패치, 모든 원본 결과는 벤치마크 저장소에 있습니다. 지연 시간 스크립트는 harness/lat_sweep.sh, pub/sub 스크립트는 harness/ps_sweep.sh입니다. raw 폴더에는 테스트마다 memtier_benchmark JSON, HDR 히스토그램, 각 실행의 서버 CPU 사용량이 담긴 아카이브가 하나씩 있습니다.

직접 사용해 보기

HotKV Cloud가 HotKV를 대신 운영해 드립니다. HotKV Cloud 시작하기를 이용하시거나 영업팀과 상담하여 귀사의 워크로드로 HotKV를 비교해 보세요.

자주 묻는 질문