[reinvent 2025] Making your Amazon Aurora cluster more resilient

들어가며

이번 세션은 Amazon Aurora가 제공하는 스토리지 고가용성(HA), 재해 복구(DR), Aurora Global Database 구조 등 다양한 기능을 질의응답 기반의 chalk talk 형식으로 깊이 있게 다루는 것을 목표로 진행되었습니다.

Aurora Storage의 핵심 구조

Aurora는 3개의 가용 영역(AZ)에 걸쳐 6개의 스토리지 복사본을 유지하는 구조를 통해 높은 내구성과 가용성을 제공합니다.
Writer와 Reader 인스턴스는 모두 동일한 공유 스토리지를 사용하기 때문에 기존 데이터베이스처럼 인스턴스 간 로그 복제가 필요하지 않습니다.

스토리지는 물리적 수준에서 로그 및 데이터 일관성을 유지하며, AZ 하나와 추가 복사본 하나가 동시에 장애가 발생하더라도 정상적으로 동작할 수 있도록 설계되어 있습니다.
이러한 구조를 기반으로 빠른 장애 조치, Reader 인스턴스의 신속한 재기동, 안정적인 데이터 일관성이 보장됩니다.

Aurora Backup/Recovery, Clone 기능을 통한 운영 안정성

Aurora는 최대 35일간의 Point-in-Time Recovery(PITR) 를 지원하며, 스냅샷 기반 복원을 통해 특정 시점으로 빠르게 복원할 수 있습니다.

복원 시 기존 인스턴스를 덮어쓰지 않고 항상 새로운 인스턴스로 생성되기 때문에 운영 환경에서 안전성과 예측 가능성이 높습니다.

또한 Aurora Clone 기능은 copy-on-write 기술을 활용하여 즉시 클러스터 복제가 가능합니다.

이 기능은 아래와 같은 다양한 상황에서 매우 유용하게 활용될 수 있습니다.

• 개발 / 테스트 환경 구성
• 대규모 데이터 수정 작업 전 사전 점검
• Global Index 생성 테스트
• 대량 업데이트 및 스키마 변경 검증

실제 운영 모범 사례에서도 Aurora Clone 기능 활용이 강력하게 권장되어 소개 되었습니다.

확장성 (Read Replica)

Reader endpoint는 DNS 라운드 로빈 방식으로 부하를 분산하며, 장애 조치 시 새로운 Writer가 캐시를 다시 로딩해야 하기 때문에 일시적인 성능 저하가 발생할 수 있습니다.

이를 완화하기 위해 Aurora는 클러스터 캐시 관리 기능을 제공하여 성능 안정성을 높일 수 있습니다.

Aurora Global Database와 Switch over 전략

Global Database는 최대 5개의 보조 리전 구성이 가능하며, 각 리전은 독립적인 Aurora 클러스터로 구성됩니다.

리전 간 복제 지연은 보통 1초 미만으로 소개되었으며, 계획된 전환(switchover)은 API 기반으로 수행되어 RTO(서비스 중단 시간)가 거의 0에 가깝게 보장된다고 설명되었습니다.

또한 일부 고객사는 실제 장애 대응 역량을 강화하기 위해 8시간마다 리전을 주기적으로 교체하는 운영 패턴을 적용하고 있다는 사례도 공유되었습니다.

세션에서는 다음과 같은 점이 반복적으로 강조되었습니다 : “데이터만 준비되어 있다고 복구가 가능한 것이 아니라, 애플리케이션 스택 전체가 보조 리전에서도 즉시 동작할 수 있어야 한다.”

Aurora Driver, DNS, Connection 관리

결론

이번 세션은 Aurora의 가용성을 구성하는 핵심 요소인 스토리지 계층의 복제, 클론, 백업, Global Database, Connection 관리 등을 실무 중심으로 다룬 내용이 매우 유익했습니다.

특히 chalk talk 방식으로 진행되면서 실제 Prod 환경에서 마주칠 수 있는 다양한 문제 상황과 해결 방법에 대해 구체적이고 실전적인 인사이트를 얻을 수 있었습니다.