개요
Redis Laps가 SSPL로 전환하면서, Redis 7.x 버전을 fork한 Valkey Engine 프로젝트가 시작되었다. Valkey 7.x는 Redis 7.x를 그대로 fork한 것과 다름 없어서, 마이그레이션을 할 때 클라이언트 라이브러리를 변경하는 것 이외에는 크게 신경 쓸 점이 없다. 하지만 Valkey 8.x Engine부터는 Redis와 꽤 다른 지점이 생긴다. 직접 ElastiCache Redis, Valkey Engine을 생성해서 마이그레이션 과정을 정리해본다.
1. 기본적인 읽기 전용 Cache
기본 환경 정보
- Node Type: cache.t4g.small
- Cluster Mode: Enabled
- Shards/Nodes: 1개 / 2개
- Encryption in transit/rest: Disabled
1.1 ElastiCache Redis에 CLI를 통해 데이터 넣기 & 기본 정보 확인
ElastiCache Redis → Valkey 마이그레이션 전후 비교를 위해서 기본 정보를 확인해본다.
- 반복문으로 데이터 넣기
for i in {1..100000}; do
redis-cli -h <endpoint> SET "key:$i" "value:$i"
done- 데이터가 잘 들어갔는지 확인(DBSIZE, GET KEY)
- Cluster Mode Info 확인
- Replication Info 확인
- Replica(=Slave) 노드가 1개 붙어있다.
- lag=0: Primary와 Replica 사이의 지연 없음
- 현재 Failover 상황 아님!
- offset: 복제 로그의 위치를 뜻한다.
1.2 redis-benchmark를 통한 GET 요청(읽기) 성능 테스트
redis-benchmark 명령어를 통해 간단하게 성능을 비교해본다.
redis-benchmark -h "$H" -p 6379 -n <총 요청 수> -c <동시 연결 수> -t <테스트할 명령>
100,000개의 key를 넣고 성능 테스트를 했을 때, 결과를 해석해보면,
- QPS(초당 처리량)은 3313.45로, 1초 당 약 3300개의 요청을 처리했다는 뜻이다. 네트워크 왕복 시간까지 합쳐서 계산하게 되는데, 나는 로컬 PC에서 redis-benchmark를 수행하였고, 실제 같은 VPC에 존재하는 인스턴스에서 실행하면 더 빠른 성능을 보일 수 있다.
- 지연시간 분포(percentile) 중 50퍼센타일. 즉, 전체 요청 중 절반은 약 14.9ms 이하로 걸렸다는 뜻이다.
redis-benchmark -h "$H" -n 100000 -c 50 -t get
- -c: 동시에 클라이언트 N(50) 개를 생성하여 병렬로 요청을 보내는 것처럼하는 옵션이다.
- -t: 테스트할 명령어를 지정한다.
100,000개의 key를 넣고, 50개의 클라이언트를 만들어서 성능 테스트를 했을 때, 결과를 해석해보면,
- 총 10만 건의 요청을 126.48초에 처리했다. 이는 약 790 QPS(초당 처리량) 수준이다.
- 동시에 50개 클라이언트 연결을 유지했다.
- 각 값(value)는 3 byte 문자열
- 대부분의 요청(p99) 이 0.1초 이내(280ms)에 처리되었다.
1.3 TTL 값 확인
Redis 엔진에서 Key의 수명을 설정하고, Valkey로 마이그레이션 했을 때 이 TTL이 유효한지 검증해본다.
TTL(Time To Live)는 키의 남은 수명을 보여준다.
- 양수: 해당 키가 만료되기까지 남은 초
- -1 : 키가 존재하지만, 만료 시간 설정이 없음. 즉, 영구 키를 뜻한다.
- -2: 키가 존재하지 않음. 즉, 이미 만료되었거나 삭제되었다.
Valkey로 마이그레이션 이후 이 TTL 설정이 잘 남아있는지 확인하기 위해 특정 키(500)에 대해서 TTL(expire)을 설정했다. 초 단위로 TTL을 설정할 수 있기에, 604800초 == 7일로 부여했다.
2. Redis 7.x → Valkey 8.x 마이그레이션 이후, 지표 확인해보기
Redis 7.x → Valkey 8.x 전환에는 boto3의 modify_replication_group API를 사용하였다. parameter_group 또한 같은 워크플로우 내에서 API로 변경하였다. 사내 배포 플랫폼을 통해 변경하였기 때문에 이 부분은 내부 시스템에만 적용된다는 점.. API 이외에도 콘솔에서 Modify하거나 Upgrade to Valkey를 하면되는데, 이 각 방법의 차이점은 AWS Support 미팅 이후에 추가해볼 예정이다!
2.1 CLI를 통해 Valkey Engine 기본 정보 확인
Redis Engine에서 Valkey Engine으로 마이그레이션하고, 데이터 변동 사항을 redis-cli를 통해 확인해본다.
- 데이터가 잘 있는지 확인(DBSIZE, GET KEY)
- Cluster Mode Info 확인
- Replication Info 확인
Valkey로 in-place 전환 즉, 엔진 교체가 이루어지면서 Primary Node의 재시작이 일어나서 master_replid가 재생성된 점을 확인할 수 있다. 여기서 second_repl_offset이 마이그레이션 이전에는 -1이었는데, 그 이유는 Redis Engine에서는 재시작이나 failover가 없었기 때문이다. Valkey로 엔진 교체를 하면서 replid가 한번 바뀌었고, 이 점이 반영되어 second_repl_offset 값이 바뀌었다.
- Master: Primary Node
- second_repl_offset: 이전 master_replid가 마지막으로 유효했던 offset 위치)
2.2 redis-benchmark를 통한 GET 요청(읽기) 성능 테스트
Redis Engine에서 Valkey Engine으로 마이그레이션 한 후, 간단한 성능테스트를 통해 두 엔진 간 차이를 실제로 확인해본다.
오..? 사실 크게 기대 안했는데 읽기 성능이 월등히 좋아진 점이 확인된다.
- 10만 건 요청을 Redis Engine에 비해서 약 6배 정도(126초 → 28초) 더 빠르게 처리한 점을 확인할 수 있다.
- 대부분의 요청(p99)이 46ms 정도로 처리되었고, 이 또한 이전 테스트에 비해서 약 7배 정도(280ms → 46ms) 성능이 좋아졌다.
2.3 TTL 값 확인
Redis Engine에 설정한 Key TTL이 마이그레이션 이후에도 잘 남아있는지 확인해본다.
처음 설정한 TTL 이후에 한 8시간(28,800초)이 지났으니까 Key TTL 설정값도 문제없이 마이그레이션 된 점을 확인할 수 있다..!
알게된 점
이렇게 Redis -> Valkey Engine을 직접 마이그레이션하면서 기본 정보들을 알아보았다. 실제로 직접 해보는 거랑 문서로 보는 거랑은 차이가 많이 나서, 기본적이지만 베이스가 되는 것들을 직접 살펴보니 와닿는 것도 많았다. Valkey가 진짜 성능이 좋은게 확 느껴졌다.
또 redis-cli 명령어 사용법도 익힐 수 있었고, TTL 설정이나 Primary Node의 재시작 관점도 눈여겨 볼 수 있었다. 사실 Redis/Valkey Client 변경 사항이 가장 클 것같은데... 이점은 AWS Support 미팅에서 잘 챙겨봐야겠다.
'DB > In-Memory DB' 카테고리의 다른 글
| [Redis] Redis 운영 지식: redis 모니터링 명령어 정리 (0) | 2026.03.02 |
|---|---|
| [Redis] 메모리 지표 Raboja & Redis 메모리 정책 (1) | 2026.01.11 |
| [Redis] 캐시와 Redis, ElastiCache (3) | 2025.08.16 |
