편집

기본 웹앱 애플리케이션

Azure App Service
Azure Key Vault
Azure Monitor
Azure SQL Database

이 아키텍처는 기본 웹 애플리케이션의 기본 구성 요소를 보여 줍니다. 아키텍처를 사용하여 웹 애플리케이션을 빌드한 다음 필요에 따라 애플리케이션을 사용자 지정할 수 있습니다.

아키텍처

Azure의 기본 웹 애플리케이션을 위한 참조 아키텍처를 보여 주는 다이어그램

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

구성 요소

  • Azure App Service는 클라우드 애플리케이션을 만들고 배포하기 위한 완전히 관리되는 플랫폼입니다. 이를 통해 웹앱이 실행할 컴퓨팅 리소스 집합을 정의하고, 웹앱을 배포하고, 배포 슬롯을 구성할 수 있습니다.
  • 배포 슬롯을 사용하면 배포를 스테이징한 다음 프로덕션 배포로 교환할 수 있습니다. 따라서 프로덕션으로 바로 배포하지 않아도 됩니다. 특정 권장 사항은 아래 릴리스 엔지니어링 및 배포 섹션을 참조하세요.
  • IP 주소: App Service 앱에는 공용 IP 주소와 도메인 이름이 있습니다. 도메인 이름은 contoso.azurewebsites.net와 같이 azurewebsites.net의 하위 도메인입니다.
  • Azure DNS는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공하는 DNS 도메인에 대한 호스팅 서비스입니다. Azure에 도메인을 호스트하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다. 사용자 지정 도메인 이름(예: contoso.com)을 사용하려면 사용자 지정 도메인 이름을 IP 주소에 매핑하는 DNS 레코드를 만듭니다. 자세한 내용은 Azure App Service에서 사용자 지정 도메인 이름 구성을 참조하세요.
  • Azure SQL Database는 클라우드의 관계형 DaaS(Database-as-a-Service)입니다. SQL Database는 해당 코드 베이스를 Microsoft SQL Server 데이터베이스 엔진과 공유합니다. 애플리케이션 요구 사항에 따라 Azure Database for MySQL 또는 Azure Database for PostgreSQL을 사용할 수도 있습니다. 이러한 대안은 오픈 소스 MySQL Server와 Postgres 데이터베이스 엔진을 기반으로 하는 완전 관리형 데이터베이스 서비스입니다.
  • Microsoft Entra ID 는 직원이 조직을 위해 개발된 클라우드 앱에 액세스할 수 있도록 하는 클라우드 기반 ID 및 액세스 관리 서비스입니다.
  • Azure Monitor는 환경 전체에서 로그와 메트릭을 수집, 분석, 조치하기 위한 솔루션입니다.
  • Azure Key Vault는 비밀 관리, 키 관리, 인증서 관리를 지원합니다. 데이터베이스 연결 문자열과 같은 애플리케이션 비밀을 저장할 수 있습니다.

권장 사항

요구 사항은 코드에 설명되어 있고 주어진 아키텍처와 다를 수 있습니다. 코드는 프로덕션 구성을 사용하여 배포됩니다. 요구 사항에 맞게 배포를 사용자 지정하려면 권장 사항을 사용하세요.

App Service 계획

