Article

AWS DMS 마이그레이션 데이터 검증 가이드

도입

AWS DMS(Database Migration Service)는 강력한 도구지만, 마이그레이션을 완료한 후 “복제는 끝났는데 값이 미묘하게 다르다”는 상황을 경험하는 개발자들이 많습니다. 이 글은 그런 상황에서 어떤 순서로 점검해야 하는지 실무 기반으로 정리한 가이드입니다. DMS만 탓하기보다는 체계적으로 문제를 진단하고 해결하는 접근 방식을 제시합니다.

먼저 확인할 3가지

데이터 불일치가 발생했을 때 가장 먼저 봐야 할 항목은 다음 세 가지입니다:

  1. 스키마 검증: DMS에만 맡기지 말고 소스 DB와 타깃 DB의 스키마를 직접 비교
  2. 외래 키 제약: 타깃 endpoint의 추가 연결 속성에서 FOREIGN_KEY_CHECKS 확인
  3. 시간대 설정: 소스와 타깃 endpoint의 시간대 설정이 일치하는지 확인

데이터 불일치의 일반적인 원인

증상의심 지점확인 방법
일부 컬럼 값이 예상과 다름기본값, NULL 허용 여부, 시간대SHOW CREATE TABLE 비교
특정 테이블만 적재 실패외래 키 제약, 테이블 적재 순서DMS 태스크 로그, target endpoint 설정
시간 관련 컬럼만 계속 어긋남소스/타깃 시간대 불일치endpoint 설정값 비교

스키마 차이에서 비롯되는 경우가 가장 많습니다. DMS는 데이터 적재와 변경 복제에 집중하고, 스키마는 소스 기준 덤프를 신뢰하는 것이 더 안전합니다.

1단계: 스키마 검증부터 시작

테이블 정의 비교

예상치 못한 값이 들어가거나 기본값이 다를 때는 레코드부터 보지 말고 테이블 정의를 먼저 비교하세요:

SHOW CREATE TABLE source_table;
SHOW CREATE TABLE target_table;

특히 다음 항목을 확인합니다:

  • DEFAULT 값: 기본값이 동일한지 확인
  • NULL 허용 여부: nullable 설정이 같은지 확인
  • TIMESTAMP/DATETIME: 자동 업데이트 설정 확인
  • 트리거와 제약: 숨겨진 트리거나 제약이 있는지 확인
  • 문자 집합: 컬럼의 문자 집합(charset) 확인

스키마 불일치 시 대응

스키마 차이가 발견되면 데이터를 다시 적재하기 전에 먼저 스키마를 바로잡는 것이 훨씬 덜 복잡합니다:

-- 예: deleted_at 기본값 추가
ALTER TABLE target_table 
MODIFY deleted_at TIMESTAMP NULL DEFAULT NULL;

2단계: 외래 키 제약 조건 확인

Foreign Key Checks 설정

AWS DMS 문서는 MySQL 호환 타깃으로 전체 적재할 때 foreign key checks를 비활성화해야 한다고 명시합니다.

타깃 endpoint의 추가 연결 속성(Extra Connection Attributes)에 다음을 추가:

Initstmt=SET FOREIGN_KEY_CHECKS=0;

일부 행이 빠지거나 “제약 조건 위반” 에러가 날 때 이 설정부터 확인하세요.

주의사항

이 설정은 “문제를 영구적으로 숨기는” 것이 아닙니다:

  • 전체 적재 시 참조 무결성 충돌을 줄이는 운영 설정입니다
  • 적재 완료 후 참조 무결성을 실제로 검증해야 합니다
  • CDC(변경 데이터 캡처)를 포함한 작업이면 적재 후 애플리케이션 쓰기 순서와 제약 조건 복구 시점도 함께 검토하세요

3단계: 시간대 설정 확인

MySQL 소스 Endpoint 설정

MySQL 소스 endpoint의 ServerTimezone 설정을 확인:

aws dms describe-endpoints --filters Name=engine-name,Values=mysql

또는 생성 시 지정:

--my-sql-settings '{"ServerTimezone":"Asia/Seoul"}'

MySQL 타깃 Endpoint 설정

MySQL 호환 타깃 endpoint의 추가 연결 속성에 시간대 추가:

Initstmt=SET time_zone='+09:00';

또는 지역명 사용:

Initstmt=SET time_zone='Asia/Seoul';

시간 불일치 진단

시간 컬럼 문제는 한 곳만 봐서는 안 풉니다. 앱, DB, DMS 세 군데를 모두 확인:

확인 항목명령어
소스 DB 시간대SELECT @@global.time_zone, @@session.time_zone;
타깃 DB 시간대SELECT @@global.time_zone, @@session.time_zone;
애플리케이션 시간대코드에서 TimeZone.getDefault() 확인
DMS 소스 endpointAWS 콘솔 또는 CLI로 ServerTimezone 확인
DMS 타깃 endpointAWS 콘솔에서 Extra Connection Attributes 확인

마이그레이션 전 체크리스트

마이그레이션을 시작하기 전에 다음 항목들을 확인하세요:

  • 소스와 타깃의 SHOW CREATE TABLE 결과를 비교하고 스키마가 일치하는지 확인
  • full load인지, CDC 포함인지 작업 방식을 명확히 함
  • 외래 키 오류가 예상되면 target endpoint에 Initstmt=SET FOREIGN_KEY_CHECKS=0; 설정
  • 시간 컬럼이 있으면 source의 ServerTimezone과 target의 time_zone을 동일하게 설정
  • 일부 테이블만 문제가 있으면 태스크 로그와 샘플 row를 함께 비교
  • 마이그레이션 후 적재된 데이터를 샘플로 검증하고 로우 카운트 비교

마치며

AWS DMS 마이그레이션에서 데이터가 어긋날 때는 “DMS가 이상하다”보다 “스키마, 제약 조건, 시간대 중 어디가 다르지?”라고 보는 편이 훨씬 빠르게 문제를 해결합니다. 특히 MySQL 계열에서는 foreign key checks와 time zone 설정이 반복적으로 문제를 만들곤 합니다. 이 가이드의 세 가지 점검 항목을 먼저 확인하면 대부분의 데이터 불일치 문제를 빠르게 찾아낼 수 있습니다.

댓글