Azure App Service 환경을 사용하는 엔터프라이즈 배포

이 참조 아키텍처는 App Service Environment 버전 3을 사용하는 일반적인 엔터프라이즈 워크로드를 보여 줍니다. 또한 워크로드의 보안을 강화하기 위한 모범 사례도 설명합니다.

이 아키텍처에 대한 참조 구현은 GitHub에서 사용할 수 있습니다.

아키텍처

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

워크플로

App Service Environment 버전 3은 이전 버전과는 다른 기능을 제공하며 해당 버전에 비해 장점이 있습니다. 자세한 내용은 기능 차이점을 참조 하세요. 다음 두 가지 방법으로 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는 항상 엔터프라이즈 가상 네트워크의 자체 서브넷에 배포되어야 합니다. 이 서브넷 내에서 App Service 애플리케이션은 앱을 실행하는 데 필요한 물리적 리소스 컬렉션인 하나 이상의 App Service 요금제에 배포됩니다. 복잡성 및 리소스 요구 사항에 따라 여러 앱 간에 App Service 요금제를 공유할 수 있습니다. 이 참조 구현은 프라이빗 웹 API 및 함수와 상호 작용하는 Voting App이라는 웹앱을 배포합니다. 또한 다중 앱 배포를 보여주는 Test App이라는 더미 웹앱을 배포합니다. 각 App Service 앱은 자체 App Service 요금제에 호스트되므로 필요한 경우 개별적으로 스케일링할 수 있습니다. 스토리지 및 컴퓨팅처럼 이러한 호스트된 앱에 필요한 모든 리소스와 크기 조정 요구 사항은 App Service Environment 인프라에서 완전히 관리됩니다.

이 구현의 간단한 투표 앱을 사용하면 사용자가 기존 항목을 보고, 새 항목을 만들고, 기존 항목에 투표할 수 있습니다. 웹 API는 항목 및 투표를 만들고 검색하는 데 사용됩니다. 데이터 자체는 SQL Server 데이터베이스에 저장됩니다. 비동기 데이터 업데이트를 보여주기 위해 웹앱은 Service Bus 인스턴스에서 새로 추가된 투표를 큐에 추가합니다. 이 함수는 큐에 추가된 투표를 선택하고 SQL 데이터베이스를 업데이트합니다. Azure Cosmos DB는 웹앱이 브라우저에 표시하기 위해 검색하는 모의 광고 저장에 사용됩니다. 애플리케이션은 캐시 관리에 Azure Cache for Redis를 사용합니다. 프리미엄 계층 Azure Cache for Redis가 사용되어 자체 서브넷에서 App Service Environment와 동일한 가상 네트워크에 대한 구성을 허용합니다. 이렇게 하면 캐시의 보안과 격리가 향상됩니다.

웹앱은 Application Gateway를 통해 인터넷에 액세스할 수 있는 유일한 구성 요소입니다. API 및 함수는 인터넷 클라이언트에서 액세스할 수 없습니다. 인바운드 트래픽은 Application Gateway에 구성된 WAF에 의해 보호됩니다.

구성 요소

다음 서비스는 이 아키텍처에서 App Service Environment를 잠그는 데 핵심입니다.

• Azure Virtual Network 는 엔터프라이즈가 소유한 프라이빗 Azure 클라우드 네트워크입니다. 향상된 네트워크 기반 보안 및 격리를 제공합니다. App Service Environment는 엔터프라이즈 소유 가상 네트워크의 서브넷에 대한 App Service 배포입니다. 이를 통해 엔터프라이즈는 네트워크 보안 그룹 및 프라이빗 엔드포인트를 사용하여 액세스하는 네트워크 공간과 리소스를 엄격하게 제어할 수 있습니다.

