Azure Virtual Machines 기준 아키텍처

이 문서에서는 Azure Virtual Machines에 배포된 워크로드에 대한 기본 참조 아키텍처를 제공합니다.

이 아키텍처에서 가정하는 워크로드 예제는 별도의 VM(가상 머신) 집합에 배포되는 인터넷 연결 다중 계층 웹 애플리케이션입니다. VM은 Azure Virtual Machine Scale Sets 배포의 일부로 프로비전됩니다. 이 아키텍처는 다음 시나리오에 사용할 수 있습니다.

• 프라이빗 애플리케이션. 이러한 애플리케이션에는 내부 LOB(기간 업무) 애플리케이션 또는 상용 상용 솔루션이 포함됩니다.
• 공용 애플리케이션. 이러한 애플리케이션은 인터넷 연결 애플리케이션입니다. 이 아키텍처는 고성능 컴퓨팅, 중요 업무용 워크로드, 대기 시간의 영향을 많이 받는 애플리케이션 또는 기타 특수한 사용 사례를 위한 것이 아닙니다.

이 아키텍처의 주요 초점은 애플리케이션이 아닙니다. 대신, 이 문서에서는 애플리케이션이 상호 작용하는 인프라 구성 요소를 구성하고 배포하기 위한 지침을 제공합니다. 이러한 구성 요소에는 컴퓨팅, 스토리지, 네트워킹 및 모니터링 구성 요소가 포함됩니다.

이 아키텍처는 IaaS(Infrastructure as a Service) 호스팅 워크로드의 시작점 역할을 합니다. 데이터 계층은 컴퓨팅 인프라에 초점을 유지하기 위해 이 지침에서 의도적으로 제외됩니다.

문서 레이아웃

아키텍처	디자인 결정	잘 설계된 프레임워크 접근 방식
▪ 아키텍처 다이어그램 ▪ 워크로드 리소스 ▪ 지원 리소스 ▪ 사용자 흐름	▪ VM 디자인 선택 ▪ 디스크 ▪ 네트워킹 ▪ 모니터링 ▪ 업데이트 관리	▪ 안정성 ▪ 보안 ▪ 비용 최적화

아키텍처

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

이러한 리소스에 대한 자세한 내용은 관련 리소스에 나열된 Azure 제품 설명서를 참조하세요.

구성 요소

이 아키텍처는 워크로드 리소스와 리소스를 지원하는 워크로드 모두에 대한 여러 Azure 서비스로 구성됩니다. 각 역할과 해당 역할에 대한 서비스는 다음 섹션에서 설명합니다.

워크로드 리소스

• Azure Virtual Machines 는 애플리케이션의 컴퓨팅 리소스 역할을 하며 가용성 영역에 분산됩니다. 설명을 위해 Windows 및 Linux VM의 조합이 사용됩니다.

  유연한 오케스트레이션 모드의 Azure Virtual Machine Scale Sets 는 VM을 프로비전하고 관리하는 데 사용됩니다.

  샘플 애플리케이션은 각각 자체 컴퓨팅이 필요한 두 계층으로 나타낼 수 있습니다.

  • 프런트 엔드는 웹 서버를 실행하고 사용자 요청을 받습니다.
  • 백 엔드는 비즈니스 논리가 실행되는 단일 엔드포인트를 노출하는 웹 API 역할을 하는 다른 웹 서버를 실행합니다.

  프런트 엔드 VM에는 상태 비정상 애플리케이션을 배포하는 데 사용할 수 있는 데이터 디스크(Premium_LRS)가 연결되어 있습니다. 백 엔드 VM은 작업의 일부로 로컬 디스크를 Premium_ZRS 데이터를 유지합니다 . 이 레이아웃은 프런트 엔드 및 백 엔드 컴퓨팅에서 상태를 저장하기 위한 데이터베이스 계층을 포함하도록 확장할 수 있습니다. 해당 계층은 이 아키텍처의 범위를 벗어습니다.

• Azure Virtual Network 는 모든 워크로드 리소스에 대한 프라이빗 네트워크를 제공합니다. 네트워크는 격리 경계 역할을 하는 서브넷으로 분할됩니다.

• Azure 애플리케이션 게이트웨이는 프런트 엔드 서버로 요청을 라우팅하는 단일 수신 지점입니다. 선택한 SKU에는 보안을 강화하기 위해 통합된 WAF(Azure Web Application Firewall)가 포함되어 있습니다.

• 내부 Azure Load Balancer는 프런트 엔드 계층에서 백 엔드 서버로 트래픽을 라우팅합니다.

• Azure Load Balancer 표준 SKU는 세 개의 공용 IP 주소를 사용하여 VM에 대한 아웃바운드 인터넷 액세스를 제공합니다.

• Azure Key Vault 는 TLS(엔드투엔드 전송 계층 보안) 통신에 사용되는 인증서를 저장합니다. 애플리케이션 비밀에도 사용할 수 있습니다.

리소스를 지원하는 워크로드

• Azure Bastion 은 보안 프로토콜을 통해 VM에 대한 운영 액세스를 제공합니다.

• Application Insights는 애플리케이션에서 로그 및 메트릭을 수집합니다. 애플리케이션이 이 아키텍처의 초점이 아니므로 로그 수집은 구현에 표시되지 않습니다.

• Log Analytics 는 Azure 리소스 및 Application Insights에서 로그 및 메트릭을 수집하는 모니터링 데이터 싱크입니다. 스토리지 계정은 작업 영역의 일부로 프로비전됩니다.

사용자 흐름

워크로드 리소스와 상호 작용하는 두 가지 유형의 사용자, 즉 워크로드 사용자 및 운영자가 있습니다. 이러한 사용자의 흐름은 이전 아키텍처 다이어그램에 표시됩니다.

워크로드 사용자

1. 사용자는 Application Gateway의 노출된 공용 IP 주소를 사용하여 웹 사이트에 액세스합니다.

2. Application Gateway는 HTTPS 트래픽을 수신하고, WAF 검사를 위해 외부 인증서를 사용하여 데이터의 암호를 해독하고, 프런트 엔드로 전송하기 위해 내부 와일드카드 인증서를 사용하여 데이터를 다시 암호화합니다.

3. Application Gateway는 프런트 엔드 VM 간에 트래픽을 분산하고 프런트 엔드 VM에 요청을 전달합니다.

4. 선택한 프런트 엔드 VM은 개별 VM의 IP가 아닌 부하 분산 장치의 개인 IP 주소를 사용하여 백 엔드 VM과 통신합니다. 이 통신은 내부 와일드카드 인증서를 사용하여 암호화됩니다.

5. 백 엔드 VM은 내부 인증서를 사용하여 요청을 해독합니다. 백 엔드가 요청을 처리한 후 결과를 프런트 엔드로 반환하고, 결과를 애플리케이션 게이트웨이에 반환하고, 마지막으로 결과를 사용자에게 반환합니다.

연산자

이 아키텍처의 VM은 운영자가 직접 액세스해야 할 수 있지만 자동화를 통해 원격 액세스를 최소화하고 액세스를 모니터링하는 것이 좋습니다. 액세스는 중단 수정 상황, 문제 해결 또는 자동화된 배포 프로세스의 일부일 수 있습니다. 이 아키텍처에는 컨트롤 플레인 액세스를 위한 공용 IP가 없습니다. Azure Bastion은 서버리스 게이트웨이 역할을 하므로 작업이 SSH 또는 RDP를 통해 VM에 액세스할 수 있습니다. 이 설정은 안전하고 효율적인 액세스 관리를 보장합니다.

1. 운영자는 Azure Portal 또는 Azure CLI에 로그인합니다.
2. 운영자는 Azure Bastion 서비스에 액세스하고 원하는 VM에 원격으로 연결합니다.

VM 디자인 선택

SKU를 선택할 때는 기준 성능 기대치가 있어야 합니다. 의사 결정 프로세스에 영향을 주는 몇 가지 특성은 다음과 같습니다.

• CPU, 메모리 및 IOPS(초당 디스크 입력/출력 작업)입니다.
• 프로세서 아키텍처.
• 운영 체제(OS) 이미지 크기입니다.

예를 들어 Intel 프로세서 컴퓨터가 필요한 온-프레미스 환경에서 워크로드를 마이그레이션하는 경우 Intel 프로세서를 지원하는 VM SKU를 선택합니다.

