[DevOps] Redis 7.x → Valkey 8.x 마이그레이션 PoC

개요

---

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 번의 GET 요청으로 부하 테스트를 진행한다.

 

100,000개의 key를 넣고 성능 테스트를 했을 때, 결과를 해석해보면,

1. QPS(초당 처리량)은 3313.45로, 1초 당 약 3300개의 요청을 처리했다는 뜻이다. 네트워크 왕복 시간까지 합쳐서 계산하게 되는데, 나는 로컬 PC에서 redis-benchmark를 수행하였고, 실제 같은 VPC에 존재하는 인스턴스에서 실행하면 더 빠른 성능을 보일 수 있다.
2. 지연시간 분포(percentile) 중 50퍼센타일. 즉, 전체 요청 중 절반은 약 14.9ms 이하로 걸렸다는 뜻이다.

redis-benchmark -h "$H" -n 100000 -c 50 -t get

50개의 클라이언트로 100,000 번의 GET 요청 부하 테스트를 진행한다.

 

• -c: 동시에 클라이언트 N(50) 개를 생성하여 병렬로 요청을 보내는 것처럼하는 옵션이다.
• -t: 테스트할 명령어를 지정한다.

100,000개의 key를 넣고, 50개의 클라이언트를 만들어서  성능 테스트를 했을 때, 결과를 해석해보면,

1. 총 10만 건의 요청을 126.48초에 처리했다. 이는 약 790 QPS(초당 처리량) 수준이다.
2. 동시에 50개 클라이언트 연결을 유지했다.
3. 각 값(value)는 3 byte 문자열
4. 대부분의 요청(p99) 이 0.1초 이내(280ms)에 처리되었다.

1.3 TTL 값 확인

Redis 엔진에서 Key의 수명을 설정하고, Valkey로 마이그레이션 했을 때 이 TTL이 유효한지 검증해본다.

key: 12, {1..5}에 대한 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)

오 Key-Value 쌍이 문제 없이 잘 남아있는 모습 확인

• Cluster Mode Info 확인

Cluster State ok에 Node도 2개로 잘 마이그레이션된 점을 확인할 수 있다. Redis일 때와 크게 다른 점은 없어 보인다.

• 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 미팅에서 잘 챙겨봐야겠다.