• Application Gateway 는 TLS/SSL 오프로드 및 WAF를 사용하는 애플리케이션 수준 웹 트래픽 부하 분산 장치입니다. 공용 IP 주소에서 수신 대기하고 ILB App Service Environment의 애플리케이션 엔드포인트로 트래픽을 라우팅합니다. 애플리케이션 수준 라우팅이므로 동일한 ILB App Service Environment 내의 여러 앱으로 트래픽을 라우팅할 수 있습니다. 자세한 내용은 Application Gateway 여러 사이트 호스팅을 참조하세요.

• Azure Firewall은 웹 애플리케이션의 아웃바운드 트래픽을 제한하는 데 사용됩니다. 프라이빗 엔드포인트 채널을 통과하지 않는 나가는 트래픽과 App Service Environment에 필요한 경로 테이블은 방화벽 서브넷으로 전달됩니다. 편의상 이 아키텍처는 서비스 서브넷의 모든 프라이빗 엔드포인트를 구성합니다.

• Microsoft Entra ID 또는 Microsoft Entra ID는 Azure 리소스 및 서비스에 대한 액세스 권한 및 권한 관리를 제공합니다. 관리 ID 는 Microsoft Entra ID로 자동으로 관리되는 서비스 및 앱에 ID를 할당합니다. 이러한 ID는 Microsoft Entra 인증을 지원하는 모든 서비스에 인증하는 데 사용할 수 있습니다. 이렇게 하면 이러한 앱에 대한 자격 증명을 명시적으로 구성할 필요가 없습니다. 이 아키텍처는 웹앱에 관리 ID를 할당합니다.

• Azure Key Vault 는 앱에 필요한 비밀 및 자격 증명을 저장합니다. 애플리케이션에 직접 비밀을 저장하지 말고 이 옵션을 사용하세요.

• GitHub Actions 는 이 아키텍처에서 지속적인 통합 및 지속적인 배포 기능을 제공합니다. App Service Environment는 가상 네트워크에 있으므로 가상 머신은 App Service 계획에 앱을 배포하기 위해 가상 네트워크 내의 점프박스로 사용됩니다. 이 작업은 가상 네트워크 외부에서 앱을 빌드합니다. 향상된 보안 및 원활한 RDP/SSH 연결을 위해 Jumpbox에 Azure Bastion을 사용하는 것이 좋습니다.

다중 사이트 파일 서버 확장 구성에서 Tiger Bridge의 참조 아키텍처를 보여 주는 다중 사이트 하이브리드

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

내부 App Service Environment는 HTTP 엔드포인트를 사용하여 여러 웹앱 및 API를 호스트할 수 있습니다. ILB IP는 Virtual Network 내에서만 액세스할 수 있으므로 이러한 애플리케이션은 공용 인터넷에서 잠깁니다. Application Gateway 는 이러한 애플리케이션을 인터넷에 선택적으로 노출하는 데 사용됩니다. App Service Environment는 각 App Service 애플리케이션에 기본 URL을 로 <default-appName>.<app-service-environment-domain>.appserviceenvironment.net할당합니다. App Service Environment do기본 이름을 App Service Environment ILB IP 주소에 매핑하는 프라이빗 DNS 영역이 만들어집니다. 이렇게 하면 사용자 지정 DNS를 사용하여 가상 네트워크 내의 앱에 액세스할 수 없습니다.

Application Gateway는 수신기가 게이트웨이의 IP 주소에 대한 요청을 위해 HTTPS 포트에서 수신 대기하도록 구성됩니다. 간단히 하기 위해 이 구현에서는 공용 DNS 이름 등록을 사용하지 않습니다. 임의로 선택한 URL을 Application Gateway IP로 가리키도록 컴퓨터의 localhost 파일을 수정해야 합니다. 간단한 설명을 위해 수신기는 자체 서명된 인증서를 사용하여 이러한 요청을 처리합니다. Application Gateway에는 각 App Service 애플리케이션의 기본 URL에 대한 백 엔드 풀 이 있습니다. 회람 규칙은 수신기를 백 엔드 풀에 연결하도록 구성됩니다. 게이트웨이와 App Service Environment 간의 연결을 암호화할지 여부를 결정하는 HTTP 설정 이 만들어집니다. 이러한 설정은 백 엔드 풀에서 선택한 호스트 이름으로 들어오는 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이라는 웹앱은 이 구성을 보여주기 위해 만든 빈 앱입니다. 이러한 JSON 파일은 배포 스크립트 commands_std.azcli에서 액세스합니다. 또한 고가용성 다중 사이트 App Service Environment 배포에 사용되는 commands_ha.azcli에서 액세스합니다.

