AWS Database Migration Service의 모범 사례 - AWS Database Migration Service

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

AWS Database Migration Service의 모범 사례

사용AWS Database Migration Service(AWS DMS) 가장 효과적인 방법은 데이터를 마이그레이션하는 가장 효율적인 방법에 대한 이 섹션의 권장 사항을 참조하십시오.

AWS Database Migration Service 마이그레이션 계획

를 사용하여 데이터베이스 마이그레이션을 계획하는 경우AWS Database Migration Service, 다음을 고려하세요.

  • 소스 및 대상 데이터베이스를 다음 데이터베이스에 연결하려면AWS DMS복제 인스턴스, 네트워크를 구성합니다. 이 작업은 두 개를 연결하는 것만큼 간단할 수 있습니다.AWS복제 인스턴스와 동일한 Virtual Private Cloud (VPC) 내 리소스 가상 사설망 (VPN) 을 통해 온프레미스 데이터베이스를 Amazon RDS DB 인스턴스에 연결하는 등 더 복잡한 구성까지 다양할 수 있습니다. 자세한 내용은 데이터베이스 마이그레이션을 위한 네트워크 구성을 참조하세요.

  • 소스 및 대상 엔드포인트— 대상 데이터베이스로 마이그레이션해야 하는 소스 데이터베이스의 정보 및 테이블을 알고 있어야 합니다.AWS DMS테이블 및 기본 키 생성을 비롯한 기본 스키마 마이그레이션을 지원합니다. 그러나,AWS DMS대상 데이터베이스에 보조 인덱스, 외래 키, 사용자 계정 등을 자동으로 생성하지 않습니다. 원본 및 대상 데이터베이스 엔진에 따라 추가 로깅을 설정하거나 원본 또는 대상 데이터베이스의 기타 설정을 수정해야 할 수 있습니다. 자세한 내용은 데이터 마이그레이션용 소스대상 마이그레이션에 적합한 대상 섹션을 참조하세요.

  • 스키마 및 코드 마이그레이션–AWS DMS스키마나 코드 변환을 수행하지 않습니다. 오라클 SQL 개발자, MySQL 워크벤치 및 PGAdmin III와 같은 도구를 사용하여 스키마를 변환할 수 있습니다. 기존 스키마를 다른 데이터베이스 엔진으로 변환하려면 을 사용하여AWS Schema Conversion Tool(AWS SCT). 대상 스키마를 만들고 테이블, 인덱스, 뷰 등 전체 스키마를 생성하고 생성할 수 있습니다. 또한 이 도구를 사용하여 PL/SQL 또는 TSQL을 PGSQL 및 기타 형식으로 변환할 수 있습니다. 에 대한 자세한 내용은AWS SCT단원을 참조하십시오.AWS SCT사용 설명서.

  • 지원되지 않는 데이터 유형— 소스 데이터 형식을 대상 데이터베이스의 해당 데이터 형식으로 변환할 수 있는지 확인합니다. 지원되는 데이터 유형에 대한 자세한 내용은 데이터 저장소의 소스 또는 대상 섹션을 참조하십시오.

  • 진단 지원 스크립트 결과— 마이그레이션을 계획할 때는 진단 지원 스크립트를 실행하는 것이 좋습니다. 이러한 스크립트의 결과를 통해 잠재적인 마이그레이션 실패에 대한 사전 정보를 찾을 수 있습니다.

    데이터베이스에 대한 지원 스크립트를 사용할 수 있는 경우 다음 섹션의 해당 스크립트 항목에 있는 링크를 사용하여 다운로드하십시오. 스크립트를 확인하고 검토한 후 로컬 환경의 스크립트 항목에 설명된 절차에 따라 스크립트를 실행할 수 있습니다. 스크립트 실행이 완료되면 결과를 검토할 수 있습니다. 문제 해결 노력의 첫 단계로 이러한 스크립트를 실행하는 것이 좋습니다. 결과는 다음과 함께 작업하는 동안 유용 할 수 있습니다.AWS Support팀. 자세한 내용은 진단 지원 스크립트 작업AWS DMS을 참조하세요.

  • 마이그레이션 수행— A마이그레이션데이터베이스 마이그레이션 작업의 지정된 구성 요소를 평가하여 마이그레이션 작업이 예상대로 실행되지 않도록 할 수 있는 문제를 식별하는 데 도움을 줍니다. 이 평가를 사용하면 새 작업이나 수정된 작업을 실행하기 전에 잠재적인 문제를 식별할 수 있습니다. 마이그레이션 전 평가 작업에 대한 자세한 내용은 을 참조하십시오.작업에 대한 사전 마이그레이션 평가 활성화 및 작업.

스키마 변환

AWS DMS에서는 스키마 또는 코드 변환을 수행하지 않습니다. 기존 스키마를 다른 데이터베이스 엔진으로 변환하려면 를 사용하여AWS SCT.AWS SCT소스 객체, 테이블, 인덱스, 뷰, 트리거 및 기타 시스템 객체를 대상 데이터 정의어 (DDL) 형식으로 변환합니다. 뿐만 아니라AWS SCTPL/SQL 또는 TSQL과 같은 대부분의 애플리케이션 코드를 동일한 대상 언어로 변환합니다.

당신은 얻을 수 있습니다AWS SCT에서 무료로 다운로드 할 수 있습니다.AWS. 에 대한 자세한 정보AWS SCT단원을 참조하십시오.AWS SCT사용 설명서.

소스 및 대상 엔드포인트가 동일한 데이터베이스 엔진에 있는 경우 Oracle SQL Developer, MySQL 워크벤치 또는 PgAdmin4를 눌러 스키마를 이동합니다.

검토AWS DMS공개 문서

다음 과정을 거치는 것이 좋습니다.AWS DMS첫 마이그레이션 전에 소스 및 대상 엔드포인트에 대한 공개 설명서 페이지 이 설명서는 마이그레이션을 시작하기 전에 마이그레이션의 전제 조건을 식별하고 현재 제한 사항을 이해하는 데 도움이 될 수 있습니다. 자세한 내용은 작업AWSDMS 엔드포인트을 참조하세요.

