실습 예제 · 4

RDS Multi-AZ와 읽기 전용 복제본

시험이 가장 집요하게 노리는 쌍을 손으로 확인하는 실습입니다. 같은 데이터베이스에 Multi-AZ와 읽기 전용 복제본을 함께 구성하고, 장애 조치를 직접 일으켜 엔드포인트가 어떻게 움직이는지 봅니다. 표로 외우는 것과 실제로 보는 것은 다릅니다.

관련 도메인: 복원력 있는 아키텍처 설계(26%) · 고성능 아키텍처 설계(24%)

학습 목표

시나리오

실습 1의 데이터베이스 서브넷에 관계형 데이터베이스를 만듭니다. 확인할 것은 둘입니다.

배경 개념은 10장 RDS와 관계형 데이터베이스에 있고, 어느 처방이 어떤 문제를 푸는지는 케이스 2 · 읽기 부하로 데이터베이스가 죽었다에서 다룹니다.

아키텍처 개요

Multi-AZ와 읽기 전용 복제본의 성질 비교
항목 Multi-AZ 배포 읽기 전용 복제본
복제 방식 동기(synchronous) 비동기(asynchronous)
목적 고가용성 읽기 확장
엔드포인트 동일하게 유지 별도 엔드포인트
읽기 처리 대기 인스턴스는 받지 않는다 받는다
리전 같은 리전의 다른 가용 영역 같은 리전 또는 다른 리전
장애 시 전환 자동 수동 승격이 필요

읽기 전용 복제본 개수에는 상한이 있습니다. MySQL · MariaDB · PostgreSQL은 인스턴스당 최대 15개, Oracle과 SQL Server는 5개, Db2는 3개입니다.

구성 단계

1 · DB 서브넷 그룹

서로 다른 가용 영역의 프라이빗 서브넷만 넣습니다. 퍼블릭 서브넷을 넣으면 나중에 퍼블릭 액세스 설정 실수가 곧바로 노출로 이어집니다.

create-subnet-group.sh — 프라이빗 서브넷만으로 구성 (서브넷 ID는 실습 1의 출력값입니다)
aws rds create-db-subnet-group \
  --db-subnet-group-name lab04-db-subnets \
  --db-subnet-group-description "private db subnets" \
  --subnet-ids subnet-0db00000000000a subnet-0db00000000000b

2 · Multi-AZ 데이터베이스 만들기

create-db.sh — Multi-AZ 인스턴스 생성 (식별자·클래스·엔진 버전은 예시입니다)
aws rds create-db-instance \
  --db-instance-identifier lab04-primary \
  --db-instance-class db.t3.micro \
  --engine mysql \
  --allocated-storage 20 \
  --master-username admin \
  --manage-master-user-password \
  --db-subnet-group-name lab04-db-subnets \
  --vpc-security-group-ids sg-0db0000000000000d \
  --multi-az \
  --no-publicly-accessible \
  --storage-encrypted \
  --backup-retention-period 7

aws rds wait db-instance-available --db-instance-identifier lab04-primary

3 · 읽기 전용 복제본 만들기

create-replica.sh — 같은 리전에 복제본 생성
aws rds create-db-instance-read-replica \
  --db-instance-identifier lab04-replica-1 \
  --source-db-instance-identifier lab04-primary

aws rds wait db-instance-available --db-instance-identifier lab04-replica-1

원본 인스턴스는 자동 백업이 활성화되어 있어야 복제본을 만들 수 있습니다. 위에서 --backup-retention-period 7을 준 이유가 이것입니다. 만들어진 복제본은 백업이 비활성화된 상태로 생성됩니다.

검증 방법

엔드포인트 비교

show-endpoints.sh — 프라이머리와 복제본의 엔드포인트·가용 영역 확인
aws rds describe-db-instances \
  --query 'DBInstances[?starts_with(DBInstanceIdentifier, `lab04`)].[
             DBInstanceIdentifier, MultiAZ, AvailabilityZone,
             SecondaryAvailabilityZone, Endpoint.Address,
             ReadReplicaSourceDBInstanceIdentifier]' \
  --output table

여기서 확인할 것은 셋입니다. 프라이머리에 보조 가용 영역이 채워져 있고, 복제본은 다른 엔드포인트 주소를 가지며, 복제본에는 원본 식별자가 표시된다는 점입니다.

강제 장애 조치

force-failover.sh — 장애 조치를 일으키고 전후를 비교
# 장애 조치 전 주소와 가용 영역을 기록해 둡니다.
aws rds describe-db-instances --db-instance-identifier lab04-primary \
  --query 'DBInstances[0].[Endpoint.Address,AvailabilityZone]' --output text

aws rds reboot-db-instance \
  --db-instance-identifier lab04-primary \
  --force-failover