시나리오 정보

Azure App Service는 웹앱, API 앱, 함수, 모바일 앱 등의 다양한 앱을 Azure에 호스트하는 데 사용되는 PaaS 서비스입니다. App Service Environment 를 사용하면 엔터프라이즈가 자체 Azure Virtual Network의 서브넷에 App Service 앱을 배포하여 클라우드 워크로드에 대해 격리되고 확장성이 뛰어난 전용 환경을 제공할 수 있습니다.

고려 사항

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

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

App Service 환경

내부 App Service Environment는 공용 인터넷에서 숨겨진 엔터프라이즈 가상 네트워크에 배포됩니다. 따라서 기업은 네트워크 수준에서 웹 API 및 함수와 같은 백 엔드 서비스를 잠글 수 있습니다. HTTP 엔드포인트가 있는 모든 App Service Environment 앱은 가상 네트워크 내에서 ILB를 통해 액세스할 수 있습니다. Application Gateway는 ILB를 통해 웹앱에 요청을 전달하도록 구성됩니다. 웹앱 자체는 ILB를 통해 API에 액세스합니다. 중요한 백 엔드 구성 요소, 즉 API 및 함수는 공용 인터넷에서 효과적으로 액세스할 수 없습니다.

App Service Environment에서 할당한 기본 do기본 이름에 대해 각 앱 서비스에 대해 기본 인증서가 만들어집니다. 이 인증서는 게이트웨이와 앱 간의 트래픽 보안을 강화할 수 있으며 특정 시나리오에서 필요할 수 있습니다. 이러한 인증서는 클라이언트 브라우저를 통해 표시되지 않습니다. Application Gateway에 구성된 인증서에만 응답할 수 있습니다.

Application Gateway

참조 구현은 appgw.bicep에서 프로그래밍 방식으로 Application Gateway를 구성합니다. commands_std.azcli 파일은 게이트웨이를 배포할 때 다음 구성을 사용합니다.

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

암호화

Application Gateway를 사용한 TLS 종료 및 종단 간 TLS 개요에 설명된 대로 Application Gateway는 TLS(전송 계층 보안)/SSL(Secure Sockets Layer)을 사용하여 웹 브라우저에서 모든 트래픽을 암호화하고 보호할 수 있습니다. 암호화는 다음과 같은 방식으로 구성할 수 있습니다.

• 게이트웨이에서 암호화 종료. 이 경우 백 엔드 풀은 HTTP용으로 구성됩니다. 게이트웨이에서 암호화가 중지되고, 게이트웨이와 앱 서비스 간의 트래픽이 암호화되지 않습니다. 암호화는 CPU를 많이 사용하므로, 백 엔드에서 암호화하지 않으면 트래픽 성능이 향상되고 인증서 관리가 더 간단해집니다. 이렇게 하면 네트워크 구성을 통해 백 엔드가 보호되므로 적절한 수준의 보안이 제공됩니다.

• 엔드 투 엔드 암호화. 특정 보안 또는 규정 준수 요구 사항이 있는 일부 시나리오에서는 게이트웨이와 앱 간에 트래픽을 암호화해야 합니다. 이러한 암호화는 HTTPS 연결을 사용하고 백 엔드 풀에서 인증서를 구성하여 수행됩니다.

