이 문서에서는 Azure 별색 VM(가상 머신)에서 빌드하기 위한 모범 사례를 간략하게 설명하고 배포 가능한 예 시나리오를 포함합니다. 스폿 VM은 일반 VM에 비해 대폭 할인된 가격으로 컴퓨팅 용량에 대한 액세스를 제공합니다. 이러한 할인은 비용을 최적화하려는 조직에게 매력적인 솔루션이 되지만 비용 절감에는 조건이 따릅니다. 스폿 VM은 언제든지 컴퓨팅에 대한 액세스 권한을 잃을 수 있습니다. 이 프로세스를 제거라고 합니다. 스폿 VM에서 실행되는 워크로드는 컴퓨팅에서 이러한 중단을 처리할 수 있어야 합니다. 올바른 워크로드와 유연한 오케스트레이션 메커니즘이 성공의 열쇠입니다. 스폿 VM 빌드에 대한 권장 사항은 다음과 같습니다.
스폿 가상 머신 이해
기술 수준에서 스폿 VM은 일반 VM과 동일합니다. 동일한 성능으로 변환되는 동일한 이미지, 하드웨어 및 디스크를 사용합니다. 스폿 VM과 일반 VM의 차이는 우선 순위와 가용성으로 귀결됩니다. Spot VM은 컴퓨팅 용량에 액세스할 우선 순위가 없으며 해당 컴퓨팅 용량에 액세스한 후 가용성을 보장하지 않습니다. 우선 순위와 가용성에 대해 더 자세히 논의해 보겠습니다.
우선 순위 액세스가 없습니다. 일반 VM은 컴퓨팅 용량에 우선적으로 액세스할 수 있습니다. 요청할 때마다 컴퓨팅 용량에 액세스합니다. 반면 스폿 VM은 여분의 컴퓨팅 용량이 있을 때만 배포되며 일반 VM에 기본 하드웨어가 필요하지 않을 때만 실행 상태를 유지합니다.
가용성이 보장되지 않습니다. Spot VM에는 가용성이 보장되지 않습니다. SLA(서비스 수준 계약)가 없습니다. Spot VM은 즉시 또는 배포(제거) 후 언제든지 컴퓨팅 용량에 대한 액세스 권한을 잃을 수 있습니다. 스폿 VM은 제거 가능성 때문에 더 저렴합니다. Azure에서 컴퓨팅 용량을 다시 필요로 할 때마다 제거 알림이 전송되고 스폿 VM이 제거됩니다. Azure는 실제 제거가 발생하기 최소 30초 전에 사전 통지를 제공합니다. 자세한 내용은 이 문서의 제거에 대한 지속적인 모니터링을 참조하세요.
스폿 가상 머신 가격 책정 이해
스폿 VM은 일반(종량제) VM보다 최대 90% 저렴할 수 있습니다. 할인은 수요, VM 크기, 배포 지역 및 운영 체제에 따라 다릅니다. Azure Spot VM 가격 책정 도구를 사용하여 예상 비용 절감액을 확인하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.
Azure 소매 가격 API를 쿼리하여 관심 있는 모든 SKU에 대한 스폿 가격을 프로그래밍 방식으로 가져올 수도 있습니다.
중단 가능한 워크로드 이해
중단 가능한 워크로드는 스폿 VM의 가장 좋은 사용 사례입니다. 중단 가능한 워크로드에는 몇 가지 공통된 특성이 있습니다. 시간 제약 조건이 거의 없거나 전혀 없으며 조직의 우선 순위가 낮고 처리 시간이 짧습니다. 필수 조직 프로세스에 해를 끼치지 않고 갑자기 중지하고 나중에 다시 시작할 수 있는 프로세스를 실행합니다. 중단 가능한 워크로드의 예로는 일괄 처리 애플리케이션, 데이터 분석 및 비프로덕션 환경을 위한 연속 통합-지속적인 배포 에이전트를 만드는 워크로드가 있습니다. 이러한 기능은 SLA(서비스 수준 계약), 고정 세션 및 상태 저장 데이터가 있는 일반 또는 중요 업무용 워크로드와 대조됩니다. 이 표는 두 워크로드 형식에 대한 예를 제공합니다.
| 중단 가능한 워크로드 기능 | 일반 워크로드 기능 | |
|---|---|---|
| 기능 | 최소 또는 없음 시간 제약 조건 낮은 조직 우선 순위 짧은 처리 시간 |
SLA(서비스 수준 계약) 고정 세션 요구 사항 상태 저장 워크로드 |
중단 불가능한 워크로드에서 스폿 VM을 사용할 수 있지만 컴퓨팅 용량의 단일 원본이 되어서는 안 됩니다. 가동 시간 요구 사항을 충족하는 데 필요한 만큼 일반 VM을 사용합니다.
제거 이해
Spot VM은 만들어진 후 SLA(서비스 수준 계약)가 없으며 언제든지 컴퓨팅에 대한 액세스 권한을 잃을 수 있습니다. 이 컴퓨팅 손실을 제거라고 합니다. 수요와 공급을 계산하면 제거가 발생합니다. 특정 VM 크기에 대한 수요가 특정 수준을 초과하면 Azure는 스폿 VM을 제거하여 일반 VM에서 컴퓨팅을 사용할 수 있도록 합니다. 수요는 지역에 따라 다릅니다. 지역 A의 수요 증가는 지역 B의 스폿 VM에 영향을 미치지 않습니다.
Spot 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 데이터를 가져올 수도 있습니다. 자세한 내용은 다음을 참조하세요.
가장 유연한 제거 정책 사용
제거된 스폿 VM의 제거 정책은 바꾸기 프로세스에 영향을 미칩니다. 삭제 제거 정책은 중지/할당 취소된 제거 정책보다 더 유연합니다.
먼저 삭제 정책 고려: 워크로드가 처리할 수 있는 경우 삭제 제거 정책을 사용하는 것이 좋습니다. 삭제를 통해 오케스트레이션은 바꾸기 스폿 VM을 새 영역 및 지역에 배포할 수 있습니다. 이러한 배포 유연성은 워크로드가 중지/할당 취소된 VM보다 더 빠르게 예비 컴퓨팅 용량을 찾는 데 도움이 될 수 있습니다. 중지/할당 취소된 VM은 만들어진 동일한 영역에서 예비 컴퓨팅 용량을 기다려야 합니다. 삭제 정책의 경우 애플리케이션 외부에 있는 제거를 모니터링하고 다른 지역 및/또는 다른 VM SKU로 배포를 오케스트레이션하는 프로세스가 필요합니다.
중지/할당 취소 정책 이해: 중지/할당 취소 정책은 삭제 정책보다 유연성이 떨어집니다. 스폿 VM은 동일한 지역 및 영역에 있어야 합니다. 중지/할당 취소된 VM을 다른 위치로 이동할 수 없습니다. VM의 위치는 고정되어 있으므로 컴퓨팅 용량을 사용할 수 있게 되면 VM을 재할당할 수 있는 것이 필요합니다. 컴퓨팅 용량을 사용할 수 있는 시기를 예측할 방법이 없습니다. 따라서 제거 후 재배포를 시도하려면 자동화된 일정 파이프라인을 사용하는 것이 좋습니다. 제거는 일정 파이프라인을 트리거해야 하며 재배포 시도는 컴퓨팅 용량이 사용 가능해질 때까지 지속적으로 확인해야 합니다.
| 정책 | When | |
|---|---|---|
| 삭제 | 임시 컴퓨팅 및 데이터 데이터 디스크에 대한 비용을 지불하지 않으려는 경우 최소 예산 |
|
| 중지됨/할당 취소됨 | 특정 VM 크기 필요 위치를 변경할 수 없음 긴 애플리케이션 설치 프로세스 |
무기한 대기 시간 비용 절감만으로 구동되지 않음 |
제거 여부를 지속적으로 모니터링
모니터링은 스폿 VM에서 워크로드 안정성의 핵심입니다. 스폿 VM은 만든 후 SLA가 없으며 언제든지 제거할 수 있습니다. 스폿 VM에서 워크로드 안정성을 개선하는 가장 좋은 방법은 제거될 시기를 예측하는 것입니다. 이 정보를 사용하면 워크로드 정상 종료를 시도하고 교체를 오케스트레이션하는 자동화를 트리거할 수 있습니다.
Scheduled Events 사용: 각 VM에 대해 Scheduled Events 서비스를 사용하는 것이 좋습니다. Azure는 VM이 인프라 유지 관리의 영향을 받을 때 VM에 신호를 보냅니다. 제거는 인프라 유지 관리에 해당합니다. Azure는 제거되기 최소 30초 전에 모든 VM에 Preempt 신호를 보냅니다. Schedule Events라는 서비스를 사용하면 라우팅할 수 없는 정적 IP 주소 169.254.169.254에서 엔드포인트를 쿼리하여 이 Preempt 신호를 캡처할 수 있습니다.
빈번한 쿼리 사용: 정상 종료를 오케스트레이션할 만큼 Schedule Events 엔드포인트를 자주 쿼리하는 것이 좋습니다. 최대 1초마다 Scheduled Events 엔드포인트를 쿼리할 수 있지만 모든 사용 사례에 1초 빈도가 필요한 것은 아닙니다. 이러한 쿼리는 스폿 VM에서 실행되는 애플리케이션에서 가져와야 합니다. 쿼리는 외부 원본에서 가져올 수 없습니다. 결과적으로 쿼리는 VM 컴퓨팅 용량을 소비하고 기본 워크로드에서 처리 능력을 훔칩니다. 특정 상황에 맞게 경쟁 우선 순위의 균형을 맞춰야 합니다.
오케스트레이션 자동화: Preempt 신호를 수집하면 오케스트레이션이 해당 신호에 따라 작동해야 합니다. 지정된 시간 제약 조건에서 Preempt 신호는 워크로드의 정상 종료를 시도하고 스폿 VM을 바꾸는 자동화된 프로세스를 시작해야 합니다. 자세한 내용은 다음을 참조하세요.
배포 시스템 빌드
제거 시 새 스폿 VM을 배포하려면 오케스트레이션에 자동화된 파이프라인이 필요합니다. 파이프라인은 영속성을 보장하기 위해 중단 가능한 워크로드 자체 외부에서 실행되어야 합니다. 배포 파이프라인이 작동하는 방식은 스폿 VM에 대해 선택한 제거 정책에 따라 다릅니다.
삭제 정책의 경우 서로 다른 VM 크기를 사용하고 서로 다른 지역에 배포하는 파이프라인을 빌드하는 것이 좋습니다. 중지/할당 취소 정책의 경우 배포 파이프라인에 두 가지 고유 작업이 필요합니다. VM을 처음 만들려면 파이프라인이 올바른 크기의 VM을 올바른 위치에 배포해야 합니다. 제거된 VM의 경우 파이프라인은 작동할 때까지 VM을 다시 시작해야 합니다. Azure Monitor 경고와 Azure Functions의 조합은 배포 시스템을 자동화하는 여러 방법 중 하나입니다. 파이프라인은 bicep 템플릿을 사용할 수 있습니다. 선언적이고 멱등적이며 인프라 배포를 위한 모범 사례를 나타냅니다.
즉시 제거 준비
워크로드가 실행되기 전에 스폿 VM이 만들어지자마자 제거 대상으로 지정될 수 있습니다. 스폿 VM을 만들 수 있는 용량이 있다고 해서 유지되는 것은 아닙니다. 스폿 VM은 만들기 후 가용성 보장(SLA)이 없습니다. 오케스트레이션은 즉각적인 제거를 고려해야 합니다. Preempt 신호는 제거에 대한 최소 30초 사전 통지를 계속 제공합니다.
VM 상태 확인을 오케스트레이션에 통합하여 즉각적인 제거에 대비하는 것이 좋습니다. 즉각적인 제거를 위한 오케스트레이션은 Schedule Events Preempt 신호에 의존할 수 없습니다. VM 자체만 Preempt 신호를 쿼리할 수 있으며 애플리케이션을 시작하고 Schedule Events 엔드포인트를 쿼리하고 정상적으로 종료할 시간이 충분하지 않습니다. 따라서 상태 확인은 워크로드 환경 외부에 상주해야 합니다. 상태 확인은 스폿 VM의 상태를 감시하고 상태가 할당 취소 또는 중지로 변경될 때 스폿 VM을 바꾸기 위한 배포 파이프라인을 시작해야 합니다.
여러 동시 제거 계획
스폿 VM의 클러스터를 실행하는 경우 여러 동시 제거를 견딜 수 있도록 워크로드를 설계해야 합니다. 워크로드의 여러 스폿 VM을 동시에 제거할 수 있습니다. 여러 VM을 동시에 제거하면 애플리케이션의 처리량에 영향을 줄 수 있습니다. 이러한 상황을 방지하려면 배포 파이프라인이 여러 VM에서 신호를 수집하고 여러 바꾸기 VM을 동시에 배포할 수 있어야 합니다.
정상 종료를 위한 디자인
VM 종료 프로세스는 30초 미만이어야 하며 제거 전에 VM을 종료할 수 있어야 합니다. 종료에 걸리는 시간은 워크로드가 Scheduled Events 엔드포인트를 쿼리하는 빈도에 따라 다릅니다. 엔드포인트를 자주 쿼리할수록 종료 프로세스가 길어질 수 있습니다. 종료 프로세스는 리소스를 해제하고 연결을 비우고 이벤트 로그를 플러시해야 합니다. 컨텍스트를 저장하고 보다 효율적인 복구 전략을 빌드하려면 검사점을 정기적으로 만들고 저장해야 합니다. 검사점은 다음 VM을 시작해야 하는 프로세스 또는 트랜잭션에 대한 정보일 뿐입니다. 이전 VM이 중단된 지점에서 VM을 다시 시작해야 하는지 또는 새 VM이 변경 내용을 롤백하고 전체 프로세스를 다시 시작해야 하는지 여부를 나타내야 합니다. 스폿 VM 환경 외부에 검사점을 저장해야 합니다. 스토리지 계정이 작동합니다.
오케스트레이션 테스트
개발/테스트 환경에서 오케스트레이션을 테스트하려면 제거 이벤트를 시뮬레이션하는 것이 좋습니다. 자세한 내용은 제거 시뮬레이션을 참조하세요.
멱등 워크로드 디자인
멱등 워크로드를 디자인하는 것이 좋습니다. 이벤트를 두 번 이상 처리한 결과는 한 번 처리한 것과 같아야 합니다. 제거는 정상 종료를 보장하기 위한 활동에도 불구하고 강제 종료로 이어질 수 있습니다. 강제 종료는 완료되기 전에 프로세스를 종료할 수 있습니다. 멱등 워크로드는 동일한 메시지를 두 번 이상 수신할 수 있으며 결과는 동일하게 유지됩니다. 자세한 내용은 멱등성을 참조하세요.
애플리케이션 준비 기간 사용
대부분의 중단 가능한 워크로드는 애플리케이션을 실행합니다. 애플리케이션은 설치 시간과 부팅 시간이 필요합니다. 외부 스토리지에 연결하고 검사점에서 정보를 수집하려면 시간이 필요합니다. 처리를 시작하기 전에 애플리케이션 준비 기간을 두는 것이 좋습니다. 준비 기간 동안 애플리케이션은 부팅, 연결 및 기여 준비를 해야 합니다. 애플리케이션의 상태의 유효성을 검사한 후에만 애플리케이션이 데이터 처리를 시작하도록 허용해야 합니다.
사용자 할당 관리 ID 구성
사용자 할당 관리 ID를 사용하여 인증 및 권한 부여 프로세스를 간소화하는 것이 좋습니다. 사용자 할당 관리 ID를 사용하면 자격 증명을 코드에 넣지 않아도 되며 시스템 할당 관리 ID와 같은 단일 리소스에 연결되지 않습니다. 사용자 할당 관리 ID에는 오케스트레이션 중에 VM을 발견하기 위해 다시 사용하고 할당할 수 있는 Microsoft Entra ID의 권한 및 액세스 토큰이 포함됩니다. 스폿 VM 간의 토큰 일관성은 스폿 VM이 보유한 워크로드 리소스에 대한 액세스 및 오케스트레이션을 간소화하는 데 도움이 됩니다.
시스템 할당 관리 ID를 사용하면 새 스폿 VM이 Microsoft Entra ID와 다른 액세스 토큰을 가져올 수 있습니다. 시스템 할당 관리 ID를 사용해야 하는 경우 워크로드를 403 Forbidden Error 응답에 탄력적으로 만드는 것이 좋습니다. 오케스트레이션은 올바른 권한이 있는 Microsoft Entra ID에서 토큰을 가져와야 합니다. 자세한 내용은 관리 ID를 참조하세요.
예제 시나리오
예 시나리오는 중단 가능한 워크로드로 적합한 큐 처리 애플리케이션을 배포합니다. 시나리오의 스크립트는 예시입니다. 이 시나리오는 리소스 배포를 위한 일회용 수동 푸시를 안내합니다. 이 구현과 함께 배포 파이프라인을 제공하지 않았습니다. 그러나 오케스트레이션 프로세스를 자동화하려면 배포 파이프라인이 필수적입니다. 다이어그램은 예 시나리오의 아키텍처를 보여 줍니다.
다음 참고 사항은 아키텍처의 주요 측면을 설명합니다.
- VM 애플리케이션 정의: VM 애플리케이션 정의는 Azure Compute Gallery에서 만들어집니다. 애플리케이션 이름, 위치, 운영 체제 및 메타데이터를 정의합니다. 애플리케이션 버전은 번호가 매겨진 VM 애플리케이션 정의 버전입니다. 애플리케이션 버전은 VM 애플리케이션의 인스턴스화입니다. 스폿 VM과 동일한 지역에 있어야 합니다. 애플리케이션 버전은 스토리지 계정의 원본 애플리케이션 패키지에 연결됩니다.
- 스토리지 계정: 스토리지 계정은 원본 애플리케이션 패키지를 저장합니다. 이 아키텍처에서는 이름이
worker-0.1.0.tar.gz인 압축된 tar 파일입니다. 두 개의 파일이 포함되어 있습니다. 한 파일은 .NET 작업자 애플리케이션을 설치하는orchestrate.shbash 스크립트입니다. - 스폿 VM: 스폿 VM이 배포됩니다. 애플리케이션 버전과 동일한 지역에 있어야 합니다. 배포 후 VM에
worker-0.1.0.tar.gz를 다운로드합니다. bicep 템플릿은 표준 제품군 VM에 Ubuntu 이미지를 배포합니다. 이러한 구성은 이 애플리케이션의 요구 사항을 충족하며 애플리케이션에 대한 일반적인 권장 사항이 아닙니다. - 스토리지 큐: .NET 작업자에서 실행 중인 다른 서비스에는 메시지 큐 논리가 포함되어 있습니다. Microsoft Entra ID는 RBAC를 사용하여 사용자 할당 ID를 사용하여 스토리지 큐에 대한 스폿 VM 액세스 권한을 부여합니다.
- .Net 작업자 애플리케이션: Orchestrate.sh 스크립트는 두 개의 백그라운드 서비스를 실행하는 .NET 작업자 애플리케이션을 설치합니다. 첫 번째 서비스는 Schedule Events 엔드포인트를 쿼리하고
Preempt신호를 찾고 이 신호를 두 번째 서비스로 보냅니다. 두 번째 서비스는 스토리지 큐의 메시지를 처리하고 첫 번째 서비스의Preempt신호를 수신합니다. 두 번째 서비스가 신호를 받으면 스토리지 큐 처리를 중단하고 종료되기 시작합니다. - Scheduled Events 엔드포인트 쿼리: API 요청은 라우팅할 수 없는 정적 IP 주소 169.254.169.254로 전송됩니다. API 요청은 Scheduled Event 엔드포인트에서 인프라 유지 관리 신호를 쿼리합니다.
- Application Insights: 아키텍처는 학습 목적으로만 Application Insights를 사용합니다. 중단 가능한 워크로드 오케스트레이션의 필수 구성 요소는 아닙니다. .NET 작업자 애플리케이션에서 원격 분석의 유효성을 검사하는 방법으로 포함했습니다. Application Insights에 원격 분석을 보내도록 .NET 작업자 애플리케이션을 구성했습니다. 자세한 내용은 .NET 애플리케이션에서 라이브 메트릭 사용을 참조하세요.
시나리오 배포
이 아키텍처를 배포하기 위한 템플릿, 스크립트 및 단계별 지침이 포함된 인터럽트 가능한 현장 워크로드라는 GitHub 리포지토리를 만들었습니다. 이 리포지토리에서 아키텍처 및 엔지니어링 아티팩트에 대한 자세한 기술 정보를 찾을 수 있습니다.
다음 단계
스폿 Virtual Machines에 대한 자세한 내용은 Azure 스폿 Virtual Machines를 참조하세요.