Azure Batch のノードとプール

  • [アーティクル]

Azure Batch ワークフローにおけるコンピューティング ノード (またはノード) とは、アプリケーションのワークロードの一部を処理する仮想マシンです。 プールは、アプリケーションを実行するためのこれらのノードのコレクションです。 この記事では、ノードとプールの詳細と、Azure Batch ワークフローでそれらを作成して使用する際の考慮事項について説明します。

Nodes

ノードは、アプリケーションのワークロードの一部を処理するための専用の Azure 仮想マシン (VM) またはクラウド サービス VM です。 ノードのサイズによって、CPU コアの数、メモリ容量、およびノードに割り当てられるローカル ファイル システムのサイズが決まります。

Azure Cloud Services か、Azure Virtual Machines Marketplace のイメージを使用して Windows ノードまたは Linux ノードのプールを作成できます。

ノードは、そのオペレーティング システム環境が対応していれば、どのような実行可能ファイル (またはスクリプト) でも実行できます。 実行可能ファイルまたはスクリプトとしては、*.exe、*.cmd、*.bat および PowerShell スクリプト (Windows の場合)、バイナリ、シェル、Python スクリプト (Linux の場合) などがあります。

Batch のすべてのコンピューティング ノードには、次の要素が存在します。

既定では、ノードは相互に通信できますが、同じプールに属していない仮想マシンとは通信できません。 ノードが他の仮想マシン、またはオンプレミス ネットワークと安全に通信できるようにするために、プールを Azure 仮想ネットワーク (VNet) のサブネット内にプロビジョニングできます。 そのようにすると、パブリック IP アドレスを介してノードにアクセスできるようになります。 これらのパブリック IP アドレスは Batch によって作成され、プールの有効期間中に変化する可能性があります。 また、ユーザーが制御する静的パブリック 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 の価格」を参照してください。

ノード サイズ

Azure Batch プールを作成する場合に、Azure で使用可能なほぼすべての VM ファミリとサイズを選択することができます。 Azure には、さまざまなワークロードに対応した各種の VM サイズが用意されています。たとえば、特殊な HPC または GPU 対応の 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 つのノードで複数のタスクを同時に実行した方が都合のよい場合もあります。 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 サービスはノードの起動時、いずれかのタスク (開始タスク、ジョブ マネージャー タスクも含まれます) を起動する前に、適切な証明書をインストールします。

証明書を既存のプールに追加した場合は、そのコンピューティング ノードを再起動して、証明書をノードに適用する必要があります。

次のステップ