makgol's note – 데이터·스토리지

GPU 스토리지 요구는 읽기 경로와 쓰기 방식에 따라 달라진다

Wed, 21 Oct 2026 00:00:00 +0900

01 · GPU 스토리지 요구는 읽기 경로와 쓰기 방식에 따라 달라진다

GPU 클러스터의 스토리지 요구는 작업 단계마다 달라집니다. 학습 데이터와 모델을 읽을 때는 대역폭뿐 아니라 CPU 전처리와 로더가 속도를 제한합니다. 체크포인트(복구를 위해 저장하는 학습 상태)를 쓸 때는 동기·비동기 방식에 따라 GPU가 기다리는 시간이 달라집니다.

GPU 스토리지의 병목을 파일 접근과 전송 경로로 읽는 법

Wed, 21 Oct 2026 00:00:00 +0900

02 · GPU 스토리지의 병목을 파일 접근과 전송 경로로 읽는 법

GPU 스토리지의 병목은 파일 크기와 접근 방식, 그리고 GDS가 직접 경로를 쓰는지에 따라 달라집니다. 큰 파일 스트리밍은 데이터 서버 수에, 소파일 접근은 메타데이터 처리량에 영향을 받습니다. GPUDirect Storage(GDS)는 CPU 메모리를 거치는 복사를 줄이지만, 파일 접근 조건과 PCIe 토폴로지(장치 연결 배치)가 맞아야 직접 경로를 씁니다.

GPU 체크포인트 저장 방식으로 보는 병렬 파일시스템의 필요성

Wed, 21 Oct 2026 00:00:00 +0900

03 · GPU 체크포인트 저장 방식으로 보는 병렬 파일시스템의 필요성

GPU 클러스터에 병렬 파일시스템이 필요한지는 체크포인트를 동기로 쓰는지 비동기로 쓰는지에 달려 있습니다. 이 글의 해석으로는 짧은 정지 시간을 요구하는 동기 저장에서는 필요하지만, 비동기 저장에서는 필수 조건이 아닙니다. 동기 저장은 짧은 시간에 데이터를 받아 줄 피크 대역폭이, 비동기 저장은 체크포인트 간격 동안의 평균 쓰기 대역폭이 기준이 됩니다.

2026년 어레이 벤더가 NVMe/TCP를 기본으로 미는 이유

Wed, 21 Oct 2026 00:00:00 +0900

04 · 2026년 어레이 벤더가 NVMe/TCP를 기본으로 미는 이유

2026-10-21 기준, 엔터프라이즈 스토리지 벤더는 NVMe/TCP와 RDMA(원격 메모리 직접 접근) 전송을 계속 제공합니다. 신규 이더넷 구축에서 기본으로 미는 쪽은 NVMe/TCP입니다. RoCE(이더넷 기반 RDMA)는 일부 제품의 호스트 연결과 어레이 내부 패브릭(연결망)에 쓰이고, FC-NVMe는 기존 FC SAN을 이어 갑니다. iSCSI도 모든 어레이에 남아 있습니다.

Kubernetes에서 NVMe-oF를 어디까지 쓸 수 있나

Wed, 21 Oct 2026 00:00:00 +0900

05 · Kubernetes에서 NVMe-oF를 어디까지 쓸 수 있나

Kubernetes에서 NVMe-oF(네트워크를 통한 NVMe 연결)를 쓰려면 CSI(컨테이너 스토리지 인터페이스) 드라이버와 노드의 이니시에이터(스토리지에 I/O를 요청하는 쪽)가 연결을 지원해야 합니다. 2026-10-21 기준으로 이 글에서 살펴본 드라이버 중 GA(정식 출시)를 확인한 것은 NetApp Trident의 NVMe/TCP 지원과 Longhorn V2입니다. ceph-csi와 Rook는 실험적입니다. Linux 노드의 연결 조건을 이어서 살펴보고, vSphere·클라우드·오프로드의 적용 범위도 짚습니다.

Linux NVMe/TCP의 연결과 장애 대응을 구성하는 법

Wed, 21 Oct 2026 00:00:00 +0900

06 · Linux NVMe/TCP의 연결과 장애 대응을 구성하는 법

Linux에서는 호스트 식별 파일, 부팅 뒤 자동 연결, 디스커버리 변경 감지, 네이티브 멀티패스와 장애 타임아웃이 NVMe/TCP 연결 유지를 좌우합니다. FC SAN에서 HBA와 패브릭, multipath.conf가 맡던 일이 Linux 호스트의 파일·서비스·커널 옵션으로 나뉩니다. Kubernetes 워커 노드도 이 구성을 바탕으로 스토리지에 연결합니다.

NVMe over FC·TCP·RDMA의 성능과 안정성 비교

Wed, 21 Oct 2026 00:00:00 +0900

07 · NVMe over FC·TCP·RDMA의 성능과 안정성 비교

Kubernetes와 클라우드에서 실제로 고를 수 있는 NVMe-oF 전송은 사실상 TCP입니다. 홈랩에서도 TCP가 가장 접근하기 쉽다는 것이 이 글의 판단입니다. 범용 NIC와 L3 라우팅 망을 쓰고, Linux 5.0부터 호스트와 타깃이 기본 커널에 들어 있습니다.

Kubernetes NVMe-oF 선택지와 Mayastor의 도입 조건

Wed, 21 Oct 2026 00:00:00 +0900

08 · Kubernetes NVMe-oF 선택지와 Mayastor의 도입 조건

Mayastor(OpenEBS의 Replicated PV 엔진)는 Kubernetes에서 RWO(단일 노드 읽기·쓰기) 볼륨을 동기 복제하는 선택지이며, 노드마다 전용 자원을 요구합니다. 이 글의 해석으로는 엔터프라이즈 기능과 DataCore Puls8 상용 지원은 갖췄지만, 공개 사례와 커뮤니티 폭은 Ceph나 Longhorn보다 좁습니다.

VM 표준 구성을 로컬 디스크로만 잡아도 되는가 — 복제를 어디에 둘 것인가

