원문 캡처 · lavik.dev
원문 캡처 · lavik.dev

Lavik은 NVMe SSD에 값을 저장하는 Redis 호환 저장소를 내세워, 메모리 용량 때문에 서버를 늘려야 하는 클러스터를 300대에서 3대로 줄이는 구성을 제시했다. 회사가 공개한 비교에서 Lavik 0.1.0은 특정 조건에서 Redis의 처리량을 웃돌았지만, 비용과 성능 수치는 자체 벤치마크 및 Azure 가정에 따른 결과다.

300대와 3대의 비용 비교

Lavik은 Azure East US 2에서 Linux 종량제 요금으로 월 730시간 운영하는 구성을 비교했다. Redis는 2 vCPU·16 GiB RAM을 갖춘 Standard_E2s_v4 가상 머신 300대에 주 서버와 복제본을 각각 150대 배치한다. Lavik은 NVMe가 있는 Standard_L16as_v4 데이터 서버 2대와 데이터 복사본을 보유하지 않는 Standard_E2s_v4 투표 서버 1대를 사용한다. 데이터 서버마다 16 vCPU, 128 GiB RAM과 3.84 TB의 로컬 NVMe SSD가 있다.

  • Redis 300대의 월 가상 머신 비용은 27,594달러, 연간 비용은 331,128달러다.
  • Lavik 3대의 월 비용은 2,100.94달러, 연간 비용은 25,211.28달러다.
  • 제시된 월 절감액은 25,493.06달러(92.4%), 연간 절감액은 305,916.72달러다.
배포 구성단일 데이터 용량 기준TB당 월 가상 머신 비용
Redis · 300 × E2s_v4주 서버 RAM 2,400 GiB(약 2.577 TB)$10,707.88
Lavik · 2 × L16as_v4 + 1 × E2s_v4NVMe SSD 3.84 TB$547.12

비용 계산에는 운영체제 디스크, 백업, 네트워크 트래픽, 인력과 세금이 포함되지 않는다. 용량 비교도 데이터베이스 오버헤드와 운영 여유 공간을 반영하기 전의 수치다. 두 데이터 서버가 각각 전체 데이터 복사본을 보유하므로 Lavik의 단일 복사본 용량 기준은 3.84 TB다. 세 번째 서버는 Raft 과반수 구성을 위한 메타데이터 투표자이며 애플리케이션 데이터는 저장하지 않는다. 비용 산정 기준과 Azure 요금 자료를 바탕으로 한 업체의 계산이다.

공개 벤치마크의 조건과 결과

Lavik은 16 vCPU Azure 서버 한 대에서 Lavik 0.1.0 SPDK, Redis 8.10.2, Valkey 9.1.2를 비교했다. 별도 부하 생성기가 사설 네트워크로 1 KiB 값에 무작위 GET·SET 요청을 보냈고, 파이프라인 깊이는 1이었다. Redis와 Valkey는 DRAM에서 값을 읽고 썼으며 Lavik은 NVMe 저장 경로를 사용했다.

시스템·작업초당 처리량(QPS)평균 지연(ms)P99 지연(ms)
Lavik 0.1.0 SPDK GET1,145,7721.1173.999
Lavik 0.1.0 SPDK SET971,9501.3174.479
Redis 8.10.2 GET1,018,7351.2564.415
Redis 8.10.2 SET951,0531.3464.511
Valkey 9.1.2 GET970,2881.3194.415
Valkey 9.1.2 SET808,1031.5834.047

위 수치는 1,280개 연결에서 측정한 결과다. Lavik의 GET 처리량은 이 조건에서 Redis보다 12.5%, Valkey보다 18.1% 높았고, SET 처리량은 Redis보다 2.2% 높았다. 이 결과를 모든 작업이나 실제 운영 환경에 일반화할 수는 없다. 벤치마크는 복제본 없이 단일 서버에서 수행됐으며, 운영 환경을 선택할 때는 애플리케이션의 값 크기와 명령 구성, 복제 지연을 포함한 꼬리 지연을 별도로 측정해야 한다. 측정 결과와 방법 및 대규모 데이터셋 보고서에 상세 조건이 담겨 있다.

Lavik은 10억 개 키 실험에서 원시 값 1.024 TB를 처리했고, GET 처리량은 초당 1,069,126회였다고 밝혔다. 해당 데이터는 서버 RAM의 약 7.6배였다. 별도의 10억 키 조건에서는 연결 80개에서 GET 처리량 385,514 QPS와 P99.9 지연 0.439ms를 기록했다고 설명했다. 혼합 작업을 다룬 별도 io_uring YCSB 실험에서는 1억 개 레코드, 필드 10개(각 128바이트), 복제본 없음 조건에서 읽기·갱신 비율 50 대 50일 때 529,501 QPS, 95 대 5일 때 577,373 QPS를 보고했다.

적용 전 확인할 점

Lavik은 키 인덱스와 메타데이터, 활성 버퍼는 DRAM에 두고 값은 NVMe SSD에 저장하는 구조를 설명한다. 로컬 NVMe는 임시 저장소이므로 업체는 VM 간 복제와 외부 백업을 함께 사용하고, 장애 도메인 배치와 복구 목표를 고려하라고 안내한다. 메타데이터에는 Raft를 사용하지만 데이터 복제는 비동기 방식이다. 따라서 복구 시점과 복구 시간 목표를 정하고 장애 조치와 팔로워 재구축을 실제 데이터 규모에서 시험해야 한다.

업체는 RedisShake를 이용해 기존 Redis에서 기준 데이터를 복사한 뒤 변경분을 따라잡고, 키 수·값·만료 시간을 대조한 후 전환하는 절차도 제시한다. 쓰기 전환 뒤 롤백 방안까지 마련해야 한다. 마이그레이션 안내를 참조할 수 있다.

이 구성은 CPU나 요청량보다 메모리 부족이 먼저 확장을 일으키는 서비스에 검토 대상이 될 수 있다. 다만 실제 서버 수와 비용은 명령 종류, 데이터 크기, 지연 목표, 복제와 백업 요구에 따라 달라지므로 대표 작업을 대상으로 부하와 장애 복구를 확인해야 한다. Lavik은 Apache 2.0 오픈소스 라이선스를 사용한다고 밝혔다.