스폿 가상 머신에서 워크로드 빌드

이 문서에서는 Azure Spot Virtual Machines에서 빌드하는 방법에 대한 모범 사례를 설명합니다. 배포 가능한 예제 시나리오가 포함됩니다. 스폿 가상 머신(스폿 VM)은 일반 VM보다 저렴한 가격으로 컴퓨팅 용량에 대한 액세스를 제공합니다. 이 할인은 비용을 최적화하려는 조직에 적합한 옵션입니다. 그러나 저축은 절상과 함께 제공됩니다. 스폿 VM은 언제든지 제거할 수 있으므로 컴퓨팅 리소스에 대한 액세스 권한이 손실됩니다. 스폿 VM에서 실행되는 워크로드는 컴퓨팅에서 이러한 중단을 처리할 수 있어야 합니다. 올바른 워크로드와 유연한 오케스트레이션 메커니즘은 성공의 열쇠입니다. 다음 권장 사항은 스폿 VM에서 빌드하는 방법을 설명합니다.

스폿 VM 이해

기술 수준에서 스폿 VM은 일반 VM과 동일합니다. 동일한 성능으로 변환되는 동일한 이미지, 하드웨어 및 디스크를 사용합니다. 스폿 VM과 일반 VM 간의 주요 차이점은 우선 순위와 가용성입니다. 스폿 VM은 컴퓨팅 용량에 액세스하는 데 우선 순위가 없으며 해당 컴퓨팅 용량에 액세스한 후에는 가용성을 보장하지 않습니다.

• 우선 순위 액세스가 없습니다. 일반 VM은 컴퓨팅 용량에 우선적으로 액세스할 수 있습니다. 요청 시 컴퓨팅 용량에 액세스합니다. 그러나 스폿 VM은 예비 컴퓨팅 용량이 있는 경우에만 배포됩니다. 또한 일반 VM에 기본 하드웨어가 필요하지 않은 경우에만 계속 실행됩니다.

• 가용성 보장이 없습니다. 스폿 VM에는 가용성 보장 또는 SLA(서비스 수준 계약)가 없습니다. 스폿 VM은 즉시 또는 배포 또는 제거 후 언제든지 컴퓨팅 용량에 대한 액세스 권한을 잃을 수 있습니다. 스폿 VM은 제거할 수 있으므로 더 저렴합니다. Azure에서 컴퓨팅 용량을 다시 필요로 하는 경우 제거 알림이 전송되고 스폿 VM이 제거됩니다. Azure는 실제 제거가 발생하기 전에 최소 30초 전에 사전 알림을 제공합니다. 자세한 내용은 제거 대한지속적으로 모니터링을 참조하세요.

스폿 VM 가격 책정 이해

스폿 VM은 일반 종량제 VM보다 최대 90% 저렴할 수 있습니다. 할인은 수요, VM 크기, 배포 지역 및 운영 체제에 따라 달라집니다. 비용 절감 예상을 얻으려면 Azure Spot Virtual Machines 가격 책정 도구 및 Spot Virtual Machines 가격 책정 개요참조하세요. Azure 소매 가격 API 쿼리하여 모든 SKU에 대한 스폿 가격을 프로그래밍 방식으로 가져올 수도 있습니다.

중단 가능한 워크로드 이해

스폿 VM은 몇 가지 일반적인 특성을 공유하는 중단 가능한 워크로드에 적합합니다. 중단 가능한 워크로드에는 최소한의 시간 제약 조건, 낮은 조직 우선 순위 및 짧은 처리 시간이 있습니다. 중요한 조직 프로세스에 해를 끼치지 않고 갑자기 중지하고 나중에 다시 시작할 수 있는 프로세스를 실행합니다. 중단 가능한 워크로드의 예로는 비프로덕션 환경에 대한 연속 통합 및 지속적인 배포 에이전트를 만드는 일괄 처리 애플리케이션, 데이터 분석 및 워크로드가 있습니다. 이러한 기능은 SLA, 고정 세션 및 상태 저장 데이터가 있는 일반 또는 중요 업무용 워크로드와 비교됩니다.

