AWS DMS ‘validation-only task’ 를 활용한 데이터 검증 최적화

이 글은 AWS Database Blog에 게시된Optimize data validation using AWS DMS validation-only tasks by Jay Shin, Barry Ooi, and Donghua Luo 을 한국어 번역 및 편집하였습니다.

AWS Database Migration Service(AWS DMS)는 데이터를 효율적이고 안전하게 Amazon Web Services(AWS)로 마이그레이션하는 데 도움이 됩니다. Oracle , SQL Server 와 같은 상용 데이터베이스부터 MySQL ,PostgreSQL과 같은 오픈 소스 데이터베이스까지 데이터를 마이그레이션할 수 있습니다. AWS DMS는 다양한 지원 소스로부터 AWS로 마이그레이션할 때 데이터를 검증하는 기능을 제공합니다. 데이터 무결성과 정확성은 고객으로부터 많이 요구되는 성공적인 마이그레이션 프로젝트를 위한 핵심 요구 사항 중 하나입니다. 이번 글을 통해 AWS DMS 데이터 검증(Data Validation) 기능을 자세히 알아보고 기능의 장점, 구성 , 사용 사례를 살펴보겠습니다.

AWS DMS Data Validation(데이터 검증)

AWS DMS Data Validation(데이터 검증) 은 데이터가 소스에서 타겟으로 정확하게 마이그레이션되었는지 확인하는 데 도움이 됩니다. AWS DMS 마이그레이션 작업에서 전체 로드(Full load) 전용(기존 데이터 마이그레이션) 마이그레이션 유형으로 마이그레이션을 통한 검증을 선택하면 전체 로드(full load)가 완료된 직후에 데이터 검증이 시작됩니다. 전체 로드(full load) + CDC (기존 데이터 마이그레이션 및 진행 중인 변경 사항 복제) 마이그레이션의 경우 Validation 은 전체 로드(Full load)가 완료된 직후에 검증이 시작됩니다. 그 다음 발생하는 변경 데이터 캡처(CDC)에 대한 증분 변경 사항을 계속 비교합니다. 검증이 활성화된 CDC 전용 작업의 경우 새 데이터의 검증이 시작되기 전에 테이블의 모든 기존 데이터가 검증됩니다. 데이터 검증 중에 AWS DMS는 소스의 각 행을 타겟의 해당 행과 비교하고 행에 동일한 데이터가 포함되어 있는지 확인하고 불일치 여부를 보고합니다. 컬럼의 값은 데이터 타입에 따라 다르게 비교합니다. 예를 들어 체크섬(checksum) 함수는 LOB(대형 바이너리 오브젝트) 컬럼을 비교하는 데 사용되는 반면 실제 값은 다른 데이터 타입이 사용됩니다. AWS DMS 콘솔이나 AWS 커맨드 라인 인터페이스(AWS CLI)를 사용하여 마이그레이션 작업에서 데이터 검증 기능을 활성화할 수 있습니다.

자세한 내용은 Migration Validation (Part 2) – Introducing Data Validation in AWS Database Migration Service 를 참고해 주십시오. 또한 마이그레이션이나 데이터 복제를 실제 수행하지 않고도 데이터 미리 보기와 검증만을 위한 검증 전용 작업을 만들 수 있습니다. 이 검증은 소스와 타겟에서 추가 리소스와 추가 네트워크 리소스가 소모되며 또한 소스와 타겟 테이블에는 Primary Key 또는 Unique Index 가 존재해야 합니다. AWS DMS Validation(검증) 을 사용하기 전에 이에 대한 제한 사항을 사전에 검토하는 것이 좋습니다.

솔루션 개요

이 글에서는 다음 주제를 다룹니다.

AWS DMS 검증 전용 작업의 사용 사례(관계형 데이터베이스)
AWS DMS 검증 전용 작업을 구성하고 모니터링하는 방법
데이터 검증 전용 작업:- 전체 로드(full load)와 CDC(지속적 복제) 비교
AWS DMS 검증 전용 작업을 최적화하는 방법
검증실패 사례를 처리할 수 있는 방법

AWS DMS 검증 전용 작업의 사용 사례(관계형 데이터베이스)

AWS DMS에서 검증 전용 작업을 활용한 일반적인 사용 사례들입니다.