Mon, 05 Oct 2026 00:00:00 +0900

03 · VM 표준 구성을 로컬 디스크로만 잡아도 되는가 — 복제를 어디에 둘 것인가

VM(가상 머신)을 여러 대 띄워도 한 VM의 로컬 디스크에 쓴 데이터가 다른 VM에 복제되지는 않습니다. 로컬 디스크로 HA(고가용성)를 구성하려면 애플리케이션이 데이터를 직접 복제하거나, 웹·API처럼 디스크에 보존할 상태가 없어야 합니다. 복제 없는 작업환경 VM이나 단일 DB까지 같은 구성으로 운영하면 호스트 장애 때 데이터를 되찾지 못할 수 있습니다.

부록 · EKS 범용 노드와 gp3에서 잰 ClickHouse 1억 행 실측

Mon, 05 Oct 2026 00:00:00 +0900

부록 · EKS 범용 노드와 gp3에서 잰 ClickHouse 1억 행 실측

4 vCPU 범용 노드 한 대와 기본 설정 gp3 100GiB에 Kubernetes 로그 1억 행을 넣으면 적재, 압축, 쿼리에서 어떤 결과가 나올까요? atomai의 ClickHouse on EKS 실측 벤치마크는 이 조건을 서버 내부 적재와 코덱·인덱스별 쿼리로 나누어 측정했습니다. 이 글의 수치는 모두 원문 보고값이며 별도로 재실행하지 않았습니다.

부록 · HDD를 NVMe로 붙이면 오버헤드가 줄어드는가

Mon, 05 Oct 2026 00:00:00 +0900

부록 · HDD를 NVMe로 붙이면 오버헤드가 줄어드는가

기존 SATA·SAS HDD를 NVMe-oF(네트워크로 NVMe 명령을 주고받는 방식) 타깃 뒤에 두면 호스트에 NVMe 저장 공간으로 제공할 수 있습니다. 드라이브 자체가 NVMe(저장장치용 호스트 인터페이스 규격)를 지원하는 방식도 규격과 시연까지 나왔지만, 이 글에서 구매 가능한 제품은 찾지 못했습니다.

부록 · NFS를 같이 놓고 보면 — 파일 프로토콜은 iSCSI·NVMe-oF와 어디서 다른가

Mon, 05 Oct 2026 00:00:00 +0900

부록 · NFS를 같이 놓고 보면 — 파일 프로토콜은 iSCSI·NVMe-oF와 어디서 다른가

NFS 위의 파일에 fio direct=1을 실행한 결과를 원격 블록 장치의 결과와 그대로 비교할 수는 없습니다. NFS는 서버에 있는 파일시스템에 접근하고, 클라이언트 캐시를 우회해도 서버 캐시는 남을 수 있습니다. 쓰기가 언제 저장된 것으로 인정되는지도 서버 설정에 따라 달라집니다.

iSCSI와 NVMe-oF — 네트워크 블록 경로와 비용

Sun, 04 Oct 2026 00:00:00 +0900

01 · iSCSI와 NVMe-oF — 네트워크 블록 경로와 비용

NVMe SSD가 꽂힌 서버의 용량을 다른 호스트에 내줄 때, iSCSI를 NVMe-oF로 바꾸면 호스트의 명령 처리 경로와 큐 배치가 달라집니다. SCSI 중간 계층과 명령을 감싸는 단계가 빠질 여지는 있지만, TCP를 쓰면 TCP/IP 처리와 복사·CRC 비용은 남습니다. 타깃이 namespace 뒤에 연결한 볼륨과 복제 계층도 그대로입니다.

NVMe 용량을 VM에 나누기 — virtio·vhost·가상 NVMe·직접 할당

Sun, 04 Oct 2026 00:00:00 +0900

02 · NVMe 용량을 VM에 나누기 — virtio·vhost·가상 NVMe·직접 할당

NVMe SSD 용량을 VM에 나누는 방법을 고를 때는 게스트가 보는 장치와 실제 요청을 처리하는 주체를 함께 봐야 합니다. virtio-blk 장치 뒤에서 QEMU가 요청을 처리할 수도, 별도 SPDK 프로세스가 처리할 수도 있습니다. 물리 장치를 직접 할당하거나 호스트가 큐를 중개하는 방식, DPU·SmartNIC가 장치를 구현하는 방식도 있습니다. 이 선택에 따라 사용하는 호스트 CPU와 장치 공유 단위, 마이그레이션·블록 기능의 제약이 달라집니다.

S3 계정 간 복사 — aws s3 sync · rclone · rsync

Mon, 07 Sep 2026 00:00:00 +0900

01 · 계정 간 복사 — aws s3 sync · rclone · rsync는 어디서 갈리나

rsync는 선택지가 아니다. S3 API를 모르니 FUSE 마운트가 필요하고 그 위에서는 델타 전송·rename·mtime이 전부 무너진다.
소규모 일회성 복사는 aws s3 sync. 서버사이드 CopyObject라 데이터가 내 머신을 거치지 않고 같은 리전이면 요청 요금만 낸다.
객체 수십만 개 이상이거나 반복 동기화면 rclone. 단 --server-side-across-configs가 없으면 에러 없이 다운로드→업로드로 돌아서고 mtime 비교는 객체마다 HEAD를 한 번씩 더 부른다.
셋 다 현재 버전만 옮기고 태그·ACL·스토리지 클래스는 도구마다 다르게 잃는다. 버전 이력까지 보존해야 하면 S3 Replication(Batch Replication)으로 간다.
계정 간이면 도구와 무관하게 SSE-KMS 키 정책과 Object Ownership 설정이 먼저 걸린다.

기준일은 2026-09-07, 요금은 버지니아 북부(us-east-1) S3 Standard 기준입니다.

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

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

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 +0900

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

한눈에

2009 첫 커밋부터 6.2 까지

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

01 · 자료구조 서버는 왜 이렇게 생겼나 — 2009 첫 커밋부터 6.2 까지

