Azure Batch での信頼性

Azure Batchは、Azureで大規模な並列コンピューティングおよびハイ パフォーマンス コンピューティング (HPC) バッチ ジョブを実行します。 Batch は、コンピューティング ノードのプールを作成および管理し、実行するアプリケーションをインストールし、ノードで実行するジョブをスケジュールします。

Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

この記事では、一時的な障害、コンピューティング ノードの障害、可用性ゾーンの障害、リージョン全体の障害、およびサービス メンテナンスに対するAzure Batch回復性を確保する方法について説明します。 また、運用環境のデプロイに関する推奨事項、Batch 信頼性アーキテクチャ、バックアップと復元、Azure Batch サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。

運用環境のデプロイに関する推奨事項

運用ワークロードの場合は、次の信頼性に関する推奨事項を含め、Azure Batchのベスト プラクティスに従ってください。

信頼性アーキテクチャの概要

このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。

論理アーキテクチャ

Azure Batchでは、複数のリソースの種類を使用してバッチ ワークロードを実行します。 これらのリソースの構成によって、障害に対するワークロードの応答方法が決まります。

すべてのバッチ処理とリソースは、Batch アカウントに関連付けられます。 Batch ソリューションでは、次の論理コンポーネントが使用されます。

• Batch アカウント: プール、ジョブ、タスク、およびその他の Batch リソースが関連付けられているリージョン リソース。 アカウントを作成し、そのリージョン、プールの割り当てモード、および認証設定を選択します。

• プール: タスクが実行されるコンピューティング ノードのコレクション。 プールの構成では、その VM イメージとサイズ、ターゲット ノード数、スケーリング動作、ネットワーク、ゾーン配置が定義されます。 ワークロードに必要な容量、配置、および運用環境を提供するように各プールを構成します。 ターゲット ノード数は要求されたノード数ですが、クォータの制限、容量の制約、または割り当ての失敗により、割り当てられたノード数が少なくなる可能性があります。

• ジョブとタスク:ジョブは、タスクのコレクションを管理し、プールに関連付けられます。 タスクは、コンピューティング ノードでアプリケーションまたはスクリプトを実行します。 ジョブ、タスク、制約、依存関係、再試行動作、および各ジョブを実行するプールを定義します。

• 関連付けられているストレージ アカウント:必要に応じて Batch アカウントにリンクするAzure Storage アカウント。 ほとんどの Batch ソリューションでは、アプリケーション ファイル、タスク リソース ファイル、入力データ、出力データに関連付けられているストレージ アカウントが使用されます。

  ストレージ アカウントを Batch アカウントにリンクすると、Batch はそれを 自動ストレージ アカウントと見なします。 アプリケーション パッケージには autostorage アカウントが必要であり、タスク リソース ファイルを格納することもできます。

  Batch ソリューションの信頼性は、そのストレージ リソースに依存します。 ストレージ アカウントを作成するときに、復旧要件を満たすストレージ冗長構成を選択する必要があります。 タスク出力やその他の永続的なデータをコンピューティング ノードからストレージに移動します。 Azure Storage信頼性オプションの詳細については、「Azure Blob Storageの信頼性」を参照してください。

詳細については、「Batch サービス ワークフローとリソース」および「Batch アカウントと Azure Storage アカウント」を参照してください。

物理アーキテクチャ

Azure Batchには、Batch アカウントとその他の Batch リソース (プール、ジョブ、タスクなど) に対する管理操作を処理するリージョンコントロール プレーンがあります。 これは、タスクを実行するコンピューティング ノードとは別です。

Azure Batch プールは Azure 仮想マシン と Virtual Machine Scale Sets を使用します。 コンピューティング ノードは、Batch ワークロードの一部を処理する VM です。 各ノードはプールに属し、Batch サービスによって割り当てられるタスクを実行します。 Batch ノード エージェントは、各ノードで実行され、ノードと Batch サービスの間のコマンドおよび制御インターフェイスを提供します。 コンピューティング ノードとそのローカル ストレージは一時的です。 ノードがプールから離れると、そのオペレーティング システムとファイルへの変更は失われます。

Batch アカウントのプール割り当てモードによって、Batch によってコンピューティングと VM 関連のリソースが作成される場所が決まります。

• Batch サービス プールの割り当てモード:Batch は、Batch サービスによって管理されるAzure サブスクリプションにリソースを割り当てます。
• ユーザー サブスクリプション プールの割り当てモード: Batch は、Batch アカウントを含むサブスクリプションに直接リソースを作成します。

