일반적 기술 플랫폼
조직의 마이그레이션 중에는 다양한 기술 플랫폼에 대비해야 합니다. 대부분의 마이그레이션은 Windows 및 SQL Server 자산으로 시작하지만 현재 작동 중인 대부분의 데이터 센터에는 Windows 기반이 아닌 여러 플랫폼도 있습니다.
이 단원에서는 Microsoft의 통합 마이그레이션 방식을 간략하게 설명합니다. 이 접근 방식에서는 기본 기술 플랫폼과 관계없이 모든 워크로드에 명확한 클라우드 마이그레이션 경로가 있어야 합니다.
통합 마이그레이션 중심
대부분의 마이그레이션 팀은 Windows 및 SQL Server 자산의 마이그레이션을 촉진하는 Azure Migrate 및 Azure Migrate 허브의 기능을 알고 있습니다. 그러나 마이그레이션을 시작하기 전에 동일한 마이그레이션 팩터리 방식이나 동일한 마이그레이션 프로세스를 사용할 수 있는 다른 기술 플랫폼에 대해 잘 알고 있어야 합니다.
다음 다이어그램과 표는 마이그레이션 및 현대화에서 동일한 반복 마이그레이션 방법론을 따르는 여러 시나리오를 간략하게 보여 줍니다. 이 모듈 마지막의 요약에는 이러한 기술 플랫폼에 대한 지속적인 학습을 위한 링크가 포함되어 있습니다.
그림 1: Migrate 방법론에서 지원하는 기술 플랫폼
| 가상 머신 | 애플리케이션 | 데이터 | 하이브리드 | 기술 플랫폼 | 추가 시나리오 |
|---|---|---|---|---|---|
| Windows Server를 실행하는 서버 | ASP.NET | SQL Server | Azure Stack | SAP(클래식 및 HANA) | 보안 워크로드 |
| Linux 서버 | Java | OSS(오픈 소스 시스템) 데이터베이스 | VMware | Kubernetes | 다중 테넌트 환경 |
| 가상 데스크톱 | PHP | 분석 | 메인프레임 | NetApp |
일반적 기술 플랫폼 준비
기술 플랫폼마다 마이그레이션을 실행해야 하는 방법이 미묘하게 다를 수 있습니다. 이러한 고려 사항을 참조하기 위해 이 모듈 뒷부분의 요약 단원에 있는 링크를 책갈피 설정할 수 있습니다. 지금은 이 단원에서 기술 플랫폼이 상위 수준에서 마이그레이션에 어떤 영향을 줄 수 있는지 이해할 수 있습니다.
다음은 영향을 보여 주는 몇 가지 예입니다.
워크로드 평가: 각 웨이브의 워크로드를 평가하는 동안 설계자는 주로 Azure 호환성과 자산 간의 종속성을 찾습니다. 하지만 현대화 및 최적화 기회와의 호환성도 찾아야 합니다.
Tailwind Traders 사례에서 팀은 데이터 호스팅을 전담하는 인프라의 양을 최소화하기 위해 각 데이터베이스의 Azure SQL Database와의 호환성을 평가합니다. OSS 데이터베이스는 Azure SQL Database에서 지원하는 다양한 데이터베이스 형식 덕분에 잠재적으로 여러 현대화를 제공합니다.
워크로드 배포: 마이그레이션 중 또는 알려진 대로 배포하는 동안 팀은 주로 Azure Migrate 도구를 사용하여 VM, 애플리케이션 및 데이터와 같은 자산을 Azure로 마이그레이션합니다. 일부 기술 플랫폼에는 무료 도구가 필요할 수도 있습니다.
Tailwind Traders 팀은 SAP 플랫폼을 마이그레이션할 때 Azure의 SAP HANA로 원활하게 마이그레이션할 수 있도록 해당 마이그레이션 도구 상자에 SAP DMO(데이터베이스 마이그레이션 옵션)를 추가합니다.
워크로드 릴리스: 각 기술 플랫폼과 워크로드가 Azure로 마이그레이션되면 팀은 새로 마이그레이션된 워크로드로의 프로덕션 트래픽을 테스트, 최적화, 릴리스해야 합니다. 일부 플랫폼에서는 팀이 워크로드 운영을 명확히 파악할 수 있도록 어느 정도 다양한 모니터링 도구가 필요할 수 있습니다.
Tailwind Traders 팀이 가상 데스크톱을 마이그레이션할 때 Lakeside Software 같은 Azure Migrate 파트너 솔루션을 사용할 가능성이 큽니다. 이러한 파트너 솔루션을 사용하면 성능을 추적하고 마이그레이션할 다른 워크로드를 파악하여 뛰어난 사용자 환경을 제공할 수 있습니다.
스프린트 계획에서 다양한 기술 플랫폼에 대비
이러한 기술 플랫폼 각각에 동일한 방법론이 적용됩니다. 초기 클라우드 채택 계획 중에는 이러한 차이에 대비하기 위한 작업을 거의 하지 않습니다. 일반적으로 개별 기술 플랫폼은 해당 수준의 계획에 실질적으로 영향을 주지 않습니다.
그러나 이러한 플랫폼 중 일부를 사용하여 성공하는 데 필요한 기본 작업에는 미묘한 차이가 있습니다. 이러한 차이점은 다음과 같은 중요 계획 활동에서 해결되며, 이는 스프린트 계획에 도움이 됩니다.
우선 순위 맞춤: 전체 클라우드 채택 계획은 비즈니스 영향에 따라 마이그레이션할 워크로드의 순서를 간략하게 설명하지만 우선 순위는 팀의 실행 능력도 고려해야 합니다.
마이그레이션 팀은 스프린트를 시작하기 전에 각 워크로드를 마이그레이션하는 데 필요한 기술 플랫폼을 평가해야 합니다. 가능하면 기술 플랫폼을 기준으로 마이그레이션 우선 순위를 그룹 워크로드 웨이브로 다시 정렬해야 합니다. 예를 들어 스프린트 1~3에서 Windows 및 SQL Server 인스턴스를 마이그레이션한 다음, 스프린트 4~6에서 Linux 서버 및 OSS 데이터를 마이그레이션합니다.
Important
이런 방식으로 우선 순위를 재조정하는 것이 항상 가능한 것은 아닙니다. 워크로드를 마이그레이션하기 위해 Windows 자산과 OSS 자산이 함께 필요한 상황이 있을 수 있습니다. 이러한 상황에서는 해당 워크로드를 단일 결과물로 포함하여 유지하는 것이 가장 좋습니다. 복잡한 워크로드를 이후 스프린트로 옮겨서 팀이 필요한 기술을 개발할 시간을 확보하도록 할 수 있습니다.
현대화 검토: 마이그레이션이 세 가지 작업 영역(평가, 배포 및 릴리스)을 모두 단일 마이그레이션 팀과 단일 마이그레이션 스프린트로 그룹화하는 경우 각 스프린트 계획에 현대화 검토를 포함해야 합니다.
이 유형의 검토에서 팀은 PaaS(Platform as a Service) 옵션으로의 현대화에 초점을 맞춰 마이그레이션할 자산을 평가합니다. 예를 들어 인프라에 대한 종속성을 최소화하기 위해 SQL Server나 OSS 데이터베이스를 Azure SQL Database로 변환해야 할까요? IaaS(Infrastructure as a Service) 서버에서 웹앱 또는 컨테이너 인스턴스로 애플리케이션을 이동해야 할까요? 각 결정에 따라 일반적 기술 플랫폼 각각을 활용하는 방법이 구성됩니다.