タスクを実行してアプリケーション パッケージを追加する
Batch REST API を使用してタスクを同時に実行する
Azure Batch では、並列タスクを使用して、コンピューティング ノード間でジョブを分割します。 Azure Batch は、大規模な並列でハイパフォーマンスのコンピューティング バッチ ジョブの実行に特に適しています。 Batch サービスによってすべてのものが自動的に処理されます。これには、シナリオの実行に必要なすべてのノードとアプリケーションの管理とスケジュール設定が含まれます。
プール内のノードの数を少なくし、複数のタスクを同時に実行することにより、リソースの使用率を最大化できます。 複数のタスクで計算ノードを共有すると、特定のワークロードでジョブの時間が短縮され、コストが削減される可能性があります。
シナリオによっては、データを共有できるタスクのデータ転送を最小限に抑えることが必要になる場合があります。 共有データを少数のノードにコピーし、各ノードでタスクを並列実行することにより、データ転送の費用を大幅に削減できます。 この方法により、多数のノードでデータを共有するより、すべてのノードにデータを転送するためにかかる時間が短縮されます。
並列タスク実行を有効にする
並列タスクの実行においては、1 つのノードが 1 つのプールで同時に処理できるタスクの数を制御します。
Batch では、スロットによって並列タスクの実行を制御します。 タスクの RequiredSlots というプロパティで、タスクがどの程度リソース集中的かが示されています。 リソース消費の多いタスクには、リソース消費の少ないタスクより多くのスロットが必要です。
プールを作成するときに、taskSlotsPerNode プロパティを設定することによって、ノードごとに使用できるタスク スロットの数を指定します。 ノード上で同時実行できるタスクのリソース消費量がこのプロパティで制御されます。
たとえば、プールの taskSlotsPerNode プロパティが 16 に設定されている場合、ノードで同時に実行されるタスクに、16 個より多くのスロットは必要ありません。 この設定により、たとえば次のようなことが示されます。
- 8 個のスロットを必要とする 2 個のタスクは、スロットの数が 16 と等しいため (2 * 8 = 16)、同時に実行できます
- 5 個のスロットを必要とする 3 個のタスクは、スロットの数が 16 より少ないため (3 * 5 = 15)、同時に実行できます
- 4 個のスロットを必要とする 5 個のタスクは、スロットの数が 16 より多いため (5 * 4 = 20)、同時に実行できません
taskSlotsPerNode プロパティに設定できる最大値は、ノードが備える vCPU の数の 4 倍までです。 ノードで使用できる vCPU の数については、「Azure の仮想マシンのサイズ」を参照してください。
Note
taskSlotsPerNode プロパティは、設定後、変更することはできません。 変更するには、新しいプールを作成する必要があります。
タスクに必要と予想される CPU またはメモリの量、または予想されるタスクの I/O 集中度に基づいて、RequiredSlots プロパティを設定します。 または、タスクの実行時間に悪影響を与えずに同時に実行できるタスクの数に基づいて、taskSlotsPerNode プロパティを設定します。
アプリケーション パッケージを追加し、Azure Batch でコンテナー アプリケーションを実行する
アプリケーション パッケージ
Azure Batch では、" アプリケーション " という用語は、プール内のコンピューティング ノードに自動でダウンロード可能なバージョン付きバイナリのセットを指します。 アプリケーションには、アプリケーションのさまざまなバージョンを表すアプリケーション パッケージが 1 つ以上含まれています。
アプリケーション パッケージはプールまたはタスク レベルで指定できます。 プールのアプリケーション パッケージは、プール内のすべてのノードでジョブのタスクが実行される場合に適しています。
プールを作成するときに、複数のアプリケーション パッケージを指定できます。 アプリケーションは、ノードがプールに参加するときと、ノードが再起動または再イメージ化されるときにデプロイされます。 既存のプールに新しいパッケージをインストールするには、そのノードを再起動する必要があります。
タスク レベルでアプリケーション パッケージをデプロイすることを選択した場合は、共有プール環境で役立ちます。 そのような環境では、異なるジョブが 1 つのプールで実行され、ジョブが完了してもプールは削除されません。 ジョブ内のタスクがプール内のノードよりも少ない場合は、タスクのアプリケーション パッケージによりデータ転送を最小限に抑えることができます。アプリケーションはタスクが実行されるノードにのみデプロイされるためです。
Azure portal または Batch Management API を使用して、Batch アカウントのアプリケーション パッケージを管理できます。 アプリケーション パッケージを使用するには、Batch アカウントに Azure ストレージ アカウントをリンクする必要があります。 Batch サービスでは、関連付けられたストレージ アカウントを使って、アプリケーション パッケージが格納されます。 Batch アカウント専用のストレージ アカウントを作成することをお勧めします。
コンテナー アプリケーション
コンテナーは、クラウド アプリケーションのパッケージ化、デプロイ、管理を行う優れた方法としてしだいに普及しつつあります。 Azure Container Instances は、単純なアプリケーション、タスク自動化、ジョブ作成など、分離されたコンテナーで操作できるあらゆるシナリオ向けの、優れたソリューションです。
コンテナーを使用すると、Batch タスクを簡単に実行できます。アプリケーションを実行する目的で環境や依存関係を管理する必要はありません。 コンテナーにより、アプリケーションが、複数の異なる環境で実行できる、軽量で移植可能かつ自律的なユニットとしてデプロイされます。 Batch のコンテナー ベース タスクでは、アプリケーション パッケージ、リソース ファイルの管理、出力ファイルの管理など、コンテナー タスク以外の機能も活用されます。
プリフェッチされたコンテナー イメージを使用しても使用しなくても、コンテナー対応のプールを作成できます。 プリフェッチ プロセスを使用すると、Docker Hub から、またはインターネット上の別のコンテナー レジストリ (Azure Container Registry など) から、コンテナー イメージを事前に読み込むことができます。
コンテナー イメージをプリフェッチするメリットは、初めてタスクを実行するとき、コンテナー イメージがダウンロードされるのを、そのタスクが待たなくてもよい点です。 プールの作成時に、コンテナー構成によって、コンテナー イメージが仮想マシンにプルされます。 これにより、プール上で実行されるタスクが、コンテナー イメージとコンテナー実行オプションの一覧を参照できます。