Azure Batch ワークフローにおけるコンピューティング ノード (またはノード) とは、アプリケーションのワークロードの一部を処理する仮想マシンです。 プールは、アプリケーションを実行するためのこれらのノードのコレクションです。 この記事では、ノードとプールの詳細と、Azure Batch ワークフローでそれらを作成して使用する際の考慮事項について説明します。
ノード
ノードは、アプリケーションのワークロードの一部を処理するための専用の Azure 仮想マシン (VM) またはクラウド サービス VM です。 ノードのサイズによって、CPU コアの数、メモリ容量、およびノードに割り当てられるローカル ファイル システムのサイズが決まります。
Azure Cloud Services か、Azure Virtual Machines Marketplace のイメージを使用して Windows ノードまたは Linux ノードのプールを作成できます。
ノードは、ノードのオペレーティング システム環境でサポートされている任意の実行可能ファイルまたはスクリプトを実行できます。 実行可能ファイルまたはスクリプトとしては、*.exe、*.cmd、*.bat および PowerShell スクリプト (Windows の場合)、バイナリ、シェル、Python スクリプト (Linux の場合) などがあります。
Batch のすべてのコンピューティング ノードには、次の要素が存在します。
- 標準的なフォルダー構造と、それに関連付けられた (タスクから参照できる) 環境変数。
- ファイアウォール 設定。
- Windows (Remote Desktop Protocol (RDP)) と Linux (Secure Shell (SSH)) の両方のノードへのリモート アクセス (リモート アクセスを無効にしてプールを作成している場合を除く)。
既定では、ノードは相互に通信できますが、同じプールに含まれていない仮想マシンと通信することはできません。 ノードが他の仮想マシン、またはオンプレミス ネットワークと安全に通信できるようにするために、プールを Azure 仮想ネットワーク (VNet) のサブネット内にプロビジョニングできます。 そのようにすると、パブリック IP アドレスを介してノードにアクセスできるようになります。 Batch はこれらのパブリック IP アドレスを作成し、プールの有効期間中に変更される可能性があります。 また、制御 する静的パブリック IP アドレスを持つプールを作成 することもできます。これにより、予期せず変更されることはありません。
プール
プールは、アプリケーションが実行されるノードのコレクションです。
Azure Batch プールは、コア Azure コンピューティング プラットフォームの上に構築されます。 これにより、大規模な割り当て、アプリケーションのインストール、データの分散、状態の監視、プール内のコンピューティング ノード数の柔軟な調整 (スケーリング) が可能になります。
プールに追加されたすべてのノードに対し、一意の名前と IP アドレスが割り当てられます。 ノードがプールから削除されると、オペレーティング システムまたはファイルに加えられた変更は失われ、将来使用できるように名前と IP アドレスが解放されます。 ノードをプールから削除すると、その有効期間が終了します。
プールは、プールが作成された Batch アカウントでのみ使用できます。 Batch アカウントでは、実行する必要があるアプリケーションのリソース要件を満たすために、複数のプールを作成できます。
プールは手動で作成できるほか、実行する操作を指定した場合は Batch サービスによって自動的に作成できます。 プールを作成するときに次の属性を指定できます。
重要
Batch アカウントには、1 つの Batch アカウントで使用できるコア数に上限を設ける既定のクォータが割り当てられています。 コア数は、コンピューティング ノードの数に対応します。 既定のクォータと、クォータを増やす手順については、「Azure Batch サービスのクォータと制限」を参照してください。 プールが目標ノード数を達成していない場合は、コア クォータが原因である可能性があります。
オペレーティング システムとバージョン
Batch プールを作成するときに、Azure 仮想マシン構成と、プール内の各コンピューティング ノード上で実行するオペレーティング システムの種類を指定します。
構成
仮想マシンの構成
仮想マシンの構成は、プールが Azure 仮想マシンで構成されるように指定します。 これらの VM は、Linux イメージまたは Windows イメージのいずれかから作成できます。
Batch ノード エージェントは、プール内の各ノードで実行されるプログラムで、ノードと Batch サービスの間のコマンドと制御のインターフェイスを提供します。 オペレーティング システムに応じてさまざまなノード エージェントの実装 (SKU と呼ばれます) があります。 仮想マシン構成に基づいてプールを作成する場合は、ノードのサイズと使用するイメージのソースだけでなく、ノードにインストールする仮想マシン イメージの参照と Batch ノード エージェント SKU も指定する必要があります。 プールに関するこれらのプロパティの指定の詳細については、「 Azure Batch プールの Linux コンピューティング ノードのプロビジョニング」を参照してください。 必要に応じて、Marketplace イメージから作成される VM をプールするために 1 つまたは複数の空のデータ ディスクをアタッチするか、VM の作成に使用するカスタム イメージにデータ ディスクを含めることができます。 データ ディスクを含める場合は、それらを使用する VM 内からディスクを マウントおよびフォーマットする必要があります。
ノード エージェント SKU
プールを作成するときは、VHD のベース イメージの OS に応じて、適切な nodeAgentSkuId を選択する必要があります。 サポートされるノード エージェント SKU をリスト表示する操作を呼び出して、使用可能なノード エージェント SKU ID と OS イメージ参照のマッピングを取得できます。
仮想マシン プールのカスタム イメージ
カスタム イメージを使用してプールを作成する方法については、「Azure Compute Gallery を使用してカスタム プールを作成する」を参照してください。
仮想マシンのプールでのコンテナーのサポート
Batch API を使用して仮想マシン構成プールを作成するときに、Docker コンテナーでタスクを実行するためのプールを設定できます。 現在は、Docker コンテナーをサポートするイメージを使ってプールを作成する必要があります。 Azure Marketplace の Windows Server 2016 Datacenter with Containers イメージを使用するか、Docker Community Edition (または Enterprise Edition) と必要なすべてのドライバーを含むカスタム VM イメージを指定する必要があります。 プール設定には、プールの作成時にコンテナー イメージを VM にコピーするコンテナー構成が含まれている必要があります。 これにより、プール上で実行されるタスクが、コンテナー イメージとコンテナー実行オプションを参照できます。
詳細については、「Azure Batch で Docker コンテナー アプリケーションを実行する」を参照してください。
ノードの種類とターゲット
プールを作成する際、必要なノードの種類と各ノードのターゲット数を指定できます。 ノードには次の 2 種類があります。
- 専用ノード。 専用のコンピューティング ノードは、ワークロード用に予約されます。 通常、スポット ノードよりもコストは高くなりますが、割り込まれることはありません。
- スポット ノード。 スポット ノードは、Azure の余剰容量を利用して Batch ワークロードを実行します。 スポット ノードは専用ノードより 1 時間あたりのコストが低く、多大なコンピューティング能力が必要なワークロードを可能にします。 詳細については、「Batch でスポット VM を使用する」を参照してください。
スポット ノードは、Azure の余剰容量が不足している場合に割り込まれることがあります。 タスクの実行中にノードが割り込まれた場合、タスクはキューに戻され、コンピューティング ノードが再び使用可能になると再度実行されます。 スポット ノードは、ジョブの完了時間に柔軟性があり作業が多数のノードにわたって分散されているワークロードに適したオプションです。 シナリオにスポット ノードを使用する前に、プリエンプションによって失われた作業が最小限で、再開または再作成が簡単であることを確認してください。
同じプール内で、スポットおよび専用計算ノードの両方を使用することができます。 ノードの種類ごとに、必要なノード数を指定できる独自のターゲット設定があります。
コンピューティング ノードの数がターゲットと呼ばれるのは、状況によってはプールが必要なノード数に達しないことがあるためです。 たとえば、プールが最初に Batch アカウントのコア クォータに達した場合は、ターゲットを実現できないことがあります。 または、ノードの最大数を制限する自動スケーリング式をプールに適用した場合、プールがターゲットを達成できない可能性があります。
注
Batch スポット コンピューティング ノードが割り込まれると、最初に unusable 状態に遷移します。 しばらくすると、これらのコンピューティング ノードは、 preempted 状態を反映するように遷移します。 Batch では、 試行と復元 の動作が自動的に有効になり、ターゲット インスタンス数を維持するためのベスト エフォート目標を使用して、削除されたスポット インスタンスを復元できます。
スポット ノードと専用ノードの両方の価格情報については、「Batch の価格」を参照してください。
ノード サイズ
Azure Batch プールを作成する場合に、Azure で使用可能なほぼすべての VM ファミリとサイズを選択することができます。 Azure には、さまざまなワークロードに対応した各種の VM サイズが用意されています。たとえば、特殊な HPC または GPU 対応の VM サイズなどです。 ノード VM のサイズは、プールの作成時にのみ選択できます。 つまり、プールが作成されると、その VM サイズを変更することはできません。
詳細については、「Choose a VM size for compute nodes in an Azure Batch pool (Azure Batch プールのコンピューティング ノード用の VM サイズを選択する)」を参照してください。
自動スケーリング ポリシー
動的なワークロードの場合は、自動スケーリング ポリシーをプールに適用できます。 Batch サービスは定期的に数式を評価し、コンピューティング シナリオの現在のワークロードとリソースの使用状況に応じてプール内のノード数を動的に調整します。 これにより、必要なリソースのみを使用し、不要なリソースを解放することで、アプリケーションの全体的な実行コストを削減することができます。
自動スケールを有効にするには、 自動スケール式 を作成してプールに関連付けます。 Batch サービスは、この式を使用して、次のスケール間隔 (構成可能な間隔) におけるプール内のノードの目標数を決定します。 プールの自動スケール設定は、プールの作成時に指定できるほか、後からプールに対してスケーリングを有効にすることもできます。 スケーリングが有効にされたプールのスケーリング設定を更新することもできます。
たとえばジョブによっては、多数のタスクを実行対象として送信することが要求されることも考えられます。 この場合、現在キューに格納されているタスクの数とジョブ内のタスクの完了率に基づいてプール内のノード数を調整するスケール式をプールに割り当てることができます。 Batch サービスは、定期的に式を評価し、ワークロードと他の式の設定に基づいてプールのサイズを変更します。 このサービスでは、キュー内のタスクの数が多くなるとそれに応じて必要なノードが追加され、キュー内のタスクや実行中のタスクがなくなるとノードが削除されます。
スケーリング式には、次のメトリックを使用できます。
- 時間メトリック : 指定した時間数内で 5 分おきに収集された統計情報に基づきます。
- リソース メトリック : CPU 使用量、帯域幅使用量、メモリ使用量、およびノードの数に基づきます。
- タスク メトリック: "アクティブ" (キューに登録済み)、"実行中"、"完了" などのタスクの状態に基づきます。
プール内のコンピューティング ノードの数が自動スケールによって縮小される場合、その縮小操作のタイミングで実行されているタスクの扱いを考慮に入れる必要があります。 その点に対応するために、Batch には式に含めることができるノードの割り当て解除オプションが用意されています。 たとえば、実行中のタスクを即座に停止したうえで再度キューに登録して別のノードで実行するか、完了するまで待ってノードをプールから削除するかを指定できます。 ノードの割り当て解除オプションを taskcompletion または retaineddata に設定すると、すべてのタスクが完了するまで、またはすべてのタスクの保持期間が切れるまで、プールのサイズ変更操作を回避できます。
アプリケーションの自動的なスケーリングの詳細については、「 Azure Batch プール内のコンピューティング ノードの自動スケール」を参照してください。
ヒント
コンピューティング リソースの使用率を最大にするには、ジョブ完了時のノードの目標個数を 0 に設定し、実行中のタスクは完了するまで実行するようにします。
タスクのスケジューリング ポリシー
プール内の各コンピューティング ノードで並列実行できるタスク数は、 ノードあたりの最大タスク数 の構成オプションによって上限が決まります。
既定の構成では、1 つのノードで一度に 1 つのタスクを実行するように指定しますが、1 つのノードで複数のタスクを同時に実行すると便利なシナリオがあります。 ノードごとに複数のタスクを利用できる可能性がある方法については、コンカレント ノード タスクに関する記事のシナリオ例を参照してください。
Batch でプール内のすべてのノードにタスクを均等に配分するか、1 つのノードに最大数のタスクを割り当ててから次のノードにタスクを割り当てていくかを決定することもできます。これは "フィルの種類" を指定することによって行います。
通信状態
ほとんどのシナリオでは、タスクは独立して動作し、相互に通信する必要はありません。 ただし、タスク間の通信が必要なアプリケーションも一部存在します (MPI のシナリオでのアプリケーションなど)。
ノード間通信を許可するようにプールを構成し、実行時にプール内のノードが通信できるようにすることができます。 ノード間通信が有効になっている場合、Cloud Services 構成プール内のノードは 1100 を超えるポートで相互に通信でき、仮想マシン構成プールはポート上のトラフィックを制限しません。
ノード間通信を有効にすると、クラスター内のノードの配置にも影響が生じます。デプロイの制限上、プール内の最大ノード数が制限される場合もあります。 アプリケーションがノード間の通信を必要としない場合、Batch サービスは、並列処理能力の向上を可能にするために、多数のノードを多数の異なるクラスターやデータ センターからプールに割り当てることができます。
開始タスク
必要に応じて、そのノードがプールに参加し、ノードが再起動または再イメージ化されるたびに、各ノードで実行される 開始タスク を追加できます。 開始タスクは、タスクの実行に使用するコンピューティング ノードを準備する (タスクによってコンピューティング ノードで実行されるアプリケーションをインストールするなど) 場合に特に有効です。
アプリケーション パッケージ
プール内のコンピューティング ノードにデプロイするアプリケーション パッケージを指定できます。 アプリケーション パッケージにより、タスクによって実行されるアプリケーションのデプロイとバージョン管理がシンプルになります。 プールに指定したアプリケーション パッケージは、そのプールに参加しているすべてのノードにインストールされます。また、ノードが再起動または再イメージ化されるたびにインストールされます。
アプリケーション パッケージを使った Batch ノードへのアプリケーションのデプロイについて詳しくは、「Batch アプリケーション パッケージを使用したコンピューティング ノードへのアプリケーションのデプロイ」をご覧ください。
仮想ネットワーク (VNet) とファイアウォールの構成
コンピューティング ノードのプールを Batch でプロビジョニングする際に、プールを Azure 仮想ネットワーク (VNet) のサブネットに関連付けることができます。 Azure VNet を使用するには、Batch クライアント API で Microsoft Entra 認証を使用する必要があります。 Microsoft Entra ID の Azure Batch のサポートについては、Active Directory を使用した Batch サービス ソリューションの認証に関する記事に記載されています。
VNet に関する要件
VNet で Batch プールを設定する方法の詳細については、仮想ネットワークでの仮想マシンのプールの作成に関するページを参照してください。
ヒント
ノードへのアクセスに使用されるパブリック IP アドレスが変更されないようにするには、ユーザーが制御するパブリック IP アドレスを指定してプールを作成することができます。
プールとコンピューティング ノードの有効期間
Azure Batch ソリューションを設計するときは、いつ、どのようにプールを作成するかと、それらのプール内のコンピューティング ノードをどのくらいの期間利用できるようにしておくかを指定する必要があります。
1 つの方法として、送信する各ジョブについてプールを作成し、対応するタスクが実行を終えた直後にそのプールを削除することができます。 これにより、ノードは必要なときにのみ割り当てられ、アイドル状態になるとシャットダウンされるため、使用率が最大化されます。 つまり、ジョブはノードが割り当てられるのを待つ必要があることを意味しますが、開始タスクの完了を待機するように指定されている場合は、ノードが個別に割り当てられ、開始タスクが完了するとすぐにタスクが実行されるようにスケジュールされることに注意してください。 Batch は、 ノードにタスクを割り当てる前に、プール内のすべてのノードが使用可能になるまで待機しません。 そのため、使用可能なすべてのノードで使用率が最大になります。
もう一方の極端な例としては、ジョブをすぐに開始することが最優先事項であるような場合、プールを事前に作成し、ジョブが送信される前にノードを使用可能にしておくという方法があります。 この場合はタスクをすぐに開始できますが、ノードはタスクが割り当てられるまでアイドル状態で待機する可能性があります。
変動の大きい継続的な負荷に対応するために、通常はこれらを組み合わせた方法が採用されます。 複数のジョブが送信されるプールを作成し、ジョブの負荷に応じてノードの数をスケールアップまたはスケールダウンすることができます。 この方法では、現在の負荷に応じて事後的に対応できます。また、負荷を予測できる場合は事前に対応することもできます。 詳細については、「自動スケーリング ポリシー」を参照してください。
自動プール
自動プールは、プール内で実行されるジョブの前に明示的に作成されるのではなく、ジョブの送信時に Batch サービスによって作成されるプールです。 Batch サービスは、指定した特性に従って自動プールの有効期間を管理します。 ほとんどの場合、これらのプールは、ジョブの完了後に自動的に削除されるように設定されます。
証明書によるセキュリティ
証明書を使用する必要があるのは、通常、Azure Storage アカウントのキーなど、タスクの機密情報を暗号化または復号化するときです。 このようなときは、ノードに証明書をインストールすることで対応できます。 暗号化された機密情報は、コマンド ライン パラメーターを通じてタスクに渡されるか、タスク リソースの 1 つに埋め込まれます。インストールされた証明書を使用して、機密情報を復号化できます。
証明書の追加操作 (Batch REST) または CertificateOperations.CreateCertificate メソッド (Batch .NET) を使用して、Batch アカウントに証明書を追加できます。 次に、新規または既存のプールに証明書を関連付けることができます。
証明書がプールに関連付けられると、Batch サービスは、プール内の各ノードに証明書をインストールします。 Batch サービスはノードの起動時、いずれかのタスク (開始タスク、ジョブ マネージャー タスクも含まれます) を起動する前に、適切な証明書をインストールします。
証明書を既存のプールに追加した場合は、そのコンピューティング ノードを再起動して、証明書をノードに適用する必要があります。
次のステップ
- ジョブとタスクについて学習します。
- プールとノードのバックグラウンド操作の失敗を検出して回避する方法を学習します。