Azure App Configuration のベスト プラクティス
この記事では、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 Core 構成システムを使用すると、構成データの複数のセットをそれぞれの上に "スタック" することができます。 キーが複数のセットに存在する場合は、そのキーを含む最後のセットが使用されます。 .NET Core など、最新のプログラミング フレームワークを使用している場合、ネイティブ構成プロバイダーを使用して App Configuration にアクセスすれば、このスタック機能を無料で利用できます。 次のコード スニペットは、.NET Core アプリケーションにおけるスタック機能の実装方法を示しています。
// 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 に、メンバーシップ情報は Azure AD グループに、顧客一覧はデータベースに格納するなどです。
それでも、外部データへの参照をキーと値に保存することで、App Configuration を利用することができます。 コンテンツ タイプを使用して、各データ ソースを区別できます。 アプリケーションが参照を読み込むとき、ソースに対する必要なアクセス許可があると仮定して、参照されたソースから実際のデータを読み込みます。 外部データの場所を変更した場合は、アプリケーション全体を更新して再デプロイするのではなく、App Configuration の参照を更新するだけで済みます。
App Configuration の Key Vault の参照機能はこのケースの一例です。 これにより、アプリケーションに必要なシークレットを必要に応じて更新しながら、基となるシークレット自体は Key Vault に残すことができます。
App Configuration の準備
アプリ構成ストアには、対応する接続文字列を Azure portal から入手してアクセスできます。 接続文字列は資格情報を含んでいるため、シークレットと見なされます。 これらのシークレットは Azure Key Vault に格納する必要があり、コードはそれらを取得するために Key Vault に対して認証を行う必要があります。
より良いオプションは、Azure Active Directory のマネージド ID 機能を使用することです。 マネージド ID を使用すると、App Configuration のエンドポイントの URL さえあれば、App Configuration ストアへのアクセスをブートストラップすることができます。 その URL は、アプリケーション コード (appsettings.json ファイルなど) に埋め込むことができます。 詳細については、「マネージド ID を使用して App Configuration にアクセスする」を参照してください。
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 に過剰な要求があると、調整や超過分料金が発生する可能性があります。 要求の数を減らすには、次のようにします。
更新のタイムアウトを大きくします (特に構成値が頻繁に変更されない場合)。
SetCacheExpirationメソッドを使用して、新しい更新のタイムアウトを指定します。個々のキーを監視するのではなく、1 つの "センチネル キー" を監視します。 そのセンチネル キーが変更された場合にのみ、すべての構成を更新します。 例については、「ASP.NET Core アプリで動的な構成を使用する」を参照してください。
変更を常にポーリングするのではなく、Azure Event Grid を使用して、構成が変更されたときに通知を受信します。 詳しくは、「App Configuration のデータ変更通知に Event Grid を使用する」をご覧ください。
要求を複数の App Configuration ストアに分散させます。 たとえば、グローバルにデプロイされたアプリケーションに、各地理的リージョンの異なるストアを使用します。 各 App Configuration ストアには、独自の要求クォータがあります。 このセットアップにより、スケーラビリティのモデルが提供され、単一障害点を回避できます。
App Configuration への構成データのインポート
App Configuration には、Azure portal または CLI のいずれかを使用して、現在の構成ファイルから構成設定を一括インポートするオプションが用意されています。 また、同じオプションを使用して、関連するストア間などで App Configuration からキーと値をエクスポートすることもできます。 GitHub または Azure DevOps のリポジトリとの継続的な同期を設定する場合は、Microsoft の GitHub Actions または Azure パイプラインのプッシュ タスクを使用できます。これにより、App Configuration を活用しながら、既存のソース管理手法を引き続き使用できます。
App Configuration での複数リージョンのデプロイ
App Configuration はリージョン単位のサービスです。 リージョンごとに構成が異なるアプリケーションでは、これらの構成を 1 つのインスタンスに格納すると、単一障害点が形成される可能性があります。 リージョンごとに 1 つの 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 では、リポジトリに対して App Configuration の同期 GitHub アクションを有効にすることができます。 構成ファイルへの変更は、プル要求がマージされるたびに、自動的に App Configuration に同期されます。
- Azure DevOps では、データ同期のためにビルドまたはリリース パイプラインに Azure パイプライン タスクである Azure App Configuration プッシュを含めることができます。
- CI/CD システムの一部として Azure CLI を使用して、構成ファイルを App Configuration にインポートすることもできます。 詳細については、az appconfig kv import に関するページを参照してください。
このモデルでは、App Configuration にデータをコミットする前に検証とテストの手順を含めることができます。 複数の App Configuration ストアを使用する場合は、段階的にまたはすべて一度に構成データをプッシュすることもできます。