Redis Cloud 클러스터링 이해하기

Redis Cloud 클러스터링 이해하기

Redis Cloud는 아주 큰 데이터베이스(25GB 이상)를 다룰 때 클러스터링을 사용해요. 이 글에서는 클러스터링을 어떻게 관리하는지, 그리고 데이터가 어떻게 분산되는지 제어하는 해싱 정책(hashing policy)을 어떻게 쓰는지 배워볼 거예요. 단일 서버의 메모리 한계를 넘어서는 데이터를 여러 클라우드 인스턴스에 분산해 저장하는 원리랍니다.

출처: Redis 공식 문서 - Clustering Redis Databases

데이터가 어떻게 분산되는가

Redis Cloud 클러스터는 관리되는 여러 Redis 프로세스와 클라우드 인스턴스의 집합이에요. 각 프로세스가 데이터베이스 키스페이스(keyspace)의 일부를 맡아 관리하죠. 클러스터링은 여러 인스턴스의 코어와 자원을 활용해 확장 문제를 해결해요.

Redis Cloud 클러스터에서 키스페이스는 해시 슬롯(hash slot)으로 분할돼요. 특정 시점에 한 해시 슬롯은 한 Redis 서버가 담당하고, 클러스터에 속한 한 인스턴스는 여러 해시 슬롯을 관리할 수 있어요. 이처럼 키 공간을 나누는 것을 샤딩(sharding) 이라고 하는데, 키 이름(또는 그 일부인 키 해시 태그)을 해싱해서 키가 놓일 해시 슬롯을 구하는 방식으로 이뤄져요. Redis Cloud는 여러 해싱 정책을 지원해요.

여러 Redis 프로세스를 쓰더라도 Redis Enterprise Cloud 클러스터는 애플리케이션 관점에서 거의 투명해요. 클러스터는 모든 연산을 관련 샤드로 자동 라우팅하는 단일 엔드포인트로 접근할 수 있거든요. 클러스터 인지(aware) 클라이언트의 복잡함 없이도 애플리케이션은 코드 변경 없이 클러스터를 사용할 수 있어요.

데이터베이스를 만들거나 편집할 때 메모리 한도와 요구 처리량을 바탕으로 필요한 샤드 수가 자동 계산돼요.

다중 키 연산과 제약

샤딩된 Redis Cloud 클러스터에서 여러 키에 대한 연산은 다음 제약 아래 지원돼요.

1. 다중 키 명령: 여러 키를 인자로 받는 명령은, 해당 키들이 전부 같은 슬롯(즉 같은 샤드)에 있을 때만 실행할 수 있어요. 이 제약은 BITOP, BLPOP, BRPOP, BRPOPLPUSH, MSETNX, RPOPLPUSH, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SMOVE, SORT, SUNION, XREAD, XREADGROUP, ZINTER, ZINTERSTORE, ZUNION, ZUNIONSTORE, ZDIFF, ZDIFFSTORE 같은 모든 다중 키 명령에 적용돼요.
2. Geo 명령: GEORADIUS/GEORADIUSBYMEMBER/GEOSEARCHSTORE 명령에서 STORE, STOREDIST 옵션은 영향을 받는 모든 키가 같은 슬롯에 있을 때만 쓸 수 있어요.
3. 트랜잭션: WATCH/MULTI/EXEC 블록 안의 모든 연산은 같은 슬롯의 키에 대해 수행해야 해요.
4. Lua 스크립트: 스크립트가 쓰는 모든 키는 같은 슬롯에 있어야 하고, Redis 스펙대로 EVAL/EVALSHA 명령의 인자로 제공돼야 해요.
5. 키 이름 변경/복사: RENAME/RENAMENX/COPY 명령은 원래 이름과 새 이름이 같은 해시 슬롯에 매핑될 때만 허용돼요.
6. 가변 인자 명령: (MGET, MSET, HMGET, HMSET 등)과 파이프라이닝은 비클러스터 DB처럼 지원돼요.

해싱 정책과 해시 태그

해싱 정책은 데이터가 데이터베이스의 여러 Redis 프로세스에 어떻게 분산되는지 결정해요. 해싱 함수로 키를 해시 슬롯에 매핑해 데이터를 고르게 분산시켜 성능과 확장성을 보장해요.

