次の方法で共有

Azure Batch のベスト プラクティス

  • [アーティクル]

この記事では、Azure Batch サービスを効果的に使用するためのベスト プラクティスと役に立つヒントについて説明します。 これらのヒントは、パフォーマンスを向上させ、Batch ソリューションの設計上の落とし穴を回避するために役立ちます。

ヒント

Azure Batch のセキュリティのガイダンスについては、「Batch のセキュリティとコンプライアンスのベスト プラクティス」を参照してください。

プール

プールは、Batch サービスでジョブを実行するためのコンピューティング リソースです。 以下のセクションでは、Batch プールを使用するための推奨事項について説明します。

プールの構成と名前指定

  • プール割り当てモード: Batch アカウントの作成時に、Batch サービスまたはユーザー サブスクリプションの 2 つのプール割り当てモードのいずれかを選択できます。 ほとんどの場合、既定の Batch サービス モードを選択することになります。このモードでは、Batch で管理されているサブスクリプションにバックグラウンドでプールが割り当てられます。 もう一方のユーザー サブスクリプション モードでは、プールの作成時に Batch VM などのリソースがサブスクリプションに直接作成されます。 ユーザー サブスクリプション アカウントは主に、小規模であるが重要なシナリオのサブセットを有効にするために使用されます。 詳細については、「ユーザー サブスクリプション モードのための構成」を参照してください。

  • classic または simplified ノード通信モード: プールは、クラシックまたは簡略化の 2 つのノード通信モードのいずれかで構成することができます。 クラシックのノード通信モデルでは、Batch サービスによってコンピューティング ノードへの通信が開始され、コンピューティング ノードも Azure Storage との通信を必要とします。 簡略化されたノード通信モデルでは、コンピューティング ノードが Batch サービスとの通信を開始します。 必要な受信または送信接続のスコープが縮小され、ベースライン操作に Azure Storage の送信アクセスは必要ないため、簡略化されたノード通信モデルを使用することをお勧めします。 Batch サービスに対する将来の改善の中にも、簡略化されたノード通信モデルを必要とするものがあります。 クラシック ノード通信モデルは、2026 年 3 月 31 日に廃止される予定です。

  • ジョブとタスクの実行時間に関する考慮事項: ジョブが主に実行時間の短いタスクで構成されていて、かつ予想されるタスクの総数が少ないため、ジョブで予想される全体的な実行時間が長くない場合は、ジョブごとに新しいプールを割り当てることはしないでください。 ノードの割り当て時間により、ジョブの実行時間が減少します。

  • 複数の計算ノード: 個々のノードが常に使用可能な状態であるとは限りません。 まれなケースですが、ハードウェア障害、オペレーティング システムの更新、その他の多くの問題によって、個々のノードがオフラインになることがあります。 Batch ワークロードの進捗が確実で保証されている必要がある場合、複数のノードでプールを割り当てる必要があります。

  • サポート終了日 (EOL) が近いイメージ: Batch のサポート終了日 (EOL) が近いイメージは、使用しないようにすることを強くお勧めします。 このような日付は、ListSupportedImages API、PowerShell、または Azure CLI で確認することができます。 プールに関連する EOL 日のビューを定期的に更新し、EOL 日になる前にワークロードを移行することは、お客様の責任となります。 指定されたノード エージェントでカスタム イメージを使用している場合は、カスタム イメージが派生されている、または連携しているイメージについて、Batch のサポート終了日を追跡できていることを確認してください。 batchSupportEndOfLife の日付が指定されていないイメージは、そのような日付がバッチ サービスによってまだ決定されていないことを示します。 日付がないことは、それぞれのイメージが無期限にサポートされることを示すわけではありません。 EOL の日付は、将来いつでも追加または更新される可能性があります。

  • サポート終了日 (EOL) が近い VM SKU: VM イメージと同様に、VM SKU またはファミリーも Batch サポートのサポート終了 (EOL) に達する可能性があります。 このような日付は、ListSupportedVirtualMachineSkus API、PowerShell、または Azure CLI で確認することができます。 サポートされている適切な VM SKU を使用して新しいプールを作成し、EOL に達していない VM SKU にワークロードを移行する計画を立てます。 VM SKU に関連付けられている batchSupportEndOfLife 日付がない場合、その特定の VM SKU は無期限にサポートされることを示しています。 EOL の日付は、将来いつでも追加または更新される可能性があります。

  • 一意のリソース名: 多くの場合、Batch リソース (ジョブ、プールなど) は、時間の経過と共に作成されたり削除されたりします。 たとえば、月曜日にプールを作成し、火曜日に削除した後、木曜日にもう 1 つ同じプールを作成することがあります。 新しく作成した各リソースには、以前に使用したことのない一意の名前を付ける必要があります。 一意の名前を付けるには、GUID を使用するか (リソース名全体、またはその一部として)、リソースが作成された日付と時間をリソース名に埋め込みます。 Batch では DisplayName がサポートされています。これにより、実際のリソース ID が人間にとってわかりやすいものではない場合でも、より判読しやすい名前をリソースに付けることができます。 一意の名前を使用すると、ログとメトリックで何らかの処理を行った特定のリソースを簡単に識別できます。 また、リソースのサポート ケースを提出する必要がある場合にも、あいまいさが解消されます。

  • プールのメンテナンス中とエラー発生時の継続性: ジョブではプールを動的に使用することをお勧めします。 ジョブですべてのものに同じプールを使用する場合、プールで問題が発生した場合にジョブが実行されない可能性があります。 この原則は、時間の制約のあるワークロードでは特に重要です。 たとえば、各ジョブをスケジュールするときにプールを動的に選択または作成するか、異常なプールをバイパスできるようにプール名をオーバーライドする方法を用意しておきます。

  • プールのメンテナンス中とエラー発生時のビジネス継続性: 必要なサイズまでプールを拡大できない原因として、内部エラーや容量の制約など、多くのことが考えられます。 必要に応じて、別のプールで (場合によっては UpdateJob を使用して別の VM サイズで) ジョブを再ターゲットできることを確認します。 削除や変更が行われないことを前提にして静的プール ID に依存することは避けてください。

