AWS Migration Hub FAQ

시작하려면 AWS 설명서의 시작 가이드를 따르세요. 

Migration Hub에서 대부분의 기능(Refactor Spaces 제외)을 사용하기 전에 Migration Hub 설정 페이지에서 또는 Migration Hub Config API를 사용하여 Migration Hub 홈 리전을 선택해야 합니다.  

Migration Hub 홈 리전에 저장된 데이터는 전체 포트폴리오의 단일 검색 및 마이그레이션 계획 정보에 대한 단일 리포지토리와 여러 AWS 리전으로의 마이그레이션에 대한 단일 보기를 제공합니다. 마이그레이션 도구에서 지원하는 이전으로 마이그레이션할 수 있으며, 마이그레이션 상태는 선택한 Migration Hub 홈 리전에 표시됩니다. Migration Hub 홈 리전에 대한 자세한 내용은 설명서를 참조하세요.

설정이 완료된 후에는 Migration Hub 홈 리전을 변경할 수 없습니다.

AWS Migration Hub를 통해 모든 AWS 리전에서 마이그레이션 상태를 추적할 수 있습니다. 단, 해당 리전에 사용자의 마이그레이션 도구가 있어야 합니다. Migration Hub에 통합된 마이그레이션 도구(예: AWS Application Migration Service 및 AWS Database Migration Service)는 선택한 Migration Hub 홈 리전으로 마이그레이션 상태를 전송합니다. 홈 리전은 서비스를 처음 사용하기 전에 검색 및 마이그레이션 추적 데이터를 저장하는 데 사용됩니다. 마이그레이션 상태는 모든 대상 리전에서 집계되며, 홈 리전에서 확인할 수 있습니다. Migration Hub 콘솔의 도구(Tools) 페이지에서 권한을 부여(연결)한 후에만 통합 도구가 상태를 전송합니다.

AWS Migration Hub는 애플리케이션이 현재 상주하는 위치에 관계없이 전 세계에서 애플리케이션 마이그레이션을 추적하는 데 사용할 수 있습니다. 인벤토리 수집, 계획, 추천, 현대화 기능을 위한 Migration Hub의 가용성은 AWS 리전 표를 참조하세요.

AWS Migration Hub는 AWS Account 역할이 필요합니다. 이 역할은 콘솔에 관리자로 처음 액세스할 때 자동으로 추가됩니다. Migration Hub 콘솔의 Tools(도구) 페이지에서 통합된 마이그레이션 도구의 권한을 부여할 수 있습니다. 자세한 내용은 AWS Migration Hub 사용 설명서의 인증 및 액세스 제어 섹션을 참조하세요.

AWS Migration Hub에서 IT 자산을 보려면 먼저 통합 마이그레이션 도구로 마이그레이션하거나 AWS 검색 도구를 사용하여 검색을 실행합니다. 그러면 Migration Hub 안에서 환경을 탐색할 수 있습니다. Migration Hub 콘솔의 Servers(서버) 페이지에 표시된 서버 ID를 클릭하면 검색된 리소스에 관해 자세히 볼 수 있습니다. 그 다음에 서버 세부 정보 페이지를 볼 수 있습니다. AWS 검색 도구를 사용하여 서버를 검색한 경우에는 기술 사양과 평균 사용률을 포함해 수집된 데이터가 표시됩니다.

AWS Migration Hub를 처음 방문하면 검색 실행 또는 마이그레이션 시작을 묻는 메시지가 표시됩니다. 검색을 실행하지 않고 마이그레이션을 시작할 경우에는 Migration Hub 콘솔에서 권한을 부여한 통합 마이그레이션 도구로 마이그레이션할 때 애플리케이션 서버와 데이터베이스 서버가 Migration Hub에 리소스로 표시됩니다.

검색에는 두 가지 데이터 수집 옵션이 있습니다. VMware 환경에서 에이전트를 설치하고 싶지 않은 경우에는 AWS Application Discovery Service 에이전트 수집기를 사용할 수 있습니다. 더 상세한 정보가 필요한 경우에는 리소스 사용률, 서버 상의 진행률, 서버의 네트워크 종속성에 관한 세부 정보를 포함해 광범위한 정보를 수집하는 서버에 에이전트를 설치하면 됩니다. 진행률과 네트워크 종속성 정보는 AWS Migration Hub 외부에서 내보내기 및 분석용으로 사용할 수 있습니다. AWS Discovery Collector에 관한 자세한 내용은 Application Discovery Service 사용 설명서를 참조하세요.

