Valkey 1주년: 커뮤니티 포크가 Redis를 어떻게 추월했는가

• Redis Inc가 소스 폐쇄(SSPL 전환) 결정으로 커뮤니티 신뢰를 흔들었지만, Valkey 포크를 중심으로 개발자 커뮤니티가 결집해 활발한 혁신과 기여가 이어짐
• Redis 8.0은 다시 오픈소스로 돌아오고, 창시자 Antirez가 복귀해 새 기능과 최적화에 참여하는 등 양 진영 모두 빠른 발전을 보이고 있음
• 최신 벤치마크 결과, Valkey 8.1.1은 8vCPU 환경에서 SET 성능이 Redis 8.0 대비 37% 더 높고, p99 지연도 더 짧게 측정됨(GET 성능도 16% 우위)
• IO 스레드/코어 핀닝 등 실전 튜닝 기법으로, Valkey는 멀티스레딩 환경에서 3배 이상 처리량 상승과 지연 최소화를 실현
• 실사용 환경에 가까운 벤치마크 및 튜닝 노하우도 공유, 벤치마크 결과 해석시 유의점과 실제 운영 환경에서의 적용법도 안내

---

Redis 소스 폐쇄와 Valkey의 등장

• 1년 전 Redis Inc(구 Garantia Data)가 오픈소스 라이선스 변경(SSPL 도입)으로 커뮤니티와 신뢰관계가 악화됨
• 이에 대한 해결책으로 탄생한 오픈 포크 Valkey는 분산 시스템, 캐시, 실시간 데이터 처리 등에서 널리 사용되는 기술 자산이 됨
• Redis 측도 이후 Antirez(창시자) 복귀, 성능/기능 강화, Redis 8.0 오픈소스 재전환 등으로 신뢰 회복 시도

Valkey 8.1 vs Redis 8.0: 성능 비교

• 동일 8vCPU AWS c8g.2xl 인스턴스, 1KB 아이템/3M 키스페이스/500 커넥션 조건에서 SET 벤치마크
  • Valkey 8.1.1: 999.8K RPS(p99 0.8ms)
  • Redis 8.0: 729.4K RPS(p99 0.99ms)
  • Valkey가 SET에서 37%, GET에서 16% 더 높고, SET p99 30%, GET p99 60% 더 빠름
• 6개 IO 스레드 도입시, Valkey는 239K → 678K RPS(2.8배↑), p99 1.68ms → 0.93ms(44%↓)
• Redis도 IO 스레드로 235K → 563K RPS, p99 1.35ms → 0.84ms(40%↓)

멀티스레딩/코어 튜닝의 효과

• IO 스레드는 3개 이상부터 효과가 크게 나타나며, Valkey는 4스레드 이후 Redis보다 큰 격차
• IRQ(인터럽트) 코어를 2개로 제한 후, Redis/Valkey를 남은 6코어에 고정(pinning)하면 추가 성능상승
  • Valkey: 832K → 999.8K RPS(코어/IRQ 핀닝, CPU 80% 활용)
  • IRQ/애플리케이션 코어 분리로 캐시 효율과 tail latency 최소화
  • 실제 Docker로 cpuset-cpus, --io-threads 등 활용 예시 제공

벤치마크 재현과 실전 팁

• 최신 AWS Graviton4(c8g.2xlarge) 인스턴스, 클러스터 placement group 활용
• 코어 핀닝/IRQ 분리/연결수 조정(400~500 선)로 최대 성능 구현
• 키스페이스/아이템 크기도 튜닝 필요, 작은 값/키스페이스가 L3 캐시 적중률을 높임
• valkey-benchmark나 rpc-perf(실사용에 더 가까운 Rust 기반 툴) 등 멀티스레드 벤치마크 도구 적극 활용 권장

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

성능 측정의 한계와 유의점

• 벤치마크 결과는 실제 운영 환경과 다를 수 있음

  • 실제 워크로드는 SET:GET 혼합, 부하 변동, TPS 타깃, 네트워크 지연 등 복합 요인 존재
  • 연결수 급증 시 대기열 지연과 throughput 감소, tail latency 증가도 관찰됨
  • 벤치마크 툴/옵션, 네트워크 토폴로지 등에 따라 결과가 크게 달라질 수 있음

