6R 마이그레이션 전략
전체 구조
노력 적음 ◄────────────────────────────────► 노력 많음
비용 절감 적음 ◄────────────────────────────► 비용 절감 많음
Retire → Retain → Rehost → Replatform → Repurchase → Refactor
Plain Text
복사
Retire (폐기)
마이그레이션 평가 중 더 이상 필요 없다고 판단
→ 그냥 삭제
→ 전체 포트폴리오의 10~20% 해당
Retain (유지)
지금 당장 마이그레이션하지 않음
→ 레거시 시스템, 마이그레이션 복잡도 너무 높음
→ 일단 그냥 둔다
Rehost(리호스트) = Lift & Shift
애플리케이션을 변경 없이 그대로 AWS로 이동
→ AWS MGN (Application Migration Service) 사용
→ 코드 변경 없음, 빠른 마이그레이션
→ 비용 절감 효과는 제한적
예시 : 온프레미스 EC2 → AWS EC2 동일 사양
Replatform (리플랫폼) = Lift, Tinker & Shift
핵심 아키텍처는 유지하되 일부 최적화
→ 코드 변경 최소화, 클라우드 이점 일부 활용
예시:
•
온프레미스 MySQL → RDS MySQL (관리형으로 전환)
•
Self-managed Tomcat → Elastic Beanstalk
•
온프레미스 DB → Aurora Serverless
Repurchase (재구매)
기존 라이선스 소프트웨어 → SaaS로 전환
→ 기존 앱 버리고 새 제품 구매
예시:
•
자체 CRM → Salesforce
•
자체 HR → Workday
•
자체 이메일 → Microsoft 365
Refactor / Re-architect (리팩터)
애플리케이션을 클라우드 네이티브로 완전 재설계
→ 가장 많은 노력, 가장 큰 비용 절감•확장성
예시:
•
모놀리식 앱 → 마이크로서비스 + Lambda
•
온프레미스 DB → DynamoDB
•
EC2 기반 → 컨테이너(ECS/EKS) + Fargate
비즈니스 드라이버:
•
강력한 확장성 필요
•
기능 추가 속도 향상 필요
•
비용 대폭 절감 필요
키워드 | 6R 전략 |
사용 안 함 | Retire |
당장 이전 불필요 | Retain |
변경 없이 빠르게 이전 | Rehost |
DB만 관리형으로 전환 | Replatform |
SaaS로 전환 | Repurchase |
마이크로서비스, 서버리스로 재설계 | Refactor |
마이그레이션 서비스
AWS MGN vs AWS DRS
AWS MGN (Application Migration Service) | AWS DRS (Elastic Disaster Recovery) | |
목적 | 마이그레이션 (한 번 이동, 영구 전환) | 재해복구 (지속적 보호) |
방식 | 블록 레벨 복제 → 테스트 → 컷오버 | 블록 레벨 복제 (지속) → 장애 시 Failover |
소스 | 온프레미스, 타 클라우드 → AWS | 온프레미스, EC2 모두 |
6R 연결 | Rehost 전략의 표준 도구 | DR 구성, Rehost 후 DR 보호에 활용 |
•
핵심 구분:
◦
이사 갈 때 → MGN (이사 후 원래 집 비움)
◦
대피 준비 → DRS (항상 복사본 유지)
AWS Migration Hub
•
여러 마이그레이션 도구의 진행 상황을 단일 대시보드에서 추적
◦
MGN, DMS, SMS 등의 진행률 통합 모니터링
◦
마이그레이션 완료 여부 중앙 확인
◦
애플리케이션별 그룹핑 가능
•
Migration Hub Orchestrator
◦
마이그레이션 워크플로우 자동화
◦
단계별 진행 상황 관리
AWS DMS + SCT
AWS DMS (Database Migration Service)
데이터베이스를 AWS로 마이그레이션
•
지원 소스: Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, MariaDB, SAP 등
•
마이그레이션 유형
◦
동종 마이그레이션 (Homogeneous)
▪
Oracle → Oracle RDS
▪
MySQL → RDS MySQL
→ SCT 불필요
◦
이종 마이그레이션 (Heterogeneous)
▪
Oracle → Aurora PostgreSQL
▪
SQL Server → MySQL RDS
→ SCT로 스키마 변환 필수
•
CDC (Change Data Capture)
◦
마이그레이션 중 소스 DB 변경사항을 실시간으로 동기화
→ 다운타임 최소화 마이그레이션
→ 초기 로드 + 지속적 복제 동시 진행
AWS SCT (Schema Conversion Tool)
•
이종 DB 마이그레이션 시 스키마 자동 변환
◦
Oracle Procedure → PostgreSQL 함수
◦
SQL Server T-SQL → Aurora MySQL SQL
•
SCT 변환 불가 항목:
◦
수동 변환 필요 (복잡한 Procedure, 커스텀 함수)
◦
SCT 리포트에서 변환 복잡도 확인 가능
DMS Migration Flow
온프레미스 Oracle DB
│
├─① SCT: 스키마 변환 (Oracle → Aurora PostgreSQL)
│
├─② DMS 초기 전체 로드 (Full Load)
│ → 전체 데이터 복사
│
├─③ DMS CDC 활성화
│ → 소스 DB 변경사항 실시간 동기화
│
├─④ 애플리케이션 테스트
│
└─⑤ 컷오버 (소스 DB 중단 → 대상 DB로 전환)
→ 다운타임: 수 분
Plain Text
복사
다운타임 최소 DB 마이그레이션 → DMS + CDC
Oracle → Aurora 스키마 변환 → SCT 먼저 + DMS
동종 DB 마이그레이션 → DMS (SCT 불필요)
마이그레이션 진행률 중앙 관리 → Migration Hub
데이터 전송 서비스 비교
DataSync | Transfer Family | Storage Gateway | Snow Family |
온라인 대량
데이터 이전 | 표준 프로토콜
파일 전송 (SFTP) | 하이브리드 스토리지
(온프레미스  AWS) | 오프라인 대량
물리 디바이스 |
AWS DataSync
AWS DataSync는 온프레미스 스토리지 시스템과 AWS 스토리지 서비스 간에 대량 데이터를 빠르고 안전하게 자동으로 이동하는 데 사용한다. 기존 스토리지 시스템(NAS 등)이나 변경 불가한 장비(DNA 시퀀서, 비디오 카메라 등)에서 데이터를 전송하거나 여러 목적지가 필요한 경우 DataSync를 사용한다.
•
DataSync 핵심
◦
온프레미스 NAS/SAN → S3, EFS, FSx 고속 전송
◦
클라우드 간 전송 (S3 → S3 크로스 리전)
◦
다른 클라우드 (GCS, Azure) → AWS 전송 가능
◦
자동 데이터 무결성 검증
◦
증분 전송 지원 (변경된 파일만)
◦
스케줄 설정 가능 (최소 1시간 간격)
AWS Transfer Family
SFTP, FTPS, FTP, AS2 프로토콜을 AWS에서 관리형으로 제공
→ S3 또는 EFS를 백엔드로 사용
•
사용 사례:
◦
파트너사가 SFTP로 파일 업로드
◦
기존 FTP 워크플로우를 AWS로 이전
◦
B2B 파일 교환
•
DayaSync vs Transfer Family
◦
대량 데이터 빠른 이전 → DataSync
◦
파트너사 SFTP 파일 교환 → Transfer Family
AWS Storage Gateway
온프레미스 앱이 AWS 스토리지를 로컬처럼 사용하는 하이브리드 서비스
•
3가지 타입
1.
S3 File Gateway
•
NFS/SMB 프로토콜로 S3에 파일 저장
•
자주 접근하는 파일 로컬 캐시
→ 온프레미스 앱이 S3를 로컬 드라이브처럼 사용
2.
Volume Gateway (Cached/Stored)
•
iSCSI 블록 스토리지
•
Cached: 자주 쓰는 데이터 로컬 캐시 + 전체 S3 저장
•
Stored: 전체 로컬 저장 + S3 백업
3.
Tape Gateway
•
물리 테이프 라이브러리를 S3/Glacier로 교체
•
기존 백업 소프트웨어 호환
•
DataSync vs Storage Gateway
◦
DataSync → 데이터 “이동” (일회성 or 정기 배치)
◦
Storage Gateway → 데이터 “접근” (지속적 하이브리드 연결)
“온프레미스 앱이 S3를 로컬처럼 사용” → Storage Gateway (File)
“물리 테이프 백업 → 클라우드로“ → Tape Gateway
“대량 데이터 S3로 빠르게 이전” → DataSync
“파트너사 SFTP 연동” → Transfer Family
“초기 마이그레이션 후 지속 접근” → DataSync(초기) + Storage Gateway(지속)
AWS Snow Family
인터넷으로 전송하기 너무 큰 데이터 → 물리 디바이스 사용
•
Snowcone: 8TB HDD / 14TB SSD, 소형, IoT 환경
•
Snowball Edge: 80TB~210TB, 엣지 컴퓨팅 가능
•
Snowmobile: 최대 100PB, 트럭 크기
•
선택 기준:
◦
데이터 크기로 판단
◦
일반적으로 10TB 이상이면 Snowball 고려
◦
100PB 이상 → Snowmobile
VMware Cloud on AWS
•
온프레미스 VMware 환경을 AWS에서 그대로 실행
→ vSphere, vSAN, NSX를 AWS 베어메탈 위에서 운영
→ 코드/프로세스 변경 없이 VMware 워크로드 클라우드로
•
사용 사례
◦
VMware 라이선스 만료 + 빠른 클라우드 이전
◦
DC 퇴출 (Data Center Exit) 가속
◦
온프레미스 AWS 간 VM 실시간 마이그레이션 (vMotion)
AWS 간 VM 실시간 마이그레이션 (vMotion)Summary
개념 | 한 줄 요약 |
Rehost | 변경 없이 그대로 이전. MGN 사용. Lift & Shift |
Replatform | 핵심 유지 + 관리형 서비스로 교체. RDS, Beanstalk |
Repurchase | SaaS로 전환. Salesforce, Workday |
Refactor | 클라우드 네이티브 재설계. 마이크로서비스, Lambda |
MGN | 서버 마이그레이션 (영구 이전). 블록 레벨 복제 |
DRS | 재해복구 (지속적 보호). Pilot Light 방식 |
DMS | DB 마이그레이션. CDC로 다운타임 최소화 |
SCT | 이종 DB 스키마 변환. DMS와 함께 사용 |
DataSync | 대량 데이터 고속 이전. 무결성 검증. 증분 지원 |
Transfer Family | SFTP/FTP 파트너사 파일 교환 |
Storage Gateway File | NFS/SMB로 S3 로컬처럼 사용. 하이브리드 |
Tape Gateway | 물리 테이프 → S3/Glacier 교체 |
Snow Family | 오프라인 대량 이전. 10TB+ 고려 |
Migration Hub | 마이그레이션 진행률 중앙 대시보드 |
VMware Cloud on AWS | VMware 환경 그대로 AWS에서 실행 |
이전 게시물
