편집

다음을 통해 공유

기본적으로 고가용성인 영역 중복 웹 애플리케이션

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL Database
Azure Private Link
Azure Virtual Network
Azure Monitor

이 기준 아키텍처는 기본 웹 애플리케이션 아키텍처를 기반으로 하며, Azure에서 보안, 영역 중복 및 고가용성 웹 애플리케이션을 디자인하기 위한 자세한 지침을 제공하도록 확장합니다. 아키텍처는 웹 애플리케이션 방화벽을 사용하여 Azure 애플리케이션 게이트웨이를 통해 공용 엔드포인트를 노출합니다. Private Link를 통해 Azure 앱 서비스에 요청을 라우팅합니다. App Service 애플리케이션은 가상 네트워크 통합 및 Private Link를 사용하여 Azure Key Vault 및 Azure SQL Database와 같은 Azure PaaS 서비스와 안전하게 통신합니다.

Important

GitHub 로고 이 지침은 Azure의 기준 App Service 구현 을 보여 주는 예제 구현을 통해 지원됩니다. 이 구현은 프로덕션을 향한 첫 번째 단계에서 추가 솔루션 개발을 위한 기초로 사용할 수 있습니다.

아키텍처

영역 중복성 및 고가용성이 있는 기준 App Service 아키텍처를 보여 주는 다이어그램.

그림 1: 기준 Azure 앱 서비스 아키텍처

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

구성 요소

이 아키텍처의 많은 구성 요소는 기본 웹 애플리케이션 아키텍처와 동일합니다. 다음 목록에서는 기본 아키텍처의 변경 내용만 강조 표시합니다.

  • Application Gateway는 계층 7(HTTP/S) 부하 분산 장치 및 웹 트래픽 관리자입니다. URL 경로 기반 라우팅을 사용하여 들어오는 트래픽을 가용성 영역에 분산하고 암호화를 오프로드하여 애플리케이션 성능을 향상시킵니다.
  • WAF(Web Application Firewall)는 SQL 삽입 및 교차 사이트 스크립팅과 같은 일반적인 악용으로부터 웹 앱을 보호하는 클라우드 네이티브 서비스입니다. WAF는 웹 애플리케이션을 들어오고 가는 트래픽에 대한 가시성을 제공하므로 애플리케이션을 모니터링하고 보호할 수 있습니다.
  • Azure Key Vault는 비밀, 암호화 키, 인증서를 안전하게 저장하고 관리하는 서비스입니다. 중요한 정보의 관리를 중앙 집중화합니다.
  • Azure Virtual Network 는 Azure에서 격리되고 안전한 프라이빗 가상 네트워크를 만들 수 있는 서비스입니다. App Service의 웹 애플리케이션의 경우 리소스 간의 네트워크 보안 통신에 프라이빗 엔드포인트를 사용하는 가상 네트워크 서브넷이 필요합니다.
  • Private Link를 사용하면 클라이언트가 공용 IP 주소 지정을 사용하지 않고 프라이빗 가상 네트워크에서 직접 Azure PaaS(Platform as a Service) 서비스에 액세스할 수 있습니다.
  • Azure DNS는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공하는 DNS 도메인에 대한 호스팅 서비스입니다. 프라이빗 DNS 영역은 서비스의 FQDN(정규화된 도메인 이름)을 프라이빗 엔드포인트의 IP 주소에 매핑하는 방법을 제공합니다.

네트워킹

네트워크 보안은 App Services 기준 아키텍처의 핵심입니다(그림 2 참조). 높은 수준에서 네트워크 아키텍처는 다음을 보장합니다.

  1. 클라이언트 트래픽에 대한 단일 보안 진입점
  2. 네트워크 트래픽이 필터링됨
  3. 전송 중인 데이터는 TLS를 사용하여 엔드투엔드로 암호화됩니다.
  4. Private Link를 사용하여 Azure에서 트래픽을 유지하여 데이터 반출을 최소화합니다.
  5. 네트워크 리소스는 네트워크 분할을 통해 논리적으로 그룹화되고 서로 격리됩니다.

네트워크 흐름

기준 App Service 네트워크 아키텍처를 보여 주는 다이어그램.

그림 2: 기준 Azure 앱 Service 애플리케이션의 네트워크 아키텍처

다음은 App Service 인스턴스로 인터넷 트래픽의 인바운드 흐름 및 App Service에서 Azure 서비스로의 흐름에 대한 설명입니다.