지원되는 VM SKU에 대한 자세한 내용은 Azure의 가상 머신 크기를 참조하세요.

부트스트래핑

VM을 부트스트랩해야 하는 경우가 많습니다. 이 프로세스는 VM이 준비되고 애플리케이션을 실행하도록 조정되는 프로세스입니다. 일반적인 부트스트래핑 작업에는 인증서 설치, 원격 액세스 구성, 패키지 설치, OS 구성 튜닝 및 강화, 데이터 디스크 서식 지정 및 탑재 등이 있습니다. 애플리케이션이 지연 또는 수동 개입 없이 VM에서 시작할 수 있도록 가능한 한 부트스트래핑 프로세스를 자동화하는 것이 중요합니다. 자동화에 대한 권장 사항은 다음과 같습니다.

• 가상 머신 확장. 이러한 확장은 IaC(Infrastructure-as-Code) 배포를 통해 관리되는 Azure Resource Manager 개체입니다. 이러한 방식으로 모든 오류는 조치를 취할 수 있는 실패한 배포로 보고됩니다. 부트스트래핑 요구 사항에 대한 확장이 없는 경우 사용자 지정 스크립트를 만듭니다. Azure 사용자 지정 스크립트 확장을 통해 스크립트를 실행하는 것이 좋습니다.

  다음은 VM에 기능을 자동으로 설치하거나 구성하는 데 사용할 수 있는 몇 가지 다른 확장입니다.

  • AMA(Azure Monitor 에이전트) 는 게스트 OS에서 모니터링 데이터를 수집하여 Azure Monitor에 전달합니다.
  • Azure 사용자 지정 스크립트 확장(Windows, Linux) 버전 2는 Azure VM(가상 머신)에서 스크립트를 다운로드하고 실행합니다. 이 확장은 배포 후 구성, 소프트웨어 설치 또는 기타 구성 또는 관리 작업을 자동화하는 데 유용합니다.
  • Azure Key Vault 가상 머신 확장(Windows, Linux)은 변경 내용을 검색하고 해당 인증서를 설치하여 Key Vault에 저장된 인증서의 자동 새로 고침을 제공합니다.
  • Azure Virtual Machine Scale Sets 가 자동 롤링 업그레이드를 수행하는 경우 Virtual Machine Scale Sets를 사용하는 Application Health 확장이 중요합니다. Azure는 개별 인스턴스의 상태 모니터링을 사용하여 업데이트를 수행합니다. 확장을 사용하여 확장 집합에서 각 인스턴스의 애플리케이션 상태를 모니터링하고 자동 인스턴스 복구를 사용하여 인스턴스 복구를 수행할 수도 있습니다.
  • Microsoft Entra ID 및 OpenSSH(Windows, Linux)는 Microsoft Entra 인증과 통합됩니다. 이제 Microsoft Entra ID 및 OpenSSH 인증서 기반 인증을 통해 Microsoft Entra ID를 핵심 인증 플랫폼으로 사용하고 Linux VM에 대한 SSH에 대한 인증 기관을 사용할 수 있습니다. 이 기능을 사용하면 Azure RBAC(역할 기반 액세스 제어) 및 조건부 액세스 정책을 사용하여 VM에 대한 액세스를 관리할 수 있습니다.

• 에이전트 기반 구성. Linux VM은 다양한 Azure 제공 VM 이미지에서 cloud-init를 통해 사용할 수 있는 간단한 네이티브 원하는 상태 구성을 사용할 수 있습니다. 구성이 지정되고 IaC 아티팩트와 함께 버전이 지정됩니다. 고유한 구성 관리 솔루션을 가져오는 것도 또 다른 방법입니다. 대부분의 솔루션은 부트스트랩에 대한 선언적 우선 접근 방식을 따르지만 유연성을 위해 사용자 지정 스크립트를 지원합니다. 인기 있는 선택 항목으로는 Windows용 Desired State Configuration, Linux용 Desired State Configuration, Ansible, Chef, Puppet 등이 있습니다. 이러한 모든 구성 솔루션을 VM 확장과 페어링하여 최상의 환경을 제공할 수 있습니다.

참조 구현에서 모든 부트스트랩은 데이터 디스크 서식 지정 및 탑재를 자동화하기 위한 사용자 지정 스크립트를 포함하여 VM 확장 및 사용자 지정 스크립트를 통해 수행됩니다.

잘 설계된 프레임워크: RE:02 - 자동화 디자인에 대한 권장 사항을 참조하세요.

VM 연결

VM과 특정 가상 네트워크의 다른 디바이스 간에 프라이빗 통신을 사용하도록 설정하기 위해 VM의 NIC(네트워크 인터페이스 카드)는 가상 네트워크의 서브넷 중 하나에 연결됩니다. VM에 여러 NIC가 필요한 경우 각 VM 크기에 대해 최대 NIC 수가 정의되어 있음을 알고 있습니다.

워크로드에 가상 네트워크의 VM 간의 짧은 대기 시간 통신이 필요한 경우 Azure VM NIC에서 지원하는 가속화된 네트워킹을 고려합니다. 자세한 내용은 가속화된 네트워킹의 이점을 참조 하세요.

유연한 오케스트레이션을 사용하는 Virtual Machine Scale Sets

VM은 유연한 오케스트레이션을 사용하여 Virtual Machine Scale Sets 의 일부로 프로비전됩니다. Virtual Machine Scale Sets는 비즈니스 요구 사항을 충족하는 데 사용되는 VM의 논리적 그룹입니다. 그룹화의 VM 유형은 동일하거나 다를 수 있습니다. 표준 Azure VM API 및 명령을 사용하여 컴퓨터, 네트워크 인터페이스 및 디스크의 수명 주기를 관리할 수 있습니다.

유연한 오케스트레이션 모드는 대규모 작업을 용이하게 하며 세분화된 크기 조정 결정에 도움이 됩니다.

물리적 하드웨어 오류, 네트워크 중단 또는 전원 중단의 영향을 제한하려면 장애 도메인 구성이 필요합니다. 확장 집합을 사용하면 Azure는 단일 하드웨어 또는 인프라 문제에 대한 복원력을 위해 장애 도메인 간에 인스턴스를 균등하게 분산합니다.

최대 인스턴스 분산, 복원력 및 가용성 향상을 위해 장애 도메인 할당을 Azure로 오프로드하는 것이 좋습니다.

Disks

OS 및 애플리케이션 구성 요소를 실행하기 위해 스토리지 디스크가 VM에 연결됩니다. OS에 임시 디스크를 사용하고 데이터 스토리지에 관리 디스크를 사용하는 것이 좋습니다.

Azure는 성능, 다양성 및 비용 측면에서 다양한 옵션을 제공합니다. 대부분의 프로덕션 워크로드에 대한 프리미엄 SSD부터 시작합니다. 선택은 VM SKU에 따라 달라집니다. 프리미엄 SSD를 지원하는 SKU는 리소스 이름(예: Dsv4이지만 Dv4는 아님)에 s를 포함합니다.

용량, IOPS 및 처리량과 같은 메트릭이 있는 디스크 옵션에 대한 자세한 내용은 디스크 유형 비교를 참조하세요.

디스크를 선택할 때 디스크 특성 및 성능 기대치를 고려합니다.

• VM SKU 제한 사항. 디스크는 IOPS 및 처리량 제한이 있는 연결된 VM 내에서 작동합니다. 디스크가 VM의 한도를 제한하지 않고 그 반대의 경우도 마찬가지인지 확인합니다. 애플리케이션 구성 요소를 최적으로 실행하는 디스크 크기, 성능 및 VM 기능(코어, CPU, 메모리)을 선택합니다. 비용에 영향을 주므로 과도하게 프로비전하지 않습니다.

• 구성이 변경됩니다. VM이 실행되는 동안 일부 디스크 성능 및 용량 구성을 변경할 수 있습니다. 그러나 많은 변경 내용으로 디스크 콘텐츠를 다시 프로비전하고 다시 빌드해야 워크로드 가용성에 영향을 미칠 수 있습니다. 따라서 가용성 영향 및 재작업을 최소화하기 위해 디스크 및 VM SKU 선택을 신중하게 계획합니다.

