スポット仮想マシンでワークロードを構築する

Azure Virtual Machines

この記事では、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 スポット仮想マシンの価格ツール と スポット仮想マシンの価格の概要に関するページを参照してください。 また、Azure 小売価格 API にクエリを実行して、任意の SKU のスポット価格をプログラムで取得することもできます。

中断可能なワークロードを理解する

スポット VM は、いくつかの一般的な特性を共有する中断可能なワークロードに最適です。 中断可能なワークロードには、時間の制約が最小限から無く、組織の優先順位が低く、処理時間が短くなります。 組織の重要なプロセスに損害を与えることなく、突然停止して後で再開できるプロセスを実行します。 中断可能なワークロードの例としては、非運用環境用の継続的インテグレーションおよび継続的デプロイ エージェントを作成するバッチ処理アプリケーション、データ分析、ワークロードがあります。 これらの機能は、SLA、スティッキー セッション、ステートフル データを含む通常のワークロードまたはミッション クリティカルなワークロードと比較されます。

中断できないワークロードではスポット VM を使用できますが、コンピューティング容量の唯一のソースにすることはできません。 アップタイム要件を満たすために必要な数の通常の VM を使用します。

削除について

スポット VM は作成後に SLA を持たなくなり、いつでもコンピューティングにアクセスできなくなる可能性があります。 このコンピューティング損失を削除と呼 びます。 コンピューティングの供給と需要のドライブの削除。 特定の VM サイズの需要が特定のレベルを超えると、Azure はスポット VM を削除して、通常の VM でコンピューティングを使用できるようにします。 需要は場所固有です。 たとえば、リージョン A の需要の増加は、リージョン B のスポット VM には影響しません。

スポット VM には、削除に影響する 2 つの構成オプションがあります。 これらの構成は、スポット VM の 削除の種類 と 削除ポリシー です。 これらの構成は、スポット VM を作成するときに設定します。 削除の種類は、削除の条件を定義します。 削除ポリシーによって、スポット VM に対する削除の動作が決まります。

削除の種類

容量の変更または価格の変更により、削除が発生します。 容量と価格の変更がスポット VM に与える影響は、VM の作成時に選択する削除の種類によって異なります。 削除の種類は、削除の条件を定義します。 削除の種類は、 容量のみの削除 と 価格または容量の削除です。

• 容量のみの削除: この削除の種類では、過剰なコンピューティング容量が使用できなくなったときに削除がトリガーされます。 既定では、価格は従量課金制の料金で制限されます。 従量課金制 VM の価格を超える料金を支払いたくない場合は、この削除の種類を使用します。

• 価格または容量の削除: この削除の種類には、2 つのトリガーがあります。 過剰なコンピューティング容量が使用できなくなった場合、または VM のコストが設定した最大価格を超えた場合、Azure はスポット VM を削除します。 この削除の種類では、従量課金制の価格をはるかに下回る最大価格を設定できます。 この削除の種類を使用して、独自の価格上限を設定します。

削除ポリシー

スポット VM に対して選択した削除ポリシーは、そのオーケストレーションに影響します。 オーケストレーションは削除を処理するプロセスであり、この記事の後半で説明します。 削除ポリシーは、 停止/割り当て解除ポリシー と 削除ポリシーです。

ポリシーの停止/割り当て解除: 停止/割り当て解除ポリシーは、ワークロードが同じ場所と VM の種類内のリリース容量を待機できる場合に最適です。 停止/割り当て解除ポリシーは、VM を停止し、基になるハードウェアでリースを終了します。 スポット VM の停止と割り当ての解除は、通常の VM の停止と割り当ての解除と同じです。 VM は Azure で引き続きアクセスでき、後で同じ VM を再起動できます。 VM は、Stop/Deallocate ポリシーを使用してコンピューティング容量と非静的 IP アドレスを失います。 ただし、VM データ ディスクは残り、引き続き料金が発生します。 VM は、サブスクリプション内のコアも占有します。 VM は、停止または割り当て解除された場合でも、リージョンまたはゾーンから移動できません。 詳細については、「 電源の状態と課金」を参照してください。

ポリシーを削除します。 ワークロードで場所または 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 データを取得することもできます。

