この記事では、Azure App Configuration を使用する際の一般的なパターンとベスト プラクティスについて説明します。
キーのグループ化
App Configuration には、キーを整理するために、次の 2 つの方法が用意されています。
- キー プレフィックス
- ラベル
どちらか一方または両方のオプションを使用して、キーをグループ化できます。
"キー プレフィックス" は、キーの先頭部分です。 キー名に同じプレフィックスを使用することによって、一連のキーを論理的にグループ化することができます。 プレフィックスに、URL パスのように区切り記号 (/ など) で接続した複数の構成要素を含めることで、名前空間を作成できます。 さまざまなアプリケーションとマイクロサービスに使用するキーを 1 つの App Configuration ストアに保管する際に、このような階層構造が役立ちます。
キーとは、対応する設定の値を取得するために、アプリケーション コードから参照するものであるということに注意してください。 キーは変更しないでください。変更した場合、その都度、コードを修正する必要があります。
"ラベル" はキーの属性です。 同じキーの別形を作成するために使用されます。 たとえばラベルは、1 つのキーの複数のバージョンに割り当てることができます。 バージョンとしては、版、環境、その他のコンテキスト情報が考えられます。 アプリケーションからは、別のラベルを指定して、まったく異なるキーと値のセットを要求することができます。 その結果、すべてのキー参照は、コード内では変更されないままになります。
キーと値の合成
App Configuration は、そこに格納されているすべてのキーを独立したエンティティとして扱います。 App Configuration では、キーの階層に基づいて、キー間の関係を推測したりキーと値を継承したりすることはありません。 ただし、アプリケーション コード内の適切な構成スタックとラベルを併用して、キーの複数のまとまりを集約することができます。
1 つ例を見てみましょう。 開発環境ごとに値が異なる Asset1 という設定があるとします。 空のラベルを 1 つと "Development" というラベルを 1 つ持つ "Asset1" というキーを作成します。 1 つ目のラベルには Asset1 の既定の値を設定し、後のラベルには "Development" の特定の値を設定します。
コードでは、最初にラベルなしでキーと値を取得し、次に "Development" ラベルを使用して同じキーと値のセットに対する 2 回目の取得を行います。 2 回目の値の取得を行うと、キーの以前の値は上書きされます。 .NET 構成システムを使用すると、構成データの複数のセットをそれぞれの上に "スタック" することができます。 キーが複数のセットに存在する場合は、そのキーを含む最後のセットが使用されます。 .NET など、最新のプログラミング フレームワークを使用している場合、ネイティブ構成プロバイダーを使用して App Configuration にアクセスすれば、このスタック機能を無料で利用できます。 次のコード スニペットは、.NET アプリケーションにおけるスタック機能の実装方法を示しています。
// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
options.Connect(configuration["connection_string"])
.Select(KeyFilter.Any, LabelFilter.Null)
.Select(KeyFilter.Any, "Development");
});
「ラベルを使用してさまざまな環境でさまざまな構成を有効にする」に、完全な例が挙げられています。
外部データへの参照
App Configuration は、通常は構成ファイルや環境変数に保存する任意の構成データを格納するように設計されています。 ただし、データの種類によっては、他のソースに保存するのが適している場合もあります。 たとえば、シークレット情報は Key Vault に、ファイルは Azure Storage に、メンバーシップ情報は Microsoft Entra グループに、顧客一覧はデータベースに格納するなどです。
それでも、外部データへの参照をキーと値に保存することで、App Configuration を利用することができます。 コンテンツ タイプを使用して、各データ ソースを区別できます。 アプリケーションが参照を読み込むとき、ソースに対する必要なアクセス許可があると仮定して、参照されたソースから実際のデータを読み込みます。 外部データの場所を変更した場合は、アプリケーション全体を更新して再デプロイするのではなく、App Configuration の参照を更新するだけで済みます。
App Configuration の Key Vault の参照機能はこのケースの一例です。 これにより、アプリケーションに必要なシークレットを必要に応じて更新しながら、基となるシークレット自体は Key Vault に残すことができます。
App Configuration の準備
アプリ構成ストアには、対応する接続文字列を Azure portal から入手してアクセスできます。 接続文字列は資格情報を含んでいるため、シークレットと見なされます。 これらのシークレットは Azure Key Vault に格納する必要があり、コードはそれらを取得するために Key Vault に対して認証を行う必要があります。
より良いオプションは、Microsoft Entra ID のマネージド ID 機能を使用することです。 マネージド ID を使用すると、App Configuration のエンドポイントの URL さえあれば、App Configuration ストアへのアクセスをブートストラップすることができます。 その URL は、アプリケーション コード (appsettings.json ファイルなど) に埋め込むことができます。 詳細については、「マネージド ID を使用して App Configuration にアクセスする」を参照してください。
Azure Kubernetes Service の App Configuration へのアクセス
Azure Kubernetes Service (AKS) でホストされているワークロードが Azure App Configuration にアクセスするには、次のオプションを使用できます。 これらのオプションは、一般的に Kubernetes にも適用されます。
Azure App Configuration Kubernetes プロバイダーを AKS クラスターに追加します。 Kubernetes プロバイダーは、クラスター内でポッドとして実行されます。 App Configuration ストア内のキー値と Key Vault 参照から ConfigMap とシークレットを構築できます。 ConfigMap とシークレットは、アプリケーション コードを変更することなく、環境変数またはマウントされたファイルとして使用できます。 同じ AKS クラスターで複数のアプリケーションを実行している場合、生成されたすべての ConfigMap とシークレットにアクセスできるため、App Configuration に対する個々の要求が不要になります。 Kubernetes プロバイダーでは、動的な構成の更新もサポートされています。 これは、可能な場合に推奨されるオプションです。
Azure App Configuration プロバイダー ライブラリを使用するようにアプリケーションを更新します。 プロバイダー ライブラリは、ASP.NET、.NET、Java Spring、JavaScript/Node.js、Python など、多くのフレームワークと言語で使用できます。 この方法では、動的な構成や機能管理など、App Configuration の機能にフル アクセスできます。 アプリケーションごとに、どのデータをどの App Configuration ストアからロードするかを詳細に制御できます。
Helm を使用して Kubernetes デプロイと統合する. アプリケーションを更新しない場合、または AKS クラスターに新しいポッドを追加しない場合は、デプロイ経由で Helm を使用して App Configuration から Kubernetes クラスターにデータを取り込むオプションがあります。 このアプローチにより、アプリケーションは Kubernetes 変数とシークレットから構成に引き続きアクセスできます。 アプリケーションに新しい構成変更を組み込む必要があるときはいつでも、Helm アップグレードを実行できます。
App Configuration への App Service または Azure Functions でのアクセス
App Configuration プロバイダーまたは SDK ライブラリを使用して、アプリケーションで App Configuration に直接アクセスします。 この方法では、動的な構成や機能管理など、App Configuration の機能にフル アクセスできます。 App Service または Azure Functions で実行されているアプリケーションは、次のいずれかの方法で App Configuration ストアにアクセスできます。
- App Service または Azure Functions でマネージド ID を有効にし、App Configuration ストアへのアクセス権を付与します。 詳細については、「マネージド ID を使用して App Configuration にアクセスする」を参照してください。
- App Service または Azure Functions の "アプリケーション設定" に App Configuration ストアへの接続文字列を保存します。 セキュリティを強化するには、接続文字列を Key Vault に保存し、App Service または Azure Functions からそれを参照します。
また、"アプリケーション設定" または環境変数として、App Configuration データにアプリケーションからアクセスできるようにすることもできます。 この方法では、アプリケーション コードの変更を回避できます。
- App Service または Azure Functions の "アプリケーション設定" で、App Configuration データへの参照を追加できます。 App Configuration には、キー値のコレクションを参照として一度にエクスポートするツールが用意されています。 詳細については、「App Service と Azure Functions の App Configuration 参照を使用する」を参照してください。
- 参照としてエクスポートのオプションを選択せずに、App Service または Azure Functions の "アプリケーション設定" に App Configuration データをエクスポートします。 App Configuration で新しい変更を行うたびに、その変更をアプリケーションで取得する場合は、データを再度エクスポートします。
App Configuration に対する要求を減らす
App Configuration に過剰な要求があると、調整や超過分料金が発生する可能性があります。 要求の数を減らすには、次のようにします。
更新間隔を大きくします (特に構成値が頻繁に変更されない場合)。
SetRefreshIntervalメソッドを使用して、新しい更新間隔を指定します。個々のキーを監視するのではなく、1 つの "センチネル キー" を監視します。 そのセンチネル キーが変更された場合にのみ、すべての構成を更新します。 例については、「ASP.NET Core アプリで動的な構成を使用する」を参照してください。
Kubernetes クラスターで複数のワークロードを実行していて、それぞれが App Configuration から個別にデータをプルする場合は、App Configuration Kubernetes プロバイダーを使います。 Kubernetes プロバイダーは、App Configuration からデータを取得し、Kubernetes の ConfigMap と Secret として使用できるようにします。 これにより、ワークロードは、App Configuration から個別にデータをプルしなくても、ConfigMap と Secret を使ってデータにアクセスできます。
App Configuration ストアの geo レプリケーションを有効にし、要求を複数のレプリカに分散させます。 たとえば、グローバルにデプロイされたアプリケーションに、各地理的リージョンの異なるレプリカを使用します。 各 App Configuration レプリカには、独自の要求クォータがあります。 このセットアップにより、一時的および地域的な障害に対するスケーラビリティと強化された回復性のモデルが提供されます。
App Configuration への構成データのインポート
App Configuration には、Azure portal または CLI のいずれかを使用して、現在の構成ファイルから構成設定を一括インポートするオプションが用意されています。 また、同じオプションを使用して、関連するストア間などで App Configuration からキーと値をエクスポートすることもできます。 コードとしての構成を採用し、GitHub または Azure DevOps 内で構成を管理している場合は、GitHub Actions または Azure パイプライン インポート タスクを使用して継続的な構成ファイルのインポートを設定することができます。
App Configuration での複数リージョンのデプロイ
アプリケーションが複数のリージョンにデプロイされている場合は、App Configuration ストアの geo レプリケーションを有効にすることをお勧めします。 アプリケーションを主に、アプリケーションのインスタンスがデプロイされているリージョンに一致するレプリカに接続し、他のリージョンのレプリカにフェールオーバーできるようにすることができます。 この設定により、アプリケーションと App Configuration の間の待機時間が最小限に抑えられます。各レプリカに個別の調整クォータが設定されているために負荷が分散され、一時的な障害やリージョンの障害に対するアプリケーションの回復性が向上します。 詳細については、「回復性とディザスター リカバリー 」を参照してください。
高い回復性を備えたアプリケーションの構築
アプリケーションは多くの場合、構成に依存して起動するため、Azure App Configuration の高可用性が重要になります。 回復性を向上させるために、アプリケーションは App Configuration の信頼性機能を活用し、特定の要件に基づいて次の対策を講じることを検討する必要があります。
- Azure 可用性ゾーンのサポートを使用してリージョンでプロビジョニングします。 可用性ゾーンを使用すると、アプリケーションはデータ センターの停止に対して回復力を得ることができます。 App Configuration では、追加料金なしですべての顧客にゾーン冗長性が提供されます。 可用性ゾーンをサポートするリージョンで App Configuration ストアを作成することをおすすめします。 App Configuration で可用性ゾーンのサポートが有効になっているリージョンの一覧を確認できます。
- geo レプリケーションを有効にして、アプリケーションがレプリカ間でフェールオーバーまたは負荷分散できるようにします。 このセットアップにより、一時的な障害や地域的な障害に対するスケーラビリティと強化された回復性のモデルが提供されます。 詳細については、「回復性とディザスター リカバリー 」を参照してください。
- 安全な展開方法 に従って構成をデプロイします。 構成の変更が正しくないか、誤って行われると、アプリケーションのダウンタイムが頻繁に発生する可能性があります。 可能な限り、Azure portal などから運用環境に直接影響を与える構成変更を行わないようにする必要があります。 安全なデプロイ プラクティス (SDP) では、段階的な露出デプロイ モデルを使用して、デプロイによって引き起こされる問題の潜在的な爆発半径を最小限に抑えます。 SDP を採用する場合は、運用環境にデプロイする前に、構成スナップショットを構築してテストできます。 デプロイ中に、アプリケーションのインスタンスを更新して、新しいスナップショットを段階的に取得できます。 問題が検出された場合は、最後に既知の正常 (LKG) スナップショットを再デプロイすることで、変更をロールバックできます。 スナップショットは不変であり、すべてのデプロイ全体にわたる一貫性が保証されます。 動的構成と共にスナップショットを利用できます。 基本的な構成にはスナップショットを使用し、緊急構成のオーバーライドと機能フラグには動的構成を使用します。
- アプリケーションに構成を含めます。 アプリケーションが常に構成のコピーにアクセスできるようにする場合、または App Configuration への実行時の依存関係を完全に回避する場合は、ビルド時またはリリース時に App Configuration から構成をプルし、アプリケーションに含めることができます。 詳細については、App Configuration と CI/CD パイプラインまたはKubernetes デプロイの統合の例を確認してください。
- App Configuration プロバイダーを使用します。 アプリケーションは、ネットワークの問題など、実行時に発生する問題を考慮し、障害に迅速に対応できるため、高い回復性を実現する上で重要な役割を果たしています。 App Configuration プロバイダーには、自動レプリカ検出、レプリカ フェールオーバー、カスタマイズ可能なタイムアウトによるスタートアップ再試行、構成キャッシュ、信頼性の高い構成更新のためのアダプティブ戦略など、さまざまな組み込みの回復性機能が用意されています。 これらの機能を利用するには、App Configuration プロバイダーを使用することを強くおすすめします。 それが不可能な場合は、最高レベルの回復性を実現するために、カスタム ソリューションに同様の機能を実装することを検討する必要があります。
App Configuration でのクライアント アプリケーション
クライアント アプリケーションで App Configuration を使用するときは、2 つの重要な要素を考慮する必要があります。 まず、クライアント アプリケーションで接続文字列を使用する場合、App Configuration ストアのアクセス キーを一般に公開するというリスクを負うことになります。 次に、標準的なスケールのクライアント アプリケーションでも、App Configuration ストアに対する要求が過剰に行われる場合がないとはいえず、それが超過料金や帯域幅調整を招く可能性があります。 帯域幅調整の詳細については、FAQ を参照してください。
これらの問題に対処するために、クライアント アプリケーションと App Configuration ストアとの間にはプロキシサービスを使用することをお勧めします。 プロキシ サービスであれば、認証情報の漏えいというセキュリティの問題を伴うことなく、App Configuration ストアに対する認証を安全に行うことができます。 プロキシ サービスは、いずれかの App Configuration プロバイダー ライブラリを使用して作成できるので、組み込みのキャッシュ機能と更新機能を活用して App Configuration に送信される要求のボリュームを最適化することができます。 App Configuration プロバイダーの使用について詳しくは、クイックスタートとチュートリアルの記事を参照してください。 プロキシ サービスでは、そのキャッシュからクライアント アプリケーションに構成が提供されるので、このセクションで前述した 2 つの問題のリスクを回避することができます。
App Configuration でのマルチテナント アプリケーション
マルチテナント アプリケーションは、アプリケーションの共有インスタンスが複数のお客様またはテナントにサービスを提供するアーキテクチャに基づいて構築されます。 たとえば、ユーザーに個別のアカウントとカスタマイズされたエクスペリエンスを提供するメール サービスがあるとします。 通常、アプリケーションはテナントごとに異なる構成を管理します。 マルチテナント アプリケーションで App Configuration を使用する場合のアーキテクチャ上の考慮事項をいくつか次に示します。
コードとしての構成
コードとしての構成は、ソース管理システム (Git リポジトリなど) で構成ファイルを管理するプラクティスです。 これにより、構成の変更に関する追跡可能性と承認プロセスなどの利点が得られます。 構成をコードとして採用する場合、App Configuration には、ファイル内の構成データを管理し、ビルド、リリース、または CI/CD プロセスの一部としてデプロイするのに役立つツールがあります。 これにより、アプリケーションでは App Configuration ストアから最新のデータにアクセスできます。
- GitHub の場合、GitHub Actions を使用して GitHub リポジトリから App Configuration ストアに構成ファイルをインポートできます
- Azure DevOps では、同期のためにビルドまたはリリース パイプラインに Azure パイプライン タスクである Azure App Configuration インポートを含めることができます。
- CI/CD システムの一部として Azure CLI を使用して、構成ファイルを App Configuration にインポートすることもできます。 詳細については、az appconfig kv import に関するページを参照してください。
このモデルでは、App Configuration にデータをコミットする前に検証とテストの手順を含めることができます。 複数の App Configuration ストアを使用する場合は、段階的にまたはすべて一度に構成データをプッシュすることもできます。