561. 클라우드 DB 고가용성 Multi-AZ 페일오버 프로토콜

⚠️ 이 문서는 클라우드 환경(AWS RDS 등)에서 단일 데이터센터의 화재나 정전에 대비하여, 수십 km 떨어진 다른 가용 영역(AZ)에 100% 동일한 복제본 DB(Standby)를 실시간으로 띄워두고, 장애 발생 시 사람이 개입하지 않아도 1분 이내에 자동으로 스위치를 전환하여 서비스 무중단을 달성하는 'Multi-AZ 자동 페일오버' 아키텍처를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 데이터의 영속성(데이터 유실 방지, RPO=0)과 서비스의 연속성(중단 시간 최소화, RTO<1분)을 동시에 만족시키기 위해, 원격지 간에 스토리지 레벨의 **'동기식(Synchronous) 복제'**를 수행하는 인프라 구조다.
  2. 가치: 새벽 3시에 서울 IDC의 DB 서버가 불에 타서 죽더라도, DBA가 자다 깨어 스크립트를 돌릴 필요 없이 클라우드가 스스로 부산 IDC의 예비 DB를 운영 DB로 승격(Promotion)시켜 앱 서버가 아무 일 없던 것처럼 DB에 다시 접속하게 만든다.
  3. 기술 체계: 장애를 감지하는 Heartbeat/Quorum 메커니즘과, 애플리케이션 코드를 수정하지 않아도 알아서 새 DB를 찾아가게 해주는 DNS 기반 엔드포인트(Endpoint) 라우팅 전환 기술이 핵심이다.

Ⅰ. Single-AZ의 위험성과 Multi-AZ의 동기식 복제

하나의 데이터센터(AZ)에만 DB를 두면, 디스크 백업본이 있더라도 RTO(복구 시간)가 길다.

  1. 스토리지 수준의 동기식 복제 (Synchronous Replication):
    • AWS RDS Multi-AZ는 물리적으로 격리된 두 개의 가용 영역(예: AZ-a, AZ-c)에 Master(Active) 인스턴스와 Standby 인스턴스를 하나씩 띄운다.
    • 클라이언트가 INSERT 쿼리를 날렸을 때, Master DB는 반드시 Standby DB의 디스크(EBS)에도 데이터가 안전하게 기록되었다는 응답(ACK)을 받아야만 클라이언트에게 최종 "성공!" 응답을 반환한다.
    • 이 깐깐한 동기화 덕분에 Master가 돌연사하더라도 Standby에는 단 1바이트의 데이터 유실도 없음을 수학적으로 보장한다. (단, 복제 지연만큼 쓰기 속도가 약간 느려지는 트레이드오프가 있다.)
  2. Standby 노드의 숨겨진 용도:
    • Standby 노드는 평소에 조회를 받는 Read Replica(읽기 전용 복제본)와 완전히 다르다. 평소에는 어떤 트래픽도 받지 않고 완전히 숨어(Hidden) 있다가, 오직 장애 복구용으로만 대기하는 '비용이 비싼 보험'이다.

📢 섹션 요약 비유: 서류(데이터)를 결재받을 때, 사장(Master)이 도장을 찍고 나서, 반드시 멀리 떨어진 부사장(Standby)에게도 똑같은 서류에 도장을 찍었다는 팩스를 받아야만 손님에게 "결재 완료"라고 말해주는 방식입니다. 이렇게 해야 사장이 쓰러져도 부사장이 100% 똑같은 서류철을 들고 즉시 업무를 인수할 수 있습니다.

Ⅱ. 장애 감지와 자동 페일오버(Failover) 프로세스

서버가 죽은 것을 어떻게 확신하고 넘길 것인가? 스플릿 브레인(Split-Brain)을 막아야 한다.

  1. 하트비트 (Heartbeat) 모니터링:
    • 클라우드 제어 평면(Control Plane)은 Master DB와 1초마다 네트워크 핑(Ping)을 주고받으며 심박수(상태)를 감시한다.
  2. 장애 확정과 전환 (Promotion):
    • 디스크 고장, 네트워크 단절 등으로 Master가 수 초 이상 응답하지 않으면 시스템은 이를 장애로 확정한다.
    • 즉시 죽은 Master를 격리(Fencing)시키고, 대기 중이던 Standby 인스턴스를 새로운 Master로 승격(Promote)시킨다.
  3. DNS 스와핑 (DNS Endpoint Switching):
    • 가장 우아한 마법이다. 앱 서버의 소스 코드에는 DB 접속 주소(IP)가 적혀있지 않고 db.example.rds.amazonaws.com 같은 도메인(Endpoint) 문자열이 적혀있다.
    • 페일오버가 일어나는 순간, 클라우드 내부의 DNS 서버가 이 도메인이 가리키는 IP를 죽은 서버의 IP에서 새로운 Master(구 Standby)의 IP로 전격 교체해 버린다.
    • 앱 서버는 그냥 똑같은 도메인에 다시 접속을 시도할 뿐인데, 자연스럽게 살아있는 새 DB로 연결된다. (보통 60초~120초 소요)

📢 섹션 요약 비유: 114 전화 안내소(DNS)에 "서울 중국집(도메인)" 번호를 물어보면 늘 강남점(Master) 번호를 알려줬는데, 강남점에 불이 난 걸 114가 감지하고 즉시 안내 번호를 강북점(Standby)으로 몰래 바꿔치기합니다. 손님들(앱)은 평소처럼 114에 묻고 전화를 걸었는데 자연스럽게 강북점으로 연결되는 완벽한 우회 시스템입니다.

Ⅲ. 멀티 리전 (Multi-Region) DR과 클러스터 아키텍처

하나의 도시가 통째로 지진 피해를 보았을 때의 궁극적 방어선이다.

  1. 리전 간 비동기 복제 (Cross-Region Read Replica):
    • Multi-AZ가 '서울' 내의 강남과 강북에 분산하는 것이라면, Multi-Region은 '서울'과 '도쿄'에 분산하는 것이다.
    • 수백 km 이상의 거리에서는 동기식(Synchronous) 복제를 하면 네트워크 지연(Latency) 때문에 쓰기 속도가 너무 느려져 서비스가 불가능하다.
    • 따라서 도쿄 리전으로는 먼저 쓰기를 완료한 뒤 나중에 데이터를 보내는 비동기식(Asynchronous) 복제를 사용하여 재해 복구(DR) 센터를 구축한다. RPO(데이터 유실)가 약간 발생할 수 있다.
  2. 오로라(Aurora)의 최신 페일오버 아키텍처:
    • 최근 클라우드 네이티브 DB(AWS Aurora 등)는 스토리지와 컴퓨팅 노드를 분리하여, 컴퓨팅 노드가 죽으면 스토리지를 복제할 필요 없이 다른 대기 노드가 스토리지 덩어리에 파이프만 다시 꽂아버리는 방식으로 페일오버 시간을 30초 이내로 단축시켰다.

📢 섹션 요약 비유: 서울 내에서 서류를 똑같이 맞추는 것(Multi-AZ)은 가능하지만, 일본 지사(Multi-Region)까지 매번 팩스가 잘 도착했는지 확인하고 결재를 끝내려다간 회사가 망합니다. 그래서 일본 지사에는 하루 치 결재가 끝난 뒤 우편으로 사본을 몰아보내고(비동기), 서울 본사가 폭격 맞았을 때 일본 지사를 본사로 격상시키는 거대한 글로벌 보험을 드는 것입니다.