LLM WikiAccess-protected knowledge portal
← 스터디 홈
5편 · 약 26분

클라우드 DB 마이그레이션: 온프레미스→클라우드 이관 전략과 실행

왜 이관 전략이 중요한가

데이터베이스 이관은 단순한 데이터 복사가 아니다. 잘못된 순서 하나가 수십 분의 서비스 중단, 데이터 불일치, 예상 밖의 롤백으로 이어질 수 있다. 온프레미스 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) 모두 지원한다.

AWS DMS 이관 파이프라인 온프레미스 소스 Source DB MySQL / Oracle / MSSQL binlog / redo log CDC 소스 DMS Source Endpoint 설정 SCT (Schema 변환) DMS Schema Conversion 자동 변환: 최대 90% 수동 변환 필요: 프로시저, 패키지, 함수 DMS 복제 인스턴스 Full Load 페이즈 ↓ CDC (변경 사항 지속 반영) AWS 클라우드 타겟 Amazon RDS MySQL / PostgreSQL Amazon Aurora MySQL / PostgreSQL DMS Target Endpoint Full Load 완료 → CDC 지속 반영 DMS 데이터 검증 row count, checksum, 불일치 row 탐지 ValidationSuspended / ValidationFailed 알림 평가 리포트 → S3 저장 (자동 변환 불가 항목 목록)
AWS DMS 이관 아키텍처

DMS 주요 단계

  1. 평가 리포트 생성: 소스 DB에 연결하여 스키마를 읽고, 자동 변환 가능/불가 항목 목록을 S3에 저장.
  2. Schema Conversion: 테이블, 뷰, 인덱스, 데이터 타입은 대부분 자동 변환. 저장 프로시저, 패키지, 트리거는 수동 검토 필요.
  3. Full Load: 소스 DB의 현재 스냅샷을 타겟으로 초기 적재. 대용량(수십 TB)은 S3 경유 적재를 권장.
  4. CDC (Change Data Capture): Full Load 완료 후, 소스 binlog/redo log를 읽어 타겟에 지속 반영. 이 단계가 길어질수록 cutover 시 lag이 줄어든다.

동종 이관 vs 이기종 이관

구분동종 이관이기종 이관
예시MySQL → RDS MySQLOracle → 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는 이기종 이관에서 설정이 복잡할 수 있다.

이관 흔한 실수

  1. 스테이징 드라이런 생략: 프로덕션에서 처음 실행하면 예상치 못한 파라미터 차이나 네트워크 지연이 발각된다.
  2. 저장 프로시저·함수 미검증: 자동 변환 90% 완료 후 나머지 10%를 방치하면 기능 장애로 나타난다.
  3. Cutover lag 과소 추정: CDC lag = 0에 도달하는 시간을 과소 추정하여 Cutover 윈도우 초과.
  4. 롤백 절차 미테스트: 롤백이 필요할 때 처음 시도하면 실패한다.
  5. 타겟 인덱스 설정 지연: 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