App Service 요금제에는 다양한 가격 책정 계층이 있습니다. 각 가격 책정 계층은 코어와 메모리 수에 따라 다양한 여러 인스턴스 크기를 지원합니다. 왼쪽 탐색에서 “스케일 업(App Service 요금제)”을 선택하여 배포 후 가격 책정 계층을 변경할 수 있습니다. 다음은 몇 가지 App Service 권장 사항입니다.

  • 기본, 표준, 프리미엄 가격 책정 계층에서 프로덕션 워크로드를 실행하세요. 이 세 계층에서 앱은 전용 가상 머신 인스턴스에서 실행되며 스케일 아웃할 수 있는 리소스를 할당했습니다.
  • 자동 스케일링과 TLS/SSL이 필요한 경우 표준 및 프리미어 계층을 사용하세요.
  • 테스트와 개발을 위한 다른 App Service 요금제를 만드세요. 비용 효율성을 위해 테스트와 개발에 무료 및 공유(미리 보기) 계층을 사용합니다. 그러나 프로덕션 워크로드에는 무료 및 공유 계층을 사용하지 마세요. 공유 리소스는 스케일 아웃할 수 없습니다.
  • 배포 테스트와 같이 사용하지 않는 요금제는 삭제해야 합니다. App Service 요금제는 초 단위로 요금이 청구됩니다. 앱이 중지된 경우에도 App Service 요금제의 인스턴스에 대해 요금이 청구됩니다. App Service 계획 및 청구에 대한 자세한 내용은 다음을 참조하세요.

아래 ARM 템플릿은 표준 가격 책정 계층에 배포됩니다.

SQL Database

  • Azure SQL Database를 사용하여 관리 오버헤드를 줄입니다. Azure SQL Database는 데이터베이스 컬렉션에 대한 중앙 관리 지점 역할을 하는 논리적 구문을 만듭니다. 이 논리적 구문은 관리 오버헤드를 줄입니다. 그룹 내의 각 데이터베이스는 특정 서비스 계층으로 배포됩니다. 각 그룹 내에서 데이터베이스는 리소스를 공유할 수 없습니다. 서버에 대한 컴퓨팅 비용은 없지만 각 데이터베이스에 대한 계층을 지정해야 합니다. 따라서 전용 리소스로 인해 성능이 향상될 수 있지만 비용이 더 높을 수 있습니다.
  • 용량 계획을 수행하고 요구 사항에 맞은 계층과 성능 수준을 선택합니다. SQL Database는 기본, 표준 및 프리미엄 서비스 계층을 지원하며, 각 계층 내에서 DTU(데이터베이스 트랜잭션 단위)로 측정되는 성능 수준이 다양합니다.

지역

  • 네트워크 대기 시간을 최소화하려면 동일한 지역에 App Service 요금제와 SQL Database를 만듭니다. 일반적으로 사용자에게 가장 가까운 지역을 선택합니다.
  • 리소스 그룹에도 지역이 있습니다. 배포 메타데이터가 저장되는 위치를 지정합니다. 배포 중에 가용성을 향상하려면 리소스 그룹 및 해당 리소스를 동일한 지역에 배치합니다.
  • 가격 책정 계산기를 사용하여 비용을 예측합니다.
  • 자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

고려 사항

이러한 고려 사항은 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 핵심 요소는 워크로드의 품질을 개선하는 일련의 지침 원칙입니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

성능 효율성

Azure App Service의 주요 이점은 부하에 따라 애플리케이션을 확장할 수 있다는 점입니다. 다음은 애플리케이션 확장을 계획할 때 염두에 둘 몇 가지 고려 사항입니다.

App Service 앱 크기 조정

App Service 앱은 확장하는 방법에는 다음 두 가지가 있습니다.

  • 스케일 업은 인스턴스 크기 변경을 의미합니다. 인스턴스 크기에 따라 각 VM 인스턴스의 메모리, 코어 수 및 스토리지가 결정됩니다. 인스턴스 크기나 계획 계층을 변경하여 수동으로 확장할 수 있습니다.
  • 스케일 아웃은 증가된 부하를 처리할 인스턴스의 추가를 의미합니다. 각 가격 책정 계층에는 최대 인스턴스 수가 있습니다. 인스턴스 수를 수동으로 변경하거나 자동 스케일링을 구성하여 Azure가 일정 및/또는 성능 메트릭에 따라 인스턴스를 자동으로 추가하거나 제거하도록 스케일 아웃할 수 있습니다. 각 확장 작업은 빠르게, 대개 몇 초 내에 실행됩니다.

