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