이 참조 구현은 Application Gateway에 자체 서명된 인증서를 사용합니다. 프로덕션 코드의 경우 인증 기관에서 발급한 인증서를 사용해야 합니다. 지원되는 인증서 유형 목록은 TLS 종료에 지원되는 인증서를 참조 하세요. 게이트웨이 종료 암호화를 만드는 방법을 알아보려면 Azure Portal을 사용하여 TLS 종료로 애플리케이션 게이트웨이 구성을 읽어보세요. appgw.bicep의 다음 코드 줄은 이를 프로그래밍 방식으로 구성합니다.

          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
          }
        }]

참조 구현은 Application Gateway와 App Service Environment의 웹앱 간의 트래픽에 대한 엔드 투 엔드 암호화를 보여 줍니다. 기본 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}'
          }
        }
      }]

Web Application Firewall

Application Gateway 의 WAF(웹 애플리케이션 방화벽)는 SQL 삽입과 같은 악의적인 공격으로부터 웹앱을 보호합니다. 또한 실시간 로그를 사용하여 공격을 모니터링할 수 있도록 Azure Monitor와 통합됩니다. Azure Portal을 사용하여 Web Application Firewall이 있는 애플리케이션 게이트웨이 만들기에 설명된 대로 게이트웨이에서 WAF를 사용하도록 설정해야 합니다. 참조 구현을 사용하면 다음 코드 조각을 사용하여 appgw.bicep 파일에서 WAF를 프로그래밍 방식으로 사용할 수 있습니다.

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

Virtual Network

네트워크 보안 그룹은 가상 네트워크의 하나 이상의 서브넷과 연결할 수 있습니다. 네트워크 보안 그룹은 다양한 Azure 리소스 간에 트래픽이 흐르도록 허용하거나 거부하는 보안 규칙입니다. 이 아키텍처는 각 서브넷에 대해 별도의 네트워크 보안 그룹을 연결합니다. 이렇게 하면 해당 서브넷에 포함된 서비스에 따라 서브넷당 이러한 규칙을 미세 조정할 수 있습니다. 예를 들어 App Service Environment 서브넷의 네트워크 보안 그룹에 대한 ase.bicep 파일 및 Application Gateway 서브넷에 대한 네트워크 보안 그룹의 appgw.bicep 파일에 대한 구성 "type": "Microsoft.Network/networkSecurityGroups" 을 참조하세요.

프라이빗 엔드포인트를 사용하면 프라이빗 네트워크를 통해 클라이언트와 Azure 서비스 간에 보안이 강화된 프라이빗 연결을 사용할 수 있습니다. Azure 서비스에 대해 개인적으로 액세스할 수 있는 IP 주소를 제공하여 Azure Private Link 리소스에 대한 향상된 보안 트래픽을 지원합니다. 플랫폼은 네트워크 연결의 유효성을 검사하여 지정된 Private Link 리소스에 연결하는 연결만 허용합니다. 프라이빗 엔드포인트는 네트워크 보안 그룹, 사용자 정의 경로 및 애플리케이션 보안 그룹과 같은 네트워크 정책을 지원합니다. 보안을 향상하려면 프라이빗 엔드포인트를 지원하는 모든 Azure 서비스에 대해 프라이빗 엔드포인트를 사용하도록 설정해야 합니다. 그런 다음 공용 액세스를 사용하지 않도록 설정하여 가상 네트워크의 서비스에 대한 보안을 개선하고 공용 인터넷의 액세스를 효과적으로 차단할 수 있습니다. 이 아키텍처는 Azure Service Bus, SQL Server, Key Vault 및 Azure Cosmos DB를 지원하는 서비스에 대한 프라이빗 엔드포인트를 구성합니다. privatendpoints.bicep에서 구성을 볼 수 있습니다.

프라이빗 엔드포인트를 사용하도록 설정하려면 프라이빗 DNS 영역도 구성해야 합니다. 자세한 내용은 Azure 프라이빗 엔드포인트 DNS 구성을 참조하세요.