物理アーキテクチャの責任は次のように分けられます。

• Microsoft: Microsoftは、リージョンの Batch コントロール プレーンとサービス インフラストラクチャを運用します。 Batch は、プールの構成と使用可能な容量に従ってコンピューティング ノードをプロビジョニングし、タスクをスケジュールし、ノードの正常性を監視し、インフラストラクチャの障害後にノードの復旧を試みます。 Batch は、中断されたタスクを、別の使用可能なノードで実行するために再キューに入れることができます。

• あなた: VM イメージとサイズ、ノードの種類、ターゲット ノード数、スケーリング構成、ネットワーク、可用性ゾーンの配置を選択します。

  また、ノードの障害を許容するための十分な容量の維持、ノードとタスクの状態の監視、ゲスト オペレーティング システムとノード エージェントの最新の状態の維持、再実行を許容するタスクの設計、コンピューティング ノードからの永続的なデータの移動も担当します。

バッチ ノードの復旧では、ワークロードが中断することなく継続することは保証されません。 詳細については、「 コンピューティング ノードの障害に対する回復性」を参照してください。

一時的な障害に対する回復性

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。

Batch ソリューション内では、一時的な障害は、タスクとして実行されるアプリケーションとスクリプト、および Batch リソースを管理するために Batch API を呼び出すアプリケーションの両方に影響を与える可能性があります。 Batch では、タスク レベルで再試行メカニズムが提供されます。 タスクの制約を構成し、タスクを べき等 にする (複数回実行しても安全)、Batch サービスやその他の依存関係の呼び出しの再試行動作を構成する必要があります。

タスクの再試行と時間制限

maxTaskRetryCount を構成して、0 以外の終了コードでプロセスが終了した後に Batch がタスクを再試行する回数を制御します。

• 既定値 0は、Batch が 0 以外の終了コードの後にタスクを再試行しないことを意味します。
• 正の整数は、最初の試行後の再試行の最大数を設定します。
• -1の値を指定すると、無制限の再試行が可能になります。 永続的なエラーによってタスクが無期限に実行される可能性があるため、この値は推奨されません。

再試行によってデータの破損や出力の重複が発生しないように、すべてのタスクを冪等になるように設計します。 実行時間の長いタスクの場合は、チェックポイント処理を使用して、保存された進行状況から再試行を続行できるようにします。 詳細については、「 再試行と再実行の設計」を参照してください。

タスクまたはジョブに maxWallClockTime 制約を設定して、許容される期間内に進行しない作業を終了します。 また、時間制限によって、繰り返し発生する障害の影響も制限されます。 ワークロードの復旧目標に合わせて再試行回数と時間制限を選択します。

タスクの依存関係の一時的な障害

Batch タスクとして実行されるアプリケーションとスクリプトは、多くの場合、Azure Storage、データベース、API などの他のコンポーネントを呼び出します。 Batch では、タスク コードがこれらの依存関係に送信する個々の要求は管理されません。 タスク コードに一時的な障害処理を実装するか、依存関係の SDK によって提供される再試行機能を使用する。 各依存関係のガイダンスに従って、再試行可能なエラーを特定し、適切なバックオフとタイムアウトの設定を選択し、Retry-After ヘッダーなどの再試行指示に従います。 繰り返しても安全な操作のみを再試行してください。

依存関係の障害が原因でタスク プロセスが 0 以外の終了コードで終了した場合、Batch は maxTaskRetryCount に従ってタスク全体を再試行できます。 ただし、Batch は実行中のタスク内で個々の依存関係要求を再試行しません。

Batch API リクエストの再試行

サービスの外部で実行されているアプリケーションは、Batch API を呼び出して、プール、ジョブ、タスク、コンピューティング ノード、およびその他の Batch リソースを作成および管理できます。 一時的な Batch サービスまたはネットワーク障害を処理するために、これらのクライアントを 少なくとも 5 分間にわたる再試行ポリシー で構成します。

使用可能な場合は、組み込みの SDK 再試行サポートを使用します。 たとえば、Azure.Compute.Batch client library for .NETでは、Azure.Core再試行オプションを通じて再試行動作を提供します。

コードから Batch サービスの API と直接やり取りする場合は、再試行する前に数秒待ってから、ランダム化 (ジッター) による指数バックオフを使用して、同期された再試行要求を回避し、429 Too Many Requests や 503 Service Unavailable などのスロットリング応答で返される Retry-After ヘッダーを優先します。