최초 문제는 “캐시가 필요하다"가 아니라 “값이 blob 이면 안 된다"였습니다. 첫 커밋에 동봉된 FAQ 가 프로젝트 시작 이유를 한 줄로 적습니다 — In order to scale LLOOGG.(redis ed9b544e1:doc/FAQ.html) 같은 커밋의 doc/README.html 은 memcached 와의 차이를 자료형과 영속성 두 축으로만 설명합니다 ✓
첫 커밋(2009-03-22 ed9b544e1)은 캐시가 아니었습니다. saveDb() 가 .rdb 로 쓰고 매직 REDIS0000 을 박고 fork() 기반 BGSAVE 와 save 900 1 / save 300 10 / save 60 10000 이 이미 있습니다 — 그 3줄은 6.0.0 의 기본값과 값까지 동일합니다 ✓
없던 것이 더 많습니다 — EXPIRE·hash·sorted set·AOF·epoll·RESP·MULTI·pub/sub·Lua·Cluster·src/ 전부. 이벤트 루프는 연결 리스트 + select(2) 단일 구현이고 응답은 nil\r\n·0\r\n 같은 타입 프리픽스 없는 raw 문자열입니다 ✓
단일 스레드는 성능 최적화가 아니라 API 계약이었습니다. “락을 지원하지 않는다, 대신 원자 프리미티브를 준다"가 day-1 문서의 답이고(ed9b544e1:doc/README.html), INCR·LPUSH·SINTERSTORE 가 별도 동기화 없이 원자인 이유가 이것뿐입니다 Σ
MANIFESTO 는 두 판본입니다. v1 은 2011-03-01(be14f38de, 7개 항목)이고 스레딩 항목이 없습니다. 7 - Threading is not a silver bullet 은 2019-03-18 v2(a5af648fd)에서 추가됐습니다 — 6.0.0 GA(2020-04-30)보다 약 13개월 앞서, 같은 문단이 we may explore parallelism only for I/O, which is the low hanging fruit 라고 예고합니다 ✓
버린 것을 보면 철학이 더 잘 보입니다. Virtual Memory 는 2.0 에 vm-enabled 로 실렸고 2.4 conf 가 WARNING! Virtual Memory is deprecated in Redis 2.4 를 붙였고 2.6.0 에서 제거됐습니다(Virtual Memory removed (was deprecated in 2.4)). 그 자리를 MANIFESTO 2번 Memory storage is #1 이 대신 지킵니다 ✓
6.0 threaded I/O 는 커맨드를 병렬로 돌리지 않습니다. 워커가 하는 일은 writeToClient() 또는 readQueryFromClient() 둘 중 하나뿐이고 커맨드는 배리어 통과 뒤 메인 스레드의 processCommandAndResetClient() 가 실행합니다. 기본값은 io-threads 1(비활성) + io-threads-do-reads no 로 둘 다 IMMUTABLE_CONFIG 이며 SSL 이 켜져 있으면 동작하지 않습니다 ✓
6.0 릴리스노트의 “2배” 주장에는 인스턴스·코어 수·값 크기·클라이언트 수가 없습니다 — when pipelining cannot be used 라는 한정만 있습니다 Ⓥ

왜 이 문서인가. Redis 를 기능 목록으로 읽으면 “왜 이 기능은 이렇게 생겼나"에 답할 수 없습니다. 이 구간(2009~2021)에서 정해진 것은 기능이 아니라 제약입니다 — 값이 자료구조라는 결정이 단일 스레드를 불렀습니다. 단일 스레드가 원자성을 공짜로 줬고 그 대가를 6.0 이 threaded I/O 로 처음 갚기 시작했습니다. 7.0 이후에 나오는 거의 모든 논쟁(스레딩·메모리 레이아웃·cluster 제약)의 전제가 여기서 굳었습니다.

Managed vs Self-hosted — TCO 크로스오버

Mon, 13 Jul 2026 00:00:00 +0900

Managed vs Self-hosted — TCO 크로스오버

ClickHouse를 직접 운영하면 서버 요금은 줄일 수 있어도 복제, 백업, 업그레이드 작업은 팀에 남습니다. Cloud와 self-host의 비용을 비교할 때 이 시간을 빼면, 월 청구서는 낮아졌는데 운영 부담은 더 커지는 선택을 하기 쉽습니다.

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

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

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 +0900

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.

memcached — 같은 문제를 다르게 푼 6년 선배

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

02 · memcached — 같은 문제를 다르게 푼 6년 선배

memcached 는 Redis 의 열등한 과거가 아닙니다. “캐시는 캐시여야 한다"를 끝까지 밀어서 Redis 가 갖지 못한 성질(한 프로세스로 코어를 먹는 확장, 느린 커맨드가 존재할 수 없는 지연 예측성, 값을 NVMe 로 내리는 용량 확장)을 얻고 자료구조·영속성·복제·다중 키 원자성을 포기했습니다 Σ
첫 커밋(2003-05-27)에는 slab allocator 도 자체 해시 테이블도 없었습니다. malloc() + Judy 트라이 + 전역 단일 LRU 였고 slab 은 3일 뒤·자체 해시는 3주 뒤에 둘 다 파편화 때문에 들어왔습니다 ✓
slab allocator 의 대가가 calcification 이고 그것을 갚는 데 21년이 걸렸습니다. 문제 인지 2003-06-24, 첫 공식 해법 1.4.11(2012-01-16), 기본값 승격 1.5.0(2017-07-21), 그리고 1.6.34(2024-12-22)의 mover 전면 재작성이 “페이지를 옮기면 아이템을 잃는다"는 대가 자체를 제거했습니다 ✓
LRU 는 HOT/WARM/COLD/TEMP 4단 segmented LRU 이고 1.5.0 부터 기본입니다. Redis 와 근사의 위치가 반대입니다 — memcached 는 접근 기록을 스레드별 bump buffer 에 비동기로 쌓고 넘치면 버리며, Redis 는 축출 시점에 표본을 뽑습니다(maxmemory-samples 5) ✓
워커 스레드 N개가 각자 이벤트 루프를 돌려 read·parse·execute·write 를 끝냅니다. -t 16 한 프로세스가 16코어를 씁니다. Redis 8.10.0 redis.conf 는 2026년에도 “Redis is mostly single threaded” 이고 io-threads 는 소켓 읽기·쓰기와 프로토콜 파싱까지입니다 — 커맨드 실행은 메인 스레드입니다 ✓
그 대가가 원자성입니다. 보장 단위가 아이템 하나뿐이라 MULTI/EXEC·Lua·다중 키 트랜잭션에 대응할 방법이 원리적으로 없습니다 ✓
binary protocol 은 1.6.0(2020-03-08)에 공식 deprecated 됐고 후계는 meta 커맨드입니다. 2026년에 클라이언트를 고를 때 meta 지원 여부가 1순위인 이유는 stampede 방어(W/Z)와 serve-stale 이 서버에서 원자적으로 되는 유일한 경로이기 때문입니다 ✓
프로젝트는 살아 있지만 기능 개발은 멈춰 있습니다. 2026년 릴리스 4개(1.6.42~1.6.45)가 전부 보안·안정화이고 최근 1년의 사용자 노출 신기능은 1.6.40 의 mg 조건부 CAS 페치 하나입니다 ✓
memcached 와 Redis 를 같은 하드웨어에서 1:1 로 측정한 1차 벤치마크는 없습니다. 그래서 이 문서는 “몇 배 빠르다"를 쓰지 않고 구조와 단독 측정치만 씁니다 ?