자동 스케일링을 사용하려면 최소 및 최대 인스턴스 수를 정의하는 자동 스케일링 프로필을 만드세요. 스케일 이벤트를 트리거하도록 일정 기반 프로필을 설정할 수 있습니다. 예를 들어 평일과 주말에 대해 별도로 프로필을 만들 수 있습니다. 프로필에는 인스턴스를 추가하거나 제거할 시기에 대한 규칙을 포함할 수 있습니다. 예를 들어 CPU 사용량이 5분 동안 70%를 초과하는 경우 두 개의 인스턴스를 추가합니다.

웹앱 확장에 대한 권장 사항:

  • 가능한 한 스케일 업과 다운을 제한합니다. 애플리케이션이 다시 시작하도록 트리거할 수 있습니다. 대신 스케일 아웃하세요. 일반적인 부하에서 성능 요구 사항에 맞는 계층과 크기를 선택한 다음 인스턴스를 스케일 아웃하여 트래픽 양의 변화를 처리합니다.
  • 자동 크기 조정을 사용합니다. 애플리케이션의 워크로드가 예측 가능하고 정기적이면 인스턴스 수를 미리 예약하는 프로필을 만듭니다. 워크로드를 예측할 수 없는 경우에는 규칙 기반 자동 스케일링을 사용하여 발생하는 부하 변경에 대처합니다. 이 두 가지 방법을 결합할 수 있습니다.
  • 자동 스케일링 규칙에 CPU 사용량을 사용합니다. CPU 사용량은 일반적으로 자동 크기 조정 규칙에 적합한 메트릭입니다. 하지만 애플리케이션 부하 테스트를 수행하고, 잠재적인 병목 상태를 식별하고 이 데이터를 기준으로 자동 크기 조정 규칙을 만들어야 합니다.
  • 인스턴스 추가의 경우 휴지 기간을 짧게 설정하고 인스턴스 제거의 경우 휴지 기간을 길게 설정합니다. 자동 스케일링 규칙에는 휴지 기간이 포함됩니다. 휴지 기간은 스케일링 작업이 완료된 후 새 스케일링 작업을 시작하기 전에 대기하는 간격입니다. 휴지 기간을 이용하여 시스템을 다시 확장하기 전에 안정화합니다. 예를 들어 인스턴스를 추가하려면 5분을 설정하지만 인스턴스를 제거하려면 60분을 설정합니다. 과도하게 사용되고 있는 경우 새 인스턴스를 빠르게 추가하여 추가 트래픽을 처리한 다음 점차 스케일 다운하는 것이 좋습니다.

SQL 데이터베이스 스케일링

SQL Database에 대해 더 높은 서비스 계층 또는 성능 수준이 필요한 경우 애플리케이션 가동 중지 시간 없이 개별 데이터베이스를 스케일 업합니다.

자세한 내용은 Azure SQL Database에서 단일 데이터베이스 리소스 크기 조정을 참조하세요.

안정성

이 문서를 작성하는 시점에서 App Service에 대한 SLA(서비스 수준 약정)은 99.95%입니다. App Service SLA는 단일 인스턴스와 여러 인스턴스 모두에 적용됩니다. SQL Database에 대한 SLA는 기본, 표준, 프리미엄 계층의 경우 99.99%입니다.

Backup

