다음을 통해 공유


클라우드 채택 여정

클라우드 채택 과정은 비슷한 궤적을 따르는 경향이 있습니다. 변형이 있지만 다른 사용자가 클라우드를 채택하는 방법을 확인하는 것은 여전히 유용할 수 있습니다. 먼저 해결해야 할 워크로드와 이를 통해 수행할 작업을 알면 클라우드 채택 과정을 간소화할 수 있습니다.

Diagram showing portfolio migration modernization approach.

올바른 클라우드 솔루션을 채택할 때 중요한 고려 사항은 제어와 생산성의 균형입니다. IaaS(Infrastructure as a Service) 솔루션은 가장 많은 제어를 제공하지만 기본 더 많은 시간이 필요합니다. PaaS(Platform as a Service) 및 SaaS(Software as a Service) 솔루션은 관리 책임을 Azure로 이전하고 팀이 생산성에 집중할 수 있도록 합니다. 제어와 생산성 간에 필요한 균형은 모든 조직마다 다르며, 우선 순위가 변경되면 시간이 지남에 따라 변경됩니다.

초기 클라우드 채택의 경우 일반적인 조직은 애플리케이션의 35%를 사용 중지하고, 포트폴리오의 15%를 대체하며, 50%를 필요한 수정(다시 배치 또는 다시 호스트)으로 마이그레이션합니다.

사용 중지(35%)

조직에 필요하지 않은 워크로드를 사용 중지합니다. 검색을 수행하고 인벤토리를 가져와서 투자할 가치가 없는 애플리케이션 및 환경을 찾아야 합니다. 비용 및 시간 효율성은 은퇴의 목표입니다. 팀은 클라우드로 이동하기 전에 포트폴리오를 축소할 때 가장 중요한 자산에 집중할 수 있습니다.

바꾸기(10%)

대부분의 조직은 애플리케이션의 약 10%를 SaaS(Software as a Service) 및 로우 코드 솔루션으로 대체합니다. 보다 생산적인 솔루션을 채택하여 목표를 더 쉽게 달성할 수 있습니다.

표 1 - 워크로드를 SaaS 및 로우 코드 솔루션으로 바꾸는 예제

보낸 사람 수행할 작업
사용자 지정 줄
비즈니스(LOB)
애플리케이션
Power Apps
DevOps 도구 GitHub
관계
관리
Dynamics 365
산업
검색 범주
타사
Saas

다시 작성 또는 다시 작성(5%)

필수 비즈니스 애플리케이션을 SaaS 또는 로우 코드 솔루션으로 효과적으로 대체할 수 없는 경우 애플리케이션을 다시 설계하거나 다시 빌드하는 것이 좋습니다. 다시 설계 또는 다시 빌드는 복잡하지만 클라우드 기술을 최대한 활용하는 데 중요합니다. 기본 목표는 이러한 애플리케이션을 클라우드에 맞게 조정하는 것입니다. 이 방법에는 다음과 같은 몇 가지 주요 측면이 포함됩니다.

  • 확장성: 다양한 수요 수준을 효율적으로 처리하도록 애플리케이션을 조정합니다.
  • 안정성: 실패 없이 일관되게 작동하는 애플리케이션의 기능을 개선합니다.
  • 보안: 고급 보안 조치를 통합하여 클라우드에서 데이터 및 작업을 보호합니다.

이 단계에서는 생성 AI와 같은 고급 기술을 통합할 수도 있습니다. 통합 솔루션은 중요한 방법으로 애플리케이션 기능을 향상시킬 수 있습니다. AI 기술의 예는 다음과 같습니다.

  • 예측 분석: AI를 사용하여 고객의 요구를 예측합니다.
  • 프로세스 자동화: AI를 사용하여 비즈니스 프로세스를 자동화합니다.

다시 설계하거나 다시 빌드하면 클라우드 네이티브 기능의 전체 범위와 AI 기반의 발전을 활용할 수 있습니다.

다시 호스팅 또는 재배치(50%)