인바운드 흐름

  1. 사용자가 Application Gateway 공용 IP에 요청을 발급합니다.
  2. WAF 규칙이 평가됩니다. WAF 규칙은 XSS(교차 사이트 스크립팅) 및 SQL 삽입과 같은 다양한 공격으로부터 보호함으로써 시스템의 안정성에 긍정적인 영향을 줍니다. Azure 애플리케이션 게이트웨이는 WAF 규칙을 위반하고 처리가 중지된 경우 요청자에게 오류를 반환합니다. WAF 규칙을 위반하지 않으면 Application Gateway는 요청을 백 엔드 풀로 라우팅합니다. 이 경우 App Service 기본 도메인입니다.
  3. 프라이빗 DNS 영역 privatelink.azurewebsites.net 은 가상 네트워크에 연결됩니다. DNS 영역에는 App Service 기본 도메인을 App Service 프라이빗 엔드포인트의 개인 IP 주소에 매핑하는 A 레코드가 있습니다. 이 연결된 프라이빗 DNS 영역을 사용하면 Azure DNS가 기본 도메인을 프라이빗 엔드포인트 IP 주소로 확인할 수 있습니다.
  4. 요청은 프라이빗 엔드포인트를 통해 App Service 인스턴스로 라우팅됩니다.

Azure PaaS 서비스 흐름에 대한 App Service

  1. App Service는 필요한 Azure 서비스의 DNS 이름을 요청합니다. Azure Key Vault에 비밀, 게시 zip 파일, Azure SQL Database 또는 Private Link를 지원하는 다른 Azure 서비스를 가져오기 위한 Azure Storage 요청일 수 있습니다. App Service 가상 네트워크 통합 기능은 가상 네트워크를 통해 요청을 라우팅합니다.
  2. 인바운드 흐름의 3단계와 마찬가지로 연결된 프라이빗 DNS 영역에는 Azure 서비스의 도메인을 프라이빗 엔드포인트의 개인 IP 주소에 매핑하는 A 레코드가 있습니다. 이 연결된 프라이빗 DNS 영역을 사용하면 Azure DNS가 도메인을 서비스의 프라이빗 엔드포인트 IP 주소로 확인할 수 있습니다.
  3. 요청은 프라이빗 엔드포인트를 통해 서비스로 라우팅됩니다.

App Services에 수신

Application Gateway는 이 기준 아키텍처의 요구 사항을 충족하는 지역 리소스입니다. Application Gateway는 웹 애플리케이션 방화벽 및 TLS 오프로드와 같은 기능을 지원하는 확장 가능한 지역 7 계층 부하 분산 장치입니다. Azure 앱 Services로의 수신을 위해 Application Gateway를 구현할 때 다음 사항을 고려합니다.

  • Application Gateway를 배포하고 Microsoft 관리 규칙 집합을 사용하여 WAF 정책을 구성합니다. 방지 모드를 사용하여 원본 서비스(아키텍처의 App Service)를 사용할 수 없게 될 수 있는 웹 공격을 완화합니다.
  • 엔드투엔드 TLS 암호화를 구현합니다.
  • 프라이빗 엔드포인트를 사용하여 App Service에 대한 인바운드 프라이빗 액세스를 구현합니다.
  • 동적 트래픽 흐름에 쉽게 조정할 수 있도록 Application Gateway에 대한 자동 크기 조정 을 구현하는 것이 좋습니다.
  • 최소 크기 조정 인스턴스 수를 3개 이하로 사용하고 항상 해당 지역에서 지원하는 모든 가용성 영역을 사용하는 것이 좋습니다. Application Gateway는 고가용성 방식으로 배포되지만 단일 확장 인스턴스 의 경우에도 실패 시 새 인스턴스를 만드는 데 최대 7분이 걸릴 수 있습니다. 여러 인스턴스를 가용성 영역 배포하면 실패 시 새 인스턴스를 만드는 동안 인스턴스가 실행되도록 할 수 있습니다.
  • App Service에서 공용 네트워크 액세스를 사용하지 않도록 설정하여 네트워크 격리를 보장합니다. Bicep에서는 속성/siteConfig에서 설정 publicNetworkAccess: 'Disabled' 하여 이 작업을 수행합니다.

App Services에서 Azure 서비스로 흐름

이 아키텍처는 App Service에 대한 가상 네트워크 통합을 사용하며, 특히 가상 네트워크를 통해 프라이빗 엔드포인트로 트래픽을 라우팅합니다. 기준 아키텍처는 모든 트래픽 라우팅이 가상 네트워크를 통해 모든 아웃바운드 트래픽을 강제로 적용하는 것은 아니라 프라이빗 엔드포인트에 바인딩된 트래픽과 같은 내부 트래픽만 사용하도록 설정합니다.

