Azure App Configuration のベストプラクティス

2025-05-20

この記事では、Azure App Configuration を使用する際の一般的なパターンとベストプラクティスについて説明します。

キーのグループ化

App Configuration には、キーを整理するために、次の 2 つの方法が用意されています。

キープレフィックス
ラベル

どちらか一方または両方のオプションを使用して、キーをグループ化できます。

キープレフィックスを 使用すると、名前に共通のプレフィックスを使用して関連するキーをグループ化できます。プレフィックスには、階層型名前空間を形成する / や :などの区切り記号で区切られた複数のセグメントを含めることができます。この方法は、1 つの App Configuration ストア内に複数のアプリケーションまたはマイクロサービスの構成キーを格納する場合に便利です。

キーはアプリケーションコードによって直接参照され、対応する値を取得することに注意してください。そのため、コードの変更を回避するために、キーは安定した状態を維持する必要があります。必要に応じて、App Configuration プロバイダーを使用して、実行時にキープレフィックスをトリミングできます。

ラベル を使用すると、異なるバージョンや環境固有の設定など、キーのバリエーションを作成できます。ラベルを割り当てることで、同じキーに対して複数の値を保持できます。アプリケーションでは、適切なラベルを指定することで、異なるキー値のセットを取得し、コード内のキー参照の一貫性を維持できます。

キーと値の合成

App Configuration は、その中に格納されている各キーを独立したエンティティとして扱います。キー間のリレーションシップを推測したり、キー階層に基づいて値を継承したりすることはありません。ただし、アプリケーションの構成スタックと組み合わせたラベルを使用して、複数のキーセットを効果的に集計できます。

TestApp:MySetting という名前の構成設定があり、その値が環境によって異なる例を考えてみましょう。同じ名前を持つ 2 つのキーを作成できますが、別のラベルを割り当てることができます。1 つはラベルなし (既定) で、もう 1 つは開発というラベルが付いています。ラベル付けされていないキーは既定値を保持し、ラベル付けされたキーには環境固有の値が含まれます。

アプリケーションコードでは、最初に既定の (ラベルなし) キー値を読み込み、次に開発ラベルを使用して環境固有のキー値を読み込みます。 2 番目のセットを読み込むと、一致するキーによって、以前に読み込まれた値が上書きされます。この方法では、複数の構成セットを "スタック" でき、最後に読み込まれた値が優先されます。サポートされている言語とプラットフォーム全体の App Configuration プロバイダーは、このスタッキング機能を提供します。

次の例は、.NET アプリケーションでキーと値のコンポジションを実装する方法を示しています。

configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and compose with two different labels
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .Select(keyFilter: "TestApp:*", labelFilter: "Development");
});

「ラベルを使用してさまざまな環境でさまざまな構成を有効にする」に、完全な例が挙げられています。

構成の更新

Azure App Configuration では、アプリケーションの再起動を必要とせずに動的構成の更新がサポートされます。 App Configuration プロバイダーは、次の 2 つの方法を使用して構成の変更を監視できます。

選択したすべてのキーの監視

この方法では、プロバイダーは選択したすべてのキーを監視します。選択したキー値のいずれかで変更が検出されると、構成全体が再読み込みされます。この方法では、追加のキー変更を必要とせずに、即時更新が保証されます。

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh when any selected key changes.
               refreshOptions.RegisterAll();
           });
});

const appConfig = await load(endpoint, credential, {
    selectors: [{ keyFilter: "TestApp:*" }],
    refreshOptions: {
        enabled: true
    }
});

options := &azureappconfiguration.Options{
    Selectors: []azureappconfiguration.Selector{
        {
            KeyFilter: "TestApp.*",
        },
    },
    RefreshOptions: azureappconfiguration.KeyValueRefreshOptions{
        Enabled:  true,
    },
}

appConfig, err := azureappconfiguration.Load(ctx, authOptions, options)

apiVersion: azconfig.io/v1
kind: AzureAppConfigurationProvider
metadata:
  name: appconfigurationprovider-sample
spec:
  endpoint: <your-app-configuration-store-endpoint>
  target:
    configMapName: configmap-created-by-appconfig-provider
  configuration:
    selectors:
      - keyFilter: TestApp*
    refresh:
      enabled: true