aws rds wait db-instance-available --db-instance-identifier lab04-primary

# 장애 조치 후 다시 확인합니다.
aws rds describe-db-instances --db-instance-identifier lab04-primary \
  --query 'DBInstances[0].[Endpoint.Address,AvailabilityZone]' --output text

# 이벤트 기록으로 무슨 일이 있었는지 봅니다.
aws rds describe-events \
  --source-identifier lab04-primary \
  --source-type db-instance \
  --duration 60 \
  --query 'Events[].[Date,Message]' --output table
장애 조치 전후에 무엇이 바뀌고 무엇이 그대로인가
항목 결과 의미
엔드포인트 주소 그대로 애플리케이션 설정을 고칠 필요가 없다. DNS가 새 인스턴스를 가리킨다
가용 영역 바뀐다 대기 인스턴스가 있던 가용 영역으로 이동했다
연결 일시적으로 끊긴다 애플리케이션에 재연결 로직이 필요하다
복제본 엔드포인트 그대로 복제본은 장애 조치와 무관하게 자기 주소를 유지한다

복제본은 자동 승격되지 않는다

읽기 전용 복제본이 재해 복구 수단이 되려면 승격이 필요하고, 이 작업은 자동으로 일어나지 않습니다. 승격하면 복제 관계가 끊기고 독립 인스턴스가 됩니다.

promote.sh — 복제본 승격 (되돌릴 수 없으므로 실습 마지막에 수행합니다)
aws rds promote-read-replica \
  --db-instance-identifier lab04-replica-1

aws rds wait db-instance-available --db-instance-identifier lab04-replica-1

# 승격 후에는 원본 식별자가 사라집니다.
aws rds describe-db-instances --db-instance-identifier lab04-replica-1 \
  --query 'DBInstances[0].ReadReplicaSourceDBInstanceIdentifier'

비용 고려

요금이 발생하는 항목
항목 성격
Multi-AZ 대기 인스턴스 인스턴스가 한 벌 더 필요하다. 읽기 처리량은 늘지 않는다
가용 영역 간 복제 트래픽 동기 복제가 가용 영역 경계를 넘는다
읽기 전용 복제본 복제본 수만큼 인스턴스와 스토리지
교차 리전 복제본 위에 더해 리전 간 전송이 붙는다
스토리지와 백업 할당 용량과 보존 기간을 넘는 백업
스냅샷 수동 스냅샷은 인스턴스를 지워도 남는다

비용 판단의 요점은 무엇을 사는가입니다. Multi-AZ는 가용성을 사고, 복제본은 읽기 처리량을 삽니다. 읽기가 문제인데 Multi-AZ를 켜면 비용만 늘고 문제는 남습니다.

프로덕션 고려사항

정리 — 리소스 삭제

cleanup.sh — 복제본부터 삭제한 뒤 프라이머리 삭제
aws rds delete-db-instance \
  --db-instance-identifier lab04-replica-1 \
  --skip-final-snapshot

aws rds wait db-instance-deleted --db-instance-identifier lab04-replica-1

aws rds delete-db-instance \
  --db-instance-identifier lab04-primary \
  --skip-final-snapshot \
  --delete-automated-backups

aws rds wait db-instance-deleted --db-instance-identifier lab04-primary

aws rds delete-db-subnet-group --db-subnet-group-name lab04-db-subnets

# 남아 있는 수동 스냅샷이 없는지 확인합니다.
aws rds describe-db-snapshots \
  --snapshot-type manual \
  --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime]' \
  --output table

자주 하는 실수

자주 나오는 실수와 증상
실수 증상 고치는 법
읽기 부하 해결로 Multi-AZ를 켬 비용만 늘고 읽기 성능은 그대로 읽기 전용 복제본이나 캐시를 쓴다
모든 읽기를 복제본으로 보냄 방금 쓴 데이터가 조회되지 않는다 쓰기 직후 읽기는 프라이머리로 고정한다
DB 서브넷 그룹에 퍼블릭 서브넷 포함 퍼블릭 액세스 설정 실수가 곧바로 노출로 이어진다 프라이빗 서브넷만 넣는다(케이스 4)
자동 백업이 꺼진 상태에서 복제본 생성 시도 생성이 거부된다 원본의 백업 보존 기간을 1 이상으로 설정한다
복제본이 자동으로 승격될 것이라 가정 프라이머리 장애 시 쓰기가 계속 실패한다 승격은 별도 작업임을 절차서에 반영한다
생성 후 암호화를 켜려 함 설정을 바꿀 수 없다 스냅샷을 암호화 옵션으로 복사해 복원한다
DNS 캐시가 긴 클라이언트 장애 조치 후에도 옛 주소로 접속한다 클라이언트의 DNS 캐시 시간을 짧게 조정한다

이어서 볼 곳

공식 문서 출처