AWS Migration Hub – 클라우드 마이그레이션 전략 추천 기능 출시

클라우드에 대한 성공적인 애플리케이션 마이그레이션 및 현대화를 위해 실행 가능한 전략을 결정하는 데는 시간이 걸립니다. 분석할 애플리케이션 포트폴리오의 규모와 복잡성에 따라 상당한 노력이 필요할 수도 있습니다. 현재까지 분석 프로세스는 대부분 수동적이고 비표준적인 속성을 가지기 때문에 대형 포트폴리오에 대규모로 적용하기가 어렵습니다. 제한된 의사 결정 시간, 도메인 지식 및 클라우드 전문 지식 부족, 사용 가능한 현대화 도구 및 서비스에 대한 낮은 인식으로 인해 노력과 복잡성이 가중될 수 있습니다.

애플리케이션 포트폴리오 분석을 자동화하는 데 도움이 되는AWS Migration Hub Strategy Recommendations를 정식 출시합니다. Strategy Recommendations는 실행 중인 애플리케이션을 분석하여 런타임 환경 및 프로세스 종속성을 확인하고 선택적으로 소스 코드와 데이터베이스를 분석하는 등의 작업을 수행합니다. 분석을 통해 수집된 데이터는 라이선스 비용 절감, 마이그레이션 속도, 관리형 서비스 사용으로 인한 운영 오버헤드 감소, 클라우드 네이티브 기술을 사용한 인프라 현대화 등 우선 순위에 따라 평가됩니다. 그런 다음 애플리케이션을 마이그레이션하고 현대화하기 위해 실행 가능한 경로에 대한 권장 사항을 제시합니다.

애플리케이션의 마이그레이션 및 현대화를 위해 리호스팅, 리플랫폼, 리팩터링 등의 여러 경로를 거칠 수 있습니다. 실행 가능한 모든 경로에 대한 권장 사항을 확인하고, 적합하다고 생각되는 권장 사항을 재정의하도록 선택할 수 있습니다. 경험 유무에 관계 없이 누구나, Strategy Recommendations를 사용하면 온프레미스에서 마이그레이션을 기다리고 있든, AWS 클라우드에서 추가 현대화를 진행할 예정이든 애플리케이션 포트폴리오를 평가하는 데 필요한 노력과 시간, 복잡성을 줄일 수 있습니다.

일반적인 N-계층 애플리케이션인 Microsoft SQL Server 데이터베이스 사용 ASP.NET 웹 애플리케이션을 예로 들어 보면 Strategy Recommendations를 통해 웹 프런트엔드 호스팅 서버, 백엔드 서버, 데이터베이스 자체 등의 다양한 구성 요소를 분석하여 AWS 클라우드에 대한 마이그레이션 및 현대화에 사용할 수 있는 실행 가능한 경로와 도구를 결정할 수 있습니다. 예를 들어 애플리케이션의 라이선스 비용을 줄이는 것이 목표인 경우 Strategy Recommendations는 Porting Assistant for .NET을 사용하여 애플리케이션을 Linux에서의 .NET으로 리팩터링하도록 권장할 수 있습니다.

Strategy Recommendations에 대해 애플리케이션 서버 등록
애플리케이션 포트폴리오를 호스팅하는 서버를 AWS Application Discovery Service에 등록하는 것은 Strategy Recommendations의 전제 조건입니다. 등록할 서버는 온프레미스에서 물리적 서버 또는 가상 머신(VM)으로 실행될 수도 있고, ‘리프트 앤 시프트’ 프로세스를 통해 이미 마이그레이션한 애플리케이션을 위한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스일 수도 있습니다. AWS Application Discovery Service 사용 설명서에서 애플리케이션 서버를 등록하는 다양한 옵션에 대한 자세한 내용을 확인할 수 있습니다.