중단 불가능한 워크로드에서 스폿 VM을 사용할 수 있지만 컴퓨팅 용량의 유일한 원본이 되어서는 안 됩니다. 가동 시간 요구 사항을 충족하는 데 필요한 만큼 일반 VM을 사용합니다.

제거 이해

스폿 VM은 만든 후 SLA가 없으며 언제든지 컴퓨팅에 대한 액세스 권한을 잃을 수 있습니다. 이 컴퓨팅 손실을 제거호출합니다. 컴퓨팅 공급 및 수요 드라이브 제거. 특정 VM 크기에 대한 수요가 특정 수준을 초과하면 Azure는 스폿 VM을 제거하여 일반 VM에서 컴퓨팅을 사용할 수 있도록 합니다. 수요는 위치별입니다. 예를 들어 지역 A의 수요 증가는 지역 B의 스폿 VM에 영향을 주지 않습니다.

스폿 VM에는 제거에 영향을 주는 두 가지 구성 옵션이 있습니다. 이러한 구성은 스폿 VM의 제거 유형 및 제거 정책. 스폿 VM을 만들 때 이러한 구성을 설정합니다. 제거 형식은 제거 조건을 정의합니다. 제거 정책은 스폿 VM에 대한 제거 작업을 결정합니다.

제거 유형

용량 변경 또는 가격 변경으로 인해 제거가 발생합니다. 용량 및 가격 변경이 스폿 VM에 영향을 주는 방식은 VM을 만들 때 선택하는 제거 유형에 따라 달라집니다. 제거 유형은 제거 조건을 정의합니다. 제거 유형은 용량 전용 제거 및 가격 또는 용량 제거.

• 용량 전용 제거: 이 제거 유형은 초과 컴퓨팅 용량을 더 이상 사용할 수 없을 때 제거를 트리거합니다. 기본적으로 가격은 종량제 요금으로 제한됩니다. 종량제 VM 가격보다 더 많은 비용을 지불하지 않으려면 이 제거 유형을 사용합니다.

• 가격 또는 용량 제거: 이 제거 유형에는 두 개의 트리거가 있습니다. 초과 컴퓨팅 용량을 더 이상 사용할 수 없거나 VM 비용이 설정한 최대 가격을 초과하는 경우 Azure는 스폿 VM을 제거합니다. 이 제거 유형을 사용하면 종량제 가격보다 훨씬 낮은 최대 가격을 설정할 수 있습니다. 이 제거 유형을 사용하여 고유한 가격 한도를 설정합니다.

제거 정책

스폿 VM에 대해 선택한 제거 정책은 해당 오케스트레이션에 영향을 줍니다. 오케스트레이션은 제거를 처리하는 프로세스이며 이 문서의 뒷부분에서 설명합니다. 제거 정책은 중지/할당 취소 정책 및 삭제 정책.

중지/할당 취소 정책: 중지/할당 취소 정책은 워크로드가 동일한 위치 및 VM 유형 내에서 릴리스 용량을 기다릴 수 있는 경우에 이상적입니다. 중지/할당 취소 정책은 VM을 중지하고 기본 하드웨어로 임대를 종료합니다. 스폿 VM을 중지 및 할당 취소하는 것은 일반 VM을 중지 및 할당 취소하는 것과 같습니다. VM은 Azure에서 계속 액세스할 수 있으며 나중에 동일한 VM을 다시 시작할 수 있습니다. VM은 중지/할당 취소 정책을 사용하여 컴퓨팅 용량 및 비정적 IP 주소를 잃습니다. 그러나 VM 데이터 디스크는 남아 있으며 요금이 계속 부과됩니다. 또한 VM은 구독의 코어를 차지합니다. VM은 중지되거나 할당 취소된 경우에도 해당 지역 또는 영역에서 이동할 수 없습니다. 자세한 내용은 Power 상태 및 청구참조하세요.

