Azure App Services를 다른 지역으로 재배치

이 문서에서는 App Service 리소스를 다른 Azure 지역으로 이동하는 방법을 설명합니다.

기존 Azure 리소스를 한 지역에서 다른 지역으로 이동하려는 이유는 다양합니다. 다음을 수행하려고 할 수 있습니다.

• 새 Azure 지역 활용.
• 특정 지역에서만 사용할 수 있는 기능 또는 서비스 배포.
• 내부 정책 및 거버넌스 요구 사항 충족.
• 회사 인수 합병에 부합.
• 용량 계획 요구 사항 충족.

App Service 리소스는 지역에 따라 달라지므로 지역 간에 이동할 수 없습니다. 대상 지역에 기존 App Service 리소스의 복사본을 만든 다음, 콘텐츠를 새 앱으로 재배치해야 합니다. 원본 앱에서 사용자 지정 도메인을 사용하는 경우, 재배치가 완료된 후 대상 지역의 새 앱으로 해당 도메인을 마이그레이션할 수 있습니다.

앱을 더 쉽게 복사하려면, 다른 지역의 App Service 요금제로 개별 App Service 앱을 백업 및 복원할 수 있습니다.

필수 조건

• 이동하려는 Azure 지역에 App Service 앱이 있는지 확인합니다.
• 리소스를 이동할 App Service 및 관련 서비스를 대상 지역에서 지원하는지 확인합니다.
• App Service 리소스를 대상 구독 및 지역에 배포할 수 있는 충분한 권한이 있는지 확인합니다.
• 모든 Azure 정책이 지역 제한을 사용해서 할당되었는지 확인합니다.
• 컴퓨팅 리소스 가격이 지역마다 다를 수 있으므로 모든 운영 비용을 고려합니다. 가능한 비용을 예상하려면 요금 계산기를 참조하세요.

준비

현재 사용 중인 모든 App Service 리소스를 식별합니다. 예시:

• App Service 앱
• App Service 계획
• 배포 슬롯
• Azure에서 구매한 사용자 지정 도메인
• TLS/SSL 인증서
• Azure Virtual Network 통합
• 하이브리드 연결
• 관리 ID
• 백업 설정

가져온 인증서 또는 하이브리드 연결과 같은 특정 리소스에는 다른 Azure 서비스와의 통합이 포함되어 있습니다. 해당 리소스를 지역 간에 이동하는 방법에 대한 자세한 내용은 각 서비스에 대한 설명서를 참조하세요.

계획

이 섹션은 다음 영역에 대한 계획 검사 목록입니다.

• 상태, 스토리지 및 다운스트림 종속성
• 인증서
• 구성
• VNet 연결 / 사용자 지정 이름 / DNS
• Identities
• 서비스 끝점

상태, 스토리지 및 다운스트림 종속성

• App Service 앱이 상태 저장형인지 상태 비저장형인지 확인합니다. App Service 앱은 상태 비저장형인 것이 좋으며 %HOME%\site 드라이브의 파일은 임시 파일이 있는 배포된 애플리케이션을 실행하는 데 필요한 파일에만 해당해야 하지만, %HOME%\site 가상 드라이브에 런타임 애플리케이션 상태를 저장할 수는 있습니다. 애플리케이션이 앱 공유 스토리지 경로에 상태를 기록하는 경우, 리소스 이동 중에 해당 상태를 관리할 방법을 계획해야 합니다.

  팁

  %HOME%\site 디렉터리에서 파일을 읽고 쓸 수 있는 파일 액세스 API(VFS(가상 파일 시스템))를 제공하기 위해, 포털 액세스와 함께 Kudu를 사용할 수 있습니다. 자세한 내용은 Kudu Wiki를 참조하세요.

• 애플리케이션 코드에서 내부 캐싱 및 상태를 확인합니다.

• 세션 선호도 설정을 사용하지 않도록 설정합니다. 가능한 경우, 세션 선호도 설정을 사용하지 않도록 설정하는 것이 좋습니다. 세션 선호도를 사용하지 않도록 설정하면 수평적 스케일 아웃에 대한 부하 분산이 개선됩니다. 모든 내부 상태는 특히 가동 중지 시간이 0이 되어야 하는 경우, 워크로드를 컷오버하는 계획에 영향을 줄 수 있습니다. 가능한 경우, 모든 애플리케이션 상태를 리팩터링하여 이동 준비 시에 애플리케이션을 상태 비저장형으로 만드는 것이 도움이 될 수 있습니다.

