참고 항목
App Service Environment 버전 3은 이 아키텍처의 기본 구성 요소입니다. 이제 버전 3을 사용할 수 있습니다. 버전 1과 2는 2024년 8월 31일에 사용 중지됩니다.
가용성 영역은 지정된 지역에 있는 데이터 센터의 물리적으로 구분된 컬렉션입니다. 영역에 리소스를 배포하면 영역으로 제한되는 중단이 애플리케이션의 가용성에 영향을 주지 않습니다. 이 아키텍처는 영역 다시 실행 아키텍처에 배포하여 App Service Environment 배포의 복원력을 개선하는 방법을 보여 줍니다. 이러한 영역은 근접과 관련이 없습니다. 서로 다른 구독에 대해 서로 다른 물리적 위치에 매핑할 수 있습니다. 아키텍처는 단일 구독 배포를 가정합니다.
App Service Environment를 영역 중복으로 구성하면 플랫폼은 선택한 지역의 세 영역에 Azure 앱 Service 계획의 인스턴스를 자동으로 배포합니다. 따라서 최소 App Service 계획 인스턴스 수는 항상 3개입니다.
가용성 영역을 지원하는 Azure 서비스는 영역, 영역 중복 또는 둘 다일 수 있습니다. 영역 서비스는 특정 영역에 배포할 수 있습니다. 영역 중복 서비스는 영역 간에 자동으로 배포될 수 있습니다. 자세한 지침 및 권장 사항은 가용성 영역 지원을 참조하세요. 이전 버전의 App Service Environment(v2)는 영역 배포만 지원하지만 현재 버전(v3)은 영역 중복 배포를 지원합니다.
이 아키텍처에 대한 참조 구현은 GitHub에서 사용할 수 있습니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
이 참조 구현의 App Service Environment 서브넷에 있는 리소스는 표준 App Service Environment 배포 아키텍처의 리소스와 동일합니다. 이 참조 구현은 App Service Environment v3 및 Azure Cache for Redis의 영역 중복 기능을 사용하여 더 높은 가용성을 제공합니다. 이 참조 아키텍처의 범위는 단일 지역으로 제한됩니다.
워크플로
이 섹션에서는 이 아키텍처에 사용되는 서비스의 가용성 특성에 대해 설명합니다.
App Service Environment v3 는 영역 중복성을 위해 구성할 수 있습니다. App Service Environment를 만드는 동안에만 영역 중복을 구성할 수 있으며 모든 App Service Environment v3 종속성을 지원하는 지역에서만 구성할 수 있습니다. 영역 중복 App Service Environment의 각 App Service 계획에는 세 개의 영역에 배포할 수 있도록 최소 3개의 인스턴스가 있어야 합니다. 최소 요금은 9개의 인스턴스에 대한 것입니다. 자세한 내용은 이 가격 책정 지침을 참조하세요. 자세한 지침 및 권장 사항은 가용성 영역 대한 App Service Environment 지원을 참조하세요.
Azure Virtual Network 는 단일 지역에 있는 모든 가용성 영역에 걸쳐 있습니다. 가상 네트워크의 서브넷도 가용성 영역을 교차합니다. 자세한 내용은 App Service Environment에 대한 네트워크 요구 사항을 참조 하세요.
Application Gateway v2 는 영역 중복입니다. 가상 네트워크와 마찬가지로 지역당 여러 가용성 영역에 걸쳐 있습니다. 따라서 단일 애플리케이션 게이트웨이는 참조 아키텍처에 표시된 것처럼 고가용성 시스템에 충분합니다. 참조 아키텍처는 OWASP(Open Web Application Security Project)의 CRS(핵심 규칙 집합) 구현에 따라 일반적인 위협 및 취약성에 대한 향상된 보호를 제공하는 Application Gateway의 WAF SKU를 사용합니다. 자세한 내용은 Application Gateway v2 및 WAF v2 크기 조정을 참조 하세요.
Azure Firewall은 고가용성을 기본적으로 지원합니다. 추가 구성 없이 여러 영역을 교차할 수 있습니다.
필요한 경우 방화벽을 배포할 때 특정 가용성 영역을 구성할 수도 있습니다. 자세한 내용은 Azure Firewall 및 가용성 영역 참조하세요. (이 구성은 참조 아키텍처에서 사용되지 않습니다.)
Microsoft Entra ID 는 가용성 영역 및 지역에 걸쳐 있는 고가용성, 높은 중복 글로벌 서비스입니다. 자세한 내용은 Microsoft Entra 가용성 진행을 참조 하세요.
GitHub Actions 는 이 아키텍처에서 CI/CD(지속적인 통합 및 지속적인 배포) 기능을 제공합니다. App Service Environment는 가상 네트워크에 있으므로 가상 머신은 App Service 계획에 앱을 배포하기 위해 가상 네트워크의 jumpbox로 사용됩니다. 이 작업은 가상 네트워크 외부에서 앱을 빌드합니다. 향상된 보안 및 원활한 RDP/SSH 연결을 위해 Jumpbox에 Azure Bastion을 사용하는 것이 좋습니다.
Azure Cache for Redis 는 영역 중복 서비스입니다. 영역 중복 캐시는 여러 가용성 영역에 배포된 VM에서 실행됩니다. 이 서비스는 더 높은 복원력과 가용성을 제공합니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
가용성
App Service 환경
가용성 영역에 App Service Environment를 배포하여 중요 비즈니스용 워크로드에 대한 복원력과 안정성을 제공할 수 있습니다. 이 구성을 영역 중복이라고도 합니다.
영역 중복을 구현하는 경우 플랫폼은 선택한 지역의 세 영역에 App Service 계획의 인스턴스를 자동으로 배포합니다. 따라서 최소 App Service 계획 인스턴스 수는 항상 3개입니다. 3보다 큰 용량을 지정하고 인스턴스 수를 3개로 나눌 경우 인스턴스가 균등하게 배포됩니다. 그렇지 않으면 재기본 인스턴스가 다시 기본 영역에 추가되거나 두 영역의 재기본에 배포됩니다.
- App Service Environment를 만들 때 가용성 영역을 구성합니다.
- 해당 App Service Environment에서 만든 모든 App Service 계획에는 최소 3개의 인스턴스가 필요합니다. 영역이 자동으로 중복됩니다.
- 새 App Service Environment를 만들 때만 가용성 영역을 지정할 수 있습니다. 가용성 영역을 사용하도록 기존 App Service Environment를 변환할 수 없습니다.
- 가용성 영역은 하위 지역 집합에서 만 지원됩니다.
자세한 내용은 가용성 영역 지원으로 App Service Environment 마이그레이션을 참조하세요.
복원력
App Service Environment에서 실행되는 애플리케이션은 Application Gateway에 대한 백 엔드 풀 을 형성합니다. 애플리케이션에 대한 요청이 공용 인터넷에서 제공되면 게이트웨이는 App Service Environment에서 실행되는 애플리케이션에 요청을 전달합니다. 이 참조 아키텍처는 기본 웹 프런트 엔드 votingApp내에서 상태 검사 구현합니다. 이 상태 프로브는 웹 API 및 Redis 캐시가 정상인지 여부를 검사. Startup.cs에서 이 프로브를 구현하는 코드를 볼 수 있습니다.
var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
{
Path = "/health"
};
services.AddHealthChecks()
.AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
.AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));
다음 코드는 commands_ha.azcli 스크립트가 애플리케이션 게이트웨이에 대한 백 엔드 풀 및 상태 프로브를 구성하는 방법을 보여 줍니다.
# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
"name": "votapp",
"routingPriority": 100,
"hostName": "${APPGW_APP1_URL}",
"backendAddresses": [
{
"fqdn": "${INTERNAL_APP1_URL}"
}
],
"certificate": {
"data": "${CERT_DATA_1}",
"password": "${PFX_PASSWORD}"
},
"probePath": "/health"
}
]
구성 요소(웹 프런트 엔드, API 또는 캐시)가 상태 프로브에 실패하면 Application Gateway는 백 엔드 풀의 다른 애플리케이션으로 요청을 라우팅합니다. 이 구성은 요청이 항상 완전히 사용 가능한 App Service Environment 서브넷의 애플리케이션으로 라우팅되도록 합니다.
상태 프로브는 표준 참조 구현에서도 구현됩니다. 이 경우 게이트웨이는 상태 프로브가 실패하면 오류를 반환합니다. 그러나 고가용성 구현은 애플리케이션의 복원력과 사용자 환경의 품질을 향상시킵니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
고가용성 아키텍처에 대한 비용 고려 사항은 표준 배포와 유사합니다.
다음과 같은 차이점이 비용에 영향을 줄 수 있습니다.
- 영역 중복 App Service Environment에서 9개 이상의 App Service 계획 인스턴스에 대한 요금이 청구됩니다. 자세한 내용은 App Service Environment 가격 책정을 참조 하세요.
- Azure Cache for Redis는 영역 중복 서비스이기도 합니다. 영역 중복 캐시는 더 높은 복원력과 가용성을 제공하기 위해 여러 가용성 영역에 배포된 VM에서 실행됩니다.
고가용성, 복원력 및 매우 안전한 시스템에 대한 절충은 비용이 증가합니다. 가격 계산기를 사용하여 가격 책정과 관련하여 요구 사항을 평가합니다.
배포 고려 사항
이 참조 구현은 하나의 jumpbox VM만 사용하여 표준 배포와 동일한 프로덕션 수준 CI/CD 파이프라인을 사용합니다. 그러나 세 영역 각각에 대해 하나의 jumpbox를 사용하도록 결정할 수 있습니다. jumpbox는 앱의 가용성에 영향을 주지 않으므로 이 아키텍처는 하나의 jumpbox만 사용합니다. jumpbox는 배포 및 테스트에만 사용됩니다.
시나리오 배포
이 아키텍처에 대한 참조 구현을 배포하는 방법에 대한 자세한 내용은 GitHub 추가 정보를 참조 하세요. 고가용성 배포에 스크립트를 사용합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Deep Bhattacharya | 클라우드 솔루션 설계자
- Suhas Rao | 클라우드 솔루션 설계자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
예상 최대 부하 용량에 따라 동일한 지역 내 또는 여러 지역에 걸쳐 애플리케이션의 크기를 수평으로 조정하여 이 아키텍처를 수정할 수 있습니다. 여러 지역에서 애플리케이션을 복제하면 지진 또는 기타 자연 재해로 인한 것과 같은 광범위한 지리적 데이터 센터 오류의 위험을 완화하는 데 도움이 될 수 있습니다. 수평 크기 조정에 대한 자세한 내용은 App Service Environment를 사용하여 지리적으로 분산된 크기를 참조 하세요. 전역적이고 고가용성 라우팅 솔루션의 경우 Azure Front Door를 사용하는 것이 좋습니다.