소개
Redis는 모든 것이 정상적으로 동작할 때는 매우 안정적으로 느껴집니다. 하지만 진짜 시험은 장애가 발생하는 순간 시작됩니다. 노드가 크래시되거나, 가상 머신이 재부팅되거나, 컨테이너가 사라지거나, 네트워크 문제로 시스템의 일부가 고립되는 상황이 그 예입니다.
그 이후 어떤 일이 벌어지는지는 전적으로 복제(Replication)와 고가용성(HA)을 어떻게 설계했는지에 달려 있습니다. 많은 팀이 Redis가 장애를 자동으로 처리해 준다고 생각하지만, 실제로는 그렇지 않습니다. Redis는 완성된 솔루션이 아니라 구성 요소(building blocks)를 제공할 뿐입니다.
복제와 고가용성은 서로 다른 문제를 해결합니다. Redis는 두 가지 모두 지원하지만, 탄력적인 프로덕션 시스템을 구축하려면 이 차이를 명확히 이해하는 것이 필수적입니다.
Redis 복제의 실제 역할
핵심적으로 Redis 복제는 한 노드에서 다른 노드로 데이터를 복사하는 기술입니다. 마스터(master)라고 불리는 프라이머리 노드가 모든 쓰기 작업을 처리하고, 하나 이상의 레플리카(replica) 노드는 변경 사항 스트림을 지속적으로 수신하며 데이터를 동기화 상태로 유지합니다.
복제가 존재하는 이유는 크게 세 가지입니다: 읽기 확장(read scaling), 페일오버 대비, 그리고 데이터 중복성 확보입니다. 그러나 복제만으로는 고가용성이 보장되지 않습니다. 복제는 고가용성을 구축하는 데 필요한 재료를 제공할 뿐입니다.
복제의 내부 동작 원리
레플리카가 마스터에 연결되면 초기 동기화(initial synchronization) 과정부터 시작합니다. 마스터는 현재 데이터의 스냅샷을 생성하여 레플리카에 전송하고, 레플리카는 이 스냅샷을 메모리에 로드합니다.
초기 동기화 이후에는 마스터가 이후의 모든 쓰기 명령을 레플리카에 스트리밍하고, 레플리카는 같은 순서대로 명령을 적용하며 일관성을 유지합니다.
이 방식은 효율적이고 단순하지만 중요한 트레이드오프를 수반합니다. 복제는 기본적으로 비동기(asynchronous) 방식이기 때문에, 마스터에는 존재하지만 아직 레플리카에는 반영되지 않은 데이터가 존재하는 짧은 시간 창(window)이 항상 존재합니다.
비동기 복제와 데이터 손실 위험
비동기 복제 덕분에 Redis는 빠르고 반응성이 뛰어난 성능을 유지할 수 있지만, 동시에 마스터 장애 발생 시 일부 데이터 손실이 가능하다는 의미이기도 합니다.
마스터가 레플리카에 최신 쓰기가 전달되기 전에 크래시되면 해당 쓰기는 유실됩니다. Redis는 이 현실을 감추려 하지 않습니다. 캐시 데이터라면 대체로 허용 가능하지만, 중요한 상태(state) 데이터라면 그렇지 않을 수 있습니다.
Redis는 복제를 더 엄격하게 만드는 옵션을 제공하지만, 더 강력한 보장은 곧 지연 시간 증가와 가용성 저하로 이어집니다. 어느 정도의 데이터 손실을 허용할 것인지 결정하는 것은 핵심 아키텍처 설계 사항입니다.
레플리카를 활용한 읽기 확장
Redis 복제를 사용하는 흔한 이유 중 하나는 읽기 트래픽 확장입니다. 애플리케이션은 쓰기 작업을 마스터로 보내고, 읽기 작업은 여러 레플리카에 분산시킬 수 있습니다.
이렇게 하면 마스터의 부하가 줄고 전체 처리량이 향상됩니다. 다만 복제가 비동기 방식이므로 레플리카가 약간 오래된(stale) 데이터를 반환할 수 있다는 점에 유의해야 합니다.
프로필이나 설정 정보 캐싱과 같은 용도라면 대체로 문제없습니다. 하지만 강력한 일관성(strong consistency)이 필요한 시나리오에서는 허용하기 어렵습니다. 팀은 이 트레이드오프를 반드시 의식적으로 결정해야 합니다.
마스터 장애 시 발생하는 일
복제만으로는 마스터 장애를 처리할 수 없습니다. 마스터가 다운되면 레플리카들은 동기화 상태를 유지하지만, 외부 페일오버 메커니즘이 없다면 자동으로 승격(promote)되지 않습니다.
고가용성을 위해서는 장애를 감지하고, 판단을 조율하며, 새로운 마스터를 승격시키는 무언가가 필요합니다. 바로 이 지점에서 페일오버 시스템이 역할을 수행합니다.
Redis Sentinel과 고가용성
Redis Sentinel은 Redis에 고가용성을 추가하는 전통적인 솔루션입니다. Sentinel 프로세스는 Redis 인스턴스를 모니터링하고, 장애를 감지하며, 서로 통신하여 합의(consensus)에 도달합니다.
Sentinel들이 마스터가 다운되었다고 판단하면 레플리카 중 하나가 새로운 마스터로 승격됩니다. 또한 Sentinel은 클라이언트에게 알려 올바른 노드에 재연결할 수 있도록 돕습니다.
Sentinel은 추가적인 구성 요소와 복잡성을 도입합니다. 효과적으로 운영하려면 여러 개의 Sentinel 노드를 실행해야 하며, 단일 Sentinel만으로는 진정한 고가용성을 확보할 수 없습니다.
Sentinel의 페일오버 판단 방식
Sentinel은 타임아웃과 쿼럼(quorum)을 사용하여 잘못된 페일오버를 방지합니다. 여러 Sentinel이 마스터에 도달할 수 없다고 동의해야만 승격이 진행됩니다.
이러한 설계는 신뢰성을 높이지만, 페일오버가 즉각적이지 않다는 의미이기도 합니다. 마스터가 사용 불가능하고 대체 노드가 아직 활성화되지 않은 짧은 시간이 항상 존재합니다.
따라서 애플리케이션은 이 시간 창을 우아하게(gracefully) 처리하도록 설계되어야 합니다. 재시도(retry), 타임아웃 처리, 폴백(fallback) 동작은 필수 요소입니다.
Redis Cluster와 내장형 고가용성
Redis Cluster는 복제와 페일오버를 시스템 자체에 통합합니다. 각 샤드(shard)는 마스터와 레플리카를 가지며, 마스터 장애 시 페일오버가 자동으로 수행됩니다.
이를 통해 Sentinel이 필요 없어지지만, 대신 다른 제약 조건이 생깁니다. 키 분배 방식, 클라이언트 동작, 샤드 간 연산(cross-shard operations)은 신중하게 설계해야 합니다.
Redis Cluster는 고가용성을 단순화하는 동시에 더 엄격한 아키텍처 경계를 요구합니다.
페일오버가 무중단을 의미하지 않는 이유
흔한 오해 중 하나는 Redis 페일오버가 무중단(zero downtime)을 보장한다는 생각입니다. 실제로 페일오버는 빠르지만 즉각적이지 않습니다.
페일오버가 진행되는 동안 일부 요청은 실패하거나 재시도가 필요합니다. 잘 설계된 시스템은 이런 동작을 예측하고 우아하게 복구하지만, 부실하게 설계된 시스템은 크래시하거나 연쇄 장애(cascading failure)를 유발할 수 있습니다.
고가용성은 완벽함이 아니라 회복탄력성(resilience)을 높이는 것입니다.
스플릿 브레인(Split Brain)과 그 위험
스플릿 브레인은 두 개 이상의 노드가 자신이 마스터라고 믿는 상황에서 발생합니다. Redis와 Sentinel은 이를 방지하도록 설계되었지만, 네트워크 파티션(partition)이나 설정 오류로 인해 여전히 발생할 수 있습니다.
스플릿 브레인은 충돌하는 쓰기와 데이터 손상으로 이어질 수 있습니다. 이 위험을 줄이려면 적절한 Sentinel 쿼럼 구성, 올바른 네트워크 설정, 합리적인 타임아웃 값이 필요합니다.
이런 세부 사항을 간과하는 것은 드물지만 치명적인 장애의 흔한 원인입니다.
복제 지연과 성능 영향
복제 지연(replication lag)은 대체로 작지만 절대 0이 되지는 않습니다. 쓰기 부하가 심한 상황에서는 레플리카가 마스터보다 뒤처질 수 있습니다.
지연이 큰 상태에서 페일오버가 발생하면 데이터 손실이 커집니다. 따라서 데이터 무결성이 중요한 시스템이라면 복제 지연 모니터링은 필수입니다.
지연이 갑자기 증가하는 경우는 종종 근본적인 성능 문제나 리소스 문제를 알리는 신호이기도 합니다.
복제는 백업이 아니다
복제를 백업과 혼동해서는 안 됩니다. 마스터에서 데이터가 삭제되면 그 삭제는 즉시 복제됩니다.
백업은 인적 오류와 논리적 손상(logical corruption)으로부터 보호합니다. 반면 복제는 하드웨어나 프로세스 장애로부터 보호합니다. Redis에 소중한 데이터를 저장한다면 두 가지 모두 필요합니다.
흔히 저지르는 Redis HA 실수
팀들은 Redis 고가용성 설계 시 반복적으로 비슷한 실수를 저지릅니다. 대표적인 예로는 복제가 곧 고가용성이라고 가정하는 것, Sentinel을 하나만 운영하는 것, 복제 지연을 무시하는 것, 페일오버를 테스트하지 않는 것, Redis 오류 발생 시 애플리케이션이 크래시하도록 두는 것 등이 있습니다.
이러한 실수는 실제 장애 보고서에서 끊임없이 반복해서 나타납니다.
설계의 일부로서 장애 테스트하기
한 번도 테스트되지 않은 고가용성은 종이 위에만 존재합니다. 팀은 통제된 환경에서 주기적으로 마스터를 중단시키는 방식으로 장애를 시뮬레이션해야 합니다.
페일오버 동작을 관찰하고, 복구 시간을 측정하고, 애플리케이션의 반응을 확인하는 과정은 어떤 문서도 대체할 수 없는 소중한 통찰을 제공합니다.
Redis HA를 위한 실용적인 사고 모델
Redis 고가용성의 본질은 우아한 성능 저하(graceful degradation)입니다. Redis가 건강할 때는 시스템이 최상의 성능을 발휘하고, Redis가 불안정해지면 성능이 다소 저하되며, Redis를 사용할 수 없더라도 시스템 전체는 생존해야 합니다.
Redis가 다운되는 것만으로 시스템 전체가 마비된다면, 고가용성 설계는 아직 미완성인 것입니다.
요약
Redis 복제와 고가용성은 스트레스 상황에서 시스템이 어떻게 동작하는지를 결정합니다. 복제는 데이터의 사본을 제공하고, 고가용성은 서비스의 연속성을 제공합니다.
두 가지 모두 신중한 설계, 현실적인 기대치, 지속적인 테스트를 요구합니다. 올바르게 구현되면 Redis 장애는 대형 사고가 아니라 일상적인 이벤트가 됩니다. 그것이 바로 Redis 고가용성의 목표입니다.