마이그레이션을 실행하지 않고 데이터 검증 – 검증 전용 작업을 사용하면 데이터를 복제하지 않고도 소스와 타겟 간의 데이터를 검증할 수 있습니다. 이는 검증 규칙과 설정을 테스트하는 데 유용합니다.
마이그레이션 작업에서 검증을 분리 – 별도의 검증 전용 작업을 만들면 기존 마이그레이션 작업에 영향을 미치지 않고 독립적으로 데이터를 검증할 수 있습니다. 이렇게 하면 검증 실패로 인해 마이그레이션이 중단되는 것을 방지하고 별도의 복제 인스턴스(RI)에서 검증 전용 작업을 실행할 수 있습니다. 또한 이 별도의 복제 인스턴스(RI) 에서는 다른 DMS 버전을 가짐으로 새로운 기능을 활용할 수 있습니다.
검증 실패 문제 해결 – 마이그레이션 작업에서 검증이 실패하는 경우 검증 전용 작업을 통해 진행 중인 마이그레이션으로부터 분리하여 특정 실패를 조사하고 문제를 해결하기가 더 쉽습니다.
예약된 검증 – 검증 전용 작업을 예약하여 소스 및 타겟 데이터베이스에서 데이터가 변경될 때 데이터를 검증할 수 있습니다. 이를 통해 지속적인 실행 작업에 비해 소스 및 타겟 데이터베이스 인스턴스의 부하를 줄일 수 있습니다.
특정 시점에 일치하지 않는 데이터 행을 빠르게 확보 – 프로덕션을 Cut-off 하기 전이나 그 기간동안 전체 로드(Full load) 검증 전용 작업을 실행하여 애플리케이션이 새 타겟 엔드포인트를 가리키기 전에 미리 데이터를 검증할 수 있습니다.
데이터 복구 스크립트 – 검증 실패 테이블에서 읽어 들이는 데이터 복구 스크립트를 만든 경우 전체 로드(full-load) 검증 전용 작업에서 스크립트가 작동할 수 있도록 실패를 빠르게 보고 받을 수 있습니다.

AWS DMS 검증 전용 작업 구성과 모니터링 하는 방법

AWS DMS 콘솔을 사용하여 검증 전용 작업을 생성하려면 DMS Task 를 생성할 때 다음 설정을 지정합니다.

TargetTablePrepMode 는 DO_NOTHING (검증 전용 적업에서의 디폴트)
Migration Type 은 Migrate existing data 또는 Replicate data changes only
Data Validation 에는 Validation without data migration 선택

또는 다음의 Json Editor 를 이용해 Task Setting 을 수정할 수 있습니다.

"EnableValidation": true,

"ValidationOnly": true,

Data Validation 을 활성화할때 DMS 콘솔이나 Amazon CloudWatch 에서 Valdation 의 상태(state) 를 모니터링할 수 있습니다.

소스와 타겟 간에 테이블의 일부 레코드가 일치하지 않는 경우 Validation (검증) 상태는 Mismatched records 이며 타겟 데이터베이스의 awsdms_validation_failures_v1 테이블에서 세부 정보를 확인할 수 있습니다. 이 테이블은 ControlSchema에서 정의한 스키마 또는 데이터베이스 엔진의 디폴트 위치에 생성됩니다. 레코드가 ValidationSuspended 또는 ValidationFailed 상태가 되면 AWS DMS는 동일한 테이블에 진단 정보를 기록합니다.

다음 스크린샷은 PostgreSQL 예제(타겟)를 보여줍니다.

DMS Data Validation 모니터링의 상세한 내용은 Insights into AWS DMS resiliency and recovery scenarios with mitigations – Part 2 를 참고해주십시오.

전체 로드(Full load) 와 지속적인 복제(CDC) 검증 전용 마이그레이션 타입

언급된 것처럼 두 가지 유형의 마이그레이션 타입 즉 전체 로드(Full Load) 검증 전용 작업과 지속적인 복제(CDC) 검증 전용 작업으로 검증 전용 작업을 만들 수 있습니다. 이 두 유형의 데이터 검증 절차와 주요 튜닝 파라미터는 다음 섹션에서 설명 드리겠습니다.

