Valkey 9: Redis 포크가 SIMD와 I/O 스레딩으로 독자적 진화를 시작한 방식

라이선스 하나가 생태계를 바꿨다

2024년 3월, Redis Ltd.는 Redis의 라이선스를 BSD에서 SSPL(Server Side Public License)과 RSALv2 이중 라이선스로 변경했다. 클라우드 제공업체가 Redis를 상용 서비스로 제공할 때 소스코드를 공개하거나 라이선스를 구매해야 하는 조항이다. AWS, Google Cloud, Oracle 등 주요 클라우드 벤더가 즉시 영향을 받았다.

같은 달, Linux Foundation은 Valkey를 공식 출범시켰다. Redis의 마지막 BSD 버전(7.2.4)을 포크 기점으로 삼았다. AWS, Google, Oracle, Snap, Ericsson 등이 초기 참여했다. 포크 첫 해 만에 Valkey는 주요 클라우드 매니지드 서비스의 기본 선택지가 됐다.

2025년 10월 21일 Valkey 9.0이 출시됐고, 2026년 5월 19일 Valkey 9.1이 뒤따랐다. 9.1은 90일 이내 릴리스이며 이 장의 주된 분석 대상이다. 9.0은 9.1을 이해하는 데 필요한 직전 맥락으로 함께 다룬다.

이 장은 Valkey 공식 블로그, Linux Foundation 보도자료, AWS ElastiCache 발표, Phoronix 릴리스 분석을 기준으로 한다. 성능 수치는 Valkey 팀의 내부 벤치마크 결과이며 워크로드와 하드웨어에 따라 다를 수 있다.

Valkey 9 아키텍처 진화 개요

Valkey 9 주요 변화 — 9.0과 9.1 릴리스 진화 경로

Valkey 9.0: 하드웨어를 최대한 쓰는 엔진 개편 (2025-10-21)

Valkey 9.0의 핵심 주제는 단순하다. 이미 존재하는 서버 하드웨어에서 더 많은 처리량을 끌어낸다. 새로운 스케일아웃 인프라 없이 단일 서버의 한계를 높인다.

SIMD 가속

Valkey 9.0은 x86 AVX512와 ARM NEON을 대상으로 한 SIMD 가속을 여러 핫패스에 적용했다. AVX512 문자열-정수 변환 경로는 CPU 시작 시 IFUNC 리졸버로 하드웨어 능력을 감지해 최적 코드 경로를 선택한다. 설정 변경이나 소프트웨어 수정 없이 해당 CPU에서 자동으로 활성화된다.

이 최적화는 CPU 명령 레벨의 병렬화다. 데이터 처리 루프에서 한 번에 여러 요소를 처리해 같은 클럭에 더 많은 작업을 완료한다.

Pipeline 메모리 프리페치

클라이언트가 여러 명령을 한 번에 파이프라인으로 보낼 때, Valkey 9.0은 다음 명령이 필요로 할 메모리를 CPU 캐시에 미리 올려둔다. 실제 명령 처리 시 캐시 미스로 인한 대기가 줄어든다.

Valkey 팀의 벤치마크에서 파이프라인 워크로드 처리량이 최대 +40% 향상됐다. 일반 단일 명령 워크로드에서는 효과가 제한적이다. 파이프라인을 적극 사용하는 배치 워크로드나 내부 캐시 갱신 패턴에서 효과가 크다.

Hash Field Expiration — 데이터 모델의 변화

해시 키 전체에 TTL을 거는 것과 달리, 해시 안의 개별 필드에 만료 시간을 설정하는 기능이다. 세션 스토리지, 토큰 캐시, 사용자 권한 캐시처럼 "키 전체"가 아니라 "필드 일부"가 만료되는 패턴에 정확하게 대응한다.

# 필드 단위 TTL 설정
HSETEX session:u1001 300 token "abc123"   # token 필드 300초 후 만료
HSETEX session:u1001 86400 profile "..."  # profile 필드 1일 후 만료

# TTL 조회 / 유지
HTTL session:u1001 FIELDS 1 token   # 남은 TTL 반환
HPERSIST session:u1001 FIELDS 1 token  # TTL 제거

이 기능 이전에는 필드별 만료를 구현하려면 별도 키를 만들거나 Sorted Set으로 만료 시각을 추적하는 복잡한 패턴이 필요했다. 해시 하나로 동일 로직을 표현할 수 있게 됐다.