プールのセキュリティ

分離の境界

分離のために、シナリオでジョブまたはタスクを相互に分離する必要がある場合は、それらを異なるプールに配置することで行います。 プールは、Batch のセキュリティ分離の境界であり、既定では、2 つのプールは表示されないか、相互に通信できません。 Batch アカウントが動作する大規模な環境で分離が必要な場合を除き、セキュリティ分離の手段として個別の Batch アカウントを使わないでください。

Batch ノード エージェントの更新

計算ノードが 0 以外のプールの場合、Batch ノード エージェントは自動的にアップグレードされません。 Batch プールが Batch ノード エージェントに対する最新のセキュリティ修正プログラムと更新プログラムを確実に受け取るには、プールのサイズを計算ノードが 0 になるように変更するか、プールを作り直す必要があります。 Batch ノード エージェントのリリース ノートをときどき見て、Batch ノード エージェントの新しいバージョンに対する変更点を確認することをお勧めします。 リリースされた更新プログラムの有無を定期的に確認すると、エージェントの最新バージョンへのアップグレードを計画できます。

プールを再作成またはサイズ変更する前に、Batch プールまたは計算ノードで問題が発生している場合は、デバッグのためにノード エージェント ログをダウンロードする必要があります。 このプロセスについては、「ノード」セクションで詳しく説明します。

Note

Azure Batch のセキュリティに関する一般的なガイダンスについては、「Batch のセキュリティとコンプライアンスのベスト プラクティス」を参照してください。

オペレーティング システムの更新プログラム

Batch プール用に選択された VM イメージは、最新の発行元が提供するセキュリティ更新プログラムを使用して最新の状態にすることをお勧めします。 一部のイメージでは、起動時 (またはその直後) にパッケージの自動更新が実行される場合があります。これにより、パッケージ リポジトリの更新の取得 (例: apt update) や、StartTask などのアクション中のパッケージのインストールなど、特定のユーザー向けのアクションが妨げられる可能性があります。