• 임시 OS 디스크. OS 디스크를 임시 디스크로 프로비전합니다. OS 파일을 유지해야 하는 경우에만 관리 디스크를 사용합니다. 애플리케이션 구성 요소 및 상태를 저장하기 위해 임시 디스크를 사용하지 마세요.

  임시 OS 디스크의 용량은 선택한 VM SKU에 따라 달라집니다. OS 이미지 디스크 크기가 SKU의 사용 가능한 캐시 또는 임시 디스크보다 작은지 확인합니다. 임시 스토리지에 나머지 공간을 사용할 수 있습니다.

• 디스크 성능. 최대 부하를 기반으로 디스크 공간을 미리 프로비전하는 것이 일반적이지만 대부분의 워크로드가 최대 부하를 유지하지 않으므로 사용률이 낮은 리소스로 이어질 수 있습니다.

  워크로드의 사용 패턴을 모니터링하고, 급증 또는 지속적인 높은 읽기 작업을 확인하고, 이러한 패턴을 VM 및 관리 디스크 SKU 선택에 고려합니다.

  성능 계층을 변경하거나 일부 관리 디스크 SKU에서 제공되는 버스팅 기능을 사용하여 주문형 성능을 조정할 수 있습니다.

  과잉 프로비전은 버스팅의 필요성을 줄이지만 비용을 지불하는 사용되지 않는 용량으로 이어질 수 있습니다. 최적의 결과를 위해 두 기능을 결합하는 것이 이상적입니다.

• 워크로드에 대한 캐싱을 조정합니다. 애플리케이션 구성 요소 사용에 따라 모든 디스크에 대한 캐시 설정을 구성합니다.

  주로 읽기 작업을 수행하는 구성 요소에는 높은 디스크 트랜잭션 일관성이 필요하지 않습니다. 이러한 구성 요소는 읽기 전용 캐싱을 활용할 수 있습니다. 높은 디스크 트랜잭션 일관성이 필요한 쓰기가 많은 구성 요소는 종종 캐싱을 사용하지 않도록 설정됩니다.

  VM이 충돌하고 대부분의 데이터 디스크 시나리오에 권장되지 않는 경우 읽기-쓰기 캐싱을 사용하면 데이터 손실이 발생할 수 있습니다.

이 아키텍처에서는 다음을 수행합니다.

• 모든 VM의 OS 디스크는 임시이며 캐시 디스크에 있습니다.

  프런트 엔드(Linux) 및 백 엔드(Windows Server)의 워크로드 애플리케이션은 개별 VM 오류에 관대하며 둘 다 작은 이미지(약 30GB)를 사용합니다. 이러한 특성은 원격 Azure Storage 리소스에 저장된 영구 OS 디스크 대신 VM 로컬 스토리지(캐시 파티션)의 일부로 만든 임시 OS 디스크를 사용할 수 있도록 합니다. 이 상황에서는 OS 디스크에 대한 스토리지 비용이 발생하지 않으며 대기 시간을 줄이고 VM 배포 시간을 줄여 성능을 향상시킵니다.

• 각 VM에는 고유한 프리미엄 SSD P1 관리 디스크가 있어 워크로드에 적합한 기본 프로비전 처리량을 제공합니다.

네트워크 레이아웃

이 아키텍처는 단일 가상 네트워크에 워크로드를 배포합니다. 네트워크 컨트롤은 이 아키텍처의 중요한 부분이며 보안 섹션에 설명되어 있습니다.

이 레이아웃은 엔터프라이즈 토폴로지와 통합할 수 있습니다. 이 예제는 Azure 랜딩 존의 가상 머신 기준 아키텍처에 표시됩니다.

가상 네트워크

초기 네트워크 레이아웃 결정 중 하나는 네트워크 주소 범위와 관련이 있습니다. 용량 계획 단계에서 예상되는 네트워크 증가를 염두에 두세요. 네트워크는 성장을 지속할 수 있을 만큼 충분히 커야 하며, 추가 네트워킹 구문이 필요할 수 있습니다. 예를 들어 가상 네트워크에는 크기 조정 작업으로 인한 다른 VM을 수용할 수 있는 용량이 있어야 합니다.

반대로 주소 공간의 크기를 적절하게 조정합니다. 지나치게 큰 가상 네트워크는 제대로 활용하지 못하게 될 수 있습니다. 가상 네트워크가 만들어지면 주소 범위를 수정할 수 없다는 점에 유의해야 합니다.

이 아키텍처에서 주소 공간은 예상 증가에 따른 결정인 /21로 설정됩니다.

서브넷 지정 고려 사항

가상 네트워크 내에서 서브넷은 다음과 같이 기능 및 보안 요구 사항에 따라 나뉩니다.

• 역방향 프록시 역할을 하는 애플리케이션 게이트웨이를 호스트하는 서브넷입니다. Application Gateway에는 전용 서브넷이 필요합니다.
• 백 엔드 VM에 트래픽을 분산하기 위해 내부 부하 분산 장치를 호스트하는 서브넷입니다.
• 워크로드 VM을 호스트하는 서브넷( 프런트 엔드용 및 백 엔드용) 이러한 서브넷은 애플리케이션의 계층에 따라 만들어집니다.
• 워크로드 VM에 대한 운영 액세스를 용이하게 하는 Azure Bastion 호스트의 서브넷입니다. 기본적으로 Azure Bastion 호스트에는 전용 서브넷이 필요합니다.
• Azure Private Link를 통해 다른 Azure 리소스에 액세스하기 위해 만든 프라이빗 엔드포인트를 호스트하는 서브넷입니다. 이러한 엔드포인트에는 전용 서브넷이 필수는 아니지만 권장합니다.

가상 네트워크와 마찬가지로 서브넷은 올바른 크기여야 합니다. 예를 들어 애플리케이션의 크기 조정 요구 사항에 맞게 유연한 오케스트레이션에서 지원하는 VM의 최대 제한을 적용할 수 있습니다. 워크로드 서브넷은 해당 제한을 수용할 수 있어야 합니다.

고려해야 할 또 다른 사용 사례는 임시 IP 주소가 필요할 수 있는 VM OS 업그레이드입니다. 오른쪽 크기 조정은 NSG(네트워크 보안 그룹)를 통한 의미 있는 보안 규칙을 서브넷 경계에 적용할 수 있도록 유사한 리소스를 그룹화하여 원하는 수준의 분할을 제공합니다. 자세한 내용은 보안: 구분을 참조 하세요.

수신 트래픽

수신 흐름에 두 개의 공용 IP 주소가 사용됩니다. 한 주소는 역방향 프록시 역할을 하는 Application Gateway에 대한 것입니다. 사용자는 해당 공용 IP 주소를 사용하여 연결합니다. 역방향 프록시는 수신 트래픽을 VM의 개인 IP로 분산합니다. 다른 주소는 Azure Bastion을 통한 운영 액세스를 위한 것입니다.

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

송신 트래픽

이 아키텍처는 VM 인스턴스에서 정의된 아웃바운드 규칙과 함께 표준 SKU Load Balancer를 사용합니다. 부하 분산 장치는 영역 중복이므로 선택되었습니다.

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

이 구성을 사용하면 부하 분산 장치의 공용 IP를 사용하여 VM에 대한 아웃바운드 인터넷 연결을 제공할 수 있습니다. 아웃바운드 규칙을 사용하면 SNAT(원본 네트워크 주소 변환) 포트를 명시적으로 정의할 수 있습니다. 규칙을 사용하면 수동 포트 할당을 통해 이 기능을 확장하고 조정할 수 있습니다. 백 엔드 풀 크기 및 수 frontendIPConfigurations 에 따라 SNAT 포트를 수동으로 할당하면 SNAT 고갈을 방지할 수 있습니다.

최대 백 엔드 인스턴스 수에 따라 포트를 할당하는 것이 좋습니다. 나머지 SNAT 포트가 허용하는 것보다 더 많은 인스턴스가 추가되면 Virtual Machine Scale Sets 크기 조정 작업이 차단되거나 새 VM이 충분한 SNAT 포트를 받지 못할 수 있습니다.

인스턴스당 포트를 다음과 Number of front-end IPs * 64K / Maximum number of back-end instances같이 계산합니다.

서브넷에 연결된 Azure NAT Gateway 리소스 배포와 같은 다른 옵션을 사용할 수 있습니다. 또 다른 옵션은 Azure Firewall 또는 다른 네트워크 가상 어플라이언스와 사용자 지정 UDR(사용자 정의 경로)을 방화벽을 통한 다음 홉으로 사용하는 것입니다. 이 옵션은 Azure 랜딩 존의 가상 머신 기준 아키텍처에 표시됩니다.