키 이름에 해시 태그인 {...} 패턴이 없다면 해싱 함수는 키 이름 전체를 사용해 해시 슬롯을 계산해요. 키에 {...} 패턴이 있으면 {와 } 사이의 부분 문자열만 해싱해서 해시 슬롯을 구해요.

{...} 패턴으로 서로 관련된 키를 같은 해시 슬롯에 둘 수 있어서 다중 키 연산을 지원할 수 있어요. 반대로 키 이름에 해시 태그를 쓰지 않으면 키가 샤드에 (통계적으로) 고르게 분산돼 자원 활용이 좋아져요. 다중 키 연산을 하지 않는 애플리케이션이라면 키 이름에 해시 태그를 만들 필요가 없어요.

Redis Cloud는 해시 태그를 처리하는 방식이 다른 3가지 해싱 정책을 제공해요. 단, 모든 정책이 항상 제공되지는 않아요.

Redis Cloud는 새 데이터베이스를 만들 때 기본적으로 Redis 해싱 정책을 사용해요. 생성 중에 다른 해싱 정책을 고를 수 있지만, 생성 후에는 Redis 해싱 정책으로/에서 변경할 수 없어요.

Redis 해싱 정책

Redis 해싱 정책은 Redis 오픈소스에서 쓰는 해싱 정책과 동일해요. 대부분의 사용자에게 권장되며, 다음 조건 중 하나라도 해당하면 이 정책을 고르면 돼요.

• Redis Cloud 계정을 처음 만들고 새로 시작하는 경우
• Redis 오픈소스나 다른 Redis 관리 플랫폼에서 데이터를 마이그레이션하는 경우
• 애플리케이션이 데이터베이스 키 이름에 해시 태그를 사용하지 않는 경우
• 애플리케이션이 키 이름으로 바이너리 데이터를 사용하는 경우

Redis 해싱 정책은 가능한 곳에서 더 빠른 확장을 지원해요.

표준 해싱 정책

표준(Standard) 해싱 정책은 대체로 Redis 해싱 정책과 일치하며 다음 경우에 같은 해시 슬롯 계산을 만들어요.

1. 해시 태그가 하나인 키: 키 이름에서 '{'와 '}' 사이의 부분 문자열이 해시 태그예요. 키 이름에 '{...}' 패턴이 있으면 해시 태그를 해싱 함수 입력으로 사용해요. 예를 들어 foo{bar}, {bar}baz, foo{bar}baz는 같은 해시 태그를 가지며 같은 슬롯에 매핑돼요.
2. 해시 태그가 없는 키: '{...}' 패턴이 없으면 키 이름 전체를 해싱에 사용해요.

표준 해싱 정책이 Redis 해싱 정책과 다르게 동작하는 경우도 있어요.

1. 빈 해시 태그({})를 쓰는 경우: 표준 해싱 정책은 빈 해시 태그를 무시하지 않아서, 빈 해시 태그로 시작하는 두 키는 같은 해시 슬롯에 해싱돼요(Redis 해싱 정책은 이를 무시해요). 예를 들어 {}foo와 {}bar 두 키를 보면:

• 표준 해싱 정책: 같은 해시 슬롯
• Redis 해싱 정책: 다른 해시 슬롯

2. 중괄호가 여러 개인 키: 키 이름에 중괄호가 여러 개 있으면 표준 해싱 계산이 Redis 해싱 정책과 달라질 수 있어요. 예를 들어 {foo}bar}와 {foo}qux} 두 키를 보면:

• 표준 해싱 정책: 각 키에서 부분 문자열 "foo}bar", "foo}qux"를 사용해 각각 다른 해시 슬롯에 해싱
• Redis 해싱 정책: 두 키 모두 "foo" 부분 문자열을 사용해 같은 슬롯에 해싱

📝 해싱 정책 간 원활한 전환을 위해 다음 기법은 권장하지 않아요.

• 빈 해시 태그로 서로 다른 키를 같은 해시 슬롯에 해싱하는 것
• 키 이름 안에 중괄호를 여러 개 사용하는 것

커스텀 해싱 정책

