기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 3단계: 마이그레이션
마이그레이션 계획을 완료하고 마이그레이션 전략을 파악한 후 실제 마이그레이션이 진행됩니다. 이 단계에서는 대상 데이터베이스를 설계하고, 원본 데이터를 대상으로 마이그레이션하고, 데이터를 검증합니다.
![\[Iterative migration process\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-database-migration/images/iterative-migration-process.png)
이는 변환, 마이그레이션 및 테스트의 여러 주기를 포함하는 반복 프로세스입니다. 기능 및 성능 테스트가 완료된 후 새 데이터베이스로 전환할 수 있습니다.
마이그레이션 단계는 다음 섹션에서 설명하는 주요 단계는 다음과 같습니다.
+ [스키마 변환](convert-schema.md)
+ [데이터 마이그레이션](migrate-data.md)
+ [애플리케이션 업데이트](update-app.md)
+ [마이그레이션 테스트](test-migration.md)
+ [새 데이터베이스로 전환](cut-over.md)
# 스키마 변환
데이터베이스 마이그레이션 중 주요 작업 중 하나는 원본 데이터베이스 엔진에서 대상 데이터베이스 엔진으로 스키마를 마이그레이션하는 것입니다. 리호스팅 또는 리플랫포밍을 해도 데이터베이스 엔진은 변경되지 않습니다. 이를 *동종 데이터베이스 마이그레이션이라고 하며, 기본 데이터베이스* 도구를 사용하여 스키마를 마이그레이션할 수 있습니다.
하지만 애플리케이션을 재설계하는 경우 스키마 변환에 더 많은 노력이 필요할 수 있습니다. 이 경우 원본 및 대상 데이터베이스 엔진이 *다른 이기종 데이터베이스 마이그레이션을* 수행하게 됩니다. 현재 데이터베이스 스키마가 대상 데이터베이스 엔진으로 직접 변환할 수 없는 패키지 및 기능을 사용하고 있을 수 있습니다. 일부 기능은 다른 이름으로 제공될 수 있습니다. 따라서 스키마를 변환하려면 원본 및 대상 데이터베이스 엔진을 잘 이해해야 합니다. 현재 스키마의 복잡성에 따라 이 작업이 어려울 수 있습니다.
AWS은(는) 스키마 변환에 도움이 되는 두 가지 리소스, 즉 AWS Schema Conversion Tool(AWS SCT) 및 마이그레이션 플레이북을 제공합니다.
## AWS SCT
AWS SCT은(는) 기존 데이터베이스를 한 엔진에서 다른 엔진으로 변환하는 데 도움이 되는 무료 도구입니다. AWS SCT은(는) Oracle, Microsoft SQL Server, MySQL, Sybase, IBM Db2 LUW 등 다양한 소스 데이터베이스를 지원합니다. Aurora MySQL 및 Aurora PostgreSQL과 같은 대상 데이터베이스 중에서 선택할 수 있습니다.
AWS SCT은(는) 소스 및 대상 데이터베이스에 직접 연결하여 현재 스키마 객체를 가져오는 그래픽 사용자 인터페이스를 제공합니다. 연결되면 데이터베이스 마이그레이션 평가 보고서를 생성하여 변환 작업과 조치 항목에 대한 높은 수준의 요약을 얻을 수 있습니다. 다음 화면 그림은 샘플 데이터베이스 마이그레이션 평가 보고서를 보여줍니다.
![\[Sample database migration assessment report from AWS SCT\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-database-migration/images/sct-assessment-report.png)
AWS SCT을(를) 사용하여 스키마를 변환하여 대상 데이터베이스에 직접 배포하거나 변환된 스키마의 SQL 파일을 가져올 수 있습니다. 자세한 내용은 AWS 문서의 [AWS Schema Conversion Tool 사용자 인터페이스 사용](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_UserInterface.html)을 참조하십시오.
## 마이그레이션 플레이북
AWS SCT은(는) 많은 소스 객체를 변환하지만 변환의 일부 측면에서는 수동 개입과 조정이 필요합니다. 이 작업을 돕기 위해 AWS에서는 두 데이터베이스 간의 비호환성 및 유사점을 자세히 설명하는 마이그레이션 플레이북을 제공합니다. 이러한 플레이북에 대한 자세한 내용은 AWS 웹 사이트의 [AWS Database Migration Service 리소스](https://aws.amazon.com/dms/resources/)를 참조하십시오.
# 데이터 마이그레이션
스키마 마이그레이션이 완료되면 데이터를 원본 데이터베이스에서 대상 데이터베이스로 이동할 수 있습니다. 응용 프로그램 가용성 요구 사항에 따라 원본 데이터를 새 데이터베이스에 한 번 복사하는 간단한 추출 작업을 실행할 수 있습니다. 또는 현재 데이터를 복사하고 새 데이터베이스로 전환할 준비가 될 때까지 모든 변경 내용을 계속 복제하는 도구를 사용할 수 있습니다. 리호스팅 및 리플랫포밍 마이그레이션의 경우 기본 데이터베이스 전용 도구를 사용하여 데이터를 마이그레이션하는 것이 좋습니다.
데이터 전송에 도움이 되는 도구로는 AWS Database Migration Service(AWS DMS) 및 오프라인 마이그레이션 도구가 있습니다. 이러한 정보는 다음 단원에 설명되어 있습니다.
## AWS DMS
AWS SCT을(를) 사용하여 원본 데이터베이스 엔진에서 대상 엔진으로 스키마 객체를 변환한 후 AWS DMS을(를) 사용하여 데이터를 마이그레이션할 수 있습니다. AWS DMS을(를) 사용하면 데이터가 복제되는 동안 원본 데이터베이스를 계속 가동하고 실행할 수 있습니다. 데이터를 한 번 복사하거나 연속 복제를 사용하여 복사할 수 있습니다. 원본 및 대상 데이터베이스가 동기화되면 데이터베이스를 오프라인으로 전환하고 작업을 대상 데이터베이스로 이동할 수 있습니다. AWS DMS은(는) 동종 데이터베이스 마이그레이션 (예: 온프레미스 Oracle 데이터베이스에서 Amazon RDS for Oracle 데이터베이스로) 및 이기종 마이그레이션 (예: 온프레미스 Oracle 데이터베이스에서 Amazon RDS for PostgreSQL 데이터베이스로) 에 사용할 수 있습니다. AWS DMS 사용에 대한 자세한 정보는 [AWS DMS 설명서](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html)를 참조하십시오.
## 오프라인 마이그레이션 옵션
또한 원본 데이터베이스에서 데이터를 추출하여 대상 데이터베이스로 로드하는 AWS DMS 방법 외에도 다른 옵션을 사용할 수 있습니다. 이러한 옵션은 데이터 마이그레이션 작업 중에 애플리케이션 다운타임이 허용되는 경우에 가장 적합합니다. 이러한 방법의 예는 다음과 같습니다.
+ 대상 데이터베이스에 로드된 원본 데이터베이스에서 CSV (쉼표로 분리된 값) 를 추출합니다.
+ 오라클 소스 데이터베이스의 경우 **ora2pg** 유틸리티를 사용하여 데이터를 PostgreSQL로 복사합니다.
+ 소스에서 타겟으로 데이터를 복사하기 위한 사용자 지정 ETL (추출, 변환, 로드) 작업
# 애플리케이션 업데이트
데이터베이스 마이그레이션은 데이터베이스 전용 마이그레이션은 거의 없습니다. 데이터베이스를 사용하는 애플리케이션을 살펴보고 새 데이터베이스에서 예상대로 작동하는지 확인해야 합니다. 동일한 데이터베이스 엔진을 단순히 리호스팅하거나 리플랫포밍하는 경우에는 변경 사항이 미미하지만 새 데이터베이스 엔진으로 전환하기로 결정하면 변경 사항이 더 중요할 수 있습니다.
응용 프로그램이 ORM(개체 관계형 매핑)을 사용하여 데이터베이스와 상호 작용하는 경우 새 데이터베이스 엔진으로 마이그레이션할 때 많은 변경이 필요하지 않습니다. 그러나 응용 프로그램에 사용자 지정 데이터베이스 상호 작용이 있거나 동적으로 작성된 SQL 쿼리가 있는 경우 변경 사항이 상당할 수 있습니다. 애플리케이션이 예상대로 작동하는지 확인하기 위해 수정해야 할 쿼리 형식이 다를 수 있습니다.
예를 들어, Oracle에서 문자열을 `NULL`(으)로 연결하면 원래 문자열이 반환됩니다. 그러나 PostgreSQL에서는 문자열을 `NULL`(으)로 연결하면 `NULL`이(가) 반환됩니다. 또 다른 예는 빈 문자열을 처리하는 방법입니다`NULL`. PostgreSQL에서 `NULL` 및 빈 문자열은 서로 다르지만 Oracle과 같은 데이터베이스는 동일한 방식으로 취급합니다. Oracle에서 열 값이 `NULL`(으)로 설정되거나 빈 문자열이 있는 행을 삽입하면 `where` 절을 사용하여 두 가지 유형의 값을 모두 가져올 수 있습니다. `where is NULL` PostgreSQL에서 `where` 이 절은 열 값이 실제로 NULL인 행 하나만 반환하고 빈 문자열 값이 있는 행은 반환하지 않습니다. 해당 차이점에 대한 자세한 내용은 [AWS Database Migration Service 리소스](https://aws.amazon.com/dms/resources/) 웹 페이지에 나열된 마이그레이션 플레이북을 참조하십시오.
# 마이그레이션 테스트
기능 및 성능 테스트는 데이터베이스 마이그레이션의 필수적인 부분입니다. 상세한 기능 테스트를 통해 애플리케이션이 새 데이터베이스에서 문제 없이 작동하는지 확인할 수 있습니다. 애플리케이션 워크플로를 테스트하기 위한 유닛 테스트를 개발하는 데 시간을 투자해야 합니다.
성능 테스트를 통해 데이터베이스 응답 시간이 허용 가능한 시간 범위 내에 있는지 확인할 수 있습니다. 병목 현상을 식별하고, 최적화하고, 성능 테스트를 반복할 수 있습니다. 사이클을 필요에 따라 반복하면 원하는 성능 결과를 얻을 수 있습니다.
테스트는 수동 또는 자동일 수 있습니다. 테스트에는 자동화된 프레임워크를 사용하는 것이 좋습니다. 마이그레이션 중에는 테스트를 여러 번 실행해야 하므로 자동화된 테스트 프레임워크를 사용하면 버그 수정 및 최적화 주기를 단축하는 데 도움이 됩니다.
이 테스트를 통해 개발 단계에서 놓친 문제를 찾아낼 수 있습니다. 예를 들어 잘못 변환된 쿼리는 실패하거나 잘못된 결과를 반환하여 기능 테스트가 실패하게 됩니다. 성능 테스트를 통해 인덱스 누락으로 인해 쿼리 응답 시간이 느려지는 등의 문제가 발견될 수 있습니다. 또한 워크로드에 따라 데이터베이스 엔진 튜닝이 필요하거나 쿼리를 수정해야 하는 성능 문제도 드러날 수 있습니다.
# 컷 오버
데이터베이스 전환 전략은 일반적으로 애플리케이션의 다운타임 요구 사항과 밀접하게 연관되어 있습니다. 데이터베이스 전환에 사용할 수 있는 전략에는 오프라인 마이그레이션, 플래시-컷 마이그레이션, 액티브/액티브 데이터베이스 구성, 증분 마이그레이션 등이 있습니다. 다음 단원에서 각각에 대해 살펴 봅니다.
## 오프라인 마이그레이션
쓰기 작업 중에 애플리케이션을 장기간 오프라인 상태로 전환할 수 있는 경우 AWS DMS 전체 로드 작업 설정이나 오프라인 마이그레이션 옵션 중 하나를 데이터 마이그레이션에 사용할 수 있습니다. 마이그레이션이 진행되는 동안 읽기 트래픽은 계속될 수 있지만 쓰기 트래픽은 중지해야 합니다. 원본 데이터베이스에서 모든 데이터를 복사해야 하므로 I/O 및 CPU와 같은 원본 데이터베이스 리소스가 사용됩니다.
크게 보면 오프라인 마이그레이션에는 다음과 같은 단계가 포함됩니다.
1. 스키마 변환을 완료하십시오.
1. 쓰기 트래픽의 다운타임을 시작합니다.
1. 오프라인 마이그레이션 옵션 중 하나를 사용하여 데이터를 마이그레이션합니다.
1. 데이터를 확인합니다.
1. 애플리케이션이 새 데이터베이스를 가리키도록 합니다.
1. 애플리케이션 다운타임을 종료하십시오.
## 플래시컷 마이그레이션
플래시컷 마이그레이션의 주요 목표는 다운타임을 최소화하는 것입니다. 이 전략은 원본 데이터베이스에서 대상 데이터베이스로의 CDC (연속 데이터 복제) 를 사용합니다. 데이터가 마이그레이션되는 동안 모든 읽기/쓰기 트래픽은 현재 데이터베이스에서 계속됩니다. 원본 데이터베이스에서 모든 데이터를 복사해야 하므로 I/O 및 CPU와 같은 원본 서버 리소스가 사용됩니다. 이 데이터 마이그레이션 활동이 애플리케이션 성능 SLA에 영향을 미치지 않는지 테스트해야 합니다.
상위 수준에서 플래시 컷 마이그레이션에는 다음 단계가 포함됩니다.
1. 스키마 변환을 완료하십시오.
1. 연속 데이터 복제 모드에서 AWS DMS을(를) 설정합니다.
1. 소스 데이터베이스와 대상 데이터베이스가 동기화되면 데이터를 확인합니다.
1. 애플리케이션 다운타임을 시작합니다.
1. 새 데이터베이스를 가리키는 새 버전의 애플리케이션을 출시합니다.
1. 애플리케이션 다운타임을 종료하십시오.
## 액티브/액티브 데이터베이스 구성
액티브/액티브 데이터베이스 구성에는 쓰기 트래픽에 두 데이터베이스를 모두 사용하는 동안 소스 및 대상 데이터베이스를 동기화하는 메커니즘을 설정하는 작업이 포함됩니다. 이 전략은 오프라인 또는 플래시컷 마이그레이션보다 더 많은 작업이 필요하지만 마이그레이션 중에도 더 많은 유연성을 제공합니다. 예를 들어 마이그레이션 중에 다운타임을 최소화하는 것 외에도 한 번에 전환을 수행하는 대신 작고 통제된 일괄 처리를 통해 프로덕션 트래픽을 새 데이터베이스로 이동할 수 있습니다. 이중 쓰기 작업을 수행하여 두 데이터베이스를 모두 변경하거나 [HVR](https://www.hvr-software.com/product/)과 같은 양방향 복제 도구를 사용하여 데이터베이스를 동기화된 상태로 유지할 수 있습니다. 이 전략은 설정 및 유지 관리 측면에서 더 복잡하므로 데이터 일관성 문제를 방지하려면 더 많은 테스트가 필요합니다.
높은 수준의 액티브/액티브 데이터베이스 구성에는 다음 단계가 포함됩니다.
1. 스키마 변환을 완료하십시오.
1. 원본 데이터베이스의 기존 데이터를 대상 데이터베이스로 복사한 다음 양방향 복제 도구 또는 애플리케이션의 이중 쓰기를 사용하여 두 데이터베이스를 동기화된 상태로 유지합니다.
1. 소스 데이터베이스와 대상 데이터베이스가 동기화되면 데이터를 확인합니다.
1. 트래픽의 일부를 새 데이터베이스로 이동하기 시작합니다.
1. 모든 데이터베이스 트래픽이 새 데이터베이스로 이동될 때까지 트래픽을 계속 이동시키십시오.
## 증분 마이그레이션
증분 마이그레이션에서는 전체 전환을 한 번에 수행하는 대신 더 작은 부분으로 나누어 애플리케이션을 마이그레이션합니다. 이 전환 전략은 현재 애플리케이션 아키텍처 또는 애플리케이션에서 수행하려는 리팩터링에 따라 다양한 변형이 있을 수 있습니다.
[디자인 패턴](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/)을 사용하여 새로운 독립 마이크로서비스를 추가하여 기존의 모놀리식 레거시 애플리케이션의 일부를 대체할 수 있습니다. 이러한 독립 마이크로서비스에는 애플리케이션의 다른 부분에서 공유하거나 액세스할 수 없는 자체 테이블이 있습니다. 다른 전환 전략을 사용하여 이러한 마이크로서비스를 하나씩 새 데이터베이스로 마이그레이션합니다. 마이그레이션된 마이크로서비스는 새 데이터베이스를 읽기/쓰기 트래픽에 사용하기 시작하고 애플리케이션의 다른 모든 부분은 기존 데이터베이스를 계속 사용합니다. 모든 마이크로서비스가 마이그레이션되면 레거시 애플리케이션을 사용 중지합니다. 이 전략은 마이그레이션을 더 작고 관리하기 쉬운 부분으로 나누므로 한 번의 대규모 마이그레이션과 관련된 위험을 줄일 수 있습니다.
# AWS에서 모범 사례 준수
이전 섹션에서 설명한 마이그레이션 활동 외에도 시간을 투자하여 AWS 클라우드에서 데이터베이스를 호스팅하는 모범 사례를 따르고 있는지 확인해야 합니다. AWS에서 관계형 데이터베이스를 사용하는 모범 사례는 [AWS 설명서를](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html) 참조하십시오.