RDS Multi-AZ 이점 완전 정리: 고가용성, 페일오버, 그리고 성능 오해

6월 14, 2026

프로덕션 RDS 인스턴스를 처음 설정할 때 Multi-AZ 옵션을 보고 '이거 켜면 성능도 좋아지겠지?'라고 생각했다면, 그 가정이 장애 대응 중에 당신을 배신할 수 있다. Multi-AZ는 고가용성과 페일오버를 위한 기능이지, 읽기 성능 향상을 위한 기능이 아니다.

TL;DR: RDS Multi-AZ 핵심 요약

항목	Multi-AZ 동작
목적	고가용성 및 자동 페일오버
스탠바이 인스턴스 직접 접근	불가 (읽기/쓰기 모두 차단)
읽기 성능 향상	없음 — 읽기 스케일아웃은 Read Replica 사용
쓰기 성능 영향	동기 복제로 인한 소폭 지연 가능
페일오버 소요 시간	일반적으로 60~120초 (공식 보장 없음)
데이터 내구성	동기 복제로 RPO ≈ 0
자동 백업	스탠바이에서 수행 (프라이머리 I/O 영향 감소)

RDS Multi-AZ가 실제로 하는 일

Multi-AZ를 활성화하면 AWS는 다른 가용 영역(AZ)에 스탠바이 인스턴스를 자동으로 프로비저닝한다. 프라이머리 인스턴스에 쓰기가 발생하면 Amazon RDS는 동기식 블록 수준 복제를 통해 스탠바이에 데이터를 미러링한다. 애플리케이션은 항상 프라이머리 엔드포인트 하나만 바라본다.

여기서 핵심은 동기(synchronous) 복제라는 점이다. 프라이머리가 트랜잭션을 커밋하기 전에 스탠바이에도 기록이 완료되어야 한다. 이 구조 덕분에 페일오버 시 데이터 손실이 없지만, 반대로 스탠바이는 항상 '대기 중'이지 '서비스 중'이 아니다.

