Azure Container Registry は、プライベート Docker コンテナー イメージとコンテナー デプロイの関連成果物を格納および管理するために使用されるマネージド コンテナー レジストリ サービスです。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな障害や問題に対するコンテナー レジストリの回復性を高める方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Container Registry サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
信頼性のための運用環境のデプロイに関する推奨事項
運用環境のワークロードの場合は、次のアクションを実行することをおすすめします。
Container Registry の Premium レベルを使用すると、最も包括的な信頼性機能を利用できます。 Premium レベルでは、運用コンテナーのワークロードに不可欠な、より高いパフォーマンス制限、強化されたセキュリティ機能、高度な機能も提供されます。 サービス レベルと機能の詳細については、「Container Registry のサービス レベル」をご覧ください。
可用性ゾーンをサポートするリージョンに Container Registry をプロビジョニングします。
複数リージョンのシナリオでは、特定の地理的要件とコンプライアンス要件に基づいて、レジストリを複数のリージョンに分散するように geo レプリケーションを構成します。
信頼性アーキテクチャの概要
Container Registry は、高可用性とデータ持続性を提供するために、分散 Azure インフラストラクチャ上に構築されています。 このサービスは、信頼性を確保するために連携するいくつかの主要なコンポーネントで構成されています。 次の図は、コア サービス アーキテクチャを示しています。
コントロール プレーンは、レジストリ構成、認証構成、レプリケーション ポリシーのホーム リージョンの一元管理コンポーネントです。
データ プレーンは、リージョンと可用性ゾーン間でコンテナー イメージのプッシュ操作とプル操作を処理する分散サービスです。
ストレージ レイヤーは、コンテナー イメージと成果物を保持する、コンテンツアドレス指定可能な Azure Storage ソリューションです。 これには、自動重複除去、保存時の暗号化、組み込みのレプリケーションが含まれます。
Microsoft は、次の種類のメンテナンスを含む、基になる Container Registry インフラストラクチャの管理を担当します。
レジストリ管理のためのコントロール プレーンのメンテナンス
リージョンと可用性ゾーン間でのコンテナー イメージ操作のためのデータ プレーンのメンテナンス
お客様は、次のアクションに責任を負います。
アプリケーション レベルの回復性: コンテナー アプリケーションとオーケストレーション プラットフォームに、適切な再試行ロジックとフェールオーバー処理を実装します。
ゾーンの回復性の構成: コンテナー レジストリが、 可用性ゾーンをサポートするリージョンにデプロイされていることを確認します。
geo レプリケーションの構成: 地理的な分散、コンプライアンス、パフォーマンスの要件に基づいて、geo レプリケーションに適したリージョンを選択します。
Container Registry では、コンテナーのビルドとメンテナンス操作を自動化するのに役立つタスクもサポートされています。 タスクは Microsoft が管理するコンピューティング インフラストラクチャで実行され、手動、イベントベース、またはスケジュールされたトリガーをサポートします。 詳細については、「Container Registry タスクを使用してコンテナー イメージのビルドとメンテナンスを自動化する」をご覧ください。
Note
Container Registry は、クラウドベースの Container Registry と同期するオンプレミスまたはリモート レプリカである接続されたレジストリをサポートしています。 接続されたレジストリを使用する場合は、信頼性の要件を満たすようにレジストリを構成する必要があります。 接続されているレジストリは、この記事の範囲外です。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが一時的な障害に対処できることが重要です。これは通常、影響を受けた要求を再試行することで対処します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Container Registry は一時的な障害を内部で複数のメカニズムを用いて処理します。 このサービスは、レジストリ操作の自動再試行ロジックを実装し、効率的なリソース使用のために接続プールを維持します。 Container Registry の操作はべき等になるように設計されており、プッシュおよびプル操作を安全に再試行できます。 タスクは、多くの種類の操作を実行する際に、一時的な障害を自動的に処理します。
Container Registry を使用するクライアント アプリケーションの場合は、レジストリ操作を実行するときに、指数バックオフで適切な再試行ポリシーを実装します。 公式の Docker クライアントまたは Container Registry SDK を使用してください。これらには、一般的な一時的な障害に対応するための再試行メカニズムが組み込まれています。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
ゾーン冗長性は、リージョン内の複数の可用性ゾーンにレジストリ データと操作を分散することで、単一ゾーンの障害からコンテナー レジストリを保護します。 コンテナー イメージのプルおよびプッシュ操作は、正常なゾーンへの自動フェールオーバーを使用して、ゾーンの停止中も引き続き機能します。
ゾーン冗長は、可用性ゾーンをサポートするリージョン内のすべてのレジストリに対して既定で有効になっています。これにより、リソースの回復性は自動的に向上しており、追加コストはかかりません。 この拡張機能は、Basic と Standard を含むすべてのサービス レベルに適用され、新規レジストリと既存のレジストリの両方に適用されています。
Important
Azure portal やその他のツールでは、ゾーン冗長の更新がまだ正確に反映されていない場合があります。
レジストリの構成の zoneRedundancy プロパティは引き続き falseとして表示されますが、サポートされているリージョン内のすべてのレジストリでゾーン冗長性はアクティブになっています。
この既定の動作をより透過的に反映するように、ポータルと API サーフェスを積極的に更新しています。 以前に有効にしたすべての機能は、引き続き想定のとおりに機能します。
Considerations
- リージョンのサポート: ゾーン冗長レジストリは、 可用性ゾーンをサポートする任意のリージョンにデプロイできます。 レジストリが可用性ゾーンをサポートしていないリージョンにある場合は、ゾーン冗長にするには、可用性ゾーンをサポートするリージョンに新しいレジストリを作成する必要があります。 次に、 転送パイプラインを作成 するか、コンテナー イメージを インポートして、コンテナー イメージを移行する必要があります。
Considerations
用事： 現在、Container Registry タスクは可用性ゾーンをサポートしていません。 ゾーン冗長はレジストリ サービス自体に適用されますが、タスクやその操作には適用されません。
geo レプリケーション: レジストリで geo レプリケーションが使用されている場合、可用性ゾーンを持つリージョンで作成されたすべてのレプリカは、自動的にゾーン冗長になります。
Cost
ゾーンの冗長性は、追加料金なしでコンテナー レジストリに含まれます。
可用性ゾーンのサポートを設定する
ゾーン冗長レジストリを作成します。 サポートされているリージョンにレジストリを作成すると、自動的にゾーン冗長になります。 新しいレジストリの作成の詳細については、「 コンテナー レジストリでのゾーン冗長レジストリの作成」を参照してください。
既存のレジストリでゾーン冗長を有効にします。 可用性ゾーンがあるリージョンにあるレジストリは、自動的にゾーン冗長になります。 ゾーン冗長を有効にする必要はありません。
ゾーン冗長を無効にします。 ゾーン冗長を無効にすることはできません。
すべてのゾーンが正常な場合の動作
このセクションでは、Container Registry リソースがゾーン冗長用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: Container Registry では、内部ルーティング機能を使用して、リージョン内のすべての可用性ゾーンにデータ プレーン操作を自動的に分散します。 レジストリ サービスは、外部ロード バランサーを必要とせずに、正常なゾーンに要求を自動的にルーティングします。
ゾーン間のデータ レプリケーション: コンテナー イメージ、マニフェスト、メタデータなどのレジストリ データは、複数の可用性ゾーン間で非同期的にレプリケートされます。 高可用性とデータ持続性を維持するために、変更はゾーン間で迅速にレプリケートされます。 レプリケーションは非同期ですが、通常は数分以内に完了し、すべてのゾーンはレプリケーション中に読み取り操作と書き込み操作に使用できます。
ゾーン障害時の動作
このセクションでは、Container Registry リソースがゾーン冗長用に構成されていて、可用性ゾーンが停止した場合に想定される内容について説明します。
ゾーンが使用できなくなった場合、Container Registry はフェールオーバー プロセスを自動的に処理し、レジストリ操作への影響を最小限に抑えます。
検出と応答: Container Registry プラットフォームは、可用性ゾーンの障害を自動的に検出し、応答を開始します。 サービスは、残りの正常なゾーンにトラフィックを自動的にルーティングします。 ゾーンのフェールオーバーを開始するために手動による介入は必要ありません。
通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
Azure Monitor でレジストリの可用性メトリックを監視することもできます。
アクティブな要求: 可用性ゾーンが使用できなくなると、障害のある可用性ゾーン内のリソースに接続されている進行中のすべての要求は終了されます。 再試行する必要があります。
予想されるデータ損失: 障害のあるゾーンで最近行われた書き込みはすべて、他のリージョンにレプリケートされない可能性があり、ゾーンが復旧するまで失われる可能性があります。 データ損失は通常 15 分未満であると想定されていますが、それが保証されているわけではありません。
予想されるダウンタイム: トラフィックが正常なゾーンにリダイレクトされるため、自動フェールオーバー中にわずかなダウンタイムが発生する可能性があります。 このダウンタイムは、ほとんどのレジストリ操作において通常数秒程度です。 アプリケーションに対するゾーン フェールオーバーの影響を最小限に抑えるために、一時的な障害処理のベスト プラクティスに従うことをおすすめします。
トラフィックの再ルーティング: プラットフォームは、構成を変更することなく、トラフィックを正常なゾーンに自動的に再ルーティングします。
ゾーンの回復
影響を受ける可用性ゾーンが復旧すると、Container Registry は、復旧されたゾーンを含むすべての使用可能なゾーンに操作を自動的に分散します。 このサービスは、手動による介入やサービス中断を引き起こすことなく、トラフィックとデータ分散を再調整します。
ゾーンエラーのテスト
Container Registry プラットフォームは、ゾーン冗長レジストリのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
リージョン全体の障害に対する回復性
Container Registry では、レジストリが Premium レベルを使用する場合に、geo レプリケーションを通じてネイティブ マルチリージョンのサポートが提供されます。 geo レプリケーションでは、選択した複数のリージョンにレジストリ レプリカが作成されます。 レジストリ リソースをデプロイするリージョンは、ホーム リージョンと呼ばれます。
Geoレプリケーションにより、地域障害に対する回復性が確保されます。 レジストリが geo レプリケートされ、リージョンの障害が発生した場合、レジストリ データは、選択した他のリージョンから引き続き使用できます。 geo レプリケーションを有効にしない場合、リージョンの停止中にデータが使用できなくなる可能性があります。
geo レプリケーションを使用して、これらのリージョン内のコンテナー イメージへのローカル アクセスを取得し、グローバル分散アプリケーションの待機時間を短縮することもできます。
Container Registry をデプロイして geo レプリケーションを有効にすると、Microsoft は Azure Traffic Manager を使用してレプリカ間でデータ プレーン要求を分散し、リージョン レプリカが使用できない場合はレプリカ間で自動的にフェールオーバーします。
Container Registry の geo レプリケーションは、Azure のペアになっているリージョンには依存しません。 特定の地理的、パフォーマンス、コンプライアンスの要件に基づいて、レプリケーション用に任意の組み合わせの Azure リージョンを選択できます。 geo レプリケートされた各レジストリは、レジストリ エンドポイントとして機能します。 イメージのプッシュ、プル、管理タスクを含む、ほとんどのレジストリ操作をサポートします。
このセクションでは、信頼性に関連する geo レプリケーションに関する情報を要約します。 詳細については、「Container Registry の geo レプリケーション」をご覧ください。
リージョンのサポート
geo レプリケーションは、Premium レベルがサポートされているすべての Azure リージョンで使用できます。 Azure がそれらのリージョンをペアにしているかどうかに関係なく、リージョンの任意の組み合わせにレプリケートできます。
Requirements
geo レプリケーションを有効にするには、Premium レベルを使用する必要があります。
Considerations
ゾーン冗長レプリカ: 可用性ゾーンを持つリージョンに作成するすべてのレプリカは、自動的にゾーン冗長になります。
コントロール プレーン: コントロール プレーンは、ホームリージョンで実行されます。 ホーム リージョンが使用できない場合、コントロール プレーン操作は使用できず、レジストリの構成を変更できない可能性があります。
タスク: 現在、Container Registry タスクは geo レプリカをサポートしていません。 タスクは常にホーム リージョンで実行されます。 ホーム リージョンが使用できない場合、タスクは実行されません。
Cost
ジオレプリケーションされた各リージョンは、それぞれのリージョンのプレミアムレベルの価格に従って個別に課金されます。 エグレス料金は、初期レプリケーションと進行中の同期中のリージョン間のデータ転送にも適用されます。
複数リージョンのサポートを構成する
geo レプリケーションは、レジストリの作成時に構成することも、既存の Premium レジストリに追加することもできます。 geo レプリケーションは、Azure portal、Azure CLI、Azure PowerShell、または Azure Resource Manager テンプレートを使用して構成できます。
geo レプリケートされたレジストリを作成します。 追加のリージョンを指定して、レジストリの作成後に geo レプリケーションを構成します。
既存のレジストリで geo レプリケーションを有効にします。 geo レプリケーション機能を有効にするには、既存の Basic レベルまたは Standard レベルのレジストリを Premium レベルにアップグレードします。 レプリケーション リージョンはいつでも変更できます。 詳細については、「geo レプリケーションの構成」をご覧ください。
geo レプリケーションを無効にします。 Azure portal またはコマンド ライン ツールを使用して、個々のリージョン レプリカを削除します。 ホーム リージョン レジストリを削除することはできません。
すべてのリージョンが正常な場合の動作
このセクションでは、レジストリが geo レプリケーション用に構成され、すべてのリージョンが運用可能な場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: Container Registry はアクティブ-アクティブ構成で動作し、各リージョン エンドポイントは、読み取りと書き込みを含め、すべてのデータ プレーン操作を個別に処理できます。 コンテナーのプッシュ操作やプル操作などのデータ プレーン操作は、パフォーマンスベースの基準で Traffic Manager を使用して自動的にルーティングされ、パフォーマンスに最適なリージョン エンドポイントを決定します。
リージョン間のデータ レプリケーション: geo レプリケーションは、最終的な整合性を持つ非同期レプリケーションを使用して、構成されているすべてのリージョン間でコンテナー イメージと成果物を自動的に同期します。 このサービスでは、コンテンツアドレス指定可能ストレージを使用して、一意のイメージ レイヤーのみを効率的にレプリケートします。 この方法により、帯域幅の使用量とレプリケーション時間が最小限に抑えられます。 読み取りと書き込みの操作は、geo レプリケートされたすべてのリージョンで機能します。 任意のリージョンで行われた変更は、他のすべてのリージョンにレプリケートされます。
通常、レプリケーションは変更から数分以内に完了します。 ただし、データ レプリケーションのタイミングは保証されません。 大規模なコンテナー イメージまたは頻度の高い更新は、すべてのリージョンでレプリケートするのに時間がかかる場合があります。
リージョン障害時の動作
このセクションでは、レジストリが geo レプリケーション用に構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
リージョンが使用できなくなった場合、コンテナー操作では引き続き代替リージョン エンドポイントを使用できます。
検出と応答: Container Registry は、各リージョン レプリカの正常性を監視し、トラフィックを別のリージョンにリダイレクトする役割を担います。
通知： リージョンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
また、Azure Monitor で各リージョン エンドポイントのレジストリ可用性メトリックを監視することもできます。
アクティブな要求: 現在、使用できないリージョンに対して実行中のアクティブな要求は失敗し、正常なリージョンにリダイレクトされるよう再試行する必要があります。
予想されるデータ損失: 障害のあるリージョンで最近行われた書き込みはすべて、他のリージョンにレプリケートされない可能性があります。 この障害は、リージョンが復旧するまで失われる可能性があることを意味します。 通常、データ損失は 15 分未満になると予想されますが、これは保証されません。
予想されるダウンタイム: データ プレーン操作の場合、フェールオーバーが完了する間、データ プレーン操作に少量のダウンタイムが予想されます。通常は 1 - 2 分かかります。
ホーム リージョンが使用できない場合、コントロール プレーン操作はリージョンが復旧するまで使用できません。
トラフィックの再ルーティング: リージョンが使用できなくなった場合、コンテナー操作は正常なリージョン内の別のレプリカに自動的にルーティングされます。 クライアントは、レジストリと対話するエンドポイントを変更する必要はありません。 Microsoft は、ルーティング、フェールオーバー、フェールバックを自動的に処理します。
リージョンの回復
リージョンが復旧すると、Traffic Manager ルーティングを通じて、そのリージョン エンドポイントのデータ プレーン操作が自動的に再開されます。 サービスは、最終的な整合性を持つ非同期レプリケーションを使用して、停止中に発生した変更を同期します。
リージョン障害のテスト
レジストリに関連付けられているいずれかのリージョンの障害をシミュレートすることはできませんが、リージョン間でフェールオーバーするアプリケーションの機能をテストすることはできます。 リージョンのフェールオーバーをシミュレートするには、geo レプリカを一時的に無効にして、Traffic Manager ルーティングから削除します。 その後、実際にリージョンの停止が発生することなく、コンテナー操作が別のリージョンに正常にフェールオーバーされたことを確認できます。 詳細については、「レプリケーションへのルーティングを一時的に無効にする」をご覧ください。
レプリカを再度有効にすると、Traffic Manager は、再有効化されたレプリカへのトラフィックのルーティングを再開します。 また、メタデータとイメージは、再有効化されたレプリカに対して最終的な整合性で同期され、すべてのリージョンでデータの整合性が確保されます。
バックアップと復元
Container Registry では、コンテナー イメージと成果物をレジストリから外部ストレージまたは代替レジストリにエクスポートできます。 Container Registry のインポートとエクスポートの機能または標準の Docker コマンドを使用して、ディザスター リカバリー シナリオ用の重要なコンテナー イメージのコピーを作成します。
ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。