왜 이 문서인가. memcached 를 “Redis 가 나오기 전에 쓰던 것"으로 읽으면 두 번 틀립니다. 하나, memcached 는 2003년에 멈춘 소프트웨어가 아닙니다 — segmented LRU(1.4.23), SSD 확장(1.5.4), 재시작 생존 캐시(1.5.18), meta 프로토콜(1.6.0), 내장 proxy(1.6.13), slab mover 재작성(1.6.34)이 전부 그 뒤에 들어왔습니다. 둘, 둘의 차이는 기능 개수가 아니라 선택한 축입니다. memcached 는 값을 해석하지 않기로 한 대가로 스레드를 열었고, Redis 는 자료구조를 서버에서 실행하기로 한 대가로 실행 스레드를 하나로 묶었습니다. 이 문서는 그 교환을 소스와 릴리스노트로 확인합니다.

스토리지 아키텍처 — 로컬 NVMe(i7i/i8g)

Mon, 13 Jul 2026 00:00:00 +0900

스토리지 아키텍처 — 로컬 NVMe(i7i/i8g)

로컬 NVMe를 ClickHouse 데이터 디스크로 쓰면 수 GB/s의 처리량을 얻을 수 있습니다. 대신 인스턴스가 사라질 때 그 디스크도 잃습니다. 따라서 노드 크기를 고를 때는 저장할 수 있는 TB보다, 노드 한 대 분량을 다른 replica에서 복구하는 데 걸리는 시간을 계산해야 합니다.

왜 찢어졌나 — Commons Clause 부터 AGPL 복귀까지

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

03 · 왜 찢어졌나 — 2018 Commons Clause 부터 2025 AGPL 복귀까지

