본문으로 건너뛰기
Valkey
00 두 갈래

두 갈래 — 같은 방, 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를 크게 굴리는 법"을 말했지만 거의 모든 지점에서 어긋납니다. 이 문서는 그 어긋남을 정리해 어느 질문에 어느 챕터를 펴야 하는지만 정합니다. 두 챕터를 요약하지 않습니다 — 요약은 각 챕터가 합니다.

출처: KubeCon + CloudNativeCon Europe 2026, 2026-03-26(목), Hall 8 | Room E — 11:00–11:30 Scaling Valkey the Right Way: Kubernetes at XL Scale(Sarthak Aggarwal · Madelyn Olson, AWS ElastiCache), 11:45–12:15 Redis on EC2 to Valkey on Kubernetes: A Zero-Downtime Case Study(Joe Heyburn, Braze).

챕터: ① 2,000노드 Valkey 클러스터 · ② Braze Sentinel HA 무중단 이관

1. 두 발표가 말하는 Valkey는 같은 물건이 아니다

같은 방, 같은 오전, 같은 제품 이름. 그런데 무대에 오른 아키텍처는 공통점이 거의 없습니다.

축① AWS · Valkey Cluster② Braze · Sentinel HA
토폴로지클러스터 1개에 노드 2,000대독립 HA 샤드 581개 — 서로의 존재를 모른다
샤딩 주체서버 — 슬롯 16384개를 노드가 나눠 소유클라이언트 — 애플리케이션에 박힌 해싱 로직
장애 감지cluster bus gossip, cluster-node-timeout 기본 15000msSentinel quorum — 샤드마다 Sentinel 3대
확장 축슬롯을 옮겨 샤드를 늘린다(9.0 atomic slot migration)샤드를 통째로 하나 더 만든다
근거의 성격EC2 벤치마크 — r7g.2xlarge 클러스터, 부하 생성기 c7g.16xlarge 750대Kubernetes 프로덕션 2년 — 2023-02~2024-05 이관 후 계속 운영
규모1B RPS — 실험에서 잰 값36M ops/sec · 6.6TiB — 매일 나오는 값
운영 주체AWS ElastiCache 팀Braze 인메모리 DB 팀

가장 자주 섞이는 행은 두 번째입니다. Braze는 Valkey Cluster를 쓰지 않습니다. 발표자가 직접 말합니다 — “clients connect to Sentinel, and the clients decide what shard they need to write to based on their own hashing logic, which is baked into the client side”(04:55–05:34). 그러니 ②를 읽으면서 슬롯·MOVED 리다이렉트·cluster bus를 떠올리면 전부 헛다립니다. 거꾸로 ①의 재접속 폭풍이나 투표 분열도 Sentinel 쪽에 그대로 대응되는 현상이 아닙니다.

2. 왜 Braze는 cluster mode를 쓰지 않는가

여기서는 발표자가 말한 것과 이 문서가 덧댄 추론을 나눠서 적습니다.

층위내용
발표자가 말한 것샤딩은 클라이언트 해싱이 한다(04:55–05:34). 레거시 EC2 시절에도 같은 구조였고 Chef가 관리했다. 이관 원칙은 “re-platforming할 땐 플랫폼 말고는 아무것도 안 바뀌어야 한다”(15:19)였다
발표자가 말하지 않은 것cluster mode를 검토했는지, 검토했다면 왜 접었는지. 발표 어디에도 그 정당화가 없다
이 문서의 추론581개가 독립이므로 장애·gossip·투표가 샤드 밖으로 번지지 않는다. 이관을 샤드 단위로 쪼갤 수 있었던 것도 같은 성질에서 나온다. 발표자가 그렇게 주장한 적은 없다

정당화가 없다는 사실 자체가 정보입니다. Braze는 고른 게 아니라 물려받았습니다. 물려받은 구조가 Kubernetes 이관을 견딜 만했으니 바꾸지 않았다고 읽는 편이 근거에 가깝습니다.