オーケストレーション システムでは、スポット配置スコア機能を使用して、個々のスポットデプロイで成功する可能性を評価することを検討してください。

詳細については、次のリソースを参照してください。

• 立ち退き率
• リソース グラフ
• スポット配置スコア

最も柔軟な削除ポリシーを使用する

削除されたスポット VM の削除ポリシーは、置換プロセスに影響します。 たとえば、削除ポリシーは、停止/割り当て解除ポリシーよりも柔軟です。

• 最初に削除ポリシーを検討します。 ワークロードで処理できる場合は、削除ポリシーを使用します。 削除により、オーケストレーションは代替スポット VM を新しいゾーンとリージョンにデプロイできます。 このデプロイの柔軟性は、ワークロードが停止または割り当て解除された VM よりも速く予備のコンピューティング容量を見つけるのに役立ちます。 停止または割り当て解除された VM は、作成されたのと同じゾーン内の予備のコンピューティング容量を待機する必要があります。 削除ポリシーでは、削除を監視し、さまざまなリージョンへのデプロイを調整したり、異なる VM SKU を使用したり、両方を使用したりする外部プロセスが必要です。

• 停止/割り当て解除ポリシーについて理解します。 停止/割り当て解除ポリシーは、削除ポリシーよりも柔軟性が低くなります。 スポット VM は、同じリージョンとゾーンに留まる必要があります。 停止または割り当て解除された VM を別の場所に移動することはできません。 VM には固定の場所があるため、コンピューティング容量が使用可能になったときに VM を再割り当てするために何かが必要です。 コンピューティング容量の可用性を予測する方法はありません。 そのため、自動スケジュール パイプラインを使用して、削除後に再デプロイを試みる必要があります。 削除によってスケジュール パイプラインがトリガーされ、再デプロイの試行では、使用可能になるまでコンピューティング容量を継続的にチェックする必要があります。

政策	ポリシーを使用するタイミング
ポリシーの削除	- エフェメラル コンピューティングとデータ - データ ディスクの料金を支払いたくない - 最小予算
ポリシーの停止/割り当て解除	- 特定の VM サイズが必要 - 場所を変更できない - 長いアプリケーション インストール プロセス - 無期限の待機時間 - コスト削減だけでは駆動されない

削除を継続的に監視する

監視は、スポット VM でのワークロードの信頼性の鍵です。 スポット VM は作成後に SLA を持たず、いつでも削除できます。 スポット VM でのワークロードの信頼性を向上させる最善の方法は、いつ削除されるのかを予測することです。 この情報がある場合は、ワークロードのグレースフル シャットダウンを試み、自動化をトリガーして置換を調整できます。

• スケジュールされたイベントを使用する: 各 VM にスケジュールされたイベント サービスを使用します。 インフラストラクチャのメンテナンスが影響を受けるときに、Azure から VM にシグナルが送信されます。 削除は、インフラストラクチャ メンテナンスの対象となります。 Azure は、削除されるまでの少なくとも 30 秒で、 Preempt シグナルをすべての VM に送信します。 スケジュールされたイベント サービスを使用すると、静的でルーティング不可能な IP アドレスPreemptでエンドポイントにクエリを実行することで、この169.254.169.254信号をキャプチャできます。

• 頻繁なクエリを使用する: スケジュールされたイベント エンドポイントに対してクエリを実行すると、正常なシャットダウンを調整するのに十分な頻度で実行されます。 スケジュールされたイベント エンドポイントのクエリは 1 秒ごとに実行できますが、すべてのユース ケースで 1 秒の頻度は必要ない場合があります。 これらのクエリは、スポット VM 上で実行されるアプリケーションから取得する必要があります。 クエリは外部ソースから取得できません。 その結果、クエリは VM コンピューティング容量を消費し、メイン ワークロードから処理能力を盗みます。 特定の状況を満たすために、競合する優先順位のバランスを取る必要があります。

• オーケストレーションを自動化する:Preemptシグナルを収集した後、オーケストレーションはそのシグナルに基づいて動作する必要があります。 時間の制約がある場合、Preempt シグナルはワークロードの正常なシャットダウンを試み、スポット VM を置き換える自動化されたプロセスを開始する必要があります。 詳細については、次のリソースを参照してください。

  • スケジュールされたイベント を する
  • スケジュールされたイベントの種類
  • エンドポイントのクエリ頻度

