지역 간에 Azure 리소스 이동

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
Azure VPN Gateway

이 솔루션은 Azure 리소스를 지역 간에 효율적이고 안전하며 원활하게 이동합니다. 이동 계획 및 수행을 위한 주요 단계, 고려 사항 및 전략을 참조하세요.

아키텍처

지역 솔루션 간에 Azure 리소스를 이동하는 데이터 흐름을 보여 주는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

데이터 흐름

  • 온-프레미스 데이터 센터 네트워크: 온-프레미스 리소스를 지원하기 위해 조직 내에서 실행되는 프라이빗 로컬 영역 네트워크입니다.

  • ExpressRoute 회로: ExpressRoute 연결은 타사 연결 공급자를 통해 프라이빗 전용 연결을 사용합니다. 프라이빗 연결은 온-프레미스 네트워크를 Azure로 확장합니다.

  • 로컬 에지 라우터: 온-프레미스 네트워크를 타사 공급자가 관리하는 회로에 연결하는 라우터입니다. 연결이 프로비전된 방법에 따라 라우터에서 사용하는 공용 IP 주소를 제공해야 할 수도 있습니다.

  • Microsoft 에지 라우터: 활성-활성 고가용성 구성의 두 라우터입니다. 이 라우터를 사용하면 타사 연결 공급자가 해당 회로를 데이터 센터에 직접 연결할 수 있습니다. 연결이 프로비전된 방법에 따라 라우터에서 사용하는 공용 IP 주소를 제공해야 할 수도 있습니다.

  • VPN Gateway: VPN 게이트웨이 서비스를 사용하여 가상 네트워크를 온-프레미스 네트워크에 연결할 수 있습니다.

  • Active Directory 서브넷: 대부분의 엔터프라이즈 조직에는 온-프레미스 데이터 센터에 ADDS(Active Directory Domain Services) 환경이 있습니다. AD DS에 의존하는 온-프레미스 네트워크에서 Azure로 이동된 자산의 관리를 용이하게 하려면 종속 워크로드가 액세스할 수 있는 중앙 VNET(Virtual Network) 허브에서 Azure에서 AD DS 도메인 컨트롤러를 호스팅하는 것이 좋습니다.

  • VNET 피어링: 피어링이 있는 여러 VNET입니다. VNET 피어링을 사용하면 각 가상 네트워크의 그룹 애플리케이션을 허용하고 대기 시간이 짧은 대역폭 연결을 제공합니다.

  • 클라우드 환경에서 실행되는 다계층 웹 애플리케이션: 이 예제 아키텍처는 클라우드에서 복원력 있는 다중 애플리케이션을 배포해야 하는 많은 산업에 적용할 수 있습니다. 이 시나리오에서는 애플리케이션이 세 계층으로 구성됩니다.

    • 웹 계층: 사용자 인터페이스를 포함하는 최상위 계층입니다. 이 계층은 사용자 상호 작용을 구문 분석하고 작업을 다음 계층으로 전달하여 처리합니다.
    • 비즈니스 또는 앱 계층: 사용자 상호 작용을 처리하고 다음 단계에 대한 논리적 결정을 내립니다. 이 계층은 웹 계층과 데이터 계층을 연결합니다.
    • 데이터 계층: 애플리케이션 데이터를 저장합니다. 이 경우 SQL 데이터베이스가 데이터를 저장합니다.
  • 내부 부하 분산 장치: VPN 게이트웨이의 네트워크 트래픽은 애플리케이션 계층의 서브넷에 있는 ILB(내부 부하 분산 장치) 엔드포인트를 통해 클라우드 애플리케이션으로 라우팅됩니다.

  • PaaS(Platform as a Service) 리소스: 이 예제 환경에서는 Azure IoT Hub, Azure Key Vault 및 Azure App Service와 같은 몇 가지 PaaS 서비스가 있습니다.

구성 요소

이 예제에서는 다음 구성 요소를 사용합니다.

시나리오 정보

Microsoft Azure가 성장하고 그 지역의 집합이 전 세계적으로 진화하면서 고객은 배포를 한 지역에서 다른 지역으로 이동해야 합니다. 지역 간에 애플리케이션을 이동하는 작업은 모든 리소스를 원활하게 이동하고 가동 중지 시간을 최소화하면서 새 지역에서 애플리케이션이 가동 및 실행되도록 잘 짜여진 계획이 필요한 활동입니다.