마이그레이션 중에 공개 문서를 참조하면 다음과 같은 문제를 해결하는 데 도움이 될 수 있습니다.AWS DMS. 설명서의 문제 해결 페이지는 두 가지를 모두 사용하여 일반적인 문제를 해결하는 데 도움이 될 수 있습니다.AWS DMS및 선택한 엔드포인트 데이터베이스 자세한 내용은 AWS Database Migration Service에서 마이그레이션 작업 문제 해결을 참조하세요.

개념 증명 수행

데이터베이스 마이그레이션의 초기 단계에서 환경 문제를 발견하는 데 도움이 되도록 간단한 테스트 마이그레이션을 실행하는 것이 좋습니다. 이렇게 하면 보다 현실적인 마이그레이션 일정을 설정하는 데도 도움이 될 수 있습니다. 또한 여부를 측정하기 위해 본격적인 테스트 마이그레이션을 실행해야 할 수도 있습니다.AWS DMS네트워크를 통해 데이터베이스의 처리량을 처리할 수 있습니다. 이 기간 동안에는 초기 전체 로드 및 지속적인 복제를 벤치마킹하고 최적화하는 것이 좋습니다. 이렇게 하면 네트워크 지연 시간을 파악하고 전반적인 성능을 측정하는 데 도움이 될 수 있습니다.

이제 다음을 포함하여 데이터 프로필과 데이터베이스 크기를 이해할 수 있습니다.

  • 대형, 중형, 소형 테이블 수는 몇 개입니까?

  • 방법AWS DMS데이터 유형 및 문자 집합 변환을 처리합니다.

  • 대형 객체 (LOB) 열이 있는 테이블의 수

  • 테스트 마이그레이션을 실행하는 데 걸리는 시간

AWS DMS 마이그레이션 성능 개선

의 성능에 영향을 주는 요인은 매우 많습니다.AWS DMS마이그레이션:

  • 소스에서의 리소스 가용성

  • 사용 가능한 네트워크 처리량.

  • 복제 서버의 리소스 용량입니다.

  • 대상의 인제스트 능력이 변합니다.

  • 소스 데이터의 유형 및 분포.

  • 마이그레이션할 객체 수

아래에 언급된 모범 사례 중 일부 또는 전체를 사용하여 성능을 개선할 수 있습니다. 이러한 방법 중 하나를 사용할 수 있는지 여부는 특정 사용 사례에 따라 다릅니다. 다음과 같은 몇 가지 제한 사항을 확인할 수 있습니다.

적절한 복제 서버 프로비저닝

AWS DMS는 Amazon EC2 인스턴스에서 실행되는 관리형 서비스입니다. 이 서비스는 원본 데이터베이스에 연결하고, 원본 데이터를 읽고, 대상 데이터베이스에서 사용할 데이터를 포맷하고, 대상 데이터베이스에 데이터를 로드합니다.

이 절차 대다수는 메모리에서 진행됩니다. 그렇지만, 대규모 트랜잭션은 디스크에서 일부 버퍼링이 필요할 수 있습니다. 캐시된 트랜잭션과 로그 파일도 디스크에 기록됩니다. 다음 섹션에서는 복제 서버를 선택할 때 고려할 사항을 확인할 수 있습니다.

CPU

AWS DMS이기종 마이그레이션을 위해 설계되었지만 동종 마이그레이션도 지원합니다. 동종 마이그레이션을 수행하려면 먼저 각 소스 데이터 유형을 해당 데이터 유형으로 변환해야 합니다.AWS DMS데이터 유형. 그런 다음 각각 변환AWS DMS대상 데이터 유형에 데이터를 입력합니다. 에서 각 데이터베이스 엔진에 대한 이러한 변환에 대한 참조를 찾을 수 있습니다.AWS DMS사용 설명서.

에 대한AWS DMS이러한 변환을 최적으로 수행하려면 변환이 발생할 때 CPU를 사용할 수 있어야 합니다. CPU에 과부하가 걸리고 CPU 리소스가 충분하지 않으면 마이그레이션 속도가 느려지고 다른 부작용이 발생할 수도 있습니다.

복제 인스턴스 클래스

소형 인스턴스 클래스 중에는 서비스를 테스트하거나 소규모 마이그레이션을 하기에 충분한 것이 있습니다. 마이그레이션에 많은 테이블이 포함되거나 여러 개의 동시 복제 작업을 실행하려는 경우 더 큰 인스턴스 중 하나를 사용하는 것이 좋습니다. 서비스가 상당한 양의 메모리와 CPU를 소비하므로 더 큰 인스턴스를 사용하는 것이 좋습니다.

T2 유형 인스턴스는 중간 정도의 기본 성능을 발휘하면서 워크로드의 필요에 따라 성능을 크게 높이는 버스트 기능을 제공하도록 설계되었습니다. 이러한 인스턴스는 CPU의 최대 성능을 자주 또는 일관적으로 사용하지 않지만 가끔 순간적인 버스트가 필요한 워크로드에 적합합니다. T2 인스턴스는 웹 서버, 개발자 환경, 소규모 데이터베이스와 같은 범용 워크로드에 적합합니다. 마이그레이션 속도가 느린 문제를 해결하고 T2 인스턴스 유형을 사용하는 경우 CPU 사용률 호스트 지표를 확인하세요. 해당 인스턴스 유형의 기준선을 초과했는지 여부를 확인할 수 있습니다.

C4 인스턴스 클래스는 컴퓨터 집약적인 워크로드에 최고 수준의 프로세서 성능을 제공하도록 설계되었습니다. PPS (Packet Per Second) 성능을 크게 높이고 네트워크 지터 및 네트워크 지연 시간을 낮춥니다.AWS DMS특히 Oracle에서 PostgreSQL로 마이그레이션하는 것과 같은 이기종 마이그레이션 및 복제를 수행하는 경우 CPU를 많이 사용할 수 있습니다. C4 인스턴스는 이러한 상황에서 훌륭한 선택이 될 수 있습니다.

R4 인스턴스 클래스는 메모리 집약적 워크로드에 최적화된 메모리입니다. 다음을 사용하여 처리량이 많은 트랜잭션 시스템의 지속적인 마이그레이션 또는 복제AWS DMS때때로 대량의 CPU와 메모리를 사용할 수 있습니다. R4 인스턴스에는 vCPU당 더 많은 메모리가 포함되어 있습니다.

AWS DMSR5 및 C5 인스턴스 클래스 지원