• 데이터베이스 연결 문자열을 분석합니다. 데이터베이스 연결 문자열은 [앱 설정]에서 찾을 수 있습니다. 그러나 애플리케이션과 함께 제공되는 구성 파일에서 해당 문자열이 하드 코딩되거나 관리될 수도 있습니다. 워크로드 이동을 위한 상위 수준 계획의 일부로 데이터 마이그레이션/복제를 분석하고 계획합니다. 번잡하거나 대기 시간이 중요한 애플리케이션의 경우, 대상 지역의 애플리케이션이 원본 지역의 데이터 원본에 다시 도달하는 성능이 좋지 않습니다.

• 외부 캐싱(예: Redis)을 분석합니다. 애플리케이션 캐시는 애플리케이션에 최대한 가깝게 배포해야 합니다. 캐시가 채워지는 방법 및 만료/제거 정책을 분석하고, 컷오버 이후 워크로드에 액세스하는 첫 번째 사용자에게 콜드 캐시가 미칠 수 있는 영향도 분석합니다.

• API(또는 애플리케이션) 종속성을 분석하고 계획합니다. 대상 지역의 앱이 원본 지역에 있는 종속성에 다시 도달하는 경우, 지역 간 통신의 성능이 훨씬 떨어집니다. 워크로드 재배치의 일부로 모든 다운스트림 종속성을 재배치하는 것이 좋습니다. 그러나 *온-프레미스* 리소스는 예외이며, 특히 (송환 시나리오의 경우와 같이) 대상 지역에 지리적으로 가까운 리소스는 예외입니다.

  Azure Container Registry는 사용자 지정 컨테이너 이미지에 대해 실행되도록 구성된 App Service에 대한 다운스트림(런타임) 종속성일 수 있습니다. Container Registry는 앱 자체와 동일한 지역에 있는 것이 더 합리적입니다. 대상 지역의 새 ACR에 필요한 이미지를 업로드하는 것을 고려합니다. 그렇지 않고 원본 지역에 이미지를 유지하려는 경우, 지역 복제 기능을 사용하는 것을 고려합니다.

• 지역 서비스를 분석하고 계획합니다. Application Insights 및 Log Analytics 데이터는 지역 서비스입니다. 새로운 Application Insights 및 Log Analytics 스토리지를 대상 지역에 만드는 것을 고려합니다. App Insights의 경우, 새 리소스는 App Configuration 변경의 일부로 업데이트해야 하는 연결 문자열에도 영향을 줍니다.

인증서

App Service 인증서 리소스는 새 리소스 그룹 또는 구독으로 이동할 수 있지만, 지역 간에는 이동할 수 없습니다. 내보낼 수 있는 인증서는 새 지역의 앱이나 Key Vault로 가져올 수도 있습니다. 이러한 내보내기 및 가져오기 프로세스는 지역 간 이동과 같습니다.

서비스 이전을 계획할 때 고려해야 할 다양한 형식의 인증서가 있습니다.

고려해야 할 몇 가지 추가 사항은 다음과 같습니다.

• App Service 앱의 SSL 연결이 특정 앱 지정 IP에 바인딩되는 앱 할당 주소는 타사 네트워크에서 App Service로 들어가는 호출을 허용 목록에 추가하는 데 사용할 수 있습니다. 예를 들어, 네트워크/IT 관리자는 잘 알려진 정적 주소를 사용하기 위해, 온-프레미스 네트워크 또는 VNet에서 나오는 아웃바운드 호출을 잠그려고 할 수 있습니다. 따라서 앱 할당 주소 기능을 사용하는 경우, 앱으로 들어가는 호출자에 대한 업스트림 방화벽 규칙(예: 내부, 외부 또는 타사 규칙)을 확인하고 새 주소를 알려야 합니다. 방화벽 규칙은 내부, 외부 또는 타사(예: 파트너 또는 잘 알려진 고객) 규칙일 수 있습니다.

• 모든 업스트림 NVA(네트워크 가상 어플라이언스) 또는 역방향 프록시를 고려합니다. 호스트 헤더 재작성 및/또는 SSL 종료의 경우, NVA 구성을 변경해야 할 수 있습니다.

구성

• Azure Portal에서 기존 앱 설정 및 연결 문자열의 스냅샷을 캡처할 수 있습니다. 설정>환경 변수를 확장하고 앱 설정 또는 연결 문자열에서 고급 편집을 선택한 다음 기존 설정이나 연결이 포함된 JSON 출력을 저장합니다. 새 지역에서 이러한 설정을 다시 만들어야 하지만, 연결된 서비스의 후속 지역 변경으로 인해 값 자체가 변경될 가능성이 높습니다.