전체 로드(Full load) 검증 전용(Validation Only)

AWS DMS 버전 3.4.6 이상부터 전체 로드(Full load) 검증 전용 작업은 소스와 타겟 테이블의 모든 로우 데이터를 빠르게 비교하고 지연 없이 검증 실패를 보고하고 검증이 완료된 후 작업을 중지합니다. DMS는 데이터를 논리적으로 파티션으로 나누고(디폴트 값은 파티션당 10,000개) 복수개의 데이터 검증(Validation) 스레드(디폴트 값은 5개)가 파티션 간에 데이터를 비교합니다.

모든 데이터 검증 오류는 타겟 데이터베이스의 컨트롤 테이블(awsdms_control.awsdms_validation_failures_v1)에 기록됩니다. 다음 다이어그램에서 불일치 레코드는 컬럼 coln의 데이터 Row n에 대한 불일치 값으로 인해 보고됩니다.

다음 테이블은 전체 로드(Full load) 검증 전용 작업에서 중요한 Task 설정 파라미터들에 대해서 나열되어 있습니다. AWS DMS 데이터 검증 작업에서 지원되는 전체 파라미터는 Data validation task settings 을 참조하십시오.

파라미터	디폴트 값	설명
PartitionSize	10,000	소스와 타겟 양쪽에서 비교를 위해서 읽어 들이는 레코드 개수를 지정
ThreadCount	5	AWS DMS 에서 검증 동안 실행 스레드의 개수를 지정
SkipLobColumns	FALSE	AWS DMS 가 “True” 로 설정되면 모든 LOB 컬럼의 검증을 생략 합니다.
ValidationPartialLobSize	0	AWS DMS는 디폴트로 모든 LOB 컬럼 데이터를 검증합니다. Limited LOB 모드에서는 절삭 되는 값을 지정합니다. 예를 들어 마이그레이션 작업 중에 최대 LOB 크기를 32KB로 설정한 경우 “ValidationPartialLobSize” 를 32로 설정합니다. 이렇게 하면 AWS DMS가 소스와 타겟 모두에서 컬럼 데이터의 처음 32KB까지만 검증합니다.

CDC 검증 전용(validation only)

CDC 검증 전용 작업이 시작된 후에는 기존 데이터를 먼저 검증한 다음 CDC에서 캡처 된 증분 된 변경 사항을 검증하고 불일치 사항을 보고합니다. 진행 중인 복제 변경 사항을 지속적으로 재 검증합니다. CDC 검증은 False Positive를 방지하기 위해 실패하기 전에 불일치 된 행에 대해 검증을 재 시도합니다. 재 시도를 기다리는 시간은 작업 설정에서 RecordFailureDelayLimitInMinutes 와 RecordSuspendDelayInMinutes파라미터에 설정된 실패 재시도 기간(분)에 따라 달라집니다. 다음 그림에서 T1 시점에서 AWS DMS 검증 스레드가 Row n에 대한 데이터 불일치를 발견했습니다. 실패를 즉시 보고하는 대신에 재 시도함으로써 진행 중인 데이터 복제 작업에서 문제가 해결될 수 있을 것으로 예상합니다.

다음 그림의 T2 시점에서 여전히 실패 재시도 시간 내에 속해 있으며 검증 스레드는 Row n에 대한 데이터를 다시 비교하여 데이터가 일치함을 확인하고 데이터 검증 실패를 보고하지 않습니다. 검증 작업에서 찾은 모든 새 데이터에 대해 DMS는 이를 파티션으로 나누고 데이터 검증 스레드를 할당하여 데이터를 검증합니다.

다음 표에서는 CDC 검증 전용 작업에 대한 중요한 Task 파라미터 리스트를 보여줍니다. 이는 이전의 전체 로드(Full Load) 검증 전용 작업에서 언급된 파라미터 외에 고려해야 합니다. 데이터 검증 작업에서 지원되는 전체 파라미터 설명은 Data validation task settings을 참고해주십시오.