Batch プールの OS の自動アップグレードを有効にすることをお勧めします。これにより、基になる Azure インフラストラクチャでプール全体の更新を調整できます。 このオプションは、タスクの実行で中断を起こさずに構成できます。 OS の自動アップグレードでは、Batch でサポートされているすべてのオペレーティング システムがサポートされるわけではありません。 詳細については、「Virtual Machine Scale Sets の OS の自動アップグレードのサポート マトリックス」を参照してください。 Windows オペレーティング システムの場合は、Batch プールで OS の自動アップグレードを使用するときにプロパティ virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates を有効にしていないことを確認してください。

Azure Batch では、サービスで使用できるイメージに最新のセキュリティ更新プログラムがあることを確認したり保証したりすることはありません。 イメージの更新プログラムは、Azure Batch ではなく、イメージの発行元の範囲にあります。 microsoft-azure-batch で公開されている特定のイメージの場合、これらのイメージがアップストリームの派生イメージで最新の状態に保たれる保証はありません。

プールの有効期間と課金

プールの有効期間は、割り当ての方法とプール構成に適用されるオプションによって異なります。 プールには、任意の有効期間と、さまざまな数の計算ノードをいつでも指定できます。 プール内の計算ノードを明示的、またはサービスによって提供される機能 (自動スケーリングまたは自動プール) を介して管理するのはユーザーの責任です。

  • プールの再作成: プールを毎日削除して再作成することは避けてください。 代わりに、新しいプールを作成し、その新規プールを参照するように既存のジョブを更新します。 すべてのタスクを新しいプールに移動したら、古いプールを削除します。

  • プールの効率と課金: Batch 自体に追加料金は発生しません。 ただし、計算、ストレージ、ネットワーク、Batch ワークロードに必要になる可能性があるその他のリソースなど、利用された Azure リソースに対して料金が発生します。 プール内のすべての計算ノードに対して、その状態に関係なく課金されます。 詳細については、「Azure Batch のコスト分析と予算」を参照してください。

  • エフェメラル OS ディスク: 仮想マシン構成プールでは、VM キャッシュまたは一時 SSD 上に OS ディスクを作成するエフェメラル OS ディスクを使用して、マネージド ディスクに関連した追加コストを回避できます。

プール割り当ての失敗

プール割り当ての失敗は、最初の割り当て中またはその後のサイズ変更中の任意の時点で発生する可能性があります。 これらの障害は、リージョン内の一時的な容量不足や、Batch が使用している他の Azure サービスの障害が原因で発生する可能性があります。 コア クォータは保証ではなく、制限です。

計画外のダウンタイム

Batch プールでは、Azure のダウンタイム イベントが発生する可能性があります。 問題が発生する可能性があることを理解し、再実行に対する回復性があるワークフローを開発する必要があります。 ノードで障害が発生した場合、Batch は自動的にそれらの計算ノードを回復しようとします。 この回復により、復元されたノードまたは別の使用可能なノードで実行中のタスクの再スケジュールがトリガーされる場合があります。 中断されたタスクの詳細については、再試行のための設計に関するセクションを参照してください。

カスタム イメージ プール

仮想マシンの構成を使用して Azure Batch プールを作成するときは、プールの各コンピューティング ノードにオペレーティング システムを提供する VM イメージを指定します。 サポートされている Azure Marketplace イメージを使ってプールを作成したり、Azure Compute Gallery のイメージを使ってカスタム イメージを作成したりできます。 マネージド イメージを使ってカスタム イメージ プールを作成することもできますが、可能であれば、Azure Compute Gallery を使ってカスタム イメージを作成することをお勧めします。 Azure Compute Gallery を使うと、プールを迅速にプロビジョニングしたり、VM の数を増やしたり、VM のプロビジョニング時に信頼性を向上させたりできます。

サード パーティのイメージ

プールは、Azure Marketplace に発行されたサード パーティのイメージを使用して作成できます。 ユーザー サブスクリプション モードの Batch アカウントを使用すると、特定のサード パーティのイメージでプールを作成する場合、"Marketplace での購入資格の確認のため、割り当てに失敗しました" というエラーが表示されることがあります。 このエラーを解決するには、イメージの発行者によって設定された条項に同意します。 これを行うには、Azure PowerShell または Azure CLI を使用します。

