마이그레이션 전에 워크로드 아키텍처 디자인

이 문서에서는 클라우드에서 워크로드의 의도된 마이그레이션된 상태를 디자인하기 위한 프로세스 및 고려 사항에 대해 설명합니다. 이 문서에서는 반복 내에서 워크로드 아키텍처를 정의하는 작업의 일부인 활동을 검토합니다.

증분 합리화에 대한 문서는 일부 아키텍처 가정이 마이그레이션을 포함하는 모든 비즈니스 변환의 일부임을 나타냅니다. 이 문서에서는 일반적인 가정을 명확하게 설명합니다. 또한 피할 수 있는 몇 가지 장애물을 가리키며 아키텍처 가정에 도전하여 비즈니스 가치를 가속화할 수 있는 기회를 식별합니다. 아키텍처를 디자인하기 위한 이 증분 모델은 팀이 더 빠르게 이동하고 비즈니스 결과를 더 빨리 얻을 수 있도록 도와줍니다.

일반적인 가정을 기반으로 하는 기본 아키텍처 디자인

다음 가정은 모든 마이그레이션 작업에서 일반적으로 발생합니다.

• IaaS(Infrastructure as a Service) 워크로드를 가정합니다. 워크로드 마이그레이션에는 주로 IaaS 마이그레이션을 통해 물리적 데이터 센터에서 클라우드 데이터 센터로 서버를 이동하는 작업이 포함됩니다. 이 프로세스는 일반적으로 최소한의 재개발 또는 재구성이 필요합니다. 이 접근 방식을 리프트 앤 시프트 마이그레이션이라고 합니다.
• 아키텍처를 일관되게 유지합니다. 마이그레이션 중에 핵심 아키텍처를 변경하면 복잡성이 상당히 증가합니다. 새 플랫폼에서 변경된 시스템을 디버깅하면 격리하기 어려울 수 있는 많은 변수가 도입됩니다. 워크로드는 마이그레이션 중에 사소한 변경만 수행해야 하며 모든 변경 내용을 철저히 테스트해야 합니다.
• 자산 크기를 조정하도록 계획합니다. 모든 리소스를 완전히 사용하는 온-프레미스 자산은 거의 없다고 가정합니다. 마이그레이션 전 또는 마이그레이션 중에 자산의 크기가 실제 사용량 요구 사항에 가장 적합하도록 조정됩니다. Azure Migrate 및 Modernize와 같은 도구는 실제 사용에 따라 크기 조정을 제공합니다.
• BCDR(비즈니스 연속성 및 재해 복구) 요구 사항을 캡처합니다. 비즈니스와 이미 협상된 워크로드에 대해 합의된 SLA(서비스 수준 계약)가 있는 경우 Azure로 마이그레이션한 후에도 SLA를 계속 사용합니다. SLA가 아직 설정되지 않은 경우 클라우드에서 워크로드를 디자인하기 전에 SLA를 정의하여 적절하게 디자인해야 합니다.
• 마이그레이션 가동 중지 시간을 계획합니다. SLA 요구 사항을 충족하지 못하는 것과 마찬가지로 워크로드를 프로덕션으로 승격할 때 발생하는 가동 중지 시간은 비즈니스에 부정적인 영향을 미칠 수 있습니다. 가동 중지 시간을 최소화하면서 전환해야 하는 솔루션에는 아키텍처 변경이 필요한 경우가 있습니다. 릴리스 계획을 시작하기 전에 가동 중지 시간 요구 사항에 대한 일반적인 이해가 설정되었다고 가정합니다.
• 사용자 및 애플리케이션 트래픽 패턴을 정의합니다. 기존 솔루션은 기존 네트워크 라우팅 패턴 및 솔루션에 따라 달라질 수 있습니다. 현재 네트워크 사용을 지원하는 데 필요한 리소스를 식별합니다.
• 네트워크 충돌을 방지하도록 계획합니다. 데이터 센터를 단일 클라우드 공급자로 통합하면 DNS(Do기본 Name System) 또는 기타 네트워킹 구조에서 충돌이 발생할 수 있습니다. 마이그레이션하는 동안 클라우드에서 호스트되는 프로덕션 시스템에 대한 중단을 방지하기 위해 이러한 충돌을 방지하도록 설계하는 것이 중요합니다.
• 테이블 라우팅을 계획합니다. 네트워크 또는 데이터 센터를 통합하는 경우 라우팅 테이블을 수정하기 위한 계획이 프로젝트에 포함되어 있는지 확인합니다. 데이터 센터 간 라우팅 요구 사항을 고려합니다.

랜딩 존의 디자인 아키텍처

클라우드 채택 프레임워크 준비 단계에서 조직은 Azure 랜딩 존 채택의 일환으로 공유 플랫폼 서비스를 배포했습니다. 마이그레이션을 위한 랜딩 존 준비에서 마이그레이션된 워크로드를 수신하도록 랜딩 존을 준비했습니다.

이 계획에 따라 다음 마이그레이션 구성 요소가 준비되어 있다고 가정할 수 있습니다.

