Ops Insights – Valkey

2,000노드 Valkey — 무엇이 먼저 부러지는가

Thu, 06 Aug 2026 00:00:00 +0000

01 · 2,000노드 Valkey — 무엇이 먼저 부러지고, 그중 무엇이 Kubernetes로 넘어오는가

간판 수치는 Kubernetes에서 잰 게 아닙니다. 2,000노드·1B RPS의 서면판인 valkey.io 블로그 원문에 Kubernetes·pod·StatefulSet·container가 한 번도 나오지 않고, 실험대는 r7g.2xlarge(8코어/64GB) 클러스터 + 부하 생성기 c7g.16xlarge 750대였습니다. 발표 시작 13초에 본인들이 “we come from Amazon, which is mostly a VM based world“라고 밝힙니다.
그래도 엔진 수정 4건은 인프라와 무관하게 넘어옵니다. #654·#1018·#2154·#2277은 배포 방식이 아니라 cluster bus 코드 안에 들어갔습니다. 버전만 맞추면 됩니다. 각각 8.0 / 8.1 / 9.0 / 9.0.
CPU 100% 그래프를 클러스터 전체로 읽으면 틀립니다. 슬라이드에서 천장에 붙는 계열은 engine_cpu_percent_p99고 같은 차트의 p90·avg는 한 자릿수입니다(스냅샷 p90 6.2 / avg 5.80). 발표자 노트는 포화 범위를 “atleast 5% of the nodes”(오타는 원문 그대로)라 적습니다. 하한이지 점추정이 아닙니다. 2,000노드가 전부 탄 게 아니라 최소 100대가 탔다는 뜻이고, 발표는 이 구분을 하지 않습니다.
Kubernetes 조언 중 실측이 뒷받침하는 건 사실상 하나입니다. CPU limit을 걸지 마라. 나머지(StatefulSet, headless service 부트스트랩, IP 직결, AZ 분산)는 전부 경험칙이고 발표에 수치가 붙지 않습니다.
operator는 아직 도입 대상이 아닙니다. API가 v1alpha1이고 README가 “not ready for production use"라고 명시하며 scale-out/in에 Valkey 9.0+를 요구합니다. 그런데 spec.shards는 진짜 최상위 필드라 Q&A의 “shard가 first-class” 주장 자체는 맞습니다.
2,000노드에서 먼저 부러지는 건 처리량이 아니라 장애 복구입니다. 정상 상태 gossip 비용은 노드 수에 선형이었고, 터진 곳은 전부 primary를 수백 개씩 한 번에 죽였을 때의 재접속(415~455 kill)·failure report(499 kill)·투표 경로였습니다.

왜 이 문서인가. 발표 제목은 Kubernetes at XL Scale인데 간판 수치인 2,000노드 / 1B RPS는 EC2에서 나왔습니다. 그래서 이 문서는 발표가 증명한 것(엔진 한계와 그 수정)과 조언에 그친 것(Kubernetes 배치·리소스)을 나눠 놓고, 그중 무엇이 Kubernetes로 전이되는지만 남깁니다. 검증 기준은 발표 전사(942줄), 발표자 노트가 붙은 슬라이드 원본 54장, valkey.io 블로그, 업스트림 PR 4건, valkey.conf unstable 브랜치입니다.

Redis 581샤드를 무중단으로 Kubernetes에 올리기

Thu, 06 Aug 2026 00:00:00 +0000

01 · Redis 581샤드를 무중단으로 Kubernetes에 올리기 — 그리고 90%라는 숫자의 진실

한눈에

부록 · 발표 전사 — Braze Redis→Valkey

Thu, 06 Aug 2026 00:00:00 +0000

02 · 발표 전사 — Redis on EC2 to Valkey on Kubernetes: A Zero-Downtime Case Study

이 문서는 KubeCon + CloudNativeCon Europe 2026 발표 Redis on EC2 to Valkey on Kubernetes: A Zero-Downtime Case Study(Joe Heyburn, Braze)의 전사 정리본입니다. YouTube 자동 자막(타임스탬프 714줄)을 원본으로 삼되 발표자 본인의 슬라이드 덱과 대조해 오인식을 교정했습니다 — Joe Hayburn/Joe Haben→Joe Heyburn(핸들 @jdheyburn), “psychic shard”→Sidekiq shard, “a free phase approach”→three-phase approach, “no network load balancer”→an NLB, “at Redis, we use AZ affinity”→at Braze, “31,000”→nodePort 31000, “custom resharding”→Cluster resharding.

부록 · 발표 전사 — Scaling Valkey

Thu, 06 Aug 2026 00:00:00 +0000

02 · 발표 전사 — Scaling Valkey the Right Way: Kubernetes at XL Scale

이 문서는 KubeCon + CloudNativeCon Europe 2026 발표 Scaling Valkey the Right Way: Kubernetes at XL Scale(Sarthak Aggarwal · Madelyn Olson, AWS ElastiCache)의 전사 정리본입니다. YouTube 자동 자막(타임스탬프 942줄)을 원본으로 삼되 발표자 본인의 슬라이드 덱과 대조해 오인식을 교정했습니다. Valkyrie→Valkey, Madeline/Merlin/Marlin→Madelyn, “as a stateless set”→StatefulSet, “something like that, CD”→etcd, “16,000 슬롯”→16384, “REST protocol”→RESP, “Bin Bin”→Binbin.

두 갈래 — 같은 방, 15분 간격, 정반대 아키텍처

Thu, 06 Aug 2026 00:00:00 +0000

두 갈래 — 같은 방, 15분 간격, 정반대 아키텍처

두 발표가 말하는 “Valkey 스케일링"은 같은 물건이 아닙니다. ①은 슬롯 16384개를 서버가 나눠 갖는 단일 클러스터 1개, ②는 서로를 모르는 Sentinel HA 샤드 581개입니다. 샤딩을 누가 하느냐부터 다릅니다 — 서버냐 클라이언트냐.
Kubernetes 프로덕션 증거는 ②에만 있습니다. ①의 간판 수치 2,000노드 / 1B RPS는 EC2에서 taskset·ethtool로 손튜닝한 벤치마크고 ②의 36M ops/sec · 6.6TiB는 2년째 돌아가는 클러스터의 실측입니다.
그래서 나누는 방식은 하나입니다 — 엔진 사실은 ①에서, 운영 사실은 ②에서 가져옵니다. 반대로 섞으면 둘 다 틀린 근거가 됩니다.
Braze가 cluster mode를 피한 이유를 발표는 말하지 않습니다. 확인되는 건 Redis 시절 클라이언트 해싱을 그대로 물려받았다는 것뿐이고 “blast radius 격리 때문"은 이 문서의 추론입니다. 아래에서 구분해 적습니다.
우리가 먼저 만나는 문제는 ②의 것입니다. 2,000노드 천장은 대부분에게 오지 않지만 파드가 롤될 때 IP가 바뀌는 문제는 첫 배포 다음 날 옵니다.
둘이 합의하는 것도 있습니다 — AZ affinity는 지연과 비용 양쪽에 걸리고 valkey-operator는 같은 미래이며 오늘은 아직 아닙니다.

왜 이 문서인가. KubeCon EU 2026 Hall 8 | Room E에서 두 발표가 15분 간격으로 이어졌습니다. 둘 다 “Valkey를 크게 굴리는 법"을 말했지만 거의 모든 지점에서 어긋납니다. 이 문서는 그 어긋남을 정리해 어느 질문에 어느 챕터를 펴야 하는지만 정합니다. 두 챕터를 요약하지 않습니다 — 요약은 각 챕터가 합니다.