Redis와 Dragonfly 직접 비교 — 아키텍처와 운영상 차이

AI 요약

Redis를 캐시뿐 아니라 세션, 카운터, 분산 잠금, 리더보드, Pub/Sub, 스트림, 큐에도 써 온 작성자가 Dragonfly를 직접 사용하고 두 시스템의 설계와 차이를 살펴봅니다. 정교한 벤치마크를 실행한 글은 아닙니다. 작성자는 실제 애플리케이션의 부하로 성능을 확인해야 한다고 강조하며, 후원이나 DragonflyDB와의 제휴 없이 작성했다고 밝힙니다.

Redis의 단일 실행 스레드

Redis는 명령을 주 실행 스레드에서 한 번에 하나씩 처리합니다. 작성자는 이 설계가 단순하고 예측 가능한 동작, 데이터 구조 주변의 잠금 제거, 명령 원자성의 이해와 디버깅에 유리하다고 설명합니다. Redis가 만들어진 2009년의 서버 환경을 고려하면 합리적인 선택이었고, 지금도 그 장점은 유효하다는 관점입니다. Redis 6부터는 네트워크 입출력 작업을 여러 스레드에 분산하며, Redis 8에서는 이 기능이 더 개선됐습니다. 명령 실행은 직렬화해 기존 모델을 유지하면서 네트워크 처리의 병목을 줄이는 방식입니다.

Dragonfly의 멀티스레드 구조

Dragonfly는 여러 코어를 활용하도록 설계했습니다. 데이터를 샤드로 나누고 각 샤드를 한 스레드가 맡는 shared-nothing 구조입니다. 요청은 해당 데이터를 소유한 스레드로 전달됩니다. 여러 샤드에 걸친 작업에는 별도 조정이 필요하지만, 작업을 여러 코어로 나눠 처리한다는 점이 설계의 중심입니다. Redis 프로토콜을 지원하므로 작성자는 기존 연결 문자열만 Dragonfly로 바꾸고 클라이언트 라이브러리는 그대로 사용했습니다.

다만 Redis 인스턴스가 CPU나 메모리 압박을 받지 않는다면 바꿔도 효과가 작을 수 있습니다. GET/SET 같은 합성 벤치마크만으로 실제 애플리케이션의 개선 여부를 알기 어렵습니다. CPU나 메모리가 병목인지 먼저 확인하고, 자신의 명령 구성과 부하로 비교하라고 권합니다.

마이그레이션 전에 확인할 차이

Dragonfly는 AOF를 지원하지 않습니다. 문서는 커뮤니티의 우선순위가 높지 않았다는 이유를 듭니다. 장애 뒤 승인된 모든 쓰기의 보존이 필요하다면 고려해야 할 차이입니다. 스냅샷에도 사용자가 보고한 문제가 있습니다. 한 GitHub 이슈에는 S3 스냅샷이 일주일간 중단된 뒤 장애 복구 과정에서 일주일 전 데이터가 복원됐다는 내용이 있습니다. 작성자는 원인을 확인하지 못했다고 덧붙입니다.

Lua 버전도 다릅니다. Dragonfly는 Lua 5.4, Redis는 Lua 5.1을 사용하므로 기존 스크립트를 점검해야 합니다. Dragonfly는 기본 설정에서 선언하지 않은 키를 스크립트가 건드리면 오류를 반환합니다. allow-undeclared-keys 옵션으로 허용할 수 있지만, 이때는 스크립트 실행 중 다른 모든 작업을 멈춰야 한다고 문서가 경고합니다. 키 이름을 동적으로 만드는 스크립트라면 특히 확인이 필요합니다.

여러 키에 걸친 연산은 VLL 알고리즘 기반 트랜잭션 프레임워크로 처리합니다. 프로젝트 설명에 따르면 mutex나 spinlock 없이 원자성을 보장합니다. 대신 샤드 잠금을 잡고, 잠금이 유지되는 동안 같은 샤드의 다른 트랜잭션은 기다립니다. 작성자는 이 비용을 직접 측정하지 않았으므로 대규모 다중 키 명령이나 스크립트를 쓰는 환경에서 별도로 시험하라고 합니다.

클러스터 운영 방식도 다릅니다. Dragonfly Cluster는 Redis Cluster 클라이언트와 비슷한 방식으로 보이지만, Redis Cluster처럼 노드끼리 클러스터 상태를 찾아 관리하지 않습니다. 중앙 관리 방식이라 구성과 운영 절차가 다릅니다. 수십 개 노드 운영을 계획한다면 Redis Cluster가 더 긴 운영 이력을 갖고 있습니다. 검색이나 시계열 같은 고급 Redis 모듈에 의존한다면 기능별 호환성을 확인해야 합니다.

성숙도와 선택 기준