분석을 위한 자동 데이터 수집
AWS Application Discovery Service에 등록된 서버를 사용하면 Strategy Recommendations에서 제공하는 에이전트 없는 데이터 수집기를 사용하여 애플리케이션 포트폴리오의 프로세스 수준 분석 자동 수집을 설정할 수 있습니다. 에이전트 없는 수집기는 VMware vCenter 환경을 위한 오픈 가상화 어플라이언스(OVA)로 다운로드할 수 있습니다. 이미 일부 또는 모든 애플리케이션을 EC2로 마이그레이션한 경우, 수집기가 포함된 EC2 Amazon Machine Image(AMI)를 사용하여 이러한 애플리케이션에 대한 현대화 기회를 추가로 분석할 수도 있습니다.

자동화된 수집 방법을 원하지 않거나 사용할 수 없거나 다른 도구 또는 서비스를 사용하여 이 데이터를 이미 수집한 경우 분석을 위해 데이터를 수동으로 가져올 수 있습니다. 그러나 수동으로 가져온 데이터에 대해 얻는 권장 사항은 자동화된 데이터 수집에서 비롯된 권장 사항만큼 심층적일 수 없습니다. 자동 수집의 또 다른 이점 중 하나는 진행 상황에 따라 데이터를 새로 고치는 것이 훨씬 쉽다는 것입니다.

서버에서의 애플리케이션 및 프로세스 검색은 언어에 구애받지 않습니다. GitHub 및 GitHub 엔터프라이즈 리포지토리와 Microsoft SQL Server 데이터베이스의 .NET 및 Java 애플리케이션의 경우 선택적으로 클라우드 안티 패턴 탐지를 포함할 수 있습니다. 소스 코드 또는 데이터베이스 분석을 수행하도록 선택하면 실제 코드나 데이터가 Strategy Recommendations에 업로드되지 않고 분석 결과만 전송된다는 점에 유의해야 합니다. 그런데 분석을 위해 데이터를 수동으로 가져오도록 선택한 경우 심층적인 소스 코드 및 데이터베이스 분석을 수행하는 옵션이 지원되지 않습니다.

애플리케이션 포트폴리오 분석
자동화된 데이터 수집, 분석 옵션 및 기타 중요한 선행 조건을 설정하는 방법에 대한 자세한 내용은 Strategy Recommendations 사용 설명서에서 확인할 수 있으므로 여기서는 더 자세히 다루지 않겠습니다. 대신 에이전트 없는 수집기를 사용하여 이미 EC2로 마이그레이션된 애플리케이션 포트폴리오를 어떻게 분석할 수 있는지 살펴보겠습니다. 앞서 언급했듯이 Strategy Recommendations는 물리적 온프레미스 서버나 가상 머신, 또는 (이 게시물에 표시된) EC2 인스턴스에서 호스팅되는 애플리케이션 포트폴리오에 대한 분석을 지원합니다.

분석을 위해 데이터 수집을 시작하려면 다음과 같은 몇 가지 단계를 따라야 합니다.

다운로드 가능한 OVA 또는 제공된 EC2 AMI를 사용하여Strategy Recommendations의 에이전트 없는 수집기를 시작하고 구성합니다.
내 애플리케이션을 호스팅하는 각 Windows 및 Linux 인스턴스가 수집기의 액세스를 허용하도록 구성합니다.
초기 권장 사항을 가져오도록 초기 비즈니스 우선 순위와 기타 애플리케이션 및 데이터베이스 기본 설정을 구성합니다. 나중에 이러한 옵션을 미세 조정할 수 있습니다.

먼저 Migration Hub 콘솔의 탐색 패널에서 전략(Strategy)을 클릭하여 시작하기(Get started) 페이지로 이동합니다. 데이터 수집기 다운로드(Download data collector), 가져오기 템플릿 다운로드(Download import template) 또는 권장 사항 가져오기(Get recommendations) 버튼 중 하나를 클릭하면 사용자를 대신하여 다른 서비스에 액세스하는 데 필요한 권한을 Strategy Recommendations에 부여하도록 서비스 연결 역할을 생성해야 된다는 메시지 창이 나타납니다. 이에 동의하면 간단한 마법사의 데이터 원본 구성(Configure data sources) 페이지가 시작됩니다. 여기에서 이전에 등록한 수집기 목록을 볼 수 있습니다. 또한 자동 수집 외에 수동으로 가져올 애플리케이션 데이터에 대한 데이터 수집기 및 가져오기 템플릿의 OVA 버전을 다운로드할 수 있습니다.

EC2 AMI 기반 수집기를 사용하겠습니다. 이 마법사를 진행하기 전에 새 브라우저 탭에서 EC2 콘솔을 열어 시작합니다. Strategy Recommendations 데이터 수집기의 이미지를 찾으려면 AMI 페이지로 이동하여 퍼블릭 이미지(Public images)를 선택하고 소유자 703163444405로 필터링하거나, 인스턴스 시작(Launch Instances) 마법사의 검색(Search) 필드에AWSMHubApplicationDataCollector라는 이름을 입력합니다. 이미지를 찾은 후에는 다른 AMI와 마찬가지로 시작 마법사를 진행합니다.

수집기 구성 과정은 간단합니다. 일련의 질문을 사용하여 안내해드리겠습니다. 앞서 언급했듯이 전체 정보는 링크해 드린 사용 설명서에 나와 있으므로 여기서는 모든 세부 사항을 다루지 않겠습니다. 구성 프로세스를 시작하려면 먼저 SSH를 사용하여 수집기 인스턴스에 연결한 다음 docker exec -it application-data-collector bash 명령을 사용해 Docker 컨테이너를 실행합니다. 실행 중인 컨테이너에서 수집기 설정(collector setup) 명령으로 구성 Q&A를 시작합니다. 프로세스 중에 다음 정보 항목에 대한 데이터를 제공하라는 메시지가 표시됩니다.

사용 계약 동의 및 모든 필수 역할 설정 확인 후 AWS 액세스 및 보안 키를 설정합니다.
vCenter 또는 EC2 Windows 인스턴스에서 관리되지 않는 온프레미스 Windows 애플리케이션 서버의 경우 수집기가 WinRM을 사용하여 내 서버에 연결할 수 있도록 사용자 ID와 암호를 제공해야 합니다.
Linux 애플리케이션 서버가 있는 경우 수집기가 SSH 또는 인증서 기반 인증을 사용하여 연결할지 여부를 선택할 수 있습니다.
마지막으로 GitHub 또는 GitHub Enterprise의 리포지토리에서 .NET 및 Java 애플리케이션에 대한 소스 코드 분석을 구성할 수 있습니다. 이를 위해서는 Git 사용자 이름과 개인 액세스 토큰(PAT)이 필요합니다. 또한 C# 애플리케이션을 위해 심층적인 소스 코드 분석을 추가로 구성할 수 있습니다. 이를 위해서는 Windows를 실행하는 별도의 서버가 필요합니다. 저는 이 별도의 서버에 Porting Assistant for .NET을 설치했습니다.

이 단계를 완료하면 데이터 수집기가 등록되어 서버 검사를 시작할 준비가 됩니다. Strategy Recommendations 데이터 원본 구성(Configure data sources) 페이지로 돌아가서 페이지를 새로 고치면 내 수집기가 나열된 것을 볼 수 있습니다.

두 번째 단계는 수집기로부터 내 애플리케이션 서버에 액세스할 수 있도록 설정하는 것입니다. 이에 대한 자세한 내용은 사용 설명서의 4단계: Strategy Recommendations 수집기 설정 주제에 나와 있습니다. 내 Windows Server의 경우, RDP를 사용해 연결한 다음 WinRM 구성을 위해 이 가이드에 제공된 링크로부터 두 개의 PowerShell 스크립트를 다운로드하여 실행했습니다.

대규모 서버 플릿의 경우 AWS Systems Manager Automation을 사용하여 이 작업을 수행하는 것을 고려해 볼 수 있습니다. 수집기에 대해 SSH 인증을 사용하도록 선택한 Linux 서버의 경우, 수집기 구성 프로세스 중에 생성된 퍼블릭 키 자료를 각 서버에 복사해야 했습니다.

이 시점에서, 분석될 서버는 AWS Application Discovery Service에 알려져 있고, Strategy Recommendations 데이터 수집기가 구성되어 있으며, 각 서버는 수집기의 액세스를 허용하도록 구성되어 있습니다. 이제 세 번째 단계이자 마지막 단계를 수행합니다. 즉, 분석을 위해 내 비즈니스 및 기타 우선 순위를 설정하고 해당 서비스가 내 권장 사항을 생성하도록 설정합니다.

Strategy Recommendations의 시작하기(Get started) 페이지로 돌아갑니다. 수집기가 등록되어 있고 수동으로 가져올 애플리케이션 데이터가 없으므로 다음(Next)을 선택합니다. 이렇게 하면 기본 설정 지정(Specify Preferences) 페이지로 이동되며, 여기에서 비즈니스 우선 순위 및 기타 기본 설정을 지정합니다.

언제든지 이를 수정하고 재분석할 수 있지만 현재는 드래그 앤 드롭을 사용하여 라이선스 비용 절감, 클라우드 네이티브 기술을 사용한 인프라 현대화, 관리형 서비스로 운영 오버헤드 감소를 가장 높은 우선 순위로 설정합니다. 애플리케이션 및 데이터베이스 기본 설정에 대한 나머지 옵션은 변경하지 않고 그대로 둡니다.

다음(Next)을 선택하고 검토(Review) 페이지로 이동해서 내가 선택한 사항을 요약한 다음 데이터 분석 시작(Start data analysis)을 선택합니다. 참고적으로, 분석은 Application Discovery Service에서 구성한 모든 서버에 대해 실행되므로 이전 단계에서 가져온 것보다 더 많은 서버가 처리되고 있는 것을 볼 수 있습니다(수집기의 액세스를 허용하도록 구성되지 않은 서버는 수집 상태가 “데이터 수집 실패”인 결과에 표시됨).

분석이 완료되면 내 권장 사항이 요약됩니다(아직 안티 패턴 분석이 실행되지 않음).

서버 중 하나가 Windows를 실행 중이며 원래 .NET 프레임워크 기반 애플리케이션인 이전 버전의 nopCommerce 및 관련 SQL Server 데이터베이스를 호스팅합니다. 가장 높은 비즈니스 우선 순위가 라이선스 비용 절감이었기 때문에 해당 서버에서 내 검사를 시작합니다. 지금까지 제공되는 권장 사항은 서버 자체에 대한 검사만을 기반으로 합니다.

애플리케이션을 구성하는 소스 코드와 구성 요소의 분석은 이러한 권장 사항에 영향을 줄 수 있으므로 관심있는 서버 및 애플리케이션으로 드릴다운하여 애플리케이션 소스 코드에 대한 추가 분석을 요청합니다.

코드 분석은 Amazon Simple Storage Service(Amazon S3)에 JSON 형식의 보고서 파일을 생성합니다. 이 파일을 열면 Amazon CloudWatch, 고정 IP 주소, 서버별 데이터베이스 연결 등의 클라우드 기반 서비스 대신 Windows 파일 시스템 경로를 사용하여 로그 파일에 액세스와 같은 안티 패턴이 표시됩니다.

코드 분석 후 제안된 권장 사항은 서버 검사만을 기반으로 한 권장 사항에서 약간 업데이트됩니다. 리플랫폼 접근 방식에 대해 원래 권장되었던 애플리케이션 구성 요소 중 하나가 이제 리팩터링 후보가 되었습니다.

