Azure App Service의 안정성
이 문서에서는 의 안정성 지원을 설명하고 가용성 영역을 통한 지역 내 복원력과 지역 간 재해 복구 및 비즈니스 연속성을 모두 설명합니다. Azure의 안정성 원칙에 대한 자세한 개요는 Azure 안정성을 참조하세요.
Azure App Service는 웹 애플리케이션, REST API 및 모바일 백 엔드를 호스트하기 위한 HTTP 기반 서비스입니다. 다음과 같은 Microsoft Azure의 기능을 애플리케이션에 추가합니다.
- 보안
- 부하 분산
- 자동 확장
- 자동화된 관리
Azure App Service가 애플리케이션 워크로드의 안정성 및 복원력을 강화하는 방법을 살펴보려면 App Service를 사용하는 이유를 참조하세요.
가용성 영역 지원
Azure 가용성 영역은 각 Azure 지역 내에서 물리적으로 분리된 세 개 이상의 데이터 센터 그룹입니다. 각 영역 내의 데이터 센터에는 독립적인 전원, 냉각, 네트워킹 인프라가 장착되어 있습니다. 가용성 영역은 로컬 영역이 실패한 경우에 한 영역이 영향을 받는 경우 나머지 두 영역에서 지역 서비스, 용량 및 고가용성을 지원하도록 설계되었습니다.
오류는 소프트웨어 및 하드웨어 오류에서 지진, 홍수 및 화재와 같은 이벤트에 이르기까지 다양합니다. Azure 서비스의 중복성과 논리적 격리로 인해 오류 허용성에 도달합니다. Azure의 가용성 영역에 대한 자세한 내용은 지역 및 가용성 영역을 참조하세요.
Azure 가용성 영역 지원 서비스는 적절한 수준의 복원력과 유연성을 제공하도록 설계되었습니다. 두 가지 방법으로 구성할 수 있습니다. 영역 간 자동 복제를 사용하는 영역 중복 또는 특정 영역에 고정된 인스턴스를 사용하는 영역일 수 있습니다. 이러한 방식을 결합할 수도 있습니다. 영역 및 영역 중복 아키텍처에 대한 자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항을 참조하세요.
Azure App Service를 AZ(가용성 영역) 간에 배포하여 중요 비즈니스용 워크로드에 대한 복원력과 안정성을 달성할 수 있습니다. 이 아키텍처를 영역 중복이라고도 합니다.
App Service를 영역 중복으로 구성하면 플랫폼에서 Azure App Service 요금제의 인스턴스를 선택한 지역의 세 영역 간에 자동으로 분산합니다.
영역 중복 배포를 통해 분산되는 인스턴스는 앱 규모가 확대 및 축소되더라도 다음 규칙 내에서 결정됩니다.
- 최소 App Service 요금제 인스턴스 수는 3개입니다.
- 3보다 큰 용량을 지정하고 인스턴스 수를 3으로 나눌 수 있는 경우 인스턴스가 균등하게 분산됩니다.
- 3*N개를 초과하는 모든 인스턴스 수는 나머지 하나 또는 두 개의 영역에 분산됩니다.
가용성 영역 지원은 App Service 요금제의 속성입니다. App Service Environment v3를 사용하여 관리형 다중 테넌트 환경 또는 전용 환경에서 App Service 요금제를 만들 수 있습니다. App Service Environment v3에 대한 자세한 내용은 App Service Environment v3 개요를 참조하세요.
영역 중복으로 구성되지 않은 App Services의 경우 VM 인스턴스는 영역 복원력이 없으며 해당 지역의 모든 영역에서 가동 중단 중에 가동 중지 시간이 발생할 수 있습니다.
엔터프라이즈 배포 아키텍처에 대한 내용은 App Service Environment를 사용하는 고가용성 엔터프라이즈 배포를 참조하세요.
필수 조건
가용성 영역을 사용하도록 설정하기 위한 현재 요구 사항/제한 사항은 다음과 같습니다.
Windows와 Linux가 모두 지원됩니다.
가용성 영역은 최신 App Service 공간에서만 지원됩니다. 지원되는 지역 중 하나를 사용하는 경우에도 리소스 그룹에 대해 가용성 영역이 지원되지 않는 경우 오류가 발생합니다. 워크로드가 가용성 영역을 지원하는 스탬프에 배치되도록 하려면 새 리소스 그룹, App Service 요금제 및 App Service를 만들어야 할 수 있습니다.
App Services 계획은 가용성 영역을 지원하는 다음 계획 중 하나여야 합니다.
- App Service Premium v2 또는 Premium v3 플랜을 사용하는 다중 테넌트 환경에서
- 격리된 v2 App Service 요금제와 함께 사용되는 App Service Environment v3를 사용하는 전용 환경에서
전용 환경의 경우 App Service Environment는 v3여야 합니다.
Important
App Service Environment v2 및 v1은 2024년 8월 31일에 사용 중지됩니다. App Service Environment v3는 사용하기 쉽고 더 강력한 인프라에서 실행됩니다. App Service Environment v3에 대한 자세한 내용은 App Service Environment 개요를 참조하세요. 현재 App Service Environment v2 또는 v1을 사용 중이고 v3로 업그레이드하려는 경우 이 문서의 단계에 따라 새 버전으로 마이그레이션합니다.
세 영역의 최소 인스턴스 수가 적용됩니다. 인스턴스 수를 3개 미만으로 지정하면 플랫폼에서 이 최소 수를 내부적으로 적용합니다.
가용성 영역은 새 App Service 요금제를 만들 때만 지정할 수 있습니다. 기존 App Service 요금제는 가용성 영역을 사용하도록 변환할 수 없습니다.
다음 지역은 다중 테넌트 환경에서 실행되는 Azure App Services를 지원합니다.
- 오스트레일리아 동부
- 브라질 남부
- 캐나다 중부
- 인도 중부
- 미국 중부
- 동아시아
- 미국 동부
- 미국 동부 2
- 프랑스 중부
- 독일 중서부
- 이스라엘 중부
- 이탈리아 북부
- 일본 동부
- 한국 중부
- 멕시코 중부
- 북유럽
- 노르웨이 동부
- 폴란드 중부
- 카타르 중부
- 남아프리카 북부
- 미국 중남부
- 동남 아시아
- 스페인 중부
- 스웨덴 중부
- 스위스 북부
- 아랍에미리트 북부
- 영국 남부
- 서유럽
- 미국 서부 2
- 미국 서부 3
- 21Vianet에서 운영하는 Microsoft Azure - 중국 북부 3
- Azure Government - US Gov 버지니아
App Service Environment v3의 가용성 영역을 지원하는 지역을 보려면 지역을 참조하세요.
가용성 영역을 사용하도록 설정된 리소스 만들기
다중 테넌트 영역 중복 App Service를 배포하려면 다음을 수행합니다.
Azure CLI를 사용하여 가용성 영역을 사용하도록 설정하려면 App Service 요금제를 만들 때 --zone-redundant 매개 변수를 포함합니다. --number-of-workers 매개 변수를 포함하여 용량을 지정할 수도 있습니다. 용량을 지정하지 않으면 플랫폼에서 기본적으로 3을 설정합니다. 용량은 워크로드 요구 사항에 따라 설정해야 하지만 3개 이하여야 합니다. 용량을 선택하는 적합한 경험 법칙은 인스턴스의 한 영역을 손실하여 예상 부하를 처리하는 데 충분한 용량을 남기도록 애플리케이션에 충분한 인스턴스를 보장하는 것입니다.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
팁
인스턴스 용량을 결정하려면 다음 계산을 사용할 수 있습니다.
플랫폼에서 세 영역에 걸쳐 VM을 분산하고 하나 이상의 영역 오류를 고려해야 하므로 최대 워크로드 인스턴스 수에 영역 수/(영역 수-1) 또는 3/2의 인수를 곱합니다. 예를 들어 일반적인 최대 워크로드에 4개의 인스턴스가 필요한 경우 6개의 인스턴스 프로비전해야 합니다((2/3 * 6개 인스턴스) = 4개 인스턴스).
전용 환경을 사용하여 영역 중복 App Service 배포
격리된 v2 플랜에서 App Service Environment v3를 만드는 방법을 알아보려면 App Service Environment 만들기를 참조하세요.
문제 해결
| 오류 메시지 | 설명 | 권장 |
|---|---|---|
| 리소스 그룹 'RG-NAME'에는 영역 중복을 사용할 수 없습니다. 새 리소스 그룹에 App Service 요금제 'ASP-NAME'을 배포하세요. | 가용성 영역은 최신 App Service 공간에서만 지원됩니다. 지원되는 지역 중 하나를 사용하는 경우에도 리소스 그룹에 대해 가용성 영역이 지원되지 않는 경우 오류가 발생합니다. | 워크로드가 가용성 영역을 지원하는 스탬프에 배치되도록 하려면 새 리소스 그룹, App Service 요금제 및 App Service를 만듭니다. |
내결함성
가용성 영역 오류에 대비하려면 서비스 용량을 과도하게 프로비전하여 솔루션이 1/3 용량 손실을 허용하고 영역 전체가 중단되는 동안 성능 저하 없이 계속 작동할 수 있도록 해야 합니다. 플랫폼에서 세 영역에 걸쳐 VM을 분산하고 하나 이상의 영역 오류를 고려해야 하므로 최대 워크로드 인스턴스 수에 영역 수/(영역 수-1) 또는 3/2의 인수를 곱합니다. 예를 들어 일반적인 최대 워크로드에 4개의 인스턴스가 필요한 경우 6개의 인스턴스 프로비전해야 합니다((2/3 * 6개 인스턴스) = 4개 인스턴스).
영역 다운 환경
트래픽은 사용 가능한 모든 App Service 인스턴스로 라우팅됩니다. 영역의 가동이 중단되는 경우 App Service 플랫폼에서 손실된 인스턴스를 검색하고 자동으로 새 대체 인스턴스를 찾고 필요에 따라 트래픽을 분산하려고 시도합니다. 자동 크기 조정이 구성되어 있고 더 많은 인스턴스가 필요하다고 판단되는 경우 자동 크기 조정에서도 더 많은 인스턴스를 추가하도록 App Service에 요청합니다. 자동 크기 조정 동작은 App Service 플랫폼 동작과 독립적이며 자동 크기 조정의 인스턴스 수 사양이 3의 배수일 필요는 없습니다.
참고 항목
영역 다운 시나리오에서 추가 인스턴스에 대한 요청이 성공할 것이라는 보장은 없습니다. 손실된 인스턴스를 다시 채우는 작업은 최선을 다해 이루어집니다. 권장 솔루션은 다음 섹션에 설명된 대로 영역 손실을 고려하여 App Service 요금제를 만들고 구성하는 것입니다.
가용성 영역이 사용하도록 설정된 App Service 요금제로 배포된 애플리케이션은 동일한 지역의 다른 영역이 중단된 경우에도 계속 실행되고 트래픽을 제공합니다. 그러나 App Service 요금제 크기 조정, 애플리케이션 만들기, 애플리케이션 구성 및 애플리케이션 게시를 포함한 비 런타임 동작은 다른 가용성 영역에서 발생하는 중단의 영향을 계속 받을 수 있습니다. App Service 요금제의 영역 중복은 배포된 애플리케이션에 대한 지속적인 작동 시간만 보장합니다.
App Service 플랫폼에서 인스턴스를 영역 중복 App Service 요금제에 할당하는 경우 기본 Azure Virtual Machine Scale Sets에서 제공하는 최상의 영역 분산을 사용합니다. 각 영역에 동일한 수의 VM이 있거나 App Service 요금제에서 사용하는 다른 모든 영역에 하나보다 많거나 적은 VM이 있는 경우 App Service 요금제가 "분산"됩니다.
가용성 영역 마이그레이션
기존 App Service 인스턴스 또는 환경 리소스를 비가용성 영역 지원에서 가용성 영역 지원으로 마이그레이션할 수 없습니다. 가용성 영역에 대한 지원을 받으려면 가용성 영역을 사용하도록 설정된 리소스를 생성해야 합니다.
가격 책정
App Service Premium v2 또는 Premium v3 플랜을 사용하는 다중 테넌트 환경의 경우 App Service 계획에 인스턴스가 3개 이상 있는 한 가용성 영역 사용과 관련된 추가 비용은 없습니다. App Service 요금제 SKU, 지정한 용량 및 자동 크기 조정 조건에 따라 크기를 조정하는 모든 인스턴스에 따라 요금이 청구됩니다. 가용성 영역을 사용하도록 설정하지만 용량을 3보다 작게 지정하면 플랫폼에서 3개의 최소 인스턴스 수를 적용하고 이러한 3개 인스턴스에 대한 요금을 청구합니다. App Service Environment v3에는 가용성 영역에 대한 다른 가격 책정 모델이 있습니다. App Service Environment v3에 대한 가격 책정 정보는 가격 책정을 참조하세요.
지역 간 재해 복구 및 비즈니스 연속성
DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.
DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 공유 책임 모델에서 Microsoft는 기준 인프라 및 플랫폼 서비스를 사용할 수 있도록 보장합니다. 동시에 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 사용하도록 설정된 다른 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우 자신의 워크로드에 적합한 재해 복구 계획을 설정할 책임이 있습니다. Azure PaaS(Platform as a Service) 제품에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공하며, 서비스별 기능을 사용하여 빠른 복구를 지원하여 DR 계획을 개발하는 데 도움이 될 수 있습니다.
이 섹션에서는 App Service에 배포된 웹앱에 대한 몇 가지 일반적인 전략에 대해 설명합니다.
App Service에서 웹앱을 만들고, 리소스를 만드는 동안 Azure 지역을 선택하면 단일 지역 앱이 됩니다. 재해 중에 지역을 사용할 수 없게 되면 애플리케이션도 사용할 수 없게 됩니다. 다중 지역 지리적 위치 아키텍처를 사용하여 보조 Azure 지역에서 동일한 배포를 만드는 경우 애플리케이션이 단일 지역 재해에 덜 취약해져서 비즈니스 연속성이 보장됩니다. 지역 간 데이터 복제를 통해 마지막 애플리케이션 상태를 복구할 수 있습니다.
IT의 경우 비즈니스 연속성 플랜은 주로 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)에 의해 좌우됩니다. RTO 및 RPO에 대한 자세한 내용은 복구 목표를 참조하세요.
일반적으로 RTO를 중심으로 SLA를 유지 관리하는 것은 지역 재해에 대해 실용적이지 않으며 일반적으로 RPO만을 고려해서 재해 복구 전략을 디자인할 수 있습니다(즉, 중단을 최소화하지 않고 데이터 복구에 집중). 그러나 Azure를 사용하면 실용적일 뿐만 아니라 자동 지역 장애 조치를 위해 App Service를 간단하게 배포할 수도 있습니다. 이렇게 하면 RTO 및 RPO를 모두 처리하여 애플리케이션의 재해를 추가적으로 방지할 수 있습니다.
원하는 RTO 및 RPO 메트릭에 따라 App Service 다중 테넌트 및 App Service Environment 모두에 일반적으로 세 가지 재해 복구 아키텍처가 사용됩니다. 각 아키텍처는 다음 표에 설명되어 있습니다.
| 메트릭 | 활성-활성 | 활성-수동 | 수동/콜드 |
|---|---|---|---|
| RTO | 실시간 또는 초 | 분 | 시간 |
| RPO | 실시간 또는 초 | 분 | 시간 |
| 비용 | $$$ | $$ | $ |
| 시나리오 | 중요 업무용 앱 | 우선 순위가 높은 앱 | 우선 순위가 낮은 앱 |
| 다중 지역 사용자 트래픽을 제공하는 기능 | 예 | 예/가능함 | 아니요 |
| 코드 배포 | CI/CD 파이프라인 선호 | CI/CD 파이프라인 선호 | 백업 및 복원 |
| 가동 중지 시간 동안 새 App Service 리소스 만들기 | 필요 없음 | 필요 없음 | Required |
참고 항목
애플리케이션은 Azure SQL Database 및 Azure Storage 계정과 같은 Azure의 다른 데이터 서비스에 따라 달라질 가능성이 큽니다. 이러한 각 종속 Azure 서비스에 대한 재해 복구 전략도 개발하는 것이 좋습니다. SQL Database에 대해서는 Azure SQL Database에 대한 활성 지역 복제를 참조하세요. Azure Storage에 대해서는 Azure Storage 중복성을 참조하세요.
다중 지역 지리의 재해 복구
App Service 백업 및 복원 사용과 같이 활성-활성 또는 활성-수동 아키텍처에서 Azure 지역 간에 웹앱 콘텐츠 및 구성을 복제하는 방법에는 여러 가지가 있습니다. 그러나 백업 및 복원은 특정 시점 스냅샷을 만들고 결국 지역 간에 웹앱 버전 관리 문제가 발생합니다. 백업 및 복원 지침과 재해 복구 지침 간의 비교는 아래 표를 참조하세요.
백업 및 복원과 재해 복구 비교
| 플랫폼 | 백업 및 복원 지침 | 재해 복구 지침 |
|---|---|---|
| App Service Web Apps (무료 및 공유 가격 책정 계층) |
무료 또는 공유 계층에 배포된 웹 애플리케이션이 있고 이러한 웹앱의 백업 및 복원 기능에 대한 액세스 권한이 필요한 경우 기본 계층 이상으로 스케일 업하세요. | 지역 재해가 발생한 동안에는 다른 Azure 지역에서 App Service 리소스를 다시 온라인 상태로 만듭니다. 2025년 3월 31일부터 App Service 애플리케이션은 지역 전체 오류 복구 문서에 설명된 대로 Azure 지역의 재해 중에는 재해 복구 모드로 전환되지 않습니다. 지역 재해 발생 시 가동 중지 시간 및 데이터 손실을 방지하려면 일반적으로 사용되는 재해 복구 기술을 구현하는 것이 좋습니다. |
| App Service Web Apps (기본, 표준 및 프리미엄 가격 책정 계층) |
Azure App Service에서 주문형 사용자 지정 백업을 만들거나 자동 백업을 활용할 수 있습니다. 기존 앱을 덮어쓰거나 새 앱 또는 슬롯으로 복원하면 백업을 복원할 수 있습니다. 자세한 내용은 Azure App Service 앱 백업 및 복원을 참조하세요. |
지역 재해 발생 시 다른 Azure 지역에서 App Service 리소스를 다시 온라인 상태로 만드는 방법에 대한 현재 지침은 지역 전체 오류에서 복구 - Azure App Service에서 확인할 수 있습니다. 2025년 3월 31일부터 Azure App Service 웹 애플리케이션은 지역 전체 오류 복구 문서에 설명된 대로 Azure 지역의 재해 중에는 재해 복구 모드로 더 이상 전환되지 않습니다. 지역 재해가 있는 경우 웹앱의 기능 또는 데이터 손실을 방지하기 위해 일반적으로 사용되는 재해 복구 기술을 구현하는 것이 좋습니다. |
| App Service Environment(V2 및 V3) | Azure App Service Environment에서는 주문형 사용자 지정 백업을 만들거나 자동 백업을 사용할 수 있습니다. 자동 백업은 다른 App Service Environment가 아닌 동일한 App Service Environment 내의 대상 앱으로 복원할 수 있습니다. 사용자 지정 백업은 다른 App Service Environment의 대상 앱으로 복원할 수 있습니다(예: V2 App Service Environment에서 V3 App Service Environment로). 원본 앱과 동일한 OS 플랫폼의 대상 앱으로 백업을 복원할 수 있습니다. 자세한 내용은 Azure App Service 앱 백업 및 복원을 참조하세요. |
일반적으로 사용되는 재해 복구 기술을 사용하여 App Service Environment에 배포된 웹앱에 대한 재해 복구 지침을 구현하는 것이 좋습니다. |
| Azure Functions: 전용 계획 |
전용(App Service) 플랜에서 함수 앱을 실행하는 경우, 필수 함수 앱 콘텐츠는 기본 제공 스토리지를 사용하여 유지 관리됩니다. 전용 플랜에서는 주문형 사용자 지정 백업을 만들거나 자동 백업을 사용할 수 있습니다. 기존 앱을 덮어쓰거나 새 앱 또는 슬롯으로 복원하면 백업을 복원할 수 있습니다. 자세한 내용은 Azure App Service에서 앱 백업 및 복원을 참조하세요. Azure Files는 전용 플랜에서 사용되지 않지만, Azure Files 연결로 앱을 잘못 구성한 경우 백업이 지원되지 않습니다. |
지역 재해 발생 시 다른 Azure 지역에서 전용 플랜의 함수 앱 리소스를 다시 온라인 상태로 전환하는 방법에 대한 최신 지침은 지역 전체 장애에서 복구 - Azure App Service에서 확인할 수 있습니다. 2025년 3월 31일부터 App Service 애플리케이션은 지역 전체 오류 복구 문서에 설명된 대로 Azure 지역의 재해 중에는 재해 복구 모드로 전환되지 않습니다. 대신 함수 앱에서 안정성을 계획해야 합니다. 전용 플랜의 함수 앱에 대해 일반적으로 사용되는 재해 복구 기술을 참조할 수도 있습니다. |
| Azure Functions: Flex 사용량, 사용량 및 프리미엄 플랜 |
Flex 사용량 플랜, 사용량 플랜 또는 프리미엄 플랜에서 실행되는 함수 앱은 App Service에서 사용자 지정 및 자동 백업 기능을 사용할 수 없습니다. 이러한 동적 크기 조정 플랜에서 함수 앱 콘텐츠는 Azure Storage에서 유지 관리됩니다. Azure Storage 중복도 옵션을 사용하여 중단 중에 스토리지 계정이 가용성 및 내구성 목표를 충족하는지 확인합니다. Azure Portal에서 기존 함수 앱 프로젝트를 .zip 파일로 다운로드할 수도 있습니다. |
함수 앱에서 안정성을 계획할 것을 적극 권장합니다. |
백업 및 복원 방법의 제한을 방지하려면 두 Azure 지역에 코드를 배포하도록 CI/CD 파이프라인을 구성합니다. Azure Pipelines 또는 GitHub Actions를 사용하는 것이 좋습니다. 자세한 내용은 Azure App Service에 지속적인 배포를 참조하세요.
중단 검색, 알림 및 관리
재해 발생 시 적시에 알림을 보내도록 웹앱에 대한 모니터링 및 경고를 설정하는 것이 좋습니다. 자세한 내용은 Application Insights 가용성 테스트를 참조하세요.
Azure에서 애플리케이션 리소스를 관리하려면 IaC(Infrastructure-as-Code) 메커니즘을 사용합니다. 여러 지역에 걸친 복잡한 배포에서 지역을 독립적으로 관리하고 신뢰할 수 있는 방식으로 지역 간에 구성을 동기화하려면 예측 가능하고 테스트 가능하며 반복 가능한 프로세스가 필요합니다. Azure Resource Manager 템플릿 또는 Terraform과 같은 IaC 도구를 고려합니다.
재해 복구 및 중단 검색 설정
다중 지역 지리적 위치에서 재해 복구를 준비하려면 활성-활성 또는 활성-수동 아키텍처를 사용할 수 있습니다.
활성-활성 아키텍처
활성-활성 재해 복구 아키텍처에서 동일한 웹앱은 두 개의 별도 지역에 배포되고 Azure Front Door는 트래픽을 두 활성 지역으로 라우팅하는 데 사용됩니다.
이 예제 아키텍처를 사용할 경우:
- 동일한 App Service 앱은 가격 책정 계층 및 인스턴스 수를 포함하는 두 개의 개별 지역에 배포됩니다.
- App Service 앱으로 직접 전송되는 공용 트래픽이 차단됩니다.
- Azure Front Door는 트래픽을 두 활성 지역으로 라우팅하는 데 사용됩니다.
- 재해 발생 시 지역 중 하나가 오프라인 상태가 되며 Azure Front Door는 트래픽을 온라인 상태로 유지하는 지역으로만 라우팅합니다. 이러한 지역 장애 조치 중에 RTO는 거의 0에 가깝습니다.
- 애플리케이션 파일은 CI/CD 솔루션을 사용하여 두 웹앱에 배포해야 합니다. 이렇게 하면 RPO가 실질적으로 0이 됩니다.
- 애플리케이션이 파일 시스템을 적극적으로 수정하는 경우 RPO를 최소화하는 가장 좋은 방법은 웹앱의 /home 콘텐츠 공유에 직접 쓰는 대신, 탑재된 Azure Storage 공유에만 쓰는 것입니다. 그런 다음, 탑재한 공유에 대해 Azure Storage 중복 기능(GZRS 또는 GRS)을 사용합니다. 여기서 RPO는 약 15분입니다.
App Service 웹앱에 대한 활성-활성 아키텍처를 만드는 단계는 다음과 같이 요약됩니다.
두 개의 서로 다른 Azure 지역에 두 개의 App Service 요금제를 만듭니다. 두 App Service 요금제를 동일하게 구성합니다.
각 App Service 요금제에 하나씩 두 개의 웹앱 인스턴스를 만듭니다.
다음을 사용하여 Azure Front Door 프로필을 만듭니다.
- 엔드포인트
- 각각 우선 순위가 1인 두 개의 원본 그룹. 우선 순위가 동일하면 Azure Front Door가 두 지역 모두에 동일하게 트래픽을 라우팅하도록 지시합니다(따라서 활성-활성).
- 경로.
데이터베이스, 스토리지 계정 및 인증 공급자와 같은 다른 모든 백 엔드 Azure 서비스를 설정 및 구성합니다.
지속적인 배포를 사용하여 두 웹앱에 코드를 배포합니다.
자습서: Azure App Service에서 고가용성 다중 지역 앱 만들기에서는 활성-수동 아키텍처를 설정하는 방법을 보여 줍니다. 최소한의 변경 내용이 있는 동일한 단계(Azure Front Door의 원본 그룹에서 두 원본 모두에 대해 우선 순위를 "1"로 설정)는 활성-활성 아키텍처를 제공합니다.
활성-수동 아키텍처
이 재해 복구 접근 방식에서 동일한 웹앱은 두 개의 별도 지역에 배포되고 Azure Front Door는 트래픽을 한 지역(활성 지역)으로만 라우팅하는 데 사용됩니다.
이 예제 아키텍처를 사용할 경우:
동일한 App Service 앱이 별도의 두 지역에 배포됩니다.
App Service 앱으로 직접 전송되는 공용 트래픽이 차단됩니다.
Azure Front Door는 트래픽을 주 지역으로 라우팅하는 데 사용됩니다.
비용을 절감하기 위해 보조 App Service 요금제는 인스턴스 수가 더 적거나 가격 책정 계층이 더 낮게 구성됩니다. 다음과 같은 세 가지 방법이 있습니다.
선호 보조 App Service 요금제의 가격 책정 계층은 주 지역과 동일하며 인스턴스 수는 같거나 더 적습니다. 이 방법은 두 App Service 요금제에 대한 기능 및 VM 크기 조정 둘 다에서 패리티를 보장합니다. 지역 장애 조치 중 RTO는 인스턴스를 스케일 아웃하는 시간에 따라서만 좌우됩니다.
선호도가 낮음 보조 App Service 요금제의 가격 책정 계층 유형(예: PremiumV3)은 동일하지만 VM 크기는 더 작으며 인스턴스 수도 더 적습니다. 예를 들어 주 지역은 P3V3 계층에 있고 보조 지역은 P1V3 계층에 있을 수 있습니다. 이 방법은 여전히 두 App Service 요금제에 대한 기능 패리티를 보장하지만 크기 패리티가 부족하면 보조 지역이 활성 지역이 될 때 수동 스케일 업이 필요할 수 있습니다. 지역 장애 조치 동안의 RTO는 인스턴스를 스케일 업하고 스케일 아웃하는 시간에 따라 달라집니다.
가장 선호도가 낮음 보조 App Service 요금제의 가격 책정 계층은 기본 인스턴스와 다르며 인스턴스 수는 더 작습니다. 예를 들어 주 지역은 P3V3 계층에 있고 보조 지역은 S1 계층에 있을 수 있습니다. 보조 App Service 요금제에 애플리케이션을 실행하는 데 필요한 모든 기능이 있는지 확인합니다. 둘 사이의 기능 가용성 차이로 인해 웹앱 복구가 지연될 수 있습니다. 지역 장애 조치 동안의 RTO는 인스턴스를 스케일 업하고 스케일 아웃하는 시간에 따라 달라집니다.
자동 크기 조정은 활성 지역이 비활성 상태가 될 경우 보조 지역에 구성됩니다. 활성 및 수동 지역 모두에서 유사한 자동 크기 조정 규칙을 사용하는 것이 좋습니다.
재해가 발생하는 동안 주 지역은 비활성 상태가 되고 보조 지역이 트래픽 수신을 시작하고 활성 지역이 됩니다.
보조 지역이 활성화되면 네트워크 부하는 미리 구성된 자동 크기 조정 규칙을 트리거하여 보조 웹앱을 스케일 아웃합니다.
활성 지역으로 실행하는 데 필요한 기능이 아직 없는 경우 보조 지역의 가격 책정 계층을 수동으로 스케일 업해야 할 수 있습니다. 예를 들어 자동 크기 조정에는 표준 계층 이상이 필요합니다.
주 지역이 다시 활성화되면 Azure Front Door는 자동으로 트래픽을 다시 전송하고 아키텍처는 이전과 같이 활성-수동으로 돌아갑니다.
애플리케이션 파일은 CI/CD 솔루션을 사용하여 두 웹앱에 배포해야 합니다. 이렇게 하면 RPO가 실질적으로 0이 됩니다.
애플리케이션이 파일 시스템을 적극적으로 수정하는 경우 RPO를 최소화하는 가장 좋은 방법은 웹앱의 /home 콘텐츠 공유에 직접 쓰는 대신, 탑재된 Azure Storage 공유에만 쓰는 것입니다. 그런 다음, 탑재한 공유에 대해 Azure Storage 중복 기능(GZRS 또는 GRS)을 사용합니다. 여기서 RPO는 약 15분입니다.
App Service 웹앱에 대한 활성-수동 아키텍처를 만드는 단계는 다음과 같이 요약됩니다.
- 두 개의 서로 다른 Azure 지역에 두 개의 App Service 요금제를 만듭니다. 보조 App Service 요금제는 앞에서 언급한 방법 중 하나를 사용하여 프로비전할 수 있습니다.
- 보조 App Service 요금제에 대한 자동 크기 조정 규칙을 구성하여 주 지역이 비활성 상태가 될 때 주 지역과 동일한 인스턴스 수로 스케일링되도록 합니다.
- 각 App Service 요금제에 하나씩 웹앱 인스턴스 두 개를 만듭니다.
- 다음을 사용하여 Azure Front Door 프로필을 만듭니다.
- 엔드포인트.
- 주 지역에 대해 우선 순위가 1인 원본 그룹.
- 보조 지역에 대해 우선 순위가 2인 두 번째 원본 그룹. 우선 순위의 차이는 Azure Front Door가 온라인 상태일 때 주 지역을 선호하도록 지시합니다(따라서 활성-수동).
- 경로.
- Azure Front Door 인스턴스의 웹앱으로만 네트워크 트래픽을 제한합니다.
- 데이터베이스, 스토리지 계정 및 인증 공급자와 같은 다른 모든 백 엔드 Azure 서비스를 설정 및 구성합니다.
- 지속적인 배포를 사용하여 두 웹앱에 코드를 배포합니다.
자습서: Azure App Service에서 고가용성 다중 지역 앱 만들기에서는 활성-수동 아키텍처를 설정하는 방법을 보여 줍니다.
수동 콜드 아키텍처
수동/콜드 아키텍처를 사용하여 다른 지역에 있는 Azure Storage 계정에서 웹앱의 정기적인 백업을 만들고 유지 관리합니다.
이 예제 아키텍처를 사용할 경우:
단일 웹앱이 단일 지역에 배포됩니다.
웹앱이 동일한 지역의 Azure Storage 계정에 주기적으로 백업됩니다.
백업의 지역 간 복제는 Azure 스토리지 계정의 데이터 중복 구성에 따라 달라집니다. 가능하면 Azure Storage 계정을 GZRS로 설정해야 합니다. GZRS는 지역 내의 동기 영역 중복과 보조 지역의 비동기 영역 중복을 모두 제공합니다. GZRS를 사용할 수 없는 경우 계정을 GRS로 구성합니다. GZRS와 GRS 모두 RPO가 약 15분입니다.
스토리지 계정의 주 지역을 사용할 수 없게 될 때 백업을 검색할 수 있도록 하려면 보조 지역에 대한 읽기 전용 액세스를 사용하도록 설정합니다(스토리지 계정을 각각 RA-GZRS 또는 RA-GRS로 설정). 지역 중복을 활용하도록 애플리케이션을 디자인하는 방법에 관한 자세한 내용은 지역 중복을 사용하여 고가용성 애플리케이션 디자인을 참조하세요.
웹앱의 지역에서 재해가 발생하면 주로 읽기 액세스 권한이 있는 보조 지역에서 Azure Storage 계정의 백업을 사용하여 필요한 모든 App Service 종속 리소스를 수동으로 배포해야 합니다. RTO는 몇 시간 또는 며칠일 수 있습니다.
RTO를 최소화하려면 웹앱 백업을 다른 Azure 지역으로 복원하는 데 필요한 모든 단계를 요약한 포괄적인 플레이북을 사용하는 것이 좋습니다.
App Service 웹앱에 대한 수동 콜드 영역을 만드는 단계는 다음과 같이 요약됩니다.
웹앱과 동일한 지역에 Azure 스토리지 계정을 만듭니다. 표준 성능 계층을 선택하고 중복도로 GRS(지역 중복 스토리지) 또는 GZRS(지역 영역 중복 스토리지)를 선택합니다.
RA-GRS 또는 RA-GZRS(보조 지역에 대한 읽기 액세스)를 사용하도록 설정합니다.
웹앱에 대한 사용자 지정 백업을 구성합니다. 웹앱 백업 일정(예: 시간별)을 설정하기로 결정할 수 있습니다.
스토리지 계정의 보조 지역의 웹앱 백업 파일을 검색할 수 있는지 확인합니다.
팁
Azure Front Door 외에도 Azure는 Azure Traffic Manager 등의 다른 부하 분산 옵션을 제공합니다. 여러 다양한 옵션을 비교하려면 부하 분산 옵션 - Azure 아키텍처 센터를 참조하세요.
단일 지역 지리의 재해 복구
웹앱의 지역에 GZRS 또는 GRS 스토리지가 없거나 지역 쌍이 아닌 Azure 지역에 있는 경우 ZRS(영역 중복 스토리지) 또는 LRS(로컬 중복 스토리지)를 활용하여 유사한 아키텍처를 만들어야 합니다. 예를 들어 다음과 같이 스토리지 계정에 대한 보조 지역을 수동으로 만들 수 있습니다.
GRS 및 GZRS 없이 수동-콜드 지역을 만드는 단계는 다음과 같이 요약됩니다.
웹앱의 동일한 지역에 Azure 스토리지 계정을 만듭니다. 표준 성능 계층을 선택하고 중복도로 ZRS(영역 중복 스토리지)를 선택합니다.
웹앱에 대한 사용자 지정 백업을 구성합니다. 웹앱 백업 일정(예: 시간별)을 설정하기로 결정할 수 있습니다.
웹앱 백업 파일을 스토리지 계정의 보조 지역에서 검색할 수 있는지 확인합니다.
다른 지역에 두 번째 Azure 스토리지 계정을 만듭니다. 표준 성능 계층을 선택하고 중복도로 LRS(로컬 중복 스토리지)를 선택합니다.
AzCopy와 같은 도구를 사용하여 사용자 지정 백업(Zip, XML 및 로그 파일)을 주 지역에서 보조 스토리지로 복제합니다. 예시:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'PowerShell 워크플로 Runbook과 함께 Azure Automation을 사용하여 일정에 따라 복제 스크립트를 실행할 수 있습니다. 복제 일정이 웹앱 백업과 유사한 일정을 따르는지 확인합니다.