App Service Environment를 사용하는 엔터프라이즈 배포
이 참조 아키텍처는 App Service Environment 버전 3을 사용하는 일반적인 엔터프라이즈 워크로드를 보여 줍니다. 또한 워크로드의 보안을 강화하기 위한 모범 사례도 설명합니다.
비고
App Service Environment 버전 3은 이 아키텍처의 주요 구성 요소입니다. 버전 1과 2 는 2024년 8월 31일에 사용 중지되었습니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
이 아키텍처에 대한 참조 구현은 GitHub에서 사용할 수 있습니다.
워크플로
다음 두 가지 방법으로 App Service Environment를 배포할 수 있습니다.
공용 IP 주소가 있는 외부 App Service Environment
ILB( 내부 부하 분산 장치)에 속하는 내부 IP 주소가 있는 내부 App Service Environment
이 참조 아키텍처는 ILB App Service Environment라고도 하는 내부 App Service Environment에 엔터프라이즈 웹 애플리케이션을 배포합니다. 다음 기능이 필요한 시나리오에서 ILB App Service Environment를 사용합니다.
클라우드에서 보안이 강화된 인트라넷 애플리케이션을 호스트하고 사이트 간 VPN 또는 Azure ExpressRoute를 통해 액세스합니다.
WAF(웹 애플리케이션 방화벽)를 사용하여 앱에 대한 보호 계층을 제공합니다.
공용 DNS(도메인 이름 시스템) 서버에 나열되지 않은 클라우드의 호스트 앱입니다.
프런트 엔드 앱이 매우 안전한 방식으로 통합할 수 있는 인터넷 격리 백 엔드 앱을 만듭니다.
항상 엔터프라이즈 가상 네트워크의 자체 서브넷에 App Service Environment를 배포합니다. 이 방법은 들어오고 나가는 트래픽을 엄격하게 제어합니다. 이 서브넷 내에서 Azure App Service 애플리케이션은 앱을 실행하는 데 필요한 물리적 리소스 컬렉션인 하나 이상의 App Service 계획에서 실행됩니다. 복잡성 및 리소스 요구 사항에 따라 여러 앱이 App Service 계획을 공유할 수 있습니다. App Service Environment 인프라는 스토리지, 컴퓨팅 및 크기 조정을 포함하여 호스트된 앱에 필요한 모든 리소스를 관리합니다.
이 참조 구현은 프라이빗 웹 API 및 함수와 상호 작용하는 Voting App이라는 웹앱을 배포합니다. 또한 테스트 앱이라는 모의 웹 앱을 배포하여 다중 앱 배포를 보여 줍니다. 참조 구현에서 각 App Service 앱은 필요할 때 독립적인 크기 조정을 가능하게 하는 자체 App Service 계획에서 실행됩니다.
이 구현의 간단한 투표 앱을 사용하면 사용자가 기존 항목을 보고, 새 항목을 만들고, 기존 항목에 투표할 수 있습니다. Web API는 항목과 투표를 만들고 검색합니다. 데이터는 Azure SQL 데이터베이스에 저장됩니다. 비동기 데이터 업데이트를 보여주기 위해 웹앱은 Azure Service Bus 인스턴스에서 새로 추가된 투표를 큐에 대기합니다. 이 함수는 큐에 추가된 투표를 선택하고 SQL 데이터베이스를 업데이트합니다. Azure Cosmos DB는 웹앱이 브라우저에 표시하기 위해 검색하는 모의 광고입니다. 애플리케이션은 캐시 관리에 Azure Cache for Redis를 사용합니다. 프리미엄 계층 Azure Cache for Redis는 App Service Environment와 동일한 가상 네트워크에서 구성되며 자체 서브넷에서 실행됩니다. 이 설정은 캐시에 대한 향상된 보안 및 격리를 제공합니다.
웹앱은 인터넷에서 연결할 수 있는 유일한 구성 요소입니다. 인터넷 트래픽은 WAF로 보호되는 Azure Application Gateway를 통해 와야 합니다. 인터넷 클라이언트는 API 또는 함수 앱에 액세스할 수 없습니다.
Components
다음 서비스는 이 아키텍처에서 App Service Environment를 보호하는 데 도움이 됩니다.
Azure Virtual Network 는 엔터프라이즈가 소유한 프라이빗 Azure 클라우드 네트워크를 제공합니다. 향상된 네트워크 기반 보안 및 격리를 제공합니다. 이 아키텍처는 App Service Environment를 엔터프라이즈 소유 가상 네트워크의 서브넷에 배포합니다. App Service Environment를 사용하면 엔터프라이즈에서 NSG(네트워크 보안 그룹) 및 프라이빗 엔드포인트를 사용하여 액세스하는 네트워크 공간과 리소스를 엄격하게 제어할 수 있습니다.
Application Gateway 는 TLS(전송 계층 보안) 또는 SSL(Secure Sockets Layer) 오프로드 및 WAF가 있는 애플리케이션 수준 웹 트래픽 부하 분산 장치입니다. 이 아키텍처에서 Application Gateway는 공용 IP 주소에서 들어오는 트래픽을 허용하고 ILB App Service Environment의 애플리케이션 엔드포인트로 라우팅합니다. 이 애플리케이션 수준 라우팅은 동일한 ILB App Service Environment 내의 여러 앱으로 트래픽을 라우팅할 수 있습니다. 자세한 내용은 Application Gateway 다중 사이트 호스팅을 참조하세요.
Azure Firewall은 Azure 에 기본 제공되는 클라우드 네이티브 상태 저장 방화벽 서비스입니다. 고가용성 및 무제한 클라우드 확장성을 제공하며 인바운드 및 아웃바운드 필터링 규칙을 모두 지원합니다. 이 아키텍처에서 Azure Firewall은 웹 애플리케이션의 아웃바운드 트래픽을 제한합니다. 경로 테이블은 프라이빗 엔드포인트 채널을 통과하지 않는 나가는 트래픽을 방화벽으로 라우팅하도록 구성됩니다. 간단히 하기 위해 이 아키텍처는 서비스 서브넷에서 모든 프라이빗 엔드포인트를 구성합니다.
Microsoft Entra ID 는 Azure 리소스 및 서비스에 대한 액세스 권한 및 권한 관리를 제공합니다. 관리 ID는 서비스 및 앱에 ID를 할당합니다. Microsoft Entra 인증을 지원하는 모든 서비스에 인증할 수 있습니다. 이 방법을 사용하면 이러한 앱에 대한 자격 증명을 명시적으로 구성할 필요가 없습니다. 이 아키텍처는 웹앱에 관리 ID를 할당합니다.
Azure Key Vault 는 비밀, 암호화 키 및 인증서와 같은 중요한 정보를 안전하게 저장하고 관리하는 클라우드 서비스입니다. 이 아키텍처는 Key Vault를 사용하여 앱에 필요한 비밀 및 자격 증명을 저장합니다. 애플리케이션에 직접 비밀을 저장하는 대신 이 옵션을 사용합니다.
GitHub Actions 는 CI/CD를 사용하도록 설정하는 GitHub에 기본 제공되는 워크플로 자동화 기능입니다. 이 아키텍처에서 App Service Environment는 가상 네트워크에 있으므로 VM은 App Service 계획에 앱을 배포하는 가상 네트워크 내의 점프박스 역할을 합니다. 이 작업은 가상 네트워크 외부에서 앱을 빌드합니다. 향상된 보안 및 원활한 RDP(원격 데스크톱 프로토콜) 및 SSH(Secure Shell) 연결을 위해 Jumpbox에 Azure Bastion 을 사용하는 것이 좋습니다.
다중 사이트 구성
내부 App Service Environment는 HTTP 엔드포인트가 있는 여러 웹앱 및 API를 호스트할 수 있습니다. ILB IP 주소는 가상 네트워크 내에서만 액세스할 수 있으므로 이러한 애플리케이션은 공용 인터넷에 노출되지 않습니다.
Application Gateway 는 이러한 애플리케이션을 인터넷에 선택적으로 노출합니다. App Service Environment는 각 App Service 애플리케이션에 기본 URL을 로 <default-appName>.<app-service-environment-___domain>.appserviceenvironment.net할당합니다.
App Service Environment 도메인 이름을 App Service Environment ILB IP 주소에 매핑하는 프라이빗 DNS 영역이 만들어집니다. 이 방법은 가상 네트워크 내에서 앱 액세스에 대한 사용자 지정 DNS를 방지합니다.
Application Gateway는 게이트웨이의 IP 주소에서 HTTP 요청을 수락하는 수신기 를 포함하도록 구성됩니다. 간단히 하기 위해 이 구현에서는 공용 DNS 이름 등록을 사용하지 않습니다. 임의로 선택한 URL을 Application Gateway IP 주소를 가리키도록 컴퓨터의 localhost 파일을 수정해야 합니다. 수신기는 자체 서명된 인증서를 사용하여 이러한 요청을 처리합니다. Application Gateway에는 각 App Service 애플리케이션의 기본 URL에 대한 백 엔드 풀 이 있습니다. 라우팅 규칙은 수신기를 백 엔드 풀에 연결하도록 구성됩니다. HTTP 설정 은 게이트웨이와 App Service Environment 간의 연결에서 암호화를 사용하는지 여부를 결정합니다. 또한 이러한 설정은 백 엔드 풀의 호스트 이름으로 들어오는 HTTP 호스트 헤더를 재정의합니다. 이 구현에서는 기본 App Service Environment 앱 URL에 대해 만든 기본 인증서를 사용하고 게이트웨이는 해당 인증서를 신뢰합니다. 요청은 해당 앱의 기본 URL로 리디렉션됩니다. 가상 네트워크에 연결된 프라이빗 DNS는 이 요청을 ILB IP 주소로 전달합니다. 그런 다음 App Service Environment는 요청된 앱 서비스에 요청을 전달합니다. App Service Environment 앱 내의 모든 HTTP 통신은 프라이빗 DNS를 통과합니다. 각 App Service Environment 앱에 대한 애플리케이션 게이트웨이에서 수신기, 백 엔드 풀, 라우팅 규칙 및 HTTP 설정을 구성해야 합니다.
appgw.bicep 및 dns.bicep 파일을 검토하여 이러한 구성에서 여러 사이트를 허용하는 방법을 알아봅니다.
testapp이라는 웹앱은 이 구성을 보여주기 위해 만든 빈 앱입니다.
commands_std.azcli 배포 스크립트는 JSON 파일에 액세스합니다.
또한 commands_ha.azcli 스크립트는 고가용성 다중 사이트 App Service Environment 배포에 동일한 파일을 사용합니다.
시나리오 세부 정보
App Service 는 웹앱, API 앱, 함수 및 모바일 앱을 포함하여 Azure에서 다양한 앱을 호스트하는 PaaS(Platform as a Service) 솔루션입니다. App Service Environment를 사용하여 자체 Azure 가상 네트워크의 서브넷에 App Service 앱을 배포할 수 있습니다. 이 방법은 클라우드 워크로드에 대해 격리되고 확장성이 뛰어나며 전용 환경을 제공합니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.
Security
보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.
App Service 환경
내부 App Service Environment는 엔터프라이즈 가상 네트워크에 있으며 공용 인터넷에서 숨겨집니다. 이를 통해 네트워크 수준에서 웹 API 및 함수와 같은 백 엔드 서비스를 보호할 수 있습니다. HTTP 엔드포인트가 있는 모든 App Service Environment 앱은 가상 네트워크 내에서 ILB를 통해 액세스할 수 있습니다. Application Gateway는 ILB를 통해 웹앱에 요청을 전달합니다. 웹앱 자체는 ILB를 통해 API에 액세스합니다. API 및 함수와 같은 중요한 백 엔드 구성 요소는 공용 인터넷에서 액세스할 수 없습니다.
App Service Environment는 각 앱 서비스에 기본 도메인 이름을 할당하고 각 도메인 이름에 대한 기본 인증서를 자동으로 만듭니다. 이 인증서는 게이트웨이와 앱 간의 트래픽을 보호하는 데 도움이 되며 일부 시나리오에서 필요할 수 있습니다. 기본 인증서는 클라이언트 브라우저에 표시되지 않으며 Application Gateway에 구성된 인증서에만 응답합니다.
Application Gateway
Application Gateway는 TLS 또는 SSL을 사용하여 웹 브라우저에서 모든 트래픽을 암호화하고 보호할 수 있습니다. 다음 두 가지 방법으로 암호화를 구성할 수 있습니다.
게이트웨이에서 암호화가 종료됨: 이 메서드의 경우 백 엔드 풀은 HTTP용으로 구성됩니다. 암호화는 게이트웨이에서 중지되고 게이트웨이와 App Service 간의 트래픽은 암호화되지 않습니다. 암호화는 CPU를 많이 사용하므로 백 엔드의 암호화되지 않은 트래픽은 성능을 향상시키고 더 간단한 인증서 관리를 허용합니다. 이 방법은 네트워크 구성이 백 엔드를 보호하므로 보통 보안을 제공합니다.
엔드 투 엔드 암호화: 특정 보안 또는 규정 준수 요구 사항이 있는 일부 시나리오에서는 트래픽을 게이트웨이와 앱 간에 암호화해야 할 수 있습니다. 이 구성은 HTTPS 연결을 사용하며 백 엔드 풀에서 인증서가 필요합니다.
이 참조 구현은 Application Gateway에 자체 서명된 인증서를 사용합니다. 프로덕션 코드의 경우 CA(인증 기관)에서 발급한 인증서를 사용합니다.
- 지원되는 인증서 유형 목록은 TLS 종료에 지원되는 인증서를 참조 하세요.
- 게이트웨이 종료 암호화를 만드는 방법에 대한 자세한 내용은 Azure Portal을 사용하여 TLS 종료를 사용하여 애플리케이션 게이트웨이 구성을 참조하세요.
다음 예제에서는 appgw.bicep 프로그래밍 방식으로 HTTP 수신기를 구성합니다.
httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
frontendIPConfiguration: {
id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
}
frontendPort: {
id: '${appgwId}/frontendPorts/port_443'
}
protocol: 'Https'
sslCertificate: {
id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
}
hostName: item.hostName
requireServerNameIndication: true
}
}]
참조 구현은 App Service Environment의 Application Gateway와 웹앱 간의 트래픽에 대한 엔드 투 엔드 암호화를 보여 줍니다. 기본 SSL 인증서를 사용합니다. 이 구현의 백 엔드 풀은 HTTPS 트래픽을 리디렉션하도록 구성됩니다. 또한 웹앱과 연결된 기본 도메인 이름으로 호스트 이름을 재정의합니다. Application Gateway는 Microsoft에서 발급하기 때문에 기본 SSL 인증서를 신뢰합니다. 자세한 내용은 Application Gateway를 사용하여 App Service 구성을 참조하세요. 다음 예제에서는 appgw.bicep 참조 구현에서 이 방법을 구성하는 방법을 보여 줍니다.
backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
port: 443
protocol: 'Https'
cookieBasedAffinity: 'Disabled'
pickHostNameFromBackendAddress: true
requestTimeout: 20
probe: {
id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
}
}
}]
웹 애플리케이션 방화벽
Application Gateway의 웹 애플리케이션 방화벽 은 SQL 삽입과 같은 악의적인 공격으로부터 웹앱을 보호합니다. 또한 Azure Monitor와 통합되어 실시간 로그를 사용하여 공격을 모니터링합니다. 웹 애플리케이션 방화벽을 사용하도록 설정하려면 해당 요구 사항을 충족하도록 게이트웨이를 구성해야 합니다. 참조 구현을 사용하면 다음 코드를 사용하여 파일에서 WAF를 appgw.bicep 프로그래밍 방식으로 사용할 수 있습니다.
webApplicationFirewallConfiguration: {
enabled: true
firewallMode: 'Detection'
ruleSetType: 'OWASP'
ruleSetVersion: '3.2'
}
Virtual Network
가상 네트워크의 하나 이상의 서브넷과 NSG 를 연결할 수 있습니다. 이러한 그룹은 다양한 Azure 리소스 간에 트래픽이 흐르도록 허용하거나 거부하는 보안 규칙을 정의합니다. 이 아키텍처는 각 서브넷에 대해 별도의 NSG를 연결하여 해당 서브넷의 서비스에 따라 미세 조정된 규칙을 사용하도록 설정합니다.
App Service Environment 서브넷의 NSG에 대한 구성은 ase.bicep 파일에 있습니다.
Application Gateway 서브넷에 대한 NSG 구성은 appgw.bicep 파일에 있습니다.
두 구성 모두 리소스 "type": "Microsoft.Network/networkSecurityGroups"를 사용합니다.
프라이빗 엔드포인트를 사용하면 프라이빗 네트워크를 통해 클라이언트와 Azure 서비스 간에 보안이 강화된 프라이빗 연결을 사용할 수 있습니다. Azure 서비스에 대한 개인 액세스 IP 주소를 제공하므로 Azure Private Link 리소스에 대한 보안 트래픽이 향상됩니다. 플랫폼은 네트워크 연결의 유효성을 검사하고 지정된 Private Link 리소스를 대상으로 하는 연결만 허용합니다.
프라이빗 엔드포인트는 NSG, 사용자 정의 경로 및 애플리케이션 보안 그룹과 같은 네트워크 정책을 지원합니다. 보안을 향상하려면 해당 엔드포인트를 지원하는 모든 Azure 서비스에 대해 프라이빗 엔드포인트를 사용하도록 설정합니다. 가상 네트워크에서 서비스를 보호하려면 공용 인터넷의 액세스를 차단하기 위해 공용 액세스를 사용하지 않도록 설정합니다. 이 아키텍처는 Azure Service Bus, SQL Database, Key Vault 및 Azure Cosmos DB를 포함하여 이를 지원하는 서비스에 대한 프라이빗 엔드포인트를 구성합니다. privatendpoints.bicep에서 구성을 볼 수 있습니다.
프라이빗 엔드포인트를 사용하도록 설정하려면 프라이빗 DNS 영역도 구성해야 합니다. 자세한 내용은 Azure 프라이빗 엔드포인트 DNS 구성을 참조하세요.
Azure Firewall
Azure Firewall 및 프라이빗 엔드포인트는 서로를 보완합니다. 프라이빗 엔드포인트는 가상 네트워크에서 발생하는 트래픽만 허용하여 리소스를 보호하는 데 도움이 됩니다. Azure Firewall을 사용하면 애플리케이션에서 아웃바운드 트래픽을 제한할 수 있습니다. 프라이빗 엔드포인트 트래픽을 포함하여 모든 아웃바운드 트래픽이 방화벽 서브넷을 통과하도록 허용하는 것이 좋습니다. 이 방법을 사용하면 아웃바운드 트래픽을 더 잘 모니터링할 수 있습니다. 간단히 하기 위해 이 참조 아키텍처는 방화벽 서브넷 대신 서비스 서브넷의 모든 프라이빗 엔드포인트를 구성합니다.
자세한 내용은 App Service Environment를 사용하여 Azure Firewall 구성을 참조하세요. 방화벽은 프라이빗 엔드포인트 및 가상 네트워크 경로 테이블을 트래버스하지 않는 트래픽을 모니터링하고 제어합니다.
Microsoft Entra ID (마이크로소프트 엔트라 ID)
Microsoft Entra ID는 애플리케이션을 인증하고 리소스에 대한 액세스 권한을 부여하는 보안 기능을 제공합니다. 이 참조 아키텍처는 Microsoft Entra ID, 관리 ID 및 Azure RBAC(역할 기반 액세스 제어)의 두 가지 주요 기능을 사용합니다.
클라우드 애플리케이션에서는 클라우드 서비스에 인증하는 데 필요한 자격 증명을 보호해야 합니다. 이상적으로 자격 증명은 개발자 워크스테이션 또는 소스 제어에 표시되지 않아야 합니다. Key Vault는 자격 증명 및 비밀을 안전하게 저장하지만 앱은 여전히 Key Vault에 인증하여 검색해야 합니다. Azure 리소스에 대한 관리 ID는 Microsoft Entra ID에서 자동으로 관리되는 ID를 Azure 서비스에 제공합니다. 이 ID를 사용하여 애플리케이션의 자격 증명 없이 Key Vault를 포함하여 Microsoft Entra 인증을 지원하는 모든 서비스에 인증할 수 있습니다.
Azure RBAC 는 다음 조건을 정의하여 Azure 리소스에 대한 액세스를 관리합니다.
사용자, 관리 ID 또는 보안 주체와 같은 액세스 권한이 있는 엔터티
소유자, 기여자, 읽기 권한자 또는 관리자와 같은 액세스 유형
리소스, 리소스 그룹, 구독 또는 관리 그룹과 같은 액세스 범위
필요한 역할과 각 앱에 대한 액세스 유형을 엄격하게 제어하여 App Service Environment 애플리케이션에 대한 액세스를 보호할 수 있습니다. 이 방법을 사용하면 여러 앱이 다른 개발 팀의 동일한 App Service Environment에 배포할 수 있습니다. 예를 들어 한 팀이 프런트 엔드를 처리하고 한 팀이 백 엔드를 처리할 수 있습니다. Azure RBAC는 각 팀이 작업 중인 앱에 대한 액세스를 제한할 수 있습니다. 조직에 적합한 역할을 만들려면 Azure 사용자 지정 역할을 참조하세요.
키 보관소 (Key Vault)
일부 서비스는 관리 ID를 지원하고 Azure RBAC를 사용하여 앱에 대한 권한을 설정합니다. 예를 들어 Azure Cosmos DB의 기본 제공 Service Bus 역할 및 Azure RBAC를 참조하세요. 이러한 권한을 부여하려면 구독에 대한 사용자 액세스 관리자 액세스 권한이 있어야 합니다. 기여자 역할은 이러한 서비스를 배포할 수 있습니다. 더 광범위한 개발자 팀이 배포 스크립트를 실행할 수 있도록 각 서비스에서 제공하는 네이티브 액세스 제어를 사용할 수 있습니다.
Service Bus의 경우 공유 액세스 서명을 사용합니다.
Azure Cosmos DB의 경우 키를 사용합니다.
워크로드에 서비스 기반 액세스가 필요한 경우 이러한 미리 공유된 비밀을 Key Vault에 저장해야 합니다. 웹 애플리케이션의 관리 ID를 통해 자격 증명 모음에 액세스합니다.
앱은 Key Vault에 저장된 비밀에 액세스합니다. Key Vault 키 및 값 쌍을 참조합니다. 이 구성은 sites.bicep 파일에 정의되어 있습니다. Voting 앱은 다음 코드를 사용합니다.
properties: {
enabled: true
hostingEnvironmentProfile: {
id: aseId
}
serverFarmId: votingWebPlanName.id
siteConfig: {
appSettings: [
{
name: 'ASecret'
value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
}
]
}
}
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화를 위한 디자인 검토 검사 목록을 참조하세요.
Azure 가격 계산기를 사용하여 비용을 예측합니다. 자세한 내용은 Well-Architected Framework의 비용 최적화 핵심 요소를 참조하세요. 비용을 절약하기 위해 Azure 예약은 많은 Azure 리소스에 대해 1년 또는 3년 계획을 제공합니다.
이 아키텍처의 일부 주요 서비스에 대해 다음 비용 요소를 고려합니다.
App Service Environment v3
App Service에는 다양한 가격 책정 옵션이 있습니다. App Service Environment는 격리된 v2 서비스 계획을 통해 배포됩니다. 이 계획에는 I1v2에서 I6v2까지 CPU 크기에 대한 여러 옵션이 포함됩니다. 이 참조 구현에서는 세 개의 I1v2 인스턴스를 사용합니다.
Application Gateway
Application Gateway에는 다양한 가격 책정 옵션이 있습니다. 이 구현에서는 자동 크기 조정 및 영역 중복을 지원하는 Application Gateway Standard v2 및 Web Application Firewall v2 SKU를 사용합니다. 자세한 내용은 Application Gateway v2 및 웹 애플리케이션 방화벽 v2 크기 조정을 참조하세요.
Azure Cache for Redis (아주어 캐시 포 레디스)
Azure Cache for Redis에는 다양한 가격 책정 옵션이 있습니다. 이 아키텍처는 가상 네트워크 지원을 위해 프리미엄 SKU를 사용합니다.
기타 종속성
App Service Environment를 보호하는 데 도움이 되는 다른 서비스에는 다음과 같은 몇 가지 가격 책정 옵션도 있습니다.
운영 효율성
운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.
이 참조 아키텍처의 배포 스크립트는 App Service Environment, 기타 서비스 및 App Service Environment 내의 애플리케이션을 배포합니다. 이러한 애플리케이션을 배포한 후에는 엔터프라이즈에서 앱 유지 관리 및 업그레이드를 위해 CI/CD를 계획할 수 있습니다. 이 섹션에서는 개발자가 App Service Environment 애플리케이션의 CI/CD에 사용하는 일반적인 방법을 설명합니다.
가상 네트워크 내에서만 내부 App Service Environment에 앱을 배포할 수 있습니다. 다음 방법 중 하나를 사용하여 App Service Environment 앱을 배포합니다.
가상 네트워크 내에서 VM을 사용합니다. 배포에 필요한 도구를 사용하여 App Service Environment 가상 네트워크 내에 VM을 만듭니다. VM에 대한 RDP 연결을 열려면 NSG 구성을 사용합니다. 코드 아티팩트 복사를 VM에 복사하고, App Service Environment 서브넷에 빌드하고 배포합니다. 이 방법은 초기 빌드 및 테스트 개발 환경을 설정하는 데 적합합니다. 필요한 배포 처리량에 맞게 크기를 조정할 수 없으므로 프로덕션 환경에 이 메서드를 사용하지 마세요.
로컬 워크스테이션에서 지점 및 사이트 간의 VPN 연결을 사용합니다. App Service Environment 가상 네트워크를 개발 머신으로 확장합니다. 로컬 워크스테이션에서 배포합니다. 이 메서드는 초기 개발 환경에서도 잘 작동하지만 프로덕션 환경에는 적합하지 않습니다.
Azure Pipelines를 사용합니다. 가상 네트워크 내에 있는 에이전트에서 끝나는 전체 CI/CD 파이프라인을 구현합니다. 이 방법은 높은 배포 처리량이 필요한 프로덕션 환경에 적합합니다. 빌드 파이프라인은 가상 네트워크 외부에 완전히 유지됩니다. 배포 파이프라인은 빌드된 개체를 가상 네트워크 내의 빌드 에이전트에 복사한 다음 App Service Environment 서브넷에 배포합니다. 자세한 내용은 Azure Pipelines와 App Service Environment 가상 네트워크 간의 자체 호스팅 빌드 에이전트를 참조하세요.
프로덕션 환경에 Azure Pipelines 또는 다른 CI/CD 도구를 사용하는 것이 좋습니다. 빌드 및 배포 프로세스를 자동화하려면 Azure Pipelines YAML 스키마를 사용하여 CI/CD를 스크립트합니다. azure-pipelines.yml 파일은 이 참조 구현에서 웹앱에 대한 이러한 CI/CD 파이프라인을 구현합니다. 유사한 CI/CD 스크립트는 웹 API 및 함수를 지원합니다. 이러한 도구가 각 애플리케이션에 대한 CI/CD를 자동화하는 방법에 대한 자세한 내용은 Azure Pipelines 사용을 참조하세요.
일부 기업은 가상 네트워크 내에서 영구 빌드 에이전트를 유지 관리하지 않을 수 있습니다. 이 경우 다음 옵션 중 하나를 고려합니다.
빌드 에이전트를 동적으로 만듭니 다. DevOps 파이프라인 내에서 빌드 에이전트를 만들고 배포가 완료된 후 중단합니다. 이 방법은 DevOps에 대한 또 다른 단계를 추가하지만 VM 유지 관리를 간소화합니다.
컨테이너: 컨테이너를 VM 대신 빌드 에이전트로 사용합니다.
에이전트 없이 배포: 일반적으로 스토리지 계정에서 가상 네트워크 외부에 배치된 압축된 파일에서 배포하여 빌드 에이전트를 완전히 방지합니다. App Service Environment 및 파이프라인은 스토리지 계정에 대한 액세스 권한이 있어야 합니다. 릴리스 파이프라인의 끝부분에는 압축된 파일을 Blob Storage에 삭제할 수 있습니다. 그러면 App Service Environment에서 이를 선택하고 배포할 수 있습니다.
이 방법은 다음과 같은 제한 사항을 포함합니다.
- 이 메서드는 실제 배포 프로세스에서 DevOps의 연결을 끊기 때문에 배포 문제를 모니터링하고 추적하기가 어렵습니다.
- 보안 트래픽이 있는 잠긴 환경에서 스토리지의 압축된 파일에 대한 액세스 규칙을 업데이트해야 할 수 있습니다.
- ZIP 파일에서 배포하려면 App Service Environment에 특정 확장 및 도구를 설치해야 합니다.
앱 배포 방법에 대한 자세한 내용은 App Service에서 앱 실행을 참조하세요.
성능 효율성
성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성에 대한 디자인 검토 검사 목록을 참조하세요.
확장 가능한 앱 디자인
이 참조 아키텍처는 사용량에 따라 개별 구성 요소의 크기를 조정할 수 있도록 애플리케이션을 구성합니다. 각 웹앱, API 및 함수는 자체 App Service 계획에 배포됩니다. 각 앱에서 성능 병목 상태를 모니터링한 다음 필요할 때 확장할 수 있습니다.
Application Gateway 자동 크기 조정
Application Gateway는 자동 크기 조정을 지원합니다. 이 기능을 사용하면 Application Gateway가 트래픽 부하 패턴에 따라 확장 또는 축소할 수 있습니다. 이 참조 아키텍처는 autoscaleConfigurationappgw.bicep 파일에서 0~10개의 추가 인스턴스 간에 크기를 조정하도록 구성합니다. 자세한 내용은 Application Gateway 및 웹 애플리케이션 방화벽 크기 조정을 참조하세요.
이 시나리오를 배포하십시오
이 아키텍처의 참조 구현을 배포하려면 GitHub 추가 정보을 확인하고, 표준 배포에 대한 스크립트를 따르세요.
기여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
대표 저자:
- Dhanashri Kshirsagar | 시니어 콘텐츠 PM
기타 기여자:
- Deep Bhattacharya | 클라우드 솔루션 설계자
- Suhas Rao | 클라우드 솔루션 설계자
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.