Amazon RDS의 백업 및 복구

Amazon RDS에는 데이터베이스 백업을 자동화하는 기능이 포함되어 있습니다. Amazon RDS는 데이터베이스 인스턴스의 스토리지 볼륨 스냅샷을 생성하여 개별 데이터베이스만 백업하는 것이 아니라 전체 DB 인스턴스를 백업합니다. Amazon RDS를 사용하면 자동 백업을 위한 백업 기간을 설정하고, 데이터베이스 인스턴스 스냅샷을 생성하고, 리전 및 계정 간에 스냅샷을 공유하고 복사할 수 있습니다.

Amazon RDS는 DB 인스턴스를 백업하고 복원하기 위한 두 가지 옵션을 제공합니다.

• 자동 백업은 DB 인스턴스의 특정 시점 복구(PITR)를 제공합니다. 새 DB 인스턴스를 생성할 때 자동 백업이 기본적으로 활성화됩니다.

  Amazon RDS는 DB 인스턴스를 생성할 때 사용자가 정의한 백업 기간 동안 데이터를 매일 전체 백업합니다. 자동 백업에 대해 최대 35일까지 보존 기간을 구성할 수 있습니다. 또한 Amazon RDS는 5분마다 DB 인스턴스에 대한 트랜잭션 로그를 Amazon S3에 업로드합니다. Amazon RDS는 데이터베이스 트랜잭션 로그와 함께 일일 백업을 사용하여 DB 인스턴스를 복원합니다. 보존 기간 중 최대 LatestRestorableTime까지(일반적으로 최근 5분) 인스턴스를 복원할 수 있습니다.

  DB 인스턴스의 복원 가능한 최신 시간을 찾으려면 DescribeDBInstances API 호출을 사용하세요. 또는 Amazon RDS 콘솔에서 데이터베이스의 설명 탭을 찾아보세요.

  PITR을 시작하면 트랜잭션 로그가 가장 적절한 일일 백업과 결합되어 DB 인스턴스를 요청한 시간으로 복원합니다.

• DB 스냅샷은 DB 인스턴스를 원하는 만큼 알려진 상태로 복원하는 데 사용할 수 있는 사용자 시작 백업입니다. 그러면 언제든지 해당 상태로 복원할 수 있습니다. Amazon RDS 콘솔 또는 CreateDBSnapshot API 호출을 사용하여 DB 스냅샷을 생성할 수 있습니다. 이러한 스냅샷은 콘솔이나 DeleteDBSnapshot API 호출을 사용하여 명시적으로 삭제할 때까지 보관됩니다.

이 두 백업 옵션 모두 AWS Backup의 Amazon RDS에서 지원되며 다른 기능도 제공합니다. Amazon RDS 데이터베이스의 표준 백업 계획을 설정하는 데 AWS Backup을(를) 사용하고, 특정 데이터베이스의 백업 계획이 다르면 사용자가 시작한 인스턴스 백업 옵션을 사용하는 것이 좋습니다.

Amazon RDS는 DB 인스턴스가 사용하는 기본 스토리지에 직접 액세스하는 것을 방지합니다. 또한 이렇게 하면 RDS DB 인스턴스의 데이터베이스를 로컬 디스크로 직접 내보낼 수 없습니다. 경우에 따라 클라이언트 유틸리티를 사용하여 기본 백업 및 복원 기능을 사용할 수 있습니다. 예를 들어, Amazon RDS MySQL 데이터베이스와 함께 mysqldump 명령을 사용하여 데이터베이스를 로컬 클라이언트 시스템으로 내보낼 수 있습니다. 경우에 따라 Amazon RDS는 데이터베이스의 기본 백업 및 복원을 수행할 수 있는 확장된 옵션도 제공합니다. 예를 들어 Amazon RDS는 SQL Server 데이터베이스의 RDS 데이터베이스 백업을 내보내고 가져오기 위한 저장 프로시저를 제공합니다.

전반적인 백업 및 복원 접근 방식의 일환으로 데이터베이스 복원 프로세스와 데이터베이스 클라이언트에 미치는 영향을 철저하게 테스트해야 합니다.

DNS CNAME 레코드를 사용하면 데이터베이스 복구 중에 클라이언트에 미치는 영향을 줄일 수 있습니다.

