대규모 트래픽 처리를 위한 Redis Cluster 구조 및 활용

Ⅰ. Redis Cluster 기술이란?

ⅰ. 단일 서버의 물리적 한계 극복

단일 Redis 서버가 가지는 메모리 용량과 단일 스레드 처리량의 한계를 수직 확장(Scale-up)이 아닌 수평 확장(Scale-out)으로 해결하는 Redis 내장 분산 모드입니다. 별도의 미들웨어나 프록시를 두지 않고 Redis 자체 기능으로 동작합니다.

ⅱ. 샤딩과 장애 조치의 통합

데이터를 여러 노드에 나누어 담는 분할(Sharding) 기능과, 일부 노드가 다운되어도 서비스를 유지하는 자동 장애 조치(Auto Failover) 기능을 하나의 구조 안에서 함께 제공합니다.

ⅲ. 도입 전 반드시 알아야 할 제약

단일 인스턴스와 완전히 동일하게 동작하지는 않습니다. 데이터베이스는 0번 하나만 사용할 수 있고, 서로 다른 슬롯에 걸친 다중 키 명령과 트랜잭션은 제한됩니다. 복제가 비동기이므로 마스터 장애 시점에 일부 쓰기가 유실될 수 있다는 점도 설계 단계에서 감안해야 합니다.

Ⅱ. Redis Cluster 기술 특징

ⅰ. 해시 슬롯 기반 분할

전체 키 공간을 16,384개의 해시 슬롯(Hash Slot)으로 나누고, 각 마스터 노드가 슬롯 범위를 나누어 담당합니다. 키가 아닌 슬롯 단위로 소유권을 관리하기 때문에 노드 증설과 축소가 단순해집니다.

ⅱ. 중앙 관리 노드 없음 (Gossip 프로토콜)

별도의 중앙 통제 서버 없이 모든 노드가 대등한 관계로 가십(Gossip) 프로토콜을 통해 서로의 상태와 슬롯 배치 정보를 실시간으로 공유합니다.

ⅲ. 자동 장애 조치

Sentinel 같은 별도 구성 요소 없이도 마스터 노드의 장애를 과반수 마스터의 합의로 판정하고, 해당 마스터의 복제본(Replica)을 새 마스터로 자동 승격시킵니다.

ⅳ. 클라이언트 리다이렉트 (MOVED / ASK)

요청한 키의 슬롯을 해당 노드가 담당하지 않으면 올바른 노드 주소를 응답으로 알려줍니다. 슬롯 소유권이 이미 넘어간 경우에는 MOVED를, 리샤딩 중이라 일시적으로 이전 중인 경우에는 ASK를 반환합니다. MOVED는 클라이언트가 슬롯 맵을 갱신해야 한다는 신호이고, ASK는 이번 요청만 다른 노드로 보내라는 일회성 안내입니다.

ⅴ. 무중단 재배치 (Resharding)

서비스 운영 중에도 노드를 추가하거나 제거하면서 슬롯을 실시간으로 이동시킬 수 있습니다.

Ⅲ. Redis Cluster 기술 동작 방식

ⅰ. 구성 요소의 역할

자동 장애 조치 판정에 과반수가 필요하므로 최소 3개의 마스터 노드가 필요하며, 가용성을 확보하려면 각 마스터마다 복제 노드를 두어 총 6개 노드로 구성합니다. 노드 간 통신에는 서비스 포트와 별개로 클러스터 버스 포트(서비스 포트 + 10000)를 사용합니다.

ⅱ. 슬롯 할당 원리

들어온 명령어의 Key를 CRC16(key) mod 16384 공식으로 연산하여 0~16383 사이의 슬롯 번호를 부여합니다. 예를 들어 user:100은 9308번 슬롯에 배치됩니다.

ⅲ. 해시 태그 (Hash Tag) 연산

여러 키를 묶어서 처리해야 할 때 키에 중괄호 {}를 포함시키면 괄호 안의 문자열만 해시 연산하여 의도적으로 같은 슬롯에 배치합니다. user:{100}:profile과 user:{100}:cart는 모두 CRC16("100") mod 16384 결과인 339번 슬롯으로 들어갑니다.

다만 해시 태그를 남용하면 특정 슬롯에 데이터가 쏠려 노드 간 부하가 불균형해집니다. 반드시 원자적으로 묶여야 하는 키 집합에만 제한적으로 사용하는 것이 좋습니다.

Ⅳ. Redis Cluster 기술 구성 및 흐름도

ⅰ. 클러스터 아키텍처 구성도

ⅱ. 데이터 요청 및 리다이렉트 흐름도

Ⅴ. Redis Cluster 기술 설치 방법

ⅰ. 노드별 환경 설정

각 노드의 redis.conf에 클러스터 모드를 활성화하고, 노드 상태 파일과 타임아웃을 지정합니다.

port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes

ⅱ. 방화벽 개방

서비스 포트와 버스 포트를 함께 열어야 합니다. 7000~7005로 구성한다면 17000~17005도 인바운드로 허용해야 노드 간 가십 통신이 정상 동작합니다.

