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 仮想マシン構成と、プール内の各コンピューティング ノード上で実行するオペレーティング システムの種類を指定します。

構成

Batch で使用できるプール構成には、次の 2 種類があります。

重要

現在、いずれかの構成を使用してプールを作成できますが、新しいプールは、Cloud Services の構成ではなく、仮想マシンの構成を使用して構成する必要があります。 現在および新しいすべての Batch 機能は、仮想マシンの構成プールによってサポートされます。 Cloud Services の構成プールでは、すべての機能はサポートされず、新しい機能は計画されていません。 2024 年 2 月 29 日を過ぎると、新しい 'CloudServiceConfiguration' プールを作成したり、既存のプールに新しいノードを追加したりすることはできなくなります。

仮想マシンの構成

仮想マシンの構成 は、プールが Azure 仮想マシンで構成されるように指定します。 これらの VM は、Linux イメージまたは Windows イメージのいずれかから作成できます。

Batch ノード エージェントは、プール内の各ノードで実行されるプログラムで、ノードと Batch サービスの間のコマンドと制御のインターフェイスを提供します。 オペレーティング システムに応じてさまざまなノード エージェントの実装 (SKU と呼ばれます) があります。 仮想マシン構成に基づいてプールを作成する場合は、ノードのサイズと使用するイメージのソースだけでなく、ノードにインストールする 仮想マシン イメージの参照 と Batch ノード エージェント SKU も指定する必要があります。 プールに関するこれらのプロパティの指定の詳細については、「 Azure Batch プールの Linux コンピューティング ノードのプロビジョニング」を参照してください。 必要に応じて、Marketplace イメージから作成される VM をプールするために 1 つまたは複数の空のデータ ディスクをアタッチするか、VM の作成に使用するカスタム イメージにデータ ディスクを含めることができます。 データ ディスクを含める場合は、それらを使用する VM 内からディスクを マウントおよびフォーマットする必要があります。

Cloud Services の構成

警告

Cloud Services 構成プールは非推奨とされます。 代わりに、仮想マシン構成プールを使用してください。 詳細については、「Batch プールの構成を Cloud Services から仮想マシンに移行する」を参照してください。

Cloud Services の構成 は、プールが Azure Cloud Services ノードで構成されるように指定します。 Cloud Services では Windows 計算ノードのみが提供されます。

Cloud Services の構成プールで使用可能なオペレーティング システムは、「Azure ゲスト OS リリースと SDK の互換性対応表」に一覧表示されており、使用可能な計算ノードのサイズは、「Cloud Services のサイズ」に一覧表示されています。 Cloud Services ノードを含むプールを作成する場合は、ノード サイズとその OS ファミリ (これにより OS と共にインストールされる .NET のバージョンが決定されます) を指定します。 Cloud Services は、Windows を実行する仮想マシンよりも迅速に Azure にデプロイされます。 Windows コンピューティング ノードのプールが必要な場合、デプロイ時間に関して Cloud Services にパフォーマンスのメリットがあることがわかります。

Cloud Services 内の worker ロールと同様、"OS バージョン" を指定できます。 "OS バージョン" には Latest (*) を指定することをお勧めします。これにより、ノードは自動的にアップグレードされ、新たにリリースされたバージョンに対応するための作業が不要になります。 特定の OS バージョンを選択するのは、主にアプリケーションの互換性を確保する必要がある場合です。こうすることで、バージョンの更新を許可する前に旧バージョンとの互換性をテストできます。 検証した後は、プールの OS バージョン を更新して、新しい OS イメージをインストールできます。 実行中のタスクは中断され、キューに再登録されます。

ノード エージェント SKU

プールを作成するときは、VHD のベース イメージの OS に応じて、適切な nodeAgentSkuId を選択する必要があります。 サポートされるノード エージェント SKU をリスト表示する操作を呼び出して、使用可能なノード エージェント SKU ID と OS イメージ参照のマッピングを取得できます。

仮想マシン プールのカスタム イメージ

カスタム イメージを使用してプールを作成する方法については、「Azure Compute Gallery を使用してカスタム プールを作成する」を参照してください。