공용 인터넷에서 액세스할 필요가 없는 Azure 서비스에는 프라이빗 엔드포인트를 사용하도록 설정하고 퍼블릭 엔드포인트를 사용하지 않도록 설정해야 합니다. 프라이빗 엔드포인트는 App Service가 공용 IP 주소 지정을 사용하지 않고 프라이빗 가상 네트워크에서 직접 Private Link 서비스에 연결할 수 있도록 하여 보안을 향상시키기 위해 이 아키텍처 전체에서 사용됩니다.

이 아키텍처에서 Azure SQL Database, Azure Storage 및 Key Vault는 모두 공용 엔드포인트를 사용하지 않도록 설정했습니다. Azure 서비스 방화벽은 다른 권한 있는 Azure 서비스의 트래픽을 허용하는 데만 사용됩니다. Azure Cosmos DB 및 Azure Redis Cache와 같은 프라이빗 엔드포인트를 사용하여 다른 Azure 서비스를 구성해야 합니다. 이 아키텍처에서 Azure Monitor는 프라이빗 엔드포인트를 사용하지 않지만 사용할 수 있습니다.

기준 아키텍처는 각 서비스에 대한 프라이빗 DNS 영역을 구현합니다. 프라이빗 DNS 영역에는 서비스의 정규화된 도메인 이름과 프라이빗 엔드포인트 개인 IP 주소 간에 매핑되는 A 레코드가 포함되어 있습니다. 영역은 가상 네트워크에 연결됩니다. 프라이빗 DNS 영역 그룹은 프라이빗 링크 DNS 레코드가 자동으로 만들어지고 업데이트되는지 확인합니다.

가상 네트워크 통합 및 프라이빗 엔드포인트를 구현할 때 다음 사항을 고려합니다.

가상 네트워크 분할 및 보안

이 아키텍처의 네트워크에는 Application Gateway, App Service 통합 구성 요소 및 프라이빗 엔드포인트에 대한 별도의 서브넷이 있습니다. 각 서브넷에는 해당 서브넷의 인바운드 및 아웃바운드 트래픽을 모두 필요한 것으로 제한하는 네트워크 보안 그룹이 있습니다. 다음 표에서는 기준이 각 서브넷에 추가하는 NSG 규칙의 간소화된 보기를 보여 줍니다. 테이블은 규칙 이름과 함수를 제공합니다.

서브넷 인바운드 아웃바운드
snet-AppGateway AppGw.In.Allow.ControlPlane: 인바운드 컨트롤 플레인 액세스 허용

AppGw.In.Allow443.Internet: 인바운드 인터넷 HTTPS 액세스 허용		 AppGw.Out.Allow.AppServices: AppServicesSubnet에 대한 아웃바운드 액세스 허용

AppGw.Out.Allow.PrivateEndpoints: PrivateEndpointsSubnet에 대한 아웃바운드 액세스 허용

AppPlan.Out.Allow.AzureMonitor: Azure Monitor에 대한 아웃바운드 액세스 허용
snet-PrivateEndpoints 기본 규칙: 가상 네트워크에서 인바운드 허용 기본 규칙: 가상 네트워크에 아웃바운드 허용
snet-AppService 기본 규칙: vnet에서 인바운드 허용 AppPlan.Out.Allow.PrivateEndpoints: PrivateEndpointsSubnet에 대한 아웃바운드 액세스 허용

AppPlan.Out.Allow.AzureMonitor: Azure Monitor에 대한 아웃바운드 액세스 허용

가상 네트워크 세분화 및 보안을 구현할 때 다음 사항을 고려합니다.

  • 공용 IP를 사용하는 애플리케이션 게이트웨이의 일부인 서브넷을 사용하여 가상 네트워크에 대해 DDoS 보호를 사용하도록 설정합니다.
  • 가능한 경우 모든 서브넷에 NSG를 추가합니다. 전체 솔루션 기능을 사용하도록 설정하는 가장 엄격한 규칙을 사용해야 합니다.
  • 애플리케이션 보안 그룹을 사용합니다. 애플리케이션 보안 그룹을 사용하면 NSG를 그룹화하여 복잡한 환경에서 규칙을 더 쉽게 만들 수 있습니다.

가상 서브넷 스키마의 예는 다음과 같습니다.

