기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 1단계: 준비
데이터베이스 마이그레이션 프로세스의 첫 번째 단계는 준비입니다. 준비 과정에서 애플리케이션과 데이터베이스 사이의 상호 종속성을 식별합니다. 또한 데이터베이스 워크로드를 분석하여 단순 리호스팅(동종) 마이그레이션부터 재설계(이종) 마이그레이션까지 마이그레이션 카테고리를 결정합니다. 이 단계를 완료하지 않으면 마이그레이션 일정이 지연될 위험이 있습니다.
이들 작업은 다음 섹션들에서 설명합니다.
+ [종속성 파악](id-dependencies.md)
+ [워크로드 적합성 파악](qualify-workloads.md)
# 종속성 파악
먼저 다음과 같은 질문을 통해 애플리케이션 및 데이터베이스의 종속성을 파악합니다.
+ 다른 애플리케이션에서 이 데이터베이스에 직접 액세스할 수 있습니까?
그렇다면 데이터베이스 마이그레이션이 해당 애플리케이션에 미치는 영향을 파악해야 합니다. 데이터베이스를 리호스팅하는 경우, 애플리케이션이 여전히 적절한 성능으로 데이터베이스에 액세스할 수 있는지 확인해야 합니다.
+ 애플리케이션이 다른 데이터베이스에 직접 액세스하나요?
그렇다면 다른 데이터베이스의 마이그레이션 계획을 결정하십시오. 또한 마이그레이션하는 중이라면 그에 따라 애플리케이션을 업데이트해야 합니다. 마이그레이션되지 않는 경우, 애플리케이션이 적절한 대기 시간 내에 계속 연결할 수 있는지 확인해야 합니다.
+ 데이터베이스에서 데이터베이스 링크를 사용하여 다른 데이터베이스에서 데이터를 가져오고 있습니까?
이전 시점과 마찬가지로 다른 데이터베이스의 마이그레이션 계획을 결정하고 그에 따라 링크를 처리하십시오.
+ 애플리케이션이 온프레미스 소프트웨어에 종속되어 있습니까?
그렇다면 해당 소프트웨어의 마이그레이션 계획을 결정해야 합니다. 마이그레이션하는 경우, 그에 따라 애플리케이션을 업데이트해야 합니다. 그렇지 않은 경우, 애플리케이션이 소프트웨어에 계속 연결할 수 있고 지연 시간이 괜찮은지 확인하십시오.
+ 하드웨어 종속성이 있나요?
그렇다면 이러한 문제를 해결하기 위한 계획을 세우십시오.
+ 엄격한 대역폭이나 네트워킹 요건이 있나요?
그렇다면 이러한 요건을 충족하는 데 도움이 되는 AWS 서비스를 선택하십시오.
+ 애플리케이션에서 특별한 데이터베이스 엔진 옵션이나 기능을 사용하나요?
다른 데이터베이스 엔진으로 마이그레이션하는 경우, 그에 따라 애플리케이션을 업데이트해야 합니다.
이러한 질문에 대한 답변이 복잡할 경우, 마이크로서비스를 사용하여 애플리케이션에서 데이터베이스를 분리하는 것이 더 좋습니다. 이렇게 하면 애플리케이션이 데이터베이스에 직접 연결하는 대신 마이크로서비스를 호출하여 데이터를 가져올 수 있습니다.
# 워크로드 적합성 파악
데이터베이스에 가장 적합한 마이그레이션 전략을 결정하려면 현재 데이터베이스 워크로드를 이해하는 것이 중요합니다. 데이터베이스를 분석하여 현재 사용 중인 기능과 [Amazon Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/)과 같은 다른 클라우드 네이티브 데이터베이스 엔진으로 마이그레이션하는 데 필요한 사항은 무엇인지 확인해야 합니다.
AWS는 AWS WQF(AWS 워크로드 검증 프레임워크)라는 워크로드 검증 도구를 제공합니다. 이 도구를 사용하면 데이터베이스 스키마와 코드 객체, 애플리케이션 코드, 종속성, 성능 특성 및 유사한 입력을 분석하여 Oracle 및 Microsoft SQL Server 데이터베이스 마이그레이션의 복잡성을 파악할 수 있습니다. WQF는 대상 데이터베이스 엔진에 대한 권장 사항을 제공합니다. 또한 관련 작업 타입과 필요한 노력의 정도를 예측합니다.
WQF는 마이그레이션 워크로드를 평가하여 다음 표에 요약된 다섯 가지 워크로드 카테고리 중 하나에 배치합니다.
![\[Five migration workload categories reported by WQF\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/strategy-database-migration/images/wqf-categories.png)
+ **카테고리 1:** 전용 드라이버 대신 ODBC(Open Database Connectivity) 또는 Java Database Connectivity(Java Database Connectivity)를 사용하여 데이터베이스에 연결하는 워크로드. 이 카테고리에는 액세스 통제를 위해 사용되는 간단한 절차가 저장되어 있습니다. 변환 시 필요한 수작업 변경 횟수는 50회 미만입니다.
+ **카테고리 2:** 독점 특성을 거의 사용하지 않고 고급 SQL 언어 특성을 사용하지 않는 워크로드. 이 타입의 워크로드는 200개 미만의 수작업 변경을 요구합니다.
+ **카테고리 3:** 자체 특성을 많이 사용하는 워크로드. 이러한 카테고리의 워크로드는 전적으로 고급 저장 프로시저 로직 또는 독점 기능으로 구동됩니다. 이러한 타입의 워크로드에는 데이터베이스에 상주하는 코드 및 기능을 포함하는 200개 이상의 수동 변경이 필요합니다.
+ **카테고리 4:** 엔진별 워크로드. 이 카테고리의 워크로드는 특정 상용 데이터베이스 엔진에서만 작동할 수 있는 프레임워크를 사용합니다. 예컨대, 이러한 프레임워크에는 Oracle Forms, Oracle Reports, Oracle Application Development Framework(ADF), Oracle Application Express(APEX) 또는 광범위하게 .NET ActiveRecord를 사용하는 앱이 포함될 수 있습니다.
+ **카테고리 5:** 비휴대용, 허용할 수 없는 리스크 또는 "리프트 앤 시프트" 워크로드. 이 카테고리의 워크로드는 동등한 클라우드 기반 버전이 없는 데이터베이스 엔진에서 구현할 수 있습니다. 이러한 프로그램을 위한 소스 코드가 없는 경우도 있습니다.
[2단계: 계획](planning-phase.md) 섹션에서 설명하겠지만, 이 분류는 애플리케이션의 마이그레이션 경로를 결정하는 데 도움이 될 수 있습니다.
AWS는 현재 다운로드를 위한 AWS WQF를 제공하지 않습니다. AWS WQF를 이용해 AWS로 마이그레이션하는 데 도움이 필요한 경우, 지원 티켓을 여는 것이 좋습니다. AWS는 귀사와 직접 연락하여 프로세스가 잘 진행되도록 도와드릴 것입니다.