주요 성장과정 및 커뮤니티 발전

Valkey 프로젝트는 지난 1년간 다양한 측면에서 활발한 발전을 이룸

• GitHub 등지에서 많은 개발자와 기업의 협업 하에 기능 추가, 버그 수정, 보안 개선 등을 이룸
• 문서화와 사용자 지원에도 힘써 신규 사용자 진입 장벽을 낮춤
• 프로젝트 운영 과정에서 투명한 의사결정과 커뮤니티 투표 등이 강조됨

업계와 기술적 가치

Valkey는 다음과 같은 강점을 지님

• 라이선스 제약 없이 누구나 사용할 수 있어 클라우드 서비스 벤더나 대규모 웹 서비스 기업들에게 매력적인 선택지임
• Redis와 호환성이 높아 마이그레이션도 용이함
• 커뮤니티 주도 개발이어서 다양한 요구사항 반영과 빠른 지속적 업데이트가 가능함

결론 및 시사점

• Valkey는 Redis 포크 1년만에 기술/성능/커뮤니티 측면에서 Redis를 뛰어넘는 성과를 보임
• IO 스레드, 코어/IRQ 분리, 커넥션 조절 등 실전 튜닝 노하우와 도구가 핵심
• 성능은 자동으로 따라오는 것이 아니며, 시스템/워크로드/인프라에 맞는 지속적인 최적화가 필수
• 실제 서비스 환경에서는 벤치마크 수치에만 의존하지 않고 다양한 상황을 직접 테스트하는 실무적 접근이 필요

[ethanhur]

Redis가 잘못된 결정을 많이 내리긴 했지만, 재주는 곰이 부리고 돈은 조련사가 받는 모양새는 아쉽네요.

[kgcrom]

페이스북 "Redis User Group"에 올린
Valkey 8에 어떤 개선이 이뤄졌는지 정리한 자료입니다.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

위 내용과 함께 보시면 이해하는데 도움이 될듯합니다.

[ndrgrd]

사실 Valkey가 뭘 했다기 보다는... 저 쪽에서 알아서 망해서...

[GN⁺]

Hacker News 의견

• 나는 ValKey가 I/O 쓰레딩 분야에서 멋진 발전을 이루어낸 점이 기쁨 느낌, 최근에 가장 흥미로운 변경 사항들도 도입하기 시작함, ValKey 기여자분들께 큰 감사 인사 드림. 하지만 이 글이 다소 오해를 불러일으키는 경향을 가진다고 생각함. 원래 Redis에서 shared nothing 아키텍처는 매우 중요한 철학이었고, 2020년에 내가 직접 I/O 쓰레딩을 도입한 장본인임. Shared nothing의 취지를 해치지 않으면서, event loop에서 반환할 때 write(2)/read(2) syscall이 굉장히 느릴 수 있다는 점을 감안해 해당 시점에 zero contention 상태에서 I/O만 N개의 쓰레드로 병렬 처리하고 이후 바로 싱글 쓰레드로 돌아오는 구조를 도입함. ValKey 팀은 이 시스템을 더 발전시켰음에 감사함을 전함. 예전부터 해당 시스템이 작동하고 있었고, 현실적으로 바뀌지 않은 데이터를 단지 언론이 과장하는 경향이 불편함. 이러한 기능들은 실제로는 대다수 일반 Redis 유저보다는 기업 사용자나 클라우드 제공자(아마존, 구글 등)에게 더욱 관심이 있음. 엄청난 부하나 다수의 유저를 동시에 처리할 수밖에 없는 경우 아니면, 대부분 Redis의 CPU 사용률이 낮아서 굳이 활성화할 필요가 없는 현실임. 최근 Redis에서 vector set data type(벡터 집합 자료형)을 개발하면서 쓰레딩을 기본값으로 삼고 있고, VADD를 통한 벡터 집합 기록도 쓰레드 방식으로 할 수 있게 함. HNSW 같은 데이터 구조는 Redis 역사상 최초로 거대한 상수 시간을 가져서 설계 영역 자체가 달라짐. 과거에는 모듈용 쓰레드 지원도 이미 구현한 바 있음. 쓰레드 사용 여부는 상황에 따라 달라지는 결정임.
  • 미묘한 관점은 클릭을 못 끄는 사실을 언급함
  • 이런 류의 비판 글이 매달 HN 메인에 오르는 느낌 받음, 항상 antirez를 응원하고 싶었음. 기술적 요지는 동의하지만, 이런 비판이 종종 구체적인 내용보다는 큰 성공을 이룬 사람을 공격하는 고전적인 tall poppy syndrome(톨 파피 신드롬, 성공자를 깎아내리는 현상)과 관련 있다고 봄. 타인의 반응을 통제할 수 없으니 이런 비판글을 당신의 업적이 크다는 우회적 인정으로 여기면 더 건강할 수 있겠다는 의견 제시, LinkedIn에서 연결된 것도 감사하게 생각함 톨 파피 신드롬 보기