Type 속성 주소 범위
Virtual Network 주소 접두사 10.0.0.0/16
서브넷 GatewaySubnet 10.0.1.0/24
서브넷 AppServicesSubnet 10.0.0.0/24
서브넷 PrivateEndpointsSubnet 10.0.2.0/27
서브넷 AgentsSubject 10.0.2.32/27

Azure-Samples\app-service-baseline-implementation 참조

고려 사항

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

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.

기준 App Services 아키텍처는 주요 지역 서비스에 대한 영역 중복성에 중점을 둡니다. 가용성 영역은 지역 내에서 물리적으로 분리된 위치입니다. 둘 이상의 인스턴스가 지원 지역에 배포될 때 지원 서비스에 대한 영역 중복성을 제공합니다. 한 영역이 가동 중지 시간을 경험하는 경우 다른 영역은 여전히 영향을 받지 않을 수 있습니다.

또한 이 아키텍처는 수요를 충족하기에 충분한 Azure 서비스 인스턴스를 보장합니다. 다음 섹션에서는 아키텍처의 주요 서비스에 대한 안정성 지침을 제공합니다. 이러한 방식으로 가용성 영역은 고가용성 및 내결함성을 제공하여 안정성을 달성하는 데 도움이 됩니다.

Application Gateway

영역 중복 구성에서 Azure 애플리케이션 Gateway v2를 배포합니다. 오류가 있는 경우 Application Gateway 인스턴스의 시작 시간을 6~7분으로 방지하려면 최소 크기 조정 인스턴스 수를 3개 이하로 사용하는 것이 좋습니다.

앱 Services

  • 가용성 영역 지원을 사용하여 App Services 인스턴스를 3개 이상 배포합니다.
  • 앱에서 상태 확인 엔드포인트를 구현하고 비정상 인스턴스에서 요청을 다시 라우팅하도록 App Service 상태 확인 기능을 구성합니다. App Service 상태 확인에 대한 자세한 내용은 상태 확인을 사용하여 App Service 인스턴스 모니터링을 참조하세요. ASP.NET 애플리케이션에서 상태 확인 엔드포인트 구현에 대한 자세한 내용은 ASP.NET Core의 상태 확인을 참조하세요.
  • 영역 오류를 처리할 수 있는 오버프로비전 용량입니다.

SQL Database

Blob Storage

  • Azure ZRS(영역 중복 스토리지 )는 해당 지역의 세 가용성 영역에서 데이터를 동기적으로 복제합니다. 표준 ZRS 또는 표준 GZRS 스토리지 계정을 만들어 가용성 영역 간에 데이터가 복제되도록 합니다.
  • 계정을 별도로 관리하고 구성할 수 있도록 배포, 웹 자산 및 기타 데이터에 대한 별도의 스토리지 계정을 만듭니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.

다음 섹션에서는 이 아키텍처의 주요 구성 요소에 대한 확장성에 대해 설명합니다.

Application Gateway

  • Application Gateway의 자동 크기 조정을 구현하여 수요에 맞게 스케일 인 또는 스케일 아웃합니다.
  • 최대 인스턴스 수를 예상한 것보다 높은 숫자로 설정합니다. 사용하는 용량 단위에 대해서만 요금이 청구됩니다.
  • 트래픽의 작은 급증을 처리할 수 있는 최소 인스턴스 수를 설정합니다. 평균 컴퓨팅 단위 사용량을 사용하여 최소 인스턴스 수를 계산할 수 있습니다.
  • Application Gateway 서브넷의 크기 조정에 대한 지침을 따릅니다.

App Service

SQL Server

데이터베이스 리소스 크기 조정은 이 아키텍처의 범위를 벗어나는 복잡한 항목입니다. 데이터베이스 크기를 조정하는 경우 다음 리소스를 고려합니다.

기타 확장성 지침

  • 구독 한도 및 할당량을 검토하여 서비스가 수요에 맞게 크기 조정되는지 확인합니다.
  • 성능과 확장성을 높이기 위해 다음과 같은 종류의 데이터를 캐싱하는 것이 좋습니다.
    • 반정적 트랜잭션 데이터
    • 세션 상태
    • HTML 출력 이는 복잡한 HTML 출력을 렌더링하는 애플리케이션에 유용할 수 있습니다.

보안

기준 App Service 아키텍처는 웹앱에 대한 필수 보안 권장 사항에 중점을 둡니다. 모든 계층에서 암호화 및 ID가 작동하는 방식을 이해하는 것은 워크로드를 보호하는 데 중요합니다.

