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