AWS DMS Cross-Region 마이그레이션 실습_ [ AWS ]

 

서론

AWS를 처음 접해본 사람으로서 천천히 교재와 수업자료를 비교해가며 따라가본다.
물리적으로 떨어진 두 리전 간의 데이터를 안전하게 옮기는 것,
수작업으로 데이터를 백업하고 복원하는 번거로움 대신 AWS DMS 라는 기능을 활용하여 
기술 변화의 혁신을 알아보았다.

본 포스팅에서는 AWS의 EC2(IaaS) 환경에서 운영 중이던 MariaDB 데이터를, 운영 편의성이 높은 Amazon RDS(PaaS) 환경으로 마이그레이션하는 과정을 다룬다. 특히 AWS DMS를 활용하여 인프라 구축부터 데이터 복제, 정합성 검증까지의 과정을 엔지니어링 관점에서 기록했다.

 

목표

도쿄 리전에 구축된 DB를 서울 리전의 관리형 DB(RDS)로 이관.
서로 다른 리전 간의 네트워크 및 보안 그룹 구성.
AWS DMS의 3요소 ( 복제 인스턴스 , 엔드포인트, 태스크 ) 를 활용한 마이그레이션 파이프라인 구축.
데이터 유실 없이 원본 데이터가 타켓 DB로 완벽하게 복제되었는지 검증해보자.

 

 

AWS DMS *Database Migration Service

 

관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 등 다양한 유형의 데이터 저장소를 쉽고 안전하게 마이그레이션하도록 돕는 AWS의 관리형 서비스.

 

마이그레이션 중에도 소스 데이터베이스를 계속 사용할 수 있어 애플리케이션 가동 중단 시간을 최소화할 수 있다.

 

AWS DMS를 선택하는 이유

1. 강력한 보안 (Security)

• IAM 권한 관리, SSL/TLS 암호화, AWS Secrets Manager를 연동하여 마이그레이션 전 과정에서 데이터를 철저하게 보호한다.

2. 최소한의 다운타임 (Minimal Downtime)

• 데이터가 이동하는 동안에도 소스 시스템(원본 DB)을 정상적으로 운영할 수 있어, 서비스 중단을 최소화할 수 있다.

3. 데이터 무결성 및 복원력 (Integrity & Resiliency)

• 다중 AZ(Multi-AZ) 이중화와 체크포인트 복구 기능을 통해 장애 발생 시에도 안정적.
• 데이터 검증(Validation) 프로세스를 통해 데이터 손실을 방지하고 불일치를 자동으로 해결.

4. 비용 효율성 (Cost-Efficiency)

• 사용한 만큼만 지불하는 시간당 요금제와, 불필요한 용량을 줄여주는 서버리스(Serverless) 확장을 통해 비용을 절감할 수 있다.

 

 

1. 도쿄 지역 인스턴스 생성 (소스 데이터베이스 준비)

 

 

 

보안그룹은 도쿄 리전에 3개를 추가해서 적용시켜주자.

인스턴스 유형은 t3.micro로 설정해보자.

vpc는 기본으로 선택.

서브넷은 위 그림과 똑같이 선택한다.

 

1-1 도쿄 지역 인스턴스 연결 후 mysql 작업

 

도쿄지역 연결 후

sudo dnf install mariadb105-server -y -> 설치
sudo systemctl start mariadb -> 실행
mysql -> 접속

 

mysql 접속.

접속 후 간단한 DB 랑 테이블 list 만들어보자.

 

예시

 

MariaDB [(none)]> CREATE DATABASE mproject;
MariaDB [(none)]> use mproject;
MariaDB [mproject]> CREATE TABLE list (
    -> Name VARCHAR(10),
    -> Number INT PRIMARY KEY NOT NULL,
    -> Date DATE );
    
    MariaDB [mproject]> DESC list;  -> 생성된 테이블 리스트 확인해보자.

 

생성된 테이블 리스트에 값을 넣어주자.

 

MariaDB [mproject]> INSERT INTO list VALUES ('Kim', 546245, '2026-01-13');
MariaDB [mproject]> INSERT INTO list VALUES ('Lee', 567336, '2026-02-15');

MariaDB [mproject]> SELECT * FROM list; -> 설정 확인해보자

 

 

1-2 도쿄 인스턴스 안에서 만든 mysql을 퍼블릭 아이피로 접속