要求タイムアウトは、Batch が要求の処理に失敗したことを意味するとは限りません。 タイムアウト後は、安全に実行できる場合は操作を再試行するか、リソースの状態を取得して元の操作が成功したかどうかを判断します。 詳細については、「Azure Batchでのエラー処理と検出」を参照してください。

コンピューティング ノードの障害に対する回復性

コンピューティング ノードは、インフラストラクチャの障害、オペレーティング システムの問題、または構成の問題のために使用できなくなる可能性があります。 Batch はインフラストラクチャの障害の影響を受けるノードの復旧を試みますが、構成に関連するすべての障害から自動的に復旧できるわけではありません。 たとえば、アプリケーション パッケージまたはコンテナーのインストールに失敗した場合は、基になる問題を修正する必要があり、影響を受けるノードを削除して置き換える必要があります。

ノード障害によってタスクが中断された場合、Batch は、可能であれば、内部制限まで同じノードでタスクを再試行できます。 タスクがそのノードで続行できない場合、Batch は別の使用可能なノードで実行するためにタスクを再キューできます。 これらの サービス駆動型の復旧再試行 は、maxTaskRetryCount とは無関係であり、その値が 0 である場合でも発生する可能性があります。

Microsoftマネージド ノードの復旧プロセス

Microsoftは、サービス駆動型ノードの復旧とタスクの再キューを管理します。 Batch サービスが復旧をトリガーするのに十分長い間ノードからのハートビートを受信しなかった場合、Batch は次のアクションを実行できます。

1. ノードを分離: Batch はノードを異常として扱い、その状態を unusableに設定し、そのノードに対する新しいタスクのスケジュールを停止します。
2. 影響を受けるタスクを特定します。 Batch は、ノードで実行されていたタスクを再スケジュールの候補として識別します。
3. 対象となるタスクを再キューする: 影響を受けるタスクが引き続き running 状態で保持されている場合、Batch はタスクを active にリセットして、スケジューラが別のノードに割り当てることができるようにすることができます。 Batch は、既に completed 状態で保持されているタスクをリセットまたは再実行しません。
4. ノードを復旧します。 Batch は、ノードを正常な状態に復元するか、基になる VM を置き換えようとします。

復旧は瞬時には行われません。 Batch がノードの障害を検出し、タスクのスケジュール変更を試みる間、タスクは running 状態のままになります。 他のコンピューティング ノードが使用できない場合、Batch がそのタスクを再スケジュールできるまで、タスクはその状態を維持できます。 詳細については、「Batch タスクの既知の制限事項」を参照してください。

置換が開始される前に元のノードが正常なハートビートを再開した場合、Batch はそれを安定した状態に戻すことができます。 置換が既に開始されている場合、Batch は代わりに元の VM を削除し、置換用 VM をプロビジョニングできます。

お客様の責任

サービス駆動型の復旧では、中断のないタスク実行や十分な残りの容量は保証されません。 ユーザーは、次の操作について責任を負います。

• 十分な容量を維持する: ノードが使用できないときにワークロードを続行する必要がある場合は、残りのノードで再スケジュールされたタスクを実行できるよう、十分な数のノードをプロビジョニングします。 別の使用可能なノードがない場合、中断されたタスクは待機する必要があります。

• 使用可能なキャパシティを監視する: プールにワークロードに十分な使用可能なノードがなくなったことを検出できるように、集計ノード数と状態を追跡します。 unusable、startTaskFailed、unknown、preemptedなどの状態は、容量の低下を示します。 詳細については、「タスクとノードを状態別にカウントして、Batch ソリューションを監視する」を参照してください。

• 問題のあるノードを調査する: タスクが繰り返し失敗したり、再キューに入ったり、割り当てられたノードが使用できなくなったり、プールから削除されたりした後に running 状態のままになった場合は、タスク メタデータを使用して、問題が特定のノードに関連付けられているかどうかを判断します。

  問題のあるノードを削除する前に、その Batch ノード エージェント ログをアップロードし、関連するタスク ログを保持してください。ノードを削除するとローカル ファイルが削除されるためです。 ノード エージェント ログは、Batch サービスまたはノードの問題を Microsoft サポート が診断するのに役立ちますが、stdout や stderr などのタスク ログは、アプリケーションと構成の問題を特定するのに役立ちます。 詳しくは、 ノード・エージェント・ログ・ファイルを参照してください。