이 예제의 권장 사항 및 아키텍처는 지역 간에 Azure 리소스를 효율적이고 안전하게 원활하게 이동하는 방법에 대한 지침을 제공합니다.

잠재적인 사용 사례

리소스를 다른 지역으로 이동하는 주요 이유 중 일부는 다음과 같습니다.

  • 지역 시작에 맞추기: 이전에 사용할 수 없었던 새로 도입된 Azure 지역으로 리소스를 이동합니다.
  • 서비스 또는 기능에 맞추기: 리소스를 이동하여 특정 지역에서 사용할 수 있는 서비스 또는 기능을 활용합니다.
  • 비즈니스 개발에 대응: 합병 또는 인수 등의 비즈니스 변화에 대응하여 리소스를 지역으로 이동합니다.
  • 근접성에 맞추기: 리소스를 비즈니스 지역으로 이동합니다.

지역 간에 리소스를 이동하는 단계

요구 사항이 예제 아키텍처와 다를 수 있으므로 다음 권장 사항을 시작점으로 사용하세요.

  1. 이동을 위한 사전 요구 사항을 확인합니다.

    • 계획된 가동 중지 시간: 고객에게 미치는 영향을 최소화하기 위해 지역 이동은 예약된 가동 중지 시간이 있는 유지 관리 작업으로 계획합니다.

    • Azure 구독 제한 및 할당량: 구독에 특정 리소스 유형을 지원하기에 충분한 리소스가 있는지 확인합니다. 예를 들어 대상 지역이 원본 지역의 가상 머신과 일치하는 크기의 가상 머신을 지원하는지 확인합니다. 필요한 경우 고객 지원팀에 문의하여 필요한 할당량을 사용하도록 설정합니다. 자세한 정보는 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.

    • 계정 권한: Azure 체험 계정을 만든 경우 자신이 구독에 대한 관리자입니다. 구독 관리자가 아닌 경우에는 관리자와 협력하여 리소스를 이동하는 데 필요한 권한을 할당받습니다. Azure 구독에서 사용되는 대상 지역에 필요한 리소스를 허용하는지 확인합니다.

    • 리소스 식별: Azure Resource Manager 템플릿을 내보내거나 다양한 기술을 사용하여 복제를 시작하는 데 필요한 리소스 유형에 따라 리소스를 식별하고 분류합니다. 이동하려는 각 리소스 유형에 대해 단계가 다를 수 있습니다. 각 리소스 종류에 대한 해당 단계를 식별하려면 지역 간에 Azure 리소스 이동을 참조하세요.

  2. 네트워킹 구성 요소를 이동합니다.

    • 네트워크 보안 그룹: 네트워크 보안 그룹을 한 지역에서 다른 지역으로 이동할 수 없습니다. 하지만 ARM 템플릿을 사용하여 네트워크 보안 그룹의 기존 구성 및 보안 규칙을 내보낼 수 있습니다. 그런 다음, 그룹을 템플릿으로 내보내고, 대상 지역과 일치하도록 매개 변수를 수정한 다음, 템플릿을 새 지역에 배포하여 리소스를 다른 지역에 준비할 수 있습니다.

    • 가상 네트워크: Azure Resource Manager 템플릿을 사용하여 가상 네트워크를 다른 지역으로 이동할 수 있습니다. 가상 네트워크를 템플릿으로 내보내고 대상 지역과 일치하도록 매개 변수를 수정한 다음, 새 지역에 템플릿을 배포하세요.

    • 가상 네트워크 피어링: VNET 피어링을 다시 만들지 않으며 VNET 피어가 템플릿에 여전히 있는 경우 실패합니다. 템플릿을 내보내기 전에 가상 네트워크 피어를 모두 제거해야 합니다. 가상 네트워크 이동 후 다시 설정할 수 있습니다.

    • 공용 IP 주소: Azure 공용 IP는 지역별로 지정되므로 한 지역에서 다른 지역으로 이동할 수 없습니다. 하지만 ARM 템플릿을 사용하여 네트워크 보안 그룹의 기존 구성 및 보안 규칙을 내보낼 수 있습니다. 그런 다음, 그룹을 템플릿으로 내보내고, 대상 지역과 일치하도록 매개 변수를 수정한 다음, 템플릿을 새 지역에 배포하여 리소스를 다른 지역에 준비할 수 있습니다.

  3. 앱 구성 요소를 이동합니다.

    • 가상 머신 리소스: 가상 머신 리소스를 이동하려면 Azure Site Recovery 대상 지역에서 리소스를 복제하여 리소스를 이동해야 합니다. Site Recovery를 사용하여 가상 머신을 이동하는 데 대한 자세한 내용은 Azure VM을 다른 지역으로 이동을 참조하세요.

    • SQL 리소스: SQL 데이터베이스는 SQL 장애 조치(failover) 그룹 메커니즘을 사용하여 지역 간에 이동합니다. SQL 데이터베이스 이동에 대한 자세한 내용은 리소스를 새 지역인 Azure SQL Database 및 Azure SQL Managed Instance로 이동을 참조 하세요.

  4. PaaS 서비스 이동: PaaS 서비스에는 이동을 오케스트레이션하기 위한 고유한 특정 단계가 있습니다. 지원되는 서비스의 목록에서 최신 정보를 찾으려면 지역 간 Azure 리소스 이동 지원을 참조하세요.

  5. 온-프레미스 인프라 이동: 대상 지역에서 전체 원본 지역을 다시 만들려면 이전과 같이 온-프레미스 구성 요소를 다시 설정하고 구성하고 Azure 네트워크에 연결합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

