소개
Redis는 모든 것이 정상일 때 매우 견고하다고 느낍니다. 실제 테스트는 무언가가 깨질 때 시작됩니다. 노드가 충돌하거나, 가상 머신이 재부팅되거나, 컨테이너가 사라지거나, 네트워크 문제로 인해 시스템 일부가 분리됩니다.
다음에 일어날 일은 전적으로 복제 및 고가용성을 어떻게 설계했는지에 달려 있습니다. 많은 팀에서는 Redis가 자동으로 오류를 처리한다고 가정하지만 그렇지 않습니다. Redis는 완성된 솔루션이 아닌 구성 요소를 제공합니다.
복제와 고가용성은 다양한 문제를 해결합니다. Redis는 두 가지를 모두 지원하지만 탄력적인 프로덕션 시스템을 구축하려면 차이점을 이해하는 것이 중요합니다.
Redis 복제의 실제 기능
Redis 복제의 핵심은 한 노드에서 다른 노드로 데이터를 복사하는 것입니다. 일반적으로 마스터라고 불리는 기본 노드는 모든 쓰기 작업을 처리합니다. 하나 이상의 복제본 노드는 지속적인 변경 스트림을 수신하고 데이터를 동기화된 상태로 유지합니다.
복제는 읽기 확장, 장애 조치 준비, 데이터 중복성이라는 세 가지 주요 이유 때문에 존재합니다. 그러나 복제만으로는 고가용성이 보장되지 않습니다. 제작에 필요한 재료만 제공합니다.
내부적으로 복제가 작동하는 방식
복제본이 마스터에 연결되면 초기 동기화 프로세스가 시작됩니다. 마스터는 현재 데이터의 스냅샷을 생성하여 복제본으로 보냅니다. 복제본은 이 스냅샷을 메모리에 로드합니다.
초기 동기화 후 마스터는 모든 후속 쓰기 명령을 복제본으로 스트리밍합니다. 복제본은 일관성을 유지하기 위해 이러한 명령을 동일한 순서로 적용합니다.
이 접근 방식은 효율적이고 간단하지만 중요한 장단점이 있습니다. 복제는 기본적으로 비동기식입니다. 즉, 데이터가 마스터에는 있지만 아직 복제본에는 없는 작은 창이 항상 있다는 것을 의미합니다.
비동기 복제 및 데이터 손실 위험
비동기식 복제를 통해 Redis는 빠른 속도와 응답성을 유지할 수 있지만 마스터에 장애가 발생할 경우 일부 데이터가 손실될 수도 있습니다.
복제본이 최신 쓰기를 수신하기 전에 마스터가 충돌하면 해당 쓰기가 손실됩니다. Redis는 이러한 현실을 숨기려고 시도하지 않습니다. 캐시 데이터의 경우 이는 일반적으로 허용됩니다. 심각한 상태의 경우 그렇지 않을 수도 있습니다.
Redis는 복제를 더 엄격하게 만드는 옵션을 제공하지만 더 엄격할수록 대기 시간은 늘어나고 가용성은 줄어듭니다. 데이터 손실이 어느 정도 허용되는지 결정하는 것은 중요한 아키텍처 결정입니다.
복제본을 사용하여 읽기 확장
Redis 복제를 사용하는 일반적인 이유 중 하나는 읽기 트래픽을 확장하는 것입니다. 애플리케이션은 쓰기 작업을 마스터에 지시하고 읽기 작업을 복제본 전체에 분산시킬 수 있습니다.
이렇게 하면 마스터의 로드가 줄어들고 전체 처리량이 향상됩니다. 그러나 복제는 비동기식이므로 복제본이 약간 오래된 데이터를 반환할 수 있습니다.
캐싱 프로필이나 구성과 같은 사용 사례의 경우 일반적으로 괜찮습니다. 강력한 일관성이 필요한 시나리오의 경우 허용되지 않을 수 있습니다. 팀은 의도적으로 이러한 균형을 맞춰야 합니다.
마스터가 실패하면 어떻게 되나요?
복제만으로는 마스터 오류를 처리할 수 없습니다. 마스터가 다운되면 복제본은 동기화 상태를 유지하지만 외부 장애 조치 메커니즘 없이는 자동으로 승격되지 않습니다.
고가용성을 위해서는 오류를 감지하고, 결정을 조정하고, 새로운 마스터를 승격할 수 있는 무언가가 필요합니다. 장애 조치 시스템이 작동하는 곳이 바로 여기입니다.
Redis Sentinel 및 고가용성
Redis Sentinel은 Redis에 고가용성을 추가하기 위한 전통적인 솔루션입니다. Sentinel 프로세스는 Redis 인스턴스를 모니터링하고 오류를 감지하며 서로 통신하여 합의에 도달합니다.
센티널이 마스터가 다운되었다는 사실에 동의하면 복제본 중 하나가 새 마스터가 되도록 승격됩니다. 센티넬은 또한 클라이언트에게 올바른 노드에 다시 연결할 수 있도록 알립니다.
Sentinel은 추가 구성 요소와 복잡성을 도입합니다. 효과적이려면 여러 Sentinel 노드가 실행되고 있어야 합니다. 진정한 고가용성을 위해서는 단일 Sentinel만으로는 충분하지 않습니다.
Sentinel이 장애 조치를 결정하는 방법
Sentinel은 잘못된 장애 조치를 방지하기 위해 시간 제한과 쿼럼을 사용합니다. 여러 센티널은 승격이 발생하기 전에 마스터에 접근할 수 없다는 데 동의해야 합니다.
이 설계는 안정성을 향상시키지만 장애 조치가 즉각적이지 않음을 의미합니다. 마스터를 사용할 수 없고 교체가 활성화되지 않는 짧은 기간이 항상 있습니다.
애플리케이션은 이 창을 정상적으로 처리하도록 설계되어야 합니다. 재시도, 시간 초과 및 대체 동작은 필수적입니다.
Redis 클러스터 및 내장된 고가용성
Redis 클러스터는 복제 및 장애 조치를 시스템에 직접 통합합니다. 각 샤드에는 마스터와 복제본이 있으며, 마스터에 장애가 발생하면 자동으로 장애 조치가 발생합니다.
이렇게 하면 Sentinel이 필요하지 않지만 다른 제약 사항이 발생합니다. 키 배포, 클라이언트 동작 및 교차 샤드 작업에는 신중한 설계가 필요합니다.
Redis 클러스터는 더 엄격한 아키텍처 경계를 적용하면서 고가용성을 단순화합니다.
장애 조치가 다운타임 제로를 의미하는 것은 아닙니다
일반적인 오해는 Redis 장애 조치가 가동 중지 시간을 보장하지 않는다는 것입니다. 실제로 장애 조치는 빠르지만 즉각적이지는 않습니다.
장애 조치 중에 일부 요청은 실패하거나 재시도가 필요합니다. 잘 설계된 시스템은 이러한 동작을 예상하고 정상적으로 복구됩니다. 잘못 설계된 시스템은 충돌을 일으키거나 연속적인 오류를 유발할 수 있습니다.
고가용성은 완벽함이 아니라 탄력성을 향상시킵니다.
분할 두뇌와 그 위험성
스플릿 브레인은 둘 이상의 노드가 자신을 마스터라고 믿을 때 발생합니다. Redis와 Sentinel은 이를 방지하도록 설계되었지만 네트워크 파티션과 잘못된 구성으로 인해 여전히 이 문제가 발생할 수 있습니다.
분할 브레인은 쓰기 충돌과 데이터 손상을 초래할 수 있습니다. 이러한 위험을 줄이려면 적절한 Sentinel 쿼럼, 올바른 네트워크 설정 및 합리적인 시간 초과가 필요합니다.
이러한 세부 사항을 무시하는 것은 드물지만 심각한 사고를 일으키는 일반적인 원인입니다.
복제 지연 및 성능 영향
복제 지연은 일반적으로 작지만 0이 아닙니다. 쓰기 부하가 높으면 복제본이 마스터보다 뒤처질 수 있습니다.
지연 시간이 긴 동안 장애 조치(failover)가 발생하면 데이터 손실이 증가합니다. 데이터 무결성이 중요한 시스템에는 복제 지연 모니터링이 필수적입니다.
갑작스러운 지연 증가는 근본적인 성능이나 리소스 문제를 나타내는 경우가 많습니다.
복제가 백업이 아닌 이유
복제를 백업과 혼동해서는 안 됩니다. 마스터에서 데이터가 삭제되면 해당 삭제가 즉시 복제됩니다.
백업은 사람의 실수와 논리적 손상으로부터 보호합니다. 복제는 하드웨어 또는 프로세스 오류로부터 보호합니다. Redis가 중요한 데이터를 저장하는 경우 둘 다 필요합니다.
일반적인 Redis HA 실수
팀에서는 Redis 고가용성을 설계할 때 동일한 실수를 자주 저지릅니다. 여기에는 복제가 고가용성과 같다고 가정하고, 하나의 Sentinel만 실행하고, 복제 지연을 무시하고, 장애 조치 테스트에 실패하고, Redis 오류로 인해 애플리케이션이 충돌하도록 허용하는 것이 포함됩니다.
이러한 실수는 실제 중단 보고서에 반복적으로 나타납니다.
설계의 일부로서 실패 테스트
테스트되지 않은 고가용성은 종이에만 존재합니다. 팀은 통제된 환경에서 마스터를 중지하여 정기적으로 실패를 시뮬레이션해야 합니다.
장애 조치 동작 관찰, 복구 시간 측정, 애플리케이션 응답 이해는 어떤 문서로도 대체할 수 없는 귀중한 통찰력을 제공합니다.
Redis HA를 위한 실용적인 정신 모델
Redis 고가용성은 우아한 성능 저하에 관한 것입니다. Redis가 정상이면 시스템이 제대로 작동합니다. Redis가 비정상 상태가 되면 성능이 저하될 수 있습니다. Redis를 사용할 수 없는 경우에도 시스템은 계속 유지되어야 합니다.
Redis가 다운되어 전체 시스템이 중단되면 고가용성은 불완전합니다.
요약
Redis 복제 및 고가용성은 스트레스 상황에서 시스템이 작동하는 방식을 결정합니다. 복제는 데이터 사본을 제공하는 동시에 고가용성은 서비스 연속성을 제공합니다.
둘 다 신중한 설계, 현실적인 기대, 지속적인 테스트가 필요합니다. 올바르게 구현되면 Redis 오류는 심각한 사고가 아닌 일상적인 이벤트가 됩니다. 이것이 Redis 고가용성의 목표입니다.