DNS 확인

Azure DNS는 워크로드 VM과 연결된 FQDN(정규화된 도메인 이름) 확인과 같은 모든 확인 사용 사례의 기본 서비스로 사용됩니다. 이 아키텍처에서 VM은 Azure DNS인 가상 네트워크 구성에 설정된 DNS 값을 사용합니다.

Azure 프라이빗 DNS 영역은 명명된 Private Link 리소스에 액세스하는 데 사용되는 프라이빗 엔드포인트에 대한 요청을 확인하는 데 사용됩니다.

모니터링

이 아키텍처에는 워크로드의 유틸리티에서 분리되는 모니터링 스택이 있습니다. 주로 데이터 원본 및 컬렉션 측면에 초점을 맞춥니다.

메트릭 및 로그는 다양한 데이터 원본에서 생성되어 다양한 고도에서 관찰 가능한 인사이트를 제공합니다.

• 기본 인프라 및 구성 요소( 예: VM, 가상 네트워크 및 스토리지 서비스)가 고려됩니다. Azure 플랫폼 로그는 Azure 플랫폼 내의 작업 및 활동에 대한 정보를 제공합니다.

• 애플리케이션 수준은 시스템에서 실행되는 애플리케이션의 성능 및 동작에 대한 인사이트를 제공합니다.

Log Analytics 작업 영역은 Azure 리소스 및 Application Insights에서 로그 및 메트릭을 수집하는 데 사용되는 권장 모니터링 데이터 싱크입니다.

이 이미지는 인프라 및 애플리케이션에서 데이터를 수집하기 위한 구성 요소, 데이터 싱크 및 분석 및 시각화를 위한 다양한 소비 도구가 포함된 기준선에 대한 모니터링 스택을 보여 줍니다. 구현은 Application Insights, VM 부팅 진단 및 Log Analytics와 같은 일부 구성 요소를 배포합니다. 대시보드 및 경고와 같은 확장성 옵션을 보여 주는 다른 구성 요소가 표시됩니다.

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

인프라 수준 모니터링

이 표는 Azure Monitor에서 수집한 로그 및 메트릭에 연결됩니다. 사용 가능한 경고는 사용자에게 영향을 주기 전에 문제를 사전에 해결하는 데 도움이 됩니다.

Azure 리소스	메트릭 및 로그	경고
Application Gateway	Application Gateway 메트릭 및 로그 설명	Application Gateway 경고
Application Insights	Application Insights 메트릭 및 로깅 API	Application Insights 경고
Azure Bastion	Azure Bastion 메트릭
Key Vault	Key Vault 메트릭 및 로그 설명	Key Vault 경고
표준 Load Balancer	부하 분산 장치 로그 및 메트릭	Load Balancer 경고
공용 IP 주소	공용 IP 주소 메트릭 및 로그 설명	공용 IP 주소 메트릭 경고
Virtual Network	가상 네트워크 메트릭 및 로그 참조	가상 네트워크 경고
Virtual Machines 및 Virtual Machine Scale Sets	VM 메트릭 및 로그 참조	VM 경고 및 자습서
Web Application Firewall	웹 애플리케이션 방화벽 메트릭 및 로그 설명	웹 애플리케이션 방화벽 경고

메트릭 및 로그 수집 비용에 대한 자세한 내용은 Log Analytics 작업 영역에 대한 Log Analytics 비용 계산 및 옵션 및 가격 책정을 참조하세요. 워크로드의 특성과 수집된 메트릭 및 로그의 빈도 및 수는 메트릭 및 로그 수집 비용에 큰 영향을 줍니다.

가상 머신

Azure 부팅 진단 은 직렬 로그 정보 및 스크린샷을 수집하여 부팅하는 동안 VM의 상태를 관찰할 수 있습니다. 이 아키텍처에서 해당 데이터는 Azure Portal 및 Azure CLI vm boot-diagnostics get-boot-log 명령을 통해 액세스할 수 있습니다. 데이터는 Azure에서 관리되며 기본 스토리지 리소스에 대한 제어 또는 액세스 권한이 없습니다. 그러나 비즈니스 요구 사항에서 더 많은 제어를 요구하는 경우 부팅 진단을 저장하도록 고유한 스토리지 계정을 프로비전할 수 있습니다.

VM 인사이트는 VM 및 확장 집합을 모니터링하는 효율적인 방법을 제공합니다. Log Analytics 작업 영역에서 데이터를 수집하고 성능 데이터 추세에 대해 미리 정의된 통합 문서를 제공합니다. 이 데이터는 VM별로 보거나 여러 VM에서 집계할 수 있습니다.

Application Gateway 및 내부 부하 분산 장치는 상태 프로브를 사용하여 트래픽을 보내기 전에 VM의 엔드포인트 상태를 검색합니다.

네트워킹

이 아키텍처에서 로그 데이터는 흐름에 참여하는 여러 네트워킹 구성 요소에서 수집됩니다. 이러한 구성 요소에는 Application Gateway, 부하 분산 장치 및 Azure Bastion이 포함됩니다. 가상 네트워크, NSG, 공용 IP 주소 및 Private Link와 같은 네트워킹 보안 구성 요소도 포함됩니다.

관리 디스크

디스크 메트릭은 워크로드에 따라 달라지며 주요 메트릭을 혼합해야 합니다. 모니터링은 이러한 관점을 결합하여 OS 또는 애플리케이션 처리량 문제를 격리해야 합니다.

• Azure 플랫폼 관점은 연결된 워크로드에 관계없이 Azure 서비스를 나타내는 메트릭을 나타냅니다. 디스크 성능 메트릭(IOPS 및 처리량)은 모든 VM 연결 디스크에 대해 개별적으로 또는 전체적으로 볼 수 있습니다. 스토리지 IO 사용률 메트릭을 사용하여 잠재적 디스크 제한 문제를 해결하거나 경고합니다. 비용 최적화에 버스팅을 사용하는 경우 크레딧 백분율 메트릭을 모니터링하여 추가 최적화 기회를 식별합니다.

• 게스트 OS 관점은 기본 디스크 기술에 관계없이 워크로드 운영자가 볼 메트릭을 나타냅니다. VM 인사이트는 사용된 논리 디스크 공간 및 디스크 IOPS 및 처리량에 대한 OS 커널의 관점과 같은 연결된 디스크의 주요 메트릭에 권장됩니다.

애플리케이션 수준 모니터링

참조 구현이 사용되지 않더라도 Application Insights 는 확장성을 위해 APM(애플리케이션 성능 관리)으로 프로비전됩니다. Application Insights는 애플리케이션에서 데이터를 수집하고 해당 데이터를 Log Analytics 작업 영역으로 보냅니다. 워크로드 애플리케이션에서 해당 데이터를 시각화할 수도 있습니다.

애플리케이션 상태 확장은 확장 집합에서 각 VM 인스턴스의 이진 상태를 모니터링하고 확장 집합 자동 인스턴스 복구를 사용하여 필요한 경우 인스턴스 복구를 수행하기 위해 VM에 배포됩니다. Application Gateway 및 내부 Azure 부하 분산 장치 상태 프로브와 동일한 파일을 테스트하여 애플리케이션이 응답하는지 확인합니다.

업데이트 관리

워크로드의 보안 상태를 약화시키지 않도록 VM을 정기적으로 업데이트하고 패치해야 합니다. 패치의 조기 검색 및 적용을 위해 자동 및 주기적인 VM 평가를 권장합니다.

인프라 업데이트

Azure는 가상 머신에 대한 호스트 인프라의 안정성, 성능 및 보안을 향상시키기 위해 주기적으로 플랫폼을 업데이트합니다. 이러한 업데이트에는 호스팅 환경에서 소프트웨어 구성 요소 패치, 네트워킹 구성 요소 업그레이드 또는 하드웨어 서비스 해제 등이 포함됩니다. 업데이트 프로세스에 대한 자세한 내용은 Azure의 가상 머신에 대한 유지 관리를 참조하세요.

