AWS Database Migration Service
사용 설명서 (버전 API Version 2016-01-01)

AWS Database Migration Service 모범 사례

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

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

다음과 같은 다양한 요인이 AWS DMS 마이그레이션 성능에 영향을 줍니다.

  • 원본의 리소스 가용성

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

  • 복제 서버의 리소스 용량

  • 변경 사항을 수집하는 대상의 기능

  • 원본 데이터의 형식과 배포

  • 마이그레이션될 객체 수

테스트에서는 이상적인 조건 하에서 테라바이트의 데이터를 한 번의 AWS DMS 작업으로 약 12~13시간에 걸쳐 마이그레이션했습니다. 이 이상적인 조건에는 Amazon RDS의 대상 데이터베이스와 함께 Amazon EC2와 Amazon RDS에서 실행 중인 원본 데이터베이스 사용이 포함되어 있었습니다(모두 동일한 가용 영역). 원본 데이터베이스에는 최대 250GB의 데이터를 포함하는 대량 테이블 여러 개와 함께 비교적 고르게 배포된 데이터가 대표적인 수량으로 포함되었습니다. 원본 데이터에는 BLOB 같이 복잡한 데이터 유형이 포함되어 있지 않았습니다.

다음에 언급된 모범 사례 일부 또는 전부를 사용해 성능을 향상시킬 수 있습니다. 이 모범 사례 중 하나를 사용할 수 있을지 여부는 대체로 구체적인 사용 사례에 달려 있습니다. 적절한 제한 사항을 언급했습니다.

여러 테이블을 병렬로 로드

기본적으로 AWS DMS는 한 번에 테이블 8개를 로드합니다. dms.c4.xlarge 이상의 인스턴트와 같이 대용량 복제 서버를 사용할 때 이 개수를 약간 늘리면 성능이 개선될 수 있습니다. 그렇지만, 특정 지점에서 이 병렬 처리가 증가하면 성능이 감소합니다. dms.t2.medium과 같이 복제 서버가 비교적 작으면 병렬로 로드되는 테이블의 개수를 줄이는 것이 좋습니다.

AWS Management Console에서 이 개수를 변경하려면 콘솔을 열고 작업을 선택하여 작업을 생성할지, 아니면 수정할지 선택한 후 고급 설정을 선택합니다. 설정 조정에서 병렬로 로드할 최대 테이블 수 옵션을 변경합니다.

AWS CLI를 사용하여 이 개수를 변경하려면 TaskSettings에서 MaxFullLoadSubTasks 파라미터를 변경합니다.

인덱스, 트리거 및 참조 무결성 제약 관련 작업

인덱스, 트리거 및 참조 무결성 제약으로 인해 마이그레이션 성능이 영향을 받을 수 있고 마이그레이션이 실패할 수 있습니다. 마이그레이션에 얼마나 영향을 미치는가는 복제 작업이 전체 로드 작업인지 지속적인 복제(CDC) 작업인지에 따라 달라집니다.

전체 로드 작업인 경우 기본 키 인덱스, 보조 인덱스, 참조 무결성 제약, 데이터 조작 언어(DML) 트리거를 버리는 것이 좋습니다. 또는 전체 로드 작업이 완료될 때까지 이들의 생성을 지연시킬 수 있습니다. 전체 로드 작업 중에는 인덱스가 필요 없으며 인덱스가 있는 경우 인덱스에서는 유지 관리 오버헤드를 발생시킵니다. 전체 로드 작업은 한 번에 하나 씩 테이블 그룹을 로드하기 때문에 참조 무결성 제약에 위배됩니다. 이와 마찬가지로 앞서 대량 로드된 테이블에 대해 행 삽입이 트리거되는 경우와 같이 삽입, 업데이트, 삭제 트리거로 인해 오류가 생길 수 있습니다. 다른 유형의 트리거 역시 처리가 추가되면서 성능에 영향을 줄 수 있습니다.

데이터 볼륨이 비교적 적고 추가 마이그레이션 시간이 문제가 되지 않는다면 전체 로드 작업 전에 기본 키와 보조 인덱스를 빌드할 수 있습니다. 참조 무결성 제약과 트리거는 항상 비활성화 시켜야 합니다.

