클라우드 마이그레이션 전략 선택

명확한 인벤토리와 워크로드에 대한 이해를 통해 클라우드 채택 계획은 클라우드의 각 워크로드로 수행할 작업을 결정해야 합니다. 클라우드 마이그레이션의 "Rs"라고도 하는 여러 마이그레이션 전략이 있습니다. 각 워크로드는 사용 중지, 보존, 다시 호스팅, 재배치, 리팩터링, 다시 보관, 다시 작성 또는 교체될 수 있습니다. 이 섹션에서는 각 워크로드에 적합한 방법을 선택하고, 옵션을 제시하고, 각각을 선택하는 시기 및 장단점을 제시하는 방법을 안내합니다.

마이그레이션 전략 개요

다음 표에서는 사용 가능한 모든 클라우드 마이그레이션 전략에 대한 개요를 제공합니다. 이 참조를 사용하여 각 전략의 주요 비즈니스 드라이버 및 워크로드에 각 접근 방식을 적용할 시기를 알리는 주요 지표를 이해합니다.

마이그레이션 전에 비즈니스 드라이버 확인

비즈니스 드라이버는 특정 비즈니스 목표를 지원하기 위해 워크로드를 변경해야 하는 이유를 정의합니다. 비즈니스 동인은 클라우드 채택 결정을 측정 가능한 비즈니스 가치 및 전략적 목표에 연결합니다. 이러한 드라이버를 식별하면 마이그레이션 작업이 목적이 있고 조직의 우선 순위에 맞게 조정됩니다.

1. 비즈니스 목표를 정의합니다. 비즈니스 목표는 AI 채택, 민첩성 향상, 혁신 가속화, 비용 절감 및 복원력 향상과 같은 클라우드 채택을 통해 조직에서 달성하고자 하는 높은 수준의 결과입니다. 이러한 목표는 모든 마이그레이션 결정에 대한 전략적 컨텍스트를 제공합니다. 전략적 계획 문서, 임원 인터뷰 또는 비즈니스 사례 워크샵을 사용하여 관련자와 이러한 목표를 식별하고 유효성을 검사합니다.

2. 간격을 식별합니다. 높은 수준의 간격 분석을 수행하여 정의된 비즈니스 목표를 더 잘 지원하기 위해 각 워크로드가 변경해야 하는 사항을 이해합니다. 이 분석은 현재 성능, 확장성, 규정 준수, 사용자 환경 및 아키텍처 제한을 고려해야 합니다. 워크로드가 원하는 결과를 완전히 실현하지 못하게 하는 결함을 문서화합니다.

3. 비즈니스 주요 요소를 확인합니다. 비즈니스 드라이버는 워크로드의 현재 상태와 원하는 미래 상태 사이의 격차에서 비롯됩니다. 이는 특정한 실행 가능한 변경 이유를 나타냅니다. 이러한 드라이버는 적절한 마이그레이션 전략의 선택을 안내합니다.

   비즈니스 드라이버	마이그레이션 전략
   중복 또는 낮은 값의 워크로드를 해제해야 합니다.	Retire
   최소한의 비즈니스 중단이 필요하고 근래에 현대화가 필요하지 않습니다.	Rehost
   유지 관리를 오프로드하고 안정성을 용이하게 하기 위해 PaaS 솔루션 및 최소한의 코드 변경이 필요합니다.	플랫폼 재구축
   기술 문제를 줄이거나 클라우드용 코드를 최적화하려면 코드 변경이 필요합니다.	Refactor
   클라우드 네이티브 기능의 잠금을 해제하려면 아키텍처 변경이 필요합니다.	Rearchitect
   작업을 간소화하기 위해 SaaS/AI 솔루션 필요	Replace
   요구 사항을 충족하려면 새로운 클라우드 네이티브 솔루션이 필요합니다.	Rebuild
   안정성이 필요하고 변화가 없음	Retain

올바른 마이그레이션 전략 선택

마이그레이션 전략은 각 워크로드가 비즈니스 드라이버에 따라 Azure로 전환하는 방법을 정의합니다. 좁아진 전략 목록을 검토하고 비즈니스 및 기술 관련자와 함께 선택한 옵션의 유효성을 검사합니다. 규정 준수, 보안 또는 운영 제약 조건과 충돌하는 옵션을 제거합니다. 전략을 마무리할 때 Azure 준비 상태, 팀 기술 및 통합 복잡성을 고려합니다.