일반적인 비즈니스는 기존 워크로드의 약 절반을 마이그레이션합니다. 이러한 워크로드 내에는 일반적으로 세 가지 난이도 계층이 있습니다. 약 35%는 이동하기 쉽습니다. 다음 10%는 더 복잡하거나 더 중요하기 때문에 더 어렵고, 마지막 5%만 실행하기 위한 추가 계획이 필요합니다.

마이그레이션 방법에는 여러 가지가 있습니다. 다시 호스팅("리프트 앤 시프트") 및 재배치("현대화")가 가장 일반적이며 클라우드 채택에 권장되는 접근 방식입니다. 그러나 요구 사항을 충족하는 방법을 결정하는 것은 어려울 수 있으므로 적합한 접근 방식을 결정하는 방법에 대한 지침이 있습니다. 자세한 내용은 마이그레이션 또는 현대화를 참조 하세요.

첫 번째 이동(35%)

첫 번째 워크로드를 이동하려면 쉬운 우선을 선택하는 것이 좋습니다. 이 전략을 사용하면 더 복잡한 워크로드를 처리하기 전에 더 쉬운 애플리케이션에 대한 채택 계획을 평가할 수 있습니다. 작업할 때 성공을 문서화하고 필요한 경우 전략을 수정해야 합니다. 이러한 인사이트를 더 복잡한 이동에 적용합니다. 첫 번째 이동에 포함할 수 있는 워크로드의 두 가지 예는 기본 웹앱과 고급 포털입니다.

  • 기본 웹앱: 기본 웹 애플리케이션을 다시 호스트하고 기본 웹앱을 이동할 때까지 더 복잡한 워크로드를 이동하는 것이 좋습니다. Azure App Service는 대부분의 애플리케이션을 호스트할 수 있는 유연한 애플리케이션 플랫폼입니다. 기본 웹 애플리케이션에는 이 솔루션을 사용하는 것이 좋습니다. 자세한 내용은 Azure App Service를 참조하세요.

  • 고급 포털: 생산성을 높이려면 포털을 Power Apps 포털로 마이그레이션해야 합니다.

다음 이동(10%)

더 까다롭거나 더 중요한 워크로드를 처리하기 위해 첫 번째 이동에서 배운 교훈을 적용해야 합니다. 워크로드 유형을 파악할 수 있는 몇 가지 예제가 있습니다.

  • 높은 비즈니스 영향: 수익을 창출하거나 중요 업무용 워크로드입니다.

  • 높은 입출력(I/O) OLTP(온라인 트랜잭션 처리) 시스템: 이러한 워크로드는 비즈니스 트랜잭션을 기록하고 높은 처리 요구 사항을 가지고 있습니다.

  • 규제 정보: 이러한 워크로드는 HIPAA, PCI DSS 등과 같은 법률 및 업계 표준을 따라야 합니다. Azure Policy를 사용하여 이러한 표준을 준수하는 것이 좋습니다. 자세한 내용은 Azure Policy를 참조하세요.

이동하기 어렵거나 비용이 많이 드는 경우(5%)

가장 어렵고 비용이 많이 드는 워크로드는 마지막으로 이동합니다. 다음 시스템은 효율적으로 이동하기 위해 더 많은 생각이 필요할 수 있습니다.

  • HVA(고부가가치 자산): 이 워크로드의 중단 또는 손상으로 인해 모든 비즈니스 운영이 중단됩니다.

  • PKI(공개 키 인프라) 시스템: x509 디지털 인증서, 네트워크 암호화 및 인증을 관리하는 워크로드입니다.

  • 레거시 소스 제어: GitHub로 쉽게 대체되지 않는 소스 제어 시스템입니다.

  • 현대화할 수 없음: 현대화할 수 없는 레거시 또는 독점 기술입니다.

  • 심층 아키텍처 변경: 아키텍처를 완전히 다시 디자인해야 하는 레거시 아키텍처입니다. CAF 현대화 방법 대신 Microsoft Azure Well-Architected Framework를 사용합니다.

추가 리소스

다음 단계