• 하이브리드 연결은 Azure 네트워크를 온-프레미스 네트워크에 연결합니다.
• Azure Firewall과 같은 네트워크 보안 어플라이언스 워크로드 외부의 트래픽 검사를 처리합니다.
• 로깅 요구 사항, 허용된 지역, 허용되지 않는 서비스 및 기타 컨트롤과 같은 거버넌스 사례를 적용하는 Azure 정책이 활성화되어 있습니다.
• 공유 로깅에 대한 Azure Monitor 로그 작업 영역이 Azure Monitor에 설정됩니다.
• do기본 조인 서버 또는 기타 ID 요구 사항을 지원하는 공유 ID 리소스가 설정됩니다.

이러한 마이그레이션 필수 구성이 설정되지 않은 경우 조직은 즉시 준비 단계를 다시 검토하여 이러한 요구 사항을 해결해야 합니다. 이러한 구성 요소가 없으면 마이그레이션에 지연과 차질이 발생할 수 있으며 성공도가 낮아질 수 있습니다.

디자인하는 워크로드에는 구독 자동 판매 프로세스를 통해 구독이 할당되어 있습니다. 구독에는 조직에서 워크로드에 대한 리소스 조직을 완료 하는 방법에 따라 여러 워크로드 또는 하나의 워크로드만 포함될 수 있습니다. 애플리케이션 환경이 많은 워크로드를 마이그레이션하는 경우 애플리케이션 환경에 대한 지침에 따라 여러 구독이 있을 수도 있습니다.

워크로드 네트워크 아키텍처 디자인

특정 구독에 애플리케이션별 리소스를 배포하고 워크로드용 전용 가상 네트워크를 설계하도록 계획합니다. 자세한 내용은 네트워킹 아키텍처를 디자인하기 위한 지침을 참조하세요. 특히 가상 네트워크를 분할하는 데 집중해야 합니다.

네트워크에 부하 분산 장치 및 기타 애플리케이션 배달 리소스와 같은 리소스가 필요할 수 있습니다. N 계층 아키텍처 가이드를 사용하여 Azure에서 이러한 리소스를 계획할 수 있습니다.

워크로드 종속성 디자인

마이그레이션 평가 도구는 Azure Migrate 및 현대화의 종속성 분석과 같은 종속성 분석을 수행할 수 있는 방법을 제공해야 합니다. 이 도구를 사용하면 서버 간의 상호 종속성을 식별할 수 있습니다.

워크로드 자체에 대한 아키텍처 계획 외에도 워크로드 종속성을 고려해야 할 수 있습니다. 예를 들어 일부 워크로드에는 빈번한 통신이 필요할 수 있습니다. 그렇다면 이 요구 사항을 고려하여 마이그레이션 웨이브 및 종속성을 계획하면 마이그레이션에 성공하는 데 도움이 됩니다.

스포크-스포크 네트워킹과 같은 Azure 아키텍처 센터의 지침을 사용하여 마이그레이션 후 상호 연결된 워크로드가 작동하는 방식을 디자인할 수 있습니다.

기밀 컴퓨팅 채택 준비

주권 요구 사항이 있는 워크로드의 하위 집합은 기밀 컴퓨팅을 사용할 수 있습니다. 소버린 랜딩 존 배포의 일환으로 기밀 컴퓨팅을 위한 관리 그룹이 만들어집니다.

주권 컨텍스트 내에서 기밀 컴퓨팅을 사용하려면 Azure Key Vault 및 고객 관리형 키를 지원 서비스로 사용해야 합니다. 자세한 내용은 Microsoft Cloud for Sovereignty에서 고객 관리형 키를 사용한 암호화를 참조 하세요.

초기 클라우드 예상 업데이트

아키텍처 디자인을 마치면 클라우드 예상을 다시 검토하여 계획된 예산 내에 있는지 확인합니다. 부하 분산 장치 또는 백업과 같은 지원 서비스를 추가하면 비용이 변경됩니다. Azure Migrate 및 Modernize의 비즈니스 사례와 같은 도구를 사용하여 자세한 비용 관리 연습을 수행할 수 있지만 아키텍처 디자인을 조정할 때 정기적으로 예상을 다시 확인해야 합니다.

기존 IT 조달 프로세스에 익숙한 경우 클라우드의 리소스를 추정하는 것은 외래로 보일 수 있습니다. 클라우드 기술을 채택하면 인수가 경직되고 구조화된 자본 비용 모델에서 유동적인 운영 비용 모델로 전환됩니다. 클라우드로 마이그레이션을 계획하는 것은 조직 또는 IT 팀이 이러한 변경을 처음 접하는 경우가 많습니다.