📝 커스텀 해싱 정책은 2025년 3월 31일 이후에 만든 계정에서는 사용할 수 없어요. 그 외 계정에서도 이 정책은 권장하지 않으며 향후 지원이 중단될 예정이에요. 이미 커스텀 해싱 정책을 쓰는 Redis Cloud 데이터베이스가 있다면 이 옵션을 고르면 돼요.

Redis Cloud 클러스터는 커스텀 해싱 정책으로 설정할 수 있어요. 서로 다른 키를 같은 샤드에 두어 다중 키 연산을 하려면 커스텀 해싱 정책이 필요해요. 커스텀 해싱 정책은 데이터셋의 키 이름 패턴을 표현하는 Perl 호환 정규표현식(PCRE) 규칙 집합으로 제공돼요.

커스텀 해싱 정책을 설정하려면 키 이름에서 해싱할 부분 문자열(해시 태그)을 식별하는 정규식(RegEx) 규칙을 입력하면 돼요. 해시 태그는 RegEx에서 tag라는 이름의 하위 패턴으로 표시돼요. 해시 태그가 같은 서로 다른 키는 같은 슬롯에 저장·관리돼요.

커스텀 해싱 정책을 켜면 표준 해싱 정책을 구현하는 Redis Cloud 기본 RegEx 규칙이 제공돼요.

애플리케이션 요구에 맞게 규칙을 수정하거나 추가·삭제·순서 변경할 수 있어요.

⚠️ 커스텀 해싱 정책을 사용할 수 있다면, 데이터베이스 생성 후 표준과 커스텀 사이에서 해싱 정책을 변경할 수 있어요. 다만 해싱 정책 변경은 적용 전에 기존 데이터를 삭제(FLUSHDB 사용)해요.

이런 변경이 여기에 포함돼요.

1. 표준↔커스텀 해싱 정책 변경
2. 커스텀 해싱 정책 규칙 순서 변경
3. 커스텀 해싱 정책에서 기존 규칙 앞에 규칙 추가
4. 커스텀 해싱 정책에서 규칙 삭제
5. 데이터베이스 클러스터링 비활성화

커스텀 해싱 정책 참고 사항과 제약

1. 각각 최대 256자의 RegEx 규칙을 최대 32개까지 정의할 수 있어요.
2. RegEx 규칙은 순서대로 평가돼요.
3. 처음 매칭된 규칙이 사용되므로 일반적인 키 이름 패턴을 규칙 목록 앞쪽에 두는 게 좋아요.
4. 어떤 RegEx 규칙에도 매칭되지 않는 키 이름은 오류를 일으켜요.
5. .*(?<tag>) RegEx 규칙은 해시 키가 항상 비어서 모든 키를 단일 슬롯으로 강제해요. 마지막 catch-all 규칙으로 써야 해요.
6. 정규식 파서에서 다음 플래그가 활성화돼 있어요:

• PCRE_ANCHORED: 패턴이 검색 중인 문자열의 시작 부분에서만 매칭되도록 제한

OSS Cluster API

OSS Cluster API는 거의 선형에 가까운 확장성으로 접근 시간과 지연 시간을 줄여줘요. OSS Cluster API는 Redis 클라이언트가 클러스터 토폴로지를 알 수 있는 간단한 메커니즘을 제공해요.

클라이언트는 먼저 마스터 노드에 연결해 클러스터 토폴로지를 얻은 다음, 마스터 샤드를 호스팅하는 각 노드의 Redis 프록시에 직접 연결해요.

📝 클러스터 API가 활성화된 데이터베이스에 연결하려면 클러스터 API를 지원하는 클라이언트를 써야 해요.

OSS Cluster API는 Redis Cloud Pro 데이터베이스에서만 지원돼요. 구성 화면의 Performance 섹션에서 켤 수 있어요.

OSS Cluster API를 선택한 뒤 Use external endpoint를 선택하면 데이터베이스의 외부 엔드포인트를 쓸 수 있어요. 이 옵션을 선택하면 이 데이터베이스의 프라이빗 엔드포인트는 차단돼요.

OSS Cluster API는 데이터베이스가 표준 해싱 정책을 사용할 때만 지원돼요.

이 기능을 데이터베이스에 활성화할지 결정하려면 OSS Cluster API 아키텍처를 검토해 보세요.

더 알아보기

• Redis 클러스터 스펙
• 클러스터링 (Clustering/Scalability)