파라미터	디폴트 설정	설명
Failure retry period	RecordFailureDelayInMinutes=0 RecordFailureDelayLimitInMinutes=0	검증 실패 세부 정보를 보고하기 전의 지연 시간을 분 단위로 지정합니다. 이 파라미터 값이 0보다 큰 경우 값은 RecordFailureDelayLimitInMinutes와 동일합니다. 그렇지 않은 경우 RecordFailureDelayInMinutes의 값에 실제 DMS CDC 작업 지연 시간이 가산됩니다. 데이터 검증 전용 작업에서는 CDC 작업 지연 시간 값의 디폴트 값은 0으로 산정됩니다.
Table level failure control	TableFailureMaxCount=1000	테이블에 대한 검증이 일시 중단(Suspend) 되기 전에 검증에 실패할 수 있는 하나의 테이블의 최대 행 수를 지정합니다.
Table level failure control	RecordSuspendDelayInMinutes=0	FailureMaxCount에 설정된 오류 임계값으로 인해 테이블의 검증이 중단되기 전의 지연 시간을 분 단위로 지정합니다.
Task Level Failure control	FailureMaxCount=10000	작업에 대한 검증이 일시 중단(Suspend)되기 전에 검증에 실패할 수 있는 최대 레코드 수를 지정합니다.

AWS DMS 검증 전용 작업을 최적화하는 방법

이 섹션에서는 AWS DMS 검증 전용 작업의 성능을 최적화할 수 있는 검증 작업 설정들에 대해서 설명하겠습니다. 이러한 설정은 운영 시스템에서 구현하기 전에 가능한 경우 개발 환경에서 테스트해볼 것을 권장 드립니다. 각 검증 작업은 고유하며 Task 레벨에서 미세한 조정이 필요합니다.

ThreadCount: 이 파라미터는 DMS가 데이터 검증을 수행할 때 사용하는 스레드 수를 지정합니다.디폴트 값은 5이며 각 스레드는 아직 검증되지 않은 데이터를 비교하고 검증합니다.숫자가 클수록검증 작업의 전반적인 성능이 향상될 수 있지만 스레드를 추가하면 소스와 타겟 인스턴스에서 추가 리소스를 필요로 합니다.
PartitionSize: 이 설정은 각 스레드가 소스와 타겟 인스턴스에서 읽는 레코드 수를 지정합니다.디폴트 값인 10,000에서 늘리면 DMS가 검증을 위해 더 많은 레코드를 읽을 수 있지만 마이그레이션 구성 요소의 추가 부하가 발생합니다.
RecordFailureDelayLimitInMinutes: 이 파라미터를 사용하면 DMS가 검증 실패를 보고하기 전 지연 시간을 지정할 수 있습니다.일반적으로 DMS는 작업 대기(Task Latency) 시간 값을 사용하여 데이터 변경 사항이 타겟에 복제되는 실제 지연 시간을 허용하여 False Positive 를 방지합니다.이 설정을 더 높은 값으로 정의할 수 있습니다.
ValidationQueryCdcDelaySeconds: 소스와 타겟에서 첫 번째 검증 쿼리가 지연되기 전의 시간을 설정합니다.검증 전용 작업의 경우 디폴트 값은 180초입니다.소스에서 많은 양의 업데이트로 인해 대기 시간이 길어지면 소스 인스턴스에서 경합을 줄이기 위해 이 값을 더 높은 값으로 설정할 수 있습니다.
FailureMaxCount: 이 설정은 작업이 일시 중지(Suspend)되기 전에 최대 검증 실패 횟수를 추적합니다.디폴트 값은 10,000입니다.검증에서 모든 레코드의 유효성을 계속 검사하려는 경우 이 값을 소스 테이블의 레코드 수보다 높게 설정합니다.반면 데이터 불일치를 허용할 수 없는 경우 오류가 발생할 때 작업이 빠르게 일시 중단(Suspend)되어 엄격한 데이터 무결성 검사가 수행되도록 더 낮은 값을 설정할 수 있습니다.
HandleCollationDiff: 이 옵션은 컬럼 정렬 차이가 처리되는 방식을 설정 합니다.기본적으로 값은 false이며 이는 컬럼 간의 정렬 차이를 무시하여 데이터 검증에서 False Positive으로 이어질 가능성이 있습니다.정렬은 레코드가 정렬되는 방식 그리고 비교 중에 데이터가 매치되는 방식을 결정하므로 데이터 검증의 중요한 요소입니다.예를 들어 다음은 ASCII 표현의 문자열 “abcABC”를 사용하는 경우 대소문자 구분 없는 정렬 순서와 대소문자 구분 있는 정렬 순서를 비교해서 보여줍니다.