삭제 정책: 워크로드가 위치 또는 VM 크기를 변경할 수 있는 경우 삭제 정책을 사용합니다. 위치 또는 VM 크기를 변경하면 VM을 더 빠르게 다시 배포할 수 있습니다. 삭제 정책은 VM 및 모든 데이터 디스크를 삭제합니다. VM은 구독의 코어를 차지하지 않습니다. 자세한 내용은 제거 정책참조하세요.

유연한 오케스트레이션을 위한 디자인

오케스트레이션은 제거 후 스폿 VM을 교체하는 프로세스입니다. 이는 안정적으로 중단 가능한 워크로드를 구축하기 위한 기반입니다. 좋은 오케스트레이션 시스템에는 기본 제공 유연성이 있습니다. 유연성은 오케스트레이션을 디자인하여 옵션을 사용하고, 여러 VM 크기를 사용하고, 다른 지역에 배포하고, 제거 인식을 가지며, 워크로드 안정성 및 속도를 개선하기 위해 다양한 제거 시나리오를 고려하도록 설계하는 것을 의미합니다.

속도를 위한 디자인

스폿 VM에서 실행되는 워크로드의 경우 컴퓨팅 용량이 중요합니다. 제거 가능성이 있으므로 할당된 컴퓨팅 시간을 이해하여 워크로드 속도의 우선 순위를 지정하는 정보에 입각한 디자인 결정을 내릴 수 있도록 합니다. 일반적으로 가지고 있는 컴퓨팅 시간을 최적화해야 합니다. 모든 필수 소프트웨어가 미리 설치된 VM 이미지를 빌드합니다. 사전 설치된 소프트웨어는 제거와 완전히 작동하는 애플리케이션 사이의 시간을 최소화하는 데 도움이 됩니다. 워크로드 목적에 영향을 주지 않는 프로세스에서 컴퓨팅 시간을 사용하지 마세요. 예를 들어 데이터 분석을 위한 워크로드는 대부분의 컴퓨팅 시간을 데이터 처리에 집중하고 제거 메타데이터 수집에 최대한 적은 시간을 할애해야 합니다. 애플리케이션에서 불필요한 프로세스를 제거합니다.

여러 VM 크기 및 위치 사용

유연성을 높이려면 여러 형식과 크기의 VM을 사용하도록 오케스트레이션을 빌드합니다. 목표는 제거된 VM을 대체할 오케스트레이션 옵션을 제공하는 것입니다. Azure에는 거의 동일한 가격에 비슷한 기능을 제공하는 VM의 유형과 크기가 다릅니다. 최소 vCPU 또는 코어, VM의 최소 RAM 및 최대 가격을 필터링합니다. 이 프로세스를 통해 예산에 맞는 여러 VM을 찾고 워크로드를 실행할 수 있는 충분한 능력을 갖출 수 있습니다.

VM의 각 유형에는 0개%-5%, 5개%-10개의%, 10개의%-15개의%, 15개의%-20%또는 20개 이상의%같은 백분율 범위로 표현되는 제거 속도가 있습니다. 제거 비율은 지역에 따라 다를 수 있습니다. 다른 지역에서 동일한 유형의 VM에 대해 더 나은 제거 속도를 찾을 수 있습니다. 포털의 각 VM 유형에 대한 제거 속도는 기본 탭에서 찾을 수 있습니다. 크기옆에 있는 가격 책정 기록 보기를 선택하거나 모든 크기확인합니다. Azure Resource Graph를 사용하여 프로그래밍 방식으로 스폿 VM 데이터를 가져올 수도 있습니다.

오케스트레이션 시스템에서는 스폿 배치 점수 기능을 사용하여 개별 스폿 배포의 성공 가능성을 평가하는 것이 좋습니다.