작성자는 Dragonfly 이슈와 릴리스 기록에서 복제, 지속성, Lua, 동시성 관련 버그를 확인합니다. 수정된 사례로 승격된 마스터에 구형 복제본이 다시 연결될 때의 충돌(#7491), 만료된 해시 필드와 HEXPIRE·HSETEX를 둘러싼 복제 불일치(#7948), 큰 문자열을 GET하는 Lua 스크립트의 충돌(#7934), 명령 병합 과정의 스레드 간 데이터 경쟁(#7927)을 듭니다. 또 v1.28.0에서 31GiB 데이터셋을 부하 시험하던 중 복제본의 BGSAVE 및 승격된 마스터의 전체 재동기화 과정에서 SIGSEGV가 났다는 미해결 사용자 보고도 소개합니다. 재현되지 않았다는 보고자의 설명도 함께 전합니다.

Redis에는 오랜 운영 경험과 넓은 생태계가 있습니다. AOF와 RDB 등 지속성 설정, 클라이언트와 모니터링 도구, 관리형 서비스, 팀의 익숙함도 장점입니다. 반면 Dragonfly는 CPU 부하가 크거나 멀티코어 장비를 활용하고 싶을 때, 메모리 비용이나 수직 확장이 중요할 때 평가할 만합니다. 스냅샷 기반 지속성으로 충분한지도 따져야 합니다. 글의 권고는 교체 자체가 아니라, 현재 시스템에서 확인한 병목을 기준으로 두 제품을 실제 워크로드에 나란히 시험하는 것입니다.

dev.to 반응

• @dhruv_malaviya — 처리량만큼 지연 시간의 예측 가능성도 다뤄야 합니다. Redis에서 느린 명령 하나가 모든 클라이언트를 막지만, Dragonfly에서는 한 샤드를 막습니다. 장애 양상이 다르며, 공유 캐시에서는 초당 연산 수보다 이 차이가 더 중요할 때가 많습니다. 호환성 비교에서 빠지기 쉬운 부분이 있습니다. 샤드 간 다중 키 명령, 트랜잭션, 블로킹 명령군은 의미가 모두 같지 않으니 GET/SET만 돌리지 말고 실제 명령 구성을 시험해야 합니다. 메모리 효율이 속도보다 더 강한 장점일 수도 있습니다. 반면 15년간 기록된 Redis 장애 사례는 3시에 장애가 나기 전까지 과소평가하기 쉽습니다.
  • @adamthedeveloper — Dragonfly가 그 격차를 따라잡으려면 빠르게 성장해야 합니다. Redis에는 문서화된 장애 사례가 약 1만 페이지나 있습니다. 신뢰를 얻기도 어렵습니다.
• @cubl9snp71hm — Redis를 오래 쓰면 익숙하지만, Dragonfly는 멀티스레드와 shared-nothing 구조로 모든 코어를 활용한다는 점이 흥미롭습니다. 수직 확장 시 Redis의 단일 스레드가 늘 골칫거리였으니까요. 실제로 읽기 중심 워크로드인 캐시 세션이나 요청 제한에서 같은 하드웨어로 Dragonfly 처리량이 2~3배 높고, KEYS나 FLUSHALL, 긴 Lua 스크립트에 막히지 않아 p99 지연 시간도 더 안정적이라는 벤치마크가 있습니다. 절충점은 Redis 생태계가 압도적으로 성숙한 반면 Dragonfly는 아직 어리다는 점입니다. 운영상 중요한 워크로드에는 Redis를 유지하고, 사이드 프로젝트나 새 서비스에는 하드웨어를 더 효율적으로 쓰도록 Dragonfly를 시험할 수 있습니다. 지금 가장 큰 부족함은 Redis Modules API 호환성입니다. RediSearch, RedisJSON, Bloom filter를 쓰는 팀은 사실상 마이그레이션이 불가능합니다. 읽기·쓰기·Pub/Sub 혼합 워크로드도 시험했나요? Redis의 단일 스레드 Pub/Sub도 규모가 커지면 병목이 자주 됩니다.
  • @adamthedeveloper — 읽어주셔서 감사합니다. p99 지연 시간과 느린 명령에 관한 지적이 좋습니다. Dragonfly 구조에서는 KEYS나 무거운 스크립트가 다른 작업을 막지 않는 점이 분명한 장점입니다. Modules API 격차에 대해서도 전적으로 동의합니다. RediSearch나 RedisJSON에 크게 의존하면 현재는 사실상 Redis에 묶입니다. 질문에 답하자면 Pub/Sub를 포함한 혼합 워크로드의 구조화된 벤치마크는 아직 실행하지 않았습니다. Redis Pub/Sub가 규모가 커질 때 흔히 겪는 문제라 후속 시험으로 고려하고 있습니다. 직접 Dragonfly의 Pub/Sub 동작을 시험해 보셨나요?

원문: dev.to / 번역·요약: Trawling