または、マネージド イメージ リソースを使用して、仮想マシンのカスタム プールを作成することもできます。 Azure VM からカスタムの Linux イメージを準備する方法の詳細については、「仮想マシンまたは VHD のイメージを作成する方法」を参照してください。 Azure VM からカスタム Windows イメージを準備する方法については、「Azure で一般化された VM の管理対象イメージを作成する」を参照してください。

仮想マシンのプールでのコンテナーのサポート

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 時間あたりのコストが低く、多大なコンピューティング能力が必要なワークロードを可能にします。 詳細については、「優先順位の低い VM で Batch を使用する」を参照してください。

優先順位の低いノードは、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 で Azure Active Directory (AD) 認証を使用する必要があります。 Azure AD の Azure Batch のサポートについては、「Batch サービスの認証に Active Directory を使用する」に記載されています。

VNet に関する要件

一般的な要件

  • VNET が存在するサブスクリプションとリージョンは、プールの作成に使用する Batch アカウントと同じである必要があります。

  • プールに指定されたサブネットには、プールの対象となる VM 数 (つまり、プールの targetDedicatedNodes および targetLowPriorityNodes プロパティの合計) に対応できる十分な未割り当て IP アドレスが必要です。 サブネットの未割り当て IP アドレスが十分でない場合、プールによってコンピューティング ノードが部分的に割り当てられ、サイズ変更エラーが発生します。

  • VNET を提供するカスタムの DNS サーバーが、Azure Storage エンドポイントを解決できることが必要です。 具体的には、フォーム <account>.table.core.windows.net<account>.queue.core.windows.net<account>.blob.core.windows.net の URL を解決できる必要があります。

  • 同じ VNet または同じサブネットに複数のプールを作成できます (十分なアドレス空間がある場合)。 1 つのプールが複数の VNet または複数のサブネットにまたがって存在することはできません。

その他の VNET 要件は、Batch プールが仮想マシンの構成にあるかクラウド サービスの構成にあるかによって異なります。 VNET に新しいプールをデプロイする場合は、仮想マシンの構成が推奨されます。

仮想マシンの構成におけるプール

サポートされる VNET - Azure Resource Manager ベースの VNET のみ

サブネット ID - Batch API を使用してサブネットを指定するときに、そのサブネットの "リソース識別子" を使用します。 サブネット識別子の形式は次のとおりです。

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}

アクセス許可 - VNET のサブスクリプションまたはリソース グループに対するロックまたはセキュリティ ポリシーで、VNET を管理するためのユーザーのアクセス許可が制限されているかどうかを確認します。

追加のネットワーク リソース - VNet を含んでいるリソース グループには、Batch によって自動的に追加のネットワーク リソースが作成されます。

重要

専用または低優先度のノード 100 台ごとに、1 つのネットワーク セキュリティ グループ (NSG)、1 つのパブリック IP アドレス、1 つのロード バランサーが Batch によって作成されます。 これらのリソースは、サブスクリプションのリソース クォータによって制限されます。 大規模なプールでは、これらの 1 つ以上のリソースについて、クォータの引き上げの要求が必要になる場合があります。

ネットワーク セキュリティ グループ:Batch の既定値

サブネットでは、コンピューティング ノード上のタスクをスケジュールできるよう、Batch サービスからのインバウンド通信を許可する必要があります。また、ワークロードのニーズに応じて、Azure Storage などのリソースと通信するために、アウトバウンド通信を許可する必要があります。 仮想マシンの構成におけるプールの場合は、計算ノードにアタッチされたネットワーク インターフェイス (NIC) のレベルで、Batch により NSG が追加されます。 これらの NSG は、次の追加の規則で構成されます。

  • BatchNodeManagement サービス タグに対応する Batch サービスの IP アドレスからポート 29876 と 29877 で受信するインバウンド TCP トラフィック。
  • ポート 22 (Linux ノード) またはポート 3389 (Windows ノード) のインバウンド TCP トラフィック。リモート アクセスを許可するために使用されます。 Linux 上の特定の種類のマルチインスタンス タスク (MPI など) の場合、Batch コンピューティング ノードを含むサブネット 内の IP で SSH ポート 22 のトラフィックも許可する必要があります。 これは、サブネット レベルの NSG 規則に従ってブロックされる可能性があります (下記参照)。
  • 仮想ネットワークに向かう全ポートのアウトバウンド トラフィック。 これは、サブネット レベルの NSG 規則に従って修正される可能性があります (下記参照)。
  • インターネットに向かう全ポートのアウトバウンド トラフィック。 これは、サブネット レベルの NSG 規則に従って修正される可能性があります (下記参照)。

