Redis와 Valkey 차이부터 AWS 마이그레이션까지

Redis를 Valkey로 바꿀지 고민할 때 가장 먼저 볼 것은 엔진 이름이 아니다.

현재 Redis 버전은 무엇인지, 그 안에 어떤 데이터를 넣어 두었는지, Redis만의 기능을 쓰고 있는지부터 알아야 한다.
AWS 같은 관리형 서비스에서는 전환 비용과 되돌아갈 수 있는 범위도 함께 봐야 한다.

결론부터 말하면, 일반적인 캐시·세션·작업 큐처럼 Redis의 기본 명령을 중심으로 사용하고 있다면 Valkey 전환을 우선 검토할 만하다. 반대로 상품 검색을 Redis Search와 JSON으로 구현했거나 Redis Cloud의 전용 운영 기능에 기대고 있다면, 이름만 바꾸기 전에 필요한 기능이 실제로 대체되는지 확인해야 한다.

이 글에서는 Redis와 Valkey의 차이를 처음부터 설명한다.
그다음 어떤 상황에서 어느 쪽을 선택할지, AWS에서는 어떤 방식으로 옮길 수 있는지, 내가 맡았던 운영 전환에서는 무엇을 먼저 확인했는지 순서대로 살펴본다.

Redis는 빠른 캐시보다 역할이 넓다

Redis는 데이터를 주로 메모리에 두고 빠르게 읽고 쓰는 데이터 저장소다.
메모리는 디스크보다 접근이 빠르기 때문에 같은 데이터를 자주 조회하는 서비스에서 특히 유용하다.

상품 상세 화면을 예로 들어 보자.
화면을 열 때마다 데이터베이스에서 같은 상품 정보를 읽으면 요청이 몰릴수록 데이터베이스의 일이 늘어난다.
첫 조회 결과를 Redis에 product:123 같은 이름으로 보관해 두면 다음 요청부터는 Redis에서 빠르게 가져올 수 있다.

여기서 product:123처럼 값을 찾을 때 쓰는 이름을 키(key)라고 한다.
키에는 문자열뿐 아니라 목록, 집합, 순위가 있는 집합 같은 자료구조도 담을 수 있다.

Redis를 캐시로 많이 쓰기는 하지만 캐시만 저장하는 것은 아니다.
로그인 상태인 세션, 처리할 작업을 줄 세우는 큐, 같은 작업이 동시에 실행되지 않도록 막는 분산 잠금에도 사용할 수 있다.

이 차이는 마이그레이션의 위험도를 크게 바꾼다.

Redis에 넣은 것	사라졌을 때 생길 수 있는 일	전환 전에 볼 것
다시 만들 수 있는 캐시	요청이 한꺼번에 원본 DB로 몰릴 수 있다	다시 채우는 속도, DB 여유
로그인 세션	사용자가 로그아웃되거나 인증 흐름이 끊길 수 있다	값과 TTL 보존
작업 큐	대기 중인 작업이 빠지거나 중복 처리될 수 있다	처리 중·대기 중 항목
분산 잠금	같은 작업이 동시에 실행될 수 있다	소유자와 만료 시간
속도 제한용 카운터	제한 횟수가 예상보다 일찍 초기화될 수 있다	집계 구간과 TTL

TTL(Time To Live)은 키가 자동으로 사라질 때까지 남은 시간이다.
값만 복사하고 TTL을 처음부터 다시 시작하면 세션이나 잠금이 원래보다 오래 남을 수 있다.

그래서 “키가 모두 복사됐다”만으로는 전환 성공을 판단하기 어렵다.
각 키가 서비스에서 어떤 의미를 가지는지 먼저 알아야 한다.

Valkey는 Redis OSS 7.2에서 출발한 별도 프로젝트다

Valkey는 2024년에 Redis OSS 7.2.4의 코드를 바탕으로 시작한 인메모리 데이터 저장소다.
Redis OSS는 당시 공개되던 Redis의 오픈 소스 배포판을 가리키는 이름이다.
기존 소스 코드를 복사해 별도 방향으로 개발하는 것을 포크(fork)라고 한다.

Valkey는 Linux Foundation 아래에서 여러 조직의 참여자가 운영하고, BSD-3-Clause 라이선스를 사용한다.
BSD는 소프트웨어의 사용과 수정, 재배포에 비교적 적은 제약을 두는 라이선스다.
누가 기술 방향을 결정하는지를 나타내는 운영 구조를 거버넌스(governance)라고 하는데, Valkey는 특정 회사 한 곳보다 재단과 참여 조직이 함께 이끄는 구조를 택했다.

Redis는 Redis Ltd.가 개발 방향과 제품을 이끈다.

Redis Open Source 8의 세 라이선스는 하나를 고르는 방식이다