업데이트에 다시 부팅이 필요하지 않은 경우 호스트가 업데이트되는 동안 VM이 일시 중지되거나 VM이 이미 업데이트된 호스트로 실시간 마이그레이션됩니다. 유지 관리에 다시 부팅이 필요한 경우 계획된 유지 관리에 대한 알림이 표시됩니다. 또한 Azure는 편의상 유지 관리를 시작할 수 있는 기간도 제공합니다. 자체 유지 관리 기간 및 사용 가능한 옵션을 구성하는 방법에 대한 자세한 내용은 계획된 유지 관리 알림 처리를 참조 하세요.

일부 워크로드는 유지 관리를 위해 몇 초 동안 VM이 중지되거나 연결이 끊어지지 않을 수 있습니다. 영향을 주지 않는 업데이트 및 재부팅 없는 업데이트를 비롯한 모든 유지 관리 작업을 보다 자세히 제어하려면 유지 관리 구성을 참조 하세요. 유지 관리 구성을 만들면 모든 플랫폼 업데이트를 건너뛰고 편의상 업데이트를 적용할 수 있습니다. 이 사용자 지정 구성이 설정되면 Azure는 재부팅 없는 업데이트를 포함하여 영향을 주지 않는 모든 업데이트를 건너뜁니다. 자세한 내용은 유지 관리 구성을 사용하여 플랫폼 업데이트 관리를 참조 하세요.

OS(운영 체제) 이미지 업그레이드

OS 업그레이드를 수행할 때 테스트된 골든 이미지가 있습니다. 사용자 지정 이미지를 게시하기 위해 Azure 공유 이미지 갤러리 및 Azure Compute 갤러리를 사용하는 것이 좋습니다. 게시자가 새 이미지를 게시할 때마다 롤링 방식으로 인스턴스의 일괄 처리를 업그레이드하는 프로세스가 있어야 합니다.

VM 이미지는 수명이 다하기 전에 사용 중지하여 노출 영역을 줄입니다.

자동화 프로세스는 추가 용량으로 오버프로비전을 고려해야 합니다.

Azure 업데이트 관리를 사용하여 Azure에서 Windows 및 Linux 가상 머신에 대한 OS 업데이트를 관리할 수 있습니다. Azure Update Manager는 Azure, 온-프레미스 및 다중 클라우드 환경에서 Windows 및 Linux 머신에 대한 소프트웨어 업데이트를 관리하고 관리하는 SaaS 솔루션을 제공합니다.

게스트 OS 패치

Azure VM은 자동 VM 게스트 패치 옵션을 제공합니다. 이 서비스를 사용하도록 설정하면 VM이 주기적으로 평가되고 사용 가능한 패치가 분류됩니다. 보류 중인 패치에 대한 일일 평가를 허용하려면 평가 모드를 사용하는 것이 좋습니다. 그러나 주문형 평가는 패치 적용을 트리거하지 않습니다. 평가 모드를 사용하도록 설정하지 않은 경우 보류 중인 업데이트를 수동으로 검색할 수 있습니다.

중요 또는 보안으로 분류된 패치만 모든 Azure 지역에 자동으로 적용됩니다. 다른 패치를 적용하는 사용자 지정 업데이트 관리 프로세스를 정의합니다.

거버넌스의 경우 Virtual Machine Scale Sets Azure Policy에서 자동 OS 이미지 패치 필요를 고려합니다.

자동 패치는 시스템에 부담을 줍니다. VM은 리소스를 사용하고 업데이트 중에 다시 부팅될 수 있으므로 중단될 수 있습니다. 부하 관리에는 오버 프로비전이 권장됩니다. 동시 업데이트를 방지하고 고가용성을 위해 영역당 두 개 이상의 인스턴스를 유지 관리하기 위해 다른 가용성 영역 VM을 배포합니다. 동일한 지역의 VM은 시간이 지남에 따라 조정되어야 하는 다른 패치를 받을 수 있습니다.

오버프로비전과 관련된 비용의 장단점에 유의하세요.

상태 검사는 자동 VM 게스트 패치의 일부로 포함됩니다. 이러한 검사는 성공적인 패치 애플리케이션을 확인하고 문제를 검색합니다.

패치를 적용하기 위한 사용자 지정 프로세스가 있는 경우 패치 원본에 프라이빗 리포지토리를 사용합니다. 이렇게 하면 업데이트가 성능 또는 보안에 부정적인 영향을 주지 않도록 패치를 테스트하는 데 더 나은 제어를 제공합니다.

자세한 내용은 Azure VM에 대한 자동 VM 게스트 패치를 참조 하세요.

안정성

이 아키텍처는 가용성 영역을 기본 요소로 사용하여 안정성 문제를 해결합니다.

이 설정에서 개별 VM은 단일 영역에 연결됩니다. 오류가 발생하면 Virtual Machine Scale Sets를 사용하여 이러한 VM을 다른 VM 인스턴스로 쉽게 바꿀 수 있습니다.

이 아키텍처의 다른 모든 구성 요소는 다음과 같습니다.

• 영역 중복은 Application Gateway 또는 공용 IP와 같은 고가용성을 위해 여러 영역에 복제됨을 의미합니다.
• 영역 복원력은 Key Vault와 같은 영역 오류를 견딜 수 있음을 의미합니다.
• 지역 간 또는 전역적으로 사용할 수 있는 지역 또는 전역 리소스(예: Microsoft Entra ID).

워크로드 디자인은 애플리케이션 코드, 인프라 및 운영에 안정성 보증을 통합해야 합니다. 다음 섹션에서는 워크로드가 오류에 대해 복원력이 있고 인프라 수준에서 중단이 있는 경우 복구할 수 있도록 하기 위한 몇 가지 전략을 보여 줍니다.

아키텍처에 사용되는 전략은 Azure Well-Architected Framework에 제공된 안정성 디자인 검토 검사 목록을 기반으로 합니다. 섹션에는 해당 검사 목록의 권장 사항으로 주석이 추가됩니다.

애플리케이션이 배포되지 않으므로 애플리케이션 코드의 복원력은 이 아키텍처의 범위를 벗어야 합니다. 검사 목록의 모든 권장 사항을 검토하고 해당하는 경우 워크로드에 채택하는 것이 좋습니다.

사용자 흐름당 안정성 보증 우선 순위 지정

대부분의 디자인에는 각각 고유한 비즈니스 요구 사항 집합이 있는 여러 사용자 흐름이 있습니다. 이러한 흐름 중 일부가 최고 수준의 보증을 필요로 하는 것은 아니므로 세분화는 안정성 전략으로 권장됩니다. 각 세그먼트를 독립적으로 관리하여 한 세그먼트가 다른 세그먼트에 영향을 주지 않도록 하고 각 계층에서 적절한 수준의 복원력을 제공할 수 있습니다. 또한 이 접근 방식을 통해 시스템을 유연하게 만들 수 있습니다.

이 아키텍처에서 애플리케이션 계층은 구분을 구현합니다. 프런트 엔드 및 백 엔드 계층에 대해 별도의 확장 집합이 프로비전됩니다. 이러한 분리를 통해 각 계층을 독립적으로 스케일링할 수 있으므로 특정 요구 사항에 따라 디자인 패턴을 구현할 수 있습니다.

잘 설계된 프레임워크: RE:02 - 흐름 식별 및 평가에 대한 권장 사항을 참조하세요.

잠재적 오류 지점 식별

모든 아키텍처는 오류에 취약합니다. 오류 모드 분석을 실행하면 오류를 예측하고 완화를 준비할 수 있습니다. 이 아키텍처의 몇 가지 잠재적인 오류 지점은 다음과 같습니다.

구성 요소	위험	Likelihood	효과/완화/참고	Outage
Microsoft Entra ID	잘못된 구성	중간	Ops 사용자가 로그인할 수 없습니다. 다운스트림 효과가 없습니다. 기술 지원팀은 구성 문제를 ID 팀에 보고합니다.	None
Application Gateway	잘못된 구성	중간	배포하는 동안 잘못된 구성을 catch해야 합니다. 구성 업데이트 중에 이러한 오류가 발생하는 경우 DevOps 팀은 변경 내용을 롤백해야 합니다. v2 SKU를 사용하는 대부분의 배포는 프로비저닝하는 데 약 6분이 소요됩니다. 그러나 배포 유형에 따라 시간이 더 오래 걸릴 수 있습니다. 예를 들어 인스턴스가 많이 있는 여러 가용성 영역에 배포하는 경우 6분 넘게 걸릴 수 있습니다.	전체
Application Gateway	DDoS 공격	중간	중단 가능성이 있습니다. Microsoft는 DDoS(L3 및 L4) 보호를 관리합니다. L7 공격으로 인한 잠재적인 위험.	전체
Virtual Machine Scale Sets	서비스 중단	낮음	자동 복구를 트리거하는 비정상 VM 인스턴스가 있는 경우 워크로드 중단이 발생할 수 있습니다. 수정할 Microsoft에 종속됩니다.	잠재적인 중단
Virtual Machine Scale Sets	가용성 영역 중단	낮음	아무런 영향이 없습니다. 확장 집합은 영역 중복으로 배포됩니다.	None