• antirez가 Redis를 다시 오픈소스로 전환한다고 발표했던 것 기억함 관련 글 예전 Node.js가 Io.js 포크 사태로 거의 무너질 뻔했지만 커뮤니티가 복구한 전례가 있음. Redis도 그런 회복이 가능할지 궁금함. 예전에는 Redis를 자주 썼지만 최근 몇년간은 커뮤니티 동향을 잘 모름
  • 마지막으로 확인했을 때 Redis는 여전히 CLA(기여자 라이선스 동의서)를 요구함. 이는 언제든지 다시 소스를 닫을 독점적 권리가 있음을 의미함. 기여자가 이런 조항에 동의해야 한다면, 또다시 같은 일을 벌이지 않을 거라고 신뢰할 이유가 없음
  • Redis는 AGPL로, Valkey는 BSD 라이선스(BSD가 예전 Redis 라이선스)로 배포되고 있음. 둘 다 공식 오픈소스 라이선스이나 BSD가 훨씬 더 자유로움
  • 솔직히 이용자 99%는 누가 소유하든 간에 무료 키-밸류 저장소만 제대로 굴러가면 신경 안 씀. 비즈니스 입장에서 Redis가 독특한 위치에 있는데, 엄청 많은 기능을 제공하지만 실사용자는 5%만 쓴다는 점, Sentinel/Streams 같은 복잡한 기능엔 관심도 없음. 유료화하려고 할 때 사용자 선택지는 "그냥 안 쓰기", "경쟁사로 옮기기", "직접 꼭 필요한 기능만 만들어 쓰기", "마지막 오픈소스 버전을 포크해서 자체 유지보수하며 비용 아끼기" 등 다양함. PostgreSQL에 비해 Redis의 단순한 버전(해시맵+네트워크 인터페이스)은 직접 만들어 쓰기 쉽고, 그래서 많은 비즈니스에선 포크하거나 직접 만드는 게 더 나은 선택임
  • 내 생각에도 이미 늦은 감이 큼. Redis의 급격한 정책 전환으로 내겐 Redis는 이제 불신 대상이고, 앞으로는 Valkey가 기본 선택지임. 한번 속으면 두 번 안 믿는 태도 유지
  • Redis가 벌인 상황 이후로 어떻게 신뢰할 수 있냐는 의문 제시
• Valkey가 기본 배포판 패키지 매니저에 들어가야 한다고 생각함. 예를 들어 GitHub Action runner에서 설치하려고 할 때 매번 키 추가하고 배포판 업데이트하는 게 번거롭다는 불만 있음
  • 어떤 배포판에 없는 게 문제인가 궁금함. repology 자료로 보건대 nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL 등에 이미 있음. 다만 Debian은 13 혹은 12+backports부터임
  • 참고로 Arch Linux에선 Valkey가 Redis를 이미 대체함
  • CI에서 컨테이너 이미지를 받자마자 이것저것 설치하는 게 첫 작업이면, 직접 이미지를 만드는 게 더 낫다는 의견 제시