コンテナー プール

仮想ネットワークを使用して Batch プールを作成する場合、指定された仮想ネットワークと既定の Docker ブリッジの間で相互作用の副作用が発生することがあります。 既定では、Docker は 172.17.0.0/16 のサブネット指定を使用してネットワーク ブリッジを作成します。 Docker ネットワーク ブリッジと仮想ネットワークの間に競合する IP 範囲がないことを確認します。

Docker Hub では、イメージのプル数が制限されます。 ワークロードが Docker Hub ベースのイメージの公開されたレート制限を超えないようにします。 Azure Container Registry を直接使用するか、ACR でアーティファクト キャッシュを活用することをお勧めします。

Azure リージョンの依存関係

時間に制約のあるワークロードまたは運用ワークロードがある場合は、単一の Azure リージョンに依存しないようにします。 まれに、リージョン全体に影響する可能性がある問題が発生することがあります。 たとえば、特定の時刻に処理を開始する必要がある場合は、開始時刻の十分前に、プライマリ リージョンでプールをスケールアップすることを検討してください。 プールのスケーリングに失敗した場合は、バックアップ リージョン (複数可) のプールのスケールアップにフォールバックできます。

さまざまなリージョンの複数のアカウントにまたがるプールには、他のプールで問題が発生した場合に、簡単にアクセスできるバックアップが用意されています。 詳細については、「高可用性を実現するようにアプリケーションを設計する」を参照してください。

ジョブ

ジョブは、数百、数千、あるいは数百万ものタスクを含むように設計されたコンテナーです。 ジョブを作成するときは、次のガイドラインに従ってください。

ジョブを少なくし、タスクを多くする

1 つのジョブを使用して 1 つのタスクを実行するのは効率的ではありません。 たとえば、それぞれ 10 個のタスクを含む 100 個のジョブを作成するのではなく、1,000 個のタスクを含む 1 つのジョブを使用する方が効率的です。 それぞれが 1 つのタスクを含む 1,000 個のジョブを使用すると、最も非効率で、最も速度が遅く、最もコストがかかります。

数千個のアクティブなジョブを同時に必要とする Batch ソリューションは設計しないようにしてください。 タスクにはクォータがないため、できるだけ少ないジョブでできるだけ多くのタスクを実行すると、ジョブとジョブ スケジュールのクォータが効率的に使用されます。

ジョブの有効期間

Batch ジョブは、システムから削除されるまで無期限の有効期限を持っています。 ジョブの状態は、スケジューリングの際にさらに多くのタスクを受け入れることができるかどうかを示します。

明示的に終了されない限り、ジョブは自動的に完了状態に移行することはありません。 このアクションは、onAllTasksComplete プロパティまたは maxWallClockTime を使用して自動的にトリガーできます。

既定のアクティブ ジョブおよびジョブ スケジュールのクォータがあります。 完了状態のジョブおよびジョブ スケジュールは、このクォータにはカウントされません。

ジョブが完了した状態であっても、不要になった場合は削除してください。 完了したジョブはアクティブなジョブ クォータにはカウントされませんが、完了したジョブを定期的にクリーンアップすることは利点があります。 たとえば、ジョブの合計数が少ない場合は、(要求に適切なフィルターが適用されていたとしても) ジョブの一覧表示の効率が向上します。

タスク

タスクは、ジョブを構成する個々の作業単位です。 タスクはユーザーによって送信され、Batch によって計算ノードに対してスケジュールされます。 以下のセクションでは、問題を処理して効率的に実行するためのタスクの設計に関する推奨事項を示しています。

タスク データを保存する

計算ノードはその性質上、短い期間しか存在しません。 自動プールや自動スケーリングなどの Batch の機能を使用すると、ノードを簡単に消失することができます。 ノードが (サイズ変更やプールの削除により) プールを離れると、それらのノード上のすべてのファイルも削除されます。 この動作のため、タスクが完了する前に、それが実行されているノードから永続ストアに出力を移動する必要があります。 同様に、タスクが失敗した場合は、障害を診断するために必要なログを永続ストアに移動する必要があります。