• タスクの進行状況とデータを保護する: 中断と再実行を許容するタスクを設計します。 チェックポイント、出力、およびその他の永続的なデータは、ローカル ストレージが一時的であるため、コンピューティング ノードから移動してください。

詳細については、「Azure Batch プールとノードのエラー」および「Azure Batch でのエラー処理と検出」を参照してください。

可用性ゾーンの障害に対する回復性

可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Batch は、主に次の 2 つの方法で可用性ゾーンをサポートします。

• コントロール プレーン: Batch コントロール プレーンは、多くのリージョンでゾーン回復性があります。 これらのリージョンでは、Batch アカウントやその他の Batch リソースに対する管理操作は、ゾーン障害時にも継続できます。 Microsoft では、このコントロール プレーンの回復性を提供するのがどのリージョンかは公開していません。

• プール:可用性ゾーンの配置を使用するように Batch プールを構成できます。 ゾーンが使用できなくなった場合、正常なゾーン内のコンピューティング ノードは、タスクのスケジュール設定に引き続き使用できます。

  コンピューティング ノード配置の場合、このサポート モデルは、1 つのプールに複数の可用性ゾーンにコンピューティング ノードを含めることができるため、他のAzure サービスのゾーン冗長性に似ています。 ただし、Batch では、ベスト エフォートベースでノードがゾーン間に分散されます。 リージョン内のすべてのゾーンを使用しようとしますが、各ゾーンへの配置、または均等な分散は保証されません。 特定のゾーンを選択したり、各ゾーンに配置されるノードの数を制御したりすることはできません。

次の図は、Batch アカウントの例を示しています。 アカウントには 1 つのプールがあり、そのノードは 3 つの可用性ゾーンに分散されています。

ストレージ アカウントなど、他の依存リソースをゾーン冗長にする責任があります。 各サービスの信頼性ガイドを確認してください。 詳細については、Azure サービスの信頼性ガイドを参照してください。

Requirements

• リージョンのサポート:可用性ゾーンをサポートするAzure リージョンにプールを作成します。

• VM SKU の可用性: 選択した VM SKU は、リージョン内の複数のゾーンで使用できる必要があります。 リソース SKU リスト API を使用して、VM SKU の locationInfo フィールドを確認します。

• サブスクリプション アクセス:ユーザー サブスクリプション プールの割り当てモードの場合、サブスクリプションには、選択した VM SKU に対するゾーン オファーの制限が設定されていない必要があります。 リソース SKU リスト API 応答の ResourceSkuRestrictions を確認します。 制限が存在する場合は、サポート リクエストを送信してその解除を依頼します。

• ノード間通信:InfiniBand 対応 VM SKU でノード間通信が有効になっている場合、プールは可用性ゾーン配置ポリシーを使用できません。

ゾーン間でのインスタンスの分散

可用性ゾーンの配置を有効にすると、Batch は選択したリージョン内のすべての可用性ゾーンにコンピューティング ノードの割り当てを試みます。 この割り当てはベスト エフォートベースで実行されます。 バッチによって分散が制御され、各ゾーン内のノードの数が等しくない可能性があります。

Cost

Batch では、アベイラビリティーゾーン配置を有効にするための料金は追加されません。 ワークロードで使用されるコンピューティング、ストレージ、ネットワーク、その他の Azure リソースに対して課金されます。 ゾーン障害に対応するために追加のノードをプロビジョニングすると、それらのノードには通常の料金が発生します。 詳細については、「Azure Batch価格」を参照してください。

可用性ゾーンのサポートを設定する

• 可用性ゾーンの配置を使用して新しいプールを作成します: 可用性ゾーンの配置を有効にしてプールを作成するには、可用性ゾーン間での Batch プールの作成を参照してください。