Redis Open Source 8 이상의 삼중 라이선스(tri-license)는 RSALv2, SSPLv1, AGPLv3 조건을 모두 지켜야 한다는 뜻이 아니다.
Redis를 사용하는 사람이나 조직이 세 가지 중 하나를 선택하고, 선택한 라이선스의 조건을 따르는 방식이다.
Redis Cloud와 Redis Software 같은 상용 제품에는 별도의 계약이 적용되므로 이 세 라이선스 표와 같은 범위로 보면 안 된다.

라이선스는 무료·유료 요금제의 차이가 아니다.
Redis 코드를 수정하거나 다른 사람에게 배포할 때, 또는 Redis 자체의 기능을 외부 서비스로 제공할 때 지켜야 하는 규칙이다.

소스 코드를 볼 수 있다는 말과 오픈 소스라는 말도 완전히 같지 않다.
세 라이선스 모두 소스는 공개돼 있지만, OSI(Open Source Initiative)가 오픈 소스로 승인한 것은 AGPLv3다.
RSALv2와 SSPLv1은 사용 목적에 별도 조건을 둔 소스 공개(source available) 라이선스다.
OSI는 누구나 사용·수정·재배포할 수 있는지 같은 오픈 소스 기준을 관리하는 비영리 단체다.
각 이름은 Redis Source Available License v2, Server Side Public License v1, GNU Affero General Public License v3의 약자다.

라이선스	성격	일반 웹서비스가 Redis를 내부 저장소로 사용할 때	Redis 자체를 외부 서비스로 제공할 때
RSALv2	OSI 오픈 소스는 아니며, 일반적인 소스 공개 의무가 없는 라이선스다	수정하지 않은 Redis를 쇼핑몰의 캐시·세션 저장소로 쓰는 일반적인 사용은 허용된다	고객이 Redis 기능을 직접 쓰는 관리형 데이터베이스 상품으로 제공하는 것은 허용하지 않는다
SSPLv1	GPLv3를 바탕으로 한 강한 소스 공개 라이선스이며 OSI 승인은 받지 않았다	Redis와 통신한다는 이유만으로 별도 웹앱 전체가 자동 공개되는 것은 아니다	Redis 기능을 서비스로 제공하면 수정 코드뿐 아니라 관리 UI·API·백업·모니터링 등 서비스 운영 코드까지 공개 조건을 검토해야 한다
AGPLv3	OSI가 승인한 강한 카피레프트 오픈 소스 라이선스다	수정하지 않은 별도 Redis 서버에 앱이 접속한다는 사실만으로 앱 전체가 자동 공개되지는 않는다	수정한 Redis를 네트워크로 사용하게 하면 원격 사용자에게 실행 중인 수정판의 대응 소스를 받을 방법을 제공해야 한다

여기서 카피레프트(copyleft)는 상업적으로 사용할 수 없다는 뜻이 아니다.
라이선스가 적용되는 프로그램을 수정해 배포하거나 네트워크로 제공할 때, 그 사용자도 해당 소스를 보고 다시 수정할 권리를 가질 수 있도록 같은 계열의 조건을 이어 가는 방식이다.
SSPL의 바탕이 된 GPLv3와 AGPLv3가 이 원칙을 강하게 적용하는 라이선스다.
AGPLv3가 적용된 프로그램을 배포할 때는 해당 프로그램의 대응 소스와 라이선스 조건을 제공해야 하고, 수정판을 네트워크로 실행할 때는 원격 사용자에게도 그 수정판의 소스를 받을 방법을 추가로 제공해야 한다.

일반 쇼핑몰의 Node.js 서버가 별도 Redis에 접속해 장바구니 캐시를 저장하는 경우와, 고객에게 Redis 인스턴스를 만들어 주고 명령 실행 권한을 파는 관리형 Redis 서비스는 성격이 다르다.
앞의 경우는 보통 앱 전체 소스 공개보다 버전·보안·운영 지원을 먼저 검토한다.
뒤의 경우에는 RSALv2의 서비스 제공 제한, SSPLv1의 광범위한 서비스 소스 공개 조건, AGPLv3의 수정판 소스 제공 조건을 실제 제품 구조에 맞춰 따져야 한다.

이 설명은 라이선스 원문을 이해하기 위한 기술적 안내이며 법률 자문은 아니다.
Redis 코드를 앱에 직접 결합했거나 수정판을 고객에게 제공하는 제품이라면 실제 배포 구조를 법무 또는 오픈 소스 담당자와 확인하는 편이 안전하다.

호환성은 7.2 이하에서 가장 분명하다

Valkey 공식 문서는 Redis OSS 7.2 이하에서 Valkey로 옮길 때 네트워크 프로토콜, 설정 형식, RDB·AOF 데이터 파일이 호환된다고 설명한다.
RDB는 특정 시점의 데이터를 저장하는 스냅샷 파일이고, AOF(Append Only File)는 데이터 변경 명령을 순서대로 남기는 파일이다.

Redis와 Valkey가 같은 말을 알아듣게 하는 RESP

