Amazon Aurora Global Database

Cloud

Amazon Aurora Global Database

All_is_LiJell 2025. 6. 27. 16:09

개요

본 문서는 Amazon Aurora Global Database에 대한 핵심 개념과 기능을 명확하게 이해하고, 실제 운영에서의 구성 및 관리 방법을 설명하는 것을 목적으로 합니다.

1. Aurora Global Database 개념과 필요성

Amazon Aurora Global Database 사용 - Amazon Aurora

Amazon Aurora Global Database는 멀티 리전 환경에서 데이터베이스의 가용성과 성능을 높이기 위한 솔루션입니다. 단일 Primary 리전에서 쓰기를 수행하고, 하나 이상의 Secondary 리전에서는 읽기 전용으로 동작하며, 스토리지 레벨 비동기 복제를 통해 낮은 복제 지연(RPO 수초 이내)을 제공합니다.

지원 엔진/버전:

Secondary Region 지원 확대: 최대 10개 Secondary Regions 가능 (2025년 5월 발표) Amazon Aurora Global Database introduces support for up to 10 secondary Regions | AWS Database Blog
장점:
- 전 세계에 걸친 읽기 처리 분산
- 리전 단위 장애 시 DR(재해 복구) 환경 제공

2. 복제 메커니즘 (스토리지 기반 비동기 복제)

Aurora Global Database의 복제는 스토리지 계층에서 직접 수행됩니다. 변경된 데이터 블록을 로그로 캡처하여 글로벌 복제 스트림으로 묶은 뒤, 각 Secondary 리전의 스토리지 노드로 병렬 전송합니다. Secondary는 수신한 로그를 적용하여 로컬 데이터를 Primary와 일치시킵니다. 이 방식은 다음 장점을 제공합니다:

저지연: 변경된 블록만 전송하여 네트워크 부하 최소화
병렬 처리: 다수 블록을 동시 전송해 복제 처리량 향상
일관성·내구성: Secondary 노드의 로컬 커밋으로 데이터 무결성 보장
높은 가용성: 리전 간 장애 시 Secondary 승격 후 즉시 쓰기 가능

3. Failover 방식 비교: 관리형(Managed) vs 자동(Failover)

Aurora Global Database는 두 가지 방식의 리전 간 장애 조치 기능을 제공합니다.

3-1. Managed Failover 전환 절차

Secondary 리전과 완전 동기화 대기
Secondary의 Reader 중 하나를 Writer로 승격
기존 Primary를 Reader로 전환
자동 데이터 무손실 전환, 짧은 다운타임

3-2. CLI 예시

aws rds switchover-global-cluster \
  --global-cluster-identifier my-global \
  --target-db-cluster-identifier <secondary-arn>

4. 네트워크 흐름 및 주요 엔드포인트

Aurora Global Database는 두 가지 주요 쓰기 라우팅 방식을 제공합니다.

4-1. Global Writer Endpoint

경로: 클라이언트 → Global Writer Endpoint(Route 53 Alias) → Primary Writer 인스턴스
특징:
- 홉 수 1회
- DNS Alias로 자동 재매핑하여 장애 조치 시 주소 불변
- 모든 쓰기 트래픽이 Primary 리전으로 집중

4-2. Global Write Forwarding

경로: 클라이언트 → Secondary Reader 엔드포인트 → Aurora 전용 복제망 → Primary Writer
특징:
- 홉 수 2회
- 로컬 리전 VPC에서 첫 핸드셰이크, Aurora 복제망에서 Primary로 포워딩 ( vpc peering 또는 TGW 없이 writer로 쓰기 가능)
- 일부 트랜잭션 워크로드에 지연 이슈 발생 가능

4-3 기능 조합 시 Failover 동작 비교

기능 조합	장애 전 동작 (A Primary, B Secondary)	장애 후 동작 (A Secondary, B Primary)
Global Writer Endpoint만 사용	Writer endpoint → A의 Writer로 연결	Writer endpoint → B의 Writer로 자동 전환
Write Forwarding만 사용	Reader endpoint → B로 연결, A Writer에 내부 포워딩	Reader endpoint → A로 재설정 필요 (새로운 Secondary로)
둘 다 사용	Writer endpoint → A로, Reader endpoint → B로	Writer endpoint → B로, Reader endpoint → A로 (양쪽 모두 자동 전환 아님)
둘 다 사용하지 않음	Writer endpoint → A로 수동 설정 필요, B Reader는 쓰기 불가	Writer endpoint → B로 수동 변경 필요, A Reader는 여전히 쓰기 불가

