AWS re:Invent 2023 - Dive deep into different AWS DMS migration options (DAT328)

AWS Events·AWS re:Invent 2023 2023·2023년

AI 요약

AWS re:Invent 2023의 DAT328 세션으로, 데이터베이스 마이그레이션을 "복제"로 단순화해 보고 AWS Database Migration Service(DMS)의 여러 옵션을 언제 무엇을 쓸지와 함께 깊이 파고든다. 자산 파악(Fleet Advisor)→스키마 변환→데이터 이동→검증·운영의 전 과정을 데모와 모범 사례로 잇는다.

핵심 포인트

Fleet Advisor로 환경을 스캔해 이전 대상·비용을 추정하고, SQL Server 등은 규칙 기반 Schema Conversion으로 자동 변환(85~90%)
데이터 이동은 DMS 클래식(인스턴스 직접 지정), 서버리스(DCU 자동 스케일), 동종 마이그레이션(네이티브 도구 래핑) 셋 중 상황에 맞게 선택
사이징(메모리가 왕)·LOB·병렬화·네트워크 대역폭 같은 성능 함정과 사전 평가·데이터 검증, 그리고 DMS 3.5.1 신규 기능

왜 읽나온프레미스/상용 DB를 AWS로 옮기려는 엔지니어가 DMS 선택지와 흔한 함정을 한 번에 정리하기 좋다.

챕터별 상세

010:00 – 7:32

DMS란 무엇인가 — 마이그레이션은 곧 복제, 그리고 Fleet Advisor

AWS DMS 제품 리드 John이 데이터 마이그레이션 이 사실상 "복제(replication)"와 같다고 짚으며 기술 심화 세션을 연다. 온프레미스→클라우드, 클라우드 내부, 서로 다른 DB 유형 사이 등 "데이터를 옮긴다"로 단순화하면 되며, DMS 는 약 21개 소스에서 19~20개 타깃으로, 특히 유형 간 이동을 핵심으로 데이터를 옮긴다. 약 10년 전 당시 CEO Andy Jassy가 클라우드 "마이그레이션"을 바라 DRS 대신 DMS로 명명됐다는 비화와, 이미 120만+ DB가 옮겨졌고 Amazon 자신도 2019년 Oracle을 벗어나 75PB·7500+ DB를 클라우드 네이티브·오픈소스로 옮긴 사례를 든다.

마이그레이션을 도울 자원으로 서드파티 파트너, Professional Services, 무료 가이드 DMA Advisors, 재정 지원을 소개한다. 첫 단계는 "내가 무엇을 가졌는지 아는 것"이며, 무료 기능 DMS Fleet Advisor 가 온프레미스에 단일 컬렉터 를 설치해 환경 전체를 스캔하고 무엇이 돌고 어떤 성능 특성인지 보고 AWS의 무엇으로 옮길지 자동 추천한다. CSV로 먼저 검증 가능하고 데이터는 고객 계정의 S3 버킷에 업로드되며, 사용 패턴·라이선스를 분석해 "RDS Oracle 다중 AZ"·"RDS PostgreSQL 후보"처럼 추천하고 가격을 끌어와 비용 추정치 까지 알려 준다.

자산을 파악한 뒤엔 옮겨야 한다. 온프레미스 PostgreSQL→RDS PostgreSQL처럼 변환이 필요 없는 경우가 많지만, SQL Server 같은 상용 시스템을 다른 유형으로 바꾸려면 DMS Schema Conversion 이 스키마를 자동 변환한다(85~90% 수준). 첫 단계는 "82%를 변환할 수 있고 어려운 영역은 이러이러하다" 같은 평가이며, Fleet Advisor가 수천 대를 빠르게 스캔하는 반면 스키마 변환은 모든 프로시저·함수·테이블·데이터 타입을 들여다보는 심층 분석이라 가장 복잡한 변환은 몇 시간이 걸린다.