1. 사용 중지(서비스 해제)

더 이상 비즈니스 가치를 제공하지 않는 서비스 해제 워크로드를 사용 중지합니다. 이 전략은 워크로드가 오래되었거나, 충분히 사용되지 않거나, 중복되는 경우에 중요합니다. 워크로드가 사용되지 않으며 다른 시스템에 영향을 주는 중요한 종속성이 없는지 확인하여 이 결정의 유효성을 검사합니다. 워크로드를 해제할 때 인벤토리를 업데이트합니다.

2. 리호스팅(동일한 형태의 마이그레이션)

재호스트 전략을 사용하면 최소한의 변경으로 워크로드를 Azure로 이동하여 빠르고 낮은 위험 마이그레이션을 수행할 수 있습니다. 다시 호스팅은 가상 머신을 IaaS로, IaaS를 IaaS로, PaaS를 PaaS로 이동하는 동일한 마이그레이션입니다.

1. 문제가 있는 워크로드를 다시 호스팅하지 마세요. 다시 호스트는 기존 성능, 안정성 또는 아키텍처 문제를 해결하지 않습니다. 현대화 없이 이러한 워크로드를 마이그레이션하면 기술적인 부담을 지고 나중에 재작업이 필요할 수 있습니다. 대신 마이그레이션 중에 이러한 워크로드를 현대화하여 근본 원인을 해결합니다.

2. 워크로드에 2년 이내에 현대화가 필요하지 않은지 확인합니다. 다시 호스팅은 워크로드가 최소 2년 동안 현재 상태로 유지된다는 확신이 있는 경우에만 적합합니다. 현대화 가능성이 있는 경우 중복 작업을 방지하기 위해 리팩터링 또는 다시 조정을 고려하세요.

3. 다시 호스팅을 사용하여 기본 클라우드 작업을 빌드합니다. 다시 호스팅을 사용하면 팀이 Azure 운영, 거버넌스 및 비용 관리에 대한 경험을 쌓을 수 있습니다. 이러한 초기 노출은 광범위한 클라우드 채택 목표를 지원하고 팀이 보다 복잡한 현대화 노력을 준비하도록 준비합니다.

3. 다시 배치(호스팅 환경 현대화)

다시 배치하면 최소한의 코드 변경으로 워크로드가 최신 호스팅 환경으로 이동합니다. 이 전략은 전체 애플리케이션을 다시 작성하지 않고 인프라 관리를 줄이고 확장성을 개선하며 작업을 간소화하려는 경우에 중요합니다.

PaaS 옵션이 운영 오버헤드를 줄이거나 안정성을 개선하거나 재해 복구를 간소화하는 워크로드를 선택합니다. PaaS 서비스를 활용하려면 최소한의 코드 리팩터링이 필요할 수 있습니다.

4. 리팩터링(코드 현대화)

리팩터링하면 새 기능을 추가하지 않고 코드의 내부 구조가 향상됩니다. 이 방법은 팀이 레거시 코드를 현대화하고, 기술 부채를 줄이고, Azure에서 장기적인 유지 관리를 위해 워크로드를 준비하는 데 도움이 되므로 클라우드 채택 중에 중요합니다. 마이그레이션 프로세스에서 기술 문제를 해결할 수 있는 고유한 기회를 만들거나 마이그레이션 후 동작에 개선 영역이 표시될 때 코드를 리팩터링해야 합니다.

5. 아키텍처 변경(아키텍처 및 코드 현대화)

다시 아키텍처 전략은 확장성, 민첩성 및 서비스 방향을 개선하기 위해 워크로드의 아키텍처를 재설계합니다. 이 전략은 모놀리식 애플리케이션을 분해하거나, 마이크로 서비스를 채택하거나, 대상 크기 조정을 사용하도록 설정해야 하는 경우에 중요합니다. 현재 아키텍처가 비즈니스 목표를 달성하거나 효과적으로 확장하는 능력을 제한하는 경우 다시 아키텍처를 지정해야 합니다. 예를 들어 최신 웹앱 패턴을 참조하세요.

6. 바꾸기(SaaS 대체 사용)