애플리케이션은 Redis 서버에 자바스크립트 함수나 HTTP 요청을 그대로 보내지 않는다.
앱 안의 클라이언트 라이브러리가 SET user:42:name 소신 같은 명령을 서버가 읽을 수 있는 메시지로 바꿔 전송한다.
Node.js에서 자주 쓰는 redis나 ioredis가 이 역할을 맡는다.

이때 클라이언트와 서버가 함께 사용하는 메시지 형식이 RESP(REdis Serialization Protocol)다.
웹 브라우저와 웹 서버가 HTTP 규칙에 맞춰 대화하듯이, Redis 클라이언트와 Redis·Valkey 서버는 RESP 규칙에 맞춰 명령과 결과를 주고받는다.
RESP는 암호화 기술이나 개발 라이브러리가 아니라, 네트워크에서 명령과 응답을 표현하는 약속이다.

개념적으로는 앱이 ["SET", "user:1", "광천"]을 보내면 서버가 OK를 돌려주고, ["GET", "user:1"]을 보내면 "광천"을 돌려주는 흐름이다.
실제 바이트 변환과 응답 해석은 클라이언트 라이브러리가 처리하므로 개발자가 RESP 문자열을 직접 만들 일은 거의 없다.

구분	RESP2	RESP3
성격	오랫동안 기본으로 사용된 버전	RESP2를 확장한 버전
응답 표현	문자열·정수·배열 중심	map·set·boolean·null·double·push 같은 자료형을 별도로 표현
확인할 점	오래된 클라이언트도 널리 지원한다	사용하는 클라이언트 버전이 RESP3 응답을 원하는 언어의 값으로 올바르게 바꾸는지 확인한다

RESP3는 RESP2보다 무조건 빠르다는 뜻이 아니다.
응답의 의미를 더 정확한 자료형으로 표현하도록 확장한 버전에 가깝다.
Redis와 Valkey 모두 RESP2와 RESP3를 지원하지만, 프로토콜 호환과 제품 전체의 호환은 다른 문제다.
마이그레이션 때는 연결 성공뿐 아니라 앱이 실제 반환값과 사용하는 기능을 올바르게 처리하는지도 봐야 한다.

Redis Stack은 검색·JSON 같은 기능을 기본 엔진에 더하던 확장 기능 묶음이고, 이런 확장 요소 하나를 모듈(module)이라고 한다.

• Redis Community Edition 7.4 이상에서 만든 RDB·AOF 파일은 Valkey와 호환되지 않는다.
• Redis Open Source 8에는 검색, JSON, 시계열, 확률 자료형 같은 Redis Stack 기능이 통합됐다.
• Valkey도 8·9 계열에서 독자 기능을 추가하며 별도로 발전하고 있다.
• 같은 이름의 모듈이나 명령이 있어도 지원 범위와 운영 방식이 같다는 보장은 없다.

비교할 항목	Redis	Valkey	선택에 미치는 영향
개발·운영 주체	Redis Ltd.	Linux Foundation 산하 커뮤니티	지원 계약과 거버넌스 선호가 다르다
현재 라이선스	Redis Open Source 8 이상은 RSALv2·SSPLv1·AGPLv3 중 하나를 선택	BSD-3-Clause	일반 앱의 내부 사용과 관리형 서비스 제공은 구분해서 봐야 한다
공통 기준선	원 프로젝트	Redis OSS 7.2.4에서 포크	7.2 이하의 기본 사용 패턴은 호환성이 높다
이후 기능	Redis Open Source 8 통합 기능	Valkey 8·9의 독자 기능	새 기능과 모듈은 항목별로 비교해야 한다
AWS ElastiCache	Redis OSS와 Valkey 모두 지원	Redis OSS와 Valkey 모두 지원	버전·가격·롤백 범위가 다르다

어떤 상황에서 Valkey를 선택하면 좋을까

Valkey가 Redis보다 항상 빠르거나 좋은 것은 아니다.
이름을 바꾸는 것보다 전환으로 얻는 이점이 검증 비용과 장애 위험보다 큰지를 보는 편이 낫다.

Valkey를 먼저 검토할 만한 경우

• ElastiCache의 오래된 Redis OSS를 사용하고 있어 새 엔진으로 올려야 한다.
• 문자열·해시·목록·집합·Streams 같은 기본 자료형과 일반 명령이 중심이다.
• Linux Foundation 거버넌스와 BSD 라이선스가 조직의 운영 방향에 맞는다.
• AWS 비용을 줄일 여지가 있다.
• 개발 환경에서 클라이언트·명령·데이터·재연결을 먼저 검증할 수 있다.

Redis를 유지하는 편이 나을 수 있는 경우

Valkey가 기본 Redis 명령과 호환된다고 해서 이미 사용 중인 모든 기능을 같은 방식으로 대체할 수 있는 것은 아니다.
Redis 자체 기능이나 Redis Cloud의 운영 방식이 서비스 설계에 들어가 있다면 기능별 대체 가능성을 확인하기 전까지 Redis를 유지하는 편이 안전하다.
색인(index)은 모든 데이터를 처음부터 훑지 않고도 원하는 항목을 빨리 찾도록 미리 정리한 구조다.
RAG(Retrieval-Augmented Generation)는 생성형 AI가 답하기 전에 관련 문서를 검색해 근거로 넣는 방식이고, 벡터 검색은 단어가 정확히 같지 않아도 의미가 가까운 문서나 상품을 찾는다.
시계열 데이터는 시간에 따라 계속 쌓이는 온도나 CPU 사용률 같은 값이며, Active-Active는 여러 리전이 동시에 쓰기를 받는 구성을 말한다.
아래 표의 FT.*, JSON.*, TS.*는 각각 Redis Search, JSON, 시계열 기능에 속한 명령 계열이다.

서비스 예시	Redis를 유지할 이유	Valkey 전환 전에 확인할 것
상품명·브랜드·가격을 함께 검색하고 자동완성을 제공하는 쇼핑몰	Redis Search와 JSON 문서로 검색 색인과 필터를 구성했을 수 있다	FT.*, JSON.* 명령과 색인 정의, 검색 결과 순서가 같은 방식으로 동작하는가
관련 문서를 먼저 찾은 뒤 AI가 답하는 RAG 서비스나 상품 추천	의미가 비슷한 문서를 찾는 벡터 검색과 일반 조건 검색을 한 번에 쓰고 있을 수 있다	벡터 자료형·색인 방식·검색 정확도와 클라이언트가 호환되는가
센서값·주가·서버 지표를 시간순으로 보여 주는 대시보드	Redis 시계열 자료형과 TS.* 명령으로 보존 기간과 집계를 구성했을 수 있다	시계열 명령과 집계 규칙, 기존 데이터를 옮길 방법이 있는가
여러 국가에서 동시에 상태를 갱신하는 주문·사용자 서비스	Redis Cloud Active-Active로 여러 리전에서 읽기와 쓰기를 받고 충돌을 조정할 수 있다	대상 서비스가 같은 다중 리전 쓰기 모델을 제공하는가
상용 지원과 Redis 전용 운영 도구가 장애 대응 절차에 포함된 기업 서비스	기술 지원 계약, Redis Insight, 배포 자동화와 관제 절차까지 바꾸는 비용이 생긴다	기능 가격뿐 아니라 지원 체계와 운영 절차의 교체 비용을 감당할 수 있는가

이 서비스들이 무조건 Redis만 써야 한다는 뜻은 아니다.
Valkey에도 유사 기능이나 별도 모듈이 있을 수 있다.
다만 현재 구현이 Redis 전용 명령·색인·제품 운영 방식에 깊이 의존한다면 엔진 교체가 아니라 기능 재설계가 되므로 검증 범위가 커진다.

반대로 작은 사내 도구의 단순 캐시가 안정적으로 동작하고 비용·지원 종료·보안 문제도 없다면, Redis 기능이 더 뛰어나서가 아니라 당장 옮겨 얻는 이익이 작아 전환을 미룰 수 있다.
어떤 서비스가 어떤 키를 쓰는지 파악되지 않았거나 Redis 7.4 이상에서 만든 데이터 파일을 그대로 옮기려는 경우는 “Redis 유지”보다 조사 전까지 전환 중단에 가깝다.

AWS에서는 제자리 변경과 병행 전환이 다르다

Amazon ElastiCache는 AWS가 Redis·Valkey 서버 생성, 장애 노드 교체와 모니터링 기반을 대신 관리하는 캐시 서비스다.
팀은 엔진·버전·용량·네트워크와 데이터의 의미를 결정하고, AWS는 서버 운영의 반복 작업 일부를 맡는다.

노드 기반은 팀이 서버 한 대의 크기와 대수를 직접 정하는 방식이다.
Serverless는 서버가 없다는 뜻이 아니라 AWS가 요청량에 맞춰 용량을 조절하고 사용량 기준으로 과금하는 방식이다.
2026년 7월 AWS 안내 기준으로 ElastiCache for Valkey는 노드 기반에서 Redis OSS보다 20%, Serverless에서 최대 33% 낮은 가격을 제시한다.
Serverless의 최소 과금 저장량도 Valkey는 100MB, Redis OSS는 1GB다.
실제 절감액은 리전, 노드 크기, 요청량, 백업과 데이터 전송 비용까지 넣어 다시 계산해야 한다.

단일 노드, 복제와 클러스터 모드는 서로 다른 말이다

AWS 화면에서는 노드가 한 대뿐인 구성도 “클러스터”라고 부를 때가 있어 용어가 특히 헷갈린다.
노드(node)는 Redis나 Valkey 서버 한 대다.
primary는 쓰기를 받는 원본 노드이고, replica는 primary의 데이터를 계속 복사해 두는 읽기 전용 노드다.
AWS는 shard와 그 안의 primary·replica를 함께 관리하는 단위를 replication group이라고 부른다.
Cluster mode disabled에서는 primary 1개와 0~5개의 replica를 담고, Cluster mode enabled에서는 이런 shard를 여러 개 담을 수 있다.