자세한 내용은 다음 리소스를 참조하세요.

• 제거 속도
• Resource Graph
• 자리 배치 점수

가장 유연한 제거 정책 사용

제거된 스폿 VM의 제거 정책은 교체 프로세스에 영향을 줍니다. 예를 들어 삭제 정책은 중지/할당 취소 정책보다 더 유연합니다.

• 먼저 삭제 정책을 고려합니다. 워크로드에서 정책을 처리할 수 있는 경우 삭제 정책을 사용합니다. 삭제를 통해 오케스트레이션은 대체 스폿 VM을 새 영역 및 지역에 배포할 수 있습니다. 이러한 배포 유연성은 워크로드가 중지되거나 할당 취소된 VM보다 더 빠르게 예비 컴퓨팅 용량을 찾는 데 도움이 될 수 있습니다. 중지되거나 할당 취소된 VM은 생성된 영역과 동일한 영역에서 예비 컴퓨팅 용량을 기다려야 합니다. 삭제 정책의 경우 제거를 모니터링하고 다양한 지역에 대한 배포를 오케스트레이션하거나 다른 VM SKU 또는 둘 다를 사용하는 외부 프로세스가 필요합니다.

• 중지/할당 취소 정책 이해: 중지/할당 취소 정책은 삭제 정책보다 유연성이 낮습니다. 스폿 VM은 동일한 지역 및 영역에 있어야 합니다. 중지되거나 할당 취소된 VM을 다른 위치로 이동할 수 없습니다. VM에는 고정된 위치가 있으므로 컴퓨팅 용량을 사용할 수 있게 될 때 VM을 다시 할당하기 위한 무언가가 필요합니다. 컴퓨팅 용량의 가용성을 예측할 수 있는 방법은 없습니다. 따라서 자동화된 일정 파이프라인을 사용하여 제거 후 재배포를 시도해야 합니다. 제거는 일정 파이프라인을 트리거해야 하며, 다시 배포 시도는 사용할 수 있게 될 때까지 컴퓨팅 용량을 지속적으로 확인해야 합니다.

제거를 지속적으로 모니터링

모니터링은 스폿 VM에서 워크로드 안정성의 핵심입니다. 스폿 VM은 만든 후 SLA가 없으며 언제든지 제거할 수 있습니다. 스폿 VM에서 워크로드 안정성을 개선하는 가장 좋은 방법은 제거될 시기를 예측하는 것입니다. 이 정보가 있는 경우 워크로드 정상 종료를 시도하고 자동화를 트리거하여 교체를 오케스트레이션할 수 있습니다.

• 예약된 이벤트 사용: 각 VM에 대해 예약된 이벤트 서비스를 사용합니다. Azure는 인프라 유지 관리가 영향을 줄 때 VM에 신호를 보냅니다. 제거는 인프라 유지 관리로 인정됩니다. Azure는 제거되기 최소 30초 전에 모든 VM에 Preempt 신호를 보냅니다. Scheduled Events 서비스를 사용하면 라우팅할 수 없는 고정 IP 주소 169.254.169.254엔드포인트를 쿼리하여 이 Preempt 신호를 캡처할 수 있습니다.

• 자주 쿼리 사용: 정상 종료를 오케스트레이션할 만큼 예약된 이벤트 엔드포인트를 자주 쿼리합니다. 예약된 이벤트 엔드포인트를 1초마다 쿼리할 수 있지만 모든 사용 사례에는 1초 빈도가 필요하지 않을 수 있습니다. 이러한 쿼리는 스폿 VM에서 실행되는 애플리케이션에서 제공해야 합니다. 쿼리는 외부 원본에서 올 수 없습니다. 결과적으로 쿼리는 VM 컴퓨팅 용량을 사용하고 주 워크로드에서 처리 능력을 도용합니다. 특정 상황에 맞게 경쟁 우선 순위의 균형을 유지해야 합니다.