R5 인스턴스 클래스는 메모리에서 대규모 데이터를 처리하는 워크로드에 대해 빠른 성능을 제공하도록 설계된 메모리 최적화 인스턴스입니다. 다음을 사용하여 처리량이 많은 트랜잭션 시스템의 지속적인 마이그레이션 또는 복제AWS DMS때때로 대량의 CPU와 메모리를 사용할 수 있습니다. R5 인스턴스는 R4에 비해 vCPU당 5% 의 추가 메모리를 제공하며, 가장 큰 크기는 768GiB의 메모리를 제공합니다. 또한 R5 인스턴스는 R4에 비해 GiB당 10% 향상된 가격과 약 20% 향상된 CPU 성능을 제공합니다.

C5 인스턴스 클래스는 컴퓨팅 집약적 워크로드에 최적화되어 있으며 컴퓨팅 비율당 저렴한 가격으로 비용 효율적인 고성능을 제공합니다. 이를 통해 네트워크 성능이 크게 향상됩니다. 엘라스틱 네트워크 어댑터 (ENA) 는 C5 인스턴스에 최대 25Gbps의 네트워크 대역폭과 최대 14Gbps의 전용 대역폭을 Amazon EBS에 제공합니다.AWS DMS특히 Oracle에서 PostgreSQL로 마이그레이션하는 것과 같은 이기종 마이그레이션 및 복제를 수행하는 경우 CPU를 많이 사용할 수 있습니다. 이러한 상황에서는 C5 인스턴스를 선택하는 것이 좋습니다.

스토리지

인스턴스 클래스에 따라 복제 서버에는 50GB 또는 100GB의 데이터 스토리지가 제공됩니다. 이 스토리지는 로그 파일 및 로드 중에 수집된 모든 캐시된 변경 사항에 사용됩니다. 소스 시스템이 사용 중이거나 트랜잭션이 많은 경우 스토리지를 늘려야 할 수 있습니다. 복제 서버에서 여러 작업을 실행하는 경우 스토리지 증가가 필요할 수도 있습니다. 그러나 일반적으로 기본 금액이면 충분합니다.

의 모든 스토리지 볼륨AWS DMS는 GP2 또는 범용 SSD (Solid-State Drive) 입니다. GP2 볼륨은 초당 세 번의 I/O 작업 (IOPS) 이라는 기본 성능을 제공하며 크레딧 기준으로 최대 3,000 IOPS까지 버스트할 수 있습니다. 경험상 다음 사항을 확인하십시오.ReadIOPSWriteIOPS복제 인스턴스에 사용되는 지표 이 값들의 합이 해당 볼륨의 기본 성능을 넘지 않는지 확인하십시오.

다중 AZ

다중 AZ 인스턴스를 선택하면 스토리지 장애로부터 마이그레이션을 보호할 수 있습니다. 대부분의 마이그레이션은 일시적이며 장기간 실행되지 않습니다. 사용하는 도구AWS DMS지속적인 복제를 위해 다중 AZ 인스턴스를 선택하면 스토리지 문제가 발생할 경우 가용성을 높일 수 있습니다.

FULL LOAD 중에 단일 AZ 또는 다중 AZ 복제 인스턴스를 사용하고 장애 조치 또는 호스트 교체가 발생하면 전체 로드 작업이 실패할 것으로 예상됩니다. 완료되지 않았거나 오류 상태인 나머지 테이블에 대해 실패 시점부터 작업을 다시 시작할 수 있습니다.

여러 테이블을 병렬로 로드

기본적으로,AWS DMS한 번에 8개의 테이블을 로드합니다. dms.c4.xlarge 이상의 인스턴스와 같은 대규모 복제 서버를 사용하는 경우 이 값을 약간 늘리면 성능이 약간 향상될 수 있습니다. 그러나 어느 시점에서는 이러한 병렬 처리를 늘리면 성능이 저하됩니다. 복제 서버가 dms.t2.medium과 같이 비교적 작은 경우 병렬로 로드되는 테이블 수를 줄이는 것이 좋습니다.

이 번호를 변경하려면AWS Management Console, 콘솔을 열고 선택하십시오작업, 작업 생성 또는 수정을 선택한 다음 선택고급 설정. 아래에튜닝 설정, 변경병렬로 로드할 수 있는 최대 테이블 수옵션.

를 사용하여 이 번호를 변경하려면AWS CLI, 변경MaxFullLoadSubTasks아래의 매개 변수TaskSettings.

parallel 풀로드 사용

파티션과 하위 파티션을 기반으로 오라클, 마이크로소프트 SQL 서버, MySQL, 사이베이스 및 IBM Db2 LUW 소스의 parallel 로드를 사용할 수 있습니다. 이렇게 하면 전체적인 전체 로드 시간을 개선할 수 있습니다. 또한, 실행하는 동안AWS DMS마이그레이션 작업을 사용하면 크거나 분할된 테이블의 마이그레이션을 가속화할 수 있습니다. 이렇게 하려면 테이블을 세그먼트로 분할하고 동일한 마이그레이션 작업에서 세그먼트를 병렬로 로드합니다.

parallel 부하를 사용하려면 다음과 같은 유형의 테이블 매핑 규칙을 생성하십시오.table-settings와 함께parallel-load옵션. 내에서table-settings규칙, 병렬로 로드하려는 테이블 또는 테이블의 선택 기준을 지정하십시오. 선택 기준을 지정하려면type의 요소parallel-load다음 설정 중 하나로

  • partitions-auto

  • subpartitions-auto

  • partitions-list

  • ranges

  • none

이러한 설정에 대한 자세한 내용은 단원을 참조하십시오.테이블 및 컬렉션 설정 규칙 및 작업.

인덱스, 트리거 및 참조 무결성 제약 조건 사용

인덱스, 트리거 및 참조 무결성 제약 조건은 마이그레이션 성능에 영향을 미치고 마이그레이션이 실패할 수 있습니다. 이들이 마이그레이션에 미치는 영향은 복제 작업이 전체 로드 작업인지 아니면 지속적인 복제 (변경 데이터 캡처 또는 CDC) 작업인지에 따라 달라집니다.