2018·2019·2022 의 라이선스 변경은 전부 모듈 얘기입니다. RediSearch·RedisGraph·ReJSON·ReBloom·Redis-ML 에 붙은 것이고 core 는 2024-03-20 까지 BSD-3 였습니다. 회사는 그 사이 세 번 문서로 “core 는 BSD 로 남는다"고 공언했습니다 ✓
core 가 넘어간 것은 커밋 하나입니다. 0b3439692 “Change license from BSD-3 to dual RSALv2+SSPLv1 (#13157)”, 2024-03-20 22:38:24Z, author Pieter Cailliau(Redis Inc.). COPYING 삭제 + LICENSE.txt(733줄) 추가 ✓
SSPL 단독이 아니라 “RSALv2 또는 SSPLv1” 듀얼이고 둘의 성격이 정반대다 — RSALv2 는 “서비스로 제공하지 말라"는 금지형, SSPLv1 은 “하려면 오케스트레이션 전부를 공개하라"는 조건형 copyleft ✓
포크 기점은 두 개입니다. 라이선스적으로는 마지막 BSD 릴리스인 7.2.4(2024-01-09), 코드적으로는 relicense 커밋의 부모 e64d91c37(2024-03-20 20:44:28Z) — Valkey 는 relicense 1시간 54분 전의 트리를 들고 나갔고 7.2.4 이후 2개월 반치 unstable 을 포함합니다 ✓
“AWS 가 만든 포크"는 절반만 사실입니다. 첫 커밋 저자 Madelyn Olson 은 2020-07-09 에 Redis Core Team 멤버가 됐는데 Redis Inc. 가 직접 초청해 앉힌 자리였습니다. 실제 대비는 “벤더 vs 벤더"가 아니고 CLA + 단일 소유 vs DCO + LF + TSC 1/3 상한에 있습니다 ✓
2025-05 에 Redis 는 AGPLv3 를 추가해 OSI 승인 라이선스로 돌아왔습니다. 그런데도 Valkey 는 돌아가지 않았습니다. 라이선스 옵션이 늘어난 것과 거버넌스가 바뀐 것은 다르다 — CLA 는 그대로이고 AGPL 은 추가였을 뿐 RSALv2/SSPLv1 철회가 아니다 ✓
호환성은 RESP 레벨까지만 참입니다. 커맨드 JSON 기준 Valkey 9.1.0 전용 18개 / Redis 8.10.0 전용 52개. atomic slot migration 처럼 같은 기능을 다른 커맨드로 구현한 사례가 이미 있습니다 ✓
사내에서 캐시로만 쓴다면 어느 라이선스에서도 걸리지 않는다(§7). 걸리는 것은 재배포·외부 제공·그룹사 경계입니다.

왜 이 문서인가. “Redis 가 라이선스를 바꿨고 AWS 가 포크했다"는 두 줄 요약은 세 곳에서 틀린다 — 무엇이 바뀌었는지(모듈 vs core), 누가 나갔는지(외부인 vs 원 core team), 왜 안 돌아왔는지입니다. 마지막 항목이 이 문서의 논지입니다. 2025-05 에 Redis 가 AGPLv3 를 추가해 OSI 승인 라이선스로 복귀했는데도 Valkey 는 돌아가지 않았습니다. 라이선스가 원인이었다면 이 시점에 봉합됐어야 합니다. 원인은 라이선스가 아니었습니다. 단일 벤더가 프로젝트의 라이선스를 일방적으로 바꿀 수 있는 구조가 원인이었고 라이선스 변경은 그 구조를 드러낸 방아쇠였습니다.

clickhouse-operator 선택

Mon, 13 Jul 2026 00:00:00 +0900

ClickHouse를 Altinity operator로 운영하기

ClickHouse를 StatefulSet으로 띄우는 일은 어렵지 않습니다. replica와 shard를 늘리면 관리할 대상이 달라집니다. 새 replica의 스키마를 만들고, remote_servers를 갱신하고, 같은 shard의 replica를 동시에 재시작하지 않도록 순서를 관리해야 합니다. operator는 이 반복 작업을 CHI 선언과 reconcile로 처리합니다.

Redis 7.0 → 8.10 — 그리고 9 는 왜 없나

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

04 · Redis 7.0 → 8.10 — 그리고 9 는 왜 없나

Redis 에 9 는 없습니다. redis/redis 에 9* 태그가 하나도 없습니다. 숫자 브랜치는 8.10 이 끝이고 마일스톤 목록에도 9.0 이 없습니다. 8.10 GA 이후에도 unstable 의 src/version.h 는 여전히 8.9.241 입니다 ✓. 9.0 계획을 공표한 문서는 찾지 못했습니다 — 9 를 기다려 업그레이드를 미루는 것은 근거 없는 유예입니다 Σ.
“8.1·8.3·8.5 가 스킵됐다” 는 오해입니다. 홀수 마이너는 프리릴리스 전용 번호입니다 — 8.0 의 RC1 은 7.9.240, 8.10 의 RC1 은 8.9.240 으로 실재합니다 ✓. GA 는 짝수만 나옵니다(8.0 → 8.2 → 8.4 → 8.6 → 8.8 → 8.10).
8.0 은 기능 릴리스가 아니라 제품 경계의 재편입니다. 이름(Community Edition → Open Source) · 라이선스(AGPLv3 추가) · 번들 구성(Redis Stack 흡수)이 한 릴리스에 겹쳤습니다 ✓. 그 “core 통합” 은 빌드 시 각 모듈 upstream 을 git clone 해 .so 로 만들고 loadmodule 로 싣는 번들입니다 — 바이너리 내장이 아닙니다(redis 8.0.0:modules/common.mk:34) ✓.
8.6 이후로 롤백 창이 닫혔습니다. RDB_VERSION 이 7.4~8.4 구간 12 로 고정이었다가 8.6=13 · 8.8=14 · 8.10=15 로 매 릴리스 올라갑니다(redis 8.10.0:src/rdb.h:21) ✓. “가볍게 올려보고 안 되면 내리자” 가 8.6 부터 성립하지 않습니다.
Redis 는 “LTS” 라는 말을 쓰지 않습니다. Standard(다음 마이너 후 6개월) / Extended(5년)이고 8.x 중 Extended 는 8.2 하나뿐(EOL 2030-09-01)입니다. 8.0 은 2026-12-01 에 끝납니다 ✓. 최신인 8.10 은 지원 표에 아직 등재조차 되지 않았습니다 — 장기 지원을 전제하면 안 됩니다.
“87% 빠르다” 는 분포의 최댓값입니다. 실제 수치는 7.2.5 대비 149개 테스트 중 90개 개선, p50 감소폭 5.4%~87.4%, 중앙값 16.7% Ⓥ. “2배 처리량” 은 io-threads=8 + multi-core Intel 조건이고 기본값은 io-threads 1 입니다(redis 8.10.0:src/config.c:3396 — 8.10.0 까지 IMMUTABLE_CONFIG) ✓.
9 를 찾는 사람은 대개 Valkey 를 보고 있습니다. Valkey 는 홀수 마이너를 정식 GA 로 쓰고(8.1 · 9.1) 9.0.0 이 2025-10-21 에 나왔습니다 — Redis 의 짝수 전용 케이던스와 정반대입니다 ✓. → 05

왜 이 문서인가. “7·8·9 에 무엇이 추가되나” 라는 질문은 Redis 쪽에서는 전제가 하나 틀려 있습니다. 9 가 없다는 사실을 모르면 릴리스 표를 아무리 읽어도 “곧 나올 9 를 기다린다” 는 잘못된 결론에 이릅니다. 그래서 이 문서는 순서를 뒤집습니다 — 먼저 9 의 부재를 확증하고 그 다음에 7.0 부터 8.10 까지 실제로 무엇이 들어왔는지, 그중 운영자가 업그레이드 전에 손을 대야 하는 것이 무엇인지 봅니다.

operator 배포 플레이북 — 로컬 NVMe 실전 구성

Wed, 15 Jul 2026 00:00:00 +0900

operator 배포 플레이북 — 로컬 NVMe 실전 구성

Altinity operator에 CHI를 적용해도 EC2의 NVMe가 자동으로 ClickHouse 데이터 볼륨이 되지는 않습니다. 노드에서 디스크를 포맷·마운트하고 local PV로 노출한 뒤, CHI의 PVC가 그 PV에 바인딩돼야 합니다. Keeper는 별도의 gp3 볼륨을 사용합니다.

Valkey 8.0 → 9.1 — 엔진이 갈라진 지점

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

05 · Valkey 8.0 → 9.1 — 엔진이 갈라진 지점

Valkey 는 이름만 바꾼 Redis 7.2 가 아닙니다. 8.0 에서 네트워크 스레딩(src/io_threads.c 신설)과 full sync 프로토콜(capa dual-channel)이, 8.1 에서 키 저장 자료구조(src/hashtable.c 신설)가 교체됐습니다. Redis 는 8.10.0 트리에도 hashtable.c 가 없습니다 — dict.c + no_value=1 입니다 ✓.
8.0 의 async I/O 스레딩은 6.0 threaded I/O 를 통째로 교체한 결과입니다. lock-free ring buffer(잡 2048개 고정) 기반 비동기 잡 큐로 바뀌고 read/parse/write 를 넘어 poll-wait · command lookup · 메모리 free 까지 워커로 넘어갔습니다 ✓.
그래도 기본값은 io-threads 1(비활성)입니다. 8.0/8.1 에서는 IMMUTABLE_CONFIG 라 재시작 없이 켤 수도 없고 런타임 변경은 9.0 부터입니다 ✓. 이 기본값이 “올렸는데 안 빨라진다"의 1차 원인입니다.
dual channel replication 은 기본 no 입니다(8.0·8.1 모두). Redis 의 대응물 repl-rdb-channel 은 기본 on 이고 와이어 문자열이 달라 서로 붙지 않습니다 — Redis primary ↔ Valkey replica 를 섞으면 이 경로는 경고 없이 레거시 단일 채널로 폴백합니다 ✓.
8.1 은 재시작만으로 키당 20~30바이트를 회수합니다. 64바이트(= 캐시라인 1개) 버킷에 엔트리 7개를 담는 새 hashtable 로 kvstore 백엔드를 갈아끼웠습니다. 설정 변경이 없는 순수 이득이지만 MEMORY USAGE·INFO memory 절대값이 바뀌므로 알림 임계값 재보정이 필요합니다 ✓.
RDB 포맷은 9.0 에서 영구히 갈라졌습니다 — RDB_VERSION 11 → 80, magic REDIS0011 → VALKEY080. 12~79 는 Redis 비-OSS 포맷용으로 예약해 거부합니다. Redis 7.4 이상에서 만든 RDB·DUMP 페이로드는 Valkey 가 받지 않고 우회 방법이 없습니다 ✓.
9.0 은 breaking change 섹션이 없는 major 입니다. 커맨드 제거 0건, 설정 제거 0건, behavior change 3건. 오히려 25개 커맨드의 deprecation 을 되돌렸습니다. 실질적 breaking 은 RDB 버전 하나입니다 ✓.
2026-07-21 의 7.2.14 / 8.0.10 / 8.1.9 / 9.0.5 / 9.1.1 동시 릴리스는 보안 릴리스입니다 — CVE-2026-56684(TLS use-after-free, CVSS 7.5) · CVE-2026-63639(stream PEL use-after-free, CVSS 8.8, 모든 버전 영향) ✓.

왜 이 문서인가. “Valkey = 리브랜딩된 Redis 7.2” 를 전제로 깔면 튜닝 가이드·모니터링 쿼리·마이그레이션 계획이 전부 어긋납니다. 스레드 수를 올려도 안 빨라지고 빠른 full sync 는 켜지지 않고 Redis 7.4 에서 뜬 RDB 를 올리면 Can't handle RDB format version 12 로 거절당합니다. 이 문서는 그 어긋남을 설정 이름·기본값·소스 경로로 확정합니다.

변경관리·스케일·롤링 업그레이드·복구

Wed, 15 Jul 2026 00:00:00 +0900

변경관리·스케일·롤링 업그레이드·복구

ClickHouse의 shard를 늘리는 변경과 replica를 늘리는 변경은 작업 결과가 다릅니다. 새 replica는 기존 shard의 사본을 받아오지만, 새 shard에 과거 데이터가 자동으로 옮겨지지는 않습니다. 매니페스트의 숫자 하나를 바꿨더라도 데이터 이동과 확인 절차까지 따로 계획해야 합니다.

cluster mode — 16384 슬롯이 강제하는 것

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

06 · cluster mode — 16384 슬롯이 강제하는 것

cluster mode 는 스케일을 주는 대신 애플리케이션의 자유를 뺏습니다. 그 대가는 2015-04-01(3.0.0)에 프록시를 두지 않기로 한 결정에서 나왔습니다 — 라우팅 비용을 클라이언트로 옮겨 hop 을 하나 없앤 대신, smart client 가 없으면 아무것도 동작하지 않습니다 ✓.
MOVED 와 ASK 는 같은 코드 경로에서 접두어만 달라지는데 의미는 정반대입니다. MOVED 는 영구 재배치라 슬롯 맵을 갱신해야 하고 ASK 는 단발이라 슬롯 맵을 갱신하면 안 되고 ASKING 을 앞세워 한 번만 재시도해야 합니다. 이 구분을 못 하는 클라이언트는 리샤딩 중 슬롯 맵을 오염시킵니다 ✓.
16384 는 gossip 헤더 예산이 정한 숫자입니다. 모든 PING/PONG/MEET 헤더에 슬롯 비트맵이 raw 로 실리고 그게 2048바이트입니다 — clusterMsg 의 myslots 오프셋 80, replicaof 오프셋 2128 을 static_assert 이 강제합니다 ✓.
슬롯 계산은 mod 가 아니라 crc16(key) & 0x3FFF 입니다. 해시 태그는 첫 { 와 그 뒤 첫 } 만 봅니다 — {a}{b} 는 a 로 해시되고 {} 나 } 없는 경우는 태그가 무시되고 키 전체가 해시됩니다 ✓.
잃는 것은 cross-slot 다중 키 연산·단일 슬롯 트랜잭션·pub/sub 브로드캐스트 비용·KEYS/SCAN/DBSIZE 의 의미·커넥션 수 곱셈입니다. “DB 0 하나뿐"만은 진영마다 다릅니다 — Valkey 9.0.0 이 cluster-databases 를 열었고 Redis 8.10.0 에는 그 설정이 없습니다 ✓.
가장 아팠던 슬롯 마이그레이션을 양쪽이 각자 원자적으로 고쳤고 방향이 반대입니다 — Valkey 9.0.0(2025-10-21) CLUSTER MIGRATESLOTS 는 source 에서 push, Redis 8.4.0(2025-11-18) CLUSTER MIGRATION IMPORT 는 destination 에서 pull. 리샤딩 자동화가 두 진영 호환되지 않는 첫 사례입니다 ✓.
cluster_state:ok 는 거짓 안심을 줍니다 — cluster-require-full-coverage no 면 커버리지 검사를 아예 하지 않습니다. 커버리지 검사는 PFAIL 을 안 봅니다. 값은 그 노드의 로컬 gossip 시야로 계산됩니다 ✓.
Valkey 에서 모듈을 하나라도 로드하면 ASM 이 아예 거부됩니다. 공식 모듈 4개(search/json/bloom/ldap) 전부가 VALKEYMODULE_OPTIONS_HANDLE_ATOMIC_SLOT_MIGRATION 을 선언하지 않습니다 ✓.