방식은 데스크톱 도구 AWS Schema Conversion Tool(SCT) 과 서비스 통합형 DMS Schema Conversion 두 가지다. 후자는 소스·타깃 폭은 좁지만 로컬 설치·노트북 CPU·정보보안팀 승인이 필요 없고 클라우드 CPU를 쓰며 무료다. 동작 원리로는 워크플로를 조율하는 오케스트레이터, 메타데이터를 적재하는 로더, 스키마 객체를 순회하는 이터레이터, 소스 코드를 분해해 추상 소스 트리(AST) 에 넣는 파서 를 소개한다. 파서가 만든 일반화된 트리에서 충돌을 해소한 뒤 Oracle→MySQL처럼 변환해 타깃 AST 에 담고 SQL로 저장하거나 DB에 직접 적용하며, 현재 스키마 변환은 AI가 아닌 순수 규칙 기반(rules based) 임을 분명히 한다.

스키마를 변환했어도(같은 유형 관리형이나 온프레미스→클라우드면 변환 불필요) 이제 데이터를 옮겨야 한다. 첫 옵션은 DMS 로지컬 리플리케이션 인스턴스 다. DMS는 본질적으로 로지컬 복제 서비스로, AWS가 관리하지만 고객이 접근하는 EC2 박스에 설치되고, 하이브리드 네트워크 컨테이너가 모든 것을 캡슐화해 데이터는 컨테이너 안에 머물고 AWS가 패치·페일오버를 맡는다. 복제 엔진은 소스에서 SELECT로 빼내(필요하면 변환) 타깃에 INSERT하고, 복제 측면에서는 소스 로그(bin log/WAL)를 마이닝해 적용한다.

이것이 "DMS 클래식"으로 M5 xlarge 같은 인스턴스 크기를 직접 지정해야 해 과소 프로비저닝 위험이 있다. 그래서 서버리스(Serverless) 가 등장한다. 시작 시 소스에 쿼리를 던져 구조·부하를 파악해 크기를 정하고, 인스턴스 대신 DCU(DMS Capacity Unit) 의 최소·최대를 지정하며 약 20분 단위로 스케일해 요요를 막는다. 세 번째는 동종(homogeneous) 마이그레이션 으로, 로지컬 복제 대신 네이티브 도구(MySQL은 MySQL이, PostgreSQL은 PostgreSQL이 가장 잘 옮긴다)를 감싸 보안·S3 경유·복제 설정을 처리하며, API 기반이라 100개 DB를 한 번에 옮기고 다중 AZ 페일오버도 켤 수 있다.

Ryan이 약 11~12분짜리 데모를 진행한다. DMS 콘솔의 세 신규 섹션인 데이터 프로바이더(연결 정보), 인스턴스 프로파일(네트워크·보안, 서브넷에 따라 퍼블릭/프라이빗 결정), 마이그레이션 프로젝트(반복 가능한 묶음)를 보여 주고 Full Load·CloudWatch 로그를 켜 작업을 시작한다. 소스 PostgreSQL에서 `top`·`iostat`·`pg_stat_activity`로 부하가 거의 없음을 보이고, 데이터가 대부분 메모리에서 흐르므로 12GB를 옮기는 데 소스 스토리지를 약 168KB만 쓴다는 점을 강조한다. 두 테이블(각 약 6GB, 8천만 행)이 타깃 RDS로 초당 80~85MB로 이동한다.

모범 사례로는 사전 마이그레이션 평가(미지원 타입·non-nullable LOB 타깃·PK 없는 CDC 테이블 점검)와 데이터 검증(Full Load 1패스, CDC는 약 3만 건 파티션 해시 비교, 커스텀 규칙)을 든다. 흔한 난제로 ① 인스턴스 사이징(메모리가 왕, freeable memory·swap 주시), ② 지원 역량 확인, ③ 네트워크 대역폭, ④ 대용량 객체(LOB), ⑤ 병렬화(멀티스레드로 Full Load를 이틀에서 3~4시간으로 단축), ⑥ 운영 우수성(모니터링·런북·SOP)을 짚는다. 끝으로 Glue 데이터 카탈로그 통합, S3 데이터 검증, PostgreSQL 15·MongoDB 파티셔닝·DocumentDB Elastic Clusters·Babelfish 타깃을 담은 DMS 3.5.1 을 소개하고 J.P. 모건의 인용으로 세션을 맺는다.