스폿 가상 머신에서 워크로드를 빌드하는 방법

이 문서에서는 Azure 스폿 VM(가상 머신)에서 빌드하기 위한 모범 사례를 간략하게 설명하고 배포 가능한 예제 시나리오를 포함합니다. 스폿 VM은 일반 VM에 상당한 할인된 가격으로 컴퓨팅 용량에 대한 액세스를 제공합니다. 이 할인을 통해 비용을 최적화하려는 조직에 매력적인 솔루션이 되지만 절감에는 조건이 함께 제공됩니다. 스폿 VM은 언제든지 컴퓨팅에 대한 액세스 권한을 잃을 수 있습니다. 이 프로세스를 제거라고 합니다. 스폿 VM에서 실행되는 워크로드는 컴퓨팅에서 이러한 중단을 처리할 수 있어야 합니다. 올바른 워크로드와 유연한 오케스트레이션 메커니즘은 성공의 열쇠입니다. 다음은 현장 VM을 빌드하기 위한 권장 사항입니다.

스폿 가상 머신 이해

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

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

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

스폿 가상 머신 가격 책정 이해

스폿 VM은 일반(종량제) VM보다 최대 90% 저렴할 수 있습니다. 할인은 수요, VM 크기, 배포 지역 및 운영 체제에 따라 달라집니다. Azure Spot VM 가격 책정 도구를 사용하여 비용 절감액을 예측하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.

• Azure Spot VM 가격 책정 도구
• 스폿 VM 가격 책정 개요

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은 중지/할당 취소된 경우에도 해당 지역 또는 영역에서 이동할 수 없습니다. 자세한 내용은 VM 전원 상태 및 청구참조하세요.

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

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

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

속도를 위한 디자인

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

여러 VM 크기 및 위치 사용

유연성을 높이기 위해 여러 VM 유형 및 크기를 사용하도록 오케스트레이션을 빌드하는 것이 좋습니다. 목표는 제거된 VM을 대체할 오케스트레이션 옵션을 제공하는 것입니다. Azure에는 동일한 가격에 비슷한 기능을 제공하는 다양한 VM 유형과 크기가 있습니다. VM 최소 vCPU/코어 및/또는 최소 RAM 및 최대 가격을 필터링하여 워크로드를 실행하고 예산에 맞는 여러 VM을 찾아야 합니다.

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

또한 기능 스폿 배치 점수를 사용하여 오케스트레이션 시스템의 일부로 개별 스폿 배포의 성공 가능성을 평가하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.

• 제거 속도
• Azure Resource Graph
• 자리 배치 점수(미리 보기)

가장 유연한 제거 정책 사용

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

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

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

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

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

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

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

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

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

배포 시스템 빌드

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

삭제 정책의 경우 다른 VM 크기를 사용하고 다른 지역에 배포하는 파이프라인을 빌드하는 것이 좋습니다. 중지/할당 취소된 정책의 경우 배포 파이프라인에는 두 가지 고유한 작업이 필요합니다. VM을 처음 만들려면 파이프라인에서 올바른 크기의 VM을 올바른 위치에 배포해야 합니다. 제거된 VM의 경우 파이프라인이 작동할 때까지 VM을 다시 시작해야 합니다. Azure Monitor 경고와 Azure Functions의 조합은 배포 시스템을 자동화하는 여러 가지 방법 중 하나입니다. 파이프라인은 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 워크로드는 동일한 메시지를 두 번 이상 받을 수 있으며 결과는 동일하게 유지됩니다. 자세한 내용은 멱등성참조하세요.

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

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

워크로드 수명 주기 다이어그램

사용자 할당 관리 ID 구성

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

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

예제 시나리오

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

다음 참고 사항은 아키텍처의 주요 측면을 설명합니다.

1. VM 애플리케이션 정의: VM 애플리케이션 정의는 Azure Compute 갤러리에 만들어집니다. 애플리케이션 이름, 위치, 운영 체제 및 메타데이터를 정의합니다. 애플리케이션 버전은 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는 RBAC를 사용하여 사용자 할당 ID를 사용하여 스토리지 큐에 대한 스폿 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 로고 이 아키텍처를 배포하기 위한 템플릿, 스크립트 및 단계별 지침이 포함된 중단 가능한 워크로드를 GitHub 리포지토리가 있습니다.

다음 단계

Spot Virtual Machines에 대한 자세한 내용은 azure Spot Virtual Machines참조하세요.

관련 리소스

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