graph LR App["애플리케이션"] -->|"단일 엔드포인트 (DNS)"| Primary["프라이머리 인스턴스
AZ-A"] Primary -->|"동기 복제
(커밋 전 확인)"| Standby["스탠바이 인스턴스
AZ-B"] Standby -.->|"직접 접근 불가"| Blocked["❌ 읽기/쓰기 차단"] Primary -->|"장애 발생"| Failover{"자동 페일오버"} Failover -->|"DNS 전환"| NewPrimary["스탠바이 → 새 프라이머리"]

애플리케이션은 RDS 엔드포인트(DNS)를 통해 프라이머리 인스턴스에만 연결된다.
동기 복제: 프라이머리의 모든 쓰기는 스탠바이에 즉시 미러링된다. 커밋 완료 전에 양쪽 모두 기록이 확인되어야 한다.
스탠바이는 읽기나 쓰기 트래픽을 직접 받지 않는다. 순수하게 페일오버 대기 상태다.
페일오버 발생 시 RDS는 DNS를 스탠바이로 전환한다. 애플리케이션은 엔드포인트 주소를 바꿀 필요가 없다.

Multi-AZ의 실질적 이점 — 성능이 아닌 운영 안정성

1. 자동 페일오버

프라이머리 인스턴스에 장애가 발생하면 RDS는 자동으로 스탠바이를 새 프라이머리로 승격시키고 DNS 레코드를 업데이트한다. 애플리케이션 입장에서는 동일한 엔드포인트를 그대로 사용하면 된다. 단, DNS TTL과 애플리케이션의 커넥션 풀 설정에 따라 실제 전환 체감 시간이 달라진다. 페일오버를 트리거하는 조건은 다음과 같다:

프라이머리 인스턴스 호스트 장애
가용 영역 장애
DB 인스턴스 클래스 변경 등 유지보수 작업
수동 재부팅 시 'Reboot with failover' 옵션 선택

2. 계획된 유지보수 중 다운타임 최소화

RDS 엔진 패치나 인스턴스 클래스 변경 같은 유지보수 작업이 발생할 때, Multi-AZ가 활성화되어 있으면 스탠바이에 먼저 적용한 뒤 페일오버를 수행하는 방식으로 프라이머리 다운타임을 줄인다. Multi-AZ 없이 유지보수를 진행하면 그 시간 전체가 다운타임이 된다.

3. 자동 백업 I/O 영향 감소

Multi-AZ 구성에서 자동 백업과 스냅샷은 스탠바이 인스턴스에서 수행된다. 프라이머리의 I/O가 백업 작업으로 인해 영향을 받는 상황을 줄여준다. 이 부분은 성능과 관련이 있지만, 읽기/쓰기 처리량 자체를 높이는 것이 아니라 백업 I/O 경합을 분리하는 효과다.

4. 데이터 내구성 (RPO ≈ 0)

동기 복제 구조상 페일오버 시 데이터 손실이 없다. 비동기 복제를 사용하는 Read Replica와 근본적으로 다른 지점이다.

Multi-AZ가 해결하지 못하는 것 — 흔한 오해

Multi-AZ를 읽기 성능 향상 수단으로 쓰려는 시도는, 예비 소방차를 출퇴근용으로 쓰려는 것과 같다. 장비는 있지만 그 용도가 아니다.

읽기 성능 스케일아웃이 필요하다면 Read Replica를 사용해야 한다. Multi-AZ 스탠바이는 애플리케이션에서 직접 접근할 수 없다. 읽기 트래픽을 분산하려면 RDS Read Replica를 별도로 생성하고, 애플리케이션에서 읽기 엔드포인트를 명시적으로 분리해야 한다.

graph TD App["애플리케이션"] --> WriteEP["쓰기 엔드포인트
(프라이머리)"] App --> ReadEP["읽기 엔드포인트
(Read Replica)"] WriteEP --> Primary["프라이머리 인스턴스"] Primary -->|"동기 복제"| Standby["Multi-AZ 스탠바이
페일오버 전용"] Primary -->|"비동기 복제"| Replica["Read Replica
읽기 트래픽 처리"] ReadEP --> Replica

Multi-AZ 스탠바이: 동기 복제, 직접 접근 불가, 페일오버 전용
Read Replica: 비동기 복제, 별도 엔드포인트로 읽기 트래픽 처리 가능
두 기능은 상호 보완적이며 동시에 사용할 수 있다. Multi-AZ + Read Replica 조합이 고가용성과 읽기 성능을 모두 확보하는 표준 구성이다.

실제 장애 패턴: 페일오버 후 커넥션이 복구되지 않는 경우

Multi-AZ 페일오버가 발생했는데 애플리케이션이 계속 연결 오류를 뱉는 상황이 있다. 처음엔 RDS 자체 문제라고 의심하게 된다. CloudWatch에서 확인하면 이미 새 프라이머리가 정상 동작 중이다.

실제 원인은 대부분 두 가지다. 첫째, 애플리케이션 커넥션 풀이 이전 프라이머리의 IP를 캐싱하고 있는 경우다. RDS 페일오버는 DNS 레코드를 업데이트하지만, 커넥션 풀이 DNS를 재조회하지 않고 기존 IP를 재사용하면 새 프라이머리에 도달하지 못한다. 둘째, DNS TTL이 길게 설정된 경우다.

RDS 엔드포인트의 DNS TTL은 5초로 짧게 설정되어 있다. 문제는 JVM 기반 애플리케이션이나 일부 커넥션 풀 라이브러리가 자체적으로 DNS 결과를 더 길게 캐싱한다는 점이다. JVM의 경우 networkaddress.cache.ttl 설정을 확인해야 한다.

페일오버 발생 여부와 현재 상태는 다음 CLI로 확인할 수 있다:

# RDS 인스턴스 현재 상태 및 Multi-AZ 구성 확인
aws rds describe-db-instances \
  --db-instance-identifier your-db-instance-id \
  --query 'DBInstances[0].{Status:DBInstanceStatus,MultiAZ:MultiAZ,SecondaryAZ:SecondaryAvailabilityZone,PrimaryAZ:AvailabilityZone}' \
  --region us-east-1

# 최근 페일오버 이벤트 확인
aws rds describe-events \
  --source-identifier your-db-instance-id \
  --source-type db-instance \
  --duration 60 \
  --region us-east-1

페일오버를 수동으로 테스트하려면 다음 명령을 사용한다. 이 작업은 즉시 페일오버를 트리거하므로 프로덕션 환경에서는 유지보수 윈도우 내에서 실행해야 한다:

# 수동 페일오버 트리거 (Multi-AZ 활성화된 인스턴스에서만 동작)
aws rds reboot-db-instance \
  --db-instance-identifier your-db-instance-id \
  --force-failover \
  --region us-east-1

Multi-AZ 활성화 및 확인 CLI

기존 인스턴스에 Multi-AZ를 활성화하는 것은 즉시 적용되지 않는다. 스탠바이 인스턴스 프로비저닝과 초기 동기화 시간이 필요하며, 이 과정에서 성능 영향이 있을 수 있다. 가능하면 유지보수 윈도우를 활용하거나 트래픽이 낮은 시간대에 적용하는 것이 좋다.

# 기존 RDS 인스턴스에 Multi-AZ 활성화
aws rds modify-db-instance \
  --db-instance-identifier your-db-instance-id \
  --multi-az \
  --apply-immediately \
  --region us-east-1

# Multi-AZ 상태 및 스탠바이 AZ 확인
aws rds describe-db-instances \
  --db-instance-identifier your-db-instance-id \
  --query 'DBInstances[0].{MultiAZ:MultiAZ,PrimaryAZ:AvailabilityZone,SecondaryAZ:SecondaryAvailabilityZone,Status:DBInstanceStatus}' \
  --output table \
  --region us-east-1

Multi-AZ와 Read Replica를 함께 사용하는 IAM 정책 예시

Multi-AZ 설정 변경과 이벤트 조회에 필요한 최소 권한은 다음과 같다:

🔽 IAM 정책 예시 펼치기

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RDSMultiAZManagement",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:DescribeEvents",
        "rds:ModifyDBInstance",
        "rds:RebootDBInstance"
      ],
      "Resource": "arn:aws:rds:us-east-1:123456789012:db:your-db-instance-id"
    },
    {
      "Sid": "RDSDescribeGlobal",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBEngineVersions",
        "rds:DescribeOrderableDBInstanceOptions"
      ],
      "Resource": "*"
    }
  ]
}

