본문으로 건너뛰기
0
r/jeffnews HN 약 4분

ForgeKV — Rust로 만든 멀티코어 Redis 대체제

backend

요약

Rust로 만든 Redis 드롭인 대체제. 64-샤드 잠금 아키텍처로 멀티코어 스케일링 지원. 2코어 환경에서 Redis 7 대비 41% 빠른 SET 처리량(158K ops/s). 고동시성에서는 약점 있음. Source-available 라이선스.

기사 전체 정리

ForgeKV — Rust로 만든 멀티코어 Redis 대체제

Redis의 고질적 한계인 싱글스레드 구조를 Rust로 해결하겠다는 프로젝트임. Redis 프로토콜(RESP2)을 완전히 지원해서 기존 Redis 클라이언트를 그대로 쓸 수 있는 드롭인 대체제를 표방함.

아키텍처: 64-샤드 잠금 구조

  • 핵심 설계는 64개 샤드 잠금 아키텍처임. 각 샤드가 자체 WAL(Write-Ahead Log), memtable, RwLock을 가짐
  • 동시 쓰기가 같은 샤드에 해시되지 않는 한 서로 블로킹하지 않음 → 코어 수에 비례해서 처리량이 올라감
  • Redis 키를 인식해서 샤딩하기 때문에, 같은 Redis 키의 메타데이터와 실제 데이터가 항상 같은 샤드에 들어감
  • put2 명령으로 SET 시 메타+데이터를 한 번의 WAL 잠금으로 처리해서 라운드트립을 줄임

벤치마크 결과

memtier_benchmark 기준, pipeline=16, 64바이트 값 기준 SET 처리량:

  • 스위트 스팟 (t=2, c=20, 40개 연결): ForgeKV 158K ops/s vs Redis 7 112K vs Dragonfly 45K
    • Redis 7 대비 41% 빠름, Dragonfly 대비 3.5배
  • 레이턴시도 우수: 같은 조건에서 ForgeKV 0.367ms vs Redis 0.546ms vs Dragonfly 1.273ms
  • 싱글스레드(t=1)에선 Redis가 약간 앞서는데, 코어를 추가하면 ForgeKV가 올라가고 Redis는 정체되는 패턴

약점도 명확함:

  • 고동시성 환경 **(t=4, c=50, 200개 연결)**에서는 ForgeKV가 59K로 떨어지고 Redis가 82K, Dragonfly가 95K로 역전됨
  • 이건 WAL 그룹 커밋 최적화로 개선 예정이라고 함

Redis 호환성

지원하는 명령어 범위가 상당히 넓음:

  • Strings, Keys, Hashes, Lists, Sets, Sorted Sets 등 기본 자료구조 전부
  • HyperLogLog, Geo, Bitmaps, Pub/Sub, Streams까지 지원
  • 트랜잭션(MULTI/EXEC), 스크립팅(EVAL/EVALSHA)도 됨
  • JSON, Bloom Filter 모듈과 RedisSearch 스텁까지 포함

블로킹 커맨드(BLPOP, BRPOP 등)는 Tokio broadcast 채널로 구현함.

라이선스 주의

  • Source-available 라이선스임. 완전한 오픈소스가 아님
  • 평가 및 비상업적 사용은 무료, 상업적 사용이나 SaaS 형태 재배포는 별도 상업 라이선스 필요
  • forgekv.com에서 라이선스 문의 가능

정리

2코어 정도의 환경에서 Redis를 대체할 만한 성능을 보여주고, 호환성도 꽤 탄탄함. 다만 고동시성 환경의 성능 하락과 source-available 라이선스는 도입 전에 반드시 따져봐야 할 부분임. "Redis가 싱글스레드라서 답답했던" 유스케이스가 있다면 한번 테스트해볼 만함.

핵심 포인트

  • 64-샤드 잠금 아키텍처(각 샤드별 WAL, memtable, RwLock)
  • t=2 c=20 기준 158K SET/s — Redis 7 대비 41% 빠름, Dragonfly 대비 3.5배
  • 고동시성(200 연결)에서는 Redis에 역전당하는 약점
  • RESP2 완전 지원, source-available 라이선스(상업용은 별도 라이선스 필요)

인사이트

Redis의 싱글스레드 한계를 정면으로 공략하는 접근. 2-4코어 환경의 성능은 인상적이나, 고동시성 약점과 비오픈소스 라이선스가 프로덕션 도입 시 주요 검토 포인트.

댓글

댓글

댓글을 불러오는 중...

backend

Redis 8.0 출시 — I/O 스레딩 갈아엎고 처리량 3배, 2.1M ops/sec 달성

Redis 8.0이 I/O 스레딩 모델을 완전히 재설계해서 16코어 기준 2.1M ops/sec를 달성함 (7.4 대비 3배). Hash field expiration, Vector search HNSW, Client-side caching v2, Redis Functions 2.0 async 실행 등 굵직한 기능이 추가되고, jemalloc 통합으로 메모리 fragmentation도 25% 줄어듦.

backend

Go 1.26의 타입 생성(Type Construction)과 순환 감지(Cycle Detection) 개선

Go 1.26에서 타입 체커의 타입 생성 알고리즘을 개선해 재귀 타입과 배열 크기 계산 시 발생하던 순환 감지 문제를 체계적으로 해결했다. 불완전한 값이 다운스트림으로 퍼지기 전에 업스트림에서 차단하는 새로운 접근법으로 여러 컴파일러 패닉을 수정.

backend

Cloudflare Gen 13 서버: 캐시를 코어로 바꿔 성능 2배 달성한 이야기

Cloudflare가 AMD Turin 9965(192코어) 기반 Gen 13 서버를 배포함. 코어당 L3 캐시가 6배 줄어 레거시 NGINX 스택(FL1)으로는 레이턴시 50% 악화가 불가피했으나, Rust로 전면 재작성한 FL2로 전환해 Gen 12 대비 처리량 2배, 성능/와트 50% 개선을 달성함.

backend

칩셋 레이턴시를 측정해봤더니 — 쓸모는 없지만 재밌는 실험

Vulkan GPU 벤치마크로 여러 세대 마더보드 칩셋의 PCIe 레이턴시를 측정한 실험. CPU 직결 대비 칩셋 경유 시 수백 ns 레이턴시가 추가되며, 의외로 2012년 Skylake Z170이 가장 낮은 추가 레이턴시를 보임.

backend

AI 바이브 코딩에 Go를 쓰는 이유 — Rust도 Python도 아닌

AI가 코드의 90%를 쓰는 바이브 코딩 시대에 Go가 최적의 언어라는 주장. Python은 안전장치가 없고, Rust는 언어 자체의 문제까지 인간에게 떠넘기지만, Go는 중요한 것만 잡고 비켜준다는 논리. 실제로 한 세션에 3도메인 풀스택 블로그를 7커밋으로 완성한 사례 제시.