HA/DR 옵션 및 고려 사항

AWS 가용 영역 또는 리전이 완전히 오프라인 상태가 될 가능성은 매우 드물지만 중복성을 위해 재해 발생 시 백업 및 복구에 대한 다중 접근 방식을 사용하고 데이터 손실을 최소화하는 것이 좋습니다. 백업 및 복구 프로세스에는 워크로드의 Recovery Time Objective(RTO) 및 Recovery Point Objective(RPO)를 충족하고, 업무 프로세스를 지원할 수 있는 적절한 수준의 세분화가 포함되어야 하는데, 이는 종종 애플리케이션에 따라 달라지는 경우가 많습니다. 데이터베이스의 경우는 고가용성 및 재해 복구(HA/DR)를 위한 SQL Server 설정 및 구성에 대한 모든 Microsoft 권장 사항 AWS 도 지원합니다. 다양한 버전의 SQL Server가 다양한 HA/DR 옵션을 지원하므로 VLDB(초대형 데이터베이스)와 같은 특수한 경우를 사례별로 고려해야 합니다. 다른 DR 구성과 마찬가지로 테스트는 각 애플리케이션이 HA/DR에 대한 서비스 수준에 관한 계약(SLA)를 충족하는지 확인하는 데 필수적입니다. 테스트/개발 환경에서는 무료이지만 제한이 있는 SQL Server 개발자 판을 사용해 보십시오.

15분의 RPO와 4시간의 RTO가 요구되는 사용 사례의 경우, 다음과 같은 HA/DR 옵션을 조합하여 사용할 수 있습니다.

• 웜 스탠바이를 사용하는 SQL Server 네이티브 HA/DR 옵션(데이터베이스 수준) – 이러한 아키텍처 중 일부에 대한 설명은 본 가이드의 뒷부분에 있는 Amazon EC2의 SQL Server 아키텍처 다이어그램 섹션을 참조하십시오.

  • 단일 지역(동기 체결 모드)의 또는 복수 지역(비동기 체결 모드, 기본 가용성 그룹)의 2노드 다AZ

  • 3노드(이상), 복수 지역의 다AZ(동기 체결 및 비동기 체결 모드)

  • 복수 지역에 2노드, 다AZ 및 로그 전달(5분마다 로그 백업)

• Amazon S3에 대한 SQL Server 네이티브 백업(데이터베이스 수준, DR만 해당) – 전체 백업(하루에 한 번)

  • 차등 백업(2~4시간마다).

  • 로그 백업(5~10분마다).

  • 효율적인 백업 및 전송을 위해서는 맞춤 스크립팅 또는 파일 게이트웨이와 같은 옵션을 사용하여 백업을 생성하고 Amazon Simple Storage Service(Amazon S3)에 복사해야 합니다.

  • 수백 개의 데이터베이스가 있는 경우, 계속해서 기존 백업 도구(예: Commvault 또는 Litespeed)를 사용하여 백업을 효율적으로 관리하고 Amazon S3에 직접 저장할 수 있습니다.

  • Amazon S3 교차 지역 복제(CRR)와 S3 복제 시간 제어(RTC)를 사용하여 15분 SLA 내에서 객체 복제를 제어 및 모니터링할 수 있습니다.

  • 규정 준수 및 비용 절감을 위해 S3 라이프사이클 관리를 사용하여 장기 보관을 위해 오래된 백업을 이동 및 저장할 수도 있습니다.

  • SQL Server 네이티브 백업을 정기적으로 Amazon S3로 옮기면 재해 발생 시 대상 지역에서 백업을 즉시 사용할 수 있습니다. 이렇게 하면 백업을 전송하거나 스냅샷을 복원할 필요가 없습니다.

  • 파일 크기를 줄이려면 SQL 네이티브 백업 압축을 사용하는 것이 좋습니다.

• AWS 스냅샷(인스턴스 및 볼륨 수준, DR만 해당)

  • Amazon Elastic Compute Cloud(Amazon EC2) Amazon Machine Image(AMI) 백업을 통해 데이터베이스를 처음부터 재구축합니다.

  • EBS 볼륨을 Amazon EC2에 연결하는 Amazon Elastic Block Store(Amazon EBS) 볼륨 스냅샷

에서 HA/DR 리소스 관리 AWS Backup