잘 설계된 프레임워크: RE:03 - 오류 모드 분석을 수행하기 위한 권장 사항을 참조하세요.

안정성 대상

디자인을 결정하려면 워크로드의 SLO(복합 서비스 수준 목표)와 같은 안정성 목표를 계산하는 것이 중요합니다. 이렇게 하려면 아키텍처에 사용되는 Azure 서비스에서 제공하는 SLA(서비스 수준 계약)를 이해해야 합니다. 워크로드 SLO는 Azure에서 보장하는 SLA보다 높지 않아야 합니다. VM 및 해당 종속성, 네트워킹 및 스토리지 옵션에서 각 구성 요소를 주의 깊게 검토합니다.

다음은 대략적인 복합 SLO를 제공하는 것이 주요 목표인 계산 예제입니다. 대략적인 지침이지만 비슷한 항목에 도달해야 합니다. 아키텍처를 수정하지 않는 한 동일한 흐름에 대해 더 높은 최대 복합 SLO를 얻을 수 없습니다.

작업 흐름

구성 요소	SLO
Microsoft Entra ID	99.99%
Azure Bastion	99.95%

복합 SLO: 99.94% | 연간 가동 중지 시간: 0d 5h 15m 20s

앱 사용자 흐름

구성 요소	SLO
Application Gateway	99.95%
Azure Load Balancer(내부)	99.99%
Premium Storage를 사용하는 프런트 엔드 VM(복합 SLO)	99.70%
Premium Storage를 사용하는 백 엔드 VM(복합 SLO)	99.70%

복합 SLO: 99.34% | 연간 가동 중지 시간: 2d 9h 42m 18s

앞의 예제에서는 VM과 연결된 디스크와 같은 VM 및 종속성의 안정성이 포함됩니다. 디스크 스토리지와 연결된 SLA는 전반적인 안정성에 영향을 줍니다.

복합 SLO를 계산할 때 몇 가지 문제가 있습니다. 다양한 서비스 계층에 서로 다른 SLA가 있을 수 있으며 안정성 목표를 설정하는 재정적으로 지원되는 보증이 포함되는 경우가 많습니다. 마지막으로 SLA가 정의되지 않은 아키텍처의 구성 요소가 있을 수 있습니다. 예를 들어 네트워킹 측면에서 NIC 및 가상 네트워크에는 자체 SLA가 없습니다.

비즈니스 요구 사항 및 해당 대상은 명확하게 정의되고 계산에 고려되어야 합니다. 조직에서 적용되는 서비스 제한 및 기타 제약 조건에 유의하세요. 구독을 다른 워크로드와 공유하면 VM에 사용할 수 있는 리소스에 영향을 미칠 수 있습니다. 워크로드가 VM에 사용할 수 있는 제한된 수의 코어를 사용하도록 허용될 수 있습니다. 구독의 리소스 사용량을 이해하면 VM을 보다 효과적으로 디자인하는 데 도움이 될 수 있습니다.

잘 설계된 프레임워크: RE:04 - 안정성 대상을 정의하기 위한 권장 사항을 참조하세요.

중복

이 아키텍처는 여러 구성 요소에 대해 영역 중복성을 사용합니다. 각 영역은 독립된 전원, 냉각 및 네트워킹이 있는 하나 이상의 데이터 센터로 구성됩니다. 인스턴스를 별도의 영역에서 실행하면 데이터 센터 오류로부터 애플리케이션을 보호합니다.

• Virtual Machine Scale Sets는 지정된 수의 인스턴스를 할당하고 가용성 영역 및 장애 도메인에 균등하게 배포합니다. 이 배포는 권장되는 최대 분산 기능을 통해 달성됩니다. 장애 도메인에 VM 인스턴스를 분산하면 모든 VM이 동시에 업데이트되지 않습니다.

  세 개의 가용성 영역이 있는 시나리오를 고려합니다. 인스턴스가 세 개 있는 경우 각 인스턴스는 다른 가용성 영역에 할당되고 다른 장애 도메인에 배치됩니다. Azure는 각 가용성 영역에서 한 번에 하나의 장애 도메인만 업데이트되도록 보장합니다. 그러나 세 가지 가용성 영역에서 VM을 호스팅하는 세 개의 장애 도메인이 모두 동시에 업데이트되는 상황이 있을 수 있습니다. 모든 영역 및 도메인에 영향을 줍니다. 각 영역에 인스턴스가 두 개 이상 있으면 업그레이드하는 동안 버퍼가 제공됩니다.

• 관리 디스크는 동일한 지역의 VM에만 연결할 수 있습니다. 해당 가용성은 일반적으로 VM의 가용성에 영향을 줍니다. 단일 지역 배포의 경우 영역 오류를 견딜 수 있도록 중복성을 위해 디스크를 구성할 수 있습니다. 이 아키텍처에서 데이터 디스크는 백 엔드 VM에서 ZRS(영역 중복 스토리지)로 구성됩니다. 가용성 영역을 활용하려면 복구 전략이 필요합니다. 복구 전략은 솔루션을 다시 배포하는 것입니다. 영역 오류에서 복구할 준비가 된 대체 가용성 영역에서 컴퓨팅을 미리 프로비전하는 것이 가장 좋습니다.

• 영역 중복 Application Gateway 또는 표준 부하 분산 장치는 단일 IP 주소를 사용하여 영역 간 VM으로 트래픽을 라우팅하여 영역 오류가 발생하더라도 연속성을 보장할 수 있습니다. 이러한 서비스는 상태 프로브를 사용하여 VM 가용성을 확인합니다. 지역의 한 영역이 계속 작동하면 다른 영역의 잠재적 오류에도 불구하고 라우팅이 계속됩니다. 그러나 영역 간 라우팅은 영역 내 라우팅에 비해 대기 시간이 더 높을 수 있습니다.

  이 아키텍처에 사용되는 모든 공용 IP는 영역 중복입니다.

• Azure는 Key Vault와 같은 안정성을 높이기 위해 영역 복원력 있는 서비스를 제공합니다.

• Azure 전역 리소스는 항상 사용할 수 있으며 필요한 경우 기본 ID 공급자인 Microsoft Entra ID와 같은 다른 지역으로 전환할 수 있습니다.

잘 설계된 프레임워크: RE:05 - 중복성을 위한 디자인에 대한 권장 사항을 참조하세요.

크기 조정 전략

서비스 수준 저하 및 오류를 방지하려면 안정적인 크기 조정 작업을 보장합니다. 워크로드를 가로로(스케일 아웃), 세로(스케일 업) 또는 두 방법의 조합을 사용합니다. Azure Monitor 자동 크기 조정을 사용하여 필요한 것보다 더 많은 용량을 할당하고 불필요한 비용을 발생시키지 않고 애플리케이션에 대한 수요를 지원하기에 충분한 리소스를 프로비전합니다.

자동 크기 조정을 사용하면 시간, 일정 또는 메트릭과 같은 다양한 이벤트 유형에 따라 다른 프로필을 정의할 수 있습니다. 메트릭 기반 프로필은 Azure Monitor 에이전트를 설치하여 수집해야 하는 기본 제공 메트릭(호스트 기반) 또는 더 자세한 메트릭(게스트 내 VM 메트릭)을 사용할 수 있습니다. 모든 프로필에는 스케일 아웃(증가) 및 규모 감축(감소)에 대한 규칙이 포함되어 있습니다. 디자인된 프로필을 기반으로 다양한 크기 조정 시나리오를 탐색하고 일련의 반대 규모 이벤트를 유발할 수 있는 잠재적 루프 조건을 평가하는 것이 좋습니다. Azure Monitor는 다시 크기 조정되기 전에 대기 시간 동안 대기하여 이 상황을 완화하려고 시도합니다.