SQL Database는 특정 시점 복원과 지역 복원을 통해 데이터 손실을 복원합니다. 이러한 기능은 모든 계층에서 제공되며 자동으로 사용하도록 설정됩니다. 백업을 예약하거나 관리할 필요가 없습니다.

  • 특정 시점 복원을 사용하세요. 데이터베이스를 이전 시점으로 되돌려 사용자 오류로부터 복구할 수 있습니다.
  • 지역 복원을 사용하세요. 지역 중복 백업에서 데이터베이스를 복원하여 서비스 중단으로부터 복구할 수 있습니다.
  • App Service 백업 및 복원을 사용하는 것이 좋습니다. 백업 및 복원은 애플리케이션 파일의 기능입니다. 그러나 백업된 파일에는 연결 문자열과 같은 일반 텍스트의 앱 설정이 포함되어 있습니다.
  • App Service 백업 기능을 사용하여 SQL 데이터베이스를 백업하지 마세요. DTU를 사용하여 데이터베이스를 SQL BACPAC 파일로 내보냅니다. 대신 위에서 설명한 SQL Database 지정 시간 복원을 사용합니다. 자세한 내용은 SQL Database를 사용한 클라우드 비즈니스 연속성 및 데이터베이스 재해 복구를 참조하세요.

운영 우수성

프로덕션, 개발 및 테스트 환경에 대해 별도의 리소스 그룹을 만듭니다. 환경을 분리하면 더 쉽게 배포를 관리하고 테스트 배포를 삭제하고 액세스 권한을 할당할 수 있습니다.

리소스 그룹에 리소스를 할당할 때는 다음 기능을 고려하세요.

  • 수명 주기. 일반적으로 수명 주기가 동일한 리소스를 동일한 리소스 그룹에 배치합니다.
  • 액세스. Azure RBAC(역할 기반 액세스 제어)를 사용하여 그룹의 리소스에 액세스 정책을 적용할 수 있습니다.
  • 청구. 리소스 그룹에 대한 롤업 비용을 확인할 수 있습니다.

자세한 내용은 Azure Resource Manager 개요를 참조하세요.

앱 구성

  • 구성 설정을 앱 설정으로 저장합니다. 앱 설정을 Resource Manager 템플릿에서 정의하거나 PowerShell을 사용하여 정의합니다. 런타임 시 앱 설정을 애플리케이션에 환경 변수로 사용할 수 있습니다.
  • 암호, 액세스 키 또는 연결 문자열을 소스 제어로 체크 인하지 마세요. 대신 이러한 값을 앱 설정으로 저장하는 배포 스크립트에 비밀을 매개 변수로 전달합니다.
  • 배포 슬롯을 교환하면 앱 설정이 기본적으로 교환됩니다. 다른 프로덕션 및 스테이징 설정이 필요하면 슬롯에 고정되어 교환되지 않는 앱 설정을 만들 수 있습니다.

진단 및 모니터링

DevOps

  • ARM 템플릿을 사용하여 Azure 리소스와 해당 종속성을 배포합니다. 함께 제공되는 ARM 템플릿은 단일 웹 애플리케이션을 배포합니다. 모든 리소스는 동일한 기본 워크로드에서 격리됩니다. 이러한 격리를 통해 워크로드의 특정 리소스를 팀에 더 쉽게 연결할 수 있습니다. 그러면 팀은 해당 리소스의 모든 측면을 독립적으로 관리할 수 있습니다. 이러한 격리를 통해 DevOps 팀은 CI/CD(연속 통합 및 지속적인 업데이트)를 수행할 수 있습니다.
  • 다양한 ARM 템플릿을 사용하고 Azure DevOps 서비스와 통합합니다. 이 설정을 사용하면 몇 분 안에 다양한 환경을 만들 수 있습니다. 예를 들어 프로덕션과 유사한 시나리오 또는 부하 테스트 환경을 필요한 경우에만 복제하고 비용을 절감할 수 있습니다.
  • 웹 애플리케이션의 여러 인스턴스를 프로비저닝합니다. 웹앱이 단일 인스턴스에 의존하여 잠재적으로 단일 실패 지점을 만드는 것을 원하지 않습니다. 여러 인스턴스는 복원력과 스케일링 성능을 개선합니다.

자세한 내용은 Azure Well-Architected Framework의 DevOps 섹션을 참조하세요.