• 既存のプールでの可用性ゾーンの配置を変更します 。プールを作成するときは、可用性ゾーンの配置を選択する必要があります。 可用性ゾーンを使用するように既存のプールを変更することはできません。

  次の手順を使用して、置換プールを作成し、それを使用するように各ジョブを更新できます。

  1. ジョブを無効にします。[ジョブの無効化] 操作を使用し、要求の送信時に実行されているタスクを Batch で処理する方法を選択します。

     • 待機: Batch は新しいタスクの開始を停止し、既存のプールで実行中のタスクを完了させます。 実行中のタスクが完了するまで、ジョブは disabling 状態のままになります。
     • Requeue: Batch は実行中のタスクを中断し、キューに戻します。 タスクは、ジョブを有効にした後に再度実行できます。
     • 終了: Batch は実行中のタスクを中断し、タスクが終了されたことを示す失敗情報で完了としてマークします。 ジョブを有効にした後、タスクは再実行されません。

     既に active の状態にあるタスクは、キューに登録されているが実行されていないことを意味し、すべてのオプションでキューに残ります。

     ジョブがdisabled状態になるまで待ってから続行してください。 その時点で、タスクは実行されておらず、Batch は新しいタスクをスケジュールしません。

  2. ジョブ プールの編集:ジョブの更新操作を使用して、ジョブの poolInfo.poolId を置換プールに設定します。 Batch では、ジョブが disabled 状態の間にのみ、このプロパティの変更が許可されます。 ジョブを有効にする前に、置換プールが存在し、使用可能な容量があることを確認します。 プールが存在しない場合、Batch は更新を受け入れますが、プールを作成するまでタスクをスケジュールすることはできません。

  3. ジョブを有効にします。[ジョブの有効化] 操作を使用します。 ジョブは enabling 状態を経て active 状態に遷移します。 次に、バッチは、Requeue オプションによってキューに返されたタスクを含む、キューに入っているタスクを置換プールでスケジュールします。 Batch で 待機オプションが適用されている間に完了したタスクと、終了オプションによって終了されたタスクは、もう一度実行されません。

容量の計画と管理

Batch の 通常のノード復旧プロセス では、ゾーン障害時に使用できなくなったノードを置き換え、プールを構成済みのターゲット ノード数に復元しようとします。 そのターゲットを増加させません。 1 つのゾーンが使用できないときにワークロードが継続するのに十分な容量を保持するには、自動スケーリングを使用するか、手動でプールの容量を過剰にプロビジョニングすることを検討してください。

• 自動スケールを使用する場合: プールの自動スケール式で$UsableNodeCountサービス定義変数を参照して、使用可能な容量がワークロードに必要なベースラインを下回った場合を検出します。 $UsableNodeCountは、Azure Monitorメトリックではなく、式が評価されるプールの Batch 自動スケール変数です。 Azure Monitor は Batch アカウント スコープで Batch ノードカウント メトリックを発行しますが、これらのメトリックにはpoolIdディメンションがありません。

• 容量を手動で管理する場合:プール ノード数の一覧表示操作を使用して、各プールの各状態の専用ノード数とスポット ノード数を取得します。 この操作では、単一の使用可能なノード数は返されません。 unusable や unknown などのタスク対応状態を、offline、startTaskFailed、idle、running などの使用できない状態や問題の状態に照らして評価します。 返されるカウントは最新ではない可能性があるため、正確な数が必要な場合は、プールのコンピューティング ノードを列挙してください。

バッチはベスト エフォートベースでノードをゾーン間で分散するため、実際の分散は等しくない可能性があります。 容量を計画するときに、ノードがゾーン間で均等に分散されるとは想定しないでください。 ワークロードがプール容量が減少した状態で復旧目標を満たすことができることを検証します。

すべてのゾーンが正常な場合の動作

このセクションでは、Batch プールで可用性ゾーンの配置が使用され、すべてのゾーンが動作している場合に想定される内容について説明します。

• ゾーン間操作: Batch は、各ノードを含むゾーンに関係なく、プール全体で使用可能なコンピューティング ノード上にタスクをスケジュールします。

• ゾーン間データ レプリケーション: Batch コンピューティング ノードはエフェメラルであり、Batch はゾーン間でタスク ファイルをレプリケートしません。 ノード障害後も保持する必要がある入力、出力、チェックポイント、診断データを永続的ストレージに移動する必要があります。 可用性要件を満たすようにストレージ アカウントの冗長性を構成します。

ゾーン障害時の動作

このセクションでは、Batch プールで可用性ゾーンの配置が使用され、1 つの可用性ゾーンが使用できない場合に想定される内容について説明します。

• 検出と応答: Microsoftは Batch サービスとコンピューティング ノードの正常性を監視します。 ゾーン障害時に、Batch は影響を受けるノードからの持続的なハートビート損失を検出し、 通常のノード回復プロセスを開始します。 正常なゾーン内のノードは引き続き使用でき、Batch では引き続きそれらのノードに対するタスクのスケジュールを設定できます。

  Batch は、通常の復旧プロセスを通じてプールを構成されたターゲット ノード数に復元しようとしますが、ただし、Batch がそのターゲット ノード数を増やすことはありません。 ターゲットがワークロードに十分な容量を提供しない場合は、追加の容量を要求する責任があります。

