왜 이관 전략이 중요한가
데이터베이스 이관은 단순한 데이터 복사가 아니다. 잘못된 순서 하나가 수십 분의 서비스 중단, 데이터 불일치, 예상 밖의 롤백으로 이어질 수 있다. 온프레미스 MySQL 5.7을 RDS Aurora MySQL 8.0으로 이관하든, Oracle을 PostgreSQL로 옮기든, 전략 선택과 사전 검증이 실제 작업보다 더 많은 시간을 차지한다.
이 장은 이관 유형 선택부터 AWS DMS 실무, 무중단 전환(cutover), 검증, 롤백 플랜까지 DBA가 실제 이관 작업에서 맞닥뜨리는 결정 지점을 다룬다.
이관 전략 3가지
1. Lift-and-Shift (재호스팅)
동일 DB 엔진, 동일 버전을 클라우드 인스턴스로 그대로 옮긴다. 스키마 변경 없음. 위험 최소, 속도 최대.
- 적합: 빠른 데이터센터 탈출, 레거시 시스템, 스키마 변경 여력 없을 때.
- 단점: 클라우드 이점(매니지드 HA, 자동 패치 등)을 완전히 활용하지 못한다.
2. Re-platform (엔진 유지, 관리 방식 전환)
동일 DB 엔진이지만 매니지드 서비스로 전환한다. MySQL → RDS MySQL, PostgreSQL → Cloud SQL PostgreSQL.
- 적합: 운영 부담 감소가 목표이고 애플리케이션 코드 변경을 최소화해야 할 때.
- 주의: 스토리지 구조(RDS EBS vs Aurora 클러스터 볼륨), 파라미터 차이, 시스템 계정 제한을 반드시 사전 확인.
3. Re-architect (이기종 DB 전환)
Oracle → PostgreSQL, MySQL → Aurora PostgreSQL처럼 엔진 자체를 바꾼다. 스키마 변환, 저장 프로시저·함수 재작성, 드라이버 교체, 애플리케이션 수정이 함께 필요하다.
- 적합: 라이선스 비용 절감(Oracle), 클라우드 네이티브 기능 활용.
- 단점: 가장 복잡하고 기간이 길다. 자동 변환 90% + 수동 10% 공식으로 접근해야 한다.
AWS DMS 아키텍처
AWS Database Migration Service(DMS)는 클라우드 이관에서 가장 널리 쓰이는 도구다. 동종 이관(MySQL → MySQL)과 이기종 이관(Oracle → PostgreSQL) 모두 지원한다.
DMS 주요 단계
- 평가 리포트 생성: 소스 DB에 연결하여 스키마를 읽고, 자동 변환 가능/불가 항목 목록을 S3에 저장.
- Schema Conversion: 테이블, 뷰, 인덱스, 데이터 타입은 대부분 자동 변환. 저장 프로시저, 패키지, 트리거는 수동 검토 필요.
- Full Load: 소스 DB의 현재 스냅샷을 타겟으로 초기 적재. 대용량(수십 TB)은 S3 경유 적재를 권장.
- CDC (Change Data Capture): Full Load 완료 후, 소스 binlog/redo log를 읽어 타겟에 지속 반영. 이 단계가 길어질수록 cutover 시 lag이 줄어든다.
동종 이관 vs 이기종 이관
| 구분 | 동종 이관 | 이기종 이관 |
|---|---|---|
| 예시 | MySQL → RDS MySQL | Oracle → Aurora PostgreSQL |
| 스키마 변환 | 최소 (엔진 차이만) | SCT 필수 (함수·타입 차이) |
| 저장 프로시저 | 대체로 그대로 작동 | 재작성 필요 (PL/SQL → PL/pgSQL) |
| 애플리케이션 변경 | 연결 문자열 수준 | 드라이버·쿼리 방언 수정 |
| 이관 난이도 | 낮음 | 높음 |
| 권장 접근 | DMS 단독 충분 | SCT + DMS + 대규모 테스트 |
무중단 이관 패턴
패턴 1: Flash-Cut (CDC 기반 전환)
가장 일반적인 방법이다. CDC로 타겟을 소스에 최대한 근접시킨 뒤 짧은 쓰기 중단 후 전환한다.
[Phase 1] Full Load: 소스 → 타겟 (시간 소요)
[Phase 2] CDC: 소스 변경사항 지속 반영 (lag 모니터링)
[Phase 3] Cutover:
1. 소스 DB 쓰기 차단 (유지보수 모드 또는 권한 제거)
2. CDC lag = 0 확인 (타겟이 소스와 완전히 동기화)
3. 데이터 검증 (row count, 핵심 테이블 체크섬)
4. 애플리케이션 연결 문자열 교체
5. 소스 DB 쓰기 재개 → 타겟만 서빙
[Phase 4] 소스 DB는 읽기 전용으로 일정 기간 유지 (롤백용)목표 downtime: 수십 초~수 분 (lag 제거 시간 포함).
패턴 2: Blue-Green Deployment
소스(Blue)와 타겟(Green)을 병렬 운영하면서 트래픽을 점진적으로 전환한다. RDS Blue/Green Deployments 기능을 활용하면 이 패턴을 관리형으로 실행할 수 있다.
Blue (현재 프로덕션) ←← 읽기 트래픽 일부를 Green으로 이동
Green (새 타겟) ←← 점진적으로 쓰기 트래픽 전환
→ 문제 없으면 Blue를 폐기RDS Blue/Green 전환은 1분 내외 downtime으로 완료된다. 단 Aurora Global Database를 사용하는 경우 Blue/Green 기능이 제한된다.
패턴 3: Active-Active (양방향 복제)
전환 중 양쪽 DB에 쓰기를 허용하고, 충돌 해결 전략을 사전에 정의한다. 복잡도가 높아 특수한 경우(이관 중 서비스 중단 불가 요건)에만 사용한다.
Cutover 체크리스트
사전 준비:
[ ] 스테이징 환경에서 이관 전 과정 드라이런 완료
[ ] 롤백 시간(RTO) 측정 및 기준값 설정
[ ] 연결 재시도 로직 애플리케이션에 적용 확인
[ ] DNS 또는 연결 문자열 교체 절차 문서화
[ ] DMS 검증 보고서 확인 (ValidationFailed 없음)
Cutover 당일:
[ ] 비즈니스 영향 최소 시간대 선택 (새벽, 주말)
[ ] 소스 DB 쓰기 차단 전 트래픽 급감 확인
[ ] CDC lag → 0 확인 (DMS 대시보드 또는 binlog position)
[ ] 주요 테이블 row count 대조 (소스 vs 타겟)
[ ] 체크섬 불일치 테이블 없음 확인
[ ] 애플리케이션 연결 전환 → 기능 테스트
[ ] 모니터링 알림 임계값 활성화
전환 후:
[ ] 소스 DB 읽기 전용으로 유지 (최소 72시간)
[ ] 타겟 DB 슬로우 쿼리 모니터링
[ ] 소스 binlog 보존 정책 연장 (롤백 시 CDC 재개 가능하도록)대용량 이관 고려사항
Parallel Load
DMS는 테이블 단위 병렬 Full Load를 지원한다. 단일 복제 인스턴스의 CPU·메모리 한계 안에서 병렬 스레드를 조정해야 한다. 대형 테이블(수백 GB)은 세그먼트 방식(파티션 키 범위 분할)으로 병렬 처리한다.
S3 경유 Bulk Load
수십 TB 테이블은 DMS 직접 이관보다 S3 → LOAD DATA INFILE (MySQL) 또는 COPY (PostgreSQL) 방식이 빠를 수 있다. 데이터를 S3에 파티셔닝하여 내보낸 뒤 타겟에서 병렬 적재.
Replication Lag 관리
CDC 단계에서 소스 쓰기 처리량이 높으면 lag이 누적된다. 이관 전 소스 피크 쓰기 처리량을 측정하고, DMS 복제 인스턴스 사이즈를 그에 맞게 선택한다. r5.2xlarge 이상이 권장되는 고부하 이관에서.
검증 전략
단순 row count 일치만으로 이관 완료를 선언하면 안 된다. 다음 계층으로 검증한다.
| 검증 계층 | 방법 | 탐지 가능한 문제 |
|---|---|---|
| 구조 검증 | 스키마 diff 도구 | 누락 컬럼, 인덱스 불일치 |
| 수량 검증 | row count 대조 | 누락 행, 중복 행 |
| 내용 검증 | 체크섬 비교 | 데이터 변조, 인코딩 오류 |
| 기능 검증 | 애플리케이션 E2E 테스트 | 쿼리 방언 차이, 프로시저 오동작 |
| 성능 검증 | 실행계획 비교 | 엔진 차이로 인한 플랜 변화 |
DMS의 내장 데이터 검증(ValidationEnabled: true)은 row count와 체크섬을 자동 비교하고 불일치를 ValidationSuspended 또는 ValidationFailed로 표시한다.
롤백 플랜
이관 중 치명적 문제 발견 시 즉각 롤백할 수 있어야 한다.
롤백 시나리오:
1. Cutover 전 롤백: DMS 작업 중단 → 소스 DB 계속 사용 (무손실)
2. Cutover 직후 롤백 (72시간 이내):
- 소스 DB를 읽기 전용에서 쓰기 전용으로 복원
- 타겟에서 소스로 역방향 CDC 설정 (cutover 이후 변경사항 복원)
- 연결 문자열 원복
3. Cutover 후 장기 롤백: 타겟 스냅샷 기반 복원 → 수동 데이터 패치역방향 CDC(타겟 → 소스)를 미리 설정해 두면 롤백 시간을 대폭 단축할 수 있다. 단, 역방향 CDC는 이기종 이관에서 설정이 복잡할 수 있다.
이관 흔한 실수
- 스테이징 드라이런 생략: 프로덕션에서 처음 실행하면 예상치 못한 파라미터 차이나 네트워크 지연이 발각된다.
- 저장 프로시저·함수 미검증: 자동 변환 90% 완료 후 나머지 10%를 방치하면 기능 장애로 나타난다.
- Cutover lag 과소 추정: CDC lag = 0에 도달하는 시간을 과소 추정하여 Cutover 윈도우 초과.
- 롤백 절차 미테스트: 롤백이 필요할 때 처음 시도하면 실패한다.
- 타겟 인덱스 설정 지연: Full Load 후 인덱스를 생성하면 빠르지만, 인덱스 없는 상태로 운영이 시작되면 성능 장애.
References
- https://aws.amazon.com/dms/
- https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html
- https://docs.aws.amazon.com/dms/latest/userguide/CHAP_SchemaConversion.html
- https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/cut-over.html
- https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html
- https://mactores.com/blog/8-techniques-to-minimize-downtime-during-database-migration
- https://sedai.io/blog/aws-database-migration-service-guide
- https://newrelic.com/blog/infrastructure-monitoring/migrating-data-to-cloud-avoid-downtime-strategies
- https://medium.com/@jholt1055/how-i-migrated-a-25tb-production-database-with-zero-downtime-a-battle-tested-blueprint-a9883d65eeb3