왜 이 문서인가. cluster mode 를 “샤딩 켜기"로 읽으면 매니페스트는 통과하고 애플리케이션이 나중에 터집니다. 애플리케이션 계약이 바뀝니다 — 같이 읽던 키를 같이 읽을 수 없습니다. standalone 에서 통과한 트랜잭션이 EXEC 에서만 실패합니다. 모니터링이 보던 DBSIZE 가 다른 뜻이 됩니다. 이 문서는 그 제약이 어느 코드에서 어떤 조건으로 발생하는지, 그리고 11년간 가장 아팠던 슬롯 마이그레이션이 2025년에 어떻게 바뀌었는지를 다룹니다.

프로덕션 운영 사례

Mon, 13 Jul 2026 00:00:00 +0900

ClickHouse 운영 사례의 규모와 배포 형태

ClickHouse로 하루 PB 단위 로그를 처리하는 사례가 있습니다. 그러나 처리량이 크다는 사실만으로 EKS의 로컬 NVMe 구성까지 검증됐다고 볼 수는 없습니다. Cloudflare·Didi는 베어메탈이고, Anthropic·Character.AI·LogHouse는 오브젝트 스토리지를 활용합니다. eBay는 Kubernetes와 operator를 공개했지만 스토리지 하드웨어는 밝히지 않았습니다.

