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