• 기존 Key Vault 참조는 Azure 지리적 경계를 넘어 내보낼 수 없습니다. 새로운 지역에서 필요한 참조를 다시 만들어야 합니다.

• App Configuration은 Azure App Configuration이나 다른 중앙(다운스트림) 데이터베이스 종속성에서 관리될 수 있습니다. 환경 및 지역별 설정에 수정이 필요할 수 있는 App Configuration 저장소나 비슷한 저장소를 검토합니다.

• 애플리케이션 설정에 의해 재정의될 수도 있고 그렇지 않을 수도 있는 모든 디스크 파일 구성을 확인합니다.

VNet 연결 / 사용자 지정 이름 / DNS

• App Service Environment는 VNet 삽입 단일 테넌트 서비스입니다. App Service Environment 네트워킹은 "프라이빗 엔드포인트" 또는 "지역 VNet 통합" 중 하나 또는 둘 다가 필요한 다중 테넌트 App Service와 다릅니다. 작동할 수 있는 다른 옵션에는 레거시 P2S VPN 기반 VNet 통합 및 하이브리드 연결(Azure Relay 서비스)이 포함됩니다.

  참고 항목

  ASEv3 네트워킹이 간소화됩니다. 즉, Azure 관리 트래픽 및 App Service Environment의 자체 다운스트림 종속성은 고객의 가상 네트워크에 표시되지 않으므로, 네트워크 가상 어플라이언스/방화벽을 통해 고객이 모든 트래픽에 강제 터널을 사용하거나 아웃바운드 트래픽의 하위 집합을 보내는 경우에 필요한 구성이 크게 간소화됩니다.

  하이브리드 연결(Azure Relay)은 지역적입니다. 하이브리드 연결을 사용하는 경우 Azure Relay 네임스페이스를 다른 지역으로 이동할 수 있더라도, 하이브리드 연결을 다시 배포하고(대상 리소스 배포 시 새 지역에 하이브리드 연결이 설정되었는지 확인) 하이브리드 연결 관리자에 하이브리드 연결을 다시 연결하는 것이 더 간단합니다. 하이브리드 연결 관리자의 위치를 신중하게 고려해야 합니다.

• 웜 대기 지역에 대한 전략을 따릅니다. 리소스를 재배치하기 전에 핵심 네트워킹과 연결, 허브 네트워크, 도메인 컨트롤러, DNS, VPN 또는 Express Route 등이 존재하고 테스트되었는지 확인합니다.

• 모든 업스트림 또는 다운스트림 네트워크 ACL 및 구성의 유효성을 검사합니다. 예를 들어, 앱 트래픽만 허용 목록에 추가하는 외부 다운스트림 서비스를 고려합니다. 다중 테넌트 App Service에 대한 새 애플리케이션 플랜으로 재배치하면 아웃바운드 IP 주소도 변경됩니다.

• 대부분의 경우, 대상 지역 VNet에 고유한 주소 공간이 있는지 확인하는 것이 가장 좋습니다. 고유한 주소 공간은 예를 들어, 데이터를 복제하는 데 필요한 경우 VNet 연결을 용이하게 합니다. 따라서 이러한 시나리오에서는 다음을 변경하는 것이 암묵적으로 요구됩니다.

  • 프라이빗 DNS
  • (호스트 이름 없이) IP 주소로 리소스를 참조하는 모든 하드 코딩된 구성 또는 외부 구성
  • 네트워크 보안 그룹 및 방화벽 구성을 포함한 네트워크 ACL(여기에서도 온-프레미스 NVA에 미치는 영향을 고려)
  • 모든 라우팅 규칙, 사용자 정의 경로 테이블

  또한, 기존 DevOps 배포 리소스를 전달하는 경우, 지역별 IP 범위/서비스 태그를 포함한 구성을 확인해야 합니다.

• Azure 도메인 및 Azure DNS Private Zones에 대해 Azure로 전달하도록 구성된 고객 배포 프라이빗 DNS에 필요한 변경 내용은 적습니다. 그러나 프라이빗 엔드포인트는 리소스 FQDN을 기반으로 하며 이는 종종 리소스 이름(대상 지역에 따라 달라질 것으로 예상할 수 있음)이기도 하므로, 구성에서 참조되는 FQDN이 적절히 업데이트되는지 확인하기 위해 구성을 교차 확인해야 합니다.