그러면 실제 거래는 무엇입니까. 둘은 같은 문제를 정반대편에서 풉니다.

항목Valkey Cluster mode독립 Sentinel HA 샤드
재샤딩서버가 슬롯 단위로 수행 — 9.0부터 원자적없다. 클라이언트 해싱 로직을 바꾸려면 모든 클라이언트를 다시 배포한다
토폴로지 발견CLUSTER SHARDS로 클라이언트가 조회Sentinel에 물어본다. 단 샤드 목록 자체는 클라이언트 설정
장애 폭발 반경클러스터 전체가 공유 — gossip·투표가 전 노드에 걸린다샤드 1개로 격리
장애 모델full-mesh 링크 1,999,000개, 투표 분열 같은 창발 현상샤드마다 Sentinel 3대 quorum — 손으로 따라갈 수 있다
클라이언트 부담리다이렉트만 처리하면 된다해싱 로직이 모든 클라이언트 안에 박힌다

cluster mode는 서버 쪽 재샤딩과 토폴로지 발견을 사고 독립 HA 샤드는 격리와 단순한 장애 모델을 삽니다. 후자의 청구서는 샤딩이 애플리케이션 코드로 밀려 들어간다는 점입니다. 이건 되돌리기 가장 어려운 종류의 결합입니다.

3. 어느 쪽 근거가 우리 상황에 유효한가

이 문서에서 실무에 가장 가까운 절입니다.

①의 수치는 맨 EC2에서 나왔습니다. 서면판인 valkey.io 블로그에는 Kubernetes·EKS·pod·StatefulSet·container가 한 번도 나오지 않습니다. 튜닝은 taskset·cset 코어 피닝과 ethtool NIC 인터럽트 어피니티로 손으로 잡았습니다. Kubernetes 위에서는 하기 까다롭거나 아예 안 하는 것들입니다. ②의 수치는 반대로 전부 Kubernetes에서 나왔습니다. 581샤드가 파드로 돌고 Sentinel이 파드마다 사이드카 컨테이너로 붙어 있습니다.

그래서 Kubernetes를 쓰는 팀이 두 발표를 읽는 방법은 하나입니다 — 엔진 사실은 ①에서, 운영 사실은 ②에서 가져옵니다.

우리가 묻는 것어느 챕터근거의 성격
엔진이 몇 노드까지 버티나①2,000노드까지 실제로 밀어본 유일한 근거
cluster bus 비용이 어디서 먼저 터지나①재접속 폭풍·failure report·투표 분열 실측
CPU limit을 걸어야 하나①“걸지 마라” — 단 실측이 아니라 경험칙이다
Sentinel을 Kubernetes에 어떻게 얹나②파드별 Service로 고정 ClusterIP, init 컨테이너가 자기를 announce
무중단으로 EC2에서 옮기려면②NLB 경유 양방향 replication 3단계
이관 중 split brain을 어떻게 막나②Sentinel 7대 · quorum 5로 절대 과반 강제
Redis에서 Valkey로 갈아타는 비용②이미지 두 줄 + _helpers.tpl 함수 하나, 350샤드 6주
operator를 지금 도입할까①·②같은 판정 — 아직 아님

4. 두 발표가 합의하는 것