대체 전략은 상업용 SaaS 솔루션을 사용하여 사용자 지정 개발 및 지속적인 유지 관리의 필요성을 제거합니다. 이 전략은 SaaS 제품이 최소한의 사용자 지정으로 비즈니스 요구를 충족하는 경우에 이상적입니다. SaaS 솔루션이 비슷한 기능을 제공하고, 통합 기능이 요구 사항을 충족하고, 총 소유 비용이 전환을 정당화할 때 워크로드를 대체합니다. 대체 옵션을 평가할 때 데이터 마이그레이션 복잡성, 사용자 교육 요구 사항 및 프로세스 변경을 고려합니다. 일반적인 대체 시나리오에는 CRM 시스템, HR 플랫폼 및 SaaS 완성도가 사용자 지정 솔루션에 대한 신뢰할 수 있는 대안을 제공하는 협업 도구가 포함됩니다.

7. 다시 빌드(클라우드 네이티브로 구축)

다시 빌드 전략은 클라우드 네이티브 솔루션을 사용하여 워크로드를 완전히 재개발하는 것입니다. 이 방법은 레거시 시스템이 사용되지 않거나 현대화가 불가능할 때 적합합니다. 레거시 기능을 현대화하는 대신 PaaS, 자동화 및 AI와 같은 Azure 기능을 사용하도록 솔루션을 다시 상상할 수 있습니다. 일부 워크로드에는 DHCP 서버와 같은 다시 빌드가 필요했습니다. 다른 워크로드의 경우 Active Directory 도메인 컨트롤러와 같이 새 서비스 인스턴스를 마이그레이션하는 대신 Azure에 배포하는 것이 좋습니다.

8. 보존(있는 그대로 유지)

유지 전략은 워크로드가 안정적이고 규정을 준수하며 단기적인 이동 동인이 없는 모든 현재 및 미래의 비즈니스 요구 사항을 충족할 때 현재 환경에서 워크로드를 유지합니다. 규제 제약 조건, 기술 종속성 또는 비즈니스 연속성 요구 사항으로 인해 마이그레이션할 수 없는 워크로드를 유지해야 합니다. Azure Arc를 사용하여 Azure에서 유지되는 온-프레미스 워크로드를 관리하여 통합 관리 기능을 제공합니다. 워크로드에 대한 Azure Local 과 같은 최신 온-프레미스 솔루션을 고려하고 Azure에 연결합니다. 다른 마이그레이션 웨이브로 마이그레이션할 수 없는 워크로드를 이동하거나 제약 조건이 변경되면 나중에 다시 방문합니다.

마이그레이션 중에 현대화해야 하는 시기 이해

마이그레이션 중 현대화는 클라우드 가치를 최대화하기 위해 워크로드를 다시 배치, 다시 관리 또는 리팩터링하는 것을 의미합니다. 현대화는 장기적인 이점을 제공할 수 있지만 마이그레이션 타임라인에 복잡성과 위험을 초래합니다. 명확한 비즈니스 근거에 따라 마이그레이션 중에 현대화할지 또는 마이그레이션 후 단계로의 현대화를 연기할지 평가해야 합니다. 다음 권장 사항을 따릅니다.

1. 팀에 필요한 기술과 시간이 있는 경우 현대화합니다. 적절한 전문 지식이나 시간 없이 현대화를 시도하면 위험과 지연이 증가합니다. 팀에 준비 상태가 부족한 경우 현대화를 이후 단계로 연기합니다.

2. 호환성 업데이트가 필요한 워크로드를 현대화합니다. 레거시 기술, 지원되지 않는 SDK 또는 SaaS 솔루션을 채택해야 하는 경우 현대화가 필요할 수 있습니다. 명확한 비즈니스 사례로 각 노력을 정당화합니다.

3. 마이그레이션을 통해 자금 조달 및 조정을 가능하게 하는 시기를 현대화합니다. 마이그레이션 프로젝트는 종종 자금 및 관련자 지원의 잠금을 해제합니다. 이 기회를 사용하여 현대화를 비즈니스 우선 순위에 맞게 조정합니다. 지연으로 인해 비효율적인 워크로드가 발생할 수 있으며 기회를 놓칠 수 있습니다.

관련자에게 의사 결정 전달

명확한 커뮤니케이션을 통해 모든 이해 관계자가 채택 프로세스 전체에서 마이그레이션 결정을 이해하고 지원할 수 있습니다. 이해 관계자 맞춤은 우선 순위 및 제약 조건에 대한 공유 이해를 설정하여 실행 위험을 줄이고 프로젝트 결과를 개선합니다. 마이그레이션 프로세스 전체에서 맞춤을 유지하려면 구조화된 통신 계획을 설정해야 합니다. 다음 권장 사항을 따릅니다.