• 通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Service Health を使用して、ゾーン障害を含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することができます。

• アクティブなタスク: 影響を受けるノードで実行されているタスクは中断されます。 Batch では、内部復旧動作の一環として、使用可能なノードにタスクが再スケジュールされる場合があります。 一時的な障害に対する回復性とコンピューティング ノード障害に対する回復性に関する説明に従って、再試行と再実行を許容するようにタスクを設計します。

• 予想されるデータ損失: 影響を受けるコンピューティング ノード上のファイルは停止中は使用できず、ノードが再イメージ化またはプールから削除されると失われます。 Batch では、これらのファイルはゾーン間でレプリケートされません。 永続ストレージに永続化されたデータは、そのストレージ リソースの冗長性構成に従って引き続き利用可能です。

• 想定ダウンタイム: 正常なノード上のタスクは継続します。 中断されたタスクは、Batch がそれらを使用可能なノードに再スケジュールできるようになるまでダウンタイムが発生します。 使用可能なノードがない場合、タスクは Batch が再スケジュールできるようになるまで running のままになることがあります。 復旧時間は、使用可能なプール容量とキューに置かれたワークロードによって異なります。

  アカウントがコントロール プレーンのゾーン回復性があるリージョンにある場合、Batch アカウントやその他の Batch リソースに対する管理操作は続行されます。 他のリージョンでは、影響を受けるゾーンが復旧するまで、管理操作が使用できなくなる可能性があります。

• 再配布: 持続的なハートビート損失の後、Batch は影響を受けるノードを unusable としてマークし、通常のノード復旧プロセスを通じて交換のために送信します。 Batch は構成済みのターゲット ノード数にプールを復元しようとしますが、補充可能な容量は、正常なゾーンでのクォータと VM の可用性によって異なります。

  ジョブは、このプロセス中もプールに関連付けられたままになります。 Batch は、正常なゾーン内の使用可能なノードでアクティブなジョブからのタスクを引き続きスケジュールします。 置換ノードが割り当てられ、使用可能になった場合、Batch はそれらのノードでタスクをスケジュールすることもできます。

  この復旧プロセスでは、設定されたターゲット ノード数は増加しません。 ワークロードでそのターゲットを超える容量が必要な場合は、手動で増やすか、プールの自動スケール式を設定して対応します。

ゾーンの回復

バッチは、障害が発生した後にゾーンが回復したときに復旧プロセスを管理します。 Batch は、 コンピューティング ノードの障害に対する回復性で定義されているのと同じプロセスに従います。

Batch では、復旧後にノードが可用性ゾーン間で均等に再調整されるとは限りません。 ゾーンの配置は、ベストエフォートのままです。

ゾーンエラーのテスト

テストのために実際のAzure可用性ゾーンの停止をシミュレートすることはできません。 代わりに、非運用プールを使用して代表的なタスクを中断し、予想される処理能力低下に近似するのに十分なコンピューティング ノードをサービスから除外します。 次のサポートされているノード操作の使用を検討してください。

• 選択したノードを再起動します。
• 選択したノードでのタスク スケジューリングを無効にします。
• 選択したノードをプールから削除します。

操作で実行中のタスクを処理する方法を選択できる場合は、[ Requeue ]\(再キュー\) オプションを選択して、Batch が割り込まれたタスクを残りのノードでスケジュールできるようにします。

テスト中に、Batch が中断されたタスクを再スケジュールし、再実行によって重複または不整合な出力が生成されていないことを確認します。 チェックポイントと出力が永続的ストレージから引き続き使用可能であることを確認し、監視によってノードの損失と容量低下が検出され、残りの容量でワークロードが完了できることを確認します。

これらの操作は、タスクの中断と再スケジュール、べき等性、チェックポイント処理、および永続的な出力処理を検証します。 ただし、ゾーン全体の障害のすべての影響を再現するわけではありません。

リージョン全体の障害に対する回復性

Batch アカウントとそのプールは、1 つの Azure リージョンに限定されます。 リージョンで障害が発生した場合、Batch ジョブとプールが影響を受ける可能性があります。

Batch では、アカウント、プールの構成、ジョブ、タスク、アプリケーション パッケージ、またはタスク データは別のリージョンにレプリケートされません。また、組み込みのリージョン間フェールオーバーも提供されません。 ワークロードがリージョン全体の障害に耐える必要がある場合は、マルチリージョン Batch ソリューションをデプロイして運用する必要があります。

レジリエンス向けのカスタム マルチリージョン ソリューション