서버를 애플리케이션으로 그룹화하기 전에 AWS Migration Hub의 서버 목록을 채워야 합니다. 통합 마이그레이션 도구를 사용하여 AWS 검색 도구를 실행할 때마다 서버 목록에 서버가 추가됩니다. 서버 목록이 채워지면 Migration Hub 콘솔의 서버(Servers) 페이지에서 하나 이상의 리소스를 선택한 다음 “애플리케이션으로 그룹화(Group as Application)”를 선택합니다. AWS Discovery 에이전트를 사용하여 서버를 검색하는 경우 네트워크 가상화 도구에서 서버를 애플리케이션으로 그룹화할 수도 있습니다. 네트워크 그래프에서 하나 이상의 서버를 선택하고 ‘애플리케이션으로 그룹화(Group as application)’를 선택합니다.

AWS Migration Hub 콘솔의 Migration(마이그레이션) 섹션에 있는 Applications(애플리케이션) 페이지로 이동하여 애플리케이션 목록과 그 현재 마이그레이션 상태를 볼 수 있습니다. Discover 섹션의 Servers 페이지 또는 AWS SDK/CLI를 사용하여 애플리케이션으로 그룹화한 리소스만 Applications 페이지에 표시됩니다. 애플리케이션(Applications)에 표시되는 마이그레이션 상태는 ‘시작 안 됨(not started)’, ‘진행 중(in-progress)’, ‘완료(completed)’의 세 가지입니다.

예. 한 계정 내에서 IAM 사용자가 생성한 애플리케이션은 AWS Migration Hub에 대한 액세스 권한이 있는 동일 계정 내의 다른 IAM 사용자에게 표시됩니다. 모든 변경 사항은 권한이 있는 모든 사용자에게 표시됩니다.

AWS 계정과 연결된 IAM User를 사용하여 AWS Migration Hub에 액세스합니다. 이 경우 사용자의 AWS 계정에서 세부 정보만 볼 수 있으며, 다른 계정은 볼 수 없습니다.

AWS Migration Hub 콘솔에서 Migration Hub 가져오기 기능에 액세스하거나 Application Discovery Service API를 간접적으로 호출하여 Migration Hub 가져오기 기능에 액세스할 수 있습니다. 가져온 데이터는 Application Discovery Service 데이터 리포지토리에 암호화된 형식으로 저장됩니다.

Migration Hub 가져오기를 이용하면 서버와 관련된 서버 사양, 사용률, 태그 및 애플리케이션 등 서버 세부 정보를 가져올 수 있습니다. Migration Hub CSV 가져오기 템플릿을 이용해 데이터가 채워지는 한 모든 소스에서 데이터를 가져올 수 있습니다.

예. 검색(Discover) > 도구(Tools) > 가져오기(Imports) 섹션으로 이동해 “가져온 데이터 삭제(Delete imported data)” 옵션을 선택하여 잘못된 파일을 삭제할 수 있습니다. 기존에 가져온 파일을 덮어쓰려면 파일을 삭제하고 올바른 레코드가 포함된 새 파일을 업로드합니다.

아니요, 업로드할 수 있는 가져오기 파일 수에는 제한이 없습니다. 하지만 가져올 수 있는 레코드 및 서버 수는 제한합니다. 자세한 내용은 설명서의 Migration Hub 가져오기 한도 섹션을 참조하세요.

아니요. 데이터 가져오기에 대한 비용은 없습니다.

예. 가져오기 템플릿의 모든 필드에 데이터가 채워지지 않은 경우에도 데이터를 가져올 수 있습니다. 각 행에 대해 본인의 매칭 키("ExternalId")를 채우면 가져오기가 이를 사용하여 레코드를 고유하게 식별하여 가져옵니다. 매칭 키를 지정하지 않으면 가져오기는 각 행에 대해 “IPAddress,” “HostName,” “MACAddress” 또는 "VMware.MoRefId"와 "VMware.vCenterId"의 조합에 대해 지정된 값을 사용하여 주어진 서버에 대한 고유성을 결정합니다. 매칭 키(“ExternalId”) 또는 위의 필드에 값을 포함하지 않는 행은 가져오지 않습니다.