Batch には、OutputFiles およびさまざまな共有ファイル システムを介してデータをアップロードするための Azure Storage サポートが統合されています。あるいは、タスクでのアップロードをユーザー自身で実行することもできます。

タスクの有効期間を管理する

不要になったタスクを削除するか、retentionTime タスク制約を設定します。 retentionTime が設定されている場合、retentionTime の有効期限が切れると、Batch はタスクによって使用されているディスク領域を自動的にクリーンアップします。

タスクを削除すると、次の 2 つのことが行われます。

  • ジョブにタスクのビルドアップがないことを確認します。 このアクションは、完了したタスクをフィルター処理する必要がある場合に、目的のタスクを見つけるのが困難になるのを回避するのに役立ちます。
  • ノード上の対応するタスク データがクリーンアップされます (retentionTime にまだ達していない場合)。 このアクションにより、ノードがタスク データでいっぱいにならず、ディスク領域が不足することがなくなります。

Note

Batch に送信したばかりのタスクの場合、DeleteTask API 呼び出しが有効になるまでに最大 10 分かかります。 それが有効になるまでは、他のタスクがスケジュールされない可能性があります。 これは、Batch Scheduler が、削除されたばかりのタスクを引き続きスケジュールしようとするためです。 1 つのタスクを送信後すぐに削除する場合は、代わりにそのタスクを終了します (タスク要求の終了はすぐに有効になるためです)。 それから、10 分後にそのタスクを削除します。

コレクション内で多数のタスクを送信する

タスクは、個別にまたはコレクションとして送信できます。 オーバーヘッドと送信時間を削減するためにタスクを一括送信する際に、一度に最大 100 個のタスクのコレクションとしてタスクを送信します。

ノードごとの最大タスク数を適切に設定する

Batch では、ノードでのタスクのオーバーサブスクライブ (ノードが持つコアの数よりも多くのタスクを実行) をサポートしています。 タスクをプール内のノードに対して適切なサイズにするのはユーザーの責任です。 たとえば、1 つのノードでそれぞれ 25% の CPU 使用量を消費する 8 個のタスクを (taskSlotsPerNode = 8 のプール内に) スケジュールしようとすると、ユーザー エクスペリエンスが低下する可能性があります。

再試行と再実行に対応して設計する

タスクは、Batch によって自動的に再試行できます。 再試行には、ユーザー制御と内部の 2 種類があります。 ユーザー制御の再試行は、タスクの maxTaskRetryCount で指定されます。 タスクで指定されたプログラムが 0 以外の終了コードで終了する場合、そのタスクは maxTaskRetryCount の値まで再試行されます。

まれなケースですが、計算ノードでの障害 (たとえば、内部状態を更新できない、タスクの実行中にノードで障害が発生したなど) によってタスクが内部的に再試行されることがあります。 タスクは、可能であれば、同じ計算ノード上で内部限度に達するまで再試行されます。その後、タスクの実行が中断されて、Batch で再スケジュール (別の計算ノード上の可能性があります) するためにタスクが延期されます。

タスクを専用ノードで実行する場合も、スポット ノードで実行する場合も、設計上の違いはありません。 タスクがスポット ノードでの実行中に割り込まれた場合も、専用ノードでの障害によって中断された場合も、障害に耐えるようにタスクを設計することで両方の状況が緩和されます。

持続的なタスクを構築する

タスクは、耐障害性があり、再試行に対応できるように設計する必要があります。 この原則は、長時間実行されるタスクにとって特に重要です。 タスクが複数回実行されている場合でも、タスクによって同じ単一の結果が生成されるようにします。 この結果を実現する 1 つの方法は、タスクを "ゴール シーク" に設定することです。もう 1 つの方法は、タスクがべき等 (タスクの実行回数に関係なく同じ結果になる) であることを確認することです。

一般的な例として、計算ノードにファイルをコピーするタスクが挙げられます。 単純な方法は、実行されるたびに、指定されたすべてのファイルをコピーするタスクを作成することですが、これは非効率的で、障害に耐えるように構築されていません。 代わりに、ファイルが計算ノードにあることを確認するタスク、つまり、既に存在するファイルを再度コピーしないタスクを作成します。 このようにして、タスクは中断された場合に、中断された場所から処理を再開します。