センチネルキーの監視

または、個々のキー (通常は Sentinel キーと呼ばれます) を監視することもできます。この方法は、複数のキー値を更新する場合に便利です。他のすべての構成変更が完了した後にのみ Sentinel キーを更新することで、アプリケーションで構成が 1 回だけ再読み込みされ、一貫性が維持されます。

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh only if the `SentinelKey` changes.
               refreshOptions.Register("SentinelKey", refreshAll: true);
           });
});

const appConfig = await load(endpoint, credential, {
    selectors: [{ keyFilter: "TestApp:*" }],
    refreshOptions: {
        enabled: true,
        watchedSettings: [{ key: "SentinelKey" }]
    }
});

options := &azureappconfiguration.Options{
    Selectors: []azureappconfiguration.Selector{
        {
            KeyFilter: "TestApp*",
        },
    },
    RefreshOptions: azureappconfiguration.KeyValueRefreshOptions{
        Enabled:  true,
        WatchedSettings: []WatchedSetting{
				    {Key: "SentinelKey"},
			},
    },
}

appConfig, err := azureappconfiguration.Load(ctx, authOptions, options)

apiVersion: azconfig.io/v1
kind: AzureAppConfigurationProvider
metadata:
  name: appconfigurationprovider-sample
spec:
  endpoint: <your-app-configuration-store-endpoint>
  target:
    configMapName: configmap-created-by-appconfig-provider
  configuration:
    selectors:
      - keyFilter: TestApp*
    refresh:
      enabled: true
      monitoring:
        keyValues:
          - key: SentinelKey

どちらの方法も、サポートされている言語とプラットフォーム全体で App Configuration プロバイダーを通じて利用できます。

構成の不整合のリスクを軽減するには、構成スナップショットを使用して構成の整合性を確保します。

外部データへの参照

App Configuration は、通常は構成ファイルや環境変数に保存する任意の構成データを格納するように設計されています。ただし、データの種類によっては、他のソースに保存するのが適している場合もあります。たとえば、シークレット情報は Key Vault に、ファイルは Azure Storage に、メンバーシップ情報は Microsoft Entra グループに、顧客一覧はデータベースに格納するなどです。

それでも、外部データへの参照をキーと値に保存することで、App Configuration を利用することができます。コンテンツタイプを使用して、各データソースを区別できます。アプリケーションが参照を読み込むとき、ソースに対する必要なアクセス許可があると仮定して、参照されたソースから実際のデータを読み込みます。外部データの場所を変更した場合は、アプリケーション全体を更新して再デプロイするのではなく、App Configuration の参照を更新するだけで済みます。

App Configuration の Key Vault の参照機能はこのケースの一例です。これにより、アプリケーションに必要なシークレットを必要に応じて更新しながら、基となるシークレット自体は Key Vault に残すことができます。

App Configuration の準備

Azure App Configuration ストアにアクセスするには、接続文字列または Microsoft Entra ID を使用して認証できます。接続文字列は Azure portal ですぐに使用できますが、資格情報が含まれており、シークレットとして扱う必要があります。この方法を選択した場合は、接続文字列を Azure Key Vault に安全に格納し、アプリケーションが Key Vault に対して認証されて取得されるようにします。

より安全で推奨される方法は、Microsoft Entra ID 認証を使用することです。アプリケーションが Azure Kubernetes Service、App Service、Azure Functions など、Azure でホストされている場合は、Microsoft Entra ID によって提供されるマネージド ID を使用できます。マネージド ID を使用すると、シークレットを明示的に管理する必要がなくなります。この方法では、アプリケーションに必要なのは App Configuration エンドポイント URL のみです。この URL は、アプリケーションコードまたは構成ファイルに安全に埋め込むことができます。

詳細については、「マネージド 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 からキーと値をエクスポートすることもできます。 Configuration をコードとして採用し、GitHub または Azure DevOps で構成を管理する場合は、 GitHub Actions または Azure Pipeline Import Task を使用して、継続的な構成ファイルのインポートを設定できます。

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 ストアを使用する場合は、段階的にまたはすべて一度に構成データをプッシュすることもできます。

次のステップ

キーと値