Azure Batch での信頼性
この記事では、Azure Batch における信頼性サポートについて説明し、可用性ゾーンによるリージョン内の回復性と、リージョン間の回復と事業継続に関する情報へのリンクの両方について取り上げます。
可用性ゾーンのサポート
Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。
障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。
Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャの比較の詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。
Batch では、可用性ゾーンのサポートで Azure とのパリティが維持されます。
前提条件
ユーザー サブスクリプション モードの Batch アカウントの場合、プールを作成するサブスクリプションに、要求した VM SKU に対するゾーン オファーの制限がないことを確認します。 サブスクリプションに制限がないかどうかを確認するには、リソース SKU リスト API を呼び出し、
ResourceSkuRestrictionsを確認します。 ゾーン制限が存在する場合は、ゾーン制限を解除するためにサポート チケットを送信できます。InfiniBand ではゾーン間通信がサポートされないため、ノード間通信が有効になっていて、InfiniBand をサポートする VM SKU を使用する場合は、ゾーン ポリシーを使用してプールを作成することはできません。
Batch では、可用性ゾーンのサポートで Azure とのパリティが維持されます。 ゾーン オプションを使用するには、可用性ゾーンがサポートされている Azure リージョンにプールを作成する必要があります。
可用性ゾーン間で Batch プールを割り当てるには、プールが作成された Azure リージョンで、複数のゾーンで要求された VM SKU をサポートする必要があります。 リージョンが複数のゾーンで要求された VM SKU をサポートしていることを検証するには、リソース SKU リスト API を呼び出し、
resourceSkuのlocationInfoフィールドを確認します。 要求した VM SKU に対して、複数のゾーンがサポートされていることを確認します。 次のコマンドを使用して、Azure CLI で使用可能なすべてのリソース SKU を一覧表示することもできます。az vm list-skus
可用性ゾーン間で Azure Batch プールを作成する
可用性ゾーン間で Batch プールを作成する方法の例については、「可用性ゾーン間で Azure Batch プールを作成する」を参照してください。
Azure portal、Azure CLI、PowerShell、または Batch Management API を使用して Batch アカウントを作成する方法の詳細について説明します。
ゾーン ダウン エクスペリエンス
ゾーン ダウン停止中、そのゾーン内のノードは使用できなくなります。 他のゾーンの同じノード プール内のノードは影響を受けず、引き続き使用できます。
Azure Batch アカウントでは、停止が原因でダウンしたノードを補正するために、新しいノードを再割り当てしたり、新しいノードを作成したりすることはありません。 ユーザーは、ノード プールにさらにノードを追加する必要があります。その後、他の正常なゾーンから割り当てられます。
フォールト トレランス
可用性ゾーンの障害の可能性に備えるためには、サービスの容量を過剰にプロビジョニングして、ソリューションが容量の 1/3 の損失を許容し、ゾーン全体の障害発生時にパフォーマンスを低下させることなく機能し続けられるようにする必要があります。 プラットフォームによって VM が 3 つのゾーンに分散されていて、少なくとも 1 つのゾーンの障害に対応できる必要がある場合は、ピーク ワークロードのインスタンス数にゾーン数/(ゾーン数 -1)、つまり 3/2 をかけます。 たとえば、通常のピーク ワークロードに 4 つのインスタンスが必要な場合、6 つのインスタンスをプロビジョニングする必要があります: (2/3 * 6 インスタンス) = 4 インスタンス。
可用性ゾーンの移行
既存の Batch プールを可用性ゾーンのサポートに移行することはできません。 可用性ゾーン間で Batch プールを再作成する場合は、「可用性ゾーン間で Azure Batch プールを作成する」を参照してください。
リージョン間のディザスター リカバリーと事業継続
Azure Batch はすべての Azure リージョンにおいて利用できます。 ただし、Batch アカウントを作成したら、それを 1 つの特定のリージョンに関連付ける必要があります。 その Batch アカウントに対する以降の操作は、すべてそのリージョンにのみ適用されます。 たとえば、プールや関連付けられている仮想マシン (VM) は、Batch アカウントと同じリージョン内に作成されます。
Batch を使用するアプリケーションを設計するときは、Batch がリージョン内で使用できなくなっている可能性を考慮する必要があります。 まれな状況として、リージョン全体、リージョン内の Batch サービス全体、または特定の Batch アカウントに関する問題が発生する場合があります。
Batch を使用するアプリケーションまたはソリューションが常に使用可能である必要がある場合は、別のリージョンにフェールオーバーするか、またはワークロードが常に 2 つ以上のリージョン間で分割されるように設計する必要があります。 どちらのアプローチにも、それぞれが異なるリージョンに配置された、少なくとも 2 つの Batch アカウントが必要です。
Azure Batch を使用してリージョン間のディザスター リカバリーを設定する必要があります。 特定のリージョン間で複数の Batch アカウントを実行し、可用性ゾーンを利用すると、Batch アカウントのいずれかが使用できなくなったときに、アプリケーションがディザスター リカバリーの目標を満たすことができます。
代替リージョンにフェールオーバーする機能を実現する場合、ソリューション内のすべてのコンポーネントを検討する必要があります。2 つ目の Batch アカウントを作成するだけでは不十分です。 たとえば、ほとんどの Batch アプリケーションでは、Azure ストレージ アカウントが必要です。 許容されるパフォーマンスを得るには、ストレージ アカウントと Batch アカウントを同じリージョンに配置する必要があります。
フェールオーバー可能なソリューションを設計するときは、次の点を考慮してください。
各リージョン内に必要なすべてのサービス (Batch アカウントやストレージ アカウントなど) を事前に作成します。 多くの場合、アカウントの作成は無料であり、アカウントが使用されたとき、またはデータが格納されたときにのみ料金が発生します。
Batch アカウントを使用して必要なコア数を割り当てるには、すべてのユーザー サブスクリプション Batch アカウントに適切なクォータが設定されていることを事前に確認してください。
テンプレートまたはスクリプト、あるいはその両方を使用して、リージョンへのアプリケーションのデプロイを自動化します。
すべてのリージョンでアプリケーション バイナリや参照データを最新の状態に維持します。 最新の状態に維持することにより、ファイルのアップロードやデプロイを待つことなく、リージョンをすばやくオンラインにできるようになります。 たとえば、プール ノードにインストールするカスタム アプリケーションが保存され、Batch アプリケーション パッケージを使用して参照される場合を考えてみましょう。 アプリケーションの更新プログラムがリリースされると、各 Batch アカウントにアップロードされ、プール構成によって参照されます (または、最新バージョンを既定のバージョンにします)。
Batch、ストレージ、およびその他のサービスを呼び出すアプリケーションで、クライアントまたは負荷を別のリージョンに簡単に切り替えることができます。
通常の操作の一環として、代替リージョンに頻繁に切り替えることを検討してください。 たとえば、個別のリージョンに 2 つのデプロイがある場合は、毎月代替リージョンに切り替えます。
障害から復旧する時間は、選択したセットアップによって異なります。 Batch 自体は、複数のアカウントを使用しているか、1 つのアカウントを使用しているかに関係しません。 2 つの Batch インスタンスが同時にトラフィックを受信しているアクティブ/アクティブ構成では、ディザスター リカバリーはアクティブ/パッシブ構成よりも高速です。 選択する構成は、ビジネス ニーズ (異なるリージョン、待機時間の要件) と技術的な考慮事項に基づく必要があります。
単一リージョンのディザスター リカバリー
Batch でディザスター リカバリーを実装する方法は、単一リージョンでも複数リージョンでも同じです。 違いは、ストレージに使用する SKU と、すべてのリージョンで同じストレージ アカウントを使用するか異なるストレージ アカウントを使用するかということだけです。
ディザスター リカバリー テスト
Batch 対応ソリューションの独自のディザスター リカバリー テストを実行する必要があります。 異なるリージョン間でクライアントとサービスの負荷を簡単に切り替え可能にすることがベスト プラクティスであると考えられています。
Batch のディザスター リカバリー計画のテストは、Batch アカウントを変更するのと同じくらい簡単です。 たとえば、ある運用日に特定のリージョンの 1 つの Batch アカウントに依存できます。 次の日に、別のリージョンの 2 つ目の Batch アカウントに切り替えることができます。 ディザスター リカバリーは、主にクライアント側で管理されます。 ディザスター リカバリーに対するこの複数アカウント アプローチによって、単一リージョンまたは複数リージョンの地域での RTO と RPO の期待に対応します。
容量と予防的なディザスター リカバリーの回復性
Microsoft とそのお客様は、共有責任モデルの下で活動します。 Microsoft は、プラットフォームとインフラストラクチャの回復性を担当します。 お客様は、デプロイおよび制御する特定のサービスのディザスター リカバリーに対処する責任があります。 復旧がプロアクティブになることを保証するには、次の手順に従います。
常にセカンダリを事前にデプロイする必要があります。 このようなリソースを事前に割り当てていないユーザーには、障害が発生したときに容量が保証されないため、セカンダリの事前デプロイが必要です。
Batch アカウントや関連するストレージ アカウントなど、各リージョンに必要なすべてのサービスを事前に作成します。 新しいアカウントの作成は無料であり、アカウントが使用されたとき、またはデータが格納されたときにのみ料金が発生します。
Batch アカウントを使用して必要な数のコアを割り当てることができるように、事前にすべてのサブスクリプションに適切なクォータが設定されていることを確認してください。 他の Azure サービスと同様に、Batch サービスに関連付けられている特定のリソースにも制限があります。 これらの制限の多くは、Azure によって、サブスクリプションまたはアカウント レベルで適用される既定のクォータです。 Batch ワークロードの設計やスケールアップを行う際は、これらのクォータに留意してください。
Note
Batch で実稼働ワークロードを実行する予定がある場合は、1 つまたは複数のクォータについて既定値から増やすことが必要になる場合があります。 クォータを引き上げるには、クォータの増加を要求します (無料)。 詳細については、クォータの引き上げの要求に関するページを参照してください。
ストレージ
データがリージョン間でバックアップされるように Batch ストレージを構成する必要があります。既定ではお客様の責任です。 ほとんどの Batch ソリューションでは、リソース ファイルまたは出力ファイルを格納するために Azure Storage を使用します。 たとえば、Batch タスク (標準タスク、開始タスク、ジョブ準備タスク、ジョブ解放タスクなど) では通常、ストレージ アカウントに存在するリソース ファイルを指定します。 また、ストレージ アカウントでは、処理されるデータと生成される出力データを格納します。 リージョン間でサービス操作のデータ損失が発生する可能性を理解することは、重要な考慮事項です。 また、データが書き換え可能か読み取り専用かを確認する必要があります。
Batch では、次の Azure ストレージ アカウントの種類がサポートされます。
- 汎用 v2 (GPv2) アカウント
- 汎用 v1 (GPv1) アカウント
- BLOB ストレージ アカウント (現在、仮想マシン構成のプールに対してのみサポートされます)
ストレージ アカウントについて詳しくは、「Azure ストレージ アカウントの概要」をご覧ください。
ストレージ アカウントは、アカウントの作成時に Batch アカウントに関連付けることができます (後で実行することもできます)。
サービスを使用できるリージョンごとに個別のストレージ アカウントを設定する場合は、ゾーン冗長ストレージ (ZRS) アカウントを使用する必要があります。 ペアになっている複数のリージョンで同じストレージ アカウントを使用している場合は、geo ゾーン冗長ストレージ (GZRS) アカウントを使用します。 単一のリージョンを含む地域では、GZRS が使用できないため、ゾーン冗長ストレージ (ZRS) アカウントを作成する必要があります。
容量計画は、ストレージに関するもう 1 つの重要な考慮事項であり、事前に対処する必要があります。 ストレージ アカウントを選択するときに、コストとパフォーマンスの要件を検討してください。 たとえば、GPv2 アカウントおよび BLOB ストレージ アカウントのオプションでは、サポートされる容量とスケーラビリティの上限が GPv1 よりも高くなっています (容量の上限の引き上げを希望する場合、Azure サポートにお問い合わせください)。これらのアカウント オプションでは、ストレージ アカウントからの読み取りまたはストレージ アカウントへの書き込みを行う多数の並列タスクが含まれた、Batch ソリューションのパフォーマンスを向上させることができます。
ストレージ アカウントが Batch アカウントにリンクされている場合、そのアカウントは autostorage アカウントとみなされます。 アプリケーション パッケージの機能を使用する場合は、アプリケーション パッケージの .zip ファイルを保存するために使用されるため、autostorage アカウントが必要です。 autostorage アカウントは、タスク リソース ファイルにも使用できます。autostorage アカウントは既に Batch アカウントにリンクされているため、リソース ファイルにアクセスするための Shared Access Signature (SAS) URL を使用する必要がありません。