지역 간 이동을 수행할 때 다음 사항을 고려합니다.

  • 지역 간 마이그레이션 계획은 복잡한 인프라를 고려해야 합니다. 최신 인프라 환경은 온-프레미스 인프라에서 클라우드로 확장되는 경우가 많습니다. 일부는 프라이빗 또는 퍼블릭 배포를 포함하는 다중 클라우드 전략으로 복잡성을 더 많이 갖습니다.

  • 리소스 종류를 함께 이동합니다. 유사한 리소스 종류(예: 가상 머신 50개 또는 SQL 데이터베이스 20개)의 이동을 결합하여 이동 준비 단계를 보다 쉽게 계획하고 장기 실행 작업이 함께 완료되도록 하여 가동 중지 시간을 줄일 수 있습니다.

  • 애플리케이션 내의 모든 리소스를 함께 이동합니다. 대상 지역에서 앱을 오케스트레이션된 방식으로 가져오는 것이 가능하도록 확인하기 위해 애플리케이션의 리소스를 선택하고 집합에서 함께 이동해볼 수 있습니다.

  • 용량 요구 사항을 충족하는지 확인합니다. 실제 이동 전에 현재 및 잠재적인 비즈니스 성장을 지원하기 위해 대상 지역에서 용량 또는 할당량을 확인하는 기능을 사용할 수 있습니다.

  • 이동이 진행되는 동안 원본 지역의 현재 중요 비즈니스용 애플리케이션 또는 인프라에 대한 영향을 최소화하거나 영향을 주지 않아야 합니다.

  • 비즈니스 연속성을 보장하려면 가동 중지 시간이 가장 적은 대상 지역에서 기능 환경을 가동 및 실행해야 합니다.

  • 대상 측에 대한 최종 커밋 전에 마이그레이션의 유효성을 검사하는 기능은 특히 FSI(금융 서비스 산업) 또는 의료 분야의 계층 0, 계층 1 워크로드를 지원하는 경우에 중요합니다.

  • 대상 지역으로 이동을 커밋하기 전에 원래 구성, 연결, 적절한 보안 구성, 정책, 데이터 복제 및 데이터베이스 연결을 테스트하고 유효성을 검사하여 실사를 수행해야 합니다.

  • 리소스를 대상으로 이동한 후 다음과 같은 최종 변경을 수행하여 최종 구성이 실행 중인지 확인합니다.

    • DNS 구성을 변경하여 새 IP를 가리킵니다.
    • 원본 지역에서 리소스를 삭제하여 이중 청구를 방지하고 범위 및 구성에서 겹치는 두 개의 개별 데이터 집합의 존재로 인한 문제를 방지합니다.
    • 이동을 위해 만든 보조 리소스를 삭제합니다. 예를 들어 중간 전송에 사용된 스토리지 계정을 삭제합니다.

다음 단계