短い実行時間を避ける

実行時間が 1 秒から 2 秒間のみのタスクは理想的ではありません。 個々のタスクで大量の作業を行うようにします (10 秒以上、最大で数時間から数日)。 各タスクが1分間 (またはそれ以上) 実行されている場合、全体的な計算時間の割合としてのスケジュールのオーバーヘッドはわずかです。

Windows ノードでの短いタスクにプール スコープを使用する

Batch ノードでタスクをスケジュールするとき、それをタスク スコープで実行するか、またはプール スコープで実行するかを選択できます。 タスクの実行時間が短い場合、そのタスクの自動ユーザー アカウントの作成にリソースが必要なため、タスク スコープでは効率が悪い場合があります。 効率を高めるには、これらのタスクをプール スコープに設定することを検討してください。 詳細については、プール スコープを使用したタスクの自動ユーザーとしての実行に関するページを参照してください。

Nodes

コンピューティング ノードは、アプリケーションの一部のワークロードの処理に特化した Azure 仮想マシン (VM) またはクラウド サービス VM です。 ノードを操作するときは、次のガイドラインに従ってください。

開始タスク: 有効期間とべき等性

他のタスクと同様に、タスクの開始というノードはべき等である必要があります。 開始タスクは、コンピューティング ノードの再起動時または Batch エージェントの再起動時に再実行されます。 べき等タスクとは、複数回実行したときに一貫した結果が得られる単純なタスクのことです。

開始タスクは、実行時間を長くしたり、コンピューティング ノードの有効期間に結合したりしないでください。 サービスであるか、サービスに似た性質のプログラムを開始する必要がある場合は、Linux または Windows サービス上の systemd などのオペレーティング システムの機能によってこれらのプログラムを開始および管理できるようにする開始タスクを作成します。 これらのプログラムが以前にサービスとしてインストールされている場合、後続の実行が適切に処理されるように、開始タスクをべき等として構築する必要があります。

ヒント

Batch が開始タスクを再実行すると、開始タスク ディレクトリを削除して、再度作成しようとします。 Batch が開始タスク ディレクトリの再作成に失敗した場合、コンピューティング ノードは開始タスクの起動に失敗します。

これらのサービスは、ノード上の Batch 管理ディレクトリ内のどのファイルに対してもファイル ロックを取得しないようにする必要があります。取得すると、ファイル ロックが原因でそれらのディレクトリを Batch が削除できなくなるためです。 たとえば、開始タスクの作業ディレクトリから直接サービスの起動を構成する代わりに、べき等の方法で他の場所にファイルをコピーします。 次に、オペレーティング システムの機能を使用して、その場所からサービスをインストールします。

分離ノード

コンプライアンスまたは規制要件があるワークロードには、分離された VM サイズの使用を検討してください。 仮想マシン構成モードでサポートされている分離サイズには、Standard_E80ids_v4、Standard_M128ms、Standard_F72s_v2、Standard_G5、Standard_GS5、Standard_E64i_v3 があります。 分離された VM サイズの詳細については、「Azure における仮想マシンの分離性」をご覧ください。

Windows ではディレクトリ ジャンクションの作成は避ける

ディレクトリ ジャンクション (ディレクトリのハードリンクと呼ばれることもあります) は、タスクおよびジョブのクリーンアップ時の処理が困難です。 ハードリンクではなく、シンボリックリンク (ソフトリンク) を使用します。

一時ディスクと AZ_BATCH_NODE_ROOT_DIR

Batch は Batch 互換 VM サイズとして VM 一時ディスクに依存し、タスク実行に関連するメタデータと、各タスク実行の成果物がこの一時ディスク上に格納されます。 これらの一時ディスク マウント ポイントまたはディレクトリの例は、/mnt/batch、/mnt/resource/batch、D:\batch\tasks です。 これらのマウント ポイントとディレクトリまたは親ディレクトリの置換、再マウント、ジャンクション、シンボリック リンク、またはリダイレクトはサポートされておらず、不安定性につながることがあります。 より多くのディスク領域が必要な場合は、要件を満たす一時的なディスク領域を持つ VM サイズまたはファミリを使用するか、データ ディスクを接続することを検討してください。 詳細については、コンピューティング ノードのデータ ディスクの接続と準備に関する次のセクションを参照してください。

