Primary/Standby 개념, 자동 Failover 원리

기본 개념

평상시:
┌─────────────┐         ┌─────────────┐
│   Primary   │ ──동기── │   Standby   │
│  (읽기/쓰기) │  복제    │  (대기 중)  │
└─────────────┘         └─────────────┘
       ▲
       │ 트래픽
    App EC2

장애 시:
┌─────────────┐         ┌─────────────┐
│   Primary   │ ✗ 죽음  │   Standby   │
│             │         │  → Primary  │
└─────────────┘         └─────────────┘
                                ▲
                                │ 트래픽 자동 전환
                             App EC2

1. RDS Multi-AZ 구조

핵심 구조

AZ-a                          AZ-c
┌──────────────────┐          ┌──────────────────┐
│  Primary DB      │ ←──동기──→│  Standby DB      │
│  (실제 처리)     │   복제    │  (대기만)        │
│  ap-northeast-2a │          │  ap-northeast-2c │
└──────────────────┘          └──────────────────┘
         ▲
         │
  DNS 엔드포인트 (고정)
  wp-db.xxxxxx.ap-northeast-2.rds.amazonaws.com

동기 복제란?

App → Primary에 쓰기
Primary → Standby에 즉시 복제
Standby → 완료 확인
Primary → App에 성공 응답

→ Primary와 Standby의 데이터가 항상 동일 ✅
→ Failover 시 데이터 손실 0 (RPO = 0)

2. Failover 트리거 조건

아래 상황이 감지되면 자동 Failover:

① Primary 인스턴스 장애 (하드웨어 문제)
② Primary OS 장애 (커널 패닉 등)
③ Primary 네트워크 단절
④ AZ 전체 장애
⑤ DB 프로세스 응답 없음
⑥ 수동 Reboot with failover 실행
⑦ 인스턴스 타입 변경 (다운타임 필요한 작업)

3. Failover 실행 과정

① Primary 장애 감지 (RDS 내부 모니터링, ~10초)
        │
        ▼
② Standby를 새 Primary로 승격
        │
        ▼
③ DNS 엔드포인트를 새 Primary IP로 업데이트
   (기존: AZ-a IP → 변경: AZ-c IP)
        │
        ▼
④ 앱이 DNS 재조회 → 새 Primary로 자동 연결
        │
        ▼
⑤ 구 Primary 복구 후 새 Standby로 전환

전체 소요 시간: 보통 60~120초

DNS TTL이 핵심

# DB 연결 시 항상 DNS 조회해야 함
host = "wp-db.xxxxxx.ap-northeast-2.rds.amazonaws.com"

# ❌ IP 직접 사용 금지 (Failover 후 IP 바뀜)
host = "10.0.1.55"

# ✅ 반드시 엔드포인트 DNS 사용

4. 앱에서 Failover 대응하는 법

연결 재시도 패턴