가져오기는 CSV 가져오기 템플릿의 일부인 모든 가져온 필드에 대해 데이터 유효성 검사를 수행합니다. 예를 들어 "IPAddress" 값이 유효하지 않은 경우 가져오기 기능은 해당 레코드를 잘못된 것으로 표시합니다. 또한 "ExternalId", "MACAddress", "HostName", "IPAddress" 또는 "VMware.VCenterId"와 "VMware.MoRefId"의 조합 중 적어도 하나 이상이 채워지지 않은 가져오기 레코드는 유효하지 않은 것으로 간주하여 가져오지 않습니다.

EC2 인스턴스 추천은 각 온프레미스 서버에서 수집한 데이터(예: 서버 사양, CPU 및 메모리 사용률)를 분석하여 온프레미스 워크로드를 실행하는 데 필요한 가장 저렴한 EC2 인스턴스를 추천하는 AWS Migration Hub의 기능입니다. 또한 AWS 구매 옵션, AWS 리전, 제외해야 할 EC2 인스턴스 유형, CPU/RAM 사용률 지표(평균, 피크 또는 백분위수)에 대한 기본 설정을 지정하여 추천 내용을 세부적으로 조정할 수도 있습니다.

아니요. EC2 인스턴스 추천 기능을 사용하려면 AWS Migration Hub에서 온프레미스 서버 세부 정보를 사용할 수 있도록 해야 합니다. 콘텐츠 관리 데이터베이스(CMDB) 같은 원본에서 기존 서버 인벤토리 정보를 가져올 수도 있고, AWS Application Discovery Service를 사용하여 환경에서 바로 데이터를 수집할 수도 있습니다.

EC2 인스턴스 추천 기능에서는 AWS 구매 옵션, AWS 리전, 제외해야 할 EC2 인스턴스 유형, CPU/RAM 사용률 지표(평균, 피크 또는 백분위수) 같은 선택한 인스턴스 유형 기본 설정을 고려하여 지정된 CPU 및 RAM 요구 사항을 충족할 수 있는 EC2 인스턴스 유형 중 가장 경제적인 인스턴스 유형을 추천합니다.

예. EC2 인스턴스 추천 기능을 통해 성능 버스트 가능 인스턴스를 추천받을 수 있습니다. 이 기능은 ‘평균’ 및 ‘피크’ CPU 데이터 요소를 사용하여 예상 사용 CPU 크레딧 및 관련 비용을 계산함으로써 예상 요금을 다른 인스턴스 패밀리와 좀 더 정확하게 비교합니다.

동일한 서버에 대해 여러 원본의 검색 데이터가 있는 경우 EC2 인스턴스 추천 기능에서는 가장 최근의 완전한 데이터를 사용하여 인스턴스를 추천합니다. 예를 들어 Migration Hub 가져오기를 사용하여 특정 서버에 대한 CPU/RAM 사양을 업로드하는 경우 가져온 데이터를 토대로 추천이 생성됩니다. 그런 다음 이 서버에 AWS Application Discovery Service(ADS) Discovery Agent를 설치하는 경우 ADS 에이전트도 서버 사양 세부 정보를 캡처합니다. 다음에 해당 서버에 대한 EC2 인스턴스 추천을 요청하면 ADS 에이전트의 데이터가 보다 최신이고 완전하므로 에이전트를 통해 수집된 사양이 추천을 생성하는 데 사용됩니다.

예. EC2 인스턴스 추천 기능은 현재 세대의 인스턴스만 추천하며, 이전 세대의 인스턴스는 추천하지 않습니다.

컴퓨팅 리소스의 규모를 올바르게 지정하면 총 소유 비용(TCO)을 이해하는 데 도움이 됩니다. Migration Hub의 EC2 인스턴스 추천 기능은 예상되는 EC2 비용을 파악하려는 경우에 사용합니다. AWS는 AWS 회사인 TSO Logic을 통해 최적화된 Microsoft 라이선스 및 스토리지 비용 같은 좀 더 세부적인 평가도 제공하고 있습니다. 이러한 세부적인 평가에 대해 자세히 알아보려면 AWS 영업 팀 또는 AWS 파트너에게 문의하세요.

AWS 검색 도구를 사용하여 검색된 서버로부터 하나 이상의 애플리케이션 그룹을 생성한 후에 또는 통합 마이그레이션 도구를 사용한 마이그레이션을 시작하여, Migration Hub 외부에서 서버 또는 데이터베이스 마이그레이션을 시작하거나 계속할 수 있습니다. Migration Hub로 돌아가 애플리케이션에 있는 각 리소스의 마이그레이션 상태를 봅니다. 

