Valkey-proxy, 기존 Redis 클라이언트로 클러스터를 쓸 수 있을까?
여러 노드의 키를 한 번에 읽는 MGET은 되는데 RENAME은 CROSSSLOT 오류로 막힌다. 기존 Redis 클라이언트를 그대로 두고 클러스터로 옮기면 어떤 명령까지 쓸 수 있을까?
- Valkey-proxy는 단일 서버에 연결하던 앱 앞에서 클러스터의 요청 라우팅을 맡는다.
- MGET처럼 결과를 모아 주는 명령이 있지만, 트랜잭션과 SELECT까지 그대로 쓸 수 있는 상태는 아니다.
- 소스와 테스트가 공개됐으며, Percona가 제시한 정식 출시 목표는 2027년 초다.
연결 코드를 덜 바꿀 수 있지만, 사용하는 명령을 봐야 한다
Valkey-proxy는 기존 단일 노드용 Redis·Valkey 클라이언트로 클러스터에 접근하려는 프로젝트다. 앱이 프록시의 주소로 요청을 보내면 프록시가 키를 담당하는 노드를 찾는다. 여러 키를 읽는 MGET은 노드별로 나눠 요청하고 원래 키 순서에 맞춰 응답을 모은다.
그러나 연결 방식이 단순해진다고 앱의 모든 명령이 그대로 동작하는 것은 아니다. 현재 공개된 명령 지원표에서 MULTI, EXEC, WATCH는 개발 예정으로 표시돼 있다. 연결한 뒤 논리 DB를 바꾸는 SELECT도 미지원 목록에 있다. 이 기능들에 의존하는 앱은 접속 주소 변경만으로 전환을 끝낼 수 없다.
Percona는 10월 7일 프로젝트를 발표하며 정식 출시를 2027년 초 목표로 제시했다. 10월 26일 기준 저장소에는 소스·빌드 파일·통합 테스트가 공개돼 있지만, GitHub Releases에 등록된 릴리스는 없다. 지금의 도입 판단은 공개 코드와 명령 지원 범위를 기준으로 해야 한다.
클러스터는 요청을 받은 노드가 모든 키를 대신 찾아 주지 않는다
Valkey 클러스터는 키를 해시 슬롯에 배정하고 슬롯을 여러 노드에 나눈다. 클러스터 명세에 따르면 요청을 잘못 받은 노드는 담당 노드로 명령을 대신 전달하지 않고 클라이언트에 이동할 곳을 알려 준다. 이때 만나는 응답이 MOVED 같은 리디렉션이다.
클러스터를 이해하는 클라이언트는 슬롯과 노드의 관계를 관리하고 알맞은 노드로 요청한다. 반면 단일 서버만 가정한 앱은 같은 서버 주소에 연결된다는 사실만으로 이 동작을 얻지 못한다. 클러스터 전환이 연결 문자열 교체보다 큰 작업이 되는 이유다.
Valkey-proxy는 이 처리를 앱 밖으로 옮긴다. 기능 문서는 키별 전달, 여러 노드로 요청을 나누는 처리, 연결 풀을 설명한다. 다만 앱이 신경 쓸 일이 줄어든 만큼 운영 대상에는 프록시가 추가된다.
MGET이 된다고 모든 여러 키 명령이 되는 것은 아니다
명령별로 키를 나눌 수 있는 조건이 다르다. MGET의 분산 조회와 MSETNX의 같은 슬롯 제한을 구별해야 한다.
| 앱에서 사용하는 기능 | 현재 공개 문서의 처리 | 전환할 때 볼 부분 |
|---|---|---|
| MGET | 키별 요청 후 원래 순서로 응답을 조립한다. | 여러 노드에 흩어진 키의 조회 결과다. |
| MSETNX·RENAME | 관련 키가 같은 슬롯에 있어야 한다. | 다른 슬롯이면 CROSSSLOT이 남는다. |
| EVAL·EVALSHA | 사용하는 키가 같은 슬롯에 있어야 한다. | 기존 Lua 코드의 키 구성을 확인한다. |
| MULTI·EXEC·WATCH | 개발 예정이다. | 트랜잭션을 쓰는 경로의 대체 여부다. |
| SELECT | 미지원이다. | 연결 후 DB 번호를 바꾸는 코드다. |
해시 태그로 관련 키를 같은 슬롯에 배치하는 방법은 Valkey 클러스터의 기존 기능이다. 프록시가 앱의 키 이름을 자동으로 설계해 주는 것은 아니다. 여러 노드에 요청을 보내 결과를 합치는 기능도 분산 트랜잭션 보장과 같은 뜻으로 읽어서는 안 된다.
PING 성공보다 실제 읽기·쓰기 경로가 중요하다
프록시를 평가할 첫 자료는 앱이 실제로 보내는 명령 목록이다. 연결 직후 실행하는 명령, 다중 키 작업, Lua와 트랜잭션 사용 여부를 지원표와 대조하면 수정할 지점을 좁힐 수 있다. Redis에서 Valkey로 서버 자체를 바꾸는 경우에는 데이터와 버전의 이관 호환성도 별도로 적용된다.
연결 검사도 구체적이어야 한다. 기능 문서상 PING은 프록시가 백엔드 요청 없이 답하는 명령이다. 따라서 PONG을 받았다는 사실만으로 실제 데이터 노드까지 읽기·쓰기가 정상이라고 판정할 수 없다.
기존 클라이언트를 유지할 가능성은 열렸지만, 전환 기준은 앱이 사용하는 명령의 의미가 보존되는지다. 단순 조회와 저장 위주의 앱, 트랜잭션·DB 전환에 기대는 앱을 같은 난이도로 잡아서는 안 된다.