デプロイ システムを構築する

オーケストレーションには、削除後に新しいスポット VM をデプロイするための自動化されたパイプラインが必要です。 パイプラインは、永続性を確保するために、中断可能なワークロードの外部で実行する必要があります。 デプロイ パイプラインは、スポット VM に対して選択した削除ポリシーに従って動作する必要があります。

削除ポリシーの場合は、さまざまな VM サイズを使用し、異なるリージョンにデプロイするパイプラインを構築することをお勧めします。 Stop/Deallocate ポリシーの場合、デプロイ パイプラインには 2 つの異なるアクションが必要です。 VM を最初に作成するには、パイプラインで適切なサイズの VM を適切な場所にデプロイする必要があります。 削除された VM の場合、パイプラインは動作するまで VM の再起動を試みる必要があります。 Azure Monitor アラートと Azure 関数の組み合わせは、デプロイ システムを自動化する 1 つの方法です。 パイプラインでは bicep テンプレートを使用できます。 これらは宣言型でべき等であり、インフラストラクチャのデプロイのベスト プラクティスを表します。

即時削除の準備

作成したスポット VM とワークロードを実行する前に、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 環境の外部にチェックポイントを格納します。

オーケストレーションをテストする

削除イベントをシミュレートして、開発/テスト環境でオーケストレーションをテストします。 詳細については、「削除の シミュレート」を参照してください。

べき等ワークロードを設計する

べき等ワークロードを設計することをお勧めします。 イベントを複数回処理した結果は、1 回の処理と同じである必要があります。 削除すると、正常なシャットダウンを確保する努力にもかかわらず、強制シャットダウンが発生する可能性があります。 強制シャットダウンでは、完了前にプロセスを終了できます。 べき等ワークロードは、結果を変更することなく、同じメッセージを複数回受信できます。 詳細については、「 べき等性」を参照してください。

アプリケーションのウォームアップ期間を使用する

割り込み可能なワークロードのほとんどは、アプリケーションを実行します。 アプリケーションのインストールと起動には時間が必要です。 また、外部ストレージに接続し、チェックポイントから情報を収集する時間も必要です。 アプリケーションのウォームアップ期間を設定してから、処理を開始します。 ウォームアップ期間中は、アプリケーションを開始し、接続を確立し、貢献する準備をする必要があります。 アプリケーションの正常性を検証した後にのみ、アプリケーションがデータの処理を開始できるようにします。

ユーザー割り当てマネージド 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 回限りの手動プッシュについて説明します。 この実装にはデプロイ パイプラインがありません。 ただし、調整プロセスを自動化するには、デプロイ パイプラインが不可欠です。 次の図は、シナリオ例のアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

次のワークフローは、上記のダイアグラムに対応しています。

1. VM アプリケーション定義: VM アプリケーション定義は、Azure コンピューティング ギャラリーに作成されます。 アプリケーション名、場所、オペレーティング システム、およびメタデータを定義します。 アプリケーションのバージョンは、VM アプリケーション定義の番号付きバージョンです。 アプリケーションのバージョンは、VM アプリケーションを表します。 スポット VM と同じリージョンに存在する必要があります。 アプリケーション バージョンは、ストレージ アカウント内のソース アプリケーション パッケージにリンクされます。

2. ストレージ アカウント: ストレージ アカウントには、ソース アプリケーション パッケージが格納されます。 このアーキテクチャでは、worker-0.1.0.tar.gzという名前の圧縮 tar ファイルです。 これには 2 つのファイルが含まれています。 1 つのファイルは、.NET worker アプリケーションをインストールする orchestrate.sh bash スクリプトです。

3. スポット VM : スポット VM がデプロイ。 アプリケーションのバージョンと同じリージョンに存在する必要があります。 デプロイ後に vm に worker-0.1.0.tar.gz をダウンロードします。 bicep テンプレートは、標準ファミリ VM に Ubuntu イメージをデプロイします。 これらの構成は、このアプリケーションのニーズを満たし、アプリケーションの一般的な推奨事項ではありません。

