다중 AZ 및 자동 백업

Multi-AZ는 동일한 리전 내 다른 가용 영역에 동기식 대기 복제본을 자동으로 프로비저닝하는 RDS 고가용성 기능입니다. AWS가 복제를 투명하게 관리하므로 단일 DNS 엔드포인트로 연결하면 RDS가 기본 인스턴스로 트래픽을 라우팅합니다.

하드웨어, 네트워크 또는 OS 문제로 기본 인스턴스에 장애가 발생하면 RDS는 약 60~120초 안에 대기 인스턴스로 자동 장애 조치를 수행합니다. 애플리케이션은 동일한 DNS 엔드포인트를 사용해 다시 연결하며, 이 엔드포인트는 이제 대기 인스턴스의 IP 주소로 확인됩니다.

RDS 인스턴스를 생성할 때 Multi-AZ를 활성화하거나 기존 인스턴스를 수정하여 활성화할 수 있습니다. 실행 중인 인스턴스에서 활성화하면 AWS가 기본 인스턴스의 스냅샷을 생성하고 두 번째 AZ에 복원한 다음 엔진의 기본 복제 기능을 사용해 동기화합니다. 이 과정에서 기본 인스턴스의 I/O가 잠시 중단될 수 있으므로 트래픽이 적은 시간에 예약하거나 유지 관리 기간에 맞춰 진행하세요.

Multi-AZ는 MySQL, PostgreSQL, MariaDB, 오라클, SQL 서버를 비롯한 모든 RDS 엔진에서 지원되며 애플리케이션 수준의 변경이 필요하지 않습니다.

장애 조치가 발생하면 RDS는 약 60초 이내에 DB 엔드포인트의 DNS CNAME을 대기 인스턴스를 가리키도록 업데이트합니다. 애플리케이션은 TCP 연결이 끊어진 것을 감지한 후 다시 연결해야 합니다. 다시 연결하는 데 걸리는 시간을 줄이려면 다음을 수행하세요.

• 짧은 DNS TTL을 사용합니다(RDS에서 일반적으로 이미 5초로 설정되어 있음)
• 연결 로직에 지수 백오프와 재시도를 구현합니다
• 자동으로 다시 연결하는 RDS Proxy와 같은 연결 풀링 도구를 사용합니다

유지 관리나 인스턴스 클래스 변경을 위해 장애 조치를 수동으로 트리거할 수도 있습니다. Multi-AZ가 활성화되어 있으면 업그레이드 중 중단 시간을 거의 없앨 수 있습니다.

시험에서 자주 혼동하는 부분은 Multi-AZ(가용성을 위한 기능)와 읽기 전용 복제본(확장성을 위한 기능)의 차이입니다. 주요 차이점은 다음과 같습니다.

• Multi-AZ 대기 인스턴스: 동기식 복제, 읽기 트래픽 처리 안 함, 자동 장애 조치, 동일한 리전
• 읽기 전용 복제본: 비동기식 복제, 읽기 트래픽 처리, 자동 장애 조치 없음, 리전 간 배치 가능

Multi-AZ는 읽기 성능을 향상시키지 않습니다. 대기 인스턴스에는 쿼리를 실행할 수 없기 때문입니다. 가용성을 높이는 동시에 읽기를 확장하려면 기본 인스턴스에 Multi-AZ를 사용하고 읽기 전용 복제본을 별도로 추가하세요.

RDS는 매일 전체 데이터베이스 스냅샷을 자동으로 생성하고 5분마다 트랜잭션 로그를 캡처합니다. 이 두 기능을 함께 사용하면 백업 보존 기간 내 임의의 시점으로 복구하는 특정 시점 복구(PITR)가 가능합니다. 해당 기간 내 어느 시점의 상태로든 데이터베이스를 복원할 수 있습니다.

자동 백업은 기본적으로 활성화되어 있으며 1~35일 동안 보존할 수 있습니다. 보존 기간을 0으로 설정하면 자동 백업과 PITR이 비활성화됩니다. 백업 기간은 사용자가 지정하거나 AWS가 사용량이 적은 시간대에 선택하는 30분의 시간 구간입니다.

백업 기간은 매일 스냅샷이 생성되는 시간입니다. 이 기간 동안 Single-AZ 배포에서는 스토리지 I/O가 잠시 중단될 수 있습니다. Multi-AZ 배포에서는 대기 인스턴스에서 스냅샷을 생성하므로 기본 인스턴스의 I/O에 영향을 주지 않습니다.

유지 관리 기간은 AWS가 OS 패치, 엔진 마이너 업그레이드 및 인스턴스 수정을 적용하는 별도의 주간 시간대입니다. 두 기간을 모두 트래픽이 적은 시간대로 설정하고 서로 겹치지 않게 하는 것이 모범 사례입니다.