이 경우 Migration Hub 콘솔에서 해당 애플리케이션 페이지로 이동해야 합니다. 거기서 애플리케이션을 구성하는 모든 리소스가 담긴 그림과 마이그레이션 상태 세부 정보가 담긴 표를 볼 수 있습니다. 각 리소스마다 일반 및 세부 상태가 그림과 표로 표시됩니다. 예를 들어, AWS Server Migration Service로 마이그레이션이 진행되는 서버의 경우 “진행 중 / 복제 시작(In progress / replication starting)”, “진행 중 / 복제 완료(In progress / replication complete)” 또는 “완료 / AMI 생성(Competed / AMI created)”으로 상태가 보고될 수 있습니다. 

마이그레이션이 완료되면 Migration Hub에서 마이그레이션으로 생성된 리소스에 관한 세부 정보도 표시합니다. AWS Application Migration Service, AWS Server Migration Service 및 ATADATA를 사용하여 마이그레이션된 서버의 경우, Migration Hub에서는 생성된 AMI 또는 실행 중인 EC2 인스턴스에 대한 링크를 제공합니다(도구에 따라 다름). AWS Database Migration Service로 마이그레이션되는 데이터베이스의 경우 Migration Hub가 Database Migration Service 콘솔에서 검색 필터로 사용할 수 있는 대상 엔드포인트 ID를 제공합니다.

아니요. AWS Migration Hub는 마이그레이션 단계를 자동화하지 않습니다. Migration Hub는 사용자가 마이그레이션하는 애플리케이션의 진행 상황을 추적할 수 있는 하나의 장소를 제공합니다.

AWS Migration Hub에서 마이그레이션 진행 상황을 보려면 두 가지 요건이 충족되어야 합니다. 마이그레이션하는 리소스가 AWS Discovery 리포지토리에 있어야 하고, 지원되는 도구를 사용하여 마이그레이션을 실행해야 합니다. AWS Discovery Collector로 검색을 실행하지 않고 마이그레이션을 시작할 경우 지원되는 마이그레이션 도구에서 보고한 서버 또는 데이터베이스가 AWS Application Discovery Service 리포지토리에 자동으로 추가됩니다. 추가된 후에는 이러한 서버를 애플리케이션으로 그룹화하고, 마이그레이션이 진행될 때 그 상태를 단일 그룹에서 추적할 수 있습니다.

지원 도구를 사용하면서 애플리케이션에서 상태를 표시하지 않으려면 먼저 업데이트(Updates) 페이지에서 도구의 상태가 수신되고 있는지 확인합니다. Updates 페이지에 상태가 표시되지 않을 경우에는 도구(Tools) 페이지에서 해당 도구에 Migration Hub로 상태를 전송할 권한을 부여했는지 확인합니다. 권한이 부여되지 않았으면 “권한 부여(Authorize)”를 클릭하여 해당 IAM 권한을 추가합니다.

업데이트(Updates) 페이지에 마이그레이션 상태가 표시된다면 리소스가 애플리케이션으로 그룹화되지 않았을 것입니다. 서버(Servers) 페이지로 이동하여 서버를 애플리케이션으로 그룹화합니다. 그런 다음 마이그레이션/애플리케이션(Migrate/Applications) 페이지에서 이 애플리케이션을 보고 마이그레이션 상태를 확인합니다.

AWS Migration Hub에 지원 도구로 실행한 리소스 마이그레이션 상태가 표시됩니다. 단, 리소스가 애플리케이션에 그룹화되어 있어야 합니다. 엄격한 재호스팅 마이그레이션일 필요는 없습니다. 예를 들어 AWS Database Migration Service를 사용하여 데이터베이스 내용을 옮길 경우, 데이터베이스 마이그레이션에 해당하는 서버가 애플리케이션에 그룹화되어 있으면 Migration Hub에 업데이트가 표시됩니다.

AWS Migration Hub와 통합되지 않은 도구는 Migration Hub 관리 콘솔에서 상태를 보고하지 않습니다. 애플리케이션 내 다른 리소스 상태와 애플리케이션 수준 상태는 표시되며, CLI 또는 API를 사용하여 사용자의 자동화 기능을 통해 상태를 업데이트할 수 있습니다.

마이그레이션 도구는 AWS Migration Hub API로 기록하여 AWS Migration Hub로 상태를 게시할 수 있습니다. 온보딩에 관심이 있는 파트너는 AWS 컴피턴시 프로그램을 통해 마이그레이션 컴피턴시를 획득해야 합니다. 컴피턴시 프로그램에 대해 자세히 알아보고 여기에서 마이그레이션 컴피턴시를 신청할 수 있습니다.