AWS 에서 엔드포인트는 어떻게 바뀌나

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

07 · AWS 에서 엔드포인트는 어떻게 바뀌나 — CMD · CME · Serverless · MemoryDB

엔드포인트는 접속 주소처럼 보이지만 실제로는 토폴로지의 표현입니다. CMD(cluster mode disabled)는 primary·reader·node 3종을 갖습니다. CME(cluster mode enabled)는 configuration endpoint 1개뿐입니다. CME 에는 primary/reader endpoint 라는 개념 자체가 없습니다 ✓ — DescribeReplicationGroups 응답에 그 필드가 없다는 것은 문서의 응답 예시로 확인했습니다. 규정한 문장은 없습니다 ≈
이름 안에 clustercfg 가 있으면 cluster 프로토콜 전용(CME 또는 MemoryDB), .ng.0001. 이면 CMD primary, .serverless. 면 Serverless, .cfg. 면 Memcached 입니다 ✓
모드 전환은 단방향입니다. disabled → compatible → enabled 2단계이고 AWS 문서가 “Reverting this configuration is not possible” 라고 명시했습니다. 되돌릴 수 있는 것은 compatible → disabled 뿐입니다 ✓
“엔드포인트만 갈아끼우면 된다"가 틀리는 이유는 바꿀 것이 3종 세트라서입니다 — 엔드포인트 문자열 + 클라이언트(cluster 프로토콜 지원) + 애플리케이션의 다중 키 연산(같은 슬롯 강제). 하나라도 빠지면 CROSSSLOT 으로 런타임에 터집니다 ✓
엔진 전환은 정반대입니다. Redis OSS → Valkey 는 in-place 이고 “including the endpoint DNS name, will remain unchanged” 입니다. 바뀌는 것은 노드 IP 뿐입니다 — 모드 전환과 엔진 전환의 리스크를 섞으면 계획서가 통째로 틀립니다 ✓
TLS 켜기는 설정 토글로 보이지만 엔드포인트 마이그레이션입니다. 포트는 6379 그대로이고 DNS 레코드 형식이 바뀝니다. per-node DNS 이름은 preferred 로 넘어가는 시점에 이미 삭제·재생성되고 구 non-TLS primary/reader 는 required 에서 삭제됩니다 ✓
failover 자체는 몇 초입니다. 장애 시간을 만드는 것은 클라이언트 DNS 캐시입니다. AWS 문서가 JVM networkaddress.cache.ttl 을 5~10초로 낮추라고 직접 지시합니다. 기본값이면 “never refresh DNS entries until the JVM is restarted” 라고 경고합니다. security property 라서 -D 플래그로는 안 들어갑니다 ✓
Serverless 는 클라이언트를 편하게 해주지 않습니다. 항상 cluster mode 로 동작하고 TLS 가 강제입니다. Read from Replica 를 쓰지 않아도 6380 을 열어야 커넥션 수립이 느려지지 않습니다 ✓
관리형은 config·debug·cluster setslot 을 막습니다. 남는 유일한 설정 경로가 파라미터 그룹입니다. self-host 를 고민하게 되는 실질적 이유입니다 ✓

왜 이 문서인가. ElastiCache 로 넘어갈 때 가장 흔한 실패는 “주소만 바꾸면 되는 줄 알았다"입니다. 그런데 ElastiCache 의 엔드포인트는 클러스터 토폴로지를 DNS 로 노출한 결과물입니다. 편의를 위해 붙인 별칭이 아닙니다. 모드를 바꾸면 주소 구조가 바뀝니다. 주소 구조가 바뀌면 클라이언트 라이브러리의 종류가 바뀌고 클라이언트가 바뀌면 애플리케이션의 다중 키 연산까지 바뀝니다. 이 연쇄를 끊어서 보면 어느 단계에서든 사고가 납니다. 연쇄를 알면 엔드포인트 문자열만 보고도 그 앱이 무엇을 해야 하는지 판정할 수 있습니다.

