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