この記事では、 Azure Container Instances での信頼性のサポートについて説明します。これにより、仮想マシン (VM) を管理したり、より複雑で高度なサービスを導入したりする必要なく、Azure で Linux または Windows コンテナーを簡単に実行できます。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対する Azure Container Instances の回復性を確保する方法について説明します。 Azure Container Instances サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報が強調表示されています。
信頼性のための運用環境のデプロイに関する推奨事項
Container Instances 上に構築された運用アプリケーションの信頼性を高めるために、次のアクションを実行することをお勧めします。
- 複数の可用性ゾーンにわたってアプリケーションを実行します。
- 複数のリージョンで個別のコンテナー グループも実行するかどうかを検討します。
- 異常なコンテナーを検出して自動的に再起動するには、 liveness プローブ を使用します。
- 準備プローブを使用して、コンテナーがトラフィックを受信する前に準備ができるまで待機します。
- NGroups を使用する場合は、ローリング アップグレードを使用して変更を段階的に適用します。 この方法により、アップグレードによるダウンタイムの可能性が低くなります。
- コンテナー インスタンスのベスト プラクティスと考慮事項を確認します。
信頼性アーキテクチャの概要
コンテナー インスタンスを使用するには、 コンテナー グループをデプロイします。 コンテナー グループには、1 つ以上の コンテナーが含まれています。 各コンテナーは、Azure Container Registry などのレジストリに格納されるコンテナー イメージから作成されます。
コンテナー グループ内のすべてのコンテナーは、1 つの論理ユニットとしてまとめてデプロイされ、同じ物理インフラストラクチャを共有します。
次の図は、コンテナー グループ、コンテナー、イメージ間の関係を示しています。
この図は、コンテナー グループ セクション内の 2 つのコンテナーを示しています。 2 つの点線は、レジストリ セクションの 2 つのイメージ セクションにコンテナーを接続します。
Container Instances には、コンテナー グループを管理するための次の機能が用意されています。
NGroups (プレビュー) には、複数の関連するコンテナー グループを管理するための一連の機能が用意されています。 NGroup を作成するときは、作成するコンテナー グループの数を定義します。 Container Instances には、アップグレードの自動ロールアウトや、可用性ゾーン間でのコンテナー グループの分散などの機能が用意されています。
スタンバイ プール は、受信トラフィックに応答して使用できる、事前プロビジョニングされたコンテナー グループのプールを作成します。 スタンバイ プールは、コンテナー グループの作成を最適化するように設計されており、回復性を向上させるものではありません。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Microsoft 提供の SDK は、通常、一時的な障害を処理します。 コンテナー インスタンスで独自のアプリケーションをホストするため、一時的な障害の可能性を減らす手順を実行します。
重要なワークロードに対して複数のコンテナー グループを実行して、1 つのコンテナーまたはコンテナー グループの障害がアプリケーション全体に影響しないようにします。
バックオフ戦略で再試行ポリシーを使用するなど、接続先のサービスの一時的な障害に対する回復性を備えたアプリケーション コードを構築します。
実行時に発生する可能性があるその他のエラーとその対応方法の詳細については、「 コンテナー グループの実行時の問題」を参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Container Instances では、コンテナー グループのデプロイ方法に応じて、さまざまな方法で可用性ゾーンがサポートされます。
手動で作成されたコンテナー グループ: 個々のコンテナー グループは ゾーン リソース です。つまり、選択した単一の可用性ゾーンにデプロイできます。 グループ内のすべてのコンテナーは、同じ可用性ゾーンにデプロイされます。 その可用性ゾーンに障害が発生した場合、コンテナー グループとそのすべてのコンテナーでダウンタイムが発生する可能性があります。
次の図は、可用性ゾーン 1 に手動でデプロイされたコンテナー グループを示しています。
この図は、可用性ゾーン 1、可用性ゾーン 2、可用性ゾーン 3 の 3 つの可用性ゾーンを示しています。 可用性ゾーン 1 のコンテナー グループには、2 つのコンテナーが含まれています。
注
リージョン内の単一のゾーンで障害が発生した場合にアプリケーションが引き続き実行されるようにするには、2 つの異なる可用性ゾーンに少なくとも 2 つのコンテナー グループを作成することをお勧めします。
コンテナー グループに使用する可用性ゾーンを指定しない場合、非 ゾーン または リージョンです。つまり、リージョン内または同じゾーン内の任意の可用性ゾーンに配置される可能性があります。 リージョン内の可用性ゾーンに問題がある場合、コンテナー グループでダウンタイムが発生する可能性があります。
NGroups: NGroup をデプロイするときに、展開する 1 つ以上のゾーンを指定できます。 NGroup を 2 つ以上のゾーンにデプロイすると、ゾーン 冗長 NGroup になり、1 つの可用性ゾーンが停止すると、影響を受けるゾーン内のコンテナー グループに対してのみ問題が発生します。
次の図は、3 つの可用性ゾーンにデプロイされている NGroup を示しています。
この図は、3 つの可用性ゾーンを示しています。 各可用性ゾーンには、コンテナー グループと 2 つのコンテナーが含まれます。 NGroupdesiredCount=3、zones=1,2,3 というラベルの付いた四角形は、3 つの可用性ゾーンすべてにまたがっています。
NGroup に使用する可用性ゾーンを指定しない場合、非ゾーンであり、リージョン内の可用性ゾーンに問題がある場合にダウンタイムが発生する可能性があります。
スタンバイ プール: スタンバイ プールをデプロイする場合は、必要に応じて 1 つ以上のゾーンを指定できます。 プラットフォームは、選択したゾーン間でコンテナーを要求する場合があります。
ただし、複数のゾーンにコンテナーが作成される保証がないため、スタンバイ プールはゾーン冗長またはゾーン回復性がありません。 ゾーンの停止が発生した場合、プール内のすべてのコンテナーが影響を受けるゾーンに配置される可能性があります。
スタンバイ プールはゾーン障害に対する回復性をサポートするように設計されていないため、このガイドでは、可用性ゾーンを持つスタンバイ プールの詳細な動作については説明しません。
Important
スタンバイ プールは、ゾーンの回復性を備えて設計されていません。 ゾーン障害に対する回復性を必要とするワークロードには使用しないでください。
リージョンのサポート
ゾーンコンテナー グループのデプロイは、 可用性ゾーンを持つすべてのリージョンでサポートされています。
Requirements
ゾーン展開は、Linux および Windows Server 2019 コンテナー グループで使用できます。
可用性ゾーンを選択するには、Standard SKU を使用する必要があります。 ゾーン コンテナー グループは、Confidential SKU では使用できません。
考慮事項
スポット コンテナー は可用性ゾーンをサポートせず、常に非ゾーンです。
費用
コンテナー グループの可用性ゾーンを構成するための追加コストは発生しません。
可用性ゾーンのサポートを設定する
可用性ゾーンのサポートを使用してコンテナー グループを作成します。 可用性ゾーンの構成に使用する方法は、コンテナー グループの作成方法によって異なります。
手動で作成されたコンテナー グループ: 特定のゾーンにゾーン コンテナー グループを作成するには、次のいずれかの方法を使用できます。
NGroups: Bicep ファイルまたは ARM テンプレートを使用し、複数のゾーンを指定することで、ゾーン冗長 NGroup をデプロイできます。 詳細については、「 ゾーンを含む NGroups のサンプル」を参照してください。
スタンバイ プール: プールの作成時または更新時に 1 つ以上のゾーンを指定することで、可用性ゾーンを使用するスタンバイ プールをデプロイできます。 ただし、コンテナーが複数のゾーンに作成されない場合があります。 ゾーン障害に対する回復性を必要とするワークロードでは、スタンバイ プールを使用しないでください。 詳細については、「 コンテナー インスタンスのスタンバイ プールを作成する」を参照してください。
既存のリソースで可用性ゾーンのサポートを有効にします。 可用性ゾーンの構成に使用する方法は、コンテナー グループの作成方法によって異なります。
手動で作成されたコンテナー グループ: 既存の非ゾーン コンテナー グループで可用性ゾーンを有効にすることはできません。 コンテナー グループを削除し、ゾーン コンテナー グループを作成する必要があります。
NGroups: 既存の非ゾーン NGroup で可用性ゾーンを有効にすることはできません。 NGroup を削除し、ゾーン冗長 NGroup を作成する必要があります。
スタンバイ プール: 既存の非ゾーン スタンバイ プールで可用性ゾーンを有効にすることはできません。 コンテナー グループを削除し、複数の可用性ゾーンを使用する新しいスタンバイ プールを作成する必要があります。
ゾーン間でコンテナー グループを移動するか、可用性ゾーンのサポートを無効にします。 可用性ゾーンの変更に使用する方法は、コンテナー グループの作成方法によって異なります。
手動で作成されたコンテナー グループ: コンテナー グループの可用性ゾーンを変更するには、コンテナー グループを削除し、新しい可用性ゾーンを持つ別のコンテナー グループを作成する必要があります。 コンテナー グループを削除する方法については、次のリソースを参照してください。
NGroups: NGroup にゾーンを追加することはできますが、ゾーンを削除することはできません。
スタンバイ プール: スタンバイ プールにゾーンを追加することはできますが、ゾーンを削除することはできません。
コンテナー グループの分散
コンテナー グループを可用性ゾーン間で分散する方法は、コンテナー グループのデプロイ方法によって異なります。
手動で作成されたコンテナー グループ: 手動で作成したコンテナー グループを複数の可用性ゾーンに分散する責任があります。
NGroups: スケールイン操作中に、NGroups はインスタンスをランダムに削除します。これは、可用性ゾーン間で分散が維持されない可能性があります。 スケールアウト操作では、ゾーン間の分散を再調整しようとします。
スタンバイ プール: スタンバイ プールは、プールで構成した任意の可用性ゾーンにコンテナーを作成できます。 ただし、コンテナーが複数のゾーンに作成されない場合があります。 ゾーン障害に対する回復性を必要とするワークロードでは、スタンバイ プールを使用しないでください。
容量の計画と管理
可用性ゾーンの障害に備えて、デプロイするコンテナー グループの数を オーバープロビジョニング することを検討してください。 このアプローチにより、ソリューションは容量損失を許容し、パフォーマンスが低下することなく機能し続けられます。 詳細については、「 オーバープロビジョニングを使用して容量を管理する」を参照してください。
コンテナー グループのオーバープロビジョニングに使用する方法は、コンテナー グループのデプロイ方法によって異なります。
手動で作成されたコンテナー グループ: 各ゾーンにデプロイするコンテナー グループの数の計画など、手動で作成したコンテナー グループの容量を計画する必要があります。
NGroup: ゾーンの損失を許容するために、NGroup の容量を 過剰プロビジョニング することを検討してください。
スタンバイ プール: スタンバイ プールは、ゾーンの障害に対する回復性を持つようには設計されていません。 異なるゾーンで複数のスタンバイ プールを使用するか、NGroup を使用することを検討してください。
すべてのゾーンが正常な場合の動作
このセクションでは、Container Instances リソースが可用性ゾーンのサポート用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: トラフィックをコンテナーにルーティングする責任があります。 たとえば、 Azure Application Gateway を コンテナー グループのゲートウェイおよびロード バランサーとして使用できます。
NGroup またはスタンバイ プールを使用する場合は、各コンテナー間で負荷分散を行う必要があります。 また、各コンテナー グループの正常性を検出し、必要に応じてトラフィックを別のグループにリダイレクトするようにトラフィック ルーティング システムを構成する必要もあります。
ゾーン間のデータ レプリケーション: コンテナーとコンテナー グループはステートレスです。 独自のファイル共有をアタッチすることも、アプリケーション内からデータベースやその他のストレージ サービスに接続することもできます。 あなたは、これらのファイル共有とストレージ サービスがゾーンの回復性を持つように確保する責任があります。 各サービスの 信頼性ガイド を確認して、各コンポーネント ゾーンの回復性を高める方法を理解します。
ゾーン障害時の動作
このセクションでは、Container Instances リソースが可用性ゾーンのサポート用に構成されていて、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
検出と応答: ゾーンの障害と関連する応答の検出の責任は、コンテナー グループのデプロイ方法によって異なります。
手動で作成されたコンテナー グループ: 可用性ゾーンの損失を検出し、別の可用性ゾーンに作成したセカンダリ コンテナー グループへのフェールオーバーを開始する必要があります。
NGroups: Container Instances プラットフォームは、可用性ゾーンでの障害の検出と応答を担当します。
ただし、トラフィックが正常なゾーン内のコンテナーにルーティングされるようにする必要があります。
スタンバイ プール: Container Instances プラットフォームは、スタンバイ プールのゾーン障害に対応するとは限りません。 ゾーン障害に対する回復性を必要とするワークロードでは、スタンバイ プールを使用しないでください。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: ゾーンで障害が発生した場合、そのゾーンで実行されているすべてのコンテナーが停止する可能性があります (処理しているアクティブな作業も含む)
予想されるデータ損失: コンテナーとコンテナー グループはステートレスであるため、ゾーン障害によるデータ損失は発生しません。 ただし、ストレージ サービスやデータベースを含め、ワークロード内の各コンポーネントがゾーンの回復性を確保する責任があります。
予想されるダウンタイム: ゾーンの障害によって予想されるダウンタイムは、コンテナー グループのデプロイ方法によって異なります。
手動で作成されたコンテナー グループ: ゾーン コンテナー グループの場合、ゾーンが使用できない場合、可用性ゾーンが復旧するまで、コンテナー グループとそのコンテナーは使用できません。
NGroups: NGroups の場合、1 つのゾーンがダウンしても、NGroups 内の残りのコンテナー グループは引き続き他のゾーンで実行されるため、アプリケーションは引き続き使用できます。 ダウンタイムは発生しません。
スタンバイ プール: スタンバイ プールでは、ゾーンの回復性は提供されません。 スタンバイ プール内のすべてのコンテナー グループが 1 つのゾーンにある場合、可用性ゾーンが復旧するまで、すべてのコンテナー グループとそのコンテナーが使用できなくなる可能性があります。
トラフィックの再ルーティング: コンテナーにトラフィックをルーティングする責任があるため、可用性ゾーンの停止によりコンテナー グループが失敗した場合のトラフィックの再ルーティングも担当します。
ゾーンの回復
ゾーンが復旧すると、停止したコンテナー グループが Azure プラットフォームによって自動的に再起動されます。 お客様による対応は必要ありません。
ゾーンエラーのテスト
コンテナー グループを含む可用性ゾーンの停止をシミュレートする方法はありません。 ただし、アップストリーム ゲートウェイまたはロード バランサーを手動で構成して、別の可用性ゾーン内の別のコンテナー グループにトラフィックをリダイレクトできます。
リージョン全体の障害に対する回復性
Container Instances は、単一リージョンのサービスです。 リージョンが使用できなくなった場合、コンテナー グループとそのコンテナーも使用できなくなります。
回復性のためのカスタム マルチリージョン ソリューション
必要に応じて、複数のリージョンに個別のコンテナー グループをデプロイできます。 各リージョンでコンテナー グループのデプロイと構成を行う必要があります。 また、Azure Traffic Manager や Azure Front Door などのサービスを使用して負荷分散を構成する必要もあります。 データの同期、フェールオーバー、フェールバックは、お客様が担当します。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。