データ ディスクの接続と準備

Batch プール インスタンスの一部として指定した場合、個々のコンピューティング ノードに、まったく同じデータ ディスク仕様が接続されます。 Batch プールに接続できるのは、新しいデータ ディスクのみです。 コンピューティング ノードに接続されているこれらのデータ ディスクは、自動的にパーティション分割、フォーマット、またはマウントされることはありません。 これらの操作は、開始タスクの一部としてユーザーが実行する必要があります。 これらの開始タスクはべき等になるように作成する必要があります。 コンピューティング ノードで開始タスクを再実行できます。 開始タスクがべき等でない場合は、データ ディスクでデータ損失が発生する可能性があります。

ヒント

Linux でデータ ディスクをマウントするときに、/mnt や /mnt/resource などの Azure 一時マウント ポイントの下にディスク マウント ポイントを入れ子にする場合は、依存関係の競合が発生しないよう注意する必要があります。 たとえば、これらのマウントが OS によって自動的に実行される場合、マウントされている一時ディスクと、親の下にマウントされているデータ ディスクの間で競合が発生する可能性があります。 systemd など、使用可能な機能によって適切な依存関係が確実に適用されるようにするか、べき等なデータ ディスク準備スクリプトの一部として、データ ディスクのマウントを開始タスクに延期するなどの手順を実行する必要があります。

Linux Batch プールでのデータ ディスクの準備

Linux の Azure データ ディスクはブロック デバイスとして表示され、一般的な sd[X] 識別子が割り当てられます。 これらのラベルは起動時に動的に割り当てられ、初回と後続のブートの間で一貫性が保証されないため、静的な sd[X] 割り当てには依存しないでください。 接続されたディスクは、/dev/disk/azure/scsi1/ で示されるマッピングを使用して識別する必要があります。 たとえば、AddPool API でデータ ディスクに LUN 0 を指定した場合、このディスクは /dev/disk/azure/scsi1/lun0 として表示されます。 たとえば、このディレクトリを一覧表示すると、次の情報が表示される可能性があります。

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

準備スクリプトで参照を sd[X] マッピングに戻す必要はなく、代わりにデバイスを直接参照します。 この例では、このデバイスは /dev/disk/azure/scsi1/lun0 になります。 この ID は、fdisk および mkfs と、ワークフローに必要なその他のツールに直接指定できます。 または、blkid で lsblk を使用して、ディスクの UUID をマップすることもできます。

Linux の Azure データ ディスクの詳細、たとえば、別の方法でデータ ディスクを見つける方法や /etc/fstab オプションについては、こちらの記事を参照してください。 ご自身の方法を運用環境で使用する前に、ヒントで説明されているように、依存関係や競合がないことを確認してください。

Windows Batch プールでのデータ ディスクの準備

Batch の Windows コンピューティング ノードに接続された Azure データ ディスクは、パーティション分割もフォーマットもされていない状態で表示されます。 開始タスクの一部としてアクションを実行するために、RAW パーティションを含むディスクを列挙する必要があります。 この情報は、PowerShell コマンドレット Get-Disk を使用して取得できます。 たとえば、次のように表示される可能性があります。

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

ここで、ディスク番号 2 は、このコンピューティング ノードに接続されている初期化されていないデータ ディスクです。 これらのディスクは、ワークフローの必要に応じて初期化、パーティション分割、フォーマットできます。

Windows の Azure データ ディスクの詳細、たとえば PowerShell スクリプトのサンプルについては、こちらの記事を参照してください。 サンプル スクリプトを運用環境で使用する前に、そのべき等性が検証されていることを確認してください。

Batch エージェント ログを収集する

ノードまたはノードで実行されているタスクの動作に関連する問題が発生した場合は、該当するノードの割り当てを解除する前に、Batch エージェント ログを収集します。 Batch エージェント ログは、Batch サービス ログのアップロード API を使用して収集できます。 これらのログは、サポート チケットの一部として Microsoft に提供することができ、問題のトラブルシューティングと解決に役立ちます。