App Service

  • FTP 및 SCM 사이트 배포에 대한 로컬 인증 방법 사용 안 함
  • 원격 디버깅을 끕니다.
  • 최신 TLS 버전을 사용합니다.
  • App Service용 Microsoft Defender를 사용하도록 설정합니다.
  • 최신 버전의 지원되는 플랫폼, 프로그래밍 언어, 프로토콜 및 프레임워크를 사용합니다.
  • 더 높은 격리 또는 보안 네트워크 액세스가 필요한 경우 App Service Environment를 고려합니다.

암호화

프로덕션 웹앱은 HTTPS를 사용하여 전송 중인 데이터를 암호화해야 합니다. HTTPS 프로토콜은 TLS(전송 계층 보안)를 사용하며 암호화에 공용 및 프라이빗 키를 사용합니다. Key Vault에 인증서(X.509)를 저장하고 Application Gateway가 프라이빗 키를 검색하도록 허용해야 합니다. 미사용 데이터의 경우 일부 서비스는 자동으로 데이터를 암호화하고 다른 서비스는 사용자 지정할 수 있습니다.

전송 중 데이터

기준 아키텍처에서 전송 중인 데이터는 사용자에서 App Service의 웹앱으로 암호화됩니다. 다음 워크플로에서는 암호화가 높은 수준에서 작동하는 방식을 설명합니다.

기준 App Service 암호화 흐름을 보여 주는 다이어그램.

  1. 사용자가 웹앱에 HTTPS 요청을 보냅니다.
  2. HTTPS 요청이 애플리케이션 게이트웨이에 도달합니다.
  3. 애플리케이션 게이트웨이는 Key Vault의 인증서(X.509)를 사용하여 사용자의 웹 브라우저와 보안 TLS 연결을 만듭니다. 애플리케이션 게이트웨이는 웹 애플리케이션 방화벽에서 검사할 수 있도록 HTTPS 요청을 해독합니다.
  4. 애플리케이션 게이트웨이는 App Service와 TLS 연결을 만들어 사용자 요청을 다시 암호화합니다. App Service는 HTTPS에 대한 기본 지원을 제공하므로 App Service에 인증서를 추가할 필요가 없습니다. 애플리케이션 게이트웨이는 암호화된 트래픽을 App Service로 보냅니다. App Service는 트래픽의 암호를 해독하고 웹앱은 요청을 처리합니다.

전송 중 데이터 암호화를 구성할 때 다음 권장 사항을 고려합니다.

  • Key Vault에 인증서를 만들거나 업로드합니다. HTTPS 암호화에는 인증서(X.509)가 필요합니다. 사용자 지정 도메인에 대해 신뢰할 수 있는 인증 기관의 인증서가 필요합니다.
  • Key Vault의 인증서에 프라이빗 키를 저장합니다.
  • 애플리케이션에 대한 권한 부여 권한의 지침에 따라 Azure 리소스에 대한 Azure RBAC 및 관리 ID를 사용하여 Azure 키 자격 증명 모음에 액세스하여 인증서 프라이빗 키에 대한 Application Gateway 액세스를 제공합니다. Key Vault 액세스 정책을 사용하여 액세스를 제공하지 마세요. 액세스 정책을 사용하면 특정 값뿐만 아니라 광범위한 권한만 부여할 수 있습니다.
  • 종단 간 암호화를 사용하도록 설정합니다. App Service는 애플리케이션 게이트웨이의 백 엔드 풀입니다. 백 엔드 풀에 대한 백 엔드 설정을 구성할 때 백 엔드 포트 443을 통해 HTTPS 프로토콜을 사용합니다.
미사용 데이터
  • 투명한 데이터 암호화를 사용하여 Azure SQL Database에서 중요한 데이터를 암호화합니다. 투명한 데이터는 전체 데이터베이스, 백업 및 트랜잭션 로그 파일을 암호화하며 웹 애플리케이션을 변경할 필요가 없습니다.
  • 데이터베이스 암호화 대기 시간을 최소화합니다. 암호화 대기 시간을 최소화하려면 자체 데이터베이스에 보호해야 하는 데이터를 배치하고 해당 데이터베이스에 대해서만 암호화를 사용하도록 설정합니다.
  • 기본 제공 암호화 지원을 이해합니다. Azure Storage는 서버 쪽 암호화(256비트 AES)를 사용하여 미사용 데이터를 자동으로 암호화합니다. Azure Monitor는 MMK(Microsoft 관리형 키)를 사용하여 미사용 데이터를 자동으로 암호화합니다.

ID 및 액세스 관리

App Service 기준은 사용자 ID(사용자) 및 워크로드 ID(Azure 리소스)에 대한 인증 및 권한 부여를 구성하고 최소 권한 원칙을 구현합니다.