전체 로드와 CDC 작업에서는 CDC 단계 전에 보조 인덱스를 추가하는 것이 좋습니다. AWS DMS는 논리적 복제를 사용하기 때문에, DML 작업을 지원하는 보조 인덱스로 전체 테이블 스캔(검사)을 방지해야 합니다. CDC 단계 전에 복제 작업을 일시 중지한 후 인덱스를 빌드하고 트리거를 생성할 수 있고, 참조 무결성 제약을 생성한 후 작업을 다시 시작할 수 있습니다.

백업 및 트랜잭션 로깅 비활성화

Amazon RDS 데이터베이스로 마이그레이션하려면 전환 준비가 될 때까지 대상에서 백업과 다중 AZ를 비활성화하는 것이 좋습니다. 마찬가지로 비 Amazon RDS 시스템으로 마이그레이션할 때에는 전환이 일반적으로 권장될 때까지 대상에서 로깅 기능을 비활성화합니다.

여러 작업 사용

때로는 단일 마이그레이션에서 여러 작업을 사용하면 성능이 개선될 수 있습니다. 공통 트랜잭션에 참여하지 않는 여러 테이블 집합이 있는 경우, 마이그레이션을 여러 작업으로 나눌 수 있습니다. 하나의 작업 내에서 트랜잭션 일관성이 유지되므로, 별도의 작업에 있는 테이블은 공통 트랜잭션에 참여하지 않아야 합니다. 또한, 각 작업은 독립적으로 트랜잭션 스트림을 독립적으로 판독하므로, 소스 데이터베이스에 너무 많은 스트레스를 가하지 않도록 주의해야 합니다.

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

변경 처리 최적화

기본적으로 AWS DMS는 트랜잭션 모드에서 변경을 처리하므로, 트랜잭션의 무결성이 유지됩니다. 트랜잭션 무결성의 일시적인 시간 경과를 감당할 수 있는 경우, 대신 batch optimized apply 옵션을 사용할 수 있습니다. 이 옵션은 트랜잭션을 효율적으로 그룹화하고 효율성 목적으로 이 트랜잭션을 배치 단위로 적용합니다. 배치 최적화된 적용 옵션을 사용하면 거의 항상 참조 무결성 제약 조건을 위반하게 되므로 마이그레이션 프로세스 중에는 이 제약 조건을 비활성화한 후에 전환 프로세스의 일부로 다시 활성화해야 합니다.

복제 인스턴스에 최적인 크기 선택

사용 사례의 여러 요인에 따라 적절한 복제 인스턴스 선택이 달라집니다. 복제 인스턴스 리소스 사용 방식을 이해하는 데 도움을 받으려면 다음 설명을 참조하십시오. 이 설명에서는 전체 로드 및 CDC 작업의 가장 일반적인 시나리오를 다룹니다.

AWS DMS는 전체 로드 작업 동안 테이블을 개별적으로 로드합니다. 기본적으로 한 번에 테이블 8개가 로드됩니다. AWS DMS는 전체 로드 작업 동안 소스의 지속적 변경을 캡처, 나중에 대상 엔드포인트에 변경 사항을 적용합니다. 변경 사항은 메모리에 캐시됩니다. 그러나 가용 메모리를 다 사용하고 나면 디스크에 캐시합니다. 테이블에 대한 전체 로드 작업이 완료되면 AWS DMS는 캐시된 변경 사항을 즉시 대상 테이블에 적용합니다.

테이블에 대기 중인 캐시된 변경 사항이 모두 적용되고 나면 대상 엔드포인트는 트랜잭션에서 일관성 있는 상태가 됩니다. 이때 대상은 캐시된 최종 변경 사항과 관련해 소스 엔드포인트와 동기화됩니다. 그 다음에 AWS DMS는 원본과 대상 사이에 지속적 복제를 시작합니다. 이를 위해 AWS DMS는 소스 트랜잭션 로그에서 변경 작업을 가져오고 트랜잭션 측면에서 일관된 방식으로 이를 대상에 적용합니다(배치 최적화 적용을 선택하지 않았다고 가정). 가능한 경우 AWS DMS는 지속적 변경을 복제 인스턴스의 메모리를 통해 스트림합니다. 그렇지 않은 경우 AWS DMS는 변경 사항이 대상에 적용될 때까지 복제 인스턴스의 디스크에 변경 사항을 기록합니다.