4. ストレージ キュー: .NET worker で実行されるもう 1 つのサービスには、メッセージ キュー ロジックが含まれています。 Microsoft Entra ID は、ロールベースのアクセス制御を使用して、ユーザー割り当て ID を使用して、Azure Queue Storage 内のストレージ キューへのスポット VM アクセスを許可します。

5. .NET worker アプリケーション:orchestrate.sh スクリプトは、2 つのバックグラウンド サービスを実行する .NET worker アプリケーションをインストールします。 最初のサービスは、スケジュールされたイベント エンドポイントに対してクエリを実行し、 Preempt シグナルを探して、このシグナルを 2 番目のサービスに送信します。 2 番目のサービスは、ストレージ キューからのメッセージを処理し、最初のサービスからの Preempt シグナルをリッスンします。 2 番目のサービスは、シグナルを受信すると、ストレージ キューの処理を中断し、シャットダウンを開始します。

6. スケジュールされたイベント エンドポイントのクエリ: API 要求は、静的なルーティング不可能な IP アドレス 169.254.169.254に送信されます。 API 要求は、スケジュールされたイベント エンドポイントに対して、インフラストラクチャ メンテナンス シグナルのクエリを実行します。

7. Application Insights: アーキテクチャでは、学習目的でのみ Application Insights が使用されます。 割り込み可能なワークロード オーケストレーションの必須コンポーネントではありませんが、.NET worker アプリケーションからのテレメトリを検証できます。 .NET worker アプリケーションは、テレメトリを Application Insights に送信します。 詳細については、「 .NET アプリケーションからのライブ メトリックを有効にする」を参照してください。

このシナリオをデプロイする

このアーキテクチャをデプロイするためのテンプレート、スクリプト、およびステップ バイ ステップの手順を含む 、割り込み可能なワークロード と呼ばれる GitHub リポジトリがあります。

次の手順

スポット仮想マシン

関連リソース

• マルチテナント ソリューションでのコスト管理と割り当てのためのアーキテクチャ アプローチ
• Azure で Windows VM を実行する
• Azure で Linux VM を実行する

この記事では、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 スポット仮想マシンの価格ツール と スポット仮想マシンの価格の概要に関するページを参照してください。 また、Azure 小売価格 API にクエリを実行して、任意の SKU のスポット価格をプログラムで取得することもできます。

中断可能なワークロードを理解する

スポット VM は、いくつかの一般的な特性を共有する中断可能なワークロードに最適です。 中断可能なワークロードには、時間の制約が最小限から無く、組織の優先順位が低く、処理時間が短くなります。 組織の重要なプロセスに損害を与えることなく、突然停止して後で再開できるプロセスを実行します。 中断可能なワークロードの例としては、非運用環境用の継続的インテグレーションおよび継続的デプロイ エージェントを作成するバッチ処理アプリケーション、データ分析、ワークロードがあります。 これらの機能は、SLA、スティッキー セッション、ステートフル データを含む通常のワークロードまたはミッション クリティカルなワークロードと比較されます。

中断できないワークロードではスポット VM を使用できますが、コンピューティング容量の唯一のソースにすることはできません。 アップタイム要件を満たすために必要な数の通常の VM を使用します。

削除について

スポット VM は作成後に SLA を持たなくなり、いつでもコンピューティングにアクセスできなくなる可能性があります。 このコンピューティング損失を削除と呼 びます。 コンピューティングの供給と需要のドライブの削除。 特定の VM サイズの需要が特定のレベルを超えると、Azure はスポット VM を削除して、通常の VM でコンピューティングを使用できるようにします。 需要は場所固有です。 たとえば、リージョン A の需要の増加は、リージョン B のスポット VM には影響しません。

スポット VM には、削除に影響する 2 つの構成オプションがあります。 これらの構成は、スポット VM の 削除の種類 と 削除ポリシー です。 これらの構成は、スポット VM を作成するときに設定します。 削除の種類は、削除の条件を定義します。 削除ポリシーによって、スポット VM に対する削除の動作が決まります。

削除の種類