사용자 ID
  • App Service( "EasyAuth")에 대한 통합 인증 메커니즘을 사용합니다. EasyAuth는 ID 공급자를 웹앱에 통합하는 프로세스를 간소화합니다. 웹앱 외부에서 인증을 처리하므로 중요한 코드를 변경할 필요가 없습니다.
  • 사용자 지정 도메인에 대한 회신 URL을 구성합니다. 웹앱을 https://<application-gateway-endpoint>/.auth/login/<provider>/callback.로 리디렉션해야 합니다. 공용 IP 주소 또는 애플리케이션 게이트웨이와 연결된 사용자 지정 도메인 이름으로 바꿉 <application-gateway-endpoint> 니다. Microsoft Entra ID에 대한 "aad"와 같이 사용 중인 인증 공급자로 바꿉 <provider> 니다. Azure Front 설명서를 사용하여 Application Gateway를 사용하여 이 흐름을 설정하거나 Application Gateway를 설정할 수 있습니다.
워크로드 ID
  • 워크로드 ID에 관리 ID를 사용합니다. 관리 ID를 통해 개발자는 이러한 인증 자격 증명을 관리할 필요가 없습니다.
  • 사용자 할당 관리 ID를 사용합니다. 시스템 할당 ID는 경합 조건 및 작업 순서에 따라 코드 기반 인프라 배포가 실패할 수 있습니다. 사용자 할당 관리 ID를 사용하여 이러한 배포 오류 시나리오 중 일부를 방지할 수 있습니다. 자세한 내용은 관리 ID를 참조하세요.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.

기준 App Service 애플리케이션에 대한 배포는 Azure Pipelines를 사용하는 Azure Web Apps에 대한 CI/CD의 지침을 따릅니다. 이 지침 외에도 App Services 기준 아키텍처는 애플리케이션 및 배포 스토리지 계정이 네트워크 보안이라는 점을 고려합니다. 아키텍처는 App Service에 대한 공용 액세스를 거부합니다. 즉, 가상 네트워크 외부에서 배포할 수 없습니다. 기준은 자체 호스팅 배포 에이전트를 사용하여 가상 네트워크 내에서 애플리케이션 코드를 배포하는 방법을 보여 줍니다. 다음 배포 지침에서는 인프라 또는 데이터베이스 변경 내용을 배포하지 않고 애플리케이션 코드를 배포하는 데 중점을 둡니다.

기준 App Service 배포 아키텍처를 보여 주는 다이어그램.

그림 3: Azure 앱 Service 애플리케이션 배포

배포 흐름

  1. 릴리스 파이프라인의 일부로 파이프라인은 작업 큐에 자체 호스팅 에이전트에 대한 작업 요청을 게시합니다. 작업 요청은 에이전트가 게시 zip 파일 빌드 아티팩트를 Azure Storage 계정에 업로드하는 것입니다.

  2. 자체 호스팅 배포 에이전트는 폴링을 통해 새 작업 요청을 선택합니다. 작업 및 빌드 아티팩트가 다운로드됩니다.

  3. 자체 호스팅 배포 에이전트는 스토리지 계정의 프라이빗 엔드포인트를 통해 스토리지 계정에 zip 파일을 업로드합니다.

  4. 파이프라인이 계속되고 관리되는 에이전트가 후속 작업을 선택합니다. 관리되는 에이전트 는 cli를 호출하여 appSetting WEBSITE_RUN_FROM_PACKAGE 스테이징 슬롯에 대한 새 게시 zip 파일의 이름으로 업데이트합니다.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip

  5. Azure 앱 Service는 스토리지 계정 프라이빗 엔드포인트를 통해 스토리지에서 새 게시 zip 파일을 가져옵니다. WEBSITE_RUN_FROM_PACKAGE 다른 파일 이름으로 설정되었으므로 스테이징 인스턴스 새 패키지로 다시 시작됩니다.

  6. 파이프라인은 연기 테스트를 다시 시작하고 실행하거나 승인을 기다립니다. 테스트 통과 또는 승인이 제공되면 파이프라인은 스테이징 및 프로덕션 슬롯을 교환합니다.

배포 지침