AWS Migration Hub의 Strategy Recommendations는 온프레미스 또는 AWS에서 실행하는 애플리케이션에 대한 마이그레이션 및 현대화 전략을 수립하는 데 도움이 됩니다. Strategy Recommendations는 대규모 마이그레이션 및 현대화에 도움이 되는 전략과 도구를 안내해줍니다.

Strategy Recommendations는 규모에 따른 맞춤형 마이그레이션 및 현대화 전략을 식별하고 전략을 실행하는 데 도움이 될 도구 및 서비스를 제공합니다. 또한 소스 코드에서 이러한 권장 사항을 구현하기 전에 해결해야 하는 비호환성(안티 패턴)을 식별하는 데 도움이 됩니다.

Strategy Recommendations는 Windows Server 2003 이상 또는 다양한 Linux 배포(Ubuntu, RedHat, Oracle Linux, Debian 및 Fedora)에서 실행되는 애플리케이션을 위한 잠재적 리호스팅(EC2) 및 리플랫포밍(RDS 및 Elastic BeanStalk와 같은 관리형 환경, 컨테이너, OS 업그레이드) 옵션에 대한 분석을 지원합니다. Strategy Recommendations는 C# 및 Java로 작성된 사용자 지정 애플리케이션과 라이선스가 있는 데이터베이스(예: Microsoft SQL Server, Oracle)에 대한 추가 리팩터링 분석을 제공합니다.

시작하려면 AWS 설명서의 시작 가이드를 따르세요.

자세히 알아보려면 AWS로 Windows 워크로드 현대화를 방문하세요.

애플리케이션 전환은 클라우드에서 실행하는 데 따른 가용성, 확장성, 비즈니스 민첩성, 비용 최적화의 이점을 극대화하기 위해 애플리케이션을 리팩터링, 리아키텍팅, 재작성하는 과정입니다.

Refactor Spaces는 애플리케이션 리팩터링 속도를 높여 AWS의 컴퓨팅을 최대한 활용하고, 프로덕션에서 작동하는 동안 리팩터링 프로세스를 쉽게 관리할 수 있도록 하여 앱 전환을 간소화하는 데 도움을 줍니다. Refactor Spaces를 사용하면, 리팩터링을 할 수 있는 기본 인프라의 생성 및 관리에 집중하는 대신 애플리케이션의 리팩터링에 집중할 수 있습니다. Refactor Spaces는 애플리케이션을 마이크로서비스로 전환하거나 레거시 애플리케이션을 마이크로서비스로 작성된 신규 기능으로 확장하는 데 따른 비즈니스 리스크를 줄이는 데 도움을 줍니다.

Refactor Spaces는 애플리케이션을 전환할 때 공통적인 두 가지 실질적인 문제, 즉 애플리케이션 리팩터링을 위한 인프라를 마련하고, 진화하는 애플리케이션을 대규모로 운영하는 문제를 해결합니다. Refactor Spaces는 기존 애플리케이션과 마이크로서비스를 하나의 애플리케이션으로 결합하는 데 도움을 주는 한편 아키텍처와 기술, 팀 조정, 파트 간 프로세스에 대한 다양한 접근 방식을 가능하게 합니다. Refactor Spaces를 사용하면 레거시 애플리케이션을 전환하거나, 모든 AWS 컴퓨팅 대상(예: EC2, Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, AWS Fargate, AWS Lambda)에서 실행되는 마이크로서비스로 레거시 애플리케이션을 확장할 수 있습니다. Refactor Spaces는 몇 분 안에 애플리케이션 리팩터링을 위한 인프라를 생성하여 상당한 시간을 절약해 줍니다.

외부 인터페이스가 HTTP 기반 프로토콜이고 AWS에서 실행된다면(또는 먼저 Application Migration Service으로 리호스팅되거나 리플랫포밍될 수 있다면) 리팩터링, 재작성 또는 리아키텍처링의 대상이 되는 모든 애플리케이션이 Refactor Spaces의 후보입니다. Refactor Spaces는 일반적으로 오래된 레거시 및 모놀리식 애플리케이션을 리팩터링하는 데 사용되지만, 최신 서비스 및 애플리케이션의 리팩터링 및 리아키텍처링을 모색하는 데에도 도움을 줍니다.

Refactor Spaces는 다른 AWS 서비스를 오케스트레이션하여 리팩터링 환경을 만들고 기존 애플리케이션과 마이크로서비스를 Refactor Spaces 애플리케이션으로 결합하므로 앱 개발을 진행하면서 운영하기가 용이합니다. 애플리케이션 리팩터링 환경은 Transit Gateway, Resource Access Manager, API Gateway를 사용해 구축됩니다. 이를 사용하여 Refactor Spaces는 손쉬운 교차 계정 통신을 위해 네트워킹과 함께 연결된 다중 계정 구조를 통해 기존 애플리케이션을 마이크로서비스와 분리합니다.

AWS 계정 전반의 네트워킹, 애플리케이션, 서비스에 대한 통합 보기를 제공하는 Refactor Spaces 환경은 기존 애플리케이션과 새 마이크로서비스를 위한 컨테이너입니다. 이 환경은 Transit Gateway, Resource Access Manager, VPC를 오케스트레이션하여 계정 전반의 네트워킹을 연결함으로써 이전 서비스와 신규 서비스 간의 통신을 간소화합니다. 환경이 생성된 계정이 환경의 소유자입니다. 소유자는 환경을 다른 AWS 계정과 공유하고, 환경에 추가된 애플리케이션, 서비스, 경로를 관리할 수 있습니다.

Refactor Spaces 애플리케이션은 기존 애플리케이션과 새 마이크로서비스에 대한 요청 라우팅 구성 기능을 제공합니다. 애플리케이션에는 AWS에서 교살자 무화과(strangler fig) 리팩터링을 간소화하는 프록시가 포함됩니다. 환경 안에 애플리케이션을 생성할 때 Refactor Spaces는 API Gateway, Network Load Balancer(NLB), AWS Lambda 리소스 정책을 오케스트레이션합니다. 애플리케이션의 프록시 및 라우팅은 기본 아키텍처 변경 사항을 앱 소비자에게 투명하게 제공하는 데 사용됩니다.

Refactor Spaces 서비스는 기존 애플리케이션 또는 새 마이크로서비스의 엔드포인트를 나타냅니다. 서비스에는 URL 엔드포인트 또는 AWS Lambda 엔드포인트를 갖는 VPC를 둘 수 있습니다. Refactor Spaces는 Transit Gateway를 사용해 환경 내의 서비스 VPC를 자동으로 연결합니다. 이로써 환경에 있는 모든 계정의 서비스 VPC에서 모든 AWS 리소스 간에 트래픽이 허용됩니다. 서비스에 대한 경로를 설정할 때 서비스에 Lambda 엔드포인트가 있으면 API Gateway의 Lambda 통합을 사용하여 트래픽이 라우팅됩니다. URL 엔드포인트가 있는 서비스의 경우 API Gateway VPC 링크 및 NLB 대상 그룹을 사용하여 트래픽이 라우팅됩니다.

Refactor Spaces는 AWS Management Console, AWS SDK/CLI 또는 CloudFormation(CFN)을 통해 사용할 수 있습니다. 일반적으로는 최소 두 개의 계정(기존 애플리케이션을 위한 계정 하나와, Refactor Spaces 환경을 소유하고 서비스 간의 트래픽 라우팅을 관리하기 위한 계정 하나)을 사용해 시작합니다. AWS 계정은 독립 계정이거나, AWS Organization의 일부인 계정이거나, AWS Control Tower에서 프로비저닝한 신규 또는 기존 계정일 수 있습니다. 

먼저, 계정의 Refactor Spaces 콘솔을 방문하거나 IAM의 콘솔 또는 API를 사용하여 리팩터링에 사용할 각 AWS 계정에 Refactor Spaces 서비스 연결 역할(SLR)을 설치하여 SLR을 만듭니다. 그 다음, 환경 소유자로 선택한 계정에서 Refactor Spaces 환경을 생성해서 다른 계정과 공유합니다. 다른 계정에서 환경 공유 초대를 수락하면 Refactor Spaces는 환경에 포함된 AWS 리소스(예: Transit Gateway)를 지정된 다른 계정과 자동으로 공유합니다. 

다음으로, 첫 번째 애플리케이션을 생성합니다. Refactor Spaces 애플리케이션은 서비스가 속한 계정에 관계없이(API Gateway를 통해) Refactor Spaces 서비스에 대한 요청 라우팅 구성 기능을 제공합니다. 애플리케이션을 생성했으면 그 안에 하나 이상의 서비스를 생성합니다. 처음에는 모든 트래픽이 기존 앱으로 전달되므로, 기존 앱을 나타내는 서비스에 모든 트래픽을 보내는 기본 경로를 만듭니다. 시간이 지나면서 서비스 이용자는 새로운 마이크로서비스가 제공하는 비즈니스 기능으로 트래픽을 전환하는 경로를 추가하게 됩니다.

