Redis Cluster에서 hash tag로 관련 키를 같은 슬롯에 배치할 때 원자성·분산·재시도에 어떤 제약이 생기나요?

Redis Cluster는 키를 슬롯으로 나누므로 여러 키를 한 명령이나 Lua 스크립트에서 함께 사용하려면 일반적으로 같은 슬롯에 있어야 합니다. 키에서 첫 여는 중괄호 뒤 첫 닫는 중괄호 사이가 비어 있지 않으면 그 부분을 hash tag로 사용합니다. 빈 중괄호 등은 규칙이 달라 전체 키가 해시될 수 있습니다. {acct:42}:balance와 {acct:42}:ledger는 같은 계정 태그를 공유하므로 한 슬롯에 배치할 수 있습니다. 이 배치는 한 계정의 잔액과 원장을 짧은 원자적 연산으로 갱신하는 데 유용하지만, hash tag가 전역 트랜잭션이나 분산 락을 제공하는 것은 아닙니다.

함께 묶을 데이터와 핫 슬롯을 동시에 봅니다

한 계정의 여러 키를 같은 슬롯에 두면 Lua나 MULTI/EXEC가 해당 키를 하나의 노드에서 처리할 수 있습니다. 하지만 모든 계정에 {all} 같은 태그를 붙이면 데이터와 명령이 한 슬롯에 몰려 전체 샤딩의 이점이 사라지고 해당 노드의 CPU·메모리·네트워크가 병목이 됩니다. 함께 변경되어야 하는 최소 원자 단위만 태그로 묶고, 두 계정 간 이체처럼 서로 다른 태그를 한 번에 바꾸는 작업은 단일 슬롯 모델로 바꿀지 조정·보상 흐름으로 만들지 결정하겠습니다.

Redis Cluster의 슬롯 이동 중 클라이언트는 MOVED와 ASK를 처리하고 라우팅 정보를 갱신해야 합니다. 다중 키 명령이 슬롯 이동이나 재시도에서 어떻게 동작하는지는 클라이언트 버전·설정에 따라 확인합니다. hash tag 문자열을 직접 파싱해 라우팅을 흉내 내기보다 클러스터 인지 클라이언트를 사용하고, 키 생성 함수의 테스트로 태그 누락·오타를 막겠습니다.

원자성과 재시도는 별도 보장입니다

같은 슬롯의 Lua는 그 노드의 명령 실행 중 다른 클라이언트가 끼어들지 않게 할 수 있지만, 긴 스크립트는 해당 노드의 다른 명령을 지연시킵니다. 슬롯이 같아도 외부 DB나 다른 Redis 노드의 변경까지 원자적으로 묶이지 않습니다. 타임아웃 뒤 클라이언트가 명령이 실행됐는지 모르면 동일 쓰기를 재전송해 잔액을 두 번 바꿀 수 있으므로 요청 ID, 처리 기록, 결과 조회와 멱등 정책을 둡니다.

Sentinel은 primary 장애 전환을 돕지만 키 공간 샤딩을 하지 않고, Cluster는 슬롯·샤드 라우팅과 replica·장애 전환을 함께 다룹니다. 따라서 두 계정 이체의 강한 원자성이 필요하면 단순히 Sentinel을 Cluster로 바꾸는 것으로 해결되지 않습니다. 검증은 핫 계정, 큰 태그 그룹, 슬롯 재배치, 연결 재설정, 명령 타임아웃을 재현해 슬롯 분포·p99·MOVED/ASK 처리·중복 반영 여부를 확인하겠습니다.

태그는 키 이름 규칙이므로 변경하면 기존 키의 슬롯이 달라지고 마이그레이션·캐시 미스가 발생할 수 있습니다. 태그 안에 사용자 입력을 그대로 넣으면 의도치 않게 여러 논리 키가 한 슬롯에 모이거나 키 충돌 정책이 흔들릴 수 있어 정규화·길이 제한을 둡니다. Cluster의 다중 키 원자성은 한 노드의 처리 경계일 뿐 장애 중복·외부 시스템 보상까지 포함하지 않으므로, 중요한 잔액은 원장과 대사 절차를 별도로 둡니다.