기존 자본 비용 모델에서 IT 팀은 다양한 프로그램에서 여러 워크로드에 대한 구매력을 결합하려고 시도합니다. 이 방법은 각 솔루션을 지원할 수 있는 공유 IT 자산 풀을 중앙 집중화합니다. 운영 비용 클라우드 모델에서 비용은 개별 워크로드, 팀 또는 사업부의 지원 요구 사항에 직접 기인할 수 있습니다. 조직에서 내부 고객 및 해당 고객이 지원하는 비즈니스 목표에 대한 비용의 보다 직접적인 특성을 제공합니다. 재무 관리에 대한 이러한 보다 역동적인 접근 방식을 종종 재무 운영(FinOps)이라고 합니다. FinOps는 Azure 관련 고려 사항이 아니지만 FinOps를 확장하여 이해하는 것이 유용할 수 있습니다. 자세한 내용은 FinOps란?을 참조하세요.

마이그레이션을 위한 워크로드 아키텍처를 디자인할 때 평가 정보와 함께 가격 계산기를 사용하여 전체 워크로드의 가격을 이해할 수 있습니다.

또한 워크로드를 마이그레이션한 후에도 워크로드 비용을 최적화하기 위해 계속 작업해야 합니다. 조직이 비용 관리 기술을 완성하는 방법에 대한 자세한 내용은 비용 관리 분야 개선을 참조하세요.

아키텍처를 변경해야 하는 경우 파악

마이그레이션은 기존 아키텍처를 기본 클라우드 플랫폼으로 전환하는 데 중점을 두는 경향이 있습니다. 그러나 마이그레이션을 위해 워크로드를 다시 보관해야 하는 경우가 있습니다. 이 목록은 마이그레이션하기 전에 아키텍처를 변경해야 하는 경우의 예를 제공합니다.

• 기술 부채에 대한 지불. 일부 노후화된 워크로드에는 많은 양의 기술적인 부채가 있습니다. 기술적인 문제는 클라우드 공급자의 호스팅 비용이 증가하여 장기적인 문제로 이어질 수 있습니다. 기술적인 문제로 호스팅 비용이 부자연스럽게 증가하는 경우 대체 아키텍처를 평가해야 합니다.
• 안정성 향상. 표준 작업 기준은 클라우드에서 어느 정도의 안정성과 복구를 제공합니다. 일부 워크로드 팀에는 더 높은 SLA가 필요할 수 있으며 이로 인해 아키텍처가 변경될 수 있습니다.
• 고비용 워크로드. 마이그레이션하는 동안 실제 사용량에 맞게 크기를 조정하도록 모든 자산을 최적화해야 합니다. 일부 워크로드는 특정 비용 문제를 해결하기 위해 아키텍처 수정이 필요할 수 있습니다.
• 성능 요구 사항. 워크로드 성능이 비즈니스에 직접적인 영향을 미치는 경우 추가 아키텍처 고려 사항이 필요할 수 있습니다.
• 애플리케이션을 보호합니다. 보안 요구 사항은 중앙에서 구현되는 경향이 있으며 일반적으로 포트폴리오의 모든 워크로드에 적용됩니다. 일부 워크로드에는 아키텍처 변경으로 이어질 수 있는 특정 보안 요구 사항이 있을 수 있습니다.

이러한 각 기준은 잠재적인 마이그레이션 장애물을 나타내는 지표로 사용됩니다. 대부분의 경우 서버 크기 조정, 새 서버 추가 또는 기타 변경으로 워크로드를 마이그레이션한 후 조건을 해결할 수 있습니다. 그러나 워크로드를 마이그레이션하기 전에 이러한 조건이 필요한 경우 마이그레이션 웨이브에서 워크로드를 제거하고 개별적으로 평가합니다.

Azure Well-Architected Framework 및 Azure Well-Architected Review는 특정 워크로드의 기술 소유자와의 대화를 안내하여 워크로드 배포를 위한 대체 옵션을 고려하는 데 도움이 될 수 있습니다.

그런 다음 워크로드는 클라우드 채택 계획에서 다시 설계 또는 현대화 작업으로 분류됩니다. 워크로드를 재설계하는 데 걸리는 추가 시간 때문에 이러한 대체 워크로드 채택 경로를 마이그레이션 프로세스와는 별도로 고려합니다.

아키텍처 검사 목록

다음 검사 목록을 사용하여 중요한 아키텍처 고려 사항을 다룰 수 있습니다.

• 아키텍처가 가용성, 재해 복구 및 데이터 복구를 위해 SLA를 충족하는지 확인합니다.
• 네트워크 디자인에 네트워크 세분화 사례를 적용했음을 확인합니다.
• 모니터링 및 로그 캡처를 계획했는지 확인합니다.
• 가상 머신의 크기가 필요한 실제 컴퓨팅 시간에 적합한지 확인합니다.
• 디스크 크기가 필요한 실제 크기 및 성능에 적합한지 확인합니다.
• 필요한 경우 부하 분산 서비스를 계획했는지 확인합니다. 서비스에는 Azure Load Balancer, Azure 애플리케이션 Gateway, Azure Front Door 또는 Azure Traffic Manager 인스턴스가 포함될 수 있습니다.
• 필요한 경우 주권 및 기밀 컴퓨팅 요구 사항을 계획했는지 확인합니다.

다음 단계

마이그레이션 워크로드 배포