Ops Insights – Redis · Valkey · Memcached

2009 첫 커밋부터 6.2 까지

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

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 제약)의 전제가 여기서 굳었습니다.

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

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

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 는 자료구조를 서버에서 실행하기로 한 대가로 실행 스레드를 하나로 묶었습니다. 이 문서는 그 교환을 소스와 릴리스노트로 확인합니다.

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

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

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 는 돌아가지 않았습니다. 라이선스가 원인이었다면 이 시점에 봉합됐어야 합니다. 원인은 라이선스가 아니었습니다. 단일 벤더가 프로젝트의 라이선스를 일방적으로 바꿀 수 있는 구조가 원인이었고 라이선스 변경은 그 구조를 드러낸 방아쇠였습니다.

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

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

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 까지 실제로 무엇이 들어왔는지, 그중 운영자가 업그레이드 전에 손을 대야 하는 것이 무엇인지 봅니다.

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

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

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 로 거절당합니다. 이 문서는 그 어긋남을 설정 이름·기본값·소스 경로로 확정합니다.

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

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

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년에 어떻게 바뀌었는지를 다룹니다.

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

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

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 로 노출한 결과물입니다. 편의를 위해 붙인 별칭이 아닙니다. 모드를 바꾸면 주소 구조가 바뀝니다. 주소 구조가 바뀌면 클라이언트 라이브러리의 종류가 바뀌고 클라이언트가 바뀌면 애플리케이션의 다중 키 연산까지 바뀝니다. 이 연쇄를 끊어서 보면 어느 단계에서든 사고가 납니다. 연쇄를 알면 엔드포인트 문자열만 보고도 그 앱이 무엇을 해야 하는지 판정할 수 있습니다.

Redis·Valkey·Memcached 판단표

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

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 에 미확인으로 남겼습니다.

Redis·Valkey·Memcached 참고 자료

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

출처 — 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만 골라 중복을 걷고 주제별로 묶었습니다.