Azure 앱 Service의 Web Apps 기능에 대한 Azure 잘 설계된 프레임워크 관점
Azure 앱 Service는 Azure 플랫폼에서 워크로드를 호스트하는 데 사용할 수 있는 PaaS(Platform as a Service) 컴퓨팅 솔루션입니다. 기본 컴퓨팅을 추상화하고 플랫폼으로 빌드, 배포 및 크기 조정의 책임을 오프로드하는 완전 관리형 서비스입니다. 앱 서비스는 항상 App Service 요금제에서 실행됩니다. 선택하는 서비스 계획은 워크로드가 실행되는 지역, 컴퓨팅 구성 및 운영 체제를 결정합니다. App Service에는 여러 청구 모델을 사용할 수 있습니다.
이 문서에서는 설계자로서 컴퓨팅 의사 결정 트리를 검토하고 워크로드에 대한 컴퓨팅으로 App Service를 선택했다고 가정합니다. 이 문서의 지침은 Azure Well-Architected Framework 핵심 요소의 원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.
Important
이 가이드를 사용하는 방법
각 섹션에는 기술 범위로 지역화된 디자인 전략과 함께 관심 있는 아키텍처 영역을 제공하는 디자인 검사 목록이 있습니다.
또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 Azure 앱 Service의 Web Apps 기능 및 해당 종속성에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.
주요 권장 사항을 보여 주는 기본 아키텍처: App Service 기준 아키텍처입니다.
기술 범위
이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.
- App Service 계획
- Web Apps
다른 Azure 제품은 Azure Functions, Azure Logic Apps 및 App Service Environment와 같은 App Service와 연결됩니다. 이러한 제품은 이 문서의 범위를 벗어납니다. App Service 환경은 핵심 App Service 제품의 기능 또는 옵션을 명확히 하기 위해 가끔 참조됩니다.
안정성
안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을 구축하여 지속적인 기능을 제공하는 것입니다.
안정성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 디자인 전략을 제공합니다.
디자인 검사 목록
디자인 검토 검사 안정성 목록에 따라 디자인 전략을 시작합니다. App Service의 계층 및 기능 및 종속성을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
사용자 흐름 우선 순위 지정: 모든 흐름이 똑같이 중요한 것은 아닙니다. 각 흐름에 우선 순위를 할당하여 디자인 결정을 안내합니다. 사용자 흐름 디자인은 App Service 계획 및 구성에 대해 선택한 서비스 계층 및 인스턴스에 영향을 줄 수 있습니다.
예를 들어 애플리케이션에는 메시지 브로커를 통해 통신하는 프런트 엔드 및 백 엔드 계층이 포함될 수 있습니다. 여러 웹앱에서 계층을 분할하여 독립적인 크기 조정, 수명 주기 관리 및 기본 테넌트 허용하도록 선택할 수 있습니다. 큰 애플리케이션을 단일 계획에 배치하면 메모리 또는 CPU 문제가 발생할 수 있으며 안정성에 영향을 줄 수 있습니다.
UI 쪽에서 최적의 성능을 위해 프런트 엔드에 더 많은 인스턴스가 필요할 수 있습니다. 그러나 백 엔드에는 동일한 수의 인스턴스가 필요하지 않을 수 있습니다.
잠재적인 실패 예측: 잠재적 오류에 대한 완화 전략을 계획합니다. 다음 표에서는 오류 모드 분석의 예를 보여 줍니다.
고장 완화 기본 또는 추상화된 App Service 구성 요소의 실패 인스턴스 및 종속성에 구성 요소 중복성이 있습니다. 인스턴스의 상태, 네트워크 성능 및 스토리지 성능을 모니터링합니다. 외부 종속성 오류 재시도 패턴 및 회로 차단기 패턴과 같은 디자인 패턴을 사용합니다. 외부 종속성을 모니터링하고 적절한 시간 제한을 설정합니다. 비정상 인스턴스로 라우팅되는 트래픽으로 인한 오류 인스턴스 상태를 모니터링합니다. 응답성을 고려하고 비정상 인스턴스에 요청을 보내지 않도록 합니다. 자세한 내용은 Azure 애플리케이션에 대한 실패 모드 분석을 참조 하세요.
빌드 중복성: 애플리케이션 및 지원 인프라에서 중복성을 빌드합니다. 가용성 영역에 인스턴스를 분산하여 내결함성을 개선합니다. 한 영역이 실패하는 경우 트래픽을 다른 영역으로 라우팅합니다. 여러 지역에 애플리케이션을 배포하여 전체 지역에서 가동 중단이 발생하더라도 앱이 다시 사용할 수 있도록 기본.
종속 서비스에서 비슷한 수준의 중복성을 빌드합니다. 예를 들어 애플리케이션 인스턴스는 Blob Storage에 바인딩됩니다. 애플리케이션에서 영역 중복 배포를 사용하는 경우 ZRS(영역 중복 스토리지)를 사용하여 연결된 스토리지 계정을 구성하는 것이 좋습니다.
네트워킹 구성 요소의 중복성을 갖습니다. 예를 들어 영역 중복 IP 주소 및 부하 분산 장치를 사용합니다.
안정적인 크기 조정 전략을 갖습니다. 애플리케이션에서 예기치 않은 로드로 인해 신뢰할 수 없게 될 수 있습니다. 워크로드 특성에 따라 적절한 크기 조정 방법을 고려합니다. 경우에 따라 부하를 처리하도록 확장할 수 있습니다. 그러나 부하가 계속 증가하는 경우 새 인스턴스로 확장합니다. 수동 접근 방식보다 자동 크기 조정을 선호합니다. 성능 저하를 방지하기 위해 크기 조정 작업 중에 항상 추가 용량 버퍼를 기본.
선택한 App Service 계획 계층은 인스턴스 수 및 컴퓨팅 단위 측면에서 크기 조정에 영향을 줍니다.
새 인스턴스가 빠르게 준비되고 요청을 받을 수 있도록 적절한 앱 초기화를 보장합니다.
가능한 경우 상태 비저장 애플리케이션을 위해 노력합니다. 새 인스턴스를 사용하여 상태를 안정적으로 확장하면 복잡성이 증가할 수 있습니다. 애플리케이션 상태를 저장해야 하는 경우 독립적으로 확장할 수 있는 외부 데이터 저장소를 고려합니다. 세션 상태를 메모리에 저장하면 애플리케이션 또는 App Service에 문제가 있을 때 세션 상태가 손실될 수 있습니다. 또한 다른 인스턴스에 부하를 분산할 가능성도 제한합니다.
자동 크기 조정 규칙을 정기적으로 테스트합니다. 로드 시나리오를 시뮬레이션하여 앱이 예상대로 확장되는지 확인합니다. 발생할 수 있는 문제를 해결하고 시간이 지남에 따라 크기 조정 전략을 최적화할 수 있도록 크기 조정 이벤트를 기록해야 합니다.
App Service에는 계획 내의 인스턴스 수에 제한이 있어 크기 조정 안정성에 영향을 줄 수 있습니다. 한 가지 전략은 동일한 배포 스탬프를 사용하고 각 실행 중인 App Service 계획 인스턴스를 자체 엔드포인트와 함께 사용하는 것입니다. 외부 부하 분산 장치를 사용하여 모든 스탬프를 전면에 배치하여 트래픽을 분산하는 것이 중요합니다. 단일 노드 배포에 Azure 애플리케이션 Gateway를 사용하고 다중 지역 배포에 Azure Front Door를 사용합니다. 이 접근 방식은 안정성이 중요한 중요 업무용 애플리케이션에 적합합니다. 자세한 내용은 App Service를 사용하여 중요 업무용 기준을 참조 하세요.
App Service 계획은 인스턴스 간에 트래픽을 분산하고 상태를 모니터링합니다. 외부 부하 분산 장치는 하나의 인스턴스가 실패하는지 즉시 감지하지 못할 수 있습니다.
복구 가능성 계획: 중복성은 비즈니스 연속성에 매우 중요합니다. 한 인스턴스에 연결할 수 없는 경우 다른 인스턴스로 장애 조치(failover)합니다. 인스턴스 자동 복구와 같은 App Service의 자동 복구 기능을 살펴봅니다.
네트워크 연결 문제와 같은 일시적인 오류와 지역 중단과 같은 대규모 이벤트 모두에 대해 정상적인 성능 저하를 처리하는 디자인 패턴을 구현합니다. 다음 디자인 패턴을 고려합니다.
Bulkhead 패턴 은 애플리케이션을 격리된 그룹으로 분할하여 오류가 전체 시스템에 영향을 주지 않도록 합니다.
큐 기반 부하 평준화 패턴 은 트래픽 급증을 원활하게 하기 위한 버퍼 역할을 하는 작업 항목을 큐에 저장합니다.
다시 시도 패턴은 네트워크 결함, 삭제된 데이터베이스 연결 또는 사용 중인 서비스로 인한 일시적인 오류를 처리합니다.
회로 차단기 패턴 은 애플리케이션이 실패할 가능성이 있는 작업을 반복적으로 수행하지 못하게 합니다.
WebJobs를 사용하여 웹앱에서 백그라운드 작업을 실행할 수 있습니다. 이러한 작업을 안정적으로 실행하려면 작업을 호스트하는 앱이 일정에 따라 또는 이벤트 기반 트리거에 따라 지속적으로 실행되는지 확인합니다.
자세한 내용은 안정성 패턴을 참조 하세요.
안정성 테스트 수행: 부하 테스트를 수행하여 부하 상태에서 애플리케이션의 안정성 및 성능을 평가합니다. 테스트 계획에는 자동화된 복구 작업의 유효성을 검사하는 시나리오가 포함되어야 합니다.
오류 주입을 사용하여 의도적으로 오류를 도입하고 자체 복구 및 자기 보존 메커니즘의 유효성을 검사합니다. Azure Chaos Studio에서 제공하는 오류 라이브러리를 탐색합니다.
App Service는 호스트된 앱에 리소스 제한을 적용합니다. App Service 계획은 이러한 제한을 결정합니다. 테스트에서 앱이 해당 리소스 제한 내에서 실행되는지 확인합니다. 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
상태 프로브를 사용하여 응답하지 않는 작업자 식별: App Service에는 웹 애플리케이션의 특정 경로를 주기적으로 ping하는 기본 제공 기능이 있습니다. 응답하지 않는 인스턴스는 부하 분산 장치에서 제거되고 새 인스턴스로 대체됩니다.
권장 사항
| 서비스 또는 계획 | 추천 | 장점 |
|---|---|---|
| App Service 계획 | 프로덕션 워크로드에 대한 App Service 계획의 프리미엄 계층을 선택합니다. 용량 계획에 따라 최대 및 최소 작업자 수를 설정합니다. 자세한 내용은 App Service 계획 개요를 참조하세요. |
프리미엄 App Service 계획은 고급 크기 조정 기능을 제공하고 오류가 발생할 경우 중복성을 보장합니다. |
| App Service 계획 | 영역 중복을 사용하도록 설정합니다. 내결함성을 향상시키기 위해 3개 이상의 인스턴스를 프로비전하는 것이 좋습니다. 모든 지역에서 이 기능을 제공하는 것은 아니므로 지역별 지원에서 영역 중복성을 확인합니다. |
여러 인스턴스가 영역에 분산된 경우 애플리케이션은 단일 영역에서 오류를 견딜 수 있습니다. 트래픽은 자동으로 다른 영역의 정상 인스턴스로 이동하고 기본 영역을 사용할 수 없는 경우 애플리케이션 안정성을 유지합니다. |
| App Service | ARR(애플리케이션 요청 라우팅) 선호도 기능을 사용하지 않도록 설정하는 것이 좋습니다. ARR 선호도는 사용자를 이전 요청을 처리한 노드로 리디렉션하는 고정 세션을 만듭니다. | ARR 선호도를 사용하지 않도록 설정하면 들어오는 요청이 사용 가능한 모든 노드에 균등하게 분산됩니다. 균등하게 분산된 요청은 트래픽이 단일 노드를 압도하는 것을 방지합니다. 노드를 사용할 수 없는 경우 요청을 다른 정상 노드로 원활하게 리디렉션할 수 있습니다. App Service 인스턴스가 상태 비정상 상태인지 확인하려면 세션 선호도를 사용하지 기본. 상태 비스테이션 App Service는 복잡성을 줄이고 노드 간에 일관된 동작을 보장합니다. App Service에서 수평으로 확장할 인스턴스를 추가하거나 제거할 수 있도록 고정 세션을 제거합니다. |
| App Service | 요청 수, 느린 요청, 메모리 제한 및 성능 기준의 일부인 기타 지표에 따라 자동 복구 규칙을 정의합니다. 크기 조정 전략의 일부로 이 구성을 고려합니다. | 자동 복구 규칙은 애플리케이션이 예기치 않은 문제로부터 자동으로 복구하는 데 도움이 됩니다. 구성된 규칙은 임계값을 위반할 때 복구 작업을 트리거합니다. 자동 복구를 사용하면 자동 자동 자동 관리 기본 테넌스를 사용할 수 있습니다. |
| App Service | 상태 검사 기능을 사용하도록 설정하고 상태 검사 요청에 응답하는 경로를 제공합니다. | 상태 검사 문제를 조기에 감지할 수 있습니다. 그러면 상태 검사 요청이 실패하면 시스템에서 자동으로 수정 작업을 수행할 수 있습니다. 부하 분산 장치는 비정상 인스턴스에서 트래픽을 라우팅하여 사용자를 정상 노드로 안내합니다. |
보안
보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보장을 제공하는 것입니다.
보안 디자인 원칙은 App Service 호스팅과 관련된 기술 디자인에 접근 방식을 적용하여 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
보안에 대한 디자인 검토 검사 목록에 따라 디자인 전략을 시작하고 취약성 및 컨트롤을 식별하여 보안 상태를 개선합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.
보안 기준 검토: App Service 계획에서 호스트되는 애플리케이션의 보안 상태를 향상하려면 App Service의 보안 기준을 검토합니다.
최신 런타임 및 라이브러리 사용: 업데이트를 수행하기 전에 애플리케이션 빌드를 철저히 테스트하여 문제를 조기에 파악하고 새 버전으로 원활하게 전환할 수 있도록 합니다. App Service는 기존 스택을 업데이트하고 지원 종료 스택을 사용 중지하기 위한 언어 런타임 지원 정책을 지원합니다.
격리 경계를 통해 구분을 만들어 위반을 포함합니다. ID 구분을 적용합니다. 예를 들어 RBAC(역할 기반 액세스 제어)를 구현하여 역할에 따라 특정 권한을 할당합니다. 최소 권한 원칙에 따라 액세스 권한을 필요한 권한으로만 제한합니다. 또한 네트워크 수준에서 분할을 만듭니다. 격리를 위해 Azure 가상 네트워크에 App Service 앱을 삽입하고 트래픽을 필터링하는 NSG(네트워크 보안 그룹)를 정의합니다.
App Service 계획은 높은 수준의 격리를 제공하는 App Service Environment 계층을 제공합니다. App Service Environment를 사용하면 전용 컴퓨팅 및 네트워킹을 얻을 수 있습니다.
ID에 액세스 제어 적용: 웹앱에 대한 내부 액세스와 웹앱에서 다른 리소스로의 외부 액세스를 모두 제한합니다. 이 구성은 ID에 대한 액세스 제어를 적용하고 워크로드의 전반적인 보안 상태를 기본 데 도움이 됩니다.
모든 인증 및 권한 부여 요구 사항에 대해 Microsoft Entra ID를 사용합니다. 웹 계획 참가자, 웹 사이트 참가자 및 일반 참가자, 읽기 권한자 및 소유자와 같은 기본 제공 역할을 사용합니다.
애플리케이션 간 네트워크 트래픽 제어: 공용 인터넷에 애플리케이션 엔드포인트를 노출하지 마세요. 대신 전용 서브넷에 배치되는 웹앱에 프라이빗 엔드포인트를 추가합니다. 해당 프라이빗 엔드포인트와 통신하는 역방향 프록시를 사용하여 애플리케이션을 프런트합니다. 이러한 용도로 Application Gateway 또는 Azure Front Door를 사용하는 것이 좋습니다.
일반적인 취약성으로부터 보호하기 위해 WAF(웹 애플리케이션 방화벽)를 배포합니다. Application Gateway와 Azure Front Door에는 WAF 기능이 통합되어 있습니다.
원하는 수준의 보안 및 제어를 달성하도록 역방향 프록시 규칙 및 네트워크 설정을 적절하게 구성합니다. 예를 들어 프라이빗 엔드포인트 서브넷에 NSG 규칙을 추가하여 역방향 프록시의 트래픽만 허용합니다.
애플리케이션에서 다른 PaaS 서비스로의 송신 트래픽은 프라이빗 엔드포인트를 통해야 합니다. 공용 인터넷으로 송신 트래픽을 제한하는 방화벽 구성 요소를 배치하는 것이 좋습니다. 두 방법 모두 데이터 반출을 방지합니다.
포괄적인 보기는 App Service 네트워킹 기능을 참조 하세요.
데이터 암호화: TLS(엔드투엔드 전송 계층 보안)를 사용하여 전송 중인 데이터를 보호합니다. 미사용 데이터의 전체 암호화를 위해 고객 관리형 키를 사용합니다. 자세한 내용은 고객 관리형 키를 사용하여 미사용 데이터 암호화를 참조 하세요.
TLS 1.0 및 1.1과 같은 레거시 프로토콜을 사용하지 마세요. App Service는 기본적으로 1.2를 사용하도록 설정합니다. 자세한 내용은 App Service TLS 개요를 참조 하세요.
App Service의 모든 인스턴스에는 기본 do기본 이름이 있습니다. 사용자 지정 작업을 사용하고기본 인증서를 사용하여 보안을 기본.
공격 노출 영역 줄이기: 필요하지 않은 기본 구성을 제거합니다. 예를 들어 원격 디버깅, SCM(Source Control Manager) 사이트에 대한 로컬 인증 및 기본 인증을 사용하지 않도록 설정합니다. HTTP 및 FTP(파일 전송 프로토콜)와 같은 안전하지 않은 프로토콜을 사용하지 않도록 설정합니다. Azure 정책을 통해 구성을 적용합니다. 자세한 내용은 Azure 정책을 참조하세요.
CORS(제한적인 원본 간 리소스 공유) 정책 구현: 웹앱에서 제한적인 CORS 정책을 사용하여 허용된 작업기본, 헤더 및 기타 조건의 요청만 수락합니다. 기본 제공 Azure 정책 정의를 사용하여 CORS 정책을 적용합니다.
애플리케이션 비밀 보호: API 키 또는 인증 토큰과 같은 중요한 정보를 처리해야 합니다. 이러한 비밀을 애플리케이션 코드 또는 구성 파일에 직접 하드 코딩하는 대신 앱 설정에서 Azure Key Vault 참조를 사용할 수 있습니다. 애플리케이션이 시작되면 App Service는 앱의 관리 ID를 사용하여 Key Vault에서 비밀 값을 자동으로 검색합니다.
애플리케이션에 대한 리소스 로그 사용: 애플리케이션에 대한 리소스 로그를 사용하도록 설정하여 보안 인시던트를 따르는 조사 중에 중요한 데이터를 제공하는 포괄적인 활동 내역을 만들 수 있습니다.
위협을 평가할 때 위협 모델링 프로세스의 일부로 로깅을 고려합니다.
권장 사항
| 서비스 또는 계획 | 추천 | 장점 |
|---|---|---|
| App Service | 웹앱에 관리 ID를 할당합니다 . 격리 경계를 기본 위해 애플리케이션 간에 ID를 공유하거나 다시 사용하지 마세요. 배포에 컨테이너를 사용하는 경우 컨테이너 레지스트리에 안전하게 연결해야 합니다. |
애플리케이션은 Key Vault에서 비밀을 검색하여 애플리케이션에서 외부 통신을 인증합니다. Azure는 ID를 관리하며 비밀을 프로비전하거나 회전할 필요가 없습니다. 컨트롤의 세분성을 위한 고유 ID가 있습니다. ID가 손상된 경우 고유 ID를 사용하면 해지를 쉽게 수행할 수 있습니다. |
| App Service | 애플리케이션에 대한 사용자 지정 do기본를 구성합니다. HTTP를 사용하지 않도록 설정하고 HTTPS 요청만 수락합니다. |
사용자 지정 do기본s는 SSL(Secure Sockets Layer) 또는 TLS 프로토콜을 사용하여 HTTPS를 통해 보안 통신을 사용하도록 설정하여 중요한 데이터의 보호를 보장하고 사용자 신뢰를 구축합니다. |
| App Service | App Service 기본 제공 인증이 애플리케이션에 액세스하는 사용자를 인증하는 올바른 메커니즘인지 여부를 평가합니다. App Service 기본 제공 인증은 Microsoft Entra ID와 통합됩니다. 이 기능은 여러 로그인 공급자에서 토큰 유효성 검사 및 사용자 ID 관리를 처리하고 OpenID 커넥트 지원합니다. 이 기능을 사용하면 세분화된 수준에서 권한 부여가 없으며 인증을 테스트하는 메커니즘이 없습니다. | 이 기능을 사용하는 경우 애플리케이션 코드에서 인증 라이브러리를 사용할 필요가 없으므로 복잡성이 줄어듭니다. 요청이 애플리케이션에 도달하면 사용자가 이미 인증됩니다. |
| App Service | 가상 네트워크 통합을 위해 애플리케이션을 구성합니다. App Service 앱에 프라이빗 엔드포인트를 사용합니다. 모든 공용 트래픽을 차단합니다. 가상 네트워크 통합을 통해 컨테이너 이미지 끌어오기를 라우팅합니다. 애플리케이션에서 나가는 모든 트래픽은 가상 네트워크를 통과합니다. |
Azure 가상 네트워크를 사용할 때의 보안 이점을 얻을 수 있습니다. 예를 들어 애플리케이션은 네트워크 내의 리소스에 안전하게 액세스할 수 있습니다. 애플리케이션을 보호하는 데 도움이 되는 프라이빗 엔드포인트를 추가합니다. 프라이빗 엔드포인트는 공용 네트워크에 대한 직접 노출을 제한하고 역방향 프록시를 통해 제어된 액세스를 허용합니다. |
| App Service | 강화를 구현하려면 다음을 수행합니다. - Microsoft Entra ID 기반 인증 을 위해 사용자 이름과 암호를 사용하는 기본 인증을 사용하지 않도록 설정합니다. - 인바운드 포트가 열리지 않도록 원격 디버깅을 끕니다. - CORS 정책을 사용하여 들어오는 요청을 강화합니다. - FTP와 같은 프로토콜을 사용하지 않도록 설정합니다. |
보안 배포 방법으로 기본 인증을 권장하지 않습니다. Microsoft Entra ID는 OAuth 2.0 토큰 기반 인증을 사용합니다. 이 인증은 기본 인증과 관련된 제한 사항을 해결하는 다양한 이점과 향상된 기능을 제공합니다. 정책은 애플리케이션 리소스에 대한 액세스를 제한하고, 특정 기본 요청만 허용하며, 지역 간 요청을 보호합니다. |
| App Service | 항상 Key Vault 참조를 앱 설정으로 사용합니다. |
비밀은 앱의 구성과 별도로 유지됩니다. 앱 설정은 미사용 시 암호화됩니다. App Service는 비밀 회전도 관리합니다. |
| App Service 계획 | App Service에 클라우드용 Microsoft Defender 사용하도록 설정합니다. | App Service 계획에서 실행되는 리소스에 대한 실시간 보호를 가져옵니다. 위협을 방지하고 전반적인 보안 태세를 강화합니다. |
| App Service 계획 | 진단 로깅 을 사용하도록 설정하고 앱에 계측을 추가합니다. 로그는 Azure Storage 계정, Azure Event Hubs 및 Log Analytics로 전송됩니다. 감사 로그 유형에 대한 자세한 내용은 지원되는 로그 유형을 참조 하세요. | 로깅은 액세스 패턴을 캡처합니다. 사용자가 애플리케이션 또는 플랫폼과 상호 작용하는 방법에 대한 중요한 인사이트를 제공하는 관련 이벤트를 기록합니다. 이 정보는 책임, 규정 준수 및 보안 목적에 매우 중요합니다. |
비용 최적화
비용 최적화는 비즈니스 요구 사항을 충족하면서 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.
비용 최적화 디자인 원칙은 이러한 목표를 달성하고 웹앱 및 웹앱이 실행되는 환경과 관련된 기술 디자인에서 필요에 따라 장단점이 되는 고급 디자인 전략을 제공합니다.
디자인 검사 목록
투자 비용 최적화를 위한 디자인 검토 검사 목록에 따라 디자인 전략을 시작하고 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.
초기 비용 예측: 비용 모델링 연습의 일환으로 Azure 가격 계산기를 사용하여 실행하려는 인스턴스 수에 따라 다양한 계층과 관련된 대략적인 비용을 평가합니다. 각 App Service 계층은 다양한 컴퓨팅 옵션을 제공합니다.
비용 모델을 지속적으로 모니터링하여 지출을 추적합니다.
할인된 옵션 평가: 상위 계층에는 전용 컴퓨팅 인스턴스가 포함됩니다. 워크로드에 예측 가능하고 일관된 사용 패턴이 있는 경우 예약 할인을 적용할 수 있습니다. 사용량 현황 데이터를 분석하여 워크로드에 적합한 예약 유형을 결정해야 합니다. 자세한 내용은 App Service 예약 인스턴스를 사용하여 비용 절감을 참조 하세요.
사용량 미터 이해: Azure는 App Service 플랜의 가격 책정 계층에 따라 두 번째로 비례 배분된 시간당 요금을 청구합니다. 요금은 VM 인스턴스를 할당하는 시간에 따라 계획의 각 스케일 아웃 인스턴스에 적용됩니다. 최적이 아닐 SKU 선택 또는 제대로 구성되지 않은 스케일 인 구성으로 인해 초과 할당으로 인해 비용이 증가할 수 있는 사용되지 않는 컴퓨팅 리소스에 주의하세요.
사용자 지정 작업기본 등록 및 사용자 지정 인증서와 같은 추가 App Service 기능은 비용을 추가할 수 있습니다. 워크로드 비밀을 보호하기 위해 솔루션 또는 키 자격 증명 모음을 격리하는 가상 네트워크와 같은 다른 리소스는 App Service 리소스와 통합되어 비용을 추가할 수도 있습니다. 자세한 내용은 App Services 청구 모델을 참조하세요.
밀도와 격리 간의 절충을 고려합니다. App Service 계획을 사용하여 동일한 컴퓨팅에서 여러 애플리케이션을 호스팅하여 공유 환경으로 비용을 절감할 수 있습니다. 자세한 내용은 절충을 참조 하세요.
비용에 대한 크기 조정 전략의 효과를 평가합니다. 자동 크기 조정을 구현할 때 스케일 아웃 및 스케일 인을 위해 적절하게 디자인, 테스트 및 구성해야 합니다. 자동 크기 조정에 대한 정확한 최대 및 최소 제한을 설정합니다.
안정적인 크기 조정을 위해 애플리케이션을 사전에 초기화합니다. 예를 들어 CPU 사용량이 95%에 도달할 때까지 기다리지 마세요. 대신 크기 조정 프로세스 중에 새 인스턴스를 할당하고 초기화하는 데 충분한 시간을 허용하도록 약 65%의 크기 조정을 트리거합니다. 그러나 이 전략은 사용되지 않는 용량으로 이어질 수 있습니다.
스케일 업 및 스케일 아웃을 위한 메커니즘을 결합하고 균형을 맞추는 것이 좋습니다. 예를 들어 앱은 일정 시간 동안 확장한 다음 필요에 따라 확장할 수 있습니다. 대용량 및 효율적인 리소스 사용을 제공하는 상위 계층을 살펴봅니다. 사용 패턴에 따라 더 높은 프리미엄 계층은 더 많은 기능을 하므로 비용 효율적인 경우가 많습니다.
환경 비용 최적화: 사전 프로덕션 환경을 실행하려면 기본 또는 무료 계층을 고려합니다. 이러한 계층은 낮은 성능과 저렴한 비용입니다. 기본 또는 무료 계층을 사용하는 경우 거버넌스를 사용하여 계층을 적용하고, 인스턴스 및 CPU 수를 제한하고, 크기 조정을 제한하고, 로그 보존을 제한합니다.
디자인 패턴 구현: 이 전략은 워크로드가 생성하는 요청의 양을 줄입니다. 요청 수를 최소화하고 비용을 줄일 수 있는 프런트 엔드 패턴 및 게이트웨이 집계 패턴과 같은 패턴을 사용하는 것이 좋습니다.
데이터 관련 비용을 정기적으로 검사: 확장된 데이터 보존 기간 또는 비용이 많이 드는 스토리지 계층으로 인해 스토리지 비용이 높아질 수 있습니다. 대역폭 사용량과 로깅 데이터의 장기간 보존으로 인해 더 많은 비용이 누적될 수 있습니다.
데이터 전송 비용을 최소화하기 위해 캐싱을 구현하는 것이 좋습니다. 로컬 메모리 내 캐싱으로 시작한 다음 분산 캐싱 옵션을 탐색하여 백 엔드 데이터베이스에 대한 요청 수를 줄입니다. 데이터베이스가 다른 지역에 있는 경우 지역 간 통신과 연결된 대역폭 트래픽 비용을 고려합니다.
배포 비용 최적화: 배포 슬롯을 활용하여 비용을 최적화합니다. 슬롯은 프로덕션 인스턴스와 동일한 컴퓨팅 환경에서 실행됩니다. 슬롯 간에 전환하는 청록색 배포와 같은 시나리오에 전략적으로 사용합니다. 이 방법은 가동 중지 시간을 최소화하고 원활한 전환을 보장합니다.
배포 슬롯을 주의해서 사용합니다. 기존 인스턴스와 새 인스턴스 모두에 영향을 줄 수 있는 예외 또는 메모리 누수와 같은 문제를 도입할 수 있습니다. 변경 내용을 철저히 테스트해야 합니다. 운영 지침은 운영 우수성을 참조하세요.
권장 사항
| 서비스 또는 계획 | 추천 | 장점 |
|---|---|---|
| App Service 계획 | 하위 환경에 대해 무료 또는 기본 계층을 선택합니다. 실험적 사용을 위해 이러한 계층을 사용하는 것이 좋습니다. 계층이 더 이상 필요하지 않은 경우 제거합니다. | 무료 및 기본 계층은 상위 계층에 비해 예산 친화적입니다. 프리미엄 플랜의 전체 기능과 성능이 필요하지 않은 비프로덕션 환경에 대한 비용 효율적인 솔루션을 제공합니다. |
| App Service 계획 | 할인을 활용하고 다음을 위한 기본 가격 책정을 살펴보세요. - 개발/테스트 계획을 사용하는 낮은 환경. - 프리미엄 V3 계층 및 App Service Environment에서 프로비전하는 전용 컴퓨팅에 대한 Azure 예약 및 Azure 절감 플랜입니다. 예측 가능한 사용 패턴이 있는 안정적인 워크로드에 예약 인스턴스를 사용합니다. |
개발/테스트 계획은 Azure 서비스에 대해 할인된 요금을 제공하므로 비프로덕션 환경에 비용 효율적입니다. 예약 인스턴스를 사용하여 컴퓨팅 리소스에 대한 선불을 제공하고 상당한 할인을 받습니다. |
| App Service | App Service 리소스에서 발생하는 비용을 모니터링합니다. Azure Portal에서 비용 분석 도구를 실행합니다. 관련자에게 알리는 예산 및 경고를 만듭니다. |
비용 급증, 비효율성 또는 예기치 않은 비용을 초기에 식별할 수 있습니다. 이러한 사전 예방적 접근 방식을 통해 초과 지출을 방지하기 위한 예산 제어를 제공할 수 있습니다. |
| App Service 계획 | 수요가 감소할 때 스케일 인합니다. 규모를 확장하려면 Azure Monitor의 인스턴스 수를 줄이는 크기 조정 규칙을 정의합니다. | 낭비를 방지하고 불필요한 비용을 줄입니다. |
운영 우수성
운영 우수성은 주로 개발 관행, 관찰성 및 릴리스 관리를 위한 절차에 중점을 둡니다.
운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
Web Apps와 관련된 관찰성, 테스트 및 배포에 대한 프로세스를 정의하기 위한 디자인 검토 검사 운영 우수성 목록에 따라 디자인 전략을 시작합니다.
릴리스 관리: 배포 슬롯을 사용하여 릴리스를 효과적으로 관리합니다. 슬롯에 애플리케이션을 배포하고, 테스트를 수행하고, 해당 기능의 유효성을 검사할 수 있습니다. 확인 후 앱을 프로덕션으로 원활하게 이동할 수 있습니다. 슬롯이 프로덕션 인스턴스와 동일한 VM(가상 머신) 환경에서 실행되므로 이 프로세스에는 추가 비용이 발생하지 않습니다.
자동화된 테스트 실행: 웹앱의 릴리스를 승격하기 전에 성능, 기능 및 다른 구성 요소와의 통합을 철저히 테스트합니다. 성능 테스트에 널리 사용되는 도구인 Apache JMeter와 통합되는 Azure Load Testing을 사용합니다. 기능 테스트를 위한 가상과 같은 다른 유형의 테스트를 위한 자동화된 도구를 탐색합니다.
변경할 수 없는 단위 배포: 배포 스탬프 패턴을 구현하여 App Service를 변경할 수 없는 스탬프로 구획합니다. App Service는 기본적으로 변경할 수 없는 컨테이너 사용을 지원합니다. App Service 웹앱에 대한 사용자 지정 컨테이너를 고려합니다.
각 스탬프는 신속하게 스케일 아웃하거나 스케일 인할 수 있는 자체 포함 단위를 나타냅니다. 이 스탬프를 기반으로 하는 단위는 일시적이고 상태 비국적입니다. 상태 비지정 디자인은 작업 및 기본 테넌스를 간소화합니다. 이 방법은 중요 업무용 애플리케이션에 적합합니다. 예를 들어 App Service를 사용하는 중요 업무용 기준을 참조 하세요.
Bicep과 같은 IaC(Infrastructure as Code) 기술을 사용하여 반복성 및 일관성이 있는 단위를 스탬프 아웃합니다.
프로덕션 환경을 안전하게 유지: 프로덕션 및 사전 프로덕션 환경을 실행하기 위한 별도의 App Service 계획을 만듭니다. 안정성과 안정성을 보장하기 위해 프로덕션 환경에서 직접 변경하지 마세요. 별도의 인스턴스를 사용하면 프로덕션으로 변경 내용을 승격하기 전에 개발 및 테스트의 유연성을 활용할 수 있습니다.
낮은 환경을 사용하여 격리된 방식으로 새 기능 및 구성을 탐색합니다. 개발 및 테스트 환경을 임시로 유지합니다.
인증서 관리: 사용자 지정 기본 경우 TLS 인증서를 관리해야 합니다.
인증서를 조달, 갱신 및 유효성 검사하는 프로세스가 마련되어 있습니다. 가능하면 이러한 프로세스를 App Service로 오프로드합니다. 사용자 고유의 인증서를 사용하는 경우 갱신을 관리해야 합니다. 보안 요구 사항에 가장 적합한 방법을 선택합니다.
| 서비스 또는 계획 | 추천 | 장점 |
|---|---|---|
| App Service | 인스턴스의 상태를 모니터링하고 인스턴스 상태 프로브를 활성화합니다. 상태 프로브 요청을 처리하기 위한 특정 경로를 설정합니다. |
문제를 즉시 감지하고 가용성 및 성능을 기본 위해 필요한 조치를 취할 수 있습니다. |
| App Service | 애플리케이션 및 인스턴스에 대한 진단 로그를 사용하도록 설정합니다. 자주 로깅하면 시스템 성능이 저하되고, 스토리지 비용이 추가되며, 로그에 대한 안전하지 않은 액세스 권한이 있는 경우 위험이 발생할 수 있습니다. 다음 모범 사례를 따릅니다. - 적절한 수준의 정보를 기록합니다. - 보존 정책을 설정합니다. - 권한 있는 액세스 및 무단 시도의 감사 내역을 유지합니다. - 로그를 데이터로 처리하고 데이터 보호 컨트롤을 적용합니다. |
진단 로그는 앱의 동작에 대한 중요한 인사이트를 제공합니다. 트래픽 패턴을 모니터링하고 변칙을 식별합니다. |
| App Service | App Service 관리 인증서를 활용하여 인증 관리를 Azure로 오프로드합니다 . | App Service는 인증서 조달, 인증서 확인, 인증서 갱신 및 Key Vault에서 인증서 가져오기와 같은 프로세스를 자동으로 처리합니다. 또는 Key Vault에 인증서를 업로드하고 App Service 리소스 공급자에게 액세스 권한을 부여합니다. |
| App Service 계획 | 프로덕션 슬롯과 교환하기 전에 스테이징 슬롯 에서 앱 변경 내용의 유효성을 검사합니다. | 가동 중지 시간 및 오류를 방지합니다. 교환 후 문제를 감지하면 마지막으로 알려진 정상 상태로 신속하게 되돌리기. |
성능 효율성
성능 효율성은 용량을 관리하여 부하가 증가하는 경우에도 사용자 환경을 기본 파악하는 것입니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.
성능 효율성 디자인 원칙은 예상된 사용량에 대해 이러한 용량 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.
디자인 검사 목록
Web Apps의 주요 성능 지표를 기반으로 기준을 정의하기 위한 성능 효율성에 대한 디자인 검토 검사 목록에 따라 디자인 전략을 시작합니다.
성능 지표 식별 및 모니터링: 들어오는 요청의 양, 애플리케이션이 요청에 응답하는 데 걸리는 시간, 보류 중인 요청 및 HTTP 응답의 오류와 같은 애플리케이션의 주요 지표에 대한 대상을 설정합니다. 주요 지표를 워크로드에 대한 성능 기준의 일부로 고려합니다.
성능 지표의 기초를 형성하는 App Service 메트릭을 캡처합니다. 로그를 수집하여 리소스 사용량 및 활동에 대한 인사이트를 얻습니다. Application Insights와 같은 APM(애플리케이션 성능 모니터링) 도구를 사용하여 애플리케이션에서 성능 데이터를 수집하고 분석합니다. 자세한 내용은 App Service 모니터링 데이터 참조를 참조하세요.
코드 수준 계측, 트랜잭션 추적 및 성능 프로파일링을 포함합니다.
용량 평가: 다양한 사용자 시나리오를 시뮬레이션하여 예상 트래픽을 처리하는 데 필요한 최적의 용량을 결정합니다. 부하 테스트를 사용하여 애플리케이션이 다양한 부하 수준에서 동작하는 방식을 이해합니다.
올바른 계층을 선택합니다. 프로덕션 워크로드에 전용 컴퓨팅을 사용합니다. 프리미엄 계층은 메모리 및 CPU 용량 증가, 더 많은 인스턴스 및 영역 중복과 같은 더 많은 기능을 갖춘 더 큰 SKU를 제공합니다. 자세한 내용은 Premium V3 가격 책정 계층을 참조 하세요.
크기 조정 전략 최적화: 가능하면 애플리케이션 부하가 변경되면 인스턴스 수를 수동으로 조정하는 대신 자동 크기 조정을 사용합니다. 자동 크기 조정을 통해 App Service는 미리 정의된 규칙 또는 트리거에 따라 서버 용량을 조정합니다. 적절한 성능 테스트를 수행하고 올바른 트리거에 대한 올바른 규칙을 설정해야 합니다.
초기 설치 중에 단순성을 우선 순위를 지정하는 경우 규칙을 정의할 필요가 없고 제한만 설정해야 하는 자동 크기 조정 옵션을 사용합니다.
최적의 성능을 보장하기 위해 쉽게 사용할 수 있는 충분한 리소스가 있습니다. 응답 시간 또는 처리량과 같은 성능 목표를 기본 위해 리소스를 적절하게 할당합니다. 필요한 경우 리소스를 초과 할당하는 것이 좋습니다.
자동 크기 조정 규칙을 정의할 때 애플리케이션을 초기화하는 데 걸리는 시간을 고려합니다. 모든 크기 조정 결정을 내릴 때 이 오버헤드를 고려합니다.
캐싱 사용: 자주 변경되지 않고 액세스 비용이 많이 드는 리소스에서 정보를 검색하면 성능에 영향을 줍니다. 조인 및 여러 조회를 비롯한 복잡한 쿼리는 런타임에 영향을 줍니다. 캐싱을 수행하여 처리 시간과 대기 시간을 최소화합니다. 쿼리 결과를 캐시하여 데이터베이스 또는 백 엔드에 대한 반복적인 왕복을 방지하고 후속 요청에 대한 처리 시간을 줄입니다.
워크로드에서 로컬 및 분산 캐시를 사용하는 방법에 대한 자세한 내용은 캐싱을 참조하세요.
성능 안티패턴 검토: 웹 애플리케이션이 비즈니스 요구 사항에 따라 수행 및 스케일링되도록 하려면 일반적인 안티패턴을 피하십시오. 다음은 App Service에서 수정하는 몇 가지 안티패턴입니다.
안티패턴(Antipattern) 설명 사용량이 많은 프런트 엔드 리소스를 많이 사용하는 작업은 사용자 요청에 대한 응답 시간을 늘리고 대기 시간이 높아질 수 있습니다.
중요한 리소스를 사용하는 프로세스를 별도의 백 엔드로 이동합니다. 메시지 브로커를 사용하여 백 엔드가 비동기적으로 처리하는 리소스 집약적 작업을 큐에 추가합니다.캐싱 없음 대기 시간을 줄이기 위해 백 엔드 데이터베이스 앞에 있는 중간 캐시에서 요청을 제공합니다. 노이즈 네이버 다중 테넌트 시스템은 테넌트 간에 리소스를 공유합니다. 한 테넌트의 활동은 다른 테넌트의 시스템 사용에 부정적인 영향을 미칠 수 있습니다. App Service Environment는 완전히 격리된 전용 환경을 제공하여 App Service 앱을 실행합니다.
권장 사항
| 추천 | 장점 |
|---|---|
| 애플리케이션이 단일 App Service 계획을 공유할 때 Always On 설정을 사용하도록 설정합니다 . App Service 앱은 유휴 상태일 때 자동으로 언로드하여 리소스를 저장합니다. 다음 요청은 콜드 시작을 트리거하므로 요청 시간 제한이 발생할 수 있습니다. | 애플리케이션은 Always On을 사용하도록 설정된 상태로 언로드되지 않습니다. |
| 프로토콜 효율성을 개선하기 위해 애플리케이션에 HTTP/2 를 사용하는 것이 좋습니다. | HTTP/2는 연결을 완전히 멀티플렉싱하고, 연결을 다시 사용하여 오버헤드를 줄이고, 헤더를 압축하여 데이터 전송을 최소화하기 때문에 HTTP/1.1을 통해 HTTP/2를 선택합니다. |
균형 유지
핵심 검사 목록의 접근 방식을 사용하는 경우 디자인이 절충될 수 있습니다. 다음은 장점과 단점의 몇 가지 예입니다.
밀도
동일한 App Service 계획 내에 여러 앱을 공동 배치하여 리소스를 최소화합니다. 모든 앱은 CPU 및 메모리와 같은 리소스를 공유하므로 비용을 절감하고 운영 복잡성을 줄일 수 있습니다. 이 방법은 리소스 사용도 최적화합니다. 로드 패턴이 시간이 지남에 따라 변경되는 경우 앱은 다른 앱의 유휴 리소스를 사용할 수 있습니다.
또한 단점을 고려합니다. 예를 들어 앱의 사용량 급증 또는 불안정은 다른 앱의 성능에 영향을 줄 수 있습니다. 한 앱의 인시던트가 공유 환경 내의 다른 앱에 스며 들어 보안에 영향을 줄 수 있습니다.
격리
격리는 간섭을 방지하는 데 도움이 됩니다. 이 전략은 개발, 테스트 및 프로덕션 환경의 보안, 성능 및 분리에도 적용됩니다.
App Service Environment는 각 앱에 자체 보안 설정이 있을 수 있으므로 보안 및 데이터 보호를 보다 효율적으로 제어할 수 있습니다. 격리는 폭발 반경을 제한하므로 환경에 위반이 포함될 수 있습니다. 리소스 경합은 성능 관점에서 최소화됩니다. 격리를 사용하면 특정 수요 및 개별 용량 계획에 따라 독립적인 크기 조정이 가능합니다.
단점으로, 이 방법은 비용이 더 많이 들고 운영이 엄격해야 합니다.
신뢰할 수 있는 크기 조정 전략
잘 정의된 크기 조정 전략을 사용하면 애플리케이션이 성능 저하 없이 다양한 부하를 처리할 수 있습니다. 그러나 비용에 대한 절충이 있습니다. 크기 조정 작업에는 시간이 소요됩니다. 새 리소스가 할당되면 애플리케이션을 제대로 초기화해야 요청을 효과적으로 처리할 수 있습니다. 리소스(전전 인스턴스)를 과도하게 프로비전하여 안전망을 제공할 수 있습니다. 이러한 추가 용량이 없으면 초기화 단계에서 요청 제공이 지연되어 사용자 환경에 영향을 줄 수 있습니다. 자동 크기 조정 작업은 고객이 리소스를 사용할 때까지 적절한 리소스 초기화를 사용할 수 있을 만큼 일찍 트리거될 수 있습니다.
단점으로, 과도하게 프로비전된 리소스는 더 많은 비용이 듭니다. 미리 준비 인스턴스를 포함하여 모든 인스턴스에 대해 초당 요금이 청구됩니다. 상위 계층에는 미리 설치된 인스턴스가 포함됩니다. 더 비싼 계층의 기능이 투자 가치가 있는지 여부를 결정합니다.
중복성 구축
중복성은 복원력을 제공하지만 비용이 발생합니다. 워크로드에 대한 SLO(서비스 수준 목표)는 허용되는 성능 임계값을 결정합니다. 중복성이 SLO 요구 사항을 초과하면 낭비됩니다. 초과 중복성이 SLO를 향상시키거나 불필요한 복잡성을 더하는지 평가합니다.
또한 단점을 고려합니다. 예를 들어 다중 지역 중복성은 고가용성을 제공하지만 데이터 동기화, 장애 조치(failover) 메커니즘 및 지역 간 통신으로 인해 복잡성과 비용이 추가됩니다. 영역 중복이 SLO를 충족할 수 있는지 확인합니다.
Azure 정책
Azure는 App Service 및 해당 종속성과 관련된 광범위한 기본 제공 정책 집합을 제공합니다. Azure 정책 집합은 이전 권장 사항 중 일부를 감사할 수 있습니다. 예를 들어 다음 여부를 검사 수 있습니다.
적절한 네트워크 컨트롤이 있습니다. 예를 들어 가상 네트워크 주입을 통해 Azure Virtual Network에 App Service를 배치하여 네트워크 분할을 통합하여 네트워크 구성을 보다 잘 제어할 수 있습니다. 애플리케이션에는 퍼블릭 엔드포인트가 없으며 프라이빗 엔드포인트를 통해 Azure 서비스에 연결됩니다.
ID 컨트롤이 있습니다. 예를 들어 애플리케이션은 관리 ID를 사용하여 다른 리소스에 대해 자신을 인증합니다. App Service 기본 제공 인증은 들어오는 요청을 확인합니다.
원격 디버깅 및 기본 인증과 같은 기능을 사용하지 않도록 설정하여 공격 노출 영역을 줄일 수 있습니다.
포괄적인 거버넌스를 위해 컴퓨팅 계층의 보안에 영향을 줄 수 있는 Azure Policy 기본 제공 정의 및 기타 정책을 검토합니다.
Azure Advisor 권장 사항
Azure Advisor 는 Azure 배포를 최적화하기 위한 모범 사례를 따르는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다. 다음은 웹 애플리케이션 인스턴스의 안정성, 보안, 비용 효율성, 성능 및 운영 우수성을 개선하는 데 도움이 되는 몇 가지 권장 사항입니다.
다음 단계
다음 문서를 이 문서에서 강조 표시된 권장 사항을 보여 주는 리소스로 간주합니다.
이러한 참조 아키텍처를 워크로드에 이러한 권장 사항을 적용하는 방법의 예로 사용합니다.
다음 제품 설명서를 사용하여 구현 전문 지식을 구축합니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기