容量の変更または価格の変更により、削除が発生します。 容量と価格の変更がスポット VM に与える影響は、VM の作成時に選択する削除の種類によって異なります。 削除の種類は、削除の条件を定義します。 削除の種類は、 容量のみの削除 と 価格または容量の削除です。

• 容量のみの削除: この削除の種類では、過剰なコンピューティング容量が使用できなくなったときに削除がトリガーされます。 既定では、価格は従量課金制の料金で制限されます。 従量課金制 VM の価格を超える料金を支払いたくない場合は、この削除の種類を使用します。

• 価格または容量の削除: この削除の種類には、2 つのトリガーがあります。 過剰なコンピューティング容量が使用できなくなった場合、または VM のコストが設定した最大価格を超えた場合、Azure はスポット VM を削除します。 この削除の種類では、従量課金制の価格をはるかに下回る最大価格を設定できます。 この削除の種類を使用して、独自の価格上限を設定します。

削除ポリシー

スポット VM に対して選択した削除ポリシーは、そのオーケストレーションに影響します。 オーケストレーションは削除を処理するプロセスであり、この記事の後半で説明します。 削除ポリシーは、 停止/割り当て解除ポリシー と 削除ポリシーです。

ポリシーの停止/割り当て解除: 停止/割り当て解除ポリシーは、ワークロードが同じ場所と VM の種類内のリリース容量を待機できる場合に最適です。 停止/割り当て解除ポリシーは、VM を停止し、基になるハードウェアでリースを終了します。 スポット VM の停止と割り当ての解除は、通常の VM の停止と割り当ての解除と同じです。 VM は Azure で引き続きアクセスでき、後で同じ VM を再起動できます。 VM は、Stop/Deallocate ポリシーを使用してコンピューティング容量と非静的 IP アドレスを失います。 ただし、VM データ ディスクは残り、引き続き料金が発生します。 VM は、サブスクリプション内のコアも占有します。 VM は、停止または割り当て解除された場合でも、リージョンまたはゾーンから移動できません。 詳細については、「 電源の状態と課金」を参照してください。

ポリシーを削除します。 ワークロードで場所または 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 データを取得することもできます。

オーケストレーション システムでは、スポット配置スコア機能を使用して、個々のスポットデプロイで成功する可能性を評価することを検討してください。

詳細については、次のリソースを参照してください。

• 立ち退き率
• リソース グラフ
• スポット配置スコア

最も柔軟な削除ポリシーを使用する

削除されたスポット VM の削除ポリシーは、置換プロセスに影響します。 たとえば、削除ポリシーは、停止/割り当て解除ポリシーよりも柔軟です。

• 最初に削除ポリシーを検討します。 ワークロードで処理できる場合は、削除ポリシーを使用します。 削除により、オーケストレーションは代替スポット VM を新しいゾーンとリージョンにデプロイできます。 このデプロイの柔軟性は、ワークロードが停止または割り当て解除された VM よりも速く予備のコンピューティング容量を見つけるのに役立ちます。 停止または割り当て解除された VM は、作成されたのと同じゾーン内の予備のコンピューティング容量を待機する必要があります。 削除ポリシーでは、削除を監視し、さまざまなリージョンへのデプロイを調整したり、異なる VM SKU を使用したり、両方を使用したりする外部プロセスが必要です。

• 停止/割り当て解除ポリシーについて理解します。 停止/割り当て解除ポリシーは、削除ポリシーよりも柔軟性が低くなります。 スポット VM は、同じリージョンとゾーンに留まる必要があります。 停止または割り当て解除された VM を別の場所に移動することはできません。 VM には固定の場所があるため、コンピューティング容量が使用可能になったときに VM を再割り当てするために何かが必要です。 コンピューティング容量の可用性を予測する方法はありません。 そのため、自動スケジュール パイプラインを使用して、削除後に再デプロイを試みる必要があります。 削除によってスケジュール パイプラインがトリガーされ、再デプロイの試行では、使用可能になるまでコンピューティング容量を継続的にチェックする必要があります。

政策	ポリシーを使用するタイミング
ポリシーの削除	- エフェメラル コンピューティングとデータ - データ ディスクの料金を支払いたくない - 最小予算
ポリシーの停止/割り当て解除	- 特定の VM サイズが必要 - 場所を変更できない - 長いアプリケーション インストール プロセス - 無期限の待機時間 - コスト削減だけでは駆動されない