ASCII 표현	대소문자 구분 없는 정렬 순서	대소문자 구분 정렬 순서
a = 01100001 b = 01100010 c = 01100011 A = 01000001 B = 01000010 C = 01000011	A = 01000001 a = 01100001 B = 01000010 b = 01100010 C = 01000011 c = 01100011	A = 01000001 B = 01000010 C = 01000011 a = 01100001 b = 01100010 c = 01100011
Result:	“AaBbCc”	“ABCabc”

검증 실패 사례를 처리할 수 있는 방법

이 섹션에서는 AWS DMS 검증 작업에서 보고되는 일반적인 데이터 검증 실패 시나리오와 이를 해결하는 방법을 살펴보겠습니다.

LOB 잘림

데이터베이스를 타겟 인스턴스로 마이그레이션할 때 AWS DMS는 마이그레이션 작업에서 구성된 경우 LOB 를 포함하여 데이터를 복제합니다. LOB 오브젝트에 대해 구성 가능한 설정이 몇 가지 있습니다. 디폴트로 DMS는 개별 LOB에 대해 최대 LOB 크기가 32KB인 Limited(제한된) LOB 모드를 사용합니다. 디폴트 구성을 사용하는 경우 최대 LOB 크기를 초과하는 모든 LOB가 잘립니다. 잘린 LOB 컬럼은 소스와 타겟의 값이 다르기 때문에 데이터 검증 실패로 이어집니다. AWS DMS CloudWatch Logs에서 잘림(truncation) 경고를 검색하여 LOB 잘림을 확인할 수 있습니다. 잘림을 방지하려면 최대 LOB 크기를 소스 데이터베이스의 LOB 크기와 일치하도록 설정합니다. LOB 크기가 확실하지 않으면 Inline LOB 모드(엔드포인트에서 지원하는 경우) 를 선택하여 작거나 큰 사이즈의 LOB를 모두 복제할 수 있습니다. 검증 전용 작업에서 ValidationPartialLobSize 값을 데이터 마이그레이션 작업의 최대 LOB 크기와 동일한 값으로 설정하는 것이 좋습니다.

숫자와 타임스탬프 잘림

숫자와 타임스탬프 데이터는 일반적으로 데이터베이스 엔진마다 다른 스케일과 정밀도를 가지며 값이 지정되지 않은 경우 스케일과 정밀도에 대한 디폴트 값이 다릅니다. 다음은 숫자와 타임스탬프에 대한 잠재적인 문제와 이를 수정할 수 있는 방법에 대한 일반적인 예제를 설명 드리겠습니다.

Oracle소스의 경우

Oracle 데이터베이스에서 NUMBER로 정의된 숫자 데이터의 경우 소수 자릿수와 정밀도가 명시적으로 언급되지 않으면 AWS DMS는 소수 자릿수를 10으로 산정하여 데이터를 자릅니다. 소수 자릿수가 10보다 큰 값을 가진 소스 데이터의 경우 타겟에서 숫자가 잘립니다. 예를 들어 데이터 123456.123456789012는 123456.1234567890으로 잘립니다. 데이터가 잘리는 것을 방지하려면 DMS 데이터 복제 작업의 엔드포인트의 Extra Connection Attribute(ECA) 파라미터 NumberDataTypeScale 에 적절한 값으로 수정합니다. 기본값은 10이지만 이 예에서는 값을 12로 설정하여 데이터가 잘리는 것을 방지합니다. 이러한 파라미터 설정에 대한 자세한 내용은 AWS DMS documentation 를 참고해주십시오.

PostgreSQL 소스의 경우

PostgreSQL에서 PostgreSQL로 마이그레이션할 때 정밀도나 소숫점 자릿수가 정의되지 않은 숫자 유형으로 정의된 컬럼에 숫자 데이터가 저장되면 AWS DMS는 정밀도 28, 소수점 자릿수 6으로 데이터를 잘라냅니다. 잘림을 방지하려면 소스 및 타겟 엔드포인트에서 ECA 설정에서 MapUnboundedNumericAsString=true를 사용하여 마이그레이션 중에 바인딩되지 않는 숫자 데이터를 문자열 유형으로 매핑할 수 있습니다.