• 이런 변화가 일어나고, Valkey가 꾸준히 잘 나가는 상황이 매우 반가운 느낌. 부디 Redis는 곧 사라지길 바람
  • 오픈소스가 독점 기업을 위한 것이라는 풍자적 어투, AWS 같은 하이퍼스케일러들이 Redis로 수억 달러를 벌고 있지만 실제 개발자와 기여자는 그 혜택을 받지 못한다는 아쉬움 표명. 그래서 DB 스타트업은 처음부터 페어 소스(anti-hyperscaler 조항이 들어간 라이선스)로 출발해야, 코드 자체는 누구든 마음껏 쓰더라도 AWS나 Google이 관리형 상품(Managed Service)으로 내놓으려면 비용을 내게 해야 함. 이미 uber permissive 라이선스로 출발한 Redis와 Elasticsearch는 돌이키기 힘든 운명임을 언급
• 최근 dotnet 프로젝트들이 상용화로 전환하는 경우 많아짐. 이런 변화가 개발자들에겐 마치 러그 풀(신뢰를 깨는 갑작스러운 정책 변신)로 느껴짐. 이런 분위기는 다른 오픈소스 dotnet 라이브러리의 확산에도 타격을 줄 가능성 있음
  • .NET에서는 이런 상업화 경향이 최근 일도 아니고, 원래 freeware/open-core와 비즈니스가 항상 붙어다니는 성향이라고 언급함
• 작년부터 Valkey를 들었는데, 여전히 잘 나가고 있다는 점이 기쁨
• Valkey가 자체 클라이언트 라이브러리를 제공하는지 궁금함. 현재 GCP 환경에서 MemoryStore와 직접 관리 환경 양쪽에서 Redis/Redis Cluster 모두 사용, 공식 C 라이브러리는 Redis Cluster+TLS를 쓸 때 실망스러워서 hiredis-cluster라는 비공식 클라이언트(https://github.com/Nordix/hiredis-cluster)를 써야 하는 상황. GCP의 Memorystore도 별로 만족못함. Scylla로 이전 고려중
  • hiredis와 hiredis-cluster를 조합한 libvalkey라는 공식 포크가 있음, 기존 hiredis/hiredis-cluster 유지보수자들이 관리 중 libvalkey 보기
• Redis가 정책을 바꾼 지금, Valkey와 Redis가 대화해서 합칠 수 있는지 궁금함
  • 라이선스가 원상 복귀한 것이 아니라 AGPL로 옮긴 것이기 때문에 진짜 유턴이 아님을 지적함
• 예상되는 GPL 관련 FUD(공포·불확실성·의심)에 대한 훌륭한 설명글 링크 공유 관련 글
  • 게시글에서 copyleft 라이선스가 더 자유롭다는 주장은 다소 손쉬운 논리라고 봄. 의무가 많아질수록 자유가 줄어드는 성격이 있으므로, 어떤 스타일이 더 '자유로운지' 논의는 보다 깊이 있다고 생각함
• 나는 수십 개 애플리케이션에서 Redis를 사용함. AWS에서 Valkey를 할인 가격에 제공한다 해서 2개월 전부터 써봤고, 성능의 차이도 느끼지 못함. 그런데 Valkey가 느닷없이 먹통이 되었고, AWS에선 여전히 구동 중으로 인식했지만 접속이 완전히 끊김. 12시간이 넘도록 복구되지 않았고, 또 재발했음. AWS가 2주 동안 조사했지만 원인을 못 찾았음. 앞으로 Valkey를 미션크리티컬 환경에 쓰기는 힘들게 되었음. 이후 동일한 워크로드로 Redis로 교체했더니 문제 없음
  • 아마 AWS 이슈일 수 있다는 생각. 우리도 프로덕션 RDS postgres 클러스터에서 비슷한 경험이 있었음. 네트워크 반응이 멈췄고, AWS 엔터프라이즈 지원을 받았지만 결국 스스로Backup 복구로 새 클러스터 생성, 4시간 걸림. 이후 AWS encapsulated 서비스는 피하고 일반 EC2에 replication, 스냅샷, S3복제 등으로 이전함
  • AWS 운영상의 문제 가능성도 있음, Redis만 직접 돌려봤지만 Valkey 자체 문제가 아닐 수도 있음
  • 왜 직접 Valkey 인스턴스를 띄우지 않는지 궁금함
  • 사용한 인스턴스 타입이 어떤 것인지 궁금, 참고용 질문