DB 마이그레이션을 해본 분이라면 “다운타임 최소화”, “데이터 정합성”, “이기종 DB 전환(Oracle→PostgreSQL 같은)”이 얼마나 까다로운지 체감하셨을 거예요.
AWS DMS는 이런 문제를 해결하기 위해 소스 DB를 운영 상태로 유지한 채 데이터 마이그레이션/복제를 수행하도록 설계된 관리형(Managed) 서비스입니다. Source
목차
AWS DMS가 하는 일
AWS DMS는 크게 두 가지 모드로 일합니다.
- Full load: 기존 데이터를 한 번에 쭉 적재(초기 이관)
- CDC(Change Data Capture): 초기 적재 이후에도 소스 DB에서 발생하는 변경(INSERT/UPDATE/DELETE)을 계속 따라가며 복제
즉, 전형적인 패턴은 Full load + CDC로 “거의 무중단(near-zero downtime)” 컷오버를 만드는 것입니다. Source
DMS 구성요소(아키텍처)
1) 핵심 컴포넌트
DMS는 보통 아래 구성으로 이해하면 쉽습니다.
- Source endpoint: 원본 DB 접속 정의
- Target endpoint: 목적지 DB(또는 S3/Redshift 등) 접속 정의
- Replication instance(또는 Serverless replication): 실제로 데이터를 옮기고 CDC를 처리하는 “엔진”
- Task: 어떤 테이블을 어떤 방식(Full load/CDC)으로 옮길지 정의
공식 문서의 “Components of AWS DMS”가 이 구조를 잘 정리합니다. Source
2) 참고 이미지(블로그/문서에 그대로 삽입 가능)
아래 이미지는 글 중간에 넣기 좋은 “DMS 개요/구성요소” 류입니다.
실 사용 사례 5가지
사례 1) 온프레미스/EC2 DB → Amazon Aurora PostgreSQL로 “다운타임 최소화” 마이그레이션
가장 전형적인 DMS 활용입니다.
- 초기 데이터는 Full load로 적재
- 운영 중 변경분은 CDC로 계속 따라감
- 애플리케이션 커넥션을 타깃 DB로 바꾸는 순간(컷오버)만 짧게 잡고 전환
AWS도 “PostgreSQL → Aurora PostgreSQL” 동종 마이그레이션 예시를 공개합니다. Source
사례 2) 이기종 마이그레이션(Oracle/SQL Server → Aurora PostgreSQL)에서 SCT + DMS 조합
이기종 전환은 “데이터 옮기기”보다 스키마/프로시저 변환이 더 큰 일입니다.
- AWS SCT(Schema Conversion Tool): 스키마/코드 변환을 지원
- AWS DMS: 변환된 타깃에 데이터 이관(Full load + CDC)
AWS Prescriptive Guidance에서도 이기종 마이그레이션 전략을 정리합니다. Source
사례 3) 운영 DB → Amazon S3로 CDC 적재해서 분석/레이크 구축
DMS는 DB → DB만이 아니라 DB → S3 같은 패턴에도 자주 씁니다.
- 운영 DB의 변경 이벤트를 S3에 쌓아두고
- 이후 Athena/Glue/Redshift 등으로 분석 파이프라인을 만들기
(이때는 “마이그레이션”이라기보다 지속 복제/수집(ingestion)에 가깝습니다.)
관련 기능과 운영 포인트는 DMS 문서/가이드 전반에서 다룹니다. Source
사례 4) 다수 DB/대용량 테이블에서 지속 복제 성능 튜닝 (필터/병렬화 등)
CDC가 길게 돌면 결국 관건은 “지연(lag) 최소화”입니다.
AWS Database Blog에서는 컬럼 필터로 병렬화해 continuous replication 성능을 개선하는 접근을 다룹니다. Source
사례 5) “서버 관리 싫다” → DMS Serverless로 자동 프로비저닝/스케일링
Replication instance를 직접 사이징/운영하는 대신, DMS Serverless를 선택할 수 있습니다.
- 자동 프로비저닝/스케일링
- 사용량 기반 과금 모델(프로젝트 특성에 따라 유리/불리 갈림)
개념/구성은 공식 문서에 정리되어 있습니다. Source
실무 체크리스트(운영/성능/검증)
1) 모니터링: CloudWatch + DMS 콘솔
DMS는 태스크 상태/진행률/테이블 통계/로그를 기반으로 운영합니다.
모니터링 방법은 “Monitoring AWS DMS tasks”에 정리되어 있어요. Source
2) 데이터 검증(Data validation)
DMS는 데이터 검증 기능을 제공합니다(환경/타깃에 따라 비용/부하 고려 필요). Source
자주 겪는 제약/함정
LOB(대용량 컬럼) 기본값 함정
DMS는 LOB 처리 모드가 있고, 설정에 따라 일부 LOB가 잘리거나(truncate) 검증 실패가 날 수 있습니다.
LOB 지원 설정 문서(“Setting LOB support…”)를 꼭 한 번 보고 세팅을 잡는 게 안전합니다. Source
마무리
정리하면 AWS DMS는 다음 상황에서 특히 강합니다.
- 다운타임을 최소화해야 하는 운영 DB 마이그레이션
- 초기 적재 + 변경분 추적(CDC)로 만드는 안전한 컷오버
- DB를 “옮기는 것”뿐 아니라 S3 등으로 흘려보내는 데이터 수집 파이프라인