릴리스 엔지니어링 및 배포

  • Azure Resource Manager 템플릿을 사용하여 리소스를 프로비저닝합니다. 템플릿을 사용하면 PowerShell 또는 Azure CLI를 통해 배포를 쉽게 자동화할 수 있습니다.
  • 애플리케이션(코드, 이진, 콘텐츠 파일)을 배포합니다. 로컬 Git 리포지토리에서 배포하거나, Visual Studio를 사용하여 배포하거나, 클라우드 기반 소스 제어를 통해 연속 배포하는 등 여러 옵션이 있습니다. Azure App Service에 앱 배포를 참조하세요.

App Service 앱에는 항상 production이라는 하나의 배포 슬롯이 있습니다. 프로덕션 슬롯은 라이브 프로덕션 사이트를 나타냅니다. 업데이트를 배포하기 위한 스테이징 슬롯을 만드는 것이 좋습니다. 스테이징 슬롯을 사용하면 다음과 같은 이점이 있습니다.

  • 프로덕션으로 교환하기 전에 배포가 성공했는지 확인할 수 있습니다.
  • 스테이징 슬롯에 배포하면 모든 인스턴스가 프로덕션으로 교환되기 전에 확실히 준비됩니다. 많은 애플리케이션에는 중요한 준비 및 콜드 부팅 시간이 있습니다.
  • 마지막으로 성공한 배포를 보관할 세 번째 슬롯을 만듭니다. 스테이징과 프로덕션을 교환한 후 이전 프로덕션 배포(이제는 스테이징에 있음)를 마지막으로 성공한 올바른 슬롯으로 이동합니다. 이렇게 하면 나중에 문제를 발견하는 경우 마지막으로 성공한 올바른 버전으로 신속하게 되돌릴 수 있습니다.

프로덕션 및 스테이징 배포에 대한 슬롯 교환

  • 이전 버전으로 되돌리는 경우에는 데이터베이스 스키마 변경 내용이 이전 버전과 호환되는지 확인합니다.
  • 동일한 App Service 계획 내의 모든 앱이 동일한 VM 인스턴스를 공유하므로 프로덕션 배포의 슬롯을 테스트에 사용하지 마세요. 예를 들어 부하 테스트는 라이브 프로덕션 사이트의 성능을 떨어뜨릴 수 있습니다. 대신 프로덕션과 테스트에 대한 App Service 계획을 별도로 만듭니다. 테스트 배포를 별도의 계획에 배치하여 프로덕션 버전과 격리합니다.

보안

이 섹션에는 이 문서에 설명된 Azure 서비스와 관련된 보안 고려 사항이 나와 있습니다. 보안 모범 사례가 완전히 다 나와 있는 것은 아닙니다. 기타 보안 고려 사항은 Azure App Service에서 앱 보호를 참조하세요.

SQL Database 감사

감사는 규정 준수를 유지 관리하고, 비즈니스 문제나 의심스러운 보안 위반을 나타낼 수 있는 불일치 및 이상 활동을 파악하는 데 도움이 될 수 있습니다. SQL Database 감사 시작을 참조하세요.

배포 슬롯

각 배포 슬롯에는 공용 IP 주소가 있습니다. 개발 및 DevOps 팀의 구성원만 해당 엔드포인트에 연결할 수 있도록 Microsoft Entra 로그인을 사용하여 비프로덕션 슬롯을 보호합니다.

로깅

사용자 암호 또는 ID 사기에 사용될 수 있는 기타 정보는 절대로 기록해서는 안 됩니다. 데이터를 저장하기 전에 데이터에서 이러한 세부 정보를 지웁니다.

SSL

App Service 앱에는 추가 비용 없이 azurewebsites.net의 하위 도메인에 SSL 엔드포인트가 포함되어 있습니다. SSL 엔드포인트에는 *.azurewebsites.net 도메인에 대한 와일드카드 인증서가 포함되어 있습니다. 사용자 지정 도메인 이름을 사용하는 경우 사용자 지정 도메인과 일치하는 인증서를 제공해야 합니다. 가장 간단한 방법은 Azure Portal에서 직접 인증서를 구입하는 것입니다. 다른 인증 기관에서 인증서를 가져올 수도 있습니다. 자세한 내용은 Azure App Service에 대한 SSL 인증서 구매 및 구성을 참조하세요.