클러스터 확장성

Valkey 9.0에서 단일 클러스터가 2,000 노드까지 안정적으로 동작하도록 복원력 개선이 이뤄졌다. Valkey 팀의 테스트 환경에서 클러스터 합계 10억 req/s를 달성한 사례가 보고됐다. 이는 대규모 지역 분산 캐시나 글로벌 세션 스토어 구성에서 의미있는 수치다.

Valkey 9.1: 운영자가 직접 느끼는 변화 (2026-05-19)

Valkey 9.1의 주제는 두 방향이다. 하나는 성능의 측면에서 처리 경로 전반을 최적화하는 것이고, 다른 하나는 보안과 운영의 측면에서 프로덕션 환경에서 필요한 기능을 보강하는 것이다.

I/O 스레딩 모델 재설계

Valkey 9.1은 I/O 스레딩 통신 모델을 전면 재설계했다. Valkey는 명령 실행 자체는 싱글 스레드지만, 네트워크 I/O(읽기·쓰기)는 별도 스레드로 처리할 수 있다. 9.1은 이 I/O 스레드와 메인 스레드 간의 통신 방식을 개선해 불필요한 컨텍스트 스위칭과 락 경합을 줄였다.

Valkey 팀 벤치마크 결과:

측정 항목	결과
전반적 처리량 향상	+17% (다양한 워크로드 평균)
단일 서버 최대 처리량	2.1M req/s (512-byte payload, 9 I/O 스레드, 파이프라인 깊이 10)
XRANGE / XREVRANGE 스트림 조회	+30% 빠름 (스트림 범위 핫패스 최적화)
문자열 GET 처리량	+30% 향상 (임베딩 임계값 상향)

9 I/O 스레드 설정은 고성능 서버에서만 효과적이다. 코어가 4개 이하인 서버에서는 기본값(I/O 스레드 비활성화 또는 최소 설정)이 오히려 낫다.

메모리 효율화

Valkey 9.1은 내부 데이터 표현 방식을 바꿔 설정 변경이나 데이터 이관 없이 메모리 사용량을 줄였다.

데이터 유형	개선폭
전반적 키당 메모리	-10%
128바이트 미만 문자열	-20% (내부 포인터 최적화)
정렬된 집합(Sorted Set)	-10% (skiplist 구조 최적화)

메모리를 추가 확보하지 않고도 같은 인스턴스에 더 많은 데이터를 올릴 수 있게 된다. 이미 메모리 한계에 근접한 인스턴스는 업그레이드만으로 여유가 생긴다.

DB-level ACL — 멀티테넌트 격리

기존 Valkey(및 Redis)의 ACL은 명령 수준 제어는 가능했지만 데이터베이스(0~15번 DB) 수준의 분리가 부족했다. 9.1은 Numbered Database-level ACL을 도입해 사용자가 특정 데이터베이스에서 실행할 수 있는 명령을 데이터베이스 번호별로 제어한다.

# 사용자 app1에게 DB 0에서만 GET/SET 허용, DB 1 이상 차단
ACL SETUSER app1 on >password ~* +GET +SET %R~db0:*

# 사용자 analytics에게 DB 2 읽기 전용
ACL SETUSER analytics on >password ~db2:* +GET +HGET +LRANGE

단일 Valkey 인스턴스에 여러 서비스나 테넌트가 DB를 나눠 쓰는 구성에서 서비스 간 명령 격리가 가능해진다. 이전에는 테넌트 격리를 위해 Valkey 인스턴스 자체를 분리해야 했다.

TLS 인증서 자동 재로딩

Valkey 9.1 이전에는 TLS 인증서가 만료되거나 교체될 때 Valkey를 재시작해야 했다. 9.1은 새 인증서를 감지해 재시작 없이 자동으로 불러온다.

# 인증서 갱신 후 수동으로 재로딩 트리거 (필요시)
CONFIG SET tls-reorder-cert yes

# 자동 감지: 파일 mtime 변경 시 자동 재로딩