새로운 데이터베이스 사용자를 만들고, 사용자에게 권한을 부여한 뒤, 외부에서 접속 해보자.

MariaDB [mproject]> CREATE USER dmsuser@'%' IDENTIFIED BY '1234';
MariaDB [mproject]> GRANT ALL ON mproject.* TO dmsuser@'%';

 

 

 

 

2. 서울 리전에서 RDS 생성 (타켓 데이터베이스 생성)

서브넷 그룹 , 파라미터 그룹, 옵션그룹 생성해준다.

가용영역은 퍼블릭으로 2개 선택해준다.

 

2-1 데이터 베이스 생성

보안그룹 RDS 생성 

첨부한 스크린샷과 같이 설정을 하자.

퍼블릭 액세스 선택 '예'로 설정.

자격증명관리 '자체관리'

템플릿은 프리티어가 없으면 샌드박스로 해서 설정하자.

 

조금 기다리면 생성 완료가 된다.

 

 

 

3. DMS 생성

데이터를 최종적으로 전송받을 목적지인 서울 리전에서 생성.

 

3-1 데이터를 실어나르는 '트럭' 역할을 하는 "복제 인스턴스"를 서울 리전에서 배치해서 도쿄의 데이터를 서울로 끌어오는 구조를 만든다.

DMS 복제 인스턴스가 서울의 어느 네트워크를 사용할지 지정하기 위해 서브넷 그룹을 먼저 만들어야 된다.

 

3-2 소스 엔드포인트 등록 ( 도쿄 EC2의 퍼블릭 IP와 접속 정보를 입력. 데이터를 가져올 곳을 등록 )

캡쳐화면에 없는 정보들은 디폴트로 두는데

하단부분 SSL은 없음으로 체크하자.

 

3-3 대상 엔드포인트 생성 ( 서울 RDS의 정보를 입력하여 데이터 넣을 곳을 등록 )

서버이름에는 서울  RDS 엔드포인트 주소정보를 넣어주자.

 

3-4 복제 인스턴스 생성 (데이터를 실제로 실어 나르는 가상 컴퓨터를 구축하는 작업)

복제 인스턴스는 생성하는데 시간이 좀 걸린다. 참고하자!

 

 

3-5 복제 인스턴스 생성 완료 확인 후 태스크 생성. (DMS 위치)

 

태스크 로드 완료 확인.

 

 

 

4. 데이터 확인을 위해 리눅스 서버 A에서 서울 RDS 엔드포인트로 접속 시도.

RDS 엔드포인트로 접속.

 

리눅스 서버 A 접속 후 엔드포인트로 접속.

mysql -h [ 엔드포인트 주소 ] -p -u admin

 

 

데이터 조회를 해본다. ( 도쿄 리전에서 넣었던 데이터인 'kim' 'Lee' 행이 그대로 조회되는 것을 확인한다 )

 

 

결론

도쿄지점에서 장부를 작성하고(DB 설정)

서울본사에서 새 금고를 마련한 뒤(RDS 설정)

장부를 실어 나를 특수 운반 트럭( DMS 복제 인스턴스) 과 양쪽 지점의 약도(엔드포인트)를 준비해서

사고 없이 안전하게 장부를 운반(태스크 실행) 해 온 것이다.

 

이번 실습을 통해서 도쿄 리전의 EC2 기반 데이터베이스를 서울리전의 RDS로 성공적으로 이관해보았다.

DMS를 활용한 이번 실습은 단순한 데이터 이동을 넘어 다음과 같은 의의를 가진다.

 

1. 관리 포인트의 최소화. 기존 EC2 환경에서는 OS와 DB를 직접 관리해야 했으나, 완전 관리형 서비스인 RDS로 전환함으로써

백업, 보안패치, 스케일링과 같은 운영 리소스를 AWS에 위임하여 비즈니스 로직에 더 집중할 수 있는 환경을 마련했다.

 

2. 물리적 거리를 극복한 서비스 성능 최적화. 기존에는 데이터가 도쿄에 있어 한국 사용자가 접속할 때마다 물리적인 지연 시간이 발생했다. 이번 실습을 통해 데이터를 주 사용자가 위치한 서울 리전으로 이관함으로써, 네트워크 거리를 단축시켜 로딩 속도를 개선하고 사용자 경험을 향상시킬 수 있는 환경을 구축했다.