유연한 모드의 Azure Virtual Machine Scale Sets는 다른 유형의 환경을 지원하지만 여러 프로필의 자동 크기 조정은 지원되지 않습니다. 둘 이상의 VM 유형으로 자동 크기 조정을 사용하려는 경우 다른 확장 집합을 만들어 개별적으로 관리하는 것이 좋습니다.

VM 인스턴스를 만들거나 삭제할 때 부트스트랩, 정상 종료, 워크로드 및 모든 종속성 설치, 디스크 관리와 같은 다른 측면을 고려합니다.

상태 저장 워크로드에는 워크로드 인스턴스를 초과하여 사용해야 하는 관리 디스크에 대한 추가 관리가 필요할 수 있습니다. 워크로드 데이터의 일관성, 동기화, 복제 및 무결성을 위해 크기 조정 이벤트에서 데이터 관리를 위한 워크로드를 디자인합니다. 이러한 시나리오의 경우 확장 집합에 미리 채워진 디스크를 추가하는 것이 좋습니다. 데이터에 액세스할 때 병목 상태를 방지하기 위해 크기 조정을 사용하는 경우 분할 및 분할을 계획합니다. 자세한 내용은 자동 크기 조정 모범 사례를 참조 하세요.

잘 설계된 프레임워크: RE:06 - 신뢰할 수 있는 크기 조정 전략을 설계하기 위한 권장 사항을 참조하세요.

자가 복구 및 복구 기능

가상 머신 확장 집합에서 자동 인스턴스 복구 를 사용하도록 설정하여 VM 오류로부터 복구를 자동화합니다. 애플리케이션 상태 확장은 응답하지 않는 VM 및 애플리케이션 검색을 지원하기 위해 VM에 배포됩니다. 이러한 인스턴스의 경우 복구 작업이 자동으로 트리거됩니다.

잘 설계된 프레임워크: 자기 치유 및 자기 보존에 대한 권장 사항을 참조하세요.

보안

이 아키텍처는 Azure Well-Architected Framework에 제공된 보안 디자인 검토 검사 목록에 제공된 보안 보증의 일부를 보여 줍니다. 섹션에는 해당 검사 목록의 권장 사항으로 주석이 추가됩니다.

보안은 기술 컨트롤만을 참조하는 것이 아닙니다. 보안 핵심 요소의 작동 측면을 이해하려면 전체 검사 목록을 따르는 것이 좋습니다.

세분화

• 네트워크 세분화 워크로드 리소스는 인터넷에서 격리를 제공하는 가상 네트워크에 배치됩니다. 가상 네트워크 내에서 서브넷을 신뢰 경계로 사용할 수 있습니다. 하나의 서브넷에서 트랜잭션을 처리하는 데 필요한 관련 리소스를 공동 배치합니다. 이 아키텍처에서 가상 네트워크는 애플리케이션의 논리적 그룹화 및 워크로드의 일부로 사용되는 다양한 Azure 서비스의 목적에 따라 서브넷으로 나뉩니다.

  서브넷 세분화의 장점은 서브넷에서 들어오고 나가는 트래픽을 제어하는 경계에 보안 컨트롤을 배치하여 워크로드 리소스에 대한 액세스를 제한할 수 있다는 것입니다.

• ID 구분입니다. 작업을 수행하기에 충분한 권한이 있는 다른 ID에 고유 역할을 할당합니다. 이 아키텍처는 Microsoft Entra ID에서 관리하는 ID 를 사용하여 리소스에 대한 액세스를 분할합니다.

• 리소스 구분. 애플리케이션은 계층별로 별도의 확장 집합으로 분할되므로 애플리케이션 구성 요소가 공동 배치되지 않습니다.

잘 설계된 프레임워크: SE:04 - 세분화 전략을 빌드하기 위한 권장 사항을 참조하세요.

ID 및 액세스 관리

사용자와 서비스 모두의 인증 및 권한 부여에는 Microsoft Entra ID를 사용하는 것이 좋습니다.

VM에 액세스하려면 Microsoft Entra ID 인증으로 제어되고 보안 그룹에서 지원되는 사용자 계정이 필요합니다. 이 아키텍처는 모든 VM에 Microsoft Entra ID 인증 확장을 배포하여 지원을 제공합니다. 사용자 사용자는 조직의 Microsoft Entra ID 테넌트에서 회사 ID를 사용하는 것이 좋습니다. 또한 서비스 주체 기반 액세스가 함수 간에 공유되지 않는지 확인합니다.

VM과 같은 워크로드 리소스는 할당된 관리 ID를 사용하여 다른 리소스에 인증합니다. 이러한 ID는 Microsoft Entra ID 서비스 주체를 기반으로 자동으로 관리됩니다.

예를 들어 Key Vault 확장은 VM에 설치되어 인증서가 있는 VM을 부팅합니다. 이 아키텍처 에서 사용자 할당 관리 ID 는 Application Gateway, 프런트 엔드 VM 및 백 엔드 VM에서 Key Vault에 액세스하는 데 사용됩니다. 이러한 관리 ID는 배포 중에 구성되며 Key Vault에 대해 인증하는 데 사용됩니다. Key Vault의 액세스 정책은 이전 관리 ID의 요청만 수락하도록 구성됩니다.

기준 아키텍처는 시스템 할당 및 사용자 할당 관리 ID를 혼합하여 사용합니다. 이러한 ID는 다른 Azure 리소스에 액세스할 때 권한 부여 목적으로 Microsoft Entra ID를 사용하는 데 필요합니다.

잘 설계된 프레임워크: SE:05 - ID 및 액세스 관리에 대한 권장 사항을 참조하세요.

네트워크 제어

• 수신 트래픽. 워크로드 VM은 공용 인터넷에 직접 노출되지 않습니다. 각 VM는 개인 IP 주소를 사용합니다. 워크로드 사용자는 Application Gateway의 공용 IP 주소를 사용하여 연결합니다.

  Application Gateway와 통합된 웹 애플리케이션 방화벽을 통해 더 많은 보안이 제공됩니다. 인바운드 트래픽을 검사하고 적절한 조치를 취할 수 있는 규칙이 있습니다. WAF는 알려진 공격을 방지하는 OWASP(Open Web Application Security Project) 취약성을 추적합니다.

• 송신 트래픽. VM 서브넷의 아웃바운드 NSG 규칙을 제외하고는 아웃바운드 트래픽에 대한 컨트롤이 없습니다. 모든 아웃바운드 인터넷 트래픽은 단일 방화벽을 통해 흐르는 것이 좋습니다. 이 방화벽은 일반적으로 조직에서 제공하는 중앙 서비스입니다. 이 사용 사례는 Azure 랜딩 존의 가상 머신 기준 아키텍처에 표시됩니다.

• 동서 교통. 서브넷 간의 트래픽 흐름은 세분화된 보안 규칙을 적용하여 제한됩니다.

  NSG(네트워크 보안 그룹) 는 IP 주소 범위, 포트 및 프로토콜과 같은 매개 변수를 기반으로 서브넷 간의 트래픽을 제한하기 위해 배치됩니다. ASG(애플리케이션 보안 그룹) 는 프런트 엔드 및 백 엔드 VM에 배치됩니다. NSG와 함께 VM을 오가는 트래픽을 필터링하는 데 사용됩니다.

• 운영 트래픽. 워크로드에 대한 보안 운영 액세스는 공용 IP의 필요성을 제거하는 Azure Bastion을 통해 제공하는 것이 좋습니다. 이 아키텍처에서 해당 통신은 SSH를 통해 수행되며 Windows 및 Linux VM 모두에서 지원됩니다. Microsoft Entra ID는 해당 VM 확장을 사용하여 두 VM 유형 모두에 대해 SSH와 통합됩니다. 이러한 통합을 통해 Microsoft Entra ID를 통해 운영자의 ID를 인증하고 권한을 부여할 수 있습니다.

  또는 자체 서브넷에 배포된 별도의 VM을 점프 상자로 사용하여 선택한 관리자 및 문제 해결 도구를 설치할 수 있습니다. 운영자는 Azure Bastion 호스트를 통해 점프 상자에 액세스합니다. 그런 다음 점프 상자에서 부하 분산 장치 뒤에 있는 VM에 로그인합니다.

  이 아키텍처에서는 트래픽을 제한하는 NSG 규칙을 사용하여 운영 트래픽을 보호하며 , VM에서 JIT(Just-In-Time) VM 액세스를 사용하도록 설정합니다. 이 클라우드용 Microsoft Defender 기능을 사용하면 선택한 포트에 대한 임시 인바운드 액세스를 허용합니다.

  보안을 강화하려면 Microsoft Entra PIM(Privileged Identity Management)을 사용합니다. PIM은 조직의 중요한 리소스에 대한 액세스를 관리, 제어 및 모니터링할 수 있는 Microsoft Entra ID의 서비스입니다. PIM은 시간 기반 및 승인 기반 역할을 활성화하여 리소스에 대해 액세스 권한이 과도하거나 불필요한 또는 잘못 사용될 위험을 줄입니다.