복제와 샤딩은 목적이 다르다.
복제는 같은 데이터를 여러 노드에 복사해 장애에 대비하거나 읽기 요청을 나누는 방식이다.
샤딩(sharding)은 전체 키를 여러 조각으로 나눠 서로 다른 primary 노드에 맡기는 방식이다.
데이터 조각 하나와 그 조각을 맡은 노드 묶음을 shard라고 부른다.

AWS 구성	데이터가 놓이는 방식	장애와 확장 특성	어울리는 예시
단일 노드	모든 키를 노드 한 대가 보관하고 읽기와 쓰기를 모두 처리한다	replica와 자동 장애 조치가 없다. 노드가 실패하면 캐시를 다시 채우거나 백업에서 복구해야 한다	개발·테스트 환경, 사라져도 원본 DB에서 다시 만들 수 있는 작은 캐시
Cluster mode disabled 복제 그룹	shard 하나에 primary 1개와 replica를 둔다. 모든 노드가 같은 데이터의 사본을 가진다	replica를 새 primary로 올리는 자동 장애 조치를 구성할 수 있고 읽기를 나눌 수 있다. 데이터와 쓰기는 여러 primary로 나뉘지 않는다	로그인 세션, 일반 API 캐시처럼 데이터가 primary 한 대의 메모리와 쓰기 처리 범위에 들어오는 서비스
Cluster mode enabled	키를 여러 shard에 나누고 각 shard에 primary와 필요에 따라 replica를 둔다	메모리와 쓰기를 여러 primary로 수평 확장할 수 있다. cluster mode를 이해하는 클라이언트와 키 설계가 필요하다	한 노드에 담기 어려운 대규모 캐시, 키와 쓰기 요청이 많은 시스템

Cluster mode disabled는 replica가 없다는 뜻이 아니라 샤딩하지 않는다는 뜻이다.
shard는 하나지만 그 안에 primary와 여러 replica를 둘 수 있다.
앱은 쓰기를 primary endpoint로 보내고, 읽기는 reader endpoint를 이용해 replica들로 나눌 수 있다.
reader endpoint는 요청을 대신 전달하는 일반적인 로드 밸런서가 아니라 replica의 IP를 번갈아 알려 주는 DNS 주소다.
primary가 쓰기를 처리할 수 없을 때 replica를 새 primary로 올리는 과정을 장애 조치(failover)라고 한다.
AWS의 자동 장애 조치는 replica가 최소 1개 있고 Multi-AZ와 Automatic Failover를 활성화한 구성에서 사용할 수 있다.
Multi-AZ는 같은 리전의 서로 떨어진 데이터센터 구역에 노드를 나누어 두는 옵션이고, Automatic Failover는 장애가 난 primary 대신 replica를 자동으로 승격하는 설정이다.
이때 기존 연결이 잠깐 끊길 수 있다.
replica는 잘못 삭제한 데이터도 그대로 복제하므로 과거 시점으로 돌아가는 백업과는 다르다.

Cluster mode enabled에서는 Redis Cluster가 모든 키를 16,384개의 hash slot 가운데 하나에 배정하고, 각 shard가 일정 범위의 slot을 맡는다.
Hash slot은 키를 어느 shard로 보낼지 정하는 중간 번호표다.

애플리케이션은 cluster mode를 이해하는 클라이언트로 configuration endpoint에 연결해야 한다.
configuration endpoint는 여러 shard의 현재 배치를 찾기 위한 클러스터용 접속 주소다.
클라이언트는 키가 속한 slot과 담당 primary를 찾아 요청을 보내고, 구성이 바뀌면 서버의 이동 안내를 따라 새 노드로 다시 보낸다.
여러 키를 한 명령에서 함께 처리할 때는 키들이 같은 slot에 있어야 하는 제약도 생길 수 있다.
따라서 RESP를 지원하는 클라이언트라고 해서 cluster mode까지 자동으로 지원하는 것은 아니다.

Global Datastore는 여러 리전에 둔 복제 묶음이다

단일 노드와 cluster mode는 한 AWS 리전 안에서 데이터를 어떻게 배치할지 정한다.
여기서 리전(region)은 서울, 도쿄처럼 AWS 데이터센터를 지역별로 묶은 운영 단위다.
Global Datastore는 노드 기반 ElastiCache 클러스터를 여러 리전에 연결한다.

서울 리전의 primary 클러스터가 주문 조회용 캐시의 읽기와 쓰기를 받는다고 해 보자.
도쿄에 secondary 클러스터를 두면 서울에서 바뀐 데이터가 도쿄로 비동기 복제되고, 도쿄 애플리케이션은 가까운 secondary에서 읽을 수 있다.
비동기는 primary가 secondary의 저장 완료를 기다리지 않고 다음 일을 처리하는 방식이라 빠르지만, 두 리전의 값이 잠시 다를 수 있다.