Batch API

タイムアウト エラー

タイムアウトエラーは、サービスが要求の処理に失敗したことを必ずしも示すわけではありません。 タイムアウト エラーが発生したときは、操作を再試行するか、状況に応じてリソースの状態を取得して、操作が成功したか失敗したかの状態を確認する必要があります。

接続

Batch ソリューションの接続に関する次のガイダンスを確認してください。

ネットワーク セキュリティ グループ (NSG) とユーザー定義ルート (UDR)

仮想ネットワークに Batch プールをプロビジョニングするときは、必ず BatchNodeManagement.region サービス タグ、ポート、プロトコル、ルールの方向の使用に関するガイドラインを厳守してください。 サービス タグを使うことを強くお勧めします。基になる Batch サービスの IP アドレスは時間の経過と共に変更される可能性があるため、その使用はお勧めしません。 Batch サービスの IP アドレスを直接使用すると、Batch プールの不安定性、中断、または障害が発生する可能性があります。

Batch サービスの IP アドレスは時間が経つと変わる可能性があるため、ユーザー定義ルート (UDR) の場合は、代わりに BatchNodeManagement.region サービス タグを使うことをお勧めします。

DNS を優先する

お使いのシステムで Batch アカウント サービス URL に対して DNS の Time-to-Live (TTL) が優先されていることを確認します。 また、Batch サービス クライアントと Batch サービスへのその他の接続メカニズムが IP アドレスに依存していないことを確認します。

HTTP 要求に 5xx レベルの状態コードと応答の "Connection: close" ヘッダーが含まれている場合は、Batch サービス クライアントの動作を調整する必要があります。 Batch サービス クライアントの推奨事項に従う必要があります。これを行うには、既存の接続を閉じ、Batch アカウント サービス URL の DNS を再度解決し、新しい接続で次の要求を再試行します。

要求の自動的な再試行

要求を自動的に再試行する適切な再試行ポリシーが Batch サービス クライアントに設定されていることを確認します。この再試行は、サービス メンテナンス期間中だけでなく、通常の操作時にも実行されます。 これらの再試行ポリシーの間隔は、5 分以上にする必要があります。 自動再試行機能は、.NET RetryPolicyProvider クラスなどのさまざまな Batch SDK で提供されています。

静的パブリック IP アドレス

通常、Batch プール内の仮想マシンには、パブリック IP アドレスを使用してアクセスしますが、これはプールの有効期間中に変更される可能性があります。 この動的な性質により、特定の IP アドレスへのアクセスが制限されるデータベースやその他の外部サービスと対話ができなくなる場合があります。 この懸念に対処するには、ご自身が制御する静的パブリック IP アドレスのセットを使用してプールを作成してください。 詳細については、「特定のパブリック IP アドレスの Azure Batch プールを作成する」を参照してください。

Batch ノードの基になる依存関係

Batch ソリューションを設計するときは、次の依存関係と制限事項を考慮してください。

システムで作成されたリソース

Azure Batch では、VM 上にユーザーとグループのセットが作成されて管理されますが、それを変更しないでください。

Windows の場合:

  • PoolNonAdmin という名前のユーザー
  • WATaskCommon という名前のユーザー グループ

Linux:

  • _azbatch という名前のユーザー

ヒント

これらのユーザーまたはグループの名前付けは実装成果物であり、いつでも変更される可能性があります。

ファイルのクリーンアップ

Batch では、タスクが実行されている作業ディレクトリのクリーンアップが、保有期間の終了後にアクティブに試行されます。 このディレクトリの外部に書き込まれたファイルは、ディスク領域の不足を防ぐため、ユーザーがクリーンアップする必要があります。

startTask 作業ディレクトリから Windows でサービスを実行すると、そのフォルダーがまだ使用されているため、作業ディレクトリの自動クリーンアップはブロックされます。 このアクションにより、パフォーマンスが低下します。 この問題を解決するには、そのサービス用のディレクトリを、Batch によって管理されていない別のディレクトリに変更します。

次のステップ