이 문서에서는 단일 지역에서 Azure App Service 웹 애플리케이션을 실행하는 방법을 배울 수 있는 기본 아키텍처를 제공합니다.
중요합니다
이 아키텍처는 프로덕션 애플리케이션을 위한 것이 아닙니다. POC(학습 및 개념 증명) 목적을 위한 소개 설정 역할을 합니다. 프로덕션 App Service 애플리케이션을 설계하려면 기준 높은 가용성 영역 중복 웹 애플리케이션을 참조하세요.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
다음 워크플로는 이전 다이어그램에 해당합니다.
사용자가 App Service 기본 도메인에 대한 HTTPS 요청을 실행합니다
azurewebsites.net. 이 도메인은 App Service 애플리케이션의 기본 제공 공용 IP 주소를 자동으로 가리킵니다. TLS(전송 계층 보안) 연결은 클라이언트에서 App Service로 직접 설정됩니다. Azure 인증서를 완전히 관리합니다.App Service의 기능인 간편한 인증은 사이트에 액세스하는 사용자가 Microsoft Entra ID 사용하여 인증되도록 합니다.
App Service에 배포된 애플리케이션 코드가 요청을 처리합니다. 예를 들어 해당 코드는 App Service에서 앱 설정으로 구성된 연결 문자열 사용하여 Azure SQL Database 인스턴스에 연결할 수 있습니다.
App Service에 대한 원래 요청 및 SQL Database 호출에 대한 정보는 Application Insights에 기록됩니다.
구성 요소
Microsoft Entra ID 는 인증 및 권한 부여 기능을 제공하는 클라우드 기반 ID 및 액세스 관리 서비스입니다. 이 아키텍처에서는 간편한 인증을 통해 App Service와 통합되어 웹 애플리케이션에 액세스하는 사용자에 대한 인증을 보장합니다. 또한 중요한 코드 변경 없이 인증 프로세스를 간소화합니다.
App Service 는 웹 애플리케이션을 빌드, 배포 및 크기 조정하기 위한 관리되는 플랫폼입니다. 이 아키텍처에서는 웹 애플리케이션 코드를 호스트하고, 기본
azurewebsites.net도메인에서 HTTPS 요청을 처리하며, 구성된 연결 문자열을 통해 SQL Database에 연결합니다.Azure Monitor 는 클라우드 및 온-프레미스 환경에서 원격 분석 데이터를 수집, 분석 및 작동하는 모니터링 서비스입니다. 이 아키텍처에서는 Application Insights 통합을 통해 App Service에 대한 요청 및 SQL Database 호출에 대한 정보를 캡처하고 저장합니다.
SQL Database 는 클라우드에서 SQL Server 기능을 제공하는 관리형 관계형 데이터베이스 서비스입니다. 이 아키텍처에서는 App Service 애플리케이션이 앱 설정에 정의된 연결 문자열을 통해 연결할 수 있도록 하는 데이터 스토리지 계층 역할을 합니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 개선하는 데 사용할 수 있는 지침 원칙 집합인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.
이 아키텍처에 나열된 구성 요소는 Well-Architected 서비스 가이드에 연결됩니다. 서비스 가이드는 특정 서비스에 대한 권장 사항 및 고려 사항을 자세히 설명합니다. 이 섹션에서는 이 아키텍처에 적용되는 주요 Well-Architected Framework 권장 사항 및 고려 사항을 강조 표시하여 해당 지침을 확장합니다.
이 기본 아키텍처는 평가 및 학습 목적으로만 설계되었습니다. 프로덕션 등급 기능보다 단순성과 비용 효율성의 우선 순위를 지정합니다. 다음 섹션에서는 이 아키텍처의 주요 제한 사항을 강조하고 보다 강력한 배포를 계획하는 데 도움이 되는 권장 사항 및 고려 사항을 제공합니다.
안정성
안정성은 애플리케이션이 고객에 대한 약정을 충족할 수 있도록 하는 데 도움이 됩니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.
이 아키텍처는 프로덕션 배포용으로 설계되지 않았습니다. 이 아키텍처에서는 다음과 같은 중요한 안정성 기능을 생략합니다.
App Service 계획은 Azure 가용성 영역 대한 지원을 포함하지 않는 표준 계층에 대해 구성됩니다. 인스턴스, 랙 또는 인스턴스를 호스트하는 데이터 센터에 문제가 발생하면 App Service를 사용할 수 없게 됩니다.
SQL Database는 영역 중복을 지원하지 않는 기본 계층에 대해 구성됩니다. 결과적으로 데이터는 Azure 가용성 영역에서 복제되지 않으므로 중단이 발생할 경우 커밋된 데이터가 손실될 위험이 있습니다.
대부분의 배포 기술에는 실행 중인 모든 인스턴스를 다시 시작해야 하므로 이 아키텍처에 배포하면 애플리케이션 배포에 가동 중지 시간이 발생할 수 있습니다. 이 프로세스 중에 사용자에게 503 오류가 발생할 수 있습니다. 이 배포 가동 중지 시간은
배포 슬롯을 통해 기준 아키텍처에서 해결됩니다. 동시 슬롯 배포를 지원하려면 신중한 애플리케이션 디자인, 스키마 관리 및 애플리케이션 구성 처리가 필요합니다. 이 POC를 사용하여 슬롯 기반 프로덕션 배포 방법을 디자인하고 유효성을 검사합니다. 이 기본 아키텍처에서는 자동 크기 조정을 사용할 수 없습니다. 컴퓨팅 리소스 부족으로 인한 안정성 문제를 방지하려면 최대 동시 수요를 처리할 수 있는 충분한 용량을 보장하기 위해 과도하게 프로비전해야 합니다.
이러한 안정성 문제를 극복하는 방법에 대한 자세한 내용은 가용성이 높은 영역 중복 웹 애플리케이션인 안정성 기준을 참조하세요.
워크로드에 다중 지역 활성-활성 또는 활성-수동 아키텍처가 필요한 경우 재해 복구를 위한 다중 지역 App Service 앱 접근 방식을 참조하세요.
보안
보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.
이 아키텍처는 프로덕션 배포용으로 설계되지 않았습니다. 다른 안정성 권장 사항 및 고려 사항과 함께 이 아키텍처에서 다음과 같은 중요한 보안 기능을 생략했습니다.
이 기본 아키텍처는 네트워크 개인 정보를 구현하지 않습니다. App Service 및 Azure SQL Server 같은 리소스에 대한 데이터 및 관리 평면은 공용 인터넷을 통해 연결할 수 있습니다. 프라이빗 네트워킹을 생략하면 아키텍처의 공격 노출 영역이 크게 증가합니다. 프라이빗 네트워킹을 구현하여 다음과 같은 보안 기능을 보장하는 방법에 대한 자세한 내용은 가용성이 높은 영역 중복 웹 애플리케이션인 네트워킹을 참조하세요. 프라이빗 네트워킹을 구현하면 다음과 같은 보안 기능을 제공하여 이러한 위험을 완화할 수 있습니다.
클라이언트 트래픽에 대한 단일 보안 진입점입니다.
네트워크 트래픽은 패킷 수준과 DDoS(분산 서비스 거부) 수준에서 모두 필터링됩니다.
데이터 반출은 Azure Private Link 사용하여 트래픽을 Azure 유지하여 최소화됩니다.
네트워크 리소스는 네트워크 분할을 통해 논리적으로 그룹화되고 서로 격리됩니다.
이 기본 아키텍처에는 Azure Web Application Firewall 배포가 포함되지 않습니다. 웹 애플리케이션은 일반적인 악용 및 취약성으로부터 보호되지 않습니다. App Services 아키텍처에서 Azure Application Gateway와 Azure Web Application Firewall을 구현하는 방법을 보려면 기본형 구현을 참조하세요.
이 기본 아키텍처는 앱 설정에 SQL Server 연결 문자열 같은 비밀을 저장합니다. 앱 설정은 기본적으로 암호화됩니다. 그러나 프로덕션으로 전환할 때는 향상된 거버넌스를 위해 비밀을 Azure Key Vault 저장하는 것이 좋습니다. 보안이 강화되고 비밀 관리 오버헤드가 감소하려면 연결 문자열에 비밀을 포함하는 대신 인증에 관리 ID를 사용하는 것이 좋습니다.
개발 또는 POC 단계에서 원격 디버깅 및 Kudu 엔드포인트를 계속 사용하도록 설정할 수 있습니다. 프로덕션으로 이동할 때 불필요한 제어 평면, 배포 또는 원격 액세스를 사용하지 않도록 설정해야 합니다.
FTP(파일 전송 프로토콜) 및 SCM(소스 제어 관리) 사이트 배포에 대한 로컬 인증 방법은 개발 또는 POC 단계에서 계속 사용할 수 있습니다. 프로덕션으로 이동하면 해당 엔드포인트에 대한 로컬 인증을 사용하지 않도록 설정해야 합니다.
POC 단계에서 App Service에 Microsoft Defender 사용하도록 설정할 필요가 없습니다. 프로덕션으로 이동하면 App Service에 대한 Defender 사용하도록 설정하여 보안 권장 사항을 생성해야 합니다. 이러한 권장 사항을 구현하여 보안 태세를 강화하고 App Service 배포에 대한 여러 위협을 감지해야 합니다.
App Service는 추가 비용 없이 하위 도메인
azurewebsites.net에 SSL(Secure Sockets Layer) 엔드포인트를 포함합니다. HTTP 요청은 기본적으로 HTTPS 엔드포인트로 리디렉션됩니다. 프로덕션 배포의 경우 사용자 지정 도메인은 일반적으로 App Service 배포 앞에서 Application Gateway 또는 API Management와 함께 사용됩니다.App Service에 대한 통합 인증 메커니즘을 사용합니다. 간편한 인증은 ID 공급자를 웹앱에 통합하는 프로세스를 간소화합니다. 웹앱 외부에서 인증을 처리하므로 중요한 코드를 변경할 필요가 없습니다.
워크로드 ID에 관리 ID를 사용합니다. 관리 ID를 통해 개발자는 이러한 인증 자격 증명을 관리할 필요가 없습니다. 기본 아키텍처는 연결 문자열 암호를 사용하여 SQL Server 인증합니다. 관리 ID를 사용하여 SQL Server 인증하는 것이 좋습니다.
자세한 내용은 App Service에서 앱 보안을 참조하세요.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화대한
이 아키텍처는 Well-Architected Framework의 다른 기둥과의 많은 절충을 통해 비용을 최적화합니다. 이러한 장차는 이 아키텍처의 학습 및 POC 목표에 맞게 특별히 만들어집니다. 기본 고가용성 영역 중복 웹 애플리케이션과 같은 프로덕션 준비 아키텍처에 비해 비용 절감은 주로 다음 선택 항목에서 비롯됩니다.
자동 크기 조정이 활성화되지 않은 단일 App Service 인스턴스
App Service의 표준 가격 책정 계층
사용자 지정 TLS 인증서 또는 고정 IP 주소 없음
WAF(웹 애플리케이션 방화벽) 없음
애플리케이션 배포를 위한 전용 스토리지 계정 없음
백업 보존 정책이 없는 SQL Database의 기본 가격 책정 계층
클라우드용 Microsoft Defender 구성 요소 없음
방화벽을 통한 네트워크 트래픽 송신 제어 없음
프라이빗 엔드포인트 없음
Azure Monitor 로그의 최소 로그 및 로그 보존 기간
이 아키텍처의 예상 비용을 보려면 이 아키텍처의 구성 요소를 사용하는 가격 계산기 추정치 를 참조하세요. 이 아키텍처의 비용은 일반적으로 Azure 개발/테스트 구독을 사용하여 더 줄일 수 있습니다. 이는 이와 같은 PC에 이상적인 구독 유형입니다.
운영 우수성
운영 우수성은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.
다음 섹션에서는 App Service 애플리케이션의 구성, 모니터링 및 배포에 대한 지침을 제공합니다.
앱 구성
기본 아키텍처는 프로덕션용이 아니므로 App Service 구성을 사용하여 구성 값과 비밀을 저장합니다. POC 단계 중에 App Service 구성에 비밀을 저장할 수 있습니다. 실제 비밀을 사용하지 않으며 프로덕션 워크로드에 필요한 비밀 거버넌스가 필요하지 않습니다.
다음 구성 권장 사항 및 고려 사항을 고려합니다.
먼저 App Service 구성을 사용하여 POC 배포에 구성 값 및 연결 문자열을 저장합니다. 앱 설정 및 연결 문자열은 앱이 시작될 때 앱에 삽입되기 직전에 암호화 및 암호 해독됩니다.
프로덕션으로 이동하면 비밀을 Key Vault 저장합니다. Key Vault 다음 두 가지 방법으로 비밀의 거버넌스를 개선합니다.
비밀을 Key Vault 외부화하면 보안 비밀 관리를 위한 중앙 집중식 단일 위치가 제공됩니다.
Key Vault 사용하면 비밀에 액세스할 때마다를 포함하여 비밀과의 모든 상호 작용을 기록할 수 있습니다.
프로덕션으로 이동하면 Key Vault 참조 사용하여 Key Vault 및 App Service 구성을 계속 사용할 수 있습니다.
컨테이너
기본 아키텍처를 사용하여 지원되는 코드를 Windows 또는 Linux 인스턴스에 직접 배포할 수 있습니다. 또는 App Service는 컨테이너화된 웹 애플리케이션을 실행하는 데 사용할 수 있는 컨테이너 호스팅 플랫폼이기도 합니다. App Service는 다양한 기본 제공 컨테이너를 제공합니다. 사용자 지정 또는 다중 컨테이너 앱은 런타임 환경을 미세 조정하거나 기본적으로 지원되지 않는 코드 언어를 지원하는 데 도움이 됩니다. 이 방법을 사용하려면 컨테이너 레지스트리를 도입해야 합니다.
제어 평면
POC 단계에서 Kudu 서비스를 통해 액세스할 수 있는 App Service 컨트롤 플레인을 숙지합니다. 이 서비스는 ZIP 배포와 같은 일반적인 배포 API를 제공하며 원시 로그 및 환경 변수를 노출합니다.
컨테이너를 사용하는 경우 고급 디버깅 기능을 지원하기 위해 컨테이너에 대한 SSH(Secure Shell) 세션을 여는 Kudu의 기능을 이해해야 합니다.
진단 및 모니터링
POC 단계에서는 캡처에 사용할 수 있는 로그 및 메트릭을 이해하는 것이 중요합니다. POC 단계에서 모니터링을 위한 다음 권장 사항 및 아이디어를 고려합니다.
모든 항목 로그 원본에 대한 진단 로깅을 사용하도록 설정합니다. 모든 진단 설정의 사용을 구성하면 기본적으로 제공되는 로그 및 메트릭을 이해하고 애플리케이션 코드에서 로깅 프레임워크를 사용하여 닫아야 하는 간격을 식별하는 데 도움이 됩니다. 프로덕션으로 이동하면 가치를 추가하지 않고 워크로드의 로그 싱크에 노이즈 및 비용을 추가하는 로그 원본을 제거합니다.
Azure Log Analytics를 사용하도록 로깅 구성 Azure Log Analytics 쉽게 쿼리할 수 있는 로깅을 중앙 집중화할 수 있는 확장 가능한 플랫폼을 제공합니다.
Application Insights 또는 다른 APM(애플리케이션 성능 관리) 도구를 사용하여 원격 분석 및 로그를 내보내 애플리케이션 성능을 모니터링합니다.
배포
다음 사항은 App Service 애플리케이션을 배포하는 방법에 대한 지침을 제공합니다.
Azure Pipelines를 사용하는 Azure Web Apps용 CI/CD의 지침에 따라 애플리케이션 배포를 자동화합니다. POC 단계에서 배포 논리 빌드를 시작합니다. 개발 프로세스 초기에 CI/CD(지속적인 통합 및 지속적인 업데이트)를 구현하면 프로덕션으로 전환할 때 애플리케이션을 빠르고 안전하게 반복할 수 있습니다.
ARM 템플릿(Azure Resource Manager 템플릿)을 사용하여 Azure 리소스 및 해당 종속성을 배포합니다. POC 단계에서 이 프로세스를 시작하는 것이 중요합니다. 프로덕션으로 전환할 때 인프라를 자동으로 배포하는 기능을 원합니다.
다른 ARM 템플릿을 사용하고 Azure DevOps Services와 통합합니다. 이 설정을 사용하면 다양한 환경을 만들 수 있습니다. 예를 들어 프로덕션과 유사한 시나리오 또는 부하 테스트 환경을 필요한 경우에만 복제하고 비용을 절감할 수 있습니다.
자세한 내용은 운영 우수성 디자인 원칙을 참조하세요.
성능 효율성
성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성에 대한 디자인 검토 검사 목록을 참조하세요.
이 아키텍처는 프로덕션 배포용으로 설계되지 않았기 때문에 이 섹션에서는 이 아키텍처에서 생략된 몇 가지 중요한 성능 효율성 기능과 다른 권장 사항 및 고려 사항을 간략하게 설명합니다.
POC의 결과는 워크로드에 적합한 것으로 예상하는 SKU 선택이어야 합니다. App Service 계획에 배포된 컴퓨팅 인스턴스 수를 조정하여 수평 크기 조정을 통해 수요를 효율적으로 충족하도록 워크로드를 디자인합니다. 수요에 맞게 컴퓨팅 SKU를 변경하는 데 의존하도록 시스템을 디자인하지 마세요.
이 기본 아키텍처의 App Service 배포에는 자동 크기 조정이 구현되지 않습니다. 서비스는 수요에 맞게 효율적으로 유지하기 위해 동적으로 스케일 아웃하거나 스케일 인하지 않습니다.
지침를 통해 애플리케이션 가동 중지 시간 없이 개별 데이터베이스를 스케일 업합니다.(SQL Database에 대해 더 높은 서비스 계층 또는 성능 수준이 필요한 경우.)
다음 단계
배포 자습서:
제품 설명서:
- App Service 개요
- Azure Monitor 개요
- App Service 계획 개요
- Azure Monitor의 Log Analytics 개요
- Microsoft Entra ID란?
- SQL Database란?
Microsoft Learn 모듈:
- 클라우드용 Microsoft Defender 및 Microsoft Sentinel을 사용하여 Azure를 보호하기
- Microsoft Entra ID 이해하기
- Azure Monitor 구성
- App Service 살펴보기
- App Service를 사용하여 웹 애플리케이션 호스트
- Azure DNS에서 도메인 호스트
- Key Vault 구현
- Microsoft Entra ID에서 사용자 및 그룹 관리