secondary는 평소 읽기만 받는다.
primary 리전에 문제가 생겨도 다른 리전으로 자동 전환되지 않으며, 운영자가 secondary를 primary로 승격하고 애플리케이션 연결을 새 primary로 돌릴 계획을 준비해야 한다.
장애 직전에 아직 복제되지 않은 최근 변경은 잃을 수도 있다.

범위	쓰기 위치	복제 방식	주된 목적
같은 리전의 replica	shard의 primary	일반적인 구성은 primary에서 replica로 비동기 복제	노드 장애 대응, 읽기 분산
Global Datastore	primary 리전의 primary 클러스터	다른 리전의 secondary 클러스터로 비동기 복제	가까운 리전에서 읽기, 리전 장애 복구

Redis Cloud Active-Active와 Global Datastore는 이름이 비슷해 보여도 같은 기능이 아니다.
Active-Active는 여러 리전에서 쓰기를 받지만, Global Datastore는 한 primary 리전만 쓰기를 받고 secondary 리전은 읽기 전용이다.

인플레이스 전환과 병행 전환

AWS ElastiCache에서 Redis OSS를 Valkey로 바꾸는 공식 기본 경로는 인플레이스 교차 엔진 업그레이드다.
인플레이스는 새 캐시를 따로 만들지 않고 기존 리소스의 엔진을 바꾸는 방식이다.

AWS는 현재 지원하는 Redis OSS 버전에서 지원하는 Valkey 버전으로 전환할 수 있다고 안내한다.
endpoint는 앱이 접속하는 호스트 이름과 포트를 합친 주소다.
DNS는 cache.internal 같은 이름을 현재 노드의 IP로 바꿔 주므로 endpoint 문자열이 같아도 뒤의 서버는 바뀔 수 있다.
인플레이스 전환에서는 애플리케이션이 사용하는 endpoint의 DNS 이름이 유지되지만 노드 기반 클러스터의 실제 IP 주소는 바뀐다.

Redis OSS 5.0.6 이상은 업그레이드 중 읽기가 계속 가능하고, 쓰기는 장애 조치가 일어나는 수 초를 제외하면 대부분 가능하다.
5.0.6보다 낮은 버전은 DNS 전파 때문에 30~60초의 장애 조치 시간이 생길 수 있다.
따라서 “무중단”이라고 가정하기보다 클라이언트의 재연결과 재시도를 실제로 시험해야 한다.

파라미터 그룹은 키 만료 방식이나 메모리가 찼을 때 어떤 키를 지울지 같은 엔진 설정을 묶은 템플릿이다.
Redis용 사용자 지정 그룹을 Valkey에 그대로 붙일 수 있다고 가정하지 말고, 대상 버전용 그룹을 만든 뒤 설정 차이를 비교해야 한다.
단일 노드에서 인플레이스 교차 엔진 업그레이드를 하려면 먼저 기존 노드를 replication group에 넣어야 하는 등 구성별 선행 조건도 확인해야 한다.

방식	인플레이스 전환	별도 환경을 둔 병행 전환
준비할 리소스	기존 리소스에서 엔진 변경	새 Valkey 환경을 따로 준비
endpoint	DNS 이름은 유지될 수 있다	애플리케이션의 연결 대상을 바꾼다
데이터 이동	AWS의 엔진 업그레이드 과정에 포함	복사·동기화 방식을 별도로 설계
장점	운영할 리소스와 전환 단계가 적다	새 환경을 충분히 관찰할 수 있다
주의점	지원 버전과 롤백 범위가 좁다	두 환경의 데이터 차이와 추가 비용이 생긴다
어울리는 상황	현재 구성을 유지한 채 공식 경로로 올릴 때	TLS·크기·토폴로지까지 함께 바꾸거나 단계적 전환이 필요할 때

AWS가 지원하는 인플레이스 역전환은 현재 Valkey 7.2에서 Redis OSS 7.1로 돌아가는 경우로 제한된다.
Valkey 8이나 9로 바로 올리면 같은 방식으로 Redis OSS에 되돌아가는 경로가 없다.
롤백이 중요하다면 목표 버전까지 한 번에 올리지 말고 전환 단계를 나눌 이유가 여기에 있다.

롤백은 단순한 실행 취소 버튼이 아니다.
백업 스냅샷을 복원하면 과거 시점의 새 캐시를 만드는 것이므로 그 뒤에 들어온 쓰기는 잃을 수 있다.
병행 전환에서도 Valkey가 새 쓰기를 받은 뒤 endpoint만 기존 Redis로 되돌리면 두 저장소의 데이터가 달라져 있다.
역동기화할 방법, 쓰기를 멈출 시점, 어느 정도의 데이터 손실을 허용할지를 전환 전에 정해야 실제 롤백 계획이 된다.

별도 환경을 두는 방식은 흔히 Blue/Green이라고 부르지만, 이 글에서 Blue와 Green은 AWS의 특정 제품 이름이 아니다.
기존 Redis와 새 Valkey를 구분하기 위한 운영 명칭이다.