방화벽

Azure Firewall 및 프라이빗 엔드포인트는 서로를 보완합니다. 프라이빗 엔드포인트는 가상 네트워크에서 발생하는 트래픽만 허용하여 리소스를 보호하는 데 도움이 됩니다. Azure Firewall을 사용하면 애플리케이션에서 아웃바운드 트래픽을 제한할 수 있습니다. 프라이빗 엔드포인트 트래픽을 포함하여 모든 아웃바운드 트래픽이 방화벽 서브넷을 통과하도록 허용하는 것이 좋습니다. 이렇게 하면 아웃바운드 트래픽을 더 잘 모니터링할 수 있습니다. 간단히 하기 위해 이 참조 아키텍처는 방화벽 서브넷 대신 서비스 서브넷의 모든 프라이빗 엔드포인트를 구성합니다.

Azure Firewall이 App Service Environment와 통합되는 방법을 알아보려면 App Service Environment를 사용하여 Azure Firewall 구성을 참조하세요. 프라이빗 엔드포인트 및 가상 네트워크 경로 테이블을 트래버스하지 않는 모든 트래픽은 방화벽에 의해 모니터링 및 제어됩니다.

Microsoft Entra ID

Microsoft Entra ID는 애플리케이션을 인증하고 리소스에 대한 액세스 권한을 부여하는 보안 기능을 제공합니다. 이 참조 아키텍처는 Microsoft Entra ID의 두 가지 주요 기능인 관리 ID와 Azure 역할 기반 액세스 제어를 사용합니다.

클라우드 애플리케이션에서는 클라우드 서비스에 인증하는 데 필요한 자격 증명을 보호해야 합니다. 자격 증명이 개발자 워크스테이션에 표시되거나 소스 제어에 체크 인되지 않는 것이 이상적입니다. Azure Key Vault는 자격 증명과 비밀을 안전하게 저장하는 방법을 제공하지만, 자격 증명과 비밀을 검색하려면 앱이 Key Vault에 인증해야 합니다. Azure 리소스에 대한 관리 ID는 Microsoft Entra ID에서 자동으로 관리되는 ID를 Azure 서비스에 제공합니다. 이 ID는 애플리케이션의 자격 증명 없이 Key Vault를 포함하여 Microsoft Entra 인증을 지원하는 모든 서비스에 인증하는 데 사용할 수 있습니다.

Azure RBAC(Azure 역할 기반 액세스 제어)는 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에 저장됩니다. 자격 증명 모음 자체는 Azure RBAC가 필요한 관리 ID를 통해 액세스됩니다. 이러한 연결 문자열에 대한 액세스 정책을 적절하게 설정하세요. 예를 들어 기본 루트 액세스 정책을 사용하는 대신 백 엔드에는 읽기 전용, 프런트 엔드에는 쓰기 전용 액세스 정책을 사용하는 식입니다.

services.bicep의 다음 코드는 이러한 서비스에 대한 Key Vault 구성을 보여 줍니다.

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

이러한 연결 문자열 값은 Key Vault 키/값 쌍을 참조하는 앱에서 액세스합니다. 이 작업은 Voting App에 대한 다음 코드와 같이 sites.bicep 파일에서 수행됩니다.

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

또한 이 함수는 비슷한 방식으로 Service Bus 수신기 연결 문자열에 액세스합니다.

확장성

확장 가능한 앱 디자인

이 참조 아키텍처의 애플리케이션은 사용량에 따라 개별 구성 요소를 스케일링할 수 있도록 구조화됩니다. 각 웹앱, API 및 함수는 자체 App Service 요금제에 배포됩니다. 각 앱의 성능 병목 상태를 모니터링하다가 필요한 경우 스케일 업할 수 있습니다.

Application Gateway 자동 크기 조정