복제 인스턴스가 변경 처리를 처리하는 방식과 이러한 프로세스에서 메모리가 사용되는 방식을 어느 정도 제어할 수 있습니다. 변경 처리 튜닝 방법에 대한 자세한 내용은 변경 처리 튜닝 설정를 참조하십시오.

앞의 설명에서 총 가용 메모리가 중요한 고려 사항인 것을 알 수 있습니다. AWS DMS가 캐시된 변경 사항과 지속적 변경 사항을 디스크에 기록하지 않고 스트림할 수 있을 정도로 복제 인스턴스의 메모리가 충분하면 마이그레이션 성능이 크게 향상됩니다. 이와 마찬가지로 변경 사항을 캐싱하고 로그를 저장할 수 있을 정도의 충분한 디스크 공간으로 복제 인스턴스를 구성해도 성능이 크게 향상됩니다. 선택한 디스크 크기에 따라 최대 IOPS가 달라집니다.

복제 인스턴스 클래스와 가용 디스크 스토리지를 선택할 때 다음 요인을 고려하십시오.

  • 테이블 크기 – 대형 테이블을 로드하는 데 더 오래 걸리므로 이러한 테이블의 트랜잭션은 테이블이 로드될 때까지 캐시되어야 합니다. 테이블이 로드되고 나면 이러한 캐시된 트랜잭션이 적용되어 더 이상 디스크에 유지되지 않습니다.

  • 데이터 조작 언어(DML) 활동 – 사용 중인 데이터베이스는 더 많은 트랜잭션을 생성합니다. 이 트랜잭션은 테이블이 로드될 때까지 캐시되어야 합니다. 개별 테이블에 대한 트랜잭션은 테이블이 로드된 후 최대한 빨리, 모든 테이블이 로드될 때까지 적용됩니다.

  • 트랜잭션 크기 – 장기 실행 트랜잭션으로 인해 변경 사항아 다수 생성될 수 있습니다. 최고 성능을 발휘하기 위해서는 AWS DMS가 트랜잭션 모드에서 변경을 적용하는 경우 트랜잭션의 모든 변경 사항을 스트림할 수 있을 만큼 충분한 메모리를 사용할 수 있어야 합니다.

  • 총 마이그레이션 크기 – 대용량 마이그레이션은 더 오래 걸리고, 여기에 비례하는 더 많은 수의 로그 파일을 생성합니다.

  • 작업 개수 – 작업 개수가 많아질수록 필요할 수 있는 캐시가 늘어나고 생성되는 로그 파일도 많아집니다.

  • 큰 객체 - LOB 테이블은 로드 시간이 더 깁니다.

입증되지 않은 증거에 따르면 로그 파일은 AWS DMS에서 필요한 대다수의 공간을 사용합니다. 기본 스토리지 구성은 대개 충분합니다.

그러나 여러 작업을 실행하는 복제 인스턴스는 더 많은 디스크 공간이 필요할 수 있습니다. 뿐만 아니라 데이터베이스에 대용량의 활성 테이블이 포함되어 있으면 전체 로드 작업 중에 디스크에 캐시되는 트랜잭션에 사용할 디스크 공간을 늘려야 할 수도 있습니다. 예를 들어 로드에 24시간이 걸리고 시간당 2GB의 트랜잭션을 생성한 경우 캐시된 트랜잭션에 48GB의 공간을 보장해야 할 수도 있습니다. 또한 복제 인스턴스에 할당하는 스토리지 공간이 많을 수록 IOPS가 높아집니다.

위 지침에서 가능한 시나리오를 모두 다루는 것은 아닙니다. 복제 인스턴스의 크기를 결정할 때 특정 사용 사례의 구체적인 내용을 고려하는 것이 매우 중요합니다. 마이그레이션을 실행한 후, CPU와 사용 가능한 메모리, 스토리지, 복제 인스턴스의 IOPS를 모니터링 하십시오. 사용자가 수집하는 데이터에 근거하여 필요에 따라 복제 인스턴스 크기를 확대 또는 축소할 수 있습니다.

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