重要

Batch によって構成された NSG のインバウンドまたはアウトバウンド規則を変更したり追加したりする際は注意が必要です。 指定したサブネット内のコンピューティング ノードとの通信が NSG によって拒否された場合、Batch サービスによって、コンピューティング ノードの状態が 使用不可 に設定されます。 また、Batch によって作成されたリソースにはリソース ロックを適用しないでください。そうしないと、プールの削除など、ユーザーが開始した操作の結果として、リソースのクリーンアップが妨げられるからです。

ネットワーク セキュリティ グループ:サブネット レベルの規則の指定

Batch の計算ノードがデプロイされているサブネットに関連付けられている NSG がある場合、またはカスタム NSG 規則を適用して既定の適用を上書きする場合は、次のテーブルに示すように、少なくとも受信および送信のセキュリティ規則を持つ NSG を構成する必要があります。

ポート 3389 (Windows) またはポート 22 (Linux) のインバウンド トラフィックは、外部ソースからの計算ノードに対するリモート アクセスを許可する必要がある場合にのみ構成します。 特定の MPI ランタイムでマルチインスタンス タスクをサポートする必要がある場合は、Linux でポート 22 の規則を有効にすることが必要になる場合があります。 これらのポートでトラフィックを許可することは、プール計算ノードを使用できるようにするために厳密には必要ありません。

警告

Batch サービスの IP アドレスは、時間の経過と共に変化することがあります。 したがって、次の表に示す NSG 規則には、BatchNodeManagement サービス タグ (またはリージョン バリアント) を使用することを強くお勧めします。 特定の Batch サービス IP アドレスを使用して NSG 規則を設定しないでください。

[受信セキュリティ規則]

ソース IP アドレス 発信元サービス タグ ソース ポート 到着地 宛先ポート Protocol アクション
該当なし BatchNodeManagement サービス タグ (リージョン バリアントを使用している場合は、Batch アカウントと同じリージョン) * Any 29876 から 29877 TCP Allow
Linux マルチインスタンス タスクのためにコンピューティング ノードまたはコンピューティング ノード サブネット (あるいは両方) にリモート アクセスするためのユーザー ソース IP (必要な場合) 該当なし * Any 3389 (Windows)、22 (Linux) TCP Allow

アウトバウンド セキュリティ規則

source ソース ポート 到着地 宛先サービス タグ 宛先ポート Protocol アクション
Any * サービス タグ Storage (リージョン バリアントを使用している場合は、Batch アカウントと同じリージョン) 443 TCP Allow
Any * サービス タグ BatchNodeManagement (リージョン バリアントを使用している場合は、Batch アカウントと同じリージョン) 443 TCP Allow

BatchNodeManagement へのアウトバウンドは、ジョブ マネージャーのタスク用など、コンピューティング ノードから Batch サービスに接続するために必要です。

クラウド サービスの構成におけるプール

警告

Cloud Services 構成プールは非推奨とされます。 代わりに、仮想マシン構成プールを使用してください。

サポートされる VNET - クラシック VNET のみ

サブネット ID - Batch API を使用してサブネットを指定するときに、そのサブネットの "リソース識別子" を使用します。 サブネット識別子の形式は次のとおりです。

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.ClassicNetwork /virtualNetworks/{network}/subnets/{subnet}

アクセス許可 - Microsoft Azure Batch サービス プリンシパルに、指定された VNet に対する Classic Virtual Machine Contributor Azure ロールが付与されている必要があります。

ネットワーク セキュリティ グループ

サブネットでは、コンピューティング ノード上のタスクをスケジュールできるよう、Batch サービスからのインバウンド通信を許可する必要があります。また、Azure Storage などのリソースと通信するために、アウトバウンド通信を許可する必要があります。

NSG を指定する必要はありません。Batch IP アドレスからプールのノードへのみのインバウンド通信が Batch によって構成されるためです。 ただし、指定したサブネットに、NSG やファイアウォールが関連付けられている場合は、次の表に示すようにインバウンドとアウトバウンドのセキュリティ規則を構成します。 指定したサブネット内のコンピューティング ノードとの通信が NSG によって拒否された場合、Batch サービスによって、コンピューティング ノードの状態が 使用不可 に設定されます。