타임스탬프 데이터

Oracle은 Timestamp 데이터 타입에서 초에 대해 최대 9자리의 소수점 자릿수(나노초)를 지원합니다. SQL Server는 TIME 데이터 타입에서 초에 최대 7자리의 소수점 자릿수를 지원합니다.이 데이터가 MySQL이나 PostgreSQL과 같은 타겟에 매핑 되면 둘 다 TIMESTAMP 데이터 타입으로 초당 최대 6자리의 소수점 자릿수를 지원합니다. 따라서 DMS 데이터 검증 작업은 소스 데이터베이스(예: Oracle)에 TIMESTAMP(7) ~ TIMESTAMP(9)로 정의된 데이터 유형이 발견되는 경우 이를 일치하지 않는 레코드로 보고됩니다. 동일한 문제가 Oracle의 TIMESTAMP WITH TIME ZONE , TIMESTAMP WITH LOCAL TIME ZONE, SQL Server의 DATEIME2 , DATETIMEOFFSET과 같이 TIMESTAMP 데이터 유형 변형에서도 발생될 수 있습니다 . 데이터 잘림이 비즈니스 업무에서 허용되는 경우 이 글의 후반부에서 보여주는 것처럼 사용자 정의 함수로 재정의 검증 규칙(override-validation-ru)을 설정할 수 있습니다.

트리거나 스케줄러에 의해서 업데이트된 데이터

AWS DMS는 소스에서 타겟 데이터베이스로 데이터를 마이그레이션하고 복제와 동기화 상태를 유지합니다. DMS 외부에서 발생하는 모든 변경은 데이터 불일치의 위험을 높이며 잠재적으로 데이터 검증 오류를 일으킬 수 있습니다. 이러한 변경 중 일부는 의도하지 않은 것으로 예를 들어 다음과 같은 경우가 있습니다.

타겟에서 활성화된 데이터베이스 트리거는 AWS DMS 작업이 타겟 테이블에서 데이터 조작 언어(DML)에 의해 변경될 때 데이터가 업데이트될 수 있습니다.권장되는 것은 데이터 마이그레이션 동안 트리거를 비 활성화하고 전환 동안만 활성화하는 것이 좋습니다.PostgreSQL이 타겟인 경우 파라미터 session_replication_role=replica 설정을 통해 트리거와 외래 키(Foreign Key) 제약 조건을 비 활성화할 수 있습니다.
타겟 데이터베이스에서 실행되는 스케줄러 작업(Job)이 데이터를 수정할 수 있습니다.초기 스키마 컨버전 중에 스케줄러 작업(Scheduler Job)이 타겟으로 마이그레이션될 수도 있습니다. 이러한 작업이 활성화된 경우 타겟의 데이터가 변경되고 복잡한 문제 해결이 필요한 데이터 검증에 영향을 미칠 수 있습니다. 권장되는 것은 내부 데이터베이스 스케줄러 작업이나 일부 애플리케이션 내에서 예약된 외부 스케줄 된 Job 의 경우 타겟 데이터를 잠재적으로 수정할 수 있어 스케줄러 작업을 비 활성화하는 것이 좋습니다.

캐릭터 셋과 콜레이션(Collation) 설정

데이터 마이그레이션 중에 데이터는 여러 디코딩과 인코딩 단계를 거쳐 소스 데이터베이스에서 데이터를 읽고 DMS 복제 인스턴스에서 데이터를 처리하고 마지막으로 타겟 데이터베이스의 로컬 설정에 따라 데이터를 로드 합니다. 변환 시 유니코드에서 라틴 캐릭터 셋으로 적절하지 않은 구성이 설정된 경우 손실 변환으로 인해 레코드 차이가 발생하며 데이터 검증 작업이 이러한 레코드를 ValidationFailed로 보고할 수 있습니다. 악센트 구분 또는 대소문자 구분으로 인해 DMS 복제 작업에서 데이터 오류가 발생할 수 있습니다. 예를 들어 디폴트로 악센트 구분이나 대소문자 구분으로 설정된 소스 데이터베이스가 있습니다. NAME 컬럼이 Primary Key 로 되어 있는 테이블에는 AAAA, aaaa, áááá라는 세 개의 레코드가 있습니다. 이러한 레코드가 악센트 구분이나 대소문자 구분이 없는 타겟 데이터베이스(예: utf8mb4_0900_ai_ci 콜레이션으로 생성된 MySQL 데이터베이스)에 반영될 때 엑센트와 대소문자가 다른 문자들이 모두 동일한 레코드로 처리하기 때문에 중복 키 오류가 발생합니다. 이러한 Unique 제약 조건 위반 오류로 인해 해당 레코드는 awsdms_validation_failures_v1 컨트롤 테이블에 FAILURE_TYPE 에 MISSING_TARGET으로 표시됩니다.