マルチリージョン ソリューションを構築するには、復旧設計で使用される各リージョンに少なくとも 1 つの Batch アカウントをデプロイします。 Batch アカウントは、リージョン間で独立して動作します。 お客様は、リージョンの選択、各リージョンでのリソースのデプロイと運用、構成、レプリケーション、フェールオーバー、フェールバックの調整を行う必要があります。

通常の運用中に複数のリージョンで作業を送信する アクティブ/アクティブ アプローチ、またはセカンダリ デプロイをフェールオーバーに備えて待機させる アクティブ/パッシブ アプローチを設計できます。 アクティブ/アクティブ設計では、両方のデプロイで通常運用中も処理を実行するため復旧時間を短縮できますが、アクティブ/パッシブ設計では定常状態のコンピューティング コストを削減できます。

次の一覧に、ソリューションを設計するときの責任の例を示します。

• デプロイ: Batch アカウント、プールまたはプールのデプロイ定義、ストレージ アカウント、ネットワーク リソース、およびその他の依存関係を各リージョンに事前に作成します。 選択した各リージョンで、ワークロードに必要な Batch 機能、VM サイズ、依存サービスがサポートされていることを確認します。 不要な待機時間を回避するために、各 Batch アカウントとそのタスクで使用されるストレージ リソースは、可能な限り同じリージョンに保持します。 構成をリージョン間で一貫して再現できるように、コードとしてインフラストラクチャを使用して Batch アカウント、プール、およびサポート リソースを定義します。

• クォータと容量: すべての復旧リージョンで該当する Batch アカウント、サブスクリプション、VM ファミリのクォータを確認し、必要に応じて障害発生前に引き上げを申請します。 クォータは、容量の保証ではなく、制限です。 VM の可用性は、リージョン、VM ファミリ、時期によって異なります。 詳細については、「 Batch アカウントとコア クォータ」を参照してください。

• データ レプリケーション: アプリケーション パッケージ、コンテナー イメージ、入力データ、および参照データを、すべての復旧リージョンで利用可能な状態に保ちます。 Batch では、これらの項目は自動的にレプリケートされません。

• ストレージ レプリケーション: 復旧ポイントの目標に基づいて、ストレージの冗長性とリージョン間のデータ レプリケーションを構成します。 レプリケートされたデータが各復旧リージョンからアクセス可能であることを確認します。 ストレージの信頼性オプションについては、「Azure Blob Storageの信頼性」を参照してください。

• リージョンのターゲット設定: アプリケーションが Batch アカウントで動作する場合は、コードのデプロイを必要とせずに別の Batch アカウントとそれに関連付けられているストレージ リソースを選択できるように設計します。

• フェールオーバー: Batch によってワークロードが別のリージョンに自動的に移動されることはありません。 障害を検出し、障害がワークロードに与える影響を判断し、影響を受ける Batch アカウントへの送信を停止し、正常なリージョンの Batch アカウントに新しい作業を送信し、中断されたジョブを再送信するかどうかを決定する必要があります。 影響を受けるリージョンの外部にレプリケートしていない作業またはタスクの出力は、使用できないか失われる可能性があります。 復旧時間は、デプロイ モデル、使用可能な容量、データ レプリケーション、自動化によって異なります。

• リージョンの回復: 影響を受けるリージョンでサービスの可用性が復元されたら、そのリージョンに作業を転送する前に、Batch アカウント、プール、ストレージの依存関係、ジョブの状態を検証します。 再送信する前に、重複または途中まで完了したタスクを解消します。 Batch では、このプロセスを調整したり、リージョン アカウント間で状態の整合性を取ったりすることはありません。

• テスト: 非運用環境で完全なリージョン復旧プロセスを定期的にテストします。 リージョン デプロイが使用不可になる状況をシミュレートし、送信要求を別のリージョンの Batch アカウントに向け、アプリケーション パッケージと入力データへのアクセスを検証し、代表的なジョブを実行し、出力を収集し、復旧されたデプロイをサービスに返す練習を行います。 目標復旧時間と目標復旧時点に対して結果を測定します。

バックアップと復元

Azure Batchは、ワークロードの入力データと出力データの永続的なストアではありません。 Microsoftは Batch サービスを維持しますが、ワークロードを再作成するために必要な構成とデータを保持する必要があります。