• PaaS(Platform as a Service) 서비스에 대한 프라이빗 연결. VM과 Key Vault 간의 통신은 Private Link를 통해 이루어집니다. 이 서비스에는 별도의 서브넷에 배치되는 프라이빗 엔드포인트가 필요합니다.

• DDoS 보호 Application Gateway 및 Azure Bastion Host에서 노출하는 공용 IP에서 Azure DDoS Protection 을 사용하도록 설정하여 위협을 감지하는 것이 좋습니다. DDoS Protection은 모니터를 통해 경고, 원격 분석 및 분석도 제공합니다. 자세한 내용은 Azure DDoS Protection: 모범 사례 및 참조 아키텍처를 참조하세요.

잘 설계된 프레임워크: SE:06 - 네트워킹 및 연결에 대한 권장 사항을 참조하세요.

암호화

• 전송 중 데이터. 사용자와 Application Gateway 공용 IP 간의 사용자 트래픽은 외부 인증서를 사용하여 암호화됩니다. 애플리케이션 게이트웨이와 프런트 엔드 VM 간의 트래픽과 프런트 엔드 VM과 백 엔드 VM 간의 트래픽은 내부 인증서를 사용하여 암호화됩니다. 두 인증서는 모두 Key Vault에 저장됩니다.

  • app.contoso.com: 클라이언트 및 Application Gateway에서 보안 공용 인터넷 트래픽에 사용하는 외부 인증서입니다.
  • *.workload.contoso.com: 인프라 구성 요소에서 보안 내부 트래픽에 사용하는 와일드카드 인증서입니다.

• 미사용 데이터. 로그 데이터는 VM에 연결된 관리 디스크에 저장됩니다. 해당 데이터는 Azure에서 플랫폼 제공 암호화를 사용하여 자동으로 암호화됩니다.

잘 설계된 프레임워크: SE:07 - 데이터 암호화에 대한 권장 사항을 참조하세요.

비밀 관리

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

Key Vault 는 TLS 인증서를 비롯한 비밀의 보안 관리를 제공합니다. 이 아키텍처에서 TLS 인증서는 Key Vault에 저장되고 프로비전 프로세스 중에 Application Gateway 및 VM의 관리 ID에 의해 검색됩니다. 초기 설정 후 이러한 리소스는 인증서를 새로 고칠 때만 Key Vault에 액세스합니다.

VM은 Key Vault VM 확장을 사용하여 모니터링되는 인증서를 자동으로 새로 고칩니다. 로컬 인증서 저장소에서 변경 내용이 검색되면 확장은 Key Vault에서 해당 인증서를 검색하고 설치합니다. 확장은 인증서 콘텐츠 형식 PKCS #12 및 PEM을 지원합니다.

잘 설계된 프레임워크: SE:09 - 애플리케이션 비밀을 보호하기 위한 권장 사항을 참조하세요.

비용 최적화

비용 제약 조건을 염두에 두고 워크로드 요구 사항을 충족해야 합니다. 아키텍처에 사용되는 전략은 Azure Well-Architected Framework에 제공된 비용 최적화 디자인 검토 검사 목록을 기반으로 합니다. 이 섹션에서는 비용을 최적화하기 위한 몇 가지 옵션에 대해 설명하고 해당 검사 목록의 권장 사항으로 주석을 추가합니다.

구성 요소 비용

범용 이미지를 사용하는 대신 워크로드에 최적화된 VM 이미지를 선택합니다. 이 아키텍처에서는 각각 30GB인 Windows 및 Linux 둘 다에 대해 상대적으로 작은 VM 이미지가 선택됩니다. 이미지가 작을수록 디스크가 있는 VM SKU도 작아서 비용이 절감되고 리소스 소비가 감소하며 배포 및 부팅 시간이 빨라집니다. 이점은 노출 영역이 감소하여 보안이 강화된 것입니다.

크기 제한을 사용하여 로그 회전을 구현하는 것은 또 다른 비용 절감 전략입니다. 작은 데이터 디스크를 사용할 수 있으므로 비용이 절감될 수 있습니다. 이 아키텍처의 구현에서는 4GB 디스크를 사용합니다.

임시 OS 디스크를 사용하면 비용을 절감하고 성능을 향상시킬 수도 있습니다. 이러한 디스크는 VM으로 프로비전된 캐시 디스크에 설치되어 있으므로 이미 지불한 VM 리소스를 사용하도록 설계되었습니다. 기존 영구 디스크와 관련된 스토리지 비용을 제거합니다. 이러한 디스크는 일시적이므로 장기 데이터 스토리지와 관련된 비용은 없습니다.

잘 설계된 프레임워크: CO:07 - 구성 요소 비용을 최적화하기 위한 권장 사항을 참조하세요.

흐름 비용

흐름의 중요도에 따라 컴퓨팅 리소스를 선택합니다. 확정되지 않은 길이를 허용하도록 설계된 흐름의 경우 Virtual Machine Scale Sets 유연한 오케스트레이션 모드에서 스폿 VM을 사용하는 것이 좋습니다. 이 방법은 우선 순위가 낮은 VM에서 우선 순위가 낮은 흐름을 호스팅하는 데 효과적일 수 있습니다. 이 전략을 통해 다양한 흐름의 요구 사항을 충족하면서 비용 최적화를 수행할 수 있습니다.

잘 설계된 프레임워크: CO:09 - 흐름 비용 최적화를 위한 권장 사항을 참조하세요.

비용 크기 조정

주 비용 드라이버가 인스턴스 수인 경우 VM의 크기 또는 성능을 늘려 스케일 업하는 것이 더 비용 효율적일 수 있습니다. 이 방법을 사용하면 다음과 같은 여러 영역에서 비용을 절감할 수 있습니다.

• 소프트웨어 라이선스. VM이 클수록 더 많은 워크로드를 처리할 수 있으므로 필요한 소프트웨어 라이선스 수가 감소할 수 있습니다.
• 유지 관리 시간: VM 수가 적고 VM이 많을수록 운영 비용이 절감됩니다.
• 부하 분산: VM 수가 적을수록 부하 분산 비용이 절감될 수 있습니다. 예를 들어 이 아키텍처에는 프런트의 애플리케이션 게이트웨이 및 중간에 내부 부하 분산 장치와 같은 여러 계층의 부하 분산이 있습니다. 더 많은 수의 인스턴스를 관리해야 하는 경우 부하 분산 비용이 증가합니다.
• 디스크 스토리지. 상태 저장 애플리케이션이 있는 경우 더 많은 인스턴스에 연결된 관리 디스크가 더 필요하므로 스토리지 비용이 증가합니다.

잘 설계된 프레임워크: CO:12 - 크기 조정 비용을 최적화하기 위한 권장 사항을 참조하세요.

운영 비용

자동 VM 게스트 패치는 수동 패치 및 관련 유지 관리 비용의 오버헤드를 줄입니다. 이 작업은 시스템을 보다 안전하게 만드는 데 도움이 될 뿐만 아니라 리소스 할당을 최적화하여 전반적인 비용 효율성에 기여합니다.

잘 설계된 프레임워크: CO:13 - 인력 시간을 최적화하기 위한 권장 사항을 참조하세요.

시나리오 배포

이 참조 아키텍처에 대한 배포는 GitHub에서 사용할 수 있습니다.

관련 참고 자료

특정 Azure 서비스에 대한 자세한 내용은 제품 설명서를 참조하세요.

• Azure Virtual Machines
• Azure Virtual Machine Scale Sets
• Azure Virtual Network
• Azure 애플리케이션 게이트웨이 Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

다음 단계

데이터 계층에 대한 옵션을 표시하는 IaaS 참조 아키텍처를 검토합니다.

• Azure에서 SQL Server를 사용하는 Windows N 계층 애플리케이션