관심 있는 서버로 돌아가서 전략 옵션(Strategy options) 탭을 클릭하면 권장 사항이 표시됩니다. 코드 분석 결과는 내 비즈니스 우선 순위와 함께 가중치 측정에 중요한 역할을 했습니다. 아래 이미지는 서버 자체의 분석만을 기반으로 하는 초기 권장 사항을 보여줍니다.

다음은 소스 코드 분석 후 수정된 서버 권장 사항입니다.

서버에 대한 권장 사항에는 애플리케이션의 SQL Server 데이터베이스를 Amazon Relational Database Service(RDS)의 MySQL로 리플랫폼하는 것도 포함됩니다. 내 우선 순위에서 관리형 서비스에 대한 고려를 요청했기 때문에 이 방법이 제안되었습니다. 이 권장 사항을 따르기 전에 데이터베이스에 대한 추가 안티 패턴 분석을 수행할 수 있습니다.

이 분석은 데이터베이스 자격 증명을 보유하기 위해 AWS Secrets Manager에서 보안 암호를 생성한 후 수행할 수 있습니다(자세한 내용은 사용 설명서의 데이터베이스 분석 주제 참조). 현재 SQL Server에 대해서만 사용할 수 있는 데이터베이스 분석에서는 지원되지 않는 데이터 형식 등의 마이그레이션 비호환성을 식별합니다.

스크린샷에서 마이그레이션 및 현대화를 위한 추가적인 실행 가능 경로를 확인할 수 있습니다. 이는 서버와 애플리케이션 구성 요소 모두에 적용됩니다. 원하는 경우 실행 가능한 전략 옵션을 선택하고 선호하는 방식 설정(Set preferred)을 클릭하여 권장 전략에 대한 실행 가능 경로를 선택할 수 있습니다.

아래 스크린샷에서는 nopCommerce 애플리케이션 구성 요소에 대해 AWS App2Container를 사용하여 애플리케이션의 컨테이너에 대한 리플랫폼 경로를 선호하도록 선택했습니다. 물론 시작 지점으로 되돌아가 비즈니스 우선 순위와 기타 옵션을 조정하고 데이터를 다시 분석할 수 있습니다.

초기 권장 사항을 적용한 다음 코드 및 데이터베이스 분석을 사용하거나 분석 우선 순위 및 제안된 권장 사항을 수정하는 방식을 사용하면 클라우드에 대한 애플리케이션 포트폴리오 마이그레이션 및 현대화와 관련된 최적의 전략을 찾기 위해 여러 가지 ‘조건 설정(What if)’ 옵션을 실험해 볼 수 있습니다. 최적의 전략이 결정되면 다운스트림 팀에 전달하여 애플리케이션 포트폴리오의 마이그레이션 및 현대화 프로세스를 시작할 수 있습니다.

지금 바로 마이그레이션 및 현대화에 대한 권장 사항 보기
추가 비용 없이 AWS Migration Hub Strategy Recommendations를 통해 지금 바로 서버 및 애플리케이션 포트폴리오 분석을 시작할 수 있습니다. 사용 가능한 리전은 미국 동부(버지니아 북부), 미국 서부(오레곤), 아시아 태평양(시드니), 아시아 태평양(도쿄), 유럽(프랑크푸르트), 유럽(아일랜드) 및 유럽(런던) 리전입니다.

물론 해당 도구에 따른 권장 사항을 기반으로 마이그레이션 및 현대화하도록 선택한 애플리케이션을 모든 리전에 배포할 수 있습니다. 앞서 언급했듯이 사용 설명서에서 사전 요구 사항, 수집기 시작 및 권장 사항 작업에 대한 자세한 내용을 확인할 수 있습니다.

— Steve

Source: AWS Migration Hub – 클라우드 마이그레이션 전략 추천 기능 출시