예. VPC 엔드포인트를 생성하여 VPC(Amazon Virtual Private Cloud를 사용해 생성)에서 Refactor Spaces API에 비공개로 액세스할 수 있습니다. VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 게이트웨이 또는 가상 프라이빗 네트워크(VPN) 연결을 사용하지 않고도 AWS 네트워크에서 VPC와 Refactor Spaces 간 라우팅을 처리할 수 있습니다. Refactor Spaces가 사용하는 최신 세대 VPC 엔드포인트는 AWS PrivateLink에서 제공합니다. 이는 VPC의 프라이빗 IP 주소를 통해 탄력적 네트워크 인터페이스(ENI)를 사용하는 AWS 서비스 간 프라이빗 연결을 지원하는 기술입니다. PrivateLink 지원에 대해 자세히 알아보려면 Refactor Spaces 설명서를 참조하세요.

마이그레이션 오케스트레이션은 템플릿을 사용하고 여러 태스크를 단일 워크플로로 통합하며 종속성을 관리하여 원하는 마이그레이션 프로젝트 목표를 달성하는 프로세스 자동화 메커니즘입니다.

AWS Migration Hub Orchestrator는 AWS로의 애플리케이션 마이그레이션을 자동화하고 간소화하도록 설계되었습니다. Orchestrator는 대규모 엔터프라이즈 애플리케이션을 마이그레이션하고 서로 다른 도구 간의 종속성을 관리하며 마이그레이션 진행 상황의 가시성을 제공하는 것과 관련된 많은 수동 태스크를 제거하여 마이그레이션 비용 및 시간을 줄이는 데 도움이 됩니다. Orchestrator에서 복잡한 워크플로 및 종속 태스크를 오케스트레이션하는 권장 마이그레이션 태스크, 마이그레이션 도구 및 자동화 기회로 미리 정의된 사용자 지정 가능한 워크플로 템플릿을 사용하여 AWS로의 마이그레이션 프로세스를 간소화할 수 있습니다. 

Orchestrator는 마이그레이션을 가속화하고 마이그레이션 프로세스를 간소화하며 마이그레이션 도구 및 프로세스를 사용 사례에 맞게 변경하는 데 도움이 됩니다.

• 마이그레이션 가속화: AWS가 마이그레이션한 것과 유사한 패턴의 수천 개 애플리케이션을 바탕으로 미리 정의된 워크플로 템플릿을 사용하여 애플리케이션 마이그레이션의 속도를 높일 수 있습니다.
• 자동화 간소화: AWS Application Discovery Service, AWS Application Migration Service 및 AWS Launch Wizard와 같은 다수의 도구에서 동일한 마이그레이션 워크플로에 대한 사전 마이그레이션 태스크, 마이그레이션 워크플로 및 마이그레이션 태스크를 자동화하여 수동 작업을 최소화할 수 있습니다. 
• 변경 및 간소화: 기준 권장 사항을 기반으로 특정 워크로드 및 사용 사례의 요구 사항에 맞게 단계 및 종속성을 수정하여 워크플로 템플릿을 사용자 지정하고 재사용할 수 있습니다.

Orchestrator를 사용하면 AWS로의 마이그레이션이 간소화되고 가속화됩니다.