• 오케스트레이션 자동화:Preempt 신호를 수집한 후에는 오케스트레이션이 해당 신호에 따라 작동합니다. 시간 제약 조건이 있는 경우 Preempt 신호는 워크로드를 정상적으로 종료하고 스폿 VM을 대체하는 자동화된 프로세스를 시작해야 합니다. 자세한 내용은 다음 리소스를 참조하세요.

  • 예약된 이벤트
  • 예약된 이벤트 유형
  • 엔드포인트 쿼리 빈도

배포 시스템 빌드

제거 후 새 스폿 VM을 배포하려면 오케스트레이션에 자동화된 파이프라인이 필요합니다. 파이프라인은 지속성을 보장하기 위해 중단 가능한 워크로드 외부에서 실행되어야 합니다. 배포 파이프라인은 스폿 VM에 대해 선택한 제거 정책에 따라 작동해야 합니다.

삭제 정책의 경우 다른 VM 크기를 사용하고 다른 지역에 배포하는 파이프라인을 빌드하는 것이 좋습니다. 중지/할당 취소 정책의 경우 배포 파이프라인에는 두 가지 고유한 작업이 필요합니다. VM을 처음 만들려면 파이프라인에서 올바른 크기의 VM을 올바른 위치에 배포해야 합니다. 제거된 VM의 경우 파이프라인이 작동할 때까지 VM을 다시 시작해야 합니다. Azure Monitor 경고와 Azure 함수의 조합은 배포 시스템을 자동화하는 한 가지 방법입니다. 파이프라인은 bicep 템플릿을 사용할 수 있습니다. 선언적이고 idempotent이며 인프라 배포에 대한 모범 사례를 나타냅니다.

즉시 제거 준비

Azure는 스폿 VM을 만드는 즉시 워크로드가 실행되기 전에 제거하도록 할 수 있습니다. 경우에 따라 스폿 VM을 만들기에 충분한 용량이 있을 수 있지만 지속되지는 않습니다. 스폿 VM은 생성 후 가용성 보장 또는 SLA가 없습니다. 오케스트레이션은 즉각적인 제거를 고려해야 합니다. Preempt 신호는 제거에 대한 최소 30초 사전 알림을 제공합니다.

즉시 제거를 준비하기 위해 VM 상태 검사를 오케스트레이션에 통합합니다. 즉시 제거를 위한 오케스트레이션은 예약된 이벤트 Preempt 신호에 따라 달라질 수 없습니다. VM 자체만 Preempt 신호를 쿼리할 수 있으며, 애플리케이션을 시작하고, 예약된 이벤트 엔드포인트를 쿼리하고, 정상적으로 종료할 시간이 충분하지 않습니다. 따라서 상태 검사는 워크로드 환경 외부에 있어야 합니다. 상태 검사는 스폿 VM의 상태를 모니터링하고 상태가 할당 취소로 변경되거나 중지하는 변경될 때 스폿 VM을 대체하기 위해 배포 파이프라인을 시작해야 합니다.

여러 동시 제거 계획

스폿 VM 클러스터를 실행하는 경우 여러 동시 제거를 견딜 수 있도록 워크로드를 설계합니다. 워크로드의 여러 스폿 VM을 동시에 제거할 수 있습니다. 여러 VM의 동시 제거는 애플리케이션의 처리량에 영향을 줄 수 있습니다. 이러한 상황을 방지하려면 배포 파이프라인이 여러 VM에서 신호를 수집하고 여러 대체 VM을 동시에 배포할 수 있어야 합니다.

정상적인 종료를 위한 디자인

