アプリケーション開発者と IT エンジニアにとって、一般的な目標は回復性のあるアプリケーションを構築して実行することです。 回復性は、障害に対応し、引き続き機能するアプリケーションの機能として定義されます。 クラウドでリージョンの障害が発生した場合の回復性を実現するには、最初の手順として、単一障害点を回避するために冗長性を構築します。 この冗長性は、geo レプリケーションを使用して実現できます。
App Configuration geo レプリケーション機能を使用すると、構成ストアを好みのリージョンにレプリケートできます。 新しい 各レプリカ は異なるリージョンに配置され、アプリケーションが要求を送信するための新しいエンドポイントが作成されます。 構成ストアの元のエンドポイントは オリジンと呼ばれます。 配信元を削除することはできませんが、それ以外の場合は任意のレプリカと同様に動作します。
キー値の変更または更新は、任意のレプリカで実行できます。 これらの変更は、最終的な整合性モデルに従って、他のすべてのレプリカと同期されます。
構成ストアをレプリケートすると、次の利点が追加されます。
- Azure の停止に対する回復性が追加されました。 リージョンの障害が発生した場合、レプリカは個別に影響を受けます。 1 つのリージョンで障害が発生した場合、影響を受けないリージョンにあるすべてのレプリカに引き続きアクセスでき、継続的に同期されます。 停止が軽減されると、影響を受けるすべてのレプリカが最新の状態に同期されます。 geo レプリケーションでは、App Configuration の構成プロバイダーを介した自動フェールオーバー機能のみが提供されることに注意してください。 それ以外の場合は、アプリケーションの構成で独自のカスタム フェールオーバー メカニズムを構築して、異なるレプリカ エンドポイントを切り替えて、Azure の停止の影響を軽減することもできます。
- 要求制限の再配布: アプリケーションで使用するレプリカ エンドポイントをコードでカスタマイズして、要求の制限を使い果たさないように要求の負荷を分散させることができます。 たとえば、アプリケーションが複数のリージョンで実行され、1 つのリージョンにのみ要求を送信する場合、App Configuration 要求の制限を使い果たす可能性があります。 この負荷を再配布するには、アプリケーションが実行されているリージョンにレプリカを作成します。 各レプリカには、配信元の要求制限と同じサイズの分離された要求制限があります。 1 つのレプリカで要求制限を使い果たすことは、別のレプリカの要求制限には影響しません。
- 地域区分: 複数のリージョンにアクセスすると、アプリケーションと構成ストアの間の待機時間が短縮され、アプリケーションが最も近いレプリカに要求を送信した場合の要求応答が高速になり、パフォーマンスが向上します。 レプリカ アクセスを指定すると、設定に基づいて異なるリージョン間のデータ ストレージとフローを制限することもできます。
ストアでこの機能を有効にするには、 geo レプリケーションを有効にする方法に関するドキュメントを参照してください。
ユースケースのサンプル
開発者チームは、複数のアプリケーションで構成されるシステムを構築しており、現在、米国西部リージョンに 1 つの Azure App Configuration ストアがあります。 システムの使用は急速に増加しており、スウェーデン中部、米国西部、北ヨーロッパ、東アジアの顧客ニーズを拡大し、顧客のニーズを満たすことを目指しています。 現在、すべてのアプリケーションは米国西部の構成ストアを使用しており、それにより単一障害点が生じています。 米国西部でリージョンの障害が発生し、他のフェールオーバー メカニズムや既定の動作がない場合、システムはお客様が利用できなくなります。 また、現在、すべてのアプリケーションは、1 つの構成ストアの要求制限によって制限されています。 チームがより多くのリージョンにスケーリングするにつれて、この制限は持続できなくなります。
このチームは地理的レプリケーションの恩恵を受けるでしょう。 アプリケーションが実行される各リージョンに、構成ストアのレプリカを作成できます。 その後、すべてのアプリケーションが米国西部に要求を送信するのではなく、同じリージョン内のレプリカに要求を送信できます。 これにより、要求の待ち時間の短縮と負荷分散の向上という 2 つの利点が得られます。 要求の負荷が適切に分散されると、要求クォータの枯渇を回避するのに役立ちます。 さらに、複数のレプリカを用意することで、チームはリージョンの障害が発生した場合にフェールオーバーするようにアプリケーションを構成できます。 たとえば、チームは、スウェーデン中部で実行されているアプリケーションを、そのリージョンから構成をプルするように構成できますが、スウェーデン中部で障害が発生している場合は北ヨーロッパにフォールバックできます。 特定のリージョンで App Configuration を使用できない場合でも、チームのシステムは影響を受けません。
考慮事項
- Geo レプリケーションは、Free レベルと Developer レベルでは使用できません。
- 各レプリカには、 App Configuration の価格ページで説明されているように制限があります。 これらの制限はレプリカごとに分離されます。
- Azure App Configuration では、Azure リージョン内に回復性と可用性の高いストアを作成するための Azure 可用性ゾーンもサポートされています。 レプリカのリージョンに可用性ゾーンのサポートがある場合、レプリカに対して可用性ゾーンのサポートが自動的に含まれます。 リージョン内の冗長性のための可用性ゾーンと、複数のリージョン間の geo レプリケーションの組み合わせにより、構成ストアの可用性とパフォーマンスの両方が向上します。
コストと課金
作成された各レプリカには追加料金が加算されます。 詳細については、「 App Configuration の価格」ページ を参照してください。 たとえば、配信元が Standard レベルの構成ストアで、5 つのレプリカがある場合、システムに対して 6 つの Standard レベル構成ストアのレートが課金されますが、レプリカの分離されたクォータと要求はそれぞれこの料金に含まれます。
モニタリング
geo レプリケーション機能の特性に関する分析情報を提供するために、App Configuration にはレプリケーション 待機時間という名前のメトリックが用意されています。 レプリケーション待機時間メトリックは、データがリージョン間でレプリケートされるまでにかかる時間を示します。
レプリケーション待機時間メトリックとその他の App Configuration メトリックの詳細については、「 監視アプリ構成データ リファレンス」を参照してください。