.png){kind=small}
안녕하세요. 온프레미스에서 클라우드로 넘어가거나, 혹은 데이터를 분석용으로 따로 빼고 싶을 때 가장 고민되는 것이 바로 **"데이터베이스 마이그레이션"**입니다. 서비스 중단 시간을 최소화하면서 대용량 데이터를 어떻게 옮길까요?
이때 사용하는 AWS의 강력한 도구가 바로 **AWS DMS(Database Migration Service)**입니다. 오늘은 DMS의 핵심 개념과 함께, EC2(MariaDB)에 있는 데이터를 S3로 실시간 적재하는 실습 과정을 단계별로 알아보겠습니다.
1. AWS DMS란 무엇인가요?
AWS DMS는 관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 등 다양한 데이터 저장소 간에 데이터를 쉽게 마이그레이션하도록 돕는 관리형 서비스입니다.
핵심 특징
최소한의 다운타임: 데이터를 옮기는 동안에도 원본 DB는 정상 운영 가능합니다.
동종/이종 마이그레이션: MySQL → MySQL은 물론, Oracle → PostgreSQL 같은 이종 간 이동도 지원합니다.
지속적 복제(CDC): 단순히 한 번 옮기고 끝나는 게 아니라, 변경된 데이터(INSERT/UPDATE/DELETE)를 실시간으로 타겟에 반영할 수 있습니다 .
2. 실습 시나리오: EC2(MariaDB) → S3 데이터 파이프라인 구축
프라이빗 환경에서 DB 데이터를 S3로 옮기는 과정을 구성해 보겠습니다.
아키텍처 구성
Source: VPC 내부 EC2에 설치된 MariaDB (Table: employees)
Target: S3 Bucket (데이터 레이크 용도)
Middleware: AWS DMS (데이터 중계자)
Network: 보안을 위해 인터넷을 타지 않는 Private Network 구성 (S3 Gateway Endpoint 활용)
3. 단계별 구축 가이드
Step 1. S3 버킷(Target) 준비 및 권한 설정
가장 먼저 데이터가 쌓일 S3 버킷을 생성하고, DMS가 이 버킷에 데이터를 쓰고 지울 수 있도록 권한을 줘야 합니다.
버킷 생성: 원하는 이름(예: dms-test-bucket-01)으로 생성합니다 .
IAM Role 생성: DMS가 S3에 접근할 수 있는 IAM Role을 만듭니다. 필수 권한은 다음과 같습니다.
s3:PutObject (데이터 저장)
s3:DeleteObject (데이터 삭제 - 로드 전 정리용)
s3:GetObject 등 .
버킷 정책(Bucket Policy) 설정: 위에서 만든 IAM Role만 이 버킷에 접근할 수 있도록 정책을 설정합니다 .
Tip: 프라이빗 환경에서 S3에 접속하려면 VPC에 S3 Gateway Endpoint가 반드시 있어야 합니다.
Step 2. DMS 복제 인스턴스 생성
데이터를 퍼 나르는 일꾼인 '복제 인스턴스(Replication Instance)'를 만듭니다.
서브넷 그룹 생성: DMS가 위치할 VPC와 서브넷(Private Subnet 권장)을 지정합니다 .
복제 인스턴스 생성:
인스턴스 클래스: dms.t3.medium (테스트용으로 적합).
Multi-AZ: 운영 환경이면 '예', 테스트면 '아니요' .
퍼블릭 액세스: 비활성화 (보안을 위해 Private IP만 할당).
Step 3. 엔드포인트(Endpoint) 연결
DMS에게 "어디서 가져와서(Source), 어디로 보낼지(Target)"를 알려줍니다.
Source Endpoint (MariaDB):
서버 이름: EC2의 Private IP.
포트: 3306.
자격 증명: DB ID/PW 입력 .
Target Endpoint (S3):
대상 엔진: Amazon S3.
버킷 폴더: s3://bucket_name/prefix.
IAM Role: Step 1에서 만든 Role의 ARN 입력.
Step 4. 마이그레이션 태스크(Task) 생성 및 실행
이제 실제로 데이터를 옮기는 작업을 정의합니다.
마이그레이션 유형 선택:
기존 데이터 마이그레이션: 현재 있는 데이터만 옮김.
데이터 마이그레이션 및 변경 사항 복제 (CDC): 현재 데이터 + 앞으로 들어올 데이터까지 계속 실시간 동기화 . <- 이번 실습 권장 사항
테이블 매핑: demo 스키마의 employees 테이블만 옮기도록 필터링합니다 .
태스크 시작: 태스크를 실행하면 로드 상태가 100%가 되고, S3 버킷에 CSV 파일 형태로 데이터가 생성된 것을 확인할 수 있습니다.
Step 5. 데이터 검증 (CDC 테스트)
실시간 동기화가 잘 되는지 확인해 봅니다.
MariaDB에서 INSERT나 UPDATE 쿼리를 날려 데이터를 변경합니다 .
S3 버킷을 확인해보면 변경된 데이터에 대한 파일(LOAD000...csv 등)이 추가로 생성된 것을 볼 수 있습니다.
4. 실제 업무에서는 이렇게 씁니다 (Use Cases)
DMS는 단순히 DB 이사뿐만 아니라 다양한 데이터 파이프라인 구축에 활용됩니다.
① 무중단 DB 마이그레이션 (On-Premise → AWS)
가장 전통적인 용도입니다. 서비스 중단 없이 온프레미스 오라클 DB를 AWS RDS(Aurora 등)로 옮길 때 사용합니다. 초기 적재(Full Load) 후 CDC를 걸어두고, 데이터가 싱크되면 DNS를 스위칭하여 다운타임을 최소화합니다.
② 데이터 레이크(Data Lake) 구축 (DB → S3)
실습에서 한 내용입니다. 운영 DB(OLTP)에 분석 쿼리를 날리면 서비스가 느려지겠죠? DMS로 데이터를 실시간으로 S3에 적재한 뒤, Athena나 Redshift를 이용해 분석 작업을 수행합니다. 운영 DB 부하를 줄이는 핵심 패턴입니다.
③ 이기종 DB 간 데이터 동기화 (MSA 환경)
마이크로서비스 아키텍처(MSA)에서, 결제 서비스(MySQL)의 데이터가 변경되면 주문 서비스(DynamoDB)에도 반영해야 할 때가 있습니다. DMS를 이용해 이기종 DB 간 데이터를 실시간으로 동기화할 수 있습니다.
5. 핵심 요약 & 주의사항
보안 그룹(SG): 복제 인스턴스는 Source(EC2)와 Target(S3 Endpoint) 양쪽에 모두 접근 가능해야 합니다.
S3 Gateway Endpoint: Private Subnet에 있는 DMS가 S3에 접근하려면 필수입니다.
IAM 권한: Target이 S3인 경우 DeleteObject 권한이 없으면 태스크가 실패할 수 있으니 꼼꼼히 챙겨야 합니다.
DMS는 AWS 데이터 생태계의 혈관과도 같은 서비스입니다. 이 가이드를 통해 데이터 파이프라인 구축의 첫걸음을 떼보시기 바랍니다!