AWS DMS는 원본 데이터베이스의 일부 리소스를 사용합니다. 전체 로드 작업 중에 AWS DMS는 병렬로 처리되는 각 테이블마다 소스 테이블의 모든 테이블을 스캔(검사)합니다. 또한 마이그레이션의 일부로 생성한 각 작업은 CDC 프로세스의 일부로 소스를 쿼리하여 변경 사항을 알아봅니다. AWS DMS가 Oracle과 같은 일부 원본에 대해 CDC를 수행할 수 있도록 하려면 데이터베이스 변경 로그에 작성된 데이터 양을 증가시켜야 할 수도 있습니다.

원본 데이터베이스에 과도한 부담을 주고 있다고 판단되면 마이그레이션할 작업 수 또는 마이그레이션 작업당 테이블 수를 줄일 수 있습니다. 각 작업에서 별도로 소스 변경 사항을 획득합니다. 즉 작업을 통합해 변경 캡처 워크로드를 감소시킬 수 있습니다.

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

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

스키마 변환

AWS DMS에서는 스키마 또는 코드 변환을 수행하지 않습니다. 기존 스키마를 다른 데이터베이스 엔진으로 변환할 경우, AWS Schema Conversion Tool(AWS SCT)을 사용할 수 있습니다. AWS SCT는 소스 객체, 테이블, 인덱스, 보기, 트리거, 기타 시스템 객체를 대상 데이터 정의 언어(DDL) 형식으로 변환합니다. 또한 AWS SCT를 사용하여 PL/SQL, TSQL 같은 대다수 애플리케이션 코드를 동등한 대상 언어로 변환할 수 있습니다.

AWS에서 AWS SCT를 무료로 다운로드할 수 있습니다. AWS SCT에 대한 자세한 내용은 AWS Schema Conversion Tool 사용 설명서를 참조하십시오.

소스와 대상 엔드포인트가 동일한 데이터베이스 엔진에 있는 경우 Oracle SQL Developer, MySQL Workbench, PgAdmin4와 같은 도구를 사용하여 스키마를 이동할 수 있습니다.

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

일반적으로 AWS DMS는 2 단계로 LOB 데이터를 마이그레이션합니다.

  1. AWS DMS는 대상 테이블에 새 행을 생성한 후 이 행을 연결된 LOB 값을 제외한 모든 데이터로 채웁니다.

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

LOB에 대해 이와 같은 마이그레이션 프로세스가 실행되려면 마이그레이션 중에 대상 테이블의 모든 LOB 열에 Null 값이 허용되어야 합니다. 이러한 요구 사항은 LOB 열이 원본 테이블에서 Null 값을 허용하지 않는다 해도 그대로 적용됩니다. AWS DMS가 대상 테이블을 생성하는 경우, 기본적으로 LOB 열에 Null 값을 허용하도록 설정합니다. 가져오기 또는 내보내기와 같은 다른 일부 메커니즘을 사용하여 대상 테이블을 생성하는 경우 마이그레이션 작업 시작 전에 LOB 열에 Null 값이 허용되어 있어야 합니다.

이런 요구 사항에는 한 가지 예외가 있습니다. Oracle 소스에서 Oracle 대상으로 동종 마이그레이션을 수행하고 제한적 LOB 모드를 선택한다고 가정합시다. 이 경우 LOB 값을 포함한 전체 행은 즉시 채워집니다. 그러면 AWS DMS는 필요한 경우 Null 허용에 대한 제약 없이 대상 테이블의 LOB 열을 생성할 수 있습니다.

제한적 LOB 모드 사용

AWS DMS는 마이그레이션에 LOB 값이 포함되어 있을 때 성능과 편의 사이에 균형을 맞추기 위해 2가지 방법을 사용합니다.

  • [Limited LOB mode]는 사용자가 지정한 크기 한도(기본값은 32KB) 모든 LOB 값을 마이그레이션 합니다. 크기 한도보다 큰 LOB 값은 수동으로 마이그레이션 해야 합니다. 모든 마이그레이션 작업의 기본값인 [Limited LOB mode]는 일반적으로 최고의 성능을 제공합니다. 그러나 Max LOB size 파라미터 설정이 올바른지 확인해야 합니다. 이 파라미터는 모든 테이블에서 가장 큰 LOB 크기에 설정되어야 합니다.

  • [Full LOB mode]는 크기와 상관 없이 테이블의 모든 LOB 데이터를 마이그레이션 합니다. [Full LOB mode]는 테이블의 모든 LOB 데이터를 이동시키기 때문에 편리합니다. 그러나 성능에 큰 영향을 줄 수도 있습니다.