다음은 기준 아키텍처에 대한 주요 배포 지침을 강조 표시합니다.

  • 패키지에서 실행을 사용하여 배포 충돌을 방지합니다. Azure 앱 Service의 패키지에서 직접 앱을 실행하면 패키지의 파일이 wwwroot 디렉터리에 복사되지 않습니다. 대신 ZIP 패키지 자체가 읽기 전용 wwwroot 디렉터리로 직접 탑재됩니다. 이렇게 하면 배포와 런타임 간의 파일 잠금 충돌이 제거되고 완전히 배포된 앱만 언제든지 실행되도록 합니다.
  • 배포된 패키지 zip 파일에 버전 번호를 포함합니다. appSetting을 다른 파일 이름으로 배포 패키지로 업데이트 WEBSITE_RUN_FROM_PACKAGE 하면 App Services가 자동으로 새 버전을 선택하고 서비스를 다시 시작합니다.
  • 복원력 있는 코드 배포에 대해 배포 슬롯을 사용합니다.
  • 관리되는 에이전트와 자체 호스팅 에이전트의 혼합을 사용하는 것이 좋습니다.
    • 자체 호스팅 에이전트를 사용하여 프라이빗 엔드포인트를 통해 스토리지 계정에 패키지 zip 파일을 업로드합니다. 에이전트는 폴링을 통해 파이프라인에 대한 통신을 시작하므로 인바운드 호출을 위해 네트워크를 열 필요가 없습니다.
    • 파이프라인의 다른 작업에 관리되는 에이전트를 사용합니다.
  • IaC(Infrastructure as Code)를 사용하여 인프라 배포를 자동화합니다.
  • Azure Load Testing 및 Azure Chaos Studio와 같은 서비스를 사용하여 전체 솔루션의 성능 및 복원력을 테스트하기 위해 워크로드의 유효성을 지속적으로 검사합니다.

구성

애플리케이션에는 구성 값과 비밀이 모두 필요합니다. 구성 및 비밀 관리에 대해 다음 지침을 사용합니다.

  • 암호 또는 액세스 키와 같은 비밀을 소스 제어에 확인하지 마세요.
  • Azure Key Vault를 사용하여 비밀을 저장합니다.
  • 애플리케이션 구성에 App Service 구성을 사용합니다. 애플리케이션 구성에서 구성을 외부화해야 하거나 기능 플래그 지원이 필요한 경우 Azure 앱 구성을 사용하는 것이 좋습니다.
  • App Service 구성에서 Key Vault 참조를 사용하여 애플리케이션에서 비밀을 안전하게 노출합니다.
  • 슬롯에 충실하고 다른 프로덕션 및 스테이징 설정이 필요한 경우 교환되지 않는 앱 설정을 만듭니다. 배포 슬롯을 교환하면 앱 설정이 기본적으로 교환됩니다.
  • 로컬 개발을 위해 로컬 환경 변수를 설정하거나 애플리케이션 플랫폼 기능을 활용합니다. App Services 구성은 앱 설정을 환경 변수로 노출합니다. 예를 들어 Visual Studio를 사용하면 시작 프로필에서 환경 변수를 설정할 수 있습니다. 또한 앱 설정 및 사용자 비밀을 사용하여 로컬 애플리케이션 설정 및 비밀을 저장할 수 있습니다.

모니터링

모니터링은 IT 시스템의 데이터 수집 및 분석입니다. 모니터링의 목표는 웹앱 상태 및 보안을 추적하기 위한 여러 계층의 관찰성입니다. 관찰성은 기준 App Service 아키텍처의 핵심 측면입니다.

웹앱을 모니터링하려면 애플리케이션 코드, 인프라(런타임) 및 플랫폼(Azure 리소스)에서 메트릭과 로그를 수집하고 분석해야 합니다. 자세한 내용은 Azure 활동 로그, Azure 리소스 로그 및 애플리케이션 로그를 참조하세요.

플랫폼 모니터링

플랫폼 모니터링은 아키텍처의 Azure 서비스에서 데이터를 수집한 것입니다. 플랫폼 모니터링에 대한 다음 지침을 고려합니다.

Application Gateway

Application Gateway는 백 엔드 풀의 리소스 상태를 모니터링합니다. Application Gateway 액세스 로그를 사용하여 타임스탬프, HTTP 응답 코드 및 URL 경로와 같은 정보를 수집합니다. 자세한 내용은 Application Gateway 기본 상태 프로브 및 백 엔드 상태 및 진단 로그를 참조하세요.

App Service