削除を継続的に監視する

監視は、スポット VM でのワークロードの信頼性の鍵です。 スポット VM は作成後に SLA を持たず、いつでも削除できます。 スポット VM でのワークロードの信頼性を向上させる最善の方法は、いつ削除されるのかを予測することです。 この情報がある場合は、ワークロードのグレースフル シャットダウンを試み、自動化をトリガーして置換を調整できます。

• スケジュールされたイベントを使用する: 各 VM にスケジュールされたイベント サービスを使用します。 インフラストラクチャのメンテナンスが影響を受けるときに、Azure から VM にシグナルが送信されます。 削除は、インフラストラクチャ メンテナンスの対象となります。 Azure は、削除されるまでの少なくとも 30 秒で、 Preempt シグナルをすべての VM に送信します。 スケジュールされたイベント サービスを使用すると、静的でルーティング不可能な IP アドレスPreemptでエンドポイントにクエリを実行することで、この169.254.169.254信号をキャプチャできます。

• 頻繁なクエリを使用する: スケジュールされたイベント エンドポイントに対してクエリを実行すると、正常なシャットダウンを調整するのに十分な頻度で実行されます。 スケジュールされたイベント エンドポイントのクエリは 1 秒ごとに実行できますが、すべてのユース ケースで 1 秒の頻度は必要ない場合があります。 これらのクエリは、スポット VM 上で実行されるアプリケーションから取得する必要があります。 クエリは外部ソースから取得できません。 その結果、クエリは VM コンピューティング容量を消費し、メイン ワークロードから処理能力を盗みます。 特定の状況を満たすために、競合する優先順位のバランスを取る必要があります。

• オーケストレーションを自動化する:Preemptシグナルを収集した後、オーケストレーションはそのシグナルに基づいて動作する必要があります。 時間の制約がある場合、Preempt シグナルはワークロードの正常なシャットダウンを試み、スポット VM を置き換える自動化されたプロセスを開始する必要があります。 詳細については、次のリソースを参照してください。

  • スケジュールされたイベント を する
  • スケジュールされたイベントの種類
  • エンドポイントのクエリ頻度

デプロイ システムを構築する

オーケストレーションには、削除後に新しいスポット VM をデプロイするための自動化されたパイプラインが必要です。 パイプラインは、永続性を確保するために、中断可能なワークロードの外部で実行する必要があります。 デプロイ パイプラインは、スポット VM に対して選択した削除ポリシーに従って動作する必要があります。

削除ポリシーの場合は、さまざまな VM サイズを使用し、異なるリージョンにデプロイするパイプラインを構築することをお勧めします。 Stop/Deallocate ポリシーの場合、デプロイ パイプラインには 2 つの異なるアクションが必要です。 VM を最初に作成するには、パイプラインで適切なサイズの VM を適切な場所にデプロイする必要があります。 削除された VM の場合、パイプラインは動作するまで VM の再起動を試みる必要があります。 Azure Monitor アラートと Azure 関数の組み合わせは、デプロイ システムを自動化する 1 つの方法です。 パイプラインでは bicep テンプレートを使用できます。 これらは宣言型でべき等であり、インフラストラクチャのデプロイのベスト プラクティスを表します。

即時削除の準備

作成したスポット VM とワークロードを実行する前に、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 環境の外部にチェックポイントを格納します。

オーケストレーションをテストする

削除イベントをシミュレートして、開発/テスト環境でオーケストレーションをテストします。 詳細については、「削除の シミュレート」を参照してください。

べき等ワークロードを設計する

べき等ワークロードを設計することをお勧めします。 イベントを複数回処理した結果は、1 回の処理と同じである必要があります。 削除すると、正常なシャットダウンを確保する努力にもかかわらず、強制シャットダウンが発生する可能性があります。 強制シャットダウンでは、完了前にプロセスを終了できます。 べき等ワークロードは、結果を変更することなく、同じメッセージを複数回受信できます。 詳細については、「 べき等性」を参照してください。

アプリケーションのウォームアップ期間を使用する

