Azure App Configuration は 、アプリケーション構成設定と機能フラグを一元的に格納および管理し、アプリケーション内に直接埋め込まれた構成ファイルを置き換えます。 この方法により、動的な更新、構成値のバージョン管理、および構成変更の履歴追跡が時間の経過と同時に可能になります。 アプリケーションの動作は実行時の構成データへのアクセスに直接依存する可能性があるため、App Configuration の可用性と信頼性は重要な考慮事項です。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、Azure App Configuration の信頼性アーキテクチャについて説明し、一時的な障害、可用性ゾーンの障害、リージョンの停止中にサービスを引き続き使用できるように設計されている方法について説明します。
信頼性のための運用環境のデプロイに関する推奨事項
App Configuration のほとんどの運用環境のデプロイでは、次の推奨事項を考慮してください。
- Sku： Standard または Premium SKU を使用します。
- 論理的な削除と消去の保護: 論理的な削除と消去の保護を有効にして、データの削除から保護します。
- ミッション クリティカルなシナリオの場合: Premium SKU を使用し、含まれているレプリカを構成して複数のリージョン間のレプリケーションを有効にして、リージョンの停止に対する高可用性と回復性を向上させます。
運用環境のワークロードに推奨されるプラクティスと構成の一覧については、「 回復性の高いアプリケーションの構築」を参照してください。
信頼性アーキテクチャの概要
App Configuration をデプロイするときは、ストアをデプロイ します。 ストアには、 キーと値、 機能フラグなど、アプリケーションで使用できるさまざまな種類の設定が含まれています。 このサービスには、環境間で構成変更を整理、セキュリティ保護、バージョン管理、および安全にロールアウトするための組み込み機能も含まれています。 詳細については、「Azure App Configuration とは」を参照してください。
App Configuration はフル マネージド サービスです。 Microsoft は、設定の保存と管理、およびサービスのメンテナンスの実行を担当します。
Azure App Configuration に接続するクライアント アプリケーションを構築する場合は、必要に応じて、 Azure Front Door (プレビュー) で App Configuration を使用 して、キャッシュとグローバル トラフィック高速化を有効にすることができます。 この構成では、geo レプリケーションに関するその他の考慮事項があり、このことは適切な箇所でこの記事全体を通して説明されています。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Azure App Configuration を使用する場合は、特に重要なコード パス内で、構成アクセスに対する一時的な障害の影響を最小限に抑えるために、次のベスト プラクティスを検討してください。
- 構成プロバイダー: 他の多くの回復性機能と共に再試行とキャッシュ機能が組み込まれている App Configuration 構成プロバイダーを使用します。
- Azure SDK: アプリケーションが書き込み要求を送信する必要がある場合は、App Configuration SDK を使用します。 SDK は、HTTP 状態コード 429 応答とその他の一時的なエラーで自動的に再試行します。
-
再試行ロジック: App Configuration Providers または SDK を使用できない場合は、カスタム クライアントに再試行ロジックを含めます。 応答の
retry-after-msヘッダーは、要求を再試行する前に推奨される待機時間をミリ秒単位で提供します。 - キャッシュ： 可能な限りメモリ内のキャッシュ設定を使用して、ストアへの直接要求を減らします。
その他のアプリケーション構成ガイダンスについては、 Azure App Configuration に関する FAQ を参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
App Configuration では、可用性ゾーンを サポートするリージョンでゾーンの冗長性が自動的に提供されます。 この冗長性により、特定の構成を必要とせずに、リージョン内で高可用性を実現できます。
可用性ゾーンが使用できなくなった場合、App Configuration は、高可用性を確保するために、要求を他の正常な可用性ゾーンに自動的にリダイレクトします。
Requirements
リージョンのサポート: 次のリージョンにデプロイされたストアは、自動的にゾーン冗長になります。
| 南北アメリカ | ヨーロッパ | 中東 | Africa | アジア太平洋 |
|---|---|---|---|---|
| ブラジル南部 | フランス中部 | イスラエル中部 | オーストラリア東部 | |
| カナダ中部 | ドイツ中西部 | カタール中部 | インド中部 | |
| 米国中部 | イタリア北部 | アラブ首長国連邦北部 | 中国北部 3 | |
| 米国東部 | 北ヨーロッパ | 東アジア | ||
| 米国東部 2 | ノルウェー東部 | 東日本 | ||
| メキシコ中部 | ポーランド中部 | 韓国中部 | ||
| 米国中南部 | スペイン中部 | 東南アジア | ||
| US Gov バージニア | スウェーデン中部 | |||
| 米国西部 2 | スイス北部 | |||
| 米国西部 3 | 英国南部 | |||
| 西ヨーロッパ |
費用
Azure App Configuration のゾーン冗長性に対する追加コストは発生しません。
可用性ゾーンのサポートを設定する
Microsoft は、可用性ゾーンをサポートするリージョンにあるストアの ゾーン冗長を自動的に有効にします。
App Configuration によって可用性ゾーンのサポートが既存のリージョンに追加される場合、可用性ゾーンのサポートの恩恵を受けるために何もする必要はありません。 ストアは、リージョン内の App Configuration ストアで利用可能になった可用性ゾーンのサポートの恩恵を受けます。
すべてのゾーンが正常な場合の動作
ストアがゾーンの冗長性をサポートするリージョンにあり、すべての可用性ゾーンが動作している場合は、次の動作が期待できます。
ゾーン間操作: App Configuration は、可用性ゾーン間のトラフィック ルーティングを自動的に管理します。 通常の操作では、ゾーン間で要求が透過的に分散されます。
ゾーン間データ レプリケーション: ゾーンをサポートするリージョンでは、App Configuration は可用性ゾーン間でデータを同期的にレプリケートします。 このレプリケーションにより、ゾーンが使用できなくなった場合でも、設定に一貫性があり、使用可能な状態が維持されます。
ゾーン障害時の動作
このセクションでは、ゾーンの冗長性をサポートするリージョンにストアがあり、可用性ゾーンが使用できない場合に想定される内容について説明します。
- 検出と応答: App Configuration サービスは、ゾーンの障害を検出し、それらに自動的に応答します。 ゾーン障害時にアクションを実行する必要はありません。
- 通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: ゾーン障害時に、影響を受けるゾーンが処理中の要求の処理に失敗する可能性があり、クライアント アプリケーションは要求を再試行する必要があります。 クライアント アプリケーションは、ゾーン障害が発生した場合に要求を再試行できるように、 一時的な障害処理プラクティス に従う必要があります。
予想されるデータ損失: ゾーン間の同期レプリケーションにより、ゾーン障害時にデータ損失は発生しません。
予想されるダウンタイム: ダウンタイムは発生しません。
再 分配： App Configuration は、影響を受けるゾーンから正常なゾーンにトラフィックを自動的に再ルーティングします。顧客の介入は必要ありません。
ゾーンの回復
以前利用できなかったゾーンが復旧すると、App Configuration はすべての可用性ゾーンで通常の操作を自動的に復元します。 ゾーン障害から復旧するためのアクションを実行する必要はありません。
ゾーンエラーのテスト
Azure App Configuration プラットフォームは、ゾーン冗長ストアのトラフィック ルーティング、フェールオーバー、ゾーン回復を管理します。 このプロセスは Microsoft によって完全に管理されているため、可用性ゾーンの障害プロセスを検証する必要はありません。
リージョン全体の障害に対する回復性
Azure App Configuration には、リージョンの停止時の回復性をサポートするためのネイティブ geo レプリケーション機能が用意されています。 geo レプリケーションを使用すると、構成データをマネージド サービス機能としてリージョン間でレプリケートできます。
ジオレプリケーション
geo レプリケーションを使用すると、複数の Azure リージョン間でストアをレプリケートできます。 各ストアは、異なるリージョンに複数の レプリカ を持つことができます。 元のストアもレプリカです。 この機能は、リージョン全体の中断からアプリケーションを保護するのに役立ちます。
Requirements
リージョンのサポート: リージョンが Azure のペアになっているリージョンでない場合でも、Azure App Configuration でサポートされている任意の Azure リージョンにレプリカを作成できます。
層： geo レプリケーションを有効にするには、構成ストアでサポートされているレベルを使用する必要があります。 詳細については、「 geo レプリケーションを有効にする」を参照してください。
考慮事項
geo レプリケーションを有効にする場合は、次の要因を考慮してください。
ゾーン冗長レプリカ: App Configuration が可用性ゾーンをサポートしているリージョンに作成したレプリカは、自動的にゾーン冗長になります。
Azure Front Door: Azure Front Door で geo 冗長構成の配信を有効にするには、配信元グループ内の配信元として App Configuration レプリカを構成します。 正しい配信元の構成により、Azure Front Door では、リージョン間の正常性ベースのルーティング、負荷分散、自動フェールオーバーを管理できます。 詳細については、「 配信元へのトラフィック ルーティング方法」を参照してください。
費用
地理的にレプリケートされた各リージョンは、それぞれの層とリージョンの価格に応じて個別に課金されます。 リージョン間レプリケーションには、データ エグレス料金は適用されません。 価格の詳細については、 Azure App Configuration の価格に関するページを参照してください。
複数リージョンのサポートを構成する
新しく作成された構成ストアのレプリケーションを設定するには、「 geo レプリケーションを有効にする」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、geo レプリケーション用に App Configuration ストアを構成し、すべてのリージョンが運用可能な場合に想定される内容について説明します。
ゾーン間操作: 各レプリカは個別にアドレス指定可能であり、独自の DNS 名を持ちます。 すべてのレプリカは、読み取り操作と書き込み操作の両方を受け入れます。
Azure App Configuration では、リージョン間でトラフィックが自動的にルーティングされることはありません。 App Configuration 構成プロバイダーを使用する場合、アプリケーションは必要に応じて自動レプリカ検出を使用できます。 または、レプリカの優先順位付けされた一覧を指定し、App Configuration によって最初の正常なレプリカが選択されます。 これにより、アプリケーションで使用するレプリカを制御できます。
注
Azure Front Door を使用する場合、トラフィック ルーティングの動作は異なります。 詳細については、「 フェールオーバーと負荷分散」を参照してください。
ゾーン間データ レプリケーション: データは非同期的にレプリケートされ、最終的には一貫性があります。 Azure Monitor のレプリケーション待機時間メトリックを使用して、レプリカ間の現在のレプリケーション待機時間を監視できます。
リージョン障害時の動作
このセクションでは、geo レプリケーション用に App Configuration ストアを構成し、いずれかのレプリカ リージョンで停止が発生した場合に想定される内容について説明します。
検出と応答: Microsoft は、リージョンまたはレプリカの障害を検出し、復旧プロセスを開始する責任を負います。
App Configuration 構成プロバイダーを使用し、レプリカの自動検出または複数のレプリカの一覧を使用して実行すると、アプリケーションは自動的に別の正常なレプリカにフェールオーバーします。
App Configuration プロバイダーを使用しない場合は、アプリケーションを正常なレプリカに切り替える必要があります。
通知： リージョンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: リージョン内のレプリカに対するアクティブな要求が削除される可能性があります。 クライアント アプリケーションは、別のレプリカに対して要求を再試行する必要があります。
予想されるデータ損失: レプリカが失敗した場合、そのレプリカで行われた最近の変更がまだ他のレプリカにレプリケートされていない可能性があります。 これらの変更は、レプリカが復旧するまで使用できなくなります。 データ損失の可能性を見積もるために、 Azure Monitor でレプリケーション待機時間メトリックを監視します。
予想されるダウンタイム: レプリカが使用できなくなった場合は、そのリージョンが復旧するまでオフラインのままです。 他のレプリカは引き続き要求を処理します。 障害を検出し、正常なレプリカに切り替えると、アプリケーションで短時間のダウンタイムが発生する可能性があります。 期間は、各アプリケーションがこの検出とフェールオーバーを実行する速度によって異なります。
再 分配： 障害が発生した場合、アプリケーションは正常なレプリカにトラフィックをルーティングする必要があります。
App Configuration 構成プロバイダーを使用する場合、プロバイダーはレプリカの選択とフェールオーバーを自動的に処理します。
Azure Front Door をデータ ストアの前に配置し、 フェールオーバーの配信元として複数のレプリカを含む配信元グループを構成すると、Azure Front Door は正常なレプリカに要求を自動的に再ルーティングします。
リージョンの復旧
リージョンが復旧すると、App Configuration は、ユーザーの介入なしにレプリカを他のレプリカと同期して戻します。
復旧されたリージョン インスタンスにトラフィックをルーティングするようにアプリケーションを再構成する必要があります。 App Configuration プロバイダーを使用するアプリケーションは、レプリカの使用を自動的に再開します。
リージョン障害のテスト
現時点では、App Configuration でレプリカ フェールオーバーを直接シミュレートすることはできません。 ただし、アプリケーションはレプリカの選択を制御するため、レプリカを切り替える必要がある状態にアプリケーションを強制することで、フェールオーバー動作をテストできます。
アプリケーションのレプリカ フェールオーバー動作を検証するために、非運用環境で制御された接続エラーを導入し、アプリケーションがどのように応答するかを観察できます。
1 つの方法は、ローカル コンピューターまたは管理アクセス権がある別の環境を使用することです。 次の手順に従います。
Azure SDK の詳細ログを有効にします。 .NET では、
AzureEventSourceListenerクラスを使用してロガーを構成します。 詳細については、「 チュートリアル: .NET アプリで動的構成を使用する - ログ記録と監視」を参照してください。App Configuration ストアへの要求が、
hosts(localhost) など、受信できない IP アドレスにルーティングされるように、127.0.0.1ファイルを手動で構成します。Warnung
この手順により、コンピューターから App Configuration ストアへのアクセスが効果的にブロックされます。 非運用環境でのみ、次の手順に従います。
次のようなメッセージのログを監視します。
[Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh: Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.このメッセージは、アプリケーションが正常にフェールオーバーしてストアの別のレプリカを使用したことを示します。
テストが完了したら、
hostsファイルへの変更を元に戻します。
バックアップと復元
Azure App Configuration を使用すると、ストアから 構成データをエクスポート し、より広範なバックアップ戦略の一部として使用できます。
ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。
誤削除に対する回復性
App Configuration には、偶発的または悪意のある削除を防ぐための 2 つの重要な回復機能が用意されています。
論理的な削除: 論理的な削除を有効にすると、構成可能な保持期間中に削除されたストアと設定を回復できます。 アプリ構成リソースのごみ箱のようなソフト削除を考えてください。
消去保護: 消去保護を有効にすると、保持期間が経過するまでストアとその設定が完全に削除されないようにします。 このセーフガードにより、悪意のあるアクターが設定を完全に破棄できなくなります。
運用環境では両方の機能を使用します。 詳細については、「 論理的な削除と消去の保護」を参照してください。
サービス メンテナンスに対する回復性
Microsoft は、サービスの更新やその他のメンテナンスを定期的に実行します。 サービスはこれらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
構成の問題に対する回復性
構成の変更が正しくないか、誤って行うと、アプリケーションのダウンタイムが発生する可能性があります。 構成スナップショットを使用して、構成に対する変更を安全にロールアウトします。 構成の変更に従ってアプリケーションの正常性を監視し、変更によって問題が発生した場合は、最新の正常な構成スナップショットに戻します。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。