로컬 NVMe 하드 유저들 — 데이터스토어 횡단 벤치마킹

Tue, 14 Jul 2026 00:00:00 +0900

데이터스토어별 로컬 NVMe 운영과 복구

로컬 NVMe를 데이터스토어의 주 디스크로 쓰면 노드 장애 뒤에 데이터를 다시 채우는 작업이 따라옵니다. ClickHouse만의 문제는 아닙니다. ScyllaDB는 스트리밍 속도를 개선하고, CockroachDB는 작은 노드에 데이터를 분산하도록 권하며, 일부 TiDB 사용자는 복구 시간 때문에 EBS를 검토합니다.

무신사 CDP — self-hosted ClickHouse에서 Cloud로

Wed, 12 Aug 2026 00:00:00 +0900

무신사 CDP — self-hosted ClickHouse에서 Cloud로

무신사의 CDP에서는 오디언스 정의 하나가 최대 1,600만 행을 추가할 수 있습니다. 회원이 어느 오디언스에 속하는지 저장하는 매핑이기 때문입니다. 정의가 2,500개로 늘면서 매핑은 약 11억 행이 됐고, 팀은 데이터와 컴퓨트를 각각 확장할 방법을 찾았습니다.

Redis·Valkey·Memcached 판단표

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

08 · 무엇을 고를 것인가 — Redis · Valkey · memcached 판단표

신규 채택은 Valkey 9.1.x 가 기본값입니다. BSD-3 이고 거버넌스가 라이선스 재변경을 2/3 super-majority + 조직 1/3 상한으로 묶어 두었고 ElastiCache 에서 7.1 위로 갈 수 있는 유일한 엔진입니다 Σ — 단 검색·벡터·JSON·시계열을 배포 하나로 끝내야 하면 이 선택은 성립하지 않습니다(§3.5).
이미 Redis 를 쓰고 있으면 대부분 그대로 두는 쪽이 맞습니다. 사내 캐시 용도는 RSALv2·SSPLv1·AGPLv3 어느 쪽에서도 금지되지 않고(03), 7.4 이상에서 Valkey 로 넘어가는 파일·복제 경로는 전부 막혀 있습니다(05) — 이주 비용이 라이선스 리스크보다 큽니다 Σ. 움직여야 하는 조직은 재배포·외부 제공이 로드맵에 있는 곳뿐입니다 ✓.
값이 blob 이고 잃어도 되는 순수 캐시는 memcached 1.6.45 가 여전히 이깁니다. 프로세스 하나가 코어를 다 먹고 느린 커맨드라는 개념이 없고 프로토콜에 stampede 방어가 들어 있습니다(02) ✓. 지는 지점은 성능이 아니라 관리형 경로와 버스 팩터입니다 Σ.
판정 기준은 성능이 아닙니다. 세 진영의 성능 수치는 전부 발행 주체가 당사자이고 같은 하드웨어 1:1 측정이 없습니다(02·04·05) ✓. 실제로 결정하는 축은 라이선스·번들 모듈·RDB 버전·관리형 지원 버전 네 개입니다 Σ.
되돌릴 수 있는지가 대부분의 결정을 대신 내려 줍니다. Redis 8.6 부터 RDB 가 매 릴리스 오르고 Valkey 9.0 은 RDB 를 80 으로 올려 영구히 분리했고 ElastiCache 의 CMD → CME 는 단방향입니다 — 이 셋은 전부 편도 티켓입니다 ✓.
“9 를 기다린다” 는 전략이 없습니다. Redis 에 9.x 는 존재하지 않고 계획 문서도 확인되지 않았습니다(04) ✓. 9.x 를 가진 쪽은 Valkey 입니다.

왜 이 문서인가. 앞 7개 문서는 각각 “무엇이 사실인가” 를 소유합니다. 이 문서는 새 사실을 도입하지 않고 그 사실들을 결정으로 압축합니다. 모든 행에 근거 문서로 가는 링크가 붙고 근거 없는 취향 서술은 넣지 않았습니다 — 근거가 부족한 자리는 §7 에 미확인으로 남겼습니다.

Iceberg·레이크하우스 — 테이블 포맷이 뭐고, S3 메인의 답이 되는가

Wed, 12 Aug 2026 00:00:00 +0900

Iceberg·레이크하우스 — 테이블 포맷이 뭐고, S3 메인의 답이 되는가

S3에 Parquet 파일을 쌓으면 여러 엔진이 읽을 수 있습니다. 하지만 파일을 추가하거나 교체하는 중에 어떤 파일 집합이 하나의 테이블인지 정하는 규칙이 필요합니다. Iceberg는 스냅샷, 스키마, 유효한 데이터 파일 목록을 메타데이터로 관리해 이 문제를 다룹니다.

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

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

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

ClickHouse 참고 자료

Mon, 13 Jul 2026 00:00:00 +0900

ClickHouse 참고 자료

ClickHouse 운영 시리즈에서 사용한 공식 문서, 운영 사례, 벤치마크를 주제별로 모았습니다. 각 자료의 수치와 주장을 어떻게 적용했는지는 해당 본문에서 확인할 수 있습니다.

Redis·Valkey·Memcached 참고 자료

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

출처 — Redis · Valkey · Memcached 조사 자료

이 페이지는 2009 첫 커밋부터 6.2 까지, memcached — 같은 문제를 다르게 푼 6년 선배, 왜 찢어졌나 — Commons Clause 부터 AGPL 복귀까지, Redis 7.0 → 8.10 — 그리고 9 는 왜 없나, Valkey 8.0 → 9.1 — 엔진이 갈라진 지점, cluster mode — 16384 슬롯이 강제하는 것, AWS 에서 엔드포인트는 어떻게 바뀌나, 무엇을 고를 것인가 여덟 페이지가 인용한 1차 조사 문서의 근거 표기(URL·gh api·로컬 클론 git show)에서 URL만 골라 중복을 걷고 주제별로 묶었습니다.