AWS Backup는 백업 계획 및 일정을 생성하고 Amazon EBS 볼륨과 같이 스냅샷 및 Amazon EC2 AMIs를 생성하는 HA/DR 구성과 관련된 AWS 리소스를 이러한 백업 계획에 할당할 수 있는 기능을 제공하는 완전 관리형 서비스입니다. 또한 AWS Backup 를 사용하여 이러한 EBS 스냅샷의 복수 지역 사본을 예약할 수 있습니다. 최적의 사용을 AWS Backup 위해는 리소스를 배치하기 위한 효율적인 태그 지정 메커니즘을 필요로 합니다.는 SQL Server에 사용할 수 있는 Windows Volume Shadow Copy Service(VSS)를 통한 애플리케이션 일관성 백업 AWS Backup 도 지원합니다. 스토리지 수준 보호를 위해서는 EBS 스냅샷을 사용하는 것이 좋습니다. 초기 EBS 스냅샷이 꽉 차면 후속 스냅샷은 증분식입니다. EBS 스냅샷은 스토리지 수준 보호를 제공하지만 특정 시점 복구를 제공하는 SQL Server 파일 기반 기본 백업을 대체하지는 않습니다.

HA/DR AWS DMS 에 사용

복제를 위한 SQL Server Always On 옵션의 대안을 찾고 있거나 하이브리드 설정 또는에서 이기종 소스 및 대상 데이터베이스가 있는 경우 AWS다음과 같은 방법으로 AWS Database Migration Service (AWS DMS)를 사용할 수 있습니다.

자체 관리형 컨텍스트(Amazon EC2 또는 온프레미스에서 호스팅됨)에서 SQL Server AWS DMS 와 함께를 사용하는 경우 MS-REPLICATION(기본 키가 있는 테이블에 대한 변경 사항 캡처)과 MS-CDC(기본 키가 없는 테이블에 대한 변경 사항 캡처)의 두 가지 모드에서 일회성 복제와 지속적 복제를 지원합니다. 그러나 Amazon Relational Database Service(Amazon RDS)를 소스로 사용하는 경우 MS-CDC AWS DMS만 지원됩니다.는 다양한 소스 및 대상 엔드포인트를 AWS DMS 제공하고, 이기종 데이터베이스 엔진을 지원하며, 복제 프로세스에 대한 세분화된 제어를 제공합니다. 이기종 데이터베이스 마이그레이션을 AWS DMS 위해 AWS Schema Conversion Tool (AWS SCT)를와 함께 사용할 수도 있습니다.는 스키마 수준 변경을 AWS SCT 자동화하고 마이그레이션 준비 및 계획에 대한 보고서를 생성합니다.

다음 다이어그램과 AWS DMS같이 소스 및 대상 데이터베이스를의 엔드포인트로 추가합니다. 이 서비스는 MS-REPLICATION 또는 MS-CDC를 사용하여 논리적 복제 프로세스를 구현합니다. 하이브리드 설정이 있는 경우 온프레미스와 간에 지속적인 복제 AWS DMS 를 위해를 구성할 수 있습니다 AWS. 전환 중에 AWS DMS 마이그레이션 작업을 중지할 수 있으며 애플리케이션은 추가 지연 없이 온프레미스 데이터베이스와 이미 동기화된 데이터베이스에 연결할 수 있습니다. SQL Server AWS DMS 용를 소스로 사용하는 데는 몇 가지 제한 사항이 있으며, 이는 AWS DMS 설명서에 설명되어 있습니다.

다음 시나리오에서는 네이티브 HA/DR 메서드 AWS DMS 대신를 사용하는 것이 좋습니다.

• 라이선스 비용을 절약하고 싶은 경우. 예를 들어, Always On 옵션에만 SQL Server Enterprise Edition과 같은 고급 버전을 사용하는 경우 Enterprise Edition 라이선스 비용 없이 논리적 복제 옵션을 제공할 수 있으므로 AWS DMS 대신를 설정하는 것이 좋습니다.

• 이종 소스 및 대상을 갖고 있는 경우. 기본 및 재해 복구 노드의 SQL Server 버전은 일치할 필요가 없으므로( AWS DMS 제한 내에서) 상당한 유연성을 제공합니다.

• Windows, SQL Server 클러스터링 및 분산 가용성 그룹 설정 및 관리의 오버헤드를 방지하기 위해는 간단한 설정과 간편한 복제 작업 관리를 AWS DMS 제공합니다.