전체 로드 작업의 경우 기본 키 인덱스, 보조 인덱스, 참조 무결성 제약 조건 및 DML (데이터 조작 언어) 트리거를 삭제하는 것이 좋습니다. 또는 전체 로드 작업이 완료될 때까지 생성을 연기할 수 있습니다. 전체 로드 작업 중에는 인덱스가 필요하지 않으며 인덱스가 있는 경우 유지 관리 오버헤드가 발생합니다. 전체 로드 작업은 테이블 그룹을 한 번에 로드하므로 참조 무결성 제약 조건을 위반합니다. 마찬가지로 삽입, 업데이트 및 삭제 트리거는 오류를 일으킬 수 있습니다 (예: 이전에 대량으로 로드한 테이블에 대해 행 삽입이 트리거되는 경우). 다른 유형의 트리거도 추가 처리로 인해 성능에 영향을 미칩니다.

데이터 볼륨이 비교적 적고 추가 마이그레이션 시간이 문제가 되지 않는 경우 전체 로드 작업 전에 기본 키 및 보조 인덱스를 만들 수 있습니다. 참조 무결성 제약 조건 및 트리거는 항상 끄십시오.

전체 로드 및 CDC 작업의 경우 CDC 단계 전에 보조 색인을 추가하는 것이 좋습니다. 왜냐하면AWS DMS논리적 복제를 사용합니다. 전체 테이블 스캔을 방지하기 위해 DML 작업을 지원하는 보조 인덱스가 있어야 합니다. CDC 단계 전에 복제 작업을 일시 중지하여 작업을 다시 시작하기 전에 색인을 작성하고 참조 무결성 제약을 생성할 수 있습니다.

컷오버 바로 전에 트리거를 활성화해야 합니다.

백업 및 트랜잭션 로깅 해제

Amazon RDS 데이터베이스로 마이그레이션할 때는 전환할 준비가 될 때까지 타겟에서 백업과 다중 AZ를 끄는 것이 좋습니다. 마찬가지로 Amazon RDS가 아닌 다른 시스템으로 마이그레이션할 때는 대체로 전환이 끝날 때까지 대상에 대한 모든 로깅을 끄는 것이 좋습니다.

다수의 작업 사용

때로는 단일 마이그레이션에 여러 작업을 사용하면 성능이 향상될 수 있습니다. 일반적인 트랜잭션에 참여하지 않는 테이블 집합이 있는 경우 마이그레이션을 여러 작업으로 나눌 수 있습니다. 트랜잭션 일관성은 작업 내에서 유지되므로 개별 작업의 테이블이 공통 트랜잭션에 참여하지 않는 것이 중요합니다. 또한 각 태스크는 트랜잭션 스트림을 독립적으로 읽으므로 소스 데이터베이스에 너무 많은 stress 주지 않도록 주의하세요.

여러 작업을 사용하여 별도의 복제 스트림을 생성할 수 있습니다. 이렇게 하면 소스의 읽기, 복제 인스턴스의 프로세스 및 대상 데이터베이스에 대한 쓰기를 병렬화할 수 있습니다.

변경 처리 최적화

기본적으로,AWS DMS트랜잭션 모드에서 변경 사항을 처리하여 트랜잭션 무결성을 보존합니다. 트랜잭션 무결성이 일시적으로 저하될 수 있는 경우 배치 최적화 적용 옵션을 대신 사용할 수 있습니다. 이 옵션은 효율적으로 트랜잭션을 그룹화하고 효율성을 위해 일괄적으로 적용합니다. 배치 최적화 적용 옵션을 사용하면 거의 항상 참조 무결성 제약 조건을 위반할 수 있습니다. 따라서 마이그레이션 프로세스 중에 이러한 제약 조건을 끄고 전환 프로세스의 일부로 다시 설정하는 것이 좋습니다.

자체 온프레미스 이름 서버 사용

보통,AWS DMS복제 인스턴스는 Amazon EC2 인스턴스의 DNS (도메인 이름 시스템) 확인자를 사용하여 도메인 엔드포인트를 확인합니다. 하지만 Amazon Route 53 리졸버를 사용하는 경우 자체 온프레미스 이름 서버를 사용하여 특정 엔드포인트를 해결할 수 있습니다. 이 도구를 사용하면 온프레미스와 온프레미스 간에 쿼리할 수AWS인바운드 및 아웃바운드 엔드포인트, 전달 규칙 및 프라이빗 연결을 사용합니다. 온-프레미스 네임 서버를 사용할 때의 이점에는 향상된 보안 및 방화벽 사용 편의성이 포함됩니다.

인바운드 엔드포인트가 있는 경우 온프레미스에서 시작되는 DNS 쿼리를 사용하여 해결할 수 있습니다.AWS-호스팅 도메인. 엔드포인트를 구성하려면 리졸버에 제공하려는 각 서브넷에 IP 주소를 할당합니다. 온프레미스 DNS 인프라와 간의 연결을 설정하려면AWS, 사용AWS Direct Connect또는 가상 사설망 (VPN).

아웃바운드 엔드포인트는 온프레미스 이름 서버에 연결됩니다. 네임 서버는 허용 목록에 포함되고 아웃바운드 엔드포인트에 설정된 IP 주소에만 액세스 권한을 부여합니다. 이름 서버의 IP 주소는 대상 IP 주소입니다. 아웃바운드 엔드포인트의 보안 그룹을 선택할 때는 복제 인스턴스에서 사용하는 것과 동일한 보안 그룹을 선택합니다.

선택한 도메인을 네임 서버에 전달하려면 전달 규칙을 사용하십시오. 아웃바운드 엔드포인트는 여러 전달 규칙을 처리할 수 있습니다. 전달 규칙의 범위는 Virtual Private Cloud (VPC) 입니다. VPC와 연결된 전달 규칙을 사용하면 논리적으로 격리된 VPC 섹션을 프로비저닝할 수 있습니다.AWS클라우드 논리적으로 격리된 이 섹션에서 다음을 시작할 수 있습니다.AWS가상 네트워크의 리소스

온프레미스 DNS 인프라 내에서 호스팅되는 도메인을 아웃바운드 DNS 쿼리를 설정하는 조건부 전달 규칙으로 구성할 수 있습니다. 이러한 도메인 중 하나를 쿼리하면 규칙이 구성된 서버에 DNS 요청을 전달하려는 시도가 규칙이 트리거됩니다. 다시 말하지만, 비공개 연결이 끊어졌습니다.AWS Direct Connect또는 VPN이 필요합니다.

다음 다이어그램은 Route 53 Resolver 아키텍처를 나타냅니다.


                Route 53 해석기 아키텍처

