AWS DMS
더 많은 작업
- AWS Database Migration Service; AWS DMS; Database Migration Service
- 원본 데이터베이스를 계속 운영하면서 데이터를 다른 데이터베이스로 옮기고 변경분을 지속 복제하는 AWS의 관리형 데이터베이스 마이그레이션 서비스
AWS DMS는 온프레미스나 다른 클라우드의 관계형 DB, 데이터 웨어하우스, NoSQL DB를 AWS로 옮기거나 AWS 안에서 엔진을 바꿀 때 쓴다. 기본 구조는 AWS 안의 복제 서버가 원본 엔드포인트에서 데이터를 읽어 대상 엔드포인트에 쓰는 것이다. 처음 한 번 전체를 복사한 뒤 원본에서 생긴 변경을 계속 따라가기 때문에, 원본 애플리케이션을 멈추지 않고 이전하다가 짧은 전환(cutover) 시간만 잡으면 된다. 같은 엔진끼리는 데이터만 옮기면 되지만, 엔진이 다르면 스키마와 코드 변환이 먼저 필요하다. 이전 방식 전반은 클라우드 이전 전략 문서를 참고한다.
| 항목 | 설명 |
|---|---|
| 복제 인스턴스 | VPC 안의 EC2 인스턴스에서 복제 소프트웨어를 실행한다. 다중 AZ로 만들면 다른 가용 영역에 동기식 대기 복제본을 두어 장애 조치를 지원한다 |
| DMS Serverless | 복제 인스턴스 대신 용량을 자동으로 프로비저닝·확장하고 사용한 만큼 과금한다. 용량 산정과 엔진 버전 관리가 필요 없다 |
| 원본·대상 엔드포인트 | 접속 정보와 엔진 유형. 작업에 쓰기 전에 연결 테스트를 통과해야 한다 |
| 마이그레이션 작업 | 어떤 스키마·테이블을 어떤 방식으로 옮길지 정의. 테이블 선택, 이름 변경 같은 변환 규칙, 데이터 검증을 설정한다 |
| DMS Schema Conversion | 원본 스키마를 대상 엔진 형식으로 평가·변환하는 DMS 기능(콘솔·API 기반) |
| AWS SCT | 로컬 PC에 설치해 쓰는 스키마 변환 도구 |
| 유형 | 동작 | 쓰는 경우 |
|---|---|---|
| 전체 로드(기존 데이터 마이그레이션) | 원본 테이블의 현재 데이터를 대상에 한 번 복사 | 다운타임을 허용하는 일회성 이전 |
| 전체 로드 + CDC | 전체 복사 중 생긴 변경을 캐시했다가 적용하고, 이후에도 변경을 계속 복제 | 다운타임 최소화 이전. 가장 많이 쓴다 |
| CDC만 | 변경 데이터만 복제 | 대량 초기 적재는 원본 엔진의 내보내기·가져오기 도구로 하고 변경분만 DMS로 따라갈 때 |
CDC(변경 데이터 캡처)는 원본 DB의 트랜잭션 로그를 읽어 변경을 가져오므로 원본은 이전이 끝날 때까지 정상 운영된다. DMS는 대상에 테이블과 기본 키를 만들어 주지만, 보조 인덱스·뷰·저장 프로시저 같은 나머지 객체는 스키마 변환 도구나 원본 엔진 도구로 따로 만들어야 한다.
| 구분 | 동종(homogeneous) | 이기종(heterogeneous) |
|---|---|---|
| 예 | 온프레미스 MySQL → 아마존 RDS for MySQL, Oracle → RDS for Oracle | Oracle → Aurora PostgreSQL, SQL Server → Aurora MySQL |
| 스키마 | 거의 그대로 사용 | 데이터 형식, 저장 프로시저, 함수를 변환해야 함 |
| 절차 | DMS(또는 엔진 기본 도구)로 데이터 이전 | ① DMS Schema Conversion이나 AWS SCT로 스키마 변환 → ② 변환 결과를 대상에 적용 → ③ DMS로 데이터 이전·CDC |
| 변환 결과 | 해당 없음 | 자동 변환이 안 되는 부분은 평가 보고서에 표시되어 수작업으로 고친다 |
AWS Schema Conversion Tool(AWS SCT)은 원본 DB 엔진의 스키마를 다른 엔진에 맞게 바꾸는 도구다. 관계형 OLTP 스키마뿐 아니라 데이터 웨어하우스 스키마도 변환하며, 대상은 RDS(MySQL, MariaDB, Oracle, SQL Server, PostgreSQL), Aurora, Redshift 등이다. 지금은 DMS 안의 기능인 DMS Schema Conversion으로 같은 일을 콘솔에서 할 수 있어서, 별도 설치가 필요한 SCT 대신 이를 쓰는 경우가 늘었다. 시험에서는 둘 다 "이기종 스키마 변환" 역할로 이해하면 된다.
AWS Application Migration Service(AWS MGN)는 물리 서버, 가상 머신, 다른 클라우드의 서버를 블록 수준에서 계속 복제해 아마존 EC2 인스턴스로 바꿔 띄우는 리호스팅(lift-and-shift) 서비스다. 2026년 10월 현재 AWS 공식 페이지와 문서에서는 이름이 AWS Transform MGN으로 바뀌어 있다(이전 이름 AWS Application Migration Service). 시험 가이드에는 기존 이름으로 실려 있다.
- 원본 서버에 복제 에이전트를 설치하면 데이터가 AWS의 스테이징 영역으로 계속 복제된다.
- 테스트 인스턴스를 띄워 검증한 뒤, 전환 시점에 실제 인스턴스로 컷오버한다. 전환 창은 보통 몇 분 수준이다.
- 서버를 애플리케이션과 웨이브 단위로 묶어 대량 이전을 관리한다.
- DB 엔진을 바꾸지 않고 DB 서버째 옮기는 경우에도 쓸 수 있지만, 관리형 DB(RDS·Aurora)로 옮기려면 DMS를 쓴다.
- "원본 DB를 계속 운영하면서 다운타임을 최소화해 이전"이면 DMS의 전체 로드 + CDC다.
- "Oracle이나 SQL Server를 Aurora PostgreSQL·MySQL로 이전"은 이기종이므로 스키마 변환(DMS Schema Conversion 또는 SCT) 후 DMS 순서다. DMS만 고르는 보기는 불완전하다.
- "온프레미스 서버(애플리케이션)를 수정 없이 EC2로 대량 이전"은 Application Migration Service(현재 이름 AWS Transform MGN)다. DMS와 구분한다.
- 복제 인스턴스 장애에 대비하려면 다중 AZ 복제 인스턴스를, 용량 산정을 피하려면 DMS Serverless를 고른다.
- 대량 초기 적재를 엔진 기본 도구로 빠르게 하고 이후 변경분만 맞추는 패턴은 CDC만 작업이다.
- AWS DMS Fleet Advisor는 2026년 5월 20일 지원이 종료되었으므로 새 설계의 보기로 고르지 않는다.