특정 시점으로 복원하려면 RDS가 먼저 가장 최근의 일일 스냅샷을 복원한 다음, 요청된 타임스탬프까지 트랜잭션 로그를 재생합니다. 그 결과는 새 DB 인스턴스가 됩니다. PITR은 원본 인스턴스를 절대 덮어쓰지 않으므로 프로덕션을 중단하지 않고 안전하게 복구할 수 있습니다.

복원된 인스턴스를 사용할 수 있게 되면 애플리케이션의 연결 문자열을 새 엔드포인트로 변경하고 데이터 무결성을 확인한 다음, 복구가 의도한 작업이었다면 원본을 삭제합니다. 일반적인 복원 시간은 데이터베이스 크기와 마지막 스냅샷 이후의 로그 양에 비례합니다.

자동 백업과 별도로 언제든 수동 스냅샷을 생성할 수 있습니다. 자동 백업과 달리 수동 스냅샷은 보존 기간의 적용을 받지 않으며, 명시적으로 삭제할 때까지 유지됩니다.

수동 스냅샷은 주요 스키마 마이그레이션이나 애플리케이션 업그레이드 전에 상태를 저장하거나, 규정 준수 목적의 보관을 위해 결제 주기가 끝날 때 상태를 저장하는 데 적합합니다. 또한 다른 AWS 계정과 수동 스냅샷을 공유하거나 재해 복구를 위해 여러 리전에 복사할 수도 있습니다.

재해 복구를 위해 자동 또는 수동 스냅샷을 다른 AWS 리전에 복사할 수 있습니다. 복사본은 대상 리전의 S3 인프라에 저장되는 전체 스냅샷입니다. 복사가 완료되면 기본 리전을 사용할 수 없게 된 경우 해당 리전에 새 RDS 인스턴스를 복원할 수 있습니다.

원본이 암호화되지 않았더라도 대상에서 스냅샷 복사본을 암호화할 수 있으며, 그 반대도 가능합니다. 리전 간 복사에는 데이터 전송 비용이 발생합니다. 주기적인 리전 간 스냅샷 복사를 자동화하려면 AWS Backup 또는 EventBridge가 트리거하는 Lambda를 사용하십시오.

Amazon RDS Proxy는 애플리케이션과 RDS 사이에서 데이터베이스 연결을 풀링합니다. 수명이 짧은 연결을 수천 개까지 열어 데이터베이스 연결 한도를 소진할 수 있는 Lambda 함수에 특히 유용합니다. RDS Proxy는 연결을 다중화하여 데이터베이스에 표시되는 활성 연결 수를 크게 줄입니다.

Multi-AZ 장애 조치 중에는 RDS Proxy가 애플리케이션 연결을 유지하고 새 기본 인스턴스에 대한 데이터베이스 연결을 다시 설정하므로, 애플리케이션 재연결 시간이 몇 분에서 몇 초로 줄어듭니다. 또한 RDS Proxy는 Secrets Manager와 통합되어 애플리케이션 중단 없이 자격 증명을 교체할 수 있습니다.

RDS는 이제 두 가지 Multi-AZ 옵션을 제공합니다. Multi-AZ DB 인스턴스(기존 방식, 대기 인스턴스 하나)와 Multi-AZ DB 클러스터(서로 다른 AZ에 읽을 수 있는 대기 인스턴스 두 개)입니다. 클러스터 모드는 반동기식 복제를 사용하고 대기 인스턴스에서 읽기 트래픽을 처리할 수 있으므로, 별도의 Read Replicas 없이도 더 높은 가용성과 읽기 확장성을 제공합니다.

SAA-C03 시험에서는 기존 방식인 Multi-AZ DB 인스턴스가 가장 자주 출제됩니다. Multi-AZ 클러스터는 대기 인스턴스가 읽기를 처리할 수 있는 최신 옵션인 반면, 기존 방식의 대기 인스턴스는 읽기를 처리할 수 없다는 점을 기억하십시오.

이 단원에서 다룬 AWS Solutions Architect(SAA-C03) 개념을 제대로 이해했는지 확인해 보십시오.

이 단원에서는 다음을 배웠습니다. Multi-AZ는 60~120초 내에 자동 장애 조치가 이루어지는 동기식 대기 복제를 제공하고, 자동 백업은 보존 기간(1~35일) 내 임의의 초 단위 시점으로 PITR을 가능하게 하며, 수동 스냅샷은 영구적으로 유지되고 재해 복구를 위해 리전 간 복사할 수 있습니다. 다음 단원에서는 읽기 트래픽을 분산하고 읽기 처리량을 향상하는 Read Replicas를 살펴봅니다.