• 대상 지역에서 프라이빗 엔드포인트(사용되는 경우)를 다시 만듭니다. 지역 VNet 통합에도 동일하게 적용됩니다.

• App Service Environment를 위한 DNS는 일반적으로 고객의 프라이빗 사용자 지정 DNS 솔루션을 통해 관리됩니다(앱별 기본 설정에서 사용할 수 있는 수동 설정 재정의가 있음). App Service Environment는 수신/송신을 위한 부하 분산 장치를 제공하지만, App Service 자체는 호스트 헤더에서 필터링합니다. 따라서 사용자 지정 이름 여러 개가 동일한 App Service Environment 수신 엔드포인트를 가리킬 수 있습니다. App Service Environment에는 도메인 유효성 검사가 필요하지 않습니다.

  참고 항목

  App Service Environment v3를 위한 Kudu 엔드포인트는 {resourcename}.scm.{asename}.appserviceenvironment.net에서만 사용할 수 있습니다. App Service Environment v3의 DNS 및 네트워킹 등에 대한 자세한 내용은 App Service Environment 네트워킹을 참조하세요.

  App Service Environment의 경우 고객은 라우팅을 소유하므로 컷오버에 사용되는 리소스도 소유합니다. (일반적으로 계층 7 NVA 또는 역방향 프록시를 통해) 외부로부터 App Service Environment에 대한 액세스가 사용되는 경우, Traffic Manager 또는 Azure Front Door/기타 L7 전역 부하 분산 서비스를 사용할 수 있습니다.

• 해당 서비스의 공용 다중 테넌트 버전의 경우, Kudu(SCM) 엔드포인트에 대한 기본 이름과 함께 데이터 평면 엔드포인트에 대한 기본 이름 {resourcename}.azurewebsites.net이 프로비전됩니다. 해당 서비스는 기본적으로 공용 엔드포인트를 제공하므로, 도메인 소유권을 증명하기 위해 바인딩을 확인해야 합니다. 그러나 일단 바인딩이 설정되면 재확인은 필요하지 않으며, 공용 DNS 레코드가 App Service 엔드포인트를 가리키도록 할 필요도 없습니다.

• 사용자 지정 도메인을 사용하는 경우, 대상 앱에 선제적으로 해당 도메인을 바인딩합니다. 대상 앱에서 해당 도메인을 사용하도록 설정하고 확인합니다.

Identities

• 새로운 대상 지역에서 앱과 함께 시스템에 할당된 관리 ID를 다시 만들어야 합니다. 일반적으로, 자동 생성된 Microsoft Entra ID 앱(EasyAuth가 사용하는 앱)은 기본적으로 앱 리소스 이름으로 설정됩니다.

• 사용자가 할당한 관리 ID도 지역 간에 이동할 수 없습니다. 앱과 동일한 리소스 그룹에 사용자가 할당한 관리 ID를 유지하려면 새 지역에서 해당 ID를 다시 만들어야 합니다. 자세한 내용은 Azure 리소스의 관리 ID를 다른 지역으로 이전을 참조하세요.

• 그룹 멤버 자격을 포함하여 바꾸는 원래 ID와 동일한 권한을 관리 ID에 재배치된 서비스에서 부여합니다.

• IDP(ID 공급자)를 대상 지역으로 재배치할 계획을 세웁니다. Microsoft Entra ID는 글로벌 서비스이지만 일부 솔루션은 로컬(또는 온-프레미스의 다운스트림) IDP를 사용합니다.

• Kudu FTP 자격 증명을 사용할 수 있는 모든 리소스를 App Service로 업데이트합니다.

서비스 엔드포인트

Azure App Service의 가상 네트워크 서비스 엔드포인트는 지정된 가상 네트워크에 대한 액세스를 제한합니다. 엔드포인트는 IPv4(인터넷 프로토콜 버전 4) 주소 범위 목록에 대한 액세스를 제한할 수도 있습니다. 해당 소스 외부에서 Event Hubs에 연결하는 모든 사용자는 액세스가 거부됩니다. Event Hubs 리소스의 원본 지역에서 서비스 엔드포인트가 구성된 경우 대상에서 동일한 작업을 수행해야 합니다.