• バッチ構成:Bicepやバージョン管理されたジョブ定義などのコードとしてインフラストラクチャを使用して、Batch アカウント、プール、ジョブ、およびサポート リソースを定義します。 これらの成果物は、同じリージョンまたは別のリージョンで構成を再作成する反復可能な方法を提供します。 定義でプールをデプロイし、代表的なジョブを実行できることを定期的にテストします。

• バッチ メタデータ: Batch は、関連付けられているジョブまたはタスクを削除するまでジョブレコードとタスクレコードを保持しますが、これらのレコードはバックアップではありません。 この履歴を保持する必要がある場合は、Batch の外部で必要なレコードを保持してください。

• コンピューティング ノード上のデータ: コンピューティング ノードは一時的なものであり、それらのファイル システムはバックアップ先でも永続的な保存先でもありません。 ノード上のデータは、ノードの再イメージ化時またはプールから削除されたときに失われます。 Batch では、保持期間が経過した後にタスク ファイルを削除することもできます。 タスクが完了する前に、必要な出力と診断ログを永続的ストレージに保持します。 実行時間の長いタスクの場合は、実行中にチェックポイントを永続化します。 詳細については、「ジョブとタスクの出力を保持する」および「Azure Batch の監視」を参照してください。

• 自動ストレージ アカウント内のデータ: 関連付けられている自動ストレージ アカウントは、アプリケーション パッケージとタスク リソース ファイルを保持できます。 回復目標を満たす冗長性を構成するだけでなく、このデータを誤って削除されたり破損したりすることから保護する必要があるかどうかを検討してください。 詳細については、「Azure Blob Storageでのバックアップと回復」を参照してください。

復元およびリカバリのテスト

回復するには、Batch とサポート リソース構成をデプロイし、必要な入力データとアプリケーション成果物を復元または再接続し、完了しなかった作業を再送信します。 隔離された復旧環境または非運用環境で、リソース再構築とデータ復元の両方を定期的にテストします。 バージョン管理された定義とバックアップ データを使用し、代表的なジョブを実行し、結果の出力と依存関係へのアクセスを確認し、目標に対して達成された復旧時間と復旧ポイントを測定します。 タスクがべき等であることを確認して、不確実な作業を再送信してもデータが破損したり、重複する出力が作成されたりしないようにします。

サービス メンテナンスに対する回復性

Microsoftは、プラットフォームのメンテナンスを実行し、Azure Batchやその他のサービスのインフラストラクチャの更新を調整します。 プールの更新動作を構成し、中断を許容するタスクを設計する必要があります。

• ホスト メンテナンス: Azureは、可能な場合はライブ マイグレーションなどのメンテナンス手法を使用します。 メンテナンスでコンピューティング ノードを再起動または移動する必要がある場合は、実行中のタスクが中断される可能性があり、Batch によりタスクが再スケジュールされる可能性があります。 タスクを冪等にし、チェックポイントと出力を永続ストレージに保持します。

• ゲスト オペレーティング システム: ゲスト オペレーティング システムと Batch ノード エージェントを最新の状態に保つ必要があります。 オペレーティング システムの更新動作は、イメージと更新プログラムの構成によって異なります。 適切な構成では、 Batch プールの OS イメージの自動アップグレード によって、実行中のタスクを中断することなくプール ノードを更新できます。 OS イメージの自動アップグレードでは、すべての Batch オペレーティング システム イメージがサポートされるわけではありません。

• ノード エージェントの更新: OS イメージの自動アップグレードでは、Batch ノード エージェントは自動的に更新されません。 プールにコンピューティング ノードがある間、Batch ノード エージェントは自動的にアップグレードされません。 新しいノード エージェントを取得するには、プールのサイズを 0 ノードに変更し、もう一度スケールアップするか、プールを置き換えます。 ノードを削除する前に、必要なタスク出力と診断ログを保持してください。 詳細については、「Batch ノード エージェントの更新」を参照してください。

本番環境へのデプロイに関する推奨事項とコンピューティング ノード障害時のガイダンスに従って、メンテナンスによってタスクが中断されたり、コンピューティング ノードが使用できなくなったりしたときに、ワークロードを続行または復旧するのに役立ててください。

サービス水準合意書

Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。

Azure Batch可用性 SLA は、Batch API に対して実行する操作に適用されます。 含まれる操作の種類の詳細については、SLA の文言を確認してください。 プール サイズ、ゾーン分散、依存サービスは、ワークロードのエンド ツー エンドの可用性に影響しますが、Batch SLA の条件は変更しません。

関連するコンテンツ

• Azure Batch のドキュメント
• Azure Batchのベスト プラクティス
• Azure での信頼性