ⅲ. 클러스터 생성 명령어 실행

설정된 노드를 모두 기동한 후 아래 명령어로 클러스터를 구축합니다. --cluster-replicas 1은 마스터 하나당 복제본을 하나씩 배치하라는 의미입니다.

redis-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

Ⅵ. Redis Cluster 기술 사용 방법

ⅰ. 클라이언트 접속

CLI 접속 시 반드시 -c 옵션을 주어 리다이렉션을 자동으로 따라가게 합니다.

redis-cli -c -p 7000

ⅱ. 클라이언트 라이브러리 연동

애플리케이션에서는 클러스터 모드를 지원하는 클라이언트를 사용해야 합니다. Java는 Jedis의 JedisCluster 또는 Lettuce의 RedisClusterClient를 사용합니다. Python은 과거에 쓰이던 redis-py-cluster가 더 이상 유지보수되지 않으므로, redis-py 4.x 이상에 내장된 RedisCluster 클래스를 사용하는 것이 맞습니다.

from redis.cluster import RedisCluster

rc = RedisCluster(host="127.0.0.1", port=7000, decode_responses=True)
rc.set("user:100", "홍길동")

ⅲ. 노드 추가 및 리샤딩

노드를 클러스터에 편입시킨 뒤 슬롯을 옮겨야 실제로 트래픽을 나눠 받습니다.

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000
redis-cli --cluster reshard 127.0.0.1:7000

Ⅶ. Redis Cluster 기술 자주 쓰는 명령어

ⅰ. cluster info

클러스터의 전반적인 상태를 확인합니다. cluster_state:ok 여부와 할당된 슬롯 수를 가장 먼저 봅니다.

ⅱ. cluster nodes

전체 노드 목록과 마스터/복제본 역할, 담당 해시 슬롯 범위를 조회합니다.

ⅲ. cluster keyslot [key]

특정 키가 어느 슬롯에 속하는지 직접 확인합니다. 해시 태그가 의도대로 동작하는지 검증할 때 유용합니다.

ⅳ. redis-cli --cluster check [IP:PORT]

슬롯이 누락 없이 모든 노드에 배분되었는지 진단합니다. 리샤딩 직후 점검용으로 적합합니다.

Ⅷ. Redis Cluster 기술 활용 방안

ⅰ. 대규모 세션 스토어

사용자 접속이 폭주하는 웹 서비스에서 세션을 여러 노드에 분산 저장하여 단일 노드 메모리 한계와 장애 영향 범위를 동시에 줄입니다.

ⅱ. 실시간 분산 캐시 시스템

대용량 읽기/쓰기가 발생하는 순위표(Leaderboard)나 실시간 재고 관리 시스템의 캐시 계층으로 도입합니다.

ⅲ. 도입이 적합하지 않은 경우

데이터 규모가 단일 서버 메모리로 충분하고 복잡한 다중 키 연산이 많다면, 클러스터보다 단일 마스터에 복제본을 붙이고 Sentinel로 장애 조치를 구성하는 편이 운영 난이도 대비 이득이 큽니다.

Ⅸ. Redis Cluster 기술 트러블 슈팅

ⅰ. CROSSSLOT 오류 해결

MSET, MGET, 트랜잭션 등 다중 키 조작이 서로 다른 슬롯에 걸칠 때 발생합니다. 함께 다뤄야 하는 키 이름에 동일한 {해시태그}를 부여해 같은 슬롯으로 모으면 해결됩니다.

ⅱ. cluster_state:fail 상태 대응

기본 설정에서는 슬롯 하나라도 담당 마스터가 없으면 클러스터 전체가 요청을 거부합니다. 근본 대책은 마스터마다 복제본을 두는 것이며, cluster-require-full-coverage no는 일부 슬롯이 비어도 살아 있는 슬롯만이라도 서비스하게 해주는 완화 옵션일 뿐 가용성을 보장해 주지는 않습니다.

ⅲ. 노드 간 통신 불가 (Gossip 실패)

서비스 포트(예: 6379)만 열고 버스 포트(예: 16379)가 막힌 경우가 가장 흔합니다. 두 포트 모두 인바운드가 열려 있는지 확인합니다.

ⅳ. 페일오버 후 데이터 유실

복제가 비동기이므로 마스터 장애 직전의 쓰기가 복제본에 반영되지 않았을 수 있습니다. 유실을 줄이려면 WAIT 명령으로 복제 확인을 강제하거나, min-replicas-to-write로 복제본이 부족할 때 쓰기를 차단하도록 설정합니다.

ⅴ. 특정 노드 부하 쏠림

해시 태그 과다 사용이나 거대 키(Big Key) 때문에 슬롯 분포가 균등해도 부하가 한쪽으로 몰릴 수 있습니다. redis-cli --bigkeys로 큰 키를 찾아내고, 해시 태그 적용 범위를 재검토합니다.

#Redis #레디스클러스터 #RedisCluster #데이터베이스 #분산시스템 #고가용성 #샤딩 #백엔드개발 #트래픽분산 #시스템아키텍처