Azure App Service를 대상 지역에 성공적으로 다시 만들려면 VNet 및 서브넷을 미리 만들어야 합니다. 이러한 두 리소스를 Azure Resource Mover 도구를 사용하여 이동하는 경우 서비스 엔드포인트가 자동으로 구성되지 않습니다. 따라서 Azure Portal, Azure CLI 또는 Azure PowerShell를 통해 수동으로 구성해야 합니다.

재배치

App Service 리소스를 재배치하려면 Azure Portal 또는 IaC(Infrastructure as Code)를 사용할 수 있습니다.

Azure Portal을 사용하여 재배치

Azure Portal을 사용하여 재배치할 때의 가장 큰 이점은 단순성입니다. 앱, 플랜 및 콘텐츠뿐만 아니라 많은 설정이 새 App Service 리소스 및 플랜으로 복제됩니다.

App Service Environment(격리) 계층의 경우, 먼저 다른 지역의 전체 App Service Environment를 다시 배포한 다음, 새 지역의 새 App Service Environment에서 개별 플랜을 다시 배포하기 시작할 수 있다는 점에 유의합니다.

Azure Portal을 사용하여 App Service 리소스를 새 지역으로 재배치하려면 다음을 수행합니다.

1. 원본 앱의 백업을 만듭니다.
2. 대상 지역에서 새 App Service 플랜의 앱을 만듭니다.
3. 대상 앱에서 백업을 복원합니다.
4. 사용자 지정 도메인을 사용하는 경우 먼저 asuid.를 사용하여 대상 앱에 사용자 지정 도메인을 바인딩하고 대상 앱에서 해당 도메인을 사용하도록 설정합니다.
5. 대상 앱의 다른 모든 항목을 원본 앱과 동일하게 구성하고 구성을 확인합니다.
6. 사용자 지정 도메인이 대상 앱을 가리키도록 할 준비가 되면 도메인 이름을 다시 매핑합니다.

IaC를 사용하여 재배치

기존 CI/CD(연속 통합 및 지속적인 업데이트/배포) 파이프라인이 있거나 만들 수 있는 경우 IaC를 사용합니다. CI/CD 파이프라인을 사용하면, 배포 작업 또는 Kudu zip 배포를 통해 대상 지역에서 App Service 리소스를 만들 수 있습니다.

SLA 요구 사항은 얼마나 많은 추가 작업이 필요한지를 결정해야 합니다. 예를 들어, 이는 가동 중지 시간이 제한된 재배포인가요? 아니면 가동 중지 시간이 최소이거나 전혀 없는 거의 실시간 컷오버인가요?

외부 글로벌 트래픽 라우팅 에지 서비스(예: Traffic Manager) 또는 Azure Front Door를 포함하면, 외부 사용자 및 애플리케이션에 대한 컷오버를 용이하게 하는 데 도움이 됩니다.

유효성 검사

재배치가 완료되면 권장 지침에 따라 Azure App Service를 테스트하고 유효성을 검사합니다.

• Azure App Service가 대상 지역으로 재배치되면 스모크 테스트 및 통합 테스트를 실행합니다. 수동으로 테스트하거나 스크립트를 통해 테스트를 실행할 수 있습니다. 모든 구성 및 종속 리소스가 제대로 연결되어 있는지 그리고 구성된 모든 데이터에 액세스할 수 있는지 확인합니다.

• 모든 Azure App Service 구성 요소 및 통합의 유효성을 검사합니다.

• 모든 공식 회귀 테스트를 포함하여, 대상 지역 배포에서 통합 테스트를 수행합니다. 통합 테스트는 워크로드에 적용되는 일반적인 비즈니스 리듬 배포 및 테스트 프로세스에 맞춰 진행해야 합니다.

• 특히 업데이트, 애플리케이션 또는 Azure 리소스에 대한 변경 또는 사용 프로필의 변경이 재배치에 포함되는 일부 시나리오에서는, 부하 테스트를 사용하여 새 워크로드가 목적에 적합한지 확인합니다. 부하 테스트는 작업 및 모니터링 적용 범위를 확인할 수 있는 기회이기도 합니다. 예를 들어, 필요한 인프라 및 애플리케이션 로그가 올바르게 생성되고 있는지 확인하는 데 부하 테스트를 사용합니다. 부하 테스트는 설정된 워크로드 성능 기준선에 대해 측정해야 합니다.

정리

원본 앱 및 App Service 플랜을 삭제하세요. 무료가 아닌 계층의 App Service 플랜에는 실행 중인 앱이 없는 경우에도 요금이 부과됩니다.

다음 단계

PowerShell을 사용하여 Azure App Service 앱 복제