ポート 3389 (Windows) のインバウンド トラフィックは、プールのノードに対する RDP アクセスを許可する必要がある場合に構成します。 これは、プールのノードを使用可能な状態にするために必要ではありません。

[受信セキュリティ規則]

ソース IP アドレス ソース ポート 到着地 宛先ポート Protocol アクション
Any

実際上は "すべて許可" が必要ですが、Batch サービス以外の IP アドレスをすべてフィルターで除外する ACL 規則が、Batch サービスにより各ノードのレベルで適用されます。
* Any 10100、20100、30100 TCP Allow
コンピューティング ノードへの RDP アクセスを許可する場合 (省略可能) * Any 3389 TCP Allow

アウトバウンド セキュリティ規則

source ソース ポート 到着地 宛先ポート Protocol アクション
Any * Any 443 Any Allow

VNet で Batch プールを設定する方法の詳細については、仮想ネットワークでの仮想マシンのプールの作成に関するページを参照してください。

ヒント

ノードへのアクセスに使用されるパブリック IP アドレスが変更されないようにするには、ユーザーが制御するパブリック IP アドレスを指定してプールを作成することができます。

プールとコンピューティング ノードの有効期間

Azure Batch ソリューションを設計するときは、いつ、どのようにプールを作成するかと、それらのプール内のコンピューティング ノードをどのくらいの期間利用できるようにしておくかを指定する必要があります。

1 つの方法として、送信する各ジョブについてプールを作成し、対応するタスクが実行を終えた直後にそのプールを削除することができます。 必要なときにのみノードが割り当てられ、ノードがアイドル状態になるとすぐにシャットダウンされるので、使用効率はきわめて高くなります。 ジョブはノードが割り当てられるまで待機する必要がありますが、ノードが個別に割り当てられ、開始タスクが完了するとすぐに、タスクの実行がスケジュール設定されることに注意してください。 つまり、プール内のすべてのノードが使用可能になるまで Batch がタスクをノードに割り当てずに待機するようなことは "ありません"。 そのため、使用可能なすべてのノードで使用率が最大になります。

もう一方の極端な例としては、ジョブをすぐに開始することが最優先事項であるような場合、プールを事前に作成し、ジョブが送信される前にノードを使用可能にしておくという方法があります。 この場合はタスクをすぐに開始できますが、ノードはタスクが割り当てられるまでアイドル状態で待機する可能性があります。

変動の大きい継続的な負荷に対応するために、通常はこれらを組み合わせた方法が採用されます。 複数のジョブが送信されるプールを作成し、ジョブの負荷に応じてノードの数をスケールアップまたはスケールダウンすることができます。 この方法では、現在の負荷に応じて事後的に対応できます。また、負荷を予測できる場合は事前に対応することもできます。 詳細については、「自動スケーリング ポリシー」を参照してください。

自動プール

自動プールは、プールで実行されるジョブの前に作成されるのではなく、ジョブの送信時に Batch サービスによって作成されるプールです。 Batch サービスでは、指定した特性に従って、自動プールの有効期間が管理されます。 ほとんどの場合、これらのプールも、ジョブの完了後に自動的に削除されるように設定されます。

証明書によるセキュリティ

証明書を使用する必要があるのは、通常、Azure Storage アカウントのキーなど、タスクの機密情報を暗号化または復号化するときです。 このようなときは、ノードに証明書をインストールすることで対応できます。 暗号化された機密情報は、コマンド ライン パラメーターを通じてタスクに渡されるか、タスク リソースの 1 つに埋め込まれます。インストールされた証明書を使用して、機密情報を復号化できます。

証明書の追加操作 (Batch REST) または CertificateOperations.CreateCertificate メソッド (Batch .NET) を使用して、Batch アカウントに証明書を追加できます。 次に、新規または既存のプールに証明書を関連付けることができます。

証明書がプールに関連付けられると、Batch サービスは、プール内の各ノードに証明書をインストールします。 Batch サービスはノードの起動時、いずれかのタスク (開始タスクジョブ マネージャー タスクも含まれます) を起動する前に、適切な証明書をインストールします。

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

次のステップ