HTTPS는 ARM 템플릿 배포에서 기본적으로 사용하도록 설정되지 않습니다. 보안을 극대화하려면 앱에서 HTTP 요청을 리디렉션하여 HTTPS를 적용해야 합니다. 애플리케이션 내부에서 HTTPS를 구현하거나 Azure App Service에서 앱에 대해 HTTPS 사용 설정에 설명된 대로 URL 다시 쓰기 규칙을 사용할 수 있습니다.

인증

Microsoft Entra ID, Facebook, Google 또는 Twitter와 같은 IDP(ID 공급자)를 통해 인증하는 것이 좋습니다. 인증 흐름에 OAuth 2 또는 OIDC(OpenID Connect)를 사용합니다. Microsoft Entra ID는 사용자 및 그룹을 관리하고, 애플리케이션 역할을 만들고, 온-프레미스 ID를 통합하고, Microsoft 365 및 비즈니스용 Skype 같은 백 엔드 서비스를 사용하는 기능을 제공합니다.

애플리케이션에서 사용자 로그인과 자격 증명을 직접 관리하도록 하지 마세요. 잠재적인 공격 표면을 만듭니다. 최소한 이메일 확인, 암호 복구 및 다단계 인증을 사용하도록 해야 하고 암호 강도를 확인하고, 암호 해시를 안전하게 저장해야 합니다. 대형 ID 공급자는 이러한 기능을 모두 자동으로 처리하며 보안 방법을 지속적으로 모니터링하고 개선합니다.

OAuth 또는 OIDC 인증 흐름을 구현하려면 App Service 인증을 사용하는 것이 좋습니다. App Service 인증의 이점은 다음과 같습니다.

  • 구성하기 쉽습니다.
  • 단순 인증 시나리오의 경우 코드가 필요하지 않습니다.
  • OAuth 액세스 토큰을 사용한 위임된 권한 부여를 통해 사용자 대신 리소스를 사용하도록 지원합니다.
  • 토큰 캐시를 기본 제공합니다.

App Service 인증의 몇 가지 제한 사항은 다음과 같습니다.

  • 사용자 지정 옵션이 제한되어 있습니다.
  • 위임된 권한 부여는 로그인 세션당 하나의 백 엔드 리소스로 제한됩니다.
  • 둘 이상의 IDP를 사용하는 경우 홈 영역 검색을 위한 기본 제공 메커니즘이 없습니다.
  • 다중 테넌트 시나리오의 경우 애플리케이션에서 토큰 발급자의 유효성을 검사하는 논리를 구현해야 합니다.

시나리오 배포

이 아키텍처에는 Azure App Service 요금제와 빈 애플리케이션이 포함됩니다. Azure SQL Database와 Azure Key Vault를 데이터베이스 연결 문자열을 저장하는 데 사용하고 Azure Monitor를 로깅, 모니터링, 경고에 사용합니다.

다음 명령을 사용하여 배포에 대한 리소스 그룹을 만듭니다. 포함된 셸을 사용하려면 시도 단추를 선택합니다.

az group create --name basic-web-app --location eastus

다음 명령을 실행하여 웹 애플리케이션 및 지원 인프라를 배포합니다. 메시지가 표시되면 사용자 이름과 암호를 입력합니다. 이러한 값은 Azure SQL Database 인스턴스에 액세스하는 데 사용됩니다.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

자세한 내용과 추가 배포 옵션은 이 솔루션을 배포하는 데 사용되는 ARM 템플릿을 참조하세요.

기본 웹 애플리케이션 ARM 템플릿

다음 단계

애플리케이션 문제 해결 팁:

제품 설명서:

Microsoft Learn 모듈: