Aurora MySQL 호환 DB 클러스터 스냅샷을 복원하는 데 시간이 오래 걸리는 이유는 무엇인가요?

3분 분량

Amazon Aurora MySQL 호환 에디션 DB 클러스터 스냅샷을 복원하고 싶은데 시간이 오래 걸립니다.

간략한 설명

Amazon Aurora MySQL 호환 에디션 DB 클러스터의 스냅샷 복원 프로세스에는 여러 가지 중요한 작업이 포함됩니다. 예를 들어 이 프로세스 중에는 고가용성 클러스터 볼륨과 마찬가지로 Aurora 클러스터가 생성됩니다. 상태 확인, 스토리지 및 하드웨어 할당, 데이터 볼륨 쓰기와 같은 프로세스 모두 스냅샷 복원에 걸리는 시간에 영향을 미칩니다.

스냅샷 복원 시간은 다음과 같은 여러 요인의 영향을 받습니다.

Aurora 클러스터의 경우 단일 클러스터가 3개의 가용 영역(AZ)에 분산되어 고가용성을 제공합니다. Aurora 클러스터를 스냅샷에서 복원할 때는 이 3개의 AZ에 스토리지가 프로비저닝됩니다. 클러스터를 사용할 수 있게 되면 클러스터 볼륨 내에 데이터를 저장하기 위한 복제본 6개가 추가로 생성됩니다. 스토리지 볼륨은 수백 개의 스토리지 노드에 스트라이핑되고 3개의 서로 다른 AZ에 분산됩니다.
Aurora 클러스터가 생성되면 클러스터가 Amazon Simple Storage Solution S3(S3)의 데이터를 스토리지 노드에 다운로드합니다. 클러스터는 데이터를 사용할 수 있게 되기 전에 이 작업을 수행합니다. MySQL 인스턴스용 Amazon Relational Database Service(RDS)의 복원 프로세스와는 달리 복원 후에 로드 지연이 발생하지 않습니다.
Aurora 복원은 비선형적입니다. 예를 들어 각각 1GB의 데이터와 10GB의 데이터가 있는 개별 클러스터 2개를 복원할 수 있습니다. 여기서 큰 데이터 세트는 복원 시간이 10배 더 오래 걸리는 것이 아니라 작은 데이터 세트보다 조금 오래 걸립니다.
복원에 포함되는 다른 프로세스로는 상태 확인, 스토리지 및 하드웨어 할당, 데이터 볼륨 쓰기가 있습니다. 이 모든 프로세스는 시간이 많이 걸리지만 최상의 성능을 위해 정확하게 수행되어야 합니다.

해결 방법

Aurora 데이터베이스를 변경할 때 사용 사례에 따라 Aurora 클러스터 클론 기능 또는 역추적 기능을 사용할 수 있습니다.

Aurora 클러스터 클론

Aurora 클러스터 클론 기능을 사용하면 현재 클러스터의 동일한 복사본을 가장 빠르게 생성할 수 있습니다. 복제된 클러스터를 만든 후에는 원래 클러스터에 영향을 주지 않고 복제된 클러스터에 대해 변경 내용을 테스트할 수 있습니다. 테스트가 통과하면 원래 클러스터에 변경 사항을 적용할 수 있습니다.

참고: 그렇다고 해도 데이터베이스를 변경하기 전에 클러스터의 스냅샷을 생성하는 것이 가장 좋습니다.

기존 Aurora 클러스터를 복제하는 몇 가지 일반적인 사용 사례는 다음과 같습니다.

스키마 변경이나 파라미터 그룹 변경과 같은 변경의 영향을 실험하고 평가하려는 경우
데이터 내보내기 또는 분석 쿼리 실행과 같은 워크로드 집약적인 작업을 수행하려는 경우
개발 또는 테스트를 위해 비프로덕션 환경에서 프로덕션 DB 클러스터의 복사본을 생성하려는 경우

Aurora 역추적 기능

Aurora 클러스터의 역추적 기능을 사용할 수도 있습니다. 역추적을 사용하면 데이터를 제자리에서 되감아 오류를 신속하게 취소할 수 있습니다. DB 클러스터를 역추적할 때는 새 DB 클러스터를 만들지 않아도 되므로 완료하는 데 몇 분밖에 걸리지 않습니다.

하지만 이 기능에는 한계가 있습니다. 첫째, 이 기능이 활성화된 상태에서 생성된 클러스터에만 사용할 수 있습니다. 따라서 클러스터에 이 기능이 활성화되어 있지 않은 경우에는 스냅샷 복원을 수행하여 역추적을 활성화해야 합니다. 또한 역추적은 바이너리 로그 복제를 지원하지 않으므로 역추적을 구성하거나 사용하려면 먼저 교차 리전 복제를 비활성화해야 합니다. 역추적 기간의 한도는 72시간입니다.

고려 사항

Aurora 클러스터 클론 및 역추적 기능은 특정 사용 사례에서 Aurora 복원 시간을 개선하기 위해 도입되었습니다. 그러나 정기적인 스냅샷을 만드는 것이 여전히 모범 사례이므로 데이터베이스에 계획된 변경을 수행하기 전에 이 방법을 사용하는 것이 가장 좋습니다.

또한 스냅샷, 특정 시점 또는 복제가 생성될 때 소스 데이터베이스에서 장기 실행 쓰기 작업이 실행되지 않도록 해야 합니다. 장기 실행 DCL, DDL 또는 DML(열린 쓰기 트랜잭션)을 사용하면 복원된 데이터베이스를 사용할 수 있게 되는 데 걸리는 시간이 늘어날 수 있습니다.