• 권장 방법론을 사용한 애플리케이션 마이그레이션: AWS가 마이그레이션한 유사한 패턴의 수천 개 애플리케이션을 바탕으로 미리 정의된 워크플로 템플릿을 사용하여 마이그레이션을 빠르게 시작할 수 있습니다.
• 마이그레이션 워크플로 사용자 지정: 특정 사용 사례의 요구 사항에 따라 자체 단계, 종속성 및 자동화를 추가하여 워크플로를 사용자 지정할 수 있습니다.
• 소스 환경의 사전 마이그레이션 태스크 오케스트레이션: 마이그레이션을 수행할 때는 마이그레이션 준비 상태를 확인하거나 에이전트를 설치하거나 AWS로 마이그레이션하지 않을 불필요한 로그 파일을 제거해야 합니다. 각 온프레미스 서버에서 이러한 태스크를 수동으로 수행하려면 지루할 뿐 아니라 오류가 많이 발생합니다. Orchestrator를 사용하면 이러한 태스크를 자동화하여 시간과 비용을 절감하는 동시에 오류를 줄일 수 있습니다.
• 다양한 마이그레이션 도구의 마이그레이션 태스크 오케스트레이션: 마이그레이션 프로세스를 최적화하려면 동일한 마이그레이션 워크플로에 AWS Application Discovery Service, AWS Application Migration Service 또는 AWS Launch Wizard와 같은 여러 도구를 사용해야 할 수 있습니다. Orchestrator를 사용하면 인벤토리 메타데이터, 구성 사양 및 환경 컨텍스트를 재사용하여 마이그레이션 태스크를 오케스트레이션함으로써 이러한 각 도구에 제공해야 하는 입력을 최소화할 수 있습니다. Orchestrator는 한 곳에서 수동 마이그레이션 태스크를 자동화하고 서로 다른 도구 간의 종속성을 관리하며 마이그레이션 진행 상황의 가시성을 제공하여 마이그레이션 비용 및 시간을 줄이는 데 도움이 됩니다.
• 마이그레이션된 애플리케이션 구성, 검증 및 시작: 대규모 마이그레이션에서 인스턴스, 데이터베이스 및 네트워크 연결을 확인하고, 마이그레이션된 서버에서 애플리케이션을 설치 및 제거하고, 스테이징 환경을 종료하려면 전환 기간 및 다운타임이 길어집니다. Orchestrator를 사용하면 이와 같은 일상적인 마이그레이션 단계를 자동화하여 전환 시간을 50% 이상 단축할 수 있습니다.

AWS Migration Hub 콘솔 또는 AWS Command Line Interface(CLI)에서 Orchestrator에 액세스할 수 있습니다. Orchestrator를 사용하여 사전 요구 사항을 완료합니다. 즉, 소스 서버를 검색하거나 가져오고, 검색된 서버를 애플리케이션으로 그룹화하고, 소스 환경에 플러그인을 설치합니다. 그런 다음 미리 정의된 워크플로 템플릿 중 하나를 선택하여 애플리케이션 마이그레이션을 오케스트레이션할 워크플로를 생성합니다. 원하는 경우 워크플로의 일부로 수동으로 완료하거나 자동화할 사용자 지정 단계를 지정해도 됩니다. 워크플로를 정의한 후에는 실행하거나 일시 중지하거나 삭제할 수 있습니다. 또한 Orchestrator에서 단계 수준 및 단계 그룹 수준으로 워크플로 상태를 추적할 수도 있습니다.

워크플로 템플릿은 권장되는 마이그레이션 태스크, 종속성, 적합한 마이그레이션 도구 및 권장 자동화 기회 세트가 포함된 플레이북입니다. 예를 들어 HANA 데이터베이스를 사용하는 SAP NetWeaver 기반 애플리케이션의 마이그레이션을 위해 미리 정의된 워크플로 템플릿에는 소스 서버와 플러그인 간의 연결 자동 검증, AWS Launch Wizard를 사용하여 새 SAP 환경을 프로비저닝하는 기능, 소스 환경과 대상 환경 자동 검증, HANA 데이터베이스 및 애플리케이션의 자동 마이그레이션과 마이그레이션 후 검증을 위한 단계별 태스크가 포함됩니다. 

현재 Orchestrator는 사용자가 사용할 수 있는 다섯 가지의 미리 정의된 워크플로 템플릿을 지원합니다. 첫 번째 템플릿은 AWS Launch Wizard 및 HANA System Replication을 사용하여 HANA 데이터베이스를 포함하는 SAP NetWeaver 기반 애플리케이션을 마이그레이션하는 데 도움이 됩니다. 두 번째 템플릿은 AWS Application Migration Service(MGN)를 사용하여 애플리케이션을 빠르게 리호스팅하는 데 도움이 됩니다. 세 번째와 네 번째 템플릿은 기본 백업 및 복원을 사용하여 SQL Server 데이터베이스를 Amazon RDS로 리플랫포밍하고 SQL Server 데이터베이스를 Amazon EC2로 리호스팅하는 데 도움이 됩니다. 다섯 번째 템플릿은 IT 보안, 구성 관리 및 규정 준수 요구 사항을 충족하도록 구축한 VM 이미지에서 Amazon Machine Image(AMI)를 생성할 수 있는 콘솔 기반 환경을 통해 온프레미스 가상 머신(VM) 이미지를 AWS로 가져오는 데 도움이 됩니다. 이러한 템플릿은 새 단계 및 자동화 스크립트를 추가하는 옵션과 함께 모두 미리 정의된 작업 자동화를 포함하고 있습니다.