AWS의 가상 서버 서비스인 EC2에서 직접 운영하는 Redis나 Valkey를 ElastiCache로 옮길 때는 AWS Online Migration을 사용할 수 있다.
이 기능은 자체 호스팅 환경에서 ElastiCache로 복제하는 용도이며, ElastiCache 클러스터끼리 옮기는 일반적인 수단은 아니다.

내 경우에는 엔진보다 옮기는 순서가 문제였다

내가 맡은 작업은 이미 운영 중인 Redis를 Valkey로 전환하고 데이터를 이관한 뒤 endpoint를 바꾸는 일이었다.
기존 환경에는 여러 서비스가 연결돼 있었고 Redash 같은 분석 도구도 별도 소비자로 남아 있었다.

기록을 다시 보니 이것은 엔진 하나만 교체하는 작업이 아니었다.
레거시 키 정리, 개발 환경 검증, 암호화 연결, 레플리카와 인스턴스 크기 조정, 운영 데이터 이관이 서로 연결돼 있었다.

그래서 완료 조건을 네 가지로 나눴다.

1. 필요 없는 데이터를 새 환경까지 가져가지 않는다.
2. 개발 환경에서 연결과 암호화를 먼저 확인한다.
3. 운영 데이터 이관과 endpoint 전환을 한 단계로 취급하지 않는다.
4. 웹 서비스 밖에서 Redis를 쓰는 소비자도 따로 찾는다.

불필요한 키부터 줄였다

2026년 5월 14일, 개발 환경의 전환을 시작하기 전에 레거시로 분류된 키 약 15만 건을 먼저 정리했다.

오래된 키를 그대로 복사하면 이관할 양만 늘어나는 것이 아니다.
새 환경에서 어떤 키가 실제로 필요한지 확인하기도 어려워진다.

다만 개수가 많다는 이유만으로 지우면 안 된다.
소유 서비스와 사용 여부가 확인된 레거시 데이터만 정리하고, 세션·큐·잠금처럼 의미가 남아 있는 키는 별도로 다뤄야 한다.

개발에서 암호화와 연결을 먼저 바꿨다

같은 날 개발 환경에서는 Redis 암호화 설정과 병행 전환을 먼저 진행했다.

TLS(Transport Layer Security)는 애플리케이션과 저장소 사이의 통신을 암호화하는 방식이다.
엔진과 TLS 연결을 운영에서 한꺼번에 처음 바꾸면 연결 실패가 명령 호환성 때문인지, 인증서나 연결 설정 때문인지 나누어 보기 어렵다.

개발 환경 선행은 이 두 문제를 분리해 확인할 시간을 만들어 줬다.

운영 데이터와 endpoint를 옮겼다

5월 18일에는 운영 Valkey 전환, 데이터 이관, endpoint 변경을 진행했다.
데이터 동기화 차이를 줄이기 위해 트래픽이 적은 새벽 시간을 선택했다.

같은 작업 묶음에서 레플리카 구성을 확인하고 인스턴스 크기를 조정했으며, 평문 Redis 연결도 차단했다.
새 환경을 크게 만들어 놓고 끝내지 않고 실제 사용량에 맞출 준비까지 함께 한 셈이다.

같은 endpoint 이름이 남아 있어도 이미 열려 있던 연결은 새 노드로 순간 이동하지 않는다.

클라이언트는 기존 연결이 끊겼을 때 DNS를 다시 조회하고 새 IP에 연결할 수 있어야 한다.
재시도를 넣을 때는 간격을 조금씩 늘리고 무작위 차이를 섞는 지수 백오프와 지터를 함께 쓰는 편이 안전하다.
모든 서버가 같은 순간에 재접속해 캐시에 또 다른 부하를 만드는 일을 줄이기 위해서다.

Redash는 별도 소비자로 남아 있었다

주요 서비스의 endpoint를 바꿨다고 전환이 모두 끝난 것은 아니었다.
5월 21일에는 Redash가 사용하던 Redis를 Valkey로 바꾸고 관련 EC2 환경도 업데이트했다.

이 후속 작업에서 얻은 기준은 분명했다.
마이그레이션 목록은 서버가 아니라 소비자를 기준으로 만들어야 한다.

웹 애플리케이션뿐 아니라 배치, 분석 도구, 관리자 도구처럼 같은 저장소를 읽는 주체를 따로 찾아야 빠뜨리지 않는다.

전환 뒤 실제 사용량을 다시 봤다

6월 15일에는 Valkey 최적화 항목과 사용량 모니터링을 다시 점검했다.

새 endpoint가 응답한다고 마이그레이션이 끝난 것은 아니다.
운영에서는 다음 값을 전환 전의 비슷한 트래픽 시간대와 비교했다.

• hit rate는 100번의 조회 가운데 캐시가 바로 답한 비율이다.
  갑자기 떨어지면서 원본 DB 요청이 늘면 키가 덜 옮겨졌거나 TTL 정책이 달라졌을 수 있다.