Transformation과 Filter Rule 의 효과

DMS는 데이터 마이그레이션의 일부로 기존 스키마와 데이터를 변환하는 강력한 transformation rules을 제공하며 필터 기준이 충족될 때만 데이터를 타겟 데이터베이스로 마이그레이션하는 filter rules도 지원합니다. 데이터 마이그레이션 작업에서 사용되는 이러한 변환 및 필터 규칙은 의도치 않게 타겟 데이터베이스에서 데이터 불일치를 생성할 수 있습니다. 데이터 검증 전용 작업을 생성할 때는 이러한 규칙의 부작용인 데이터 검증 문제를 피하기 위해 동일한 변환과 필터 규칙을 사용하는 것이 중요합니다. 데이터 검증 전용 작업에서 변환이나 필터 규칙이 포함된 경우 DMS는 먼저 규칙(Rule)을 적용한 다음 데이터를 검증하고 일치하지 않는 레코드에 대한 실패를 보고합니다.

예를 들어, 소스의 COL1을 타겟의 col2로 Rename 하는 변환 규칙이 있는 마이그레이션 작업을 생성했습니다. 그러나 동일한 변환 규칙 없이 데이터 검증 전용 작업을 생성하는 경우 DMS는 TargetTablePrepMode가 DO_NOTHING이므로 기반이 되는 테이블의 메타데이터를 인식하지 못합니다. 여기에서 DMS는 검증을 위해 COL1과 col2가 무시됩니다. 또다른 사례는 데이터 마이그레이션에서 필터를 적용하였지만 데이터 검증 전용 작업에서는 필터 규칙을 생략한 경우에는 소스 데이터베이스 상에는 레코드가 존재하지만 필터 규칙으로 인해 타겟으로 마이그레이션되지 않았으므로 이때 검증 오류가 표시됩니다.

데이터 검증에서 재정의 규칙(Override Rule)을 활용하는 방법

데이터 검증 중에 이 글에서 설명된 사례를 포함하여 다양한 검증 오류가 발생 될 수 있습니다. 예를 들어 소스 엔진과 타겟 엔진 간에 캐릭터 셋이 다르기 때문에 동일한 데이터가 마이그레이션되었지만 RECORD_DIFF로 표시되는 Mismatched records 오류가 발생할 수 있습니다. 또는 AWS DMS 데이터 검증에 사용되는 소스 데이터베이스 버전이 Bulit-in 함수를 지원하지 않기 때문에 ValidationFailed가 발생하고 CloudWatch Logs에서 < No authorized routine named ‘HASH’ of type ‘FUNCTION’ having compatible arguments was found > 또는 <pg_catalog.timezone(unknown, json)> 과 같은 오류가 발생할 수 있습니다. 이를 위한 AWS DMS의 데이터 검증은 Mapping-rule에서 검증 규칙 유형의 override-validation-function을 제공합니다. 소스 엔진과 타겟 엔진에서 지원하는 데이터베이스 함수를 사용하여 고유한 검증 규칙을 추가할 수 있습니다.

예를 들어 Oracle에서 MySQL로 마이그레이션한 이전의 설명 드린 타임스탬프 데이터 잘림 사례를 예를 들어보면 다음의 재정의 규칙에서 사용자 지정 함수를 사용하여 데이터를 비교할 수 있습니다. 이 규칙은 Oracle의 to_char 함수를 사용하여 소스 컬럼의 타임스탬프 값을 YYYY-MM-DD HH:MM:SS.ffffff 형식으로 변환하고 MySQL의 date_format 함수를 사용하여 타겟 컬럼 값을 동일한 형식으로 변환할 수 있습니다.

