초당 1,000,000++ RPS를 처리하는 네이버 개발자의 Valkey
VALKEY · IN-MEMORY DATABASE · NAVER ENGINEER
Valkey vs Redis :
네이버 개발자와 함께하는 100만 TPS 완전 정복
Valkey(밸키)는 2024년 Redis 라이선스 변경 직후 Redis 7.2를 포크해 만든 BSD 라이선스 오픈소스 인메모리 데이터베이스입니다. 이 Valkey 강의는 네이버에서 10년째 서버를 만들며 겪은 장면을 그대로 재현합니다. 재고가 마이너스로 찍히는 경쟁 상태, 캐시가 한꺼번에 만료되며 DB가 휘청이는 캐시 스탬피드(cache stampede), 마스터가 죽는 순간의 failover까지. 작은 이커머스를 만들며 캐시부터 복제·Sentinel·Cluster 운영까지 이어서 배우고, 마지막엔 노트북 한 대에서 초당 100만 건을 직접 넘겨 봅니다.
01
Redis 명령어는 아는데,
캐시 운영은 다른 얘기였습니다
02
Valkey와 Redis 차이 — 라이선스 · 호환성 · 성능
Valkey는 2024년 3월 Redis 라이선스 변경 직후 Redis 7.2.4를 포크해 만든 BSD 라이선스 오픈소스 인메모리 키-값 데이터베이스입니다. Linux Foundation이 관리하고 AWS·Google Cloud·Oracle이 개발을 지원하며, Redis 프로토콜·명령어와 호환됩니다. 지금 인메모리 DB를 새로 배운다면 이 갈림길부터 보는 편이 이해가 빠릅니다.
- BSD 라이선스 그대로, 완전 오픈소스
- Linux Foundation 산하 · AWS·Google Cloud·Oracle이 개발 지원
- 포크 이후 I/O 스레딩 재설계 등 성능에 집중 투자
- AWS ElastiCache에서 같은 사양이면 Redis 엔진보다 저렴
- 2024년 3월 BSD에서 RSALv2·SSPLv1(소스 공개형, OSI 비승인)로 전환
- 2025년 Redis 8부터 AGPLv3 선택지 추가
- 원조 프로젝트, 두터운 자료 생태계
- 프로토콜·명령어는 Valkey와 호환
이 강의는 Valkey 9.1 기준으로 진행하지만 프로토콜이 호환되므로, Redis 강의를 찾는 분도 같은 명령·같은 운영 개념을 배웁니다. Redis를 쓰다 오신 분께는 Valkey에서 달라진 지점(기본값 개선·신기능)을 강의 중간중간 짚어 드립니다. 팀이 Valkey로 옮길 때 그 일을 맡는 사람은 먼저 운영해 본 사람입니다.
03
Valkey 운영 핵심 개념 — 싱글 스레드 · 경쟁 상태 · Sentinel · 파이프라이닝
제조사 벤치마크를 옮겨 적지 않았습니다. 아래 장면의 수치는 전부 강사가 같은 노트북에서 직접 실행해 얻은 값이고, 강의에서는 이걸 터미널에서 그대로 재현합니다. 잘 안 나온 결과도 잘라 내지 않습니다.
싱글 스레드와 BUSY 에러 —
느린 명령 하나가 서버 전체를 멈춥니다
Valkey는 명령을 한 번에 하나씩 처리하는 싱글 스레드 구조입니다. 무거운 Lua 스크립트가 실행되는 동안 평소 7밀리초짜리 PING이 4.5초를 기다렸고, 점유가 5초를 넘기면 뒤이은 클라이언트는 BUSY 에러를 받습니다. 이 장면을 직접 만들어 보고 SLOWLOG와 --bigkeys로 원인을 찾습니다.
PING 대기 7ms → 4.5초. 5초를 넘기면 BUSY.
경쟁 상태(race condition)와 원자 연산 —
GET과 SET 사이에 다른 요청이 끼어듭니다
경쟁 상태는 두 클라이언트가 같은 값을 읽고 같은 값을 써서 한쪽 변경이 사라지는 현상입니다. 동시 구매 50건을 처리했는데 차감은 4건만 반영돼 재고가 46으로 남았습니다. DECRBY 한 줄의 원자 연산, SET NX PX와 unlock.lua로 만드는 소유자 토큰 분산락, 조건부 차감 Lua 스크립트로 0건까지 막습니다.
동시 구매 50건 중 46건이 차감 누락 → 원자 연산으로 0건. 실행할 때마다 46, 47로 달라지는 것이 경쟁 상태의 특징입니다.
Sentinel 자동 failover —
장애 판정과 승격을 사람 없이 처리합니다
Sentinel은 마스터를 감시하다가 장애로 판정되면 복제본 하나를 새 마스터로 승격시키는 Valkey의 고가용성 프로세스이고, failover(장애 조치)는 그 역할을 넘겨받는 과정입니다. 응답이 5초(down-after) 끊기면 각 Sentinel이 주관적 다운으로 표시하고, 쿼럼 2가 모이면 객관적 다운으로 확정합니다. 마스터 프로세스를 직접 종료하고, 잠시 두 마스터가 보이는 구간과 강등·따라잡기까지 관찰합니다.
마스터를 종료하고 15초 뒤 새 마스터가 승격돼 있습니다.
파이프라이닝(pipelining)과 처리량 —
병목은 서버가 아니라 왕복(round trip)이었습니다
파이프라이닝은 응답을 기다리지 않고 여러 명령을 한 번에 보내 왕복 횟수를 줄이는 방식입니다. 서버도 명령도 그대로 두고 왕복만 10개씩 묶었더니 처리량이 6.6배 벌어졌고, 16개로 늘리고 조건을 맞추면 133만까지 갑니다. 반대로 I/O 스레드를 6개로 늘렸더니 오히려 GET이 12% 느려진 실측도 그대로 보여 드립니다. 무엇이 진짜 병목인지 강의 마지막에 직접 뜯어봅니다.
명령 수는 그대로, 왕복만 줄였습니다. 노트북 한 대 GET 기준 1,331,558 RPS.
04
Valkey Cluster · 영속성 · Lua, 실제 터미널 화면 그대로입니다
Valkey Cluster는 키 공간을 16,384개 해시 슬롯으로 나눠 여러 노드에 분산 저장하는 샤딩 구성이고, RDB는 특정 시점의 스냅숏 파일, AOF는 쓰기 명령을 순서대로 남기는 로그 파일입니다. 강의에서 직접 다루는 네 장면을 짧게 잘라 두었습니다.
05
작은 이커머스로 배우는 캐시 전략 · 분산락 · Sentinel · Cluster
자료구조를 순서대로 외우지 않습니다. 서비스에 기능이 필요해지는 순간마다 도구를 꺼냅니다. 강의를 마치면 캐시부터 클러스터 운영까지 갖춘 이커머스 백엔드 저장소 하나가 남고, 그게 그대로 포트폴리오가 됩니다.
- 상품 페이지가 느리다캐시를 답니다 — String, TTL, cache-aside(캐시에 없을 때만 DB에서 읽어 채우기), 스탬피드 방어
- 손님이 상품을 담는다장바구니와 세션 — Hash, 슬라이딩 만료
- 인기 순위를 보여주자찜과 랭킹 — Set, ZSet, HyperLogLog, Bitmap
- 주문이 몰리자 재고가 사라진다동시성 사고 재현 — 원자 연산, 분산락, Lua
- 주문 뒤처리가 밀려든다이벤트 파이프라인 — List 큐, Pub/Sub, Stream 소비자 그룹
- 명령어를 코드로TypeScript 미니 프로젝트 — iovalkey 클라이언트, CLI와 코드가 1:1로 대응
- 껐다 켜면 사라진다영속성과 메모리 — RDB, AOF, eviction, SLOWLOG·--bigkeys 진단
- 서버 한 대가 죽는다면복제와 Sentinel — 자동 failover를 직접 관찰
- 데이터가 한 대보다 커진다면Valkey Cluster(Redis Cluster 호환) — 해시 슬롯, 온라인 리샤딩, 클러스터 failover
- 처리량을 끝까지 끌어올린다I/O 스레딩을 켰는데 오히려 느려지는 실측을 보고, 진짜 병목을 찾아 노트북에서 100만 돌파
06
Valkey 도입 사례 — 클라우드와 대형 서비스가 옮겨 가고 있습니다
2024년 라이선스 변경 이후 클라우드와 대형 서비스가 Valkey로 옮겨 가고 있습니다. Amazon Ads는 Valkey로 전환하며 인프라 비용을 45% 줄였고 처리량은 12% 올랐습니다. Aiven은 Redis로 돌리던 서버 15,000대를 3개월 만에 Valkey로 옮겼습니다. Valkey 9.0은 2,000노드 클러스터에서 초당 10억 요청을 처리한다고 발표했습니다(2025).
AWS ElastiCache와 Google Cloud Memorystore가 Valkey를 관리형 엔진으로 제공하고, ElastiCache에서는 같은 사양이면 Redis 엔진보다 쌉니다. 그런데 옮기고 나면 운영은 결국 사람이 합니다. 복제를 붙이고, failover를 확인하고, 슬롯을 다시 나누는 일이요. 이 강의가 그 부분을 다룹니다.
출처: Valkey 9.0·9.1 릴리스 노트 · AWS Database Blog(Valkey turns two, Amazon Ads 사례) · Aiven 마이그레이션 사례. 회사명은 공개된 사례를 밝히기 위한 표기이며, 이 강의와 제휴 관계는 없습니다.
07
포트폴리오와 이력서에 그대로 쓰는 여섯 줄
"Redis를 사용해 봤습니다"와 "동시 구매 50건에서 나던 과판매를 0건으로 만들었습니다"는 다른 문장입니다. 뒤쪽을 쓰려면 사고를 직접 내 보고 직접 재 봐야 하고, 이 강의가 그 과정입니다.
여섯 줄 모두 이 강의에서 직접 만들고 직접 측정하는 것들입니다. 면접에서 "그래서 어떻게 확인하셨어요"라는 질문이 들어와도 답할 게 남습니다.
08
네이버 백엔드 개발자가 만든 Valkey 강의
Ande — 네이버 백엔드 개발자
네이버 본사에서 서버를 개발하는 10년차 백엔드 개발자입니다. 재고가 마이너스로 찍히는 사고, 캐시가 한꺼번에 만료되면서 DB가 휘청이는 상황처럼 강의에서 재현하는 장면들은 대부분 현장에서 실제로 겪은 것들입니다. 질문은 강사가 직접 확인하고 답합니다.
“잘 나온 숫자만 보여 드리지 않습니다. 안 나온 숫자에서 더 많이 배우거든요.”
現 네이버 서버(본사) 개발자 · 前 신세계 그룹 백엔드 개발자 · 前 헬스케어 스타트업 서버 개발자
Hong — 판교 플랫폼 서버 개발자
판교에서 플랫폼 서버를 개발하며 이 강의의 커리큘럼을 짜고 촬영을 맡았습니다. Redis만 알던 사람에게 Valkey를 왜 봐야 하는지부터 설명해야 했고, 그 순서를 그대로 강의에 담았습니다. 오픈채팅방에서 질문에 답합니다.
취업했다고,
이직했다고 연락이 올 때가 있어요
강의를 듣다 막히는 부분, 본인 회사의 Redis를 Valkey로 옮기면서 생기는 질문, 커리어와 현업 이야기를 나누는 오픈채팅방입니다.
서버를 직접 죽여 보고, 100만을 직접 넘겨 보세요
재고 사고를 원자 연산으로 막고, 마스터를 죽였다 되살리고, 6노드 클러스터를 직접 세웁니다. 끝나면 면접에서 "직접 해 봤습니다"라고 말할 장면이 남습니다.