この記事では、Azure スポット仮想マシン (VM) での構築に関するベスト プラクティスの概要を説明し、デプロイ可能なシナリオ例を紹介します。 スポット VM を利用すると、通常の VM と比較して大幅な割引でコンピューティング容量にアクセスできます。 この割引により、コストを最適化しようとしている組織にとって魅力的なソリューションとなりますが、この割引には条件があります。 スポット VM は、いつでもコンピューティングへのアクセスを失う可能性があります。 このプロセスを削除 (eviction) と呼びます。 スポット 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 Retail Price API に対してクエリを実行して、関心のある SKU のスポット価格をプログラムで取得することもできます。
中断可能なワークロードを理解する
中断可能なワークロードは、スポット VM の最適なユース ケースです。 中断可能なワークロードには、いくつかの共通する特性があります。 時間の制約が最小限であるか、まったくなく、組織にとっての優先度が低く、処理時間は短時間です。 実行されるプロセスは、突然停止して後で再開しても組織の重要なプロセスに損害を与えることがないものです。 中断可能なワークロードの例としては、バッチ処理アプリケーションやデータ分析があり、他にも非運用環境用の継続的インテグレーション/継続的デプロイ エージェントを作成するワークロードがあります。 これらの特徴とは対照的に、通常つまりミッション クリティカルなワークロードでは、サービス レベル アグリーメント (SLA)、スティッキー セッション、ステートフル データという特徴があります。 この表では、両方のワークロードの種類の例を示します。
| 中断可能なワークロードの特徴 | 通常のワークロードの特徴 | |
|---|---|---|
| 機能 | 時間の制約は最小限、またはまったくない。 組織にとっての優先度が低い。 処理時間が短い |
サービス レベル アグリーメント (SLA) スティッキー セッションの要件 ステートフル ワークロード |
スポット VM を中断不可ワークロードで使用できますが、これがコンピューティング容量の唯一の供給源であってはなりません。 アップタイムの要件を満たすために必要な数の通常の VM を使用してください。
削除について理解する
スポット VM では、作成後のサービス レベル アグリーメント (SLA) はなく、いつでもコンピューティングへのアクセスを失う可能性があります。 このようなコンピューティングの損失を削除と呼びます。 コンピューティングの供給と需要によって、削除が促進されます。 特定の VM サイズの需要が一定のレベルを超えると、コンピューティングを通常の VM で使用できるようにするために、Azure によってスポット 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 のコンピューティング容量と非静的 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 を使用する: Scheduled Events サービスを各 VM に使用することをお勧めします。 Azure は、インフラストラクチャのメンテナンスの影響を受ける場合、VM にシグナルを送信します。 削除はインフラストラクチャ メンテナンスと見なされます。 Azure は、削除される少なくとも 30 秒前にすべての VM に Preempt シグナルを送信します。 スケジュール イベントと呼ばれるサービスを使用すると、ルーティング不可能な静的 IP アドレス 169.254.169.254 でエンドポイントに対してクエリを実行することで、この Preempt シグナルをキャプチャできます。
頻繁なクエリを使用する: 正常なシャットダウンをオーケストレーションするのに十分な頻度でスケジュール イベント エンドポイントに対するクエリを実行することをお勧めします。 Scheduled Events エンドポイントに対するクエリは最高 1 秒間隔で実行できますが、この 1 秒という頻度がすべてのユース ケースに必要とは限りません。 これらのクエリは、スポット VM で実行されているアプリケーションからである必要があります。 クエリは外部ソースからであってはなりません。 その結果、クエリによって VM コンピューティング容量が消費され、メイン ワークロードのための処理能力が奪われることになります。 利用者固有の状況に合わせて、これらの競合する優先事項のバランスを取る必要があります。
オーケストレーションを自動化する: Preempt シグナルを受け取ったら、そのシグナルに基づいてオーケストレーションによってアクションを起こすはずです。 時間の制約を考慮して、Preempt シグナルによってワークロードの正常なシャットダウンを試行するとともに自動プロセスを開始してスポット VM を置換する必要があります。 詳細については、次を参照してください。
デプロイ システムを構築する
オーケストレーションには、削除されたときに新しいスポット VM をデプロイするための自動化されたパイプラインが必要です。 パイプラインは、永続性を確保するために、中断可能なワークロード自体の外部で実行する必要があります。 デプロイ パイプラインの動作方法は、スポット VM に対して選択された削除ポリシーによって異なります。
"削除" というポリシーの場合は、さまざまな VM サイズを使用し、さまざまなリージョンにデプロイするパイプラインを構築することをお勧めします。 "停止/割り当て解除" というポリシーの場合は、デプロイ パイプラインには 2 つの異なるアクションが必要です。 VM の最初の作成時は、パイプラインによって適切なサイズの VM を適切な場所にデプロイする必要があります。 削除された VM の場合は、VM が動作するようになるまでパイプラインによって再起動を試みる必要があります。 Azure Monitor アラートと Azure Functions の組み合わせは、デプロイ システムを自動化する多数の方法の 1 つです。 パイプラインで bicep テンプレートを使用することもできます。 これらは宣言型で、べき等であり、インフラストラクチャのデプロイのベスト プラクティスを表します。
即時削除に備える
スポット VM は作成直後でも、場合によってはワークロードが実行される前でも、削除の対象と指定される可能性があります。 スポット VM を作成するための容量があったからといって、それがずっと続くわけではありません。 スポット VM には、作成後の可用性保証 (SLA) はありません。 オーケストレーションでは、即時削除を考慮する必要があります。 Preempt シグナルによって引き続き、削除の少なくとも 30 秒前の通知が送られます。
即時削除に備えるために、VM の正常性チェックをオーケストレーションに組み込むことをお勧めします。 即時削除のためのオーケストレーションが Schedule Events Preempt シグナルに依存していてはなりません。 Preempt シグナルのクエリを実行できるのは VM 自体だけであり、アプリケーションを起動して Schedule Events エンドポイントに対してクエリを実行して正常にシャットダウンするのに十分な時間はありません。 そのため、正常性チェックはワークロード環境の外部に存在する必要があります。 この正常性チェックでスポット VM の状態を監視し、状態が割り当て解除中または停止中に変化したときにデプロイ パイプラインを開始してスポット VM を置換する必要があります。
複数同時削除に備える
スポット VM のクラスターを実行する場合は、複数同時削除に耐えられるようにワークロードを設計する必要があります。 ワークロード内の複数のスポット VM が同時に削除されることもあります。 複数 VM の同時削除によって、アプリケーションのスループットに影響が及ぶ可能性があります。 この状況を回避するには、デプロイ パイプラインで複数の VM からシグナルを収集できることと、複数の代わりの VM を同時にデプロイできることが必要です。
正常なシャットダウンのために設計する
VM のシャットダウン プロセスが 30 秒未満であることと、VM を削除前にシャットダウンできるようにすることが必要です。 シャットダウンに要する時間は、ワークロードで Scheduled Events エンドポイントに対するクエリを実行する頻度によって異なります。 エンドポイントに対してクエリを実行する頻度が高いほど、シャットダウン プロセスが長くなる可能性があります。 シャットダウン プロセスでは、リソースを解放し、接続をドレインし、イベント ログをフラッシュする必要があります。 コンテキストを保存するためにチェックポイントを定期的に作成して保存するとともに、より効率的な復旧戦略を構築する必要があります。 チェックポイントは、次の VM がどのプロセスまたはトランザクションから開始する必要があるかについての情報にすぎません。 VM は前の VM が中断したところから再開する必要があるか、それとも新しい VM が変更をロールバックしてプロセス全体を再度開始する必要があるかをこれによって示す必要があります。 チェックポイントは、スポット VM 環境の外部に格納する必要があります。 ストレージ アカウントがあるとよいでしょう。
オーケストレーションをテストする
開発/テスト環境で削除イベントをシミュレートしてオーケストレーションをテストすることをお勧めします。 詳細については、「削除をシミュレートする」を参照してください。
べき等ワークロードを設計する
べき等ワークロードを設計することをお勧めします。 1 つのイベントを複数回処理したときの結果は、1 回処理したときと同じである必要があります。 正常にシャットダウンしようとする努力にもかかわらず、削除が強制シャットダウンにつながることもあります。 強制シャットダウンの場合は、プロセスが完了前に終了させられることがあります。 べき等ワークロードでは、同じメッセージを複数回受け取っても結果は変わりません。 詳細については、「べき等性」を参照してください。
アプリケーション ウォームアップ期間を使用する
ほとんどの中断可能ワークロードでは、アプリケーションが実行されます。 アプリケーションには、インストールする時間と起動する時間が必要です。 外部ストレージに接続して、チェックポイントから情報を収集する時間が必要です。 アプリケーション ウォームアップ期間を設けて、その後で処理を開始できるようにすることをお勧めします。 このウォームアップ期間の中で、アプリケーションを起動し、接続し、貢献の準備をする必要があります。 アプリケーションの正常性の検証が完了した後にのみ、アプリケーションによるデータの処理を開始できるようにする必要があります。
ユーザー割り当てマネージド ID を構成する
認証と認可のプロセスを効率化するために、ユーザー割り当てマネージド ID を使用することをお勧めします。 ユーザー割り当てマネージド ID を使用すると、資格情報をコードの中に入れる必要はなくなります。システム割り当てマネージド ID のように単一のリソースには関連付けられません。 ユーザー割り当てマネージド ID には、Microsoft Entra ID からのアクセス許可とアクセス トークンが含まれており、これらは再利用可能で、オーケストレーション中にスポット VM に割り当てることができます。 スポット VM 間のトークンの一貫性は、オーケストレーションと、スポット VM が持つワークロード リソースへのアクセスを効率化するのに役立ちます。
システム割り当てマネージド ID を使用する場合は、新しいスポット VM によって別のアクセス トークンが Microsoft Entra ID から取得されることがあります。 システム割り当てマネージド ID を使用する必要がある場合は、ワークロードが 403 Forbidden Error 応答に対して回復性があるようにすることをお勧めします。 オーケストレーションでは、適切なアクセス許可で Microsoft Entra ID からトークンを取得する必要があります。 詳細については、マネージド ID に関するページを参照してください。
サンプル シナリオ
このシナリオ例では、中断可能ワークロードとして適格な、キュー処理アプリケーションをデプロイします。 シナリオ内のスクリプトは例示です。 このシナリオでは、リソースをデプロイするための 1 回限りの手動プッシュの方法を順に示します。 この実装では、デプロイ パイプラインは用意されていません。 ただし、オーケストレーションのプロセスを自動化するにはデプロイ パイプラインが不可欠です。 図に、シナリオ例のアーキテクチャを示します。
次のメモでは、アーキテクチャの主な側面について説明します。
- VM アプリケーション定義: VM アプリケーション定義は、Azure Compute Gallery 内に作成されます。 アプリケーション名、場所、オペレーティング システム、およびメタデータが定義されます。 このアプリケーション バージョンは、VM アプリケーション定義の番号付きバージョンの 1 つです。 このアプリケーション バージョンは、VM アプリケーションのインスタンス化の 1 つです。 スポット VM と同じリージョンに存在する必要があります。 このアプリケーション バージョンは、ストレージ アカウント内のソース アプリケーション パッケージにリンクされます。
- ストレージ アカウント: このストレージ アカウントに、ソース アプリケーション パッケージが格納されます。 このアーキテクチャでは、
worker-0.1.0.tar.gzという名前の圧縮 tar ファイルです。 この中には 2 つのファイルがあります。 ファイルの 1 つはorchestrate.shbash スクリプトで、これによって .NET worker アプリケーションがインストールされます。 - スポット VM: スポット VM がデプロイされます。 アプリケーション バージョンと同じリージョンに存在する必要があります。 デプロイ後に
worker-0.1.0.tar.gzが VM にダウンロードされます。 この bicep テンプレートによって、Ubuntu イメージが Standard ファミリ VM 上にデプロイされます。 これらの構成は、このアプリケーションのニーズを満たしていますが、お客様のアプリケーションのための一般的な推奨事項ではありません。 - ストレージ キュー: .NET worker で実行されるもう 1 つのサービスの中に、メッセージ キュー ロジックがあります。 Microsoft Entra ID によって、RBAC を使用してユーザー割り当て ID によるストレージ キューへのアクセスがスポット VM に許可されます。
- .Net worker アプリケーション: orchestrate.sh スクリプトで .NET worker アプリケーションがインストールされ、このアプリケーションによって 2 つのバックグラウンド サービスが実行されます。 最初のサービスは、Schedule Events エンドポイントに対してクエリを実行し、
Preemptシグナルを見つけて、このシグナルを 2 番目のサービスに送信します。 2 番目のサービスは、ストレージ キューからのメッセージを処理し、最初のサービスからのPreemptシグナルをリッスンします。 2 番目のサービスがシグナルを受信すると、ストレージ キューの処理が中断されてシャットダウンが開始します。 - Scheduled Events エンドポイントのクエリ: 静的な、ルーティング不可の IP アドレス 169.254.169.254 に API 要求が送信されます。 この API 要求で、Scheduled Event エンドポイントに対してインフラストラクチャ メンテナンス シグナルが照会されます。
- Application Insights: このアーキテクチャでは、学習のみを目的として Application Insights が使用されます。 これは、中断可能ワークロードのオーケストレーションに不可欠な要素ではありません。 これは、.NET worker アプリケーションからのテレメトリを検証する方法として含まれています。 この .NET worker アプリケーションはテレメトリを Application Insights に送信するように構成されています。 詳細については、.NET アプリケーションからのライブ メトリックを有効にすることについてのページを参照してください。
このシナリオのデプロイ
interruptible workload on spot という名前の GitHub リポジトリが作成済みであり、このアーキテクチャをデプロイするためのテンプレート、スクリプト、ステップバイステップの手順がここにあります。 このアーキテクチャに関する技術的な詳細とエンジニアリング成果物がこのリポジトリにあります。
次のステップ
Spot Virtual Machines の詳細については、Azure Spot Virtual Machines に関するページを参照してください。