Azure Application Gateway V2에서 자동 크기 조정을 사용하도록 설정할 수 있습니다. 이를 통해 Application Gateway는 트래픽 부하 패턴에 따라 확장 또는 축소할 수 있습니다. 이 참조 아키텍처는 autoscaleConfiguration appgw.bicep 파일에서 0~10개의 추가 인스턴스 간에 크기를 조정하도록 구성합니다. 자세한 내용은 Application Gateway 및 WAF v2 크기 조정을 참조하세요.

배포

이 참조 아키텍처의 배포 스크립트는 App Service Environment, 기타 서비스 및 App Service Environment 내에 애플리케이션을 배포하는 데 사용됩니다. 이러한 애플리케이션이 배포되면 기업에서는 앱 유지 관리 및 업그레이드를 위한 연속 통합 및 지속적인 배포 계획을 세우는 것이 좋습니다. 이 섹션에서는 개발자가 App Service Environment 애플리케이션의 CI/CD에 사용하는 몇 가지 일반적인 방법을 보여 줍니다.

앱은 가상 네트워크 내에서만 내부 App Service Environment에 배포할 수 있습니다. 다음 세 가지 방법은 App Service Environment 앱을 배포하는 데 널리 사용됩니다.

• Virtual Network 내에서 수동으로: 배포에 필요한 도구를 사용하여 App Service Environment 가상 네트워크 내에 가상 머신을 만듭니다. NSG 구성을 사용하여 VM에 대한 RDP 연결을 엽니다. 코드 아티팩트 복사를 VM에 복사하고, App Service Environment 서브넷에 빌드하고 배포합니다. 초기 빌드 및 테스트 개발 환경을 설정하는 간단한 방법입니다. 그러나 필요한 배포 처리량을 스케일링할 수 없는 프로덕션 환경에는 사용하지 않는 것이 좋습니다.

• 로컬 워크스테이션의 지점 및 사이트 연결: 이를 통해 App Service Environment 가상 네트워크를 개발 머신으로 확장하고 여기에서 배포할 수 있습니다. 초기 개발 환경을 설정하는 또 다른 방법이며, 프로덕션에는 사용하지 않는 것이 좋습니다.

• Azure Pipelines를 통해: 가상 네트워크 내에 있는 에이전트에서 끝나는 전체 CI/CD 파이프라인을 구현합니다. 이 방법은 높은 배포 처리량이 필요한 프로덕션 환경에 적합합니다. 빌드 파이프라인은 가상 네트워크 외부에 완전히 기본. 배포 파이프라인은 빌드된 개체를 가상 네트워크 내의 빌드 에이전트에 복사한 다음 App Service Environment 서브넷에 배포합니다. 자세한 내용은 Pipelines와 App Service Environment 가상 네트워크 간의 자체 호스팅 빌드 에이전트에 대한 이 토론을 참조하세요.

프로덕션 환경에는 Azure Pipelines를 사용하는 것이 좋습니다. Azure Pipelines YAML 스키마의 도움을 받아 CI/CD를 스크립팅하면 빌드 및 배포 프로세스를 자동화하는 데 도움이 됩니다. azure-pipelines.yml은 이 참조 구현의 웹앱에 대한 CI/CD 파이프라인을 구현합니다. 웹 API와 함수에 대한 유사한 CI/CD 스크립트가 있습니다. 각 애플리케이션에 대해 CI/CD를 자동화하는 방법을 알아보려면 Azure Pipelines 사용을 읽어보세요.