PostgreSQL 같은 일부 데이터베이스 엔진의 경우, AWS DMS에서 JSON 데이터 형식을 LOB로 간주합니다. 제한적 LOB 모드를 선택한 경우 JSON 데이터가 잘리지 않는 값으로 Max LOB size 옵션이 설정되었는지 확인합니다.

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

  • Oracle

  • Microsoft SQL Server

  • ODBC

다음 대상 엔드포인트에는 전체 LOB 지원이 있습니다.

  • Oracle

  • Microsoft SQL Server

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

  • Amazon Redshift

전체 LOB 지원이 포함된 엔드포인트의 경우, LOB 데이터 형식에서 크기 한도를 설정할 수도 있습니다.

지속적 복제

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

지속적 복제를 사용할 계획이라면 복제 인스턴스를 생성할 때 다중 AZ 옵션을 활성화해야 합니다. 다중 AZ 옵션을 선택하면 복제 인스턴스에 대해 고가용성 및 장애 조치를 지원받을 수 있습니다. 그러나 이 옵션으로 인해 성능이 저하될 수 있습니다.

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

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

예를 들어 PERFDATA라고 하는 스키마를 Oracle 대상 엔드포인트로 마이그레이션하는 중이며, 대상 엔드포인트 사용자 이름이 MASTER라고 가정해봅니다. AWS DMS는 MASTER로서 Oracle 대상에 연결되고 PERFDATA의 데이터베이스 객체로 MASTER 스키마를 채웁니다.

이 동작을 재정의하려면 스키마 변환을 제공해야 합니다. 예를 들어 대상 엔드포인트에서 PERFDATA 스키마 객체를 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 대상에 대한 테이블 및 인덱스 테이블스페이스 변경

대상으로 Oracle을 사용할 경우 원본도 Oracle이면 AWS DMS는 원본에 정의된 대로 테이블스페이스를 마이그레이션합니다. 그러나 원본이 Oracle이 아닌 경우 AWS DMS는 모든 테이블 및 인덱스를 대상의 기본 테이블 및 인덱스 테이블스페이스로 마이그레이션합니다.

예를 들어 원본이 Orcle 이외의 데이터베이스 엔진이라고 가정해봅니다. 모든 대상 테이블 및 인덱스는 동일한 기본 테이블스페이스로 마이그레이션됩니다.

이 동작을 재정의하려면 해당하는 테이블스페이스 변환을 제공해야 합니다. 예를 들어 원본의 스키마를 따라 이름이 지정된 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을 사용하여 테이블 매핑을 통해 테이블 선택 및 변환 지정 섹션을 참조하십시오.

라지 테이블 마이그레이션 시 성능 향상

큰 테이블을 마이그레이션할 때 성능을 향상시키고 싶다면 마이그레이션을 하나 이상의 작업으로 나눌 수 있습니다. 행 필터링을 사용하여 마이그레이션을 여러 가지 작업으로 나누려면 키 또는 파티션 키를 사용하십시오. 예를 들어 1~8,000,000까지의 정수 기본 키 ID가 있다면 행 필터링을 사용하여 작업 8개를 생성해 매번 100만 개의 레코드를 마이그레이션할 수 있습니다.

AWS Management Console에서 행 필터링을 적용하려면 콘솔을 열어 작업을 선택하고 새 작업을 생성하십시오. 테이블 매핑 섹션에서 Selection Rule(섹션 규칙)에 값을 추가합니다. 그러면 작거나 같음, 크거나 같음, 같음, (두 값 사이의) 범위 조건 중 하나로 열 필터를 추가할 수 있습니다. 열 필터링에 대한 자세한 내용은 콘솔에서 테이블 매핑을 통해 테이블 선택 및 변환 지정를 참조하십시오.

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