PITR 또는 RDS DB 인스턴스 스냅샷을 사용하여 데이터베이스를 복원하면 새 엔드포인트가 있는 새 DB 인스턴스가 생성됩니다. 이렇게 하면 특정 DB 스냅샷 또는 특정 시점에서 여러 DB 인스턴스를 만들 수 있습니다. 라이브 RDS DB 인스턴스를 대체하기 위해 RDS DB 인스턴스를 복원할 때는 특히 고려해야 할 사항이 있습니다. 예를 들어 중단과 수정을 최소화하면서 기존 데이터베이스 클라이언트를 새 인스턴스로 리디렉션할 방법을 결정해야 합니다. 새 인스턴스가 쓰기를 받기 시작할 때의 복원된 데이터 시간과 복구 시간을 고려하여 데이터베이스 내 데이터의 연속성과 일관성을 보장해야 합니다.

DB 인스턴스 엔드포인트를 가리키는 별도의 DNS CNAME 레코드를 만들고 클라이언트가 이 DNS 이름을 사용하도록 할 수 있습니다. 그러면 데이터베이스 클라이언트를 업데이트할 필요 없이 CNAME이 복원된 새 엔드포인트를 가리키도록 업데이트할 수 있습니다.

CNAME 레코드의 Time to Live(TTL)를 적절한 값으로 설정합니다. 지정하는 TTL에 따라 다른 요청이 이루어지기 전에 DNS 해석기로 레코드를 캐시하는 데 걸리는 시간이 결정됩니다. 참고로 일부 DNS 해석기 또는 애플리케이션은 TTL을 준수하지 않을 수 있으며 TTL보다 더 오래 레코드를 캐시할 수 있습니다. Amazon Route 53의 경우, 더 긴 값(예: 172800초 또는 2일)을 지정한 경우, 이 레코드의 최신 정보를 얻으려면 DNS recursive resolver의 Route 53에 대한 호출 수를 줄여야 합니다. 이렇게 하면 지연 시간이 줄어들고 Route 53 서비스에 대한 요금이 절감됩니다. 자세한 내용은 Amazon Route 53이 도메인의 트래픽을 라우팅하는 방법을 참조하세요.

애플리케이션과 클라이언트 운영 체제는 새 DNS 확인 요청을 시작하고 업데이트된 CNAME 레코드를 검색하기 위해 플러시하거나 다시 시작해야 하는 DNS 정보를 캐시할 수도 있습니다.

데이터베이스 복원을 시작하고 복원된 인스턴스로 트래픽을 이동할 때는 모든 클라이언트가 이전 인스턴스 대신 복원된 인스턴스에 쓰고 있는지 확인하세요. 데이터 아키텍처는 데이터베이스를 복원하고, 복원된 인스턴스로 트래픽을 이동하도록 DNS를 업데이트하며, 이전 인스턴스에 아직 기록되어 있을 수 있는 모든 데이터를 수정하는 것을 지원할 수 있습니다. 그렇지 않은 경우 DNS CNAME 레코드를 업데이트하기 전에 기존 인스턴스를 중지할 수 있습니다. 그러면 새로 복원된 인스턴스에서 모든 액세스가 이루어집니다. 이로 인해 일부 데이터베이스 클라이언트에 일시적으로 연결 문제가 발생할 수 있으며, 이는 개별적으로 처리할 수 있습니다. 클라이언트에 미치는 영향을 줄이려면 유지 관리 기간 중에 데이터베이스 복원을 수행하시기 바랍니다.

지수 백오프를 사용한 재시도를 통해 데이터베이스 연결 실패를 적절하게 처리하도록 애플리케이션을 작성하세요. 이렇게 하면 복원 중에 데이터베이스 연결을 사용할 수 없게 되어도 애플리케이션이 예기치 않게 충돌하지 않고 복구할 수 있습니다.

복원 프로세스를 완료한 후 이전 인스턴스를 중지된 상태로 유지할 수 있습니다. 또는 보안 그룹 규칙을 사용하여 더 이상 필요하지 않다고 판단될 때까지 이전 인스턴스에 대한 트래픽을 제한할 수 있습니다. 점진적인 서비스 해제 방식을 취하려면 먼저 보안 그룹이 실행 중인 데이터베이스에 대한 액세스를 제한하세요. 더 이상 필요하지 않은 인스턴스는 결국 중지할 수 있습니다. 마지막으로 데이터베이스 인스턴스의 스냅샷을 만들고 삭제합니다.