1. 개요
이 예제에서는 Redis와 Redis Sentinel 및 Redis Cluster의 두 가지 배포 전략에 대해 설명합니다. 그런 다음 이러한 전략과 그 뉘앙스의 차이점에 대해 논의합니다.
마지막으로 Redis에 대해 충분히 이해하여 어떤 배포 전략이 우리의 요구 사항을 더 잘 충족하는지 판단할 수 있기를 바랍니다 .
2. 레디스 소개
Redis는 키-값 데이터베이스, 캐시 및 기타 많은 사용 사례로 사용할 수 있는 오픈 소스 메모리 내 데이터 구조 저장소입니다. 데이터에 대한 고속 액세스를 제공하는 것을 목표로 합니다.
우리의 목표는 Redis Sentinel과 Redis Cluster라는 두 가지 다른 전략을 분석하고 비교하는 것입니다.
Redis Sentinel은 Redis에서 제공하는 별도의 프로세스입니다. 목표는 Redis 인스턴스를 모니터링하고, 알림 기능, 마스터 검색, 장애 시 자동 장애 조치, 다수결 투표를 통한 마스터 선택을 제공하는 것입니다. 즉, Sentinel은 Redis에 고가용성 및 장애 조치와 같은 추가 기능을 제공하는 분산 시스템입니다. Redis Sentinel은 표준 Redis 배포와 힘을 결합합니다.
Redis 클러스터는 훨씬 더 확장되는 배포 전략입니다. Sentinel과 유사하게 장애 조치, 구성 관리 등을 제공합니다 . 차이점은 최대 1000개 노드까지 용량을 거의 선형으로 확장할 수 있는 샤딩 기능입니다.
3. 기본 개념
두 전략의 뉘앙스를 이해하는 데 도움이 되도록 먼저 몇 가지 기본 개념과 구성 요소를 내부화해 보겠습니다.
일부 개념은 Redis 클러스터 또는 Sentinel과 엄격하게 관련되지 않을 수 있습니다. 그러나 다른 사람들은 둘 다에 적용될 수 있지만 Redis를 이해하는 데 도움이 될 것입니다.
3.1. 데이터베이스
Redis는 여러 논리적 데이터베이스를 지원합니다. 여전히 동일한 파일에 유지되지만 사용자는 각 데이터베이스에서 다른 값을 가진 동일한 키를 가질 수 있습니다. 서로 다른 데이터베이스 스키마와 같습니다.
기본적으로 Redis는 16개의 논리적 데이터베이스를 제공하지만 사용자가 이 수를 변경할 수 있습니다 . 이러한 데이터베이스는 0부터 시작하는 인덱스로 식별됩니다.
강화해야 할 또 다른 필수 사항은 Redis가 단일 스레드 데이터 저장소라는 것입니다. 따라서 모든 데이터베이스 작업은 동일한 실행 파이프라인으로 이동합니다.
3.2. 해시 슬롯
Redis 클러스터는 표준 클러스터와 약간 다르게 작동합니다. 예를 들어 데이터를 자동으로 샤딩하고 클러스터의 다양한 노드에 배포하기 위해 Redis 클러스터는 소위 해시 슬롯을 사용합니다 .
Redis 클러스터는 배포 작업을 수행하기 위해 일관된 해싱을 사용하지 않습니다. 대신 해시 슬롯을 사용합니다.
각 클러스터에는 모든 노드 에 분산될 수 있는 16384개의 해시 슬롯이 있으며 모든 작업 중에 Redis 클라이언트는 키 모듈로 16384 의 CRC16 을 취하여 키를 사용하여 해시를 계산합니다 . 그런 다음 이를 사용하여 명령을 올바른 노드로 라우팅합니다.
각 노드에는 할당된 해시 슬롯의 하위 집합이 있으며 리샤딩 또는 재조정 작업을 사용하여 노드 간에 슬롯을 이동할 수 있습니다. 또한 이 접근 방식의 특수성을 감안할 때 Redis 클러스터는 노드당 여러 논리적 데이터베이스를 허용하지 않습니다. 따라서 각 노드에서는 데이터베이스 0만 사용할 수 있습니다 .
마지막으로, 해시 슬롯의 키 배포로 인해 Redis 클러스터에는 여러 키 작업에 관한 주의 사항이 있습니다. 관련된 모든 키가 동일한 해시 슬롯에 속해야 하지만 이러한 작업은 계속 사용할 수 있습니다. 그렇지 않으면 Redis가 요청을 거부합니다.
3.3. 해시 태그
이 메커니즘은 사용자가 키 그룹이 동일한 해시 슬롯으로 이동하도록 보장하는 데 도움이 됩니다. 해시 태그 를 정의하려면 사용자가 키의 대괄호 사이에 하위 문자열을 추가해야 합니다. 예를 들어 app1{user:123}.mykey1 및 app1{user:123}.mykey2 키는 동일한 해시 로트로 이동합니다.
이를 통해 Redis는 하위 문자열만 사용하여 키의 해시를 생성하고 결과적으로 모든 키를 동일한 해시 슬롯으로 라우팅합니다.
3.4. 비동기 복제
Redis 클러스터와 표준 클러스터 모두 비동기 복제를 사용합니다. 즉, Redis는 복제본이 쓰기를 승인할 때까지 기다리지 않습니다.
또한 오류로 인해 승인된 쓰기가 손실될 수 있는 작은 시간 창이 항상 있습니다. 그러나 이 시간 창을 가능한 한 많이 제한하여 이 위험을 완화할 수 있는 방법이 있습니다. 그러나 다시 한 번 말하지만 위험은 항상 존재하므로 Redis는 강력한 일관성 을 보장하지 않습니다 .
3.5. 장애 조치
Redis는 장애를 처리하고 일정 수준의 내결함성을 보장하는 다양한 메커니즘을 제공합니다. Redis 클러스터와 Sentinel을 사용하는 표준 클러스터에는 이러한 도구가 있습니다. 이러한 시스템에는 상태 확인 및 시간 초과를 기반으로 하는 오류 감지기가 함께 제공됩니다.
Redis Cluster의 경우 하트비트와 가십 프로토콜 을 사용합니다 . 이 기사의 목적을 위해 더 깊이 들어가지는 않겠습니다. 그러나 요약하자면 각 노드는 다른 노드와 대화하고 메타데이터와 패킷을 교환하며 특정 노드가 응답하지 않는 경우 일부 시간 제한을 계산합니다.
Sentinel과 관련하여 각 Sentinel 인스턴스는 Redis 인스턴스를 모니터링합니다. 또한 Sentinel 인스턴스는 서로 통신 하며 구성에 따라 통신 및 시간 초과 문제로 인해 장애 조치를 실행할 수 있습니다.
3.6. 마스터 선거
다시 말하지만 두 가지 구현에는 투표 전략이 있으며 프로세스에는 서로 다른 단계가 있습니다. 그러나 주요 목표는 장애 조치가 발생해야 하는지 여부와 승격 여부를 결정하는 것입니다.
Sentinel은 정족수 개념으로 작동합니다. 정족수는 마스터 노드에 도달할 수 있는지 여부에 대한 합의를 찾아야 하는 Sentinel 인스턴스의 최소 수입니다.
이런 일이 발생하면 마스터는 실패한 것으로 표시되고 결국 가능한 경우 장애 조치 프로세스가 시작됩니다. 그 이후에는 최소한 Sentinel의 대다수가 장애 조치를 승인하고 장애 조치를 담당하는 Sentinel 인스턴스를 선택해야 합니다. 그런 다음 이 인스턴스는 승격할 최상의 읽기 전용 복제본을 선택하고 장애 조치를 실행합니다. 마지막으로 인스턴스는 새 설정을 다른 Sentinel 인스턴스에 브로드캐스팅하기 시작합니다.
Redis Cluster와 관련하여 프로세스가 약간 변경됩니다 . 이번에는 복제본 노드가 담당합니다. 앞에서 언급했듯이 이 경우 모든 노드가 그들 사이에서 통신하므로 하나 이상의 복제본이 실패를 감지하면 선거를 시작할 수 있습니다. 다음 단계는 마스터의 투표를 요청하는 것입니다. 투표가 발생하면 복제본이 장애 조치 권한을 받습니다.
이러한 투표 메커니즘의 특성을 고려할 때 Redis는 클러스터에서 항상 홀수 개의 노드를 사용할 것을 권장하며 이는 두 구현 모두에 적용됩니다.
3.7. 네트워크 파티션
Redis는 다양한 장애를 견뎌낼 수 있으며 그 설계는 노드가 다운되더라도 지속적인 운영을 제공할 수 있을 만큼 충분히 견고합니다. 그러나 우리가 직면할 수 있는 중요한 문제 시나리오 중 하나는 소위 네트워크 파티션입니다. 토폴로지로 인해 Redis는 이러한 문제를 처리할 때 어려운 상황에 직면합니다.
이른바 스플릿 브레인은 이 범주에서 가장 간단한 문제 중 하나입니다 . 다음 예를 사용해 보겠습니다.
여기에서 우리는 네트워크 파티션이 있고 한쪽에서 클라이언트가 이제 두 개의 인스턴스(1과 2)에만 연결할 수 있는 클러스터와 통신하고 있음을 관찰할 수 있습니다.
다른 쪽에서 다른 클라이언트는 파티션에서 3과 4에만 연결할 수 있는 다른 파티션과 통신합니다. 쿼럼이 2라고 가정하면 어느 시점에서 오른쪽에서 장애 조치가 발생하고 결과에 도달하게 됩니다.
이제 두 개의 클러스터가 있습니다(Redis 3이 마스터로 승격됨). 어느 시점에서 네트워크 파티션이 사라지면 분리하는 동안 동일한 키가 다른 값으로 양쪽에 쓰여진 경우 클러스터에 문제가 발생할 수 있습니다.
동일한 원칙을 Redis 클러스터에 적용할 수 있으며 결과는 비슷합니다. 이는 왜 홀수가 권장되고 min-replicas-to-write 와 같은 구성이 사용 되는지를 보여줍니다 . 아이디어는 항상 다수만이 장애 조치를 수행할 수 있는 다수 및 소수 파티션을 갖는 것입니다.
우리가 상상할 수 있듯이 네트워크 파티션 중에 가능한 다른 많은 시나리오가 있습니다. 따라서 어떤 옵션을 선택하든 클러스터를 설계할 때 이를 이해하고 염두에 두는 것이 중요합니다.
4. Redis Sentinel 대 클러스터링
아래 표는 몇 가지 주요 기능을 비교합니다.
Redis 클러스터의 모든 세부 사항과 뉘앙스 및 Redis Sentinel과 결합된 표준 구현을 사용하여 점을 연결할 수 있습니다.
Sentinel이 모니터링, 내결함성 및 알림을 제공한다는 결론을 내릴 수 있습니다. 구성 공급자이기도 합니다. 또한 인증 기능과 클라이언트 서비스 검색을 제공할 수 있습니다. 클러스터에 16개의 논리적 데이터베이스, 비동기 복제 및 고가용성을 제공할 수 있습니다.
그럼에도 불구하고 Redis의 단일 스레드 특성과 수직 확장의 장벽은 Sentinel의 확장 기능을 제한하는 요소 입니다. 그러나 중소 프로젝트의 경우 이상적일 수 있습니다.
Sentinel을 사용한 배포에는 더 적은 수 의 노드가 필요하다는 것도 사실입니다 . 따라서 더 비용 효율적입니다.
언급할 가치가 있는 점은 읽기 전용 복제본을 사용하여 읽기 전용 작업을 더 확장할 수도 있다는 것입니다.
Redis 클러스터는 자동화된 샤딩 기능(수평 확장 기능)을 갖춘 완전 분산형 구현으로 고성능 및 최대 1000개 노드까지의 선형 확장을 위해 설계되었습니다 . 또한 마스터의 모든 데이터가 다수 측에서 도달할 수 있는 한(마스터 또는 복제본 케이블을 통해 장애 조치 수행) 재해에서 살아남을 수 있는 합리적인 수준의 쓰기 안전과 수단을 제공합니다.
또 다른 요점은 네트워크 파티션 중에 클러스터의 소수 부분이 요청 수락을 중지한다는 것입니다. 반면 Sentinel 배포는 구성에 따라 부분적으로 계속 작동할 수 있습니다. 앞에서 언급했듯이 클러스터의 가용성과 내결함성은 클러스터 구성 및 구성에 따라 다릅니다.
클러스터 버전은 또한 단일 노드에서 여러 개의 독립적인 오류가 발생하는 경우 재조정을 위해 마스터와 복제본 간의 매핑을 재구성하는 기능을 제공합니다. 그러나 다시 한 번 더 강력한 클러스터를 위해서는 더 많은 노드가 필요하므로 더 많은 비용이 듭니다. 게다가 더 많은 노드를 관리하고 샤드 균형을 맞추는 것은 간과할 수 없는 추가적인 복잡성입니다.
요약하면 Redis Cluster는 높은 처리량과 확장 기능이 필요한 빅 데이터 세트가 포함된 대규모 배포에서 빛을 발합니다.
5. 결론
이 기사에서는 Redis와 Redis의 다양한 구현, Redis 클러스터 및 Sentinel을 사용한 Redis 표준에 대해 논의했습니다.
또한 솔루션의 모든 기본 구성 요소와 이를 사용하여 솔루션을 최대한 활용하는 방법을 이해했습니다. 사용 사례에 따라 사용할 옵션을 결정할 수 있는 도구가 있기를 바랍니다.