1. 비즈니스 결과의 유효성을 검사하는 성공 메트릭을 정의합니다. 성공 메트릭은 선택한 작업의 값을 정량화하고 비즈니스 드라이버가 달성되었는지 여부를 확인합니다. 이 단계는 의사 결정이 기술 완성이 아닌 비즈니스 가치를 기반으로 함을 보장합니다. 다음과 같은 메트릭을 사용합니다.

   클라우드 마이그레이션 전략	성공 메트릭 예제
   Retire	• 마이그레이션 전에 사용되지 않는 것으로 확인된 워크로드의 100개% 사용 중지
   Rehost	• SLA(서비스 수준 계약) 성능 저하 없이 다른 클라우드에서 Azure로 계층 1 워크로드의 100개% 마이그레이션 • 마이그레이션 후 온-프레미스 인프라의 30% 서비스 해제.
   플랫폼 전환	• 마이그레이션된 애플리케이션에 대한 배포 리드 시간을 30% 줄입니다. • 12개월 이내에 인프라 및 라이선스 비용 25% 절감
   Refactor	• Azure 네이티브 서비스를 사용하여 애플리케이션 응답 시간을 40% 개선 • 코드 계측을 통해 95% 관찰 가능성 달성
   Rearchitect	• 성능 저하 없이 2배 사용자 로드 지원 • 기존 아키텍처에 세 가지 새로운 Azure 네이티브 서비스 통합
   Replace	• 99.9% 가동 시간 및 사용자 지정 코드가 없는 SaaS로 CRM 전환 • 개발 노력의 30% 경쟁 차별화 요인으로 전환합니다.
   Rebuild	• 클라우드 네이티브 애플리케이션을 3개월 내에 출시 대 온-프레미스에서는 6개월 소요 • PaaS 서비스를 사용하여 운영 비용을 40% 절감
   유지	• 현재 SLA 및 규정 준수 상태 유지 관리 • Azure Arc를 사용하여 Azure에서 온-프레미스 워크로드 관리

2. 모든 관련 이해 관계자와 워크로드 처리 결정을 문서화하고 공유합니다. 마이그레이션 결정은 여러 조직 기능에 영향을 줄 수 있으며 광범위한 관련자 입력이 필요할 수 있습니다. 의사 결정 통신에 비즈니스 소유자, 법률 팀, 보안 팀 및 기술 리더를 포함합니다. 각 마이그레이션 전략 결정이 문서화된 비즈니스 목표를 지원하고 관련자 문제를 해결하는 방법을 설명합니다.

3. 클라우드 전략 팀과 마이그레이션 계획을 조정합니다. 클라우드 전략 팀은 조직의 컨텍스트를 제공하고 마이그레이션 결정이 더 광범위한 클라우드 채택 목표에 부합하도록 보장합니다. 정기적인 조정은 개별 워크로드 결정과 엔터프라이즈 전체 클라우드 전략 간의 충돌을 방지합니다. 일관성을 유지하기 위해 전략 단계에서 설정된 클라우드 채택 계획에 대한 마이그레이션 전략 선택을 검토합니다.

4. 위임 소유자와 실행 팀 간에 정기적인 통신을 설정합니다. 의사 결정자와 구현자 간의 지속적인 통신은 기술 현실이 등장함에 따라 계획이 실행 가능한 상태로 유지되도록 합니다. 마이그레이션 진행 상황을 추적하고, 위험을 식별하고, 기술 문제를 해결하도록 정기적인 진행률 검토를 예약합니다. 이 피드백 루프를 사용하여 구현 과제 또는 새로운 기회가 발생할 때 마이그레이션 전략을 조정합니다.

5. 진화하는 요구 사항에 따라 마이그레이션 전략을 검토하고 업데이트합니다. 비즈니스 우선 순위 및 기술 인사이트는 마이그레이션 프로세스 전반에 걸쳐 변경되어 전략을 조정해야 합니다. 정기적인 검토 주기를 설정하여 현재 비즈니스 목표 및 기술 기능에 대한 워크로드 처리 결정을 재평가합니다. 새로운 우선 순위, 학습된 교훈 및 변화하는 조직의 요구 사항을 반영하도록 전략 매핑을 업데이트합니다.

다음 단계