인증서 갱신 주기가 짧은 환경(Let's Encrypt 90일, 내부 CA 30일)이나 대규모 Valkey 클러스터에서 재시작 없이 인증서를 교체할 수 있다는 것은 유지보수 부담을 크게 줄인다.

Redis에서 Valkey로 마이그레이션할 때 알아야 할 것

호환되는 것

RESP2 / RESP3 프로토콜 — 기존 클라이언트 라이브러리(jedis, lettuce, redis-py, ioredis) 설정 변경 없이 사용 가능

RDB 파일 포맷 — Redis 7.x RDB를 Valkey에서 직접 로드 가능. 데이터 재적재 불필요

명령어 API — 거의 모든 Redis 명령이 동일. HSETEX 같은 Valkey 전용 신규 명령은 Redis에 없음

복제 프로토콜 — Redis 주종 구성을 Valkey로 점진 교체 가능 (혼합 모드 주의사항 있음)

주의할 차이점

Redis Stack 모듈(RediSearch, RedisJSON 등)은 Valkey에서 직접 지원되지 않음. 대체 모듈 또는 기본 기능으로 구현 검토 필요

Redis Enterprise 고급 기능(Active-Active, CRDT)은 Valkey에 없음

메이저 버전 간 직접 복제(Redis 7.x primary → Valkey 9.x replica)는 철저한 검증 후 진행

ACL 규칙 문법 일부가 Valkey에서 확장됨. Redis ACL 규칙은 호환되나 반대 방향은 확인 필요

권장 마이그레이션 순서

1. 스테이징 환경에서 Valkey 9.1 구성 후 동일 RDB 파일 로드 → 데이터 정합성과 명령 호환성 검증

2. 클라이언트 라이브러리 동작 검증 — 연결 문자열을 Valkey 엔드포인트로 변경 후 기능 테스트 수행

3. 단일 레플리카부터 교체 → 복제 지연·데이터 일관성 모니터링 후 프라이머리 교체

4. 매니지드 서비스(ElastiCache, Memorystore) 이용 시 콘솔에서 Valkey 9.1 엔진 버전 선택만으로 마이그레이션 가능

Redis → Valkey 마이그레이션 판단 기준

운영 체크리스트: Valkey 9.1 도입 전 확인 사항

I/O 스레딩 설정: io-threads 값은 CPU 코어 수에 맞게 설정한다. 권장값은 코어 수의 절반이다. 8코어 서버에서 io-threads 4가 출발점이다. 벤치마크로 실제 워크로드에서 최적값을 찾는다. io-threads-do-reads yes를 설정하면 읽기 I/O도 스레드로 처리한다.

메모리 용량 재산정: 9.1 업그레이드 후 키당 메모리가 최대 10% 줄어든다. 기존 maxmemory 설정을 유지하면 같은 공간에 더 많은 데이터가 올라간다. 예상치 못한 데이터 증가가 없는지 메모리 사용 추이를 며칠간 모니터링한다.

DB-level ACL 설계: 단일 인스턴스에 여러 서비스가 올라와 있다면 9.1의 DB-level ACL로 서비스 간 명령 격리를 구현한다. 이전에는 테넌트 분리를 위해 별도 인스턴스가 필요했던 경우다.

TLS 운영: 자동 인증서 재로딩이 활성화된 경우, 갱신된 인증서 파일 경로와 권한이 Valkey 프로세스에서 읽힐 수 있는지 확인한다. 갱신 후 INFO server로 TLS 인증서 정보가 갱신됐는지 검증한다.

정리

Valkey 9.1(2026-05-19)은 같은 하드웨어에서 더 많은 처리량과 더 적은 메모리를 동시에 달성한다. I/O 스레딩 재설계로 처리량이 평균 +17% 향상됐고, 내부 포인터 최적화로 키당 메모리가 최대 -20% 줄었다. XRANGE, 문자열 GET 같은 특정 명령은 각각 +30% 개선됐다.

운영 측면에서는 DB-level ACL로 멀티테넌트 격리가 실질적으로 가능해졌고, TLS 자동 재로딩으로 무중단 인증서 교체가 가능해졌다.

Redis에서 이관을 고려한다면 RESP 프로토콜과 RDB 포맷 호환성 덕분에 클라이언트 코드 수정 없이 이관이 가능하다. Redis Stack 모듈 의존성이 있다면 대체 경로를 먼저 확보한 뒤 이관을 진행한다.

Valkey 9.0의 SIMD, 파이프라인 프리페치, Hash Field TTL이 성능과 데이터 모델을 확장했다면, 9.1은 그 기반 위에서 운영 현장의 요구를 채웠다.