{
    "rule-type": "validation",
    "rule-id": "1",
    "rule-name": "1",
    "rule-target": "column",
    "object-locator": {
      "schema-name": "SCHEMA_NAME",
      "table-name": "TABLE_NAME",
      "column-name": "COLUMN_NAME"
    },
    "rule-action": "override-validation-function",
    "source-function": "to_char(cast(${column-name} as timestamp(6)), 'YYYY-MM-DD HH24:MI:SS.FF6')”
    "target-function": "date_format(${column-name}, '%Y-%m-%d %H:%i%:%s.%f')"
}

다음은 IBM DB2 에서 PostgreSQL 마이그레이션에서 특정 컬럼의 길이를 비교하는 예입니다.

{
    "rule-type": "validation",
    "rule-id": "2",
    "rule-name": "2",
    "rule-target": "column",
    "object-locator": {
      "schema-name": "SCHEMA_NAME",
      "table-name": "TABLE_NAME",
      "column-name": "COLUMN_NAME"
    },
    "rule-action": "override-validation-function",
    "source-function": "length(${column-name})",
    "target-function": "length(${column-name})"
}

다음 검증 규칙은 소스와 타겟의 컬럼을 텍스트로 변환해서 UTF8로 인코딩하고 MD5 해시값으로 계산해서 이 해시값을 대문자로 변환해서 최종 출력 유형이 VARCHAR(64)인지 확인한 후 비교합니다. 이는 PostgreSQL에서 PostgreSQL로 동종 마이그레이션하는 경우 여러 데이터베이스로부터의 일관된 고유한 식별자로서 비교하는 데 유용하게 사용될 수 있습니다.

{
  "rule-type": "validation",
  "rule-id": "3",
  "rule-name": "3",
  "rule-target": "column",
  "object-locator": {
    "schema-name": "SCHEMA_NAME",
    "table-name": "TABLE_NAME",
    "column-name": "COLUMN_NAME"
  },
  "rule-action": "override-validation-function",
  "source-function": "CAST (upper(md5(convert_to(CAST ('${column-name}' AS text), 'UTF8'))) AS VARCHAR(64))",
  "target-function": "CAST (upper(md5(convert_to(CAST ('${column-name}' AS text), 'UTF8'))) AS VARCHAR(64))"
}

AWS DMS는 SYS.DBMS_CRYPTO.HASH(TO_CLOB(“COLUMN_NAME”), 2) 와 같은 LOB를 검증하기 위해 MD5 해시 암호화를 사용합니다. 소스 Oracle이 FIPS(Federal Information Processing Standards)가 활성화된 경우(DPFIPS_140 = true) 버전에 따라 HASH_MD5가 작동하지 않을 수 있습니다. 이 경우 PostgreSQL 마이그레이션에 대해 다음의 재정의 규칙을 고려할 수 있습니다.

{
  "rule-type": "validation",
  "rule-id": "4",
  "rule-name": "4",
  "rule-target": "column",
  "object-locator": {
    "schema-name": "SCHEMA_NAME",
    "table-name": "TABLE_NAME",
    "column-name": "COLUMN_NAME"
  },
  "rule-action": "override-validation-function",
  "source-function": "dbms_lob.getlength(${column-name})"
  "target-function": "coalesce(char_length(${column-name}),0)"
}

정리

이 글의 내용을 따라하기 위해 테스트 환경을 만드신 경우 Clean up AWS DMS resources에 제공된 정보를 참고하시어 이 글에서 설명하는 방법들을 테스트하기 위해 만든 환경을 정리해주십시오.

결론

이 글에서는 AWS DMS 데이터 검증 전용 작업의 일반적인 사용 사례를 활용, 모니터링, 최적화, 처리하는 방법을 설명드렸습니다. 소스와 타겟 데이터베이스와 데이터 마이그레이션 요구 사항에 따라 AWS DMS 데이터 검증 전용 작업을 고려해서 마이그레이션에 대한 높은 신뢰를 얻을 수 있습니다. 질문이 있으신 경우 댓글에 남겨주십시오.

AWS 기술 블로그