• 거의 실시간 전송(복제 인스턴스, 네트워크 구성 및 데이터 볼륨에 따라 다름), 데이터 마스킹, 선택적 필터링, 스키마/표 매핑(동종 및 이종), 마이그레이션 전 평가 및 JSON 지원과 같은 업무 사용 사례에 적합합니다.

• LSN(로그 시퀀스 번호), 타임스탬프 및 유사한 옵션에 근거하여 필요에 따라 작업을 쉽게 복제, 중지 및 시작할 수 있습니다.

다음 다이어그램은가 복제 지원을 AWS DMS 제공하는 방법에 대한 대체 접근 방식을 보여줍니다. 이 구성에서 소스는 SQL Server Always On 가용성 그룹 클러스터이며 변경 데이터 캡처(CDC) 옵션을 AWS DMS 사용하여 데이터를 다른 AWS 리전의 대상에 지속적으로 복제합니다. 최적의 성능을 위해서는 복제 인스턴스의 크기가 적절하고 소스 지역에 유지되도록 하는 것이 중요합니다.

소스 엔진과 대상 엔진이 일치하지 않아도 됩니다. 다이어그램에서 (1)로 표식된 기본 노드와 보조 노드는 단일 AZ 또는 다AZ 구성의 SQL Server 클러스터일 수 있습니다. 또는 MS-CDC 또는 MS-REPLICATION을 지원하는 단일 SQL Server 노드가 소스일 수도 있습니다.

다이어그램에서 (2)로 표식된 대상 DB 인스턴스는 Amazon RDS, Amazon EC2에 있는 모든 버전의 SQL Server 또는 기타 이종 대상일 수 있습니다. 기본 및 보조 인스턴스가 일치하거나 Always On 가용성 그룹을 지원할 필요는 없습니다. 예컨대, 소스는 SQL Server Always On 가용성 그룹 클러스터일 수 있고, 대상은 Amazon Aurora PostgreSQL 병립판일 수 있습니다.

DR AWS Application Migration Service 에 사용

lift-and-shift 마이그레이션 AWS Application Migration Service 에는를 사용하는 것이 좋습니다 AWS. 애플리케이션 마이그레이션 서비스는 작동 시스템, 시스템 상태 구성, 데이터베이스, 애플리케이션 및 파일을 포함한 시스템을 대상 AWS 계정 및 선호 지역의 저렴한 스테이징 영역에 지속적으로 복제합니다. 재해가 발생하는 경우, 애플리케이션 마이그레이션 서비스를 사용하여 몇 분 만에 완전히 프로비전된 상태로 수천 대의 컴퓨터를 자동으로 시작할 수 있습니다.

추가 고려 사항

다음 목록은 HA/DR 전략을 설계할 때 고려해야 할 가능한 병목 현상을 식별합니다.

• 복수 지역 노드 설정의 대역폭, 지연 시간, 네트워크 복잡성 및 연결성.

• Amazon EBS 또는 Amazon EC2 스냅샷의 크기 및 AWS Backup를 사용하여 복사하는 데 걸리는 시간.

  • Amazon EBS 및 Amazon EC2 스냅샷은를 사용하여 Amazon S3에 저장됩니다 AWS Backup.

  • EBS 스냅샷은 현재 스냅샷이 완료될 때까지 Amazon S3의 대상 지역에 복제되지 않습니다. 복제 기간도 볼륨의 크기에 따라 다릅니다.

  • 스냅샷이 완료되면 객체들의 99.99%에 대해 스냅샷을 복사하는 데 걸리는 시간이 15분 정도로 짧을 수 있습니다. 그러나 특정 사용 사례와 중요한 대용량의 경우, 철저한 테스트가 필요합니다.

• 대상 가용 영역 및 지역의 EBS 볼륨을 복원하는 데 필요한 시간.

• 대상 가용 영역 및 지역에서 Amazon EC2 이미지를 복원하는 데 필요한 시간.

• 처음부터 구축하는 경우, 대상 가용 영역 및 지역에 Amazon EC2 이미지 또는 복원된 EBS 스냅샷을 위한 인프라를 프로비저닝하는 데 필요한 시간입니다.

• 처음부터 복원하는 경우, 대상 가용 영역 및 지역에서 SQL Server 네이티브 전체, 차등 및 로그 백업을 복원하는 데 필요한 시간입니다.

• 애플리케이션 및 외부 종속성은 여러 지역에서 사용할 수 있어야 합니다.

• 볼륨 및 Amazon S3로의 업로드에 대한 파일 크기 제한.