프로덕션 시스템에서 Redis 사용량이 증가함에 따라 팀은 결국 중요한 아키텍처 결정에 직면하게 됩니다. Redis를 Redis Sentinel 또는 Redis Cluster를 사용하여 확장해야 합니까?
이러한 결정은 일반적으로 성능 문제, 메모리 고갈 또는 가용성 사고가 나타난 후에 늦게, 그리고 압력을 받아 내려지는 경우가 많습니다. 불행하게도 Redis Sentinel과 Redis Cluster는 매우 다른 문제를 해결하며, 잘못된 것을 선택하면 고통스러운 재설계로 이어집니다.
Redis Sentinel은 가용성에 관한 것입니다. Redis 클러스터는 확장성에 관한 것입니다. 이 둘을 혼동하는 것은 Redis 아키텍처에서 가장 흔한 실수 중 하나입니다.
Redis Sentinel이 해결하는 핵심 문제
Redis Sentinel은 단일 Redis 데이터 세트에 고가용성을 제공하도록 설계되었습니다.
주요 임무는 다음과 같습니다:
-
Redis 마스터 및 복제본 노드 모니터링
-
실패 감지
-
자동 장애 조치 수행
-
새 마스터에 대한 클라이언트 업데이트
Redis Sentinel은 데이터를 샤딩하지 않습니다. 모든 키를 보유하는 논리적 Redis 인스턴스는 여전히 정확히 하나입니다.
마스터가 실패하면 Sentinel은 복제본을 승격합니다. 애플리케이션 관점에서 Redis는 최소한의 중단으로 계속 작업합니다.
Redis Sentinel이 내부적으로 작동하는 방식
일반적인 Redis Sentinel 설정에는 다음이 포함됩니다:
-
하나의 Redis 마스터
-
하나 이상의 Redis 복제본
-
이를 모니터링하는 여러 Sentinel 프로세스
센티넬은 마스터의 건강 상태를 지속적으로 확인합니다. 센티널 쿼럼이 마스터가 다운되었다는 사실에 동의하면 장애 조치가 시작됩니다.
하나의 복제본은 마스터로 승격되고 나머지 복제본은 이를 따르도록 재구성됩니다.
중요한 점은 데이터가 동일한 크기와 모양을 유지한다는 것입니다. 키 재배포는 없습니다.
Redis Sentinel이 수행하지 않는 작업
Redis Sentinel은 다음을 수행하지 않습니다:
-
단일 노드 이상으로 메모리 용량 늘리기
-
하나의 코어 이상으로 쓰기 처리량 증가
-
데이터 분할 또는 배포
Redis 인스턴스에 메모리나 CPU가 부족해지면 Sentinel을 추가해도 도움이 되지 않습니다. Sentinel은 Redis를 더 큰 규모가 아닌 가용성으로 유지합니다.
Redis 클러스터가 해결하는 핵심 문제
Redis 클러스터는 가용성보다는 확장성을 다룹니다.
해결 방법:
-
단일 시스템의 메모리 제한
-
단일 스레드 실행으로 인한 처리량 제한
Redis 클러스터는 여러 마스터 노드에 걸쳐 데이터를 분할합니다. 각 마스터는 키스페이스의 하위 집합을 소유합니다.
복제는 가용성을 위해 사용되지만 샤딩이 정의 기능입니다.
Redis 클러스터가 높은 수준에서 작동하는 방식
Redis 클러스터는 키스페이스를 16,384개의 해시 슬롯으로 나눕니다.
각 마스터 노드는 이러한 슬롯의 일부를 소유합니다. 키는 해시 함수를 기반으로 슬롯에 할당됩니다.
클라이언트가 명령을 실행하면 해당 슬롯을 담당하는 노드로 라우팅됩니다.
마스터에 장애가 발생하면 Sentinel과 유사하게 복제본 중 하나가 자동으로 승격되지만 해당 샤드에 대해서만 승격됩니다.
가용성 모델 비교
Redis Sentinel은 다음을 제공합니다:
-
한 번에 하나의 활성 마스터
-
단일 노드의 전체 데이터세트
-
자동 장애 조치
Redis 클러스터는 다음을 제공합니다:
-
여러 마스터
-
노드 전체에 분산된 데이터
-
샤드 수준의 장애 조치
Sentinel은 노드 장애로부터 보호합니다. 클러스터는 노드 장애와 용량 제한 모두로부터 보호합니다.
확장 특성
Redis Sentinel은 수직으로 확장됩니다.
Redis를 더 큰 시스템으로 옮기거나, 더 많은 메모리를 추가하거나, 더 빠른 CPU를 사용할 수 있지만 여전히 한계에 도달합니다.
Redis 클러스터는 수평으로 확장됩니다.
메모리와 처리량을 늘리려면 노드를 추가합니다. 각 노드는 데이터 세트의 일부만 처리합니다.
단일 Redis 노드가 더 이상 충분하지 않으면 Sentinel만으로는 부족합니다.
애플리케이션 디자인에 미치는 영향
Redis Sentinel은 대부분 애플리케이션에 투명합니다.
애플리케이션은 여전히 하나의 Redis 인스턴스와 통신하고 있다고 생각합니다. 클라이언트는 장애 조치 후 새 마스터에 다시 연결됩니다.
Redis 클러스터에는 클러스터 인식 클라이언트가 필요합니다.
신청서는 다음을 충족해야 합니다:
-
리디렉션 처리
-
해시 슬롯 경계 존중
-
지원되지 않는 다중 키 작업 방지
클러스터 채택은 주요 설계 및 데이터 모델링에 큰 영향을 미칩니다.
다중 키 작업 및 트랜잭션
Redis Sentinel 사용:
-
모든 키는 하나의 마스터에 있습니다
-
다중 키 작동은 정상적으로 작동합니다
-
트랜잭션과 Lua 스크립트가 예상대로 작동합니다
Redis 클러스터 사용:
-
키는 다른 노드에 있을 수 있습니다
-
다중 키 작업은 동일한 해시 슬롯 내에서만 작동합니다
-
교차 슬롯 작업 실패
이 단 하나의 차이점은 Redis 클러스터로 마이그레이션하는 팀에게 가장 큰 충격이 되는 경우가 많습니다.
운영 복잡성
Redis Sentinel은 중간 수준의 운영 복잡성을 도입합니다.
귀하는 다음을 관리합니다:
-
마스터 및 복제본
-
센티넬 정족수
-
장애 조치 동작
Redis 클러스터는 훨씬 더 복잡해졌습니다.
귀하는 다음을 관리합니다:
-
다수의 마스터 및 복제본
-
슬롯 할당 및 밸런싱
-
리샤딩 작업
-
클라이언트 호환성
클러스터에는 더 강력한 운영 규율이 필요합니다.
Redis Sentinel이 올바른 선택일 때
Redis Sentinel은 다음과 같은 경우에 적합합니다.
-
데이터 세트는 한 컴퓨터에 편안하게 들어맞습니다
-
쓰기 처리량은 단일 코어에 적합합니다
-
고가용성이 필요합니다
-
응용 프로그램 논리는 다중 키 작업에 따라 다릅니다.
Sentinel만으로도 많은 시스템이 수년간 성공적으로 실행되었습니다.
Redis 클러스터가 올바른 선택일 때
Redis 클러스터는 다음과 같은 경우에 적합합니다:
-
메모리 요구 사항이 단일 노드를 초과합니다
-
처리량은 지속적으로 증가해야 합니다.
-
수평 확장이 필요합니다
-
샤딩을 위해 애플리케이션을 설계할 수 있습니다
클러스터는 단순한 장애 조치 메커니즘이 아닌 확장 전략입니다.
일반적인 마이그레이션 실수
팀이 자주 하는 일:
-
Redis 클러스터를 너무 일찍 채택
-
Sentinel과 Cluster는 상호 교환 가능하다고 가정
-
주요 디자인 영향 무시
-
다중 키 제한 사항을 너무 늦게 발견했습니다
이러한 실수는 대개 성급한 리팩토링을 초래합니다.
단순한 결정 규칙
다음과 같은 경우 Redis Sentinel을 사용하세요:
-
데이터 모델을 변경하지 않고 고가용성을 원합니다
다음과 같은 경우 Redis 클러스터를 사용하세요:
-
Redis를 하나의 머신 이상으로 확장해야 합니다
클러스터를 선택하는 경우 즉시 활성화하지 않더라도 조기에 설계하십시오.
요약
Redis Sentinel과 Redis Cluster는 다양한 시스템 압력을 해결하는 보완 기술입니다. Sentinel은 단일 데이터 세트에 대한 서비스 연속성을 보장합니다. 클러스터를 사용하면 Redis가 여러 머신에 걸쳐 확장할 수 있습니다. 올바른 접근 방식을 선택하는 것은 가용성 또는 확장성이 주요 아키텍처 동인인지에 따라 달라집니다.