RDS Multi-AZ 이점 정리 및 다음 단계

RDS Multi-AZ는 단일 목적에 최적화된 기능이다. AZ 수준의 장애로부터 데이터베이스를 보호하고, 계획된 유지보수 중 다운타임을 줄이며, 자동 백업 I/O를 프라이머리에서 분리한다. 읽기 성능 향상이나 처리량 증가는 이 기능의 범위가 아니다.

고가용성과 읽기 성능을 동시에 확보하려면 Multi-AZ + Read Replica 조합이 표준이다. Multi-AZ가 장애 복구를 담당하고, Read Replica가 읽기 트래픽 분산을 담당한다.

핵심 용어 정리

용어	설명
Multi-AZ	다른 가용 영역에 스탠바이 인스턴스를 동기 복제로 유지하는 RDS 고가용성 구성
페일오버(Failover)	프라이머리 장애 시 스탠바이가 새 프라이머리로 자동 승격되는 과정
동기 복제	트랜잭션 커밋 전 스탠바이에도 기록이 완료되어야 하는 복제 방식. RPO ≈ 0 보장
Read Replica	비동기 복제로 생성된 읽기 전용 복제본. 읽기 트래픽 분산에 사용
RPO	Recovery Point Objective. 장애 발생 시 허용 가능한 최대 데이터 손실 시점

📄 RDS 스냅샷 복원 완벽 가이드: 기존 인스턴스 덮어쓰기 vs 새 엔드포인트 생성

이 블로그 검색

SW BBANG K