일부 기업은 가상 네트워크 내에서 영구 빌드 에이전트를 기본 싶지 않을 수 있습니다. 이 경우 DevOps 파이프라인 내에서 빌드 에이전트를 만들고, 배포가 완료되면 삭제하도록 선택할 수 있습니다. 이렇게 하면 DevOps에 또 다른 단계가 추가되지만 VM 유지 관리의 복잡성이 줄어듭니다. VM 대신 컨테이너를 빌드 에이전트로 사용하는 방법도 고려해 볼 수 있습니다. 빌드 에이전트는 일반적으로 스토리지 계정에서 가상 네트워크 외부에 배치된 압축된 파일에서 배포하여 완전히 방지할 수도 있습니다. 스토리지 계정은 App Service Environment에서 액세스할 수 있어야 합니다. 파이프라인에서 스토리지에 액세스할 수 있어야 합니다. 릴리스 파이프라인이 끝나면 압축된 파일을 Blob 스토리지에 드롭할 수 있습니다. 그러면 App Service Environment에서 이를 선택하고 배포할 수 있습니다. 이 방법은 다음과 같은 제한이 있습니다.

• DevOps와 실제 배포 프로세스 간에 연결이 끊어져 배포 문제를 모니터링하고 추적하는 데 어려움이 있습니다.
• 트래픽이 보호되는 잠긴 환경에서는 스토리지의 압축된 파일에 액세스하려면 규칙을 변경해야 할 수도 있습니다.
• Zip에서 배포할 수 있도록 App Service Environment에 특정 확장 및 도구를 설치해야 합니다.

앱을 App Service 요금제에 배포할 수 있는 몇 가지 방법을 더 알아보려면 배포 전략에 초점을 맞춘 App Service 문서를 참조하세요.

비용 최적화

Azure 가격 계산기를 사용하여 비용을 예측합니다. 기타 고려 사항은 Microsoft Azure Well-Architected Framework의 비용 섹션에 설명되어 있습니다. Azure Reservations는 여러 Azure 리소스의 1년 또는 3년 플랜에 따라 비용을 절감하는 데 도움이 됩니다. 예약 구입 문서에서 자세한 내용을 읽어보세요.

다음은 이 아키텍처에 사용되는 주요 서비스에 대해 고려할 사항입니다.

App Service Environment v3

App Service에 제공되는 다양한 가격 책정 옵션이 있습니다. App Service Environment는 격리된 v2 서비스 계획을 사용하여 배포됩니다. 이 계획 내에는 I1v2에서 I6v2까지 CPU 크기에 대한 여러 옵션이 있습니다. 이 참조 구현에서는 인스턴스당 3개의 I1v2를 사용합니다.

Application Gateway

Application Gateway 가격 책정 은 다양한 가격 책정 옵션을 제공합니다. 이 구현에서는 자동 크기 조정 및 영역 중복을 지원하는 Application Gateway Standard v2 및 WAF v2 SKU를 사용합니다. 이 SKU에 사용되는 가격 책정 모델에 대한 자세한 내용은 Application Gateway v2 및 WAF v2 크기 조정을 참조하세요.

Azure Cache for Redis

Azure Cache for Redis 가격 책정에서는 이 서비스에 대한 다양한 가격 책정 옵션을 제공합니다. 이 아키텍처에서는 가상 네트워크 지원을 위해 프리미엄 SKU를 사용합니다.

다음은 App Service Environment를 잠그는 데 사용되는 다른 서비스에 대한 가격 책정 페이지입니다.

• Azure Firewall 가격 책정

• Key Vault 가격 책정

• Microsoft Entra 가격 책정

시나리오 배포

이 아키텍처의 참조 구현을 배포하려면 GitHub 추가 정보을 확인하고, 표준 배포에 대한 스크립트를 따르세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Dhanashri Kshirsagar | 시니어 콘텐츠 PM

기타 기여자:

• Deep Bhattacharya | 클라우드 솔루션 설계자
• Suhas Rao | 클라우드 솔루션 설계자

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

• Azure App Service에서 ZIP 패키지의 앱 직접 실행하기
• Azure Pipelines YAML 스키마
• API에서 관리 주소 가져오기
• Azure Key Vault
• Azure Pipelines

관련 리소스

고가용성을 지원하도록 이 아키텍처를 확장하는 방법을 알아보려면 App Services 환경을 사용하여 고가용성 앱 배포를 읽어보세요.