어긋나는 지점이 많은 만큼 겹치는 지점은 그만큼 무겁게 읽어야 합니다.

  • AZ affinity는 지연과 비용 양쪽에 걸립니다. ①은 클라이언트가 같은 AZ의 replica를 읽게 하라고 말합니다. valkey.io 측정은 800µs → 300µs, cross-AZ 전송비 월 $3,285 → ~$0을 제시합니다. ②는 같은 원칙을 failover에 적용합니다 — 승격 대상을 나가는 EC2 primary와 같은 AZ의 파드로 고릅니다(15:51–15:58). AWS 공식 blog 기준 cross-AZ는 방향당 $0.01/GB입니다.
  • 규모에서 부러지는 건 처리량이 아니라 토폴로지가 흔들리는 순간입니다. ①은 primary 수백 개를 한꺼번에 죽였을 때 벌어지는 재접속 폭풍을 실측하고 valkey-io/valkey#2154로 스로틀링을 넣었습니다. ②는 파드가 롤될 때마다 IP가 바뀌어 Sentinel에 stale replica가 쌓이는 문제를 만났습니다. 기전은 다르지만 둘 다 변화의 순간에 터집니다.
  • valkey-operator는 공통의 미래이자 공통의 유보입니다. 둘 다 valkey-io/valkey-operator를 지목하는데 README는 “not ready for production use"라고 명시하고 API는 v1alpha1입니다. ①이 기대하는 건 shard가 최상위 필드가 되는 것이고 ②가 기다리는 건 슬라이드 31의 Cells 모드 — 바로 Braze가 오늘 돌리는 토폴로지입니다.
  • ①이 권한 helm chart의 메인테이너가 ②의 발표자입니다. ①은 standalone 배포에 valkey-io/valkey-helm을 쓰라고 말하는데 그 차트 메인테이너 4명 중 하나가 jdheyburn, 즉 Joe Heyburn입니다.
  • ①의 발표자들이 ②로 직접 넘깁니다. “Joe will also talk about in the next talk”(07:18), “Valkey operator is something that Joe will talk about just after this”(26:12). 그런데 실제 ②는 operator 세션이 아니라 이관 사례 발표입니다. operator는 마지막 1분 남짓에만 나옵니다.

5. 우리라면 어느 쪽인가

판정: 대부분의 팀에게 ①의 천장은 오지 않습니다. ②의 문제는 첫 주에 옵니다.

2,000노드는 발표자 본인이 “You shouldn’t run a 2000 node Valkey cluster, but you might have to"로 열 만큼 예외적인 규모입니다. ②가 다루는 것들 — 파드 롤마다 바뀌는 IP, 토폴로지가 바뀌는 동안 열리는 split brain 창, 클라이언트에 박힌 해싱 — 은 Kubernetes에 stateful 캐시를 올리는 순간 전부 등장합니다. ①은 한계를 알려주는 문서고 ②는 다음 주에 펴는 문서입니다.

그렇다고 “무조건 Sentinel"이 답은 아닙니다. 판단 축은 이쪽입니다.

상황권장이유
샤드 수가 자주 바뀐다cluster mode클라이언트 재배포 없이 슬롯을 옮길 수 있는 유일한 길
클라이언트 언어·팀이 여럿이다cluster mode해싱 로직을 N개 언어에 복제하고 동기화하는 건 지는 싸움이다
샤드 단위 격리가 최우선이다독립 HA 샤드한 샤드의 장애가 나머지 580개를 건드리지 않는다
이미 클라이언트 해싱을 쓰고 있다독립 HA 샤드②가 증명한 건 “그대로 두고도 Kubernetes로 갈 수 있다"이다
샤드가 수백 개로 늘고 계속 는다재검토독립 HA 샤드는 샤드 수만큼 Sentinel 세트와 운영 표면이 같이 는다

답을 뒤집는 조건도 있습니다. valkey-operator가 production-ready가 되고 Cells 모드가 들어오면 “Sentinel을 직접 얹는 비용"이 크게 떨어져 독립 HA 샤드 쪽이 유리해집니다. 클라이언트가 이미 여러 언어로 나뉘어 있다면 해싱 로직 동기화 비용이 격리 이득을 먼저 잡아먹습니다.

이 문서가 확인하지 못한 것도 있습니다. Braze가 cluster mode를 실제로 검토했는지, 검토했다면 어떤 근거로 접었는지는 발표·슬라이드·발표자 공개 글 어디에도 없습니다. 2절의 “격리 때문"은 구조에서 끌어낸 추론이지 발표자의 주장이 아닙니다.

6. 출처

발표 ① — AWS · Valkey Cluster

발표 ② — Braze · Sentinel HA

두 발표가 함께 가리키는 곳

마지막 수정 일자