5. Global Write Forwarding 상세

5-1. 활성화 방법

콘솔: Secondary 클러스터 선택 → Modify → Enable global write forwarding
CLI:

aws rds modify-db-cluster \
  --db-cluster-identifier <secondary-cluster-id> \
  --enable-global-write-forwarding

5-2. Read-After-Write Consistency 모드

예시:

파라미터:

MySQL: aurora_replica_read_consistency
PostgreSQL: apg_write_forward.consistency_mode

5-3. 사용 시나리오 예시

EVENTUAL: 성능 우선 웹 애플리케이션
SESSION: 사용자 세션 기반 쇼핑카트 처리
GLOBAL: 금융·결제 시스템 등 강력 일관성 필요

5-4 Write Forwarding 가능 유형

5-5. 기능 조합 시 Failover 동작 비교

기능 조합	장애 전 동작 (A Primary, B Secondary)	장애 후 동작 (A Secondary, B Primary)
Global Writer Endpoint만 사용	Writer endpoint → A의 Writer로 연결	Writer endpoint → B의 Writer로 자동 전환
Write Forwarding만 사용	Reader endpoint → B로 연결, A Writer에 내부 포워딩	Reader endpoint → A로 재설정 필요 (새로운 Secondary로)

5-6. Writer Endpoint / Write Forwarding 단독 vs 혼용 시 장단점

사용 방식	장점	단점
Global Writer Endpoint만 사용	단일 쓰기 엔드포인트로 구성 단순- 장애 조치 시 자동 연결	모든 쓰기 트래픽이 Primary로 집중- 리전 간 네트워크 비용 발생
Global Write Forwarding만 사용	Secondary에서도 쓰기 가능- 리전 레이턴시 절감 가능	복잡한 failover 시 Reader endpoint 수동 전환 필요- 세션 설정 필요
둘 다 혼용	장애 시 대응 유연- 글로벌 사용자 분산 트래픽 설계 가능	두 경로를 애플리케이션에서 명확히 분리 관리해야 함

6. 글로벌 데이터베이스 전환 시 다운타임

결론부터: Aurora Global Database로 전환할 때 다운타임은 없습니다. modifying 상태는 백그라운드 구성 작업이며, Writer 인스턴스는 available 상태로 계속 I/O를 처리합니다.

순서:
- 기존 Regional 클러스터가 Global Cluster의 Primary로 등록
- 내부적으로 replication stream 구성 및 KMS 키 검증
- 관련 메타데이터 업데이트

modifying 상태: 내부 메타데이터·복제 스트림 설정 중
Writer 인스턴스: 가용 상태 유지, 쓰기·읽기 정상
제한: 콘솔/CLI의 다른 Modify 작업 일시 제한

7. 비용 및 성능 고려사항

전환 비용: 없음
Secondary 인스턴스: 시간 단위 인스턴스 과금
복제 전송: $0.02/GB (Secondary→Primary)
Global Writer Endpoint: 요청·응답 양방향 $0.02/GB씩, 최대 $0.04/GB
레이턴시: 홉 수 및 경로별 네트워크 품질이 성능에 직결

✅ Global Write Forwarding은 Aurora 내부 복제망을 사용하므로 추가 네트워크 비용이 발생하지 않습니다.

예:

8. 운영 및 자동화 베스트 프랙티스

모니터링: CloudWatch AuroraGlobalDBReplicationLag, AuroraGlobalDBRPOLag
자동화: Terraform으로 구성 관리, Lambda+Alarm으로 Failover 자동화

Aurora Global Database로 전환하면 Primary Cluster가 modifying 상태가 되는데,
그 시간 동안 DB가 다운되거나 쓰기 중단되는지는 실제 운영에 중요한 영향을 미치니까요.