Route 53 DNS Resolver에 대한 자세한 내용은 섹션을 참조하세요.Route 53 Resolver 시작하기에서Amazon Route 53 개발자 가이드.

에서 Amazon Route 53 Resolver 사용AWS DMS

에 대한 온프레미스 네임 서버를 만들 수 있습니다.AWS DMS다음을 사용하여 엔드포인트를 해결하려면Amazon Route 53 Resolver.

에 대한 온프레미스 이름 서버를 만들려면AWS DMSRoute 53

  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/route53/에서 Route 53 콘솔을 엽니다.

  2. Route 53 콘솔에서AWSRoute 53 Resolver를 구성하려는 리전입니다. Route 53 리졸버는 특정 지역에만 적용됩니다.

  3. 쿼리 방향 (인바운드, 아웃바운드 또는 둘 다) 을 선택합니다.

  4. 인바운드 쿼리 구성을 입력합니다.

    1. 엔드포인트 이름을 입력하고 VPC 선택합니다.

    2. VPC 내에서 하나 이상의 서브넷을 할당합니다(예: 가용성을 위해 2개 선택).

    3. 엔드포인트로 사용할 특정 IP 주소를 할당하거나 Route 53 Resolver에서 자동으로 할당하도록 합니다.

  5. VPC 내부의 워크로드가 DNS 쿼리를 DNS 인프라로 라우팅할 수 있도록 온프레미스 도메인에 대한 규칙을 생성합니다.

  6. 온프레미스 DNS 서버의 IP 주소를 하나 이상 입력합니다.

  7. 규칙을 제출하세요.

모든 것이 생성되면 VPC가 인바운드 및 아웃바운드 규칙과 연결되어 트래픽 라우팅을 시작할 수 있습니다.

Route 53 Resolver에 대한 자세한 내용은 섹션을 참조하세요.Route 53 Resolver 시작하기에서Amazon Route 53 개발자 가이드.

대용량 이진 객체(LOB) 마이그레이션

일반적으로,AWS DMSLOB 데이터를 두 단계로 마이그레이션합니다.

  1. AWS DMS대상 테이블에 새 행을 생성하고 관련 LOB 값을 제외한 모든 데이터로 행을 채웁니다.

  2. AWS DMS대상 테이블의 행을 LOB 데이터로 업데이트합니다.

LOB에 대한 이 마이그레이션 프로세스를 수행하려면 마이그레이션 중에 대상 테이블의 모든 LOB 열이 Null이 가능해야 합니다. 원본 테이블에서 LOB 열에 NULL을 지정할 수 없는 경우에도 마찬가지입니다. 만약AWS DMS대상 테이블을 생성하며 LOB 열을 기본적으로 null로 설정합니다. 경우에 따라 가져오기 또는 내보내기와 같은 다른 메커니즘을 사용하여 대상 테이블을 만들 수 있습니다. 이러한 경우에는 마이그레이션 작업을 시작하기 전에 LOB 열에 Null이 가능한지 확인하십시오.

이 요구 사항은 한 가지 예외가 있습니다. Oracle 소스에서 Oracle 타겟으로 동종 마이그레이션을 수행한다고 가정하고 다음 옵션을 선택합니다.리전. 이 경우 모든 LOB 값을 포함하여 전체 행이 한 번에 채워집니다. 그런 경우에는AWS DMS필요한 경우 Null이 불가능한 제약 조건이 있는 대상 테이블 LOB 열을 생성할 수 있습니다.

제한적 LOB 모드 사용

AWS DMS는 마이그레이션에 LOB 값이 포함된 경우 성능과 편의성의 균형을 유지하는 두 가지 방법을 사용합니다.

  1. 리전 모드모든 LOB 값을 사용자가 지정한 크기 제한 (기본값 32KB) 까지 마이그레이션합니다. 크기 제한보다 큰 LOB 값은 수동으로 마이그레이션해야 합니다. 리전 모드모든 마이그레이션 작업의 기본값이며 일반적으로 최상의 성능을 제공합니다. 그러나최대 LOB 크기파라미터 설정이 올바릅니다. 이 매개변수를 모든 테이블의 최대 LOB 크기로 설정합니다.

  2. 전체 LOB 모드크기와 관계없이 테이블의 모든 LOB 데이터를 마이그레이션합니다. 전체 LOB 모드테이블의 모든 LOB 데이터를 편리하게 이동할 수 있지만 이 프로세스는 성능에 큰 영향을 미칠 수 있습니다.

PostgreSQL과 같은 일부 데이터베이스 엔진의 경우AWS DMS는 JSON 데이터 유형을 LOB와 같이 취급합니다. 선택했다면리전 모드, 그최대 LOB 크기옵션이 JSON 데이터가 잘리지 않는 값으로 설정되었습니다.

AWS DMS대용량 객체 데이터 유형 (BLOB, CLOB 및 NCLOB) 사용을 완벽하게 지원합니다. 다음 소스 엔드포인트는 전체 LOB를 지원합니다.

  • Oracle

  • Microsoft SQL Server

  • ODBC

다음 대상 엔드포인트는 전체 LOB를 지원합니다.

  • Oracle

  • Microsoft SQL Server

다음 대상 엔드포인트는 LOB 지원이 제한적입니다. 이 대상 엔드포인트에는 LOB 크기를 무제한으로 사용할 수 없습니다.

  • Amazon Redshift

  • Amazon S3

전체 LOB를 지원하는 엔드포인트의 경우 LOB 데이터 유형에 대한 크기 제한을 설정할 수도 있습니다.

LOB 성능이 향상되었습니다.

LOB 데이터를 마이그레이션하는 동안 다음 다양한 LOB 최적화 설정을 지정할 수 있습니다.

테이블별 LOB 설정

테이블별 LOB 설정을 사용하여 일부 또는 모든 테이블에 대한 작업 수준 LOB 설정을 재정의할 수 있습니다. 이 작업을 수행하려면 를 정의해야 합니다.lob-settings당신의table-settings규칙입니다. 다음은 몇 가지 큰 LOB 값을 포함하는 예제 테이블입니다.

SET SERVEROUTPUT ON CREATE TABLE TEST_CLOB ( ID NUMBER, C1 CLOB, C2 VARCHAR2(4000) ); DECLARE bigtextstring CLOB := '123'; iINT; BEGIN WHILE Length(bigtextstring) <= 60000 LOOP bigtextstring := bigtextstring || '000000000000000000000000000000000'; END LOOP; INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue'); END; / SELECT * FROM TEST_CLOB; COMMIT