VM 종료 프로세스는 30초 미만이어야 하며 제거 전에 VM을 종료할 수 있습니다. 종료에 걸리는 시간은 워크로드가 예약된 이벤트 엔드포인트를 쿼리하는 빈도에 따라 달라집니다. 엔드포인트를 쿼리하는 경우가 많을수록 종료 프로세스가 더 오래 걸릴 수 있습니다. 종료 프로세스는 리소스를 해제하고, 연결을 드레이닝하고, 이벤트 로그를 플러시해야 합니다. 컨텍스트를 유지하고 보다 효율적인 복구 전략을 빌드하기 위해 검사점을 정기적으로 만들고 저장해야 합니다. 검사점은 다음 VM에서 시작해야 하는 프로세스 또는 트랜잭션에 대한 정보일 뿐입니다. 이전 VM이 중단된 위치에서 VM을 다시 시작해야 하는지 또는 새 VM이 변경 내용을 되돌리고 전체 프로세스를 다시 시작해야 하는지 여부를 나타내야 합니다. 스토리지 계정과 같이 스폿 VM 환경 외부에 검사점을 저장합니다.

오케스트레이션 테스트

제거 이벤트를 시뮬레이션하여 개발/테스트 환경에서 오케스트레이션을 테스트합니다. 자세한 내용은 제거 시뮬레이트참조하세요.

idempotent 워크로드 디자인

idempotent 워크로드를 디자인하는 것이 좋습니다. 이벤트를 두 번 이상 처리하는 결과는 한 번 처리하는 것과 동일해야 합니다. 정상적인 종료를 보장하려는 노력에도 불구하고 퇴거로 인해 강제 종료가 발생할 수 있습니다. 강제 종료는 완료되기 전에 프로세스를 종료할 수 있습니다. Idempotent 워크로드는 결과를 변경하지 않고도 동일한 메시지를 두 번 이상 받을 수 있습니다. 자세한 내용은 Idempotency참조하세요.

애플리케이션 준비 기간 사용

대부분의 중단 가능한 워크로드는 애플리케이션을 실행합니다. 애플리케이션을 설치하고 시작하는 데 시간이 필요합니다. 또한 외부 스토리지에 연결하고 검사점에서 정보를 수집하는 데 시간이 필요합니다. 처리를 시작하기 전에 애플리케이션 준비 기간을 갖습니다. 준비 기간 동안 애플리케이션을 시작하고, 연결을 설정하고, 기여할 준비를 해야 합니다. 애플리케이션의 상태 유효성을 검사한 후에만 애플리케이션에서 데이터 처리를 시작하도록 허용합니다.

사용자 할당 관리 ID 구성

사용자 할당 관리 ID를 할당하여 인증 및 권한 부여 프로세스를 간소화합니다. 사용자 할당 관리 ID를 사용하면 코드에 자격 증명을 배치하지 않고 시스템 할당 관리 ID와 같은 단일 리소스에 연결되지 않습니다. 사용자 할당 관리 ID에는 오케스트레이션 중에 VM을 발견하기 위해 다시 사용하고 할당할 수 있는 Microsoft Entra ID의 권한 및 액세스 토큰이 포함됩니다. 스폿 VM 간 토큰 일관성은 오케스트레이션을 간소화하고 스폿 VM에 있는 워크로드 리소스에 대한 액세스를 간소화하는 데 도움이 됩니다.

시스템 할당 관리 ID를 사용하는 경우 새 스폿 VM이 Microsoft Entra ID와 다른 액세스 토큰을 가져올 수 있습니다. 시스템 할당 관리 ID를 사용해야 하는 경우 워크로드를 복원력 있게 만들어 응답을 403 Forbidden Error. 오케스트레이션은 올바른 권한이 있는 Microsoft Entra ID에서 토큰을 가져와야 합니다. 자세한 내용은 관리 ID참조하세요.

예제 시나리오

예제 시나리오는 인터럽트 가능한 워크로드로 한정되는 큐 처리 애플리케이션을 배포합니다. 시나리오의 스크립트는 예제로 사용됩니다. 이 시나리오에서는 리소스를 배포하기 위한 일회성 수동 푸시를 안내합니다. 이 구현에는 배포 파이프라인이 없습니다. 그러나 오케스트레이션 프로세스를 자동화하려면 배포 파이프라인이 필수적입니다. 다음 다이어그램은 예제 시나리오의 아키텍처를 보여줍니다.

