構成を利用する際には、クライアント アプリケーションとサーバー アプリケーションでは異なる要件があります。 シークレットを格納することはできなく、はるかに大規模な操作を行い、ユーザーは世界中のどこからでもすぐに起動できることを期待しています。 クライアント側のアプリケーション構成の要件を満たすために、Azure App Configuration は Azure Front Door との統合を提供します。 Azure Front Door のエッジベースのコンテンツ配信ネットワークと Azure App Configuration の一元化された構成管理を組み合わせることで、クライアント アプリケーションはどこからでも、高速で信頼性の高い匿名で構成を取得できます。
Azure Front Door を使用した CDN 高速構成の配信
App Configuration を使用すると、開発者は構成設定と機能フラグを定義するための一貫した場所を 1 つ作成できます。 Azure App Configuration と Azure Front Door を統合することで、構成データは Azure App Configuration を通じて一元的に管理され、Azure のコンテンツ配信ネットワークを介してキャッシュおよび配布されます。 このアーキテクチャは、モバイル、デスクトップ、ブラウザーベースのアプリケーションを含むクライアント向けアプリケーションに価値があります。
システム アーキテクチャ
動作方法
- クライアント アプリケーションは、認証なしで Azure Front Door エンドポイントを介して構成を取得するため、クライアント側コードに資格情報を埋め込むというセキュリティ リスクが排除されます。
- Azure Front Door はマネージド ID を使用して、Azure App Configuration で安全に認証します。
- キー値、機能フラグ、またはスナップショットの構成可能なサブセットは、Azure Front Door を介して公開されます。
- エッジ キャッシュを使用すると、高スループットと低待機時間の構成配信が可能になります。
このアーキテクチャにより、カスタム プロキシまたはゲートウェイが不要になりますが、クライアント アプリケーションに安全で効率的な構成配信が提供されます。
開発者のシナリオ
CDN で提供される構成では、さまざまなクライアント アプリケーション シナリオのロックが解除されます。
- UI コンポーネントのクライアント側機能ロールアウト
- 機能フラグを使用した A/B テストまたはターゲット エクスペリエンス
- 構成を使用して AI/LLM モデルのパラメーターと UI の動作を制御する
- 構成を使用して、クライアント側エージェントの動作、安全モード、およびガードレールの設定を動的に制御する
- スナップショット ベースの構成を使用するクライアントの一貫性のある動作
注
この機能は現在、Azure パブリック クラウドでのみ使用できます。
推奨事項と考慮事項
セキュリティ
Azure Front Door を介して公開される構成は、認証なしでパブリックにアクセスできるため、適切なセキュリティ制御が不可欠になります。 意図しない公開から構成データを保護するには、次の戦略を実装します。
専用の App Configuration ストアを使用する
Azure Front Door を介して配信されるクライアント向けの構成には、専用の App Configuration ストアを使用することを検討してください。 このストアには、一般に使用しても安全な非センティティブな設定のみを含める必要があります。 この分離戦略により、構成が誤って公開された場合の潜在的な影響が制限され、機密データが保護されたままになります。
マネージド ID を使用したロール ベースのアクセス制御
Azure Front Door は、システム割り当てマネージド ID またはユーザー割り当てマネージド ID を使用して App Configuration データにアクセスします。 構成データを取得するには、選択した ID に App Configuration Data Reader ロールを割り当てる必要があります。 App Configuration ポータルを使用して Azure Front Door エンドポイントを作成すると、このロールの割り当てが自動的に作成されます。 ロールの割り当ての作成プロセスで問題が発生した場合、ポータルに警告が表示されます。 マネージド ID を App Configuration Data Reader ロールのみに制限し、書き込みアクセス許可を持つロールを割り当てないようにします。
スコープ設定を依頼する
1 つ以上のフィルターを構成して、Azure Front Door を通過できる要求を制御します。 これにより、匿名クライアントは、App Configuration に負荷をかけ、サービスの調整をトリガーする可能性がある、過剰な要求や形式が正しくない要求によって CDN キャッシュをバイパスできなくなります。
キーと値のフィルターを使用してスコープを要求する
アプリケーションの構成要件に正確に一致するように Azure Front Door フィルターを構成します。 アプリケーションが使用する正確なキー パターンのみを公開します。 たとえば、アプリケーションが
"App1:"プレフィックスを持つキーを読み込む場合は、"App1:"のようなより広範なパターンではなく、"App"キーのみを許可するように Azure Front Door ルールを構成します。アプリケーションが機能フラグを読み込む場合は、Keyに
指定し、 Starts with 演算子でフィルターを行います。App Configuration プロバイダー ライブラリを使用していて、アプリケーションが機能フラグのみを読み込む場合は、Azure Front Door ルールに 2 つのキー フィルターを追加する必要があります。1 つはラベルのない
ALLキー用、2 つ目は".appconfig.featureflag/{YOUR-FEATURE-FLAG-PREFIX}"以降のすべてのキーです。 これは、App Configuration プロバイダー ライブラリは、キー値セレクターが指定されていない場合に、ラベルのないすべてのキー値を既定で読み込むためです。
複数の Azure Front Door エンドポイントを介してスコープを要求する
構成要件が異なるアプリケーション用に個別の Azure Front Door エンドポイントを作成します。 各アプリケーションは、1 つのエンドポイントで複数のフィルター 規則を組み合わせるのではなく、正確にスコープ指定されたフィルターを使用して専用エンドポイントに接続します。 この方法では、アプリケーションが互いの構成データにアクセスするのを防ぎ、フィルター管理を簡略化します。
フェールオーバーと負荷分散
クライアント アプリケーションは、App Configuration に直接接続しないため、フェールオーバーと負荷分散のために Azure Front Door に依存します。 自動フェールオーバーと geo 冗長構成の配信を有効にするには、Azure Front Door エンドポイントの配信元として App Configuration レプリカを構成します。 配信元グループが可用性とパフォーマンスを向上させる方法の詳細については、Azure Front Door のルーティング方法に関するページを参照してください。
キャッシュ処理
構成の鮮度と配信元の負荷のバランスを取るために、Azure Front Door キャッシュ期間を構成します。 Azure Front Door はキャッシュ動作を制御します。つまり、App Configuration からの更新は、Front Door キャッシュの有効期限が切れた後にのみアプリケーションによって表示されます。 このキャッシュの有効期限は、アプリが変更を確認する頻度に関係なく、アプリが新しい構成値を監視できるようになるまでに、実質的に最小時間になります。
Azure Front Door キャッシュ TTL を少なくとも 10 分に設定し、アプリケーションの更新間隔を少なくとも 1 分に設定することをお勧めします。 これらの設定では、構成の更新が反映されるまでに最大 11 分かかる場合があります。Azure Front Door 10 分のキャッシュ TTL と、次のアプリケーションの更新まで最大 1 分。
アプリケーションに合った適切な更新間隔の値を選択できます。 キャッシュ期間が短いほど、Azure Front Door 経由でルーティングされる要求の数が増えます。 このモデルは、CDN ベースの配信で予想されるリアルタイムの伝達ではなく、最終的な整合性を提供します。 Azure Front Door を使用したキャッシュの詳細について説明します。
注
Azure Front Door は、コンテンツがキャッシュに格納される期間を保証していません。 コンテンツが頻繁に使用されない場合、コンテンツの有効期限が切れる前に、キャッシュされたコンテンツがエッジ キャッシュから削除される可能性があります。 さらに、App Configuration に到達できない場合、Azure Front Door は、アプリケーションの可用性を維持するために、キャッシュから古いデータを提供し続ける可能性があります。