• eviction은 메모리가 찼을 때 엔진이 정책에 따라 기존 키를 내보내는 동작이다.
  횟수가 계속 늘면 노드 용량, TTL과 삭제 정책을 함께 확인해야 한다.
• 연결 오류와 원본 DB 부하는 재연결 실패와 캐시 미스를 함께 보여 준다.
  둘이 동시에 늘면 엔진 성능보다 연결 전환이나 데이터 누락을 먼저 의심할 수 있다.

hit rate가 높다고 언제나 좋은 것은 아니며 서비스 특성과 키 사용 방식에 따라 정상 범위가 다르다.
같은 조건의 전후 값을 비교해야 인스턴스 크기와 TTL 정책이 실제 사용량에 맞는지 판단할 수 있다.

같은 전환에 바로 쓸 체크리스트

아래는 당시 기록을 그대로 옮긴 목록이 아니라, 공식 문서와 작업 경험을 합쳐 다시 만든 권장 순서다.
표에 나오는 Lua 스크립트는 Redis 서버 안에서 여러 명령을 한 번에 실행하는 작은 프로그램이다.

단계	확인할 질문	통과 기준
범위 파악	Redis 버전과 배포 형태, 모든 소비자는 무엇인가	서비스·배치·Redash 같은 분석 도구까지 목록에 있다
데이터 분류	키는 캐시·세션·큐·잠금 중 무엇인가	원본과 허용 가능한 손실 범위를 설명할 수 있다
호환성	명령, Lua 스크립트, 모듈, 클라이언트가 대상 버전에서 동작하는가	운영과 같은 조건의 개발 환경에서 확인했다
보안	TLS, 인증, 사용자 권한과 파라미터 그룹이 맞는가	평문 우회 경로 없이 연결된다
기준선	키 수, TTL 표본, 메모리, hit rate, eviction, 오류율은 얼마인가	전환 전후를 같은 기준으로 비교할 수 있다
데이터 이관	값과 TTL, 처리 중인 큐 항목이 보존되는가	단순 키 개수 외에 기능 동작으로 확인했다
endpoint 전환	DNS 재조회와 재연결, 재시도가 동작하는가	기존 연결을 끊어도 새 노드로 복구된다
운영 관찰	오류·지연·DB 부하가 허용 범위인가	미리 정한 중단 조건을 넘지 않는다
기존 환경 제거	되돌아갈 필요가 없다고 판단할 근거가 있는가	관찰 시간을 통과하고 소비자 누락이 없다

정확한 명령어를 복사하는 것보다 이 표의 답을 먼저 적는 편이 안전하다.
AWS 지원 버전과 파라미터 조건은 계속 바뀔 수 있으므로 실제 변경 직전에는 콘솔과 공식 문서를 다시 확인해야 한다.

마이그레이션의 완료 조건은 엔진 이름이 아니다

이 작업에서 확인되는 결과는 운영 Valkey 전환, 데이터 이관과 endpoint 변경, 평문 연결 차단, Redash 후속 전환까지 완료했다는 것이다.
이후에는 실제 사용량을 바탕으로 최적화와 모니터링도 다시 점검했다.

운영 전후 성능이나 비용 수치는 남아 있는 기록으로 확인할 수 없어 임의로 만들지 않았다.
대신 다음 전환에서는 기준선을 먼저 저장해 오류율, 지연, hit rate, eviction, DB 부하와 실제 비용을 같은 기간끼리 비교할 수 있도록 했다.

Redis와 Valkey 중 하나를 고르는 기준은 유행이 아니다.
서비스가 어떤 데이터를 맡기고 있는지, 필요한 기능이 호환되는지, 클라우드가 안전한 전환과 롤백 경로를 제공하는지가 먼저다.

기존 Redis가 재생성 가능한 캐시 중심이고 공식 지원 경로와 롤백 계획이 있다면 Valkey 전환은 충분히 검토할 수 있다.
세션·큐·잠금의 소유 관계가 불분명하거나 Redis 전용 기능에 의존한다면 엔진부터 바꾸지 말고 데이터와 소비자 목록부터 만드는 편이 안전하다.

참고 자료

• Redis Open Source 소개
• Redis 라이선스 안내
• Redis Source Available License v2 원문
• Server Side Public License v1 원문
• GNU Affero General Public License v3 원문
• Redis Serialization Protocol 명세
• Redis Cluster의 hash slot 설명
• Redis 데이터 자료형과 통합 기능
• Redis Cloud Active-Active 설명
• Valkey 프로젝트 소개
• Valkey의 Redis 마이그레이션 가이드
• Valkey RESP 프로토콜 설명
• ElastiCache Redis OSS에서 Valkey로 교차 엔진 업그레이드
• ElastiCache 엔진 업그레이드 고려 사항
• ElastiCache 노드·클러스터·샤드 설명
• ElastiCache endpoint 종류
• ElastiCache Global Datastore 설명
• ElastiCache Global Datastore 승격과 장애 복구
• ElastiCache for Valkey FAQ
• ElastiCache Online Migration 범위