割り込み可能なワークロードのほとんどは、アプリケーションを実行します。 アプリケーションのインストールと起動には時間が必要です。 また、外部ストレージに接続し、チェックポイントから情報を収集する時間も必要です。 アプリケーションのウォームアップ期間を設定してから、処理を開始します。 ウォームアップ期間中は、アプリケーションを開始し、接続を確立し、貢献する準備をする必要があります。 アプリケーションの正常性を検証した後にのみ、アプリケーションがデータの処理を開始できるようにします。

ユーザー割り当てマネージド 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 回限りの手動プッシュについて説明します。 この実装にはデプロイ パイプラインがありません。 ただし、調整プロセスを自動化するには、デプロイ パイプラインが不可欠です。 次の図は、シナリオ例のアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

次のワークフローは、上記のダイアグラムに対応しています。

1. VM アプリケーション定義: VM アプリケーション定義は、Azure コンピューティング ギャラリーに作成されます。 アプリケーション名、場所、オペレーティング システム、およびメタデータを定義します。 アプリケーションのバージョンは、VM アプリケーション定義の番号付きバージョンです。 アプリケーションのバージョンは、VM アプリケーションを表します。 スポット VM と同じリージョンに存在する必要があります。 アプリケーション バージョンは、ストレージ アカウント内のソース アプリケーション パッケージにリンクされます。

2. ストレージ アカウント: ストレージ アカウントには、ソース アプリケーション パッケージが格納されます。 このアーキテクチャでは、worker-0.1.0.tar.gzという名前の圧縮 tar ファイルです。 これには 2 つのファイルが含まれています。 1 つのファイルは、.NET worker アプリケーションをインストールする orchestrate.sh bash スクリプトです。

3. スポット VM : スポット VM がデプロイ。 アプリケーションのバージョンと同じリージョンに存在する必要があります。 デプロイ後に vm に worker-0.1.0.tar.gz をダウンロードします。 bicep テンプレートは、標準ファミリ VM に Ubuntu イメージをデプロイします。 これらの構成は、このアプリケーションのニーズを満たし、アプリケーションの一般的な推奨事項ではありません。

4. ストレージ キュー: .NET worker で実行されるもう 1 つのサービスには、メッセージ キュー ロジックが含まれています。 Microsoft Entra ID は、ロールベースのアクセス制御を使用して、ユーザー割り当て ID を使用して、Azure Queue Storage 内のストレージ キューへのスポット VM アクセスを許可します。

5. .NET worker アプリケーション:orchestrate.sh スクリプトは、2 つのバックグラウンド サービスを実行する .NET worker アプリケーションをインストールします。 最初のサービスは、スケジュールされたイベント エンドポイントに対してクエリを実行し、 Preempt シグナルを探して、このシグナルを 2 番目のサービスに送信します。 2 番目のサービスは、ストレージ キューからのメッセージを処理し、最初のサービスからの Preempt シグナルをリッスンします。 2 番目のサービスは、シグナルを受信すると、ストレージ キューの処理を中断し、シャットダウンを開始します。

6. スケジュールされたイベント エンドポイントのクエリ: API 要求は、静的なルーティング不可能な IP アドレス 169.254.169.254に送信されます。 API 要求は、スケジュールされたイベント エンドポイントに対して、インフラストラクチャ メンテナンス シグナルのクエリを実行します。

7. Application Insights: アーキテクチャでは、学習目的でのみ Application Insights が使用されます。 割り込み可能なワークロード オーケストレーションの必須コンポーネントではありませんが、.NET worker アプリケーションからのテレメトリを検証できます。 .NET worker アプリケーションは、テレメトリを Application Insights に送信します。 詳細については、「 .NET アプリケーションからのライブ メトリックを有効にする」を参照してください。

このシナリオをデプロイする

このアーキテクチャをデプロイするためのテンプレート、スクリプト、およびステップ バイ ステップの手順を含む 、割り込み可能なワークロード と呼ばれる GitHub リポジトリがあります。

次の手順

スポット仮想マシン

関連リソース

• マルチテナント ソリューションでのコスト管理と割り当てのためのアーキテクチャ アプローチ
• Azure で Windows VM を実行する
• Azure で Linux VM を実行する