예제 시나리오 아키텍처를 보여 주는

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

다음 워크플로는 이전 다이어그램에 해당합니다.

1. VM 애플리케이션 정의 : VM 애플리케이션 정의는 Azure 컴퓨팅 갤러리에 만들어집니다. 애플리케이션 이름, 위치, 운영 체제 및 메타데이터를 정의합니다. 애플리케이션 버전은 VM 애플리케이션 정의의 번호가 매겨진 버전입니다. 애플리케이션 버전은 VM 애플리케이션을 나타냅니다. 스폿 VM과 동일한 지역에 있어야 합니다. 애플리케이션 버전은 스토리지 계정의 원본 애플리케이션 패키지에 연결됩니다.

2. Storage 계정: 스토리지 계정은 원본 애플리케이션 패키지를 저장합니다. 이 아키텍처에서는 worker-0.1.0.tar.gz이라는 압축된 tar 파일입니다. 여기에는 두 개의 파일이 포함되어 있습니다. 한 파일은 .NET 작업자 애플리케이션을 설치하는 orchestrate.sh bash 스크립트입니다.

3. 스폿 VM: 스폿 VM이 배포됩니다. 애플리케이션 버전과 동일한 지역에 있어야 합니다. 배포 후 VM에 worker-0.1.0.tar.gz 다운로드합니다. bicep 템플릿은 표준 제품군 VM에 Ubuntu 이미지를 배포합니다. 이러한 구성은 이 애플리케이션의 요구 사항을 충족하며 애플리케이션에 대한 일반적인 권장 사항은 아닙니다.

4. Storage 큐: .NET 작업자에서 실행되는 다른 서비스에는 메시지 큐 논리가 포함되어 있습니다. Microsoft Entra ID는 역할 기반 액세스 제어를 사용하여 사용자 할당 ID를 사용하여 Azure Queue Storage의 스토리지 큐에 대한 스폿 VM 액세스 권한을 부여합니다.

5. .NET 작업자 애플리케이션 :orchestrate.sh 스크립트는 두 개의 백그라운드 서비스를 실행하는 .NET 작업자 애플리케이션을 설치합니다. 첫 번째 서비스는 예약된 이벤트 엔드포인트를 쿼리하고, Preempt 신호를 찾고, 이 신호를 두 번째 서비스로 보냅니다. 두 번째 서비스는 스토리지 큐에서 메시지를 처리하고 첫 번째 서비스에서 Preempt 신호를 수신 대기합니다. 두 번째 서비스는 신호를 받으면 스토리지 큐 처리를 중단하고 종료하기 시작합니다.

6. 예약된 이벤트 쿼리 엔드포인트 : API 요청이 정적 대체 불가능한 IP 주소 169.254.169.254전송됩니다. API 요청은 인프라 유지 관리 신호를 위해 예약된 이벤트 엔드포인트를 쿼리합니다.

7. Application Insights: 아키텍처는 학습 목적으로만 Application Insights를 사용합니다. 중단 가능한 워크로드 오케스트레이션의 필수 구성 요소는 아니지만 .NET 작업자 애플리케이션에서 원격 분석의 유효성을 검사할 수 있습니다. .NET 작업자 애플리케이션은 Application Insights에 원격 분석을 보냅니다. 자세한 내용은 .NET 애플리케이션 라이브 메트릭 사용참조하세요.

이 시나리오 배포

이 아키텍처를 배포하기 위한 템플릿, 스크립트 및 단계별 지침이 있는 중단 가능한 워크로드를 GitHub 리포지토리가 있습니다.

다음 단계

관련 리소스

• 다중 테넌트 솔루션 비용 관리 및 할당을 위한 아키텍처 접근 방식
• Azure Windows VM 실행
• Azure Linux VM 실행