App Service에는 향상된 가시성을 위해 사용하도록 설정해야 하는 기본 제공 및 통합 모니터링 도구가 있습니다. 웹앱에 이미 원격 분석 및 모니터링 기능("In-process 계측")이 있는 경우 App Service에서 계속 작동해야 합니다.

  • 자동 계측을 사용하도록 설정합니다. App Service에는 코드 변경 없이 사용하도록 설정할 수 있는 계측 확장이 있습니다. APM(애플리케이션 성능 모니터링) 가시성을 얻습니다. 자세한 내용은 Azure 앱 서비스 성능 모니터링을 참조하세요.
  • 분산 추적을 사용하도록 설정합니다. 자동 계측은 분산 추적 및 성능 프로파일러를 통해 분산 클라우드 시스템을 모니터링하는 방법을 제공합니다.
  • 사용자 지정 원격 분석에 코드 기반 계측을 사용합니다. Azure 애플리케이션 Insights는 사용자 지정 애플리케이션 원격 분석에 대한 코드 기반 계측도 지원합니다. 코드에 Application Insights SDK를 추가하고 Application Insights API를 사용합니다.
  • App Service 로그를 사용하도록 설정합니다. App Service 플랫폼은 문제 해결을 지원하기 위해 사용하도록 설정해야 하는 4개의 추가 로그를 지원합니다. 이러한 로그는 애플리케이션 로그, 웹 서버 로그, 자세한 오류 메시지 및 실패한 요청 추적입니다.
  • 구조적 로깅을 사용합니다. 애플리케이션 코드에 구조화된 로깅 라이브러리를 추가합니다. 키-값 쌍을 사용하도록 코드를 업데이트하고 App Service에서 애플리케이션 로그가 Log Analytics 작업 영역에 이러한 로그를 저장할 수 있도록 합니다.
  • App Service Health 검사를 켭니다. 상태 검사는 비정상 인스턴스에서 요청을 다시 라우팅하고 비정상 인스턴스를 대체합니다. App Service 계획은 상태 검사가 작동하려면 둘 이상의 인스턴스를 사용해야 합니다.
데이터베이스
  • User database Insights. Azure SQL 데이터베이스의 경우 Azure Monitor에서 SQL Insights를 구성해야 합니다. Database Insights는 동적 관리 뷰를 사용하여 상태를 모니터링하고, 문제를 진단하고, 성능을 조정하는 데 필요한 데이터를 노출합니다. 자세한 내용은 Azure Monitor를 사용하여 Azure SQL Database 모니터링을 참조 하세요.
  • 아키텍처에 Cosmos DB가 포함된 경우 Cosmos DB 인사이트를 사용하도록 설정하거나 구성할 필요가 없습니다.

거버넌스

웹앱은 아키텍처 및 보안 결정을 적용하여 Azure Policy의 이점을 누릴 수 있습니다. Azure Policy를 사용하면 (1) 배포(거부) 또는 (2) 원하는 상태에서 구성 드리프트를 쉽게 감지(감사)할 수 있습니다. 이렇게 하면 합의된 아키텍처에서 벗어나는 IaC(Infrastructure as Code) 배포 또는 Azure Portal 변경 내용을 catch할 수 있습니다. 아키텍처의 모든 리소스를 Azure Policy 거버넌스 아래에 배치해야 합니다. 가능한 경우 기본 제공 정책 또는 정책 이니셔티브를 사용하여 필수 네트워크 토폴로지, 서비스 기능, 보안 및 모니터링 결정을 적용합니다. 예를 들면 다음과 같습니다.

  • App Service에서 공용 네트워크 액세스를 사용하지 않도록 설정해야 함
  • 앱 서비스는 가상 네트워크 통합을 사용해야 합니다.
  • App Service는 Azure Private Link를 사용하여 PaaS 서비스에 연결해야 합니다.
  • App Service는 FTP 및 SCM 사이트 배포에 대해 로컬 인증 방법을 사용하지 않도록 설정해야 합니다.
  • App Service에 원격 디버깅이 꺼져 있어야 합니다.
  • App Service 앱은 최신 TLS 버전을 사용해야 함
  • App Service용 Microsoft Defender를 사용하도록 설정해야 함
  • Application Gateway에 WAF(웹 애플리케이션 방화벽)를 사용하도록 설정해야 함

Application Gateway 및 네트워킹 구성 요소, App Service, Key Vault 및 모니터링과 같은 주요 서비스에 대한 추가 기본 제공 정책을 참조하세요. 기본 제공 정책이 요구 사항을 완전히 충족하지 않는 경우 사용자 지정 정책을 만들거나 커뮤니티 정책(예: Azure 랜딩 존)을 사용할 수 있습니다. 기본 제공 정책을 사용할 수 있는 경우 선호합니다.

다음 단계

고가용성 다중 지역 웹 애플리케이션 읽기