다음으로 마이그레이션 작업을 생성하고 새 작업을 사용하여 테이블의 LOB 처리를 수정합니다.lob-settings규칙입니다. 이bulk-max-siz값은 최대 LOB 크기 (KB) 를 결정합니다. 지정한 크기보다 크면 잘립니다.

{ "rules": [{ "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "HR", "table-name": "TEST_CLOB" }, "rule-action": "include" }, { "rule-type": "table-settings", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "HR", "table-name": "TEST_CLOB" }, "lob-settings": { "mode": "limited", "bulk-max-size": "16" } } ] }

이것 일지라도AWS DMS다음과 같이 작업이 생성됩니다.FullLobMode : true, 테이블별 LOB 설정 직접AWS DMS이 특정 테이블의 LOB 데이터를 16,000으로 자를 수 있습니다. 작업 로그를 확인하여 이를 확인할 수 있습니다.

721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table 'HR.TEST_CLOB' was truncated to length 16384

인라인 LOB 설정

를 생성하는 경우AWS DMS작업, LOB 모드는 LOB 처리 방법을 결정합니다.

풀 LOB 모드와 제한된 LOB 모드에서는 각각 고유한 장점과 단점이 있습니다. 인라인 LOB 모드는 전체 LOB 모드와 제한된 LOB 모드의 장점을 모두 제공합니다.

소형 및 대형 LOB를 모두 복제해야 하고 대부분의 LOB가 작을 때 인라인 LOB 모드를 사용할 수 있습니다. 이 옵션을 선택하면 전체 로드 중에AWS DMS태스크는 소형 LOB를 인라인으로 전송하므로 더 효율적입니다. 이AWS DMS태스크는 원본 테이블에서 조회를 수행하여 큰 LOB를 전송합니다.

변경 처리 중에는 소스 테이블에서 조회를 수행하여 소규모 LOB와 대형 LOB 모두 복제됩니다.

인라인 LOB 모드를 사용하는 경우AWS DMStask는 모든 LOB 크기를 검사하여 인라인으로 전송할 LOB 크기를 결정합니다. 지정된 크기보다 큰 LOB는 전체 LOB 모드를 사용하여 복제됩니다. 따라서 대부분의 LOB가 지정된 설정보다 크다는 것을 알고 있는 경우에는 이 옵션을 사용하지 않는 것이 좋습니다. 대신 LOB 크기를 무제한으로 허용하십시오.

작업 설정의 속성을 사용하여 이 옵션을 구성합니다.InlineLobMaxSize, 다음과 같은 경우에만 사용할 수 있습니다.FullLobMode를 로 설정합니다.true. 의 기본값은 입니다.InlineLobMaxSize는 0이고 범위는 1 —102400 킬로바이트 (100메가바이트) 입니다.

예를 들면 다음을 사용할 수 있습니다.AWS DMS작업 설정 여기, 설정InlineLobMaxSize값이 5,000이면 5,000보다 작거나 같은 모든 LOB가 인라인으로 전송됩니다.

{ "TargetMetadata": { "TargetSchema": "", "SupportLobs": true, "FullLobMode": true, "LobChunkSize": 64, "LimitedSizeLobMode": false, "LobMaxSize": 32, "InlineLobMaxSize": 5, "LoadMaxFileSize": 0, "ParallelLoadThreads": 0, "ParallelLoadBufferSize":0, "BatchApplyEnabled": false, "TaskRecoveryTableEnabled": false}, . . . }

행 필터링을 사용하여 대형 테이블을 마이그레이션할 때 성능 향상

대형 테이블을 마이그레이션할 때 성능을 향상시키려면 마이그레이션을 둘 이상의 작업으로 나누십시오. 행 필터링을 사용하여 마이그레이션을 여러 작업으로 나누려면 키 또는 파티션 키를 사용합니다. 예를 들어 1~8,000,000 사이의 정수 기본 키 ID가 있는 경우 행 필터링을 사용하여 8개의 작업을 만들어 각각 1백만 개의 레코드를 마이그레이션할 수 있습니다.

콘솔에서 행 필터링을 적용하려면:

  1. AWS Management Console을 엽니다.

  2. 선택해작업를 통해 새 백업을 생성합니다.

  3. 를 선택하세요테이블 매핑탭 및 확장선택 규칙.

  4. 선택해새 선택 규칙 추가. 이제 두 값 사이에 작거나 같거나, 크거나 같거나, 같거나, 범위 조건이 있는 열 필터를 추가할 수 있습니다. 열 필터링에 대한 자세한 내용은 단원을 참조하십시오. 콘솔에서 테이블 선택 및 변환 규칙 지정.

날짜별로 파티션을 나눈 큰 테이블이 있는 경우 날짜를 기준으로 데이터를 마이그레이션할 수 있습니다. 예를 들어, 월별로 분할된 테이블이 있고 현재 월의 데이터만 업데이트된다고 가정합시다. 이 경우 각 정적 월별 파티션에 대해 전체 로드 작업을 생성하고 현재 업데이트된 파티션에 대한 전체 로드 및 CDC 작업을 생성할 수 있습니다.

테이블에 단일 열 기본 키 또는 고유 인덱스가 있는 경우AWS DMS태스크는 범위 유형의 parallel 하중을 사용하여 테이블을 분할하여 데이터를 병렬로 로드합니다. 자세한 내용은 테이블 및 컬렉션 설정 규칙 및 작업을 참조하세요.

지속적 복제

AWS DMS지속적인 데이터 복제를 제공하여 소스 및 대상 데이터베이스를 동기화된 상태로 유지합니다. 제한된 양의 데이터 정의 언어 (DDDL) 문만 복제합니다.AWS DMS는 인덱스, 사용자, 권한, 저장 프로시저, 테이블 데이터와 직접 관련되지 않은 기타 데이터베이스 변경 사항과 같은 항목을 전파하지 않습니다.

지속적인 복제를 사용하려는 경우다중 AZ옵션은 복제 인스턴스를 생성할 때 사용합니다. 선택하여다중 AZ를 통해 복제 인스턴스에 대한 고가용성 및 장애 조치 지원이 제공됩니다. 하지만 이 옵션은 성능에 영향을 줄 수 있으며 대상 시스템에 변경 사항을 적용하는 동안 복제 속도를 늦출 수 있습니다.

원본 또는 대상 데이터베이스를 업그레이드하기 전에 모든 데이터베이스를 중지하는 것이 좋습니다.AWS DMS이러한 데이터베이스에서 실행 중인 작업 업그레이드가 완료된 후 작업을 재개합니다.

복제를 진행하는 동안에는 소스 데이터베이스 시스템과 사용자 데이터베이스 시스템 간의 네트워크 대역폭을 식별하는 것이 중요합니다.AWS DMS복제 인스턴스입니다. 복제를 진행하는 동안 네트워크가 병목 현상을 일으키지 않는지 확인하십시오.

또한 소스 데이터베이스 시스템에서 시간당 변경 비율과 아카이브 로그 생성을 식별하는 것도 중요합니다. 이렇게 하면 복제를 진행하는 동안 얻을 수 있는 처리량을 이해하는 데 도움이 될 수 있습니다.

소스 데이터베이스의 로드 감소

AWS DMS는 소스 데이터베이스의 일부 리소스를 사용합니다. 전체 로드 작업 중에AWS DMS병렬로 처리된 각 테이블에 대해 원본 테이블의 전체 테이블 스캔을 수행합니다. 또한 마이그레이션 과정에서 생성하는 각 작업은 CDC 프로세스의 일환으로 변경 출처를 쿼리합니다. 에 대한AWS DMS오라클과 같은 일부 출처에 대해 CDC를 수행하려면 데이터베이스의 변경 로그에 기록되는 데이터의 양을 늘려야 할 수 있습니다.

원본 데이터베이스에 과부하가 걸린다면 마이그레이션에 필요한 각 작업의 작업 또는 테이블 수를 줄이세요. 각 작업마다 소스 변경 사항이 개별적으로 적용되므로 작업을 통합하면 변경 내용 캡처 워크로드를 줄일 수 있습니다.

대상 데이터베이스의 병목 현상 감소

마이그레이션하는 동안 대상 데이터베이스에서 쓰기 리소스를 놓고 경쟁하는 프로세스를 모두 제거해 보십시오.

  • 불필요한 트리거를 끕니다.

  • 초기 로드 중에는 보조 인덱스를 끄고 나중에 복제가 진행되는 동안 보조 인덱스를 다시 켜십시오.

  • Amazon RDS 데이터베이스의 경우 전환될 때까지 백업과 다중 AZ를 끄는 것이 좋습니다.

  • 비 RDS 시스템으로 마이그레이션할 때는 전환될 때까지 타겟에 대한 모든 로깅을 해제하는 것이 좋습니다.

마이그레이션 중 데이터 검증 사용

데이터가 원본에서 타겟으로 정확하게 마이그레이션되었는지 확인하려면 데이터 검증을 사용하는 것이 좋습니다. 작업에 대해 데이터 검증을 켜는 경우AWS DMS테이블에 대해 전체 로드가 수행된 후 즉시 소스 및 대상 데이터 비교를 시작합니다.

데이터 검증은 AWS DMS가 소스 및 대상 엔드포인트로서 다음 데이터베이스를 지원할 때마다 해당 데이터베이스와 연동합니다.

  • Oracle

  • PostgreSQL

  • MySQL

  • MariaDB

  • Microsoft SQL Server

  • Amazon Aurora MySQL-Compatible Edition

  • Amazon Aurora PostgreSQL-Compatible Edition

  • IBM Db2 LUW

자세한 내용은 AWSDMS 데이터 유효성 검사을 참조하세요.

모니터링AWS DMS지표를 사용하는 작업

를 사용하여 작업의 지표를 모니터링할 수 있는 몇 가지 옵션이 있습니다.AWS DMS콘솔:

호스트 지표

호스트 지표는 에서 찾을 수 있습니다.CloudWatch 측정 항목각 특정 복제 인스턴스에 대한 탭 여기에서 복제 인스턴스의 크기가 적절한지 모니터링할 수 있습니다.

복제 작업 지표

수신 및 커밋된 변경 사항, 복제 호스트와 원본/대상 데이터베이스 간의 대기 시간을 포함한 복제 작업에 대한 메트릭은 다음에서 확인할 수 있습니다.CloudWatch 측정 항목각 특정 작업에 대한 탭

테이블 지표

에서 개별 테이블 지표를 찾을 수 있습니다.테이블 통계각 개별 작업에 대한 탭 이러한 지표에는 다음 수치가 포함됩니다.

  • 전체 로드 중에 로드된 행.

  • 작업이 시작된 이후에 삽입, 업데이트 및 삭제합니다.

  • 작업 시작 이후의 DDL 작업

지표 모니터링에 대한 자세한 내용은 단원을 참조하십시오.모니터링AWSDMS 작업.

이벤트 및 알림

AWS DMSAmazon SNS 사용하여 다음과 같은 경우 알림을 제공합니다.AWS DMS이벤트 발생 (예: 복제 인스턴스 생성 또는 삭제) 다음과 같은 경우 Amazon SNS SNS에서 지원하는 모든 형식으로 이러한 알림을 사용할 수 있습니다.AWS리전. 여기에는 이메일 메시지, 문자 메시지 또는 HTTP 엔드포인트로의 호출이 포함될 수 있습니다.

자세한 내용은 에서 Amazon SNS 이벤트 및 알림 다루기AWS Database Migration Service을 참조하세요.

마이그레이션 문제 해결을 위해 작업 로그 사용

어떤 경우에는 다음과 같습니다.AWS DMS경고 또는 오류 메시지가 작업 로그에만 나타나는 문제가 발생할 수 있습니다. 특히 외래 키 위반으로 인한 데이터 잘림 문제 또는 행 거부는 작업 로그에만 기록됩니다. 따라서 데이터베이스를 마이그레이션할 때는 작업 로그를 검토해야 합니다. 작업 로그를 보려면 Amazon을 구성하십시오. CloudWatch 작업 생성의 일환으로

자세한 내용을 알아보려면 다음 섹션을 참조하세요.Amazon을 사용한 복제 작업 모니터링 CloudWatch.

타임 트래블을 통한 복제 작업 문제 해결

문제 해결AWS DMS마이그레이션 문제가 있으면 Time Travel과 함께 작업할 수 있습니다. 시간 여행에 대한 자세한 내용은 단원을 참조하십시오.시간 이동 작업 설정.

Time Travel을 사용할 경우 다음 사항을 고려해야 합니다.

  • DMS 복제 인스턴스에서 오버헤드를 방지하려면 디버깅이 필요한 작업에 대해서만 Time Travel을 켜십시오.

  • Time Travel을 사용하여 며칠 동안 실행될 수 있는 복제 작업의 문제를 해결할 때는 복제 인스턴스 지표의 리소스 오버헤드를 모니터링하세요. 이 접근 방식은 소스 데이터베이스에서 오랜 기간 동안 높은 트랜잭션 로드가 실행되는 경우에 특히 적용됩니다. 자세한 내용은 모니터링AWSDMS 작업 단원을 참조하세요.

  • 시간 이동 태스크를 설정할 때EnableRawData를 로 설정합니다.trueDMS 복제 중 작업 메모리 사용량이 Time Travel이 켜져 있지 않을 때보다 많을 수 있습니다. 시간 여행을 장시간 켜는 경우 작업을 모니터링하세요.

  • 현재는 작업 수준에서만 시간 이동을 켤 수 있습니다. 모든 테이블에 대한 변경 사항은 Time Travel 로그에 기록됩니다. 트랜잭션 볼륨이 많은 데이터베이스의 특정 테이블에 대한 문제를 해결하려면 별도의 작업을 생성하십시오.

Oracle 대상의 사용자 및 스키마 변경

Oracle을 타겟으로 사용하는 경우AWS DMS대상 엔드포인트 사용자가 소유한 스키마로 데이터를 마이그레이션합니다.

예를 들면, 라는 스키마를 마이그레이션한다고 가정해 보십시오.PERFDATAOracle 대상 엔드포인트에 연결되며 대상 엔드포인트 사용자 이름은 다음과 같습니다.MASTER.AWS DMSOracle 타겟에 다음과 같이 접속MASTER을 (를) 채우고MASTER에서 데이터베이스 객체를 포함하는 스키마PERFDATA.

이 동작을 무시하려면 스키마 변환을 제공하십시오. 예를 들어, 마이그레이션하려면PERFDATA스키마 객체를 a로PERFDATA대상 엔드포인트의 스키마는 다음 변환을 사용합니다.

{ "rule-type": "transformation", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "PERFDATA" }, "rule-target": "schema", "rule-action": "rename", "value": "PERFDATA" }

변환에 대한 자세한 내용은 JSON을 사용하여 테이블 선택 및 변환 규칙 지정 섹션을 참조하십시오.

Oracle 대상의 테이블 및 인덱스 테이블스페이스 변경

오라클을 타겟으로 사용하는 경우AWS DMS모든 테이블과 인덱스를 대상의 기본 테이블스페이스로 마이그레이션합니다. 예를 들어 원본이 Oracle이 아닌 다른 데이터베이스 엔진이라고 가정해 보겠습니다. 모든 대상 테이블과 인덱스가 동일한 기본 테이블스페이스로 마이그레이션됩니다.

이 동작을 무시하려면 해당하는 테이블스페이스 변환을 제공하십시오. 예를 들어, 테이블과 인덱스를 원본의 스키마를 따라 이름이 지정된 Oracle 대상의 테이블 및 인덱스 테이블스페이스로 마이그레이션하려는 경우를 가정해 보겠습니다. 이 경우 다음과 유사한 변환을 사용할 수 있습니다. 여기서는 소스의 스키마 이름이 지정됩니다.INVENTORY대상의 해당 테이블 및 인덱스 테이블스페이스에 이름이 지정됩니다.INVENTORYTBLINVENTORYIDX.

{ "rule-type": "transformation", "rule-id": "3", "rule-name": "3", "rule-action": "rename", "rule-target": "table-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "table-tablespace-name": "%" }, "value": "INVENTORYTBL" }, { "rule-type": "transformation", "rule-id": "4 "rule-name": "4", "rule-action": "rename", "rule-target": "index-tablespace", "object-locator": { "schema-name": "INVENTORY", "table-name": "%", "index-tablespace-name": "%" }, "value": "INVENTORYIDX" }

변환에 대한 자세한 내용은 JSON을 사용하여 테이블 선택 및 변환 규칙 지정 섹션을 참조하십시오.

Oracle이 소스이자 대상인 경우 Oracle 소스 추가 연결 속성을 설정하여 기존 테이블 또는 인덱스 테이블스페이스 할당을 보존할 수 있습니다.enableHomogenousTablespace=true. 자세한 내용은 AWS DMS용에서 Oracle을 소스로 사용 시 추가 연결 속성을 참조하세요.

복제 인스턴스 버전 업그레이드

AWS정기적으로 새 버전을 출시합니다.AWS DMS새로운 기능과 향상된 성능을 갖춘 복제 엔진 소프트웨어 각 버전의 복제 엔진 소프트웨어에는 고유한 버전 번호가 있습니다. 기존 버전을 테스트하는 것이 중요합니다.AWS DMS복제 인스턴스를 최신 버전으로 업그레이드하기 전에 프로덕션 작업 로드를 실행하는 복제 인스턴스 사용 가능한 버전 업그레이드에 대한 자세한 내용은 단원을 참조하십시오.AWSDMS 릴리스 정보.

마이그레이션 비용 이해

AWS Database Migration Service데이터베이스를 마이그레이션하는 데 도움이 됩니다.AWS저렴한 비용으로 쉽고 안전하게. 복제 인스턴스와 추가 로그 스토리지에 대한 비용만 지불하면 됩니다. 각 데이터베이스 마이그레이션 인스턴스에는 대부분의 복제를 위한 스왑 공간, 복제 로그 및 데이터 캐시를 위한 충분한 스토리지가 포함되어 있으며 인바운드 데이터 전송은 무료입니다.

초기 로드 또는 피크 로드 시간에 더 많은 리소스가 필요할 수 있습니다. Cloud Watch 지표를 사용하여 복제 인스턴스 리소스 사용률을 면밀히 모니터링할 수 있습니다. 그런 다음 사용량에 따라 복제 인스턴스 크기를 확장 및 축소할 수 있습니다.

마이그레이션 비용 추정에 대한 자세한 내용은 다음을 참조하십시오.