Azure App Configuration の FAQ

App Configuration は、開発者がアプリケーション設定を管理したり機能の利用の可否を制御したりするのに役立ちます。 複雑な構成データの扱いに伴うさまざまなタスクを単純化することを目的としています。

App Configuration では、以下がサポートされています。

• 階層型名前空間
• ラベル付け
• 広範なクエリ
• 一括取得
• 特殊化された管理操作
• 機能管理のユーザー インターフェイス

App Configuration は Key Vault を補完するものであり、両者はほとんどのアプリケーションのデプロイにおいて一緒に使用する必要があります。

App Configuration は強固なセキュリティを備えていますが、それでもアプリケーション シークレットの保管場所としては Key Vault が最も優れています。 Key Vault では、ハードウェアレベルの暗号化、粒度の細かいアクセス ポリシー、管理操作 (証明書のローテーションなど) が利用できます。

キー コンテナーに格納されているシークレットを参照する App Configuration キー値を作成できます。 詳細については、「ASP.NET Core アプリで Key Vault 参照を使用する」を参照してください。

はい。 App Configuration を使用すると、転送中および保存中のすべてのデータが常に暗号化されます。 すべてのネットワーク通信は、TLS 1.2 または TLS 1.3 経由で行われます。 App Configuration では、Microsoft マネージド キーまたはカスタマー マネージド キーのいずれかを使用する保存時の暗号化がサポートされています。

Azure App Service では、App Service インスタンスごとにアプリ設定を定義できます。 これらの設定は、環境変数としてアプリケーション コードに渡されます。 必要に応じて、特定のデプロイ スロットに設定を関連付けることができます。 詳細については、「アプリ設定の構成」を参照してください。

対照的に、Azure App Configuration では、複数のアプリ間で共有できる設定を定義できます。 これには、App Service で実行されるアプリや、その他のプラットフォームが含まれます。 ご利用のアプリケーション コードからこれらの設定へのアクセスは、(.NET と Java の場合) 構成プロバイダーから、Azure SDK から、あるいは REST API 経由で直接、行われます。

App Service のアプリケーション設定で、App Configuration データへの参照を追加できます。 App Service と App Configuration の間で設定をインポートおよびエクスポートすることもできます。 この機能を使用すると、既存の App Service 設定に基づいて新しい App Configuration ストアをすばやく設定できます。 App Service 設定に依存する既存のアプリと構成を共有することもできます。

1 つのキー値には 10 KB の制限があります。これには、ラベル、コンテンツタイプ、タグ、その他のメタデータなどの属性が含まれます。 キーとラベルの合計サイズがストレージの上限に達していない限り、キーとラベルの数に制限はありません。

ほとんどのアプリケーションでは、1 つの設定に対してこのキーと値の制限で十分です。 ご使用の設定がこの制限を超えている場合は、データを他の場所に格納し、App Configuration にそのデータの参照を追加することを検討してください。

全制限の一覧については、Azure サブスクリプションとサービスの制限に関する記事を参照してください。

ストアごとのレベルで App Configuration にアクセスできるユーザーを制御します。 異なるアクセス許可を必要とする環境ごとに、個別のストアを使用してください。 セキュリティ分離上、このアプローチが最も優れています。

環境間でセキュリティ分離が必要ない場合は、ラベルを使用して構成値を区別できます。 「ラベルを使用して異なる環境に対する異なる構成を有効にする」に、完全な例が挙げられています。

ベスト プラクティスを参照してください。

Free、Standard、Premium の 3 つの価格レベルがあります。 価格の詳細については、「App Configuration の価格」ページを参照してください。

App Configuration のいずれのレベルにも、構成設定、機能フラグ、Key Vault 参照、構成スナップショット、基本的な管理操作、メトリック、ログなどのコア機能が用意されています。

レベルを選択する際の考慮事項を次に示します。

• 目的: Free レベルは、非運用環境でのサービスの評価に最適であり、コストなしでその機能を探索できます。 Standard レベルは、中ボリュームの運用環境のユース ケースに合わせて調整されており、バランスの取れたパフォーマンスとコスト効率を提供します。 大量またはエンタープライズ レベルの運用環境のニーズに対して、Premium レベルは最高レベルのパフォーマンスとスケーラビリティを提供し、負荷が高い場合でもアプリケーションをスムーズに実行できるようにします。

• サブスクリプションあたりのリソース数: リソースは、1 つの構成ストアで構成されます。 Free レベルでは、各サブスクリプションの構成ストアはリージョンあたり 1 つに制限されています。 Standard および Premium レベルでは、サブスクリプションに構成ストアを無制限に含めることができます。

• リソースあたりのストレージ: Free レベルでは、各構成ストアは 10 MB の通常ストレージと 10 MB のスナップショット ストレージに制限されます。 Standard レベルでは、各構成ストアは最大 1 GB の通常ストレージと、さらに 1 GB のスナップショット ストレージを使用できます。 Premium レベルでは、各構成ストアは最大 4 GB の通常ストレージと、さらに 4 GB のスナップショット ストレージを使用できます。

• リビジョン履歴:App Configuration では、キーに加えられたすべての変更の履歴が格納されます。 Free レベルでは、この履歴は 7 日間保存されます。 Standard レベルと Premium レベルでは、この履歴は 30 日間保存されます。

• 要求のクォータ:Free レベルのストアでは、1 日あたりの要求数が 1000 件に制限されています。 要求数が 1,000 件に達すると、ストアからは、UTC の午前 0 時まですべての要求に対して HTTP 状態コード 429 が返されます。

  Standard レベルのストアでは、1 時間あたりの要求数が 30,000 件に制限されています。 時間あたりのクォータを使い果たした後は、その 1 時間が終わるまでの間は、さらなる要求に対し、要求数が多すぎることを示す HTTP 状態コード 429 が返される場合があります。 クォータを超えて送信される要求数が多ければ多いほど、それらの要求で、状態コード 429 が返される割合が高くなります。

  Premium レベル ストアには、要求に対するクォータ制限がないため、ストアへのアクセスがブロックされることはありません。

• スループット: すべてのレベルの App Configuration ストアにはスループットの許容値があります。 この許容値を超える要求は、HTTP 状態コード 429 応答を受け取ります。 Free レベルのストアにはスループットが保証されていません。

  Standard レベルのストアでは、読み取り要求の場合は 1 秒あたりの要求数 (RPS) が最大 300、書き込み要求の場合は最大 60 RPS の実行速度†が可能です。

  Premium レベルのストアでは、読み取り要求の場合は最大 450 RPS、書き込み要求の場合は最大 100 RPS の実行速度†が可能です。

  †実行速度は、通常、指定した期間に調整を行わずに App Configuration ストアによって処理された要求数の平均として測定されます。

• サービス レベル アグリーメント: Free レベルには SLA がありません。 Standard レベルの SLA は 99.9% の可用性であり、geo レプリケーションが有効な場合は 99.95% の可用性です。 Premium レベルの SLA は 99.9% の可用性であり、geo レプリケーションが有効な場合は 99.99% の可用性です。

• 機能: いずれの層にも、Microsoft マネージド キーによる暗号化、アクセス キーまたは Microsoft Entra ID による認証、Azure のロールベースのアクセス制御 (RBAC)、マネージド ID、サービス タグ、可用性ゾーン冗長性などの機能が含まれています。 Standard および Premium レベルでは、Private Link のサポート、カスタマー マネージド キーによる暗号化、論理的な削除保護、geo レプリケーション機能など、さらに多くの機能が提供されます。

• コスト: Free レベルのストアを使用する場合、コストはかかりません。

  Standard レベルのストアには、日ごとの使用量が課金されます。これには、毎日 200,000 件までの要求が含まれます。 この 1 日の割り当てを超える要求に対しては超過料金が発生します。

  Premium レベルのストアには、日ごとの使用量が課金されます。これにはレプリカも含まれます。 1 日あたり、配信元に対する最初の要求 800,000 件までと、レプリカに対する最初の要求 800,000 件までが 1 日の料金に含まれます。 この 1 日あたりの割り当てを超える要求では、超過料金が発生します。

App Configuration ストアは、Free レベルから Standard レベルまたは Premium レベル、Standard レベルから Premium レベルへと、いつでもアップグレードできます。

App Configuration ストアをダウングレードすることはできません。たとえば、Premium レベルから Standard レベルへ、または、Standard レベルから Free レベルへとダウングレードしたりすることはできません。 しかし、希望するレベルで新しいストアを作成してから、そのストアに構成データをインポートすることができます。

App Configuration に格納されている顧客データは、顧客の App Configuration ストアが作成されたリージョンに置かれています。 顧客データは、顧客がそのリージョンの geo レプリケーションを有効にした場合にのみ、別のリージョンにレプリケートされます。 これは、利用可能なすべてのリージョンに適用されます。 顧客は、世界各国のあらゆる場所からデータの移動、コピー、アクセスを行うことができます。

Azure App Configuration では、リージョンの障害に対する回復性を強化するために geo レプリケーションがサポートされています。

Azure App Configuration では、単一のデータセンターの障害からアプリケーションとデータを保護するために、Azure 可用性ゾーンがサポートされています。 可用性ゾーンが有効なすべてのリージョンは、少なくとも 3 つの可用性ゾーンで構成されます。各可用性ゾーンは物理的に独立したデータセンターです。 回復性のために、App Configuration でのこのサポートは、追加コストなしですべてのお客様に対して有効になっています。 以下は、App Configuration で可用性ゾーンのサポートが有効になっているリージョンです。 詳細については、「可用性ゾーンをサポートする Azure リージョン」を参照してください。

以下は、App Configuration で可用性ゾーンのサポートが有効になっているリージョンです。

App Configuration ストアの要求クォータは、レベルによって異なります。 Free レベル ストアは 1 日あたり 1,000 要求、Standard レベル ストアは 1 時間あたり 30,000 要求に制限されます。Premium レベル ストアには要求の制限がないため、アクセスは中断されません。

App Configuration ストアには、レベルに基づいたスループットの許容値があります。 Free レベルのストアにはスループットが保証されていません。 Standard レベルのストアは、読み取り操作の場合は 1 秒あたりの要求数 (RPS) が最大 300、書き込み操作の場合は最大 60 RPS の実行速度をサポートします。 Premium レベル ストアは、読み取り操作の場合は最大 450 RPS、書き込み操作の場合は最大 100 RPS の実行速度をサポートします。

例を見てみましょう。1,000 個の構成設定を持つアプリケーションがあるとします。 アプリケーションは、起動時に App Configuration からこれらの設定をすべて読み込みます。 その後、30 秒ごとに Sentinel キーの構成変更が確認されます。 Kubernetes、App Service、VM のいずれで実行している場合でも、アプリケーションの 50 個のインスタンスが同時に実行されているとします。

まず、構成監視の要求を見積もりましょう。 アプリケーションの各インスタンスは、30 秒ごとに 1 つのセンチネル キーに対する要求を App Configuration に送信するため、1 時間で 120 (=3600/30) 件の要求が送信されます。 アプリケーションのインスタンスが 50 個ある場合、アプリケーションは構成監視のために 1 時間ごとに合計 6,000 (=120x50) 個の要求を送信します。 センチネル キー要求は頻繁に行われますが、ほとんど変更されないため、Standard レベル ストアの場合、その大半はストアの 1 時間あたりのクォータ制限†にはカウントされないことに注意してください。

次に、構成の読み込み/再読み込みの要求を見積もります。 アプリケーションは、起動時または Sentinel キーの変更が検出されるたびに、すべての設定を読み込みます。 App Configuration への各要求は最大 100 個のキー値を取得できるため、すべての設定を読み込むには 10 (=1000/100) 個の要求が必要です。 アプリケーション インスタンスが 50 個ある場合、アプリケーションが再起動または構成を再読み込みするときに、合計 500 (=10x50) 個の要求を送信します。

最後に、まとめてみましょう。 1 時間以内に Sentinel キーを 2 回更新したと仮定すると、App Configuration ストアでは、その時間の合計要求数が 7,000 (=6,000+500x2) 件になります。 これらの要求のうち、Standard レベルのストアで使用できる 1 時間あたりのクォータを使用しているのは、約 1,000 (= 500 x 2) 要求だけであることに注意してください。 この例の数値を特定の設定と設計に合わせて更新して、時間単位のクォータ制限に対して十分なバッファーを確保できるようにします。

†Free レベル ストアでは、頻繁に繰り返される要求が 1 日あたりの制限から除外されることはありません。

次の状態では、アプリケーションは HTTP 状態コード 429 応答を受け取ることがあります。

• Free レベルのストアの 1 日あたりの要求クォータを超えている。
• Standard レベルのストアの 1 時間あたりの要求クォータを超えている。
• いずれかのレベルのストアでスループットの許容値を超えています。
• いずれかのレベルのストアで帯域幅の許容値を超えています。
• ストレージ クォータを超過しているときに、キーと値を作成または変更しようとしている。

要求が失敗した具体的な理由について、429 応答の本文を確認します。 Azure Monitor の App Configuration ストアのログを収集し、"要求クォータの使用量" メトリックのアラートを設定することもできます。

一時的な HTTP 状態コード 429 応答を受信しても、App Configuration クライアントによって適切に処理されるため、通常は害はありません。 ただし、アプリケーションで HTTP 状態コード 429 応答が定期的に発生する場合は、次のオプションを検討してください。

• ストアを Premium レベルにアップグレードする: このレベルには要求のクォータ制限がありません。また、ストレージ クォータが増え、スループットの上限が高くなります。
• App Configuration プロバイダーを使用する: プロバイダーには、他の多くの復元機能に加えて、再試行とキャッシュ機能が組み込まれています。 最新の機能強化をすべて利用するには、必ずプロバイダーの最新バージョンに更新してください。
• アプリケーションから書き込み要求を送信する必要がある場合は、App Configuration SDK を使用します。 SDK はプロバイダーほど機能が豊富ではないかもしれませんが、HTTP 状態コード 429 応答と他の一時的なエラーに対して再試行が自動的に行われます。
• App Configuration プロバイダーまたは SDK を使用できない場合は、カスタム クライアントに再試行ロジックを含めます。 応答の retry-after-ms ヘッダーには、要求を再試行するまでの推奨される待機時間 (ミリ秒) を指定します。
• 要求を複数のクライアント インスタンスに分散する: これは、App Configuration ストアからの最大スループットを達成するために役立ちます。
• App Configuration に対する要求を減らす: ガイダンスに従って、要求の数を最小限に抑えます。
• アプリケーションの回復性を高める: フェールオーバーと負荷分散を可能にするために geo レプリケーションを統合することを検討してください。 回復性の高いアプリケーションを構築するためのベスト プラクティスを確認してください。

Standard および Premium レベルのすべての App Configuration ストアにおいて、論理的な削除機能が自動的に有効になっています。 Standard および Premium レベルの App Configuration ストアが削除された場合、その名前は保持期間のあいだ保存されます。 保持期間が経過する前に同じ名前のストアを再作成するには、そのストアで消去保護が有効になっていなければ、まず論理的に削除されたストアを消去する必要があります。 消去保護が有効になっている場合は、保持期間が経過するまで待つ必要があります。 同じ名前のストアを頻繁に再作成する必要がある場合は、消去機能を使用するか、またはより短い保持期間を設定します。 同じ名前のストアを再作成する必要があるワークフローでは、構成ストアを消去してから以降の作成を実行するまでに 1 時間の余裕を持たせる必要があります。 消去が要求されると、構成ストア リソースの実際のクリーンアップが非同期的に実行され、最終処理に少し余分な時間が必要になるため、この推奨事項が適用されます。 待機する必要がないように、エフェメラル構成ストアを作成するワークフローでは、一意の名前を使用することをお勧めします。

Standard および Premium レベルのすべての App Configuration ストアで論理的な削除機能がサポートされており、これを無効にすることはできません。 削除されたストアは、その保持期間内に回復することができます。 誤って削除された App Configuration ストアを回復するには、この手順に従ってください。

はい。 Azure portal または CLI を使用して、App Configuration で機能フラグと Key Vault 参照を管理できますが、App Configuration SDK を使用してプログラムで作成および更新することもできます。 したがって、カスタマイズされた管理ポータルを作成したり、CI/CD でプログラムで管理したりできます。 機能フラグと キー コンテナーの参照 API は、サポートされているすべての言語の SDK で使用できます。 サポートされている各言語の例については、サンプル リンク を参照してください。

アプリケーションで機能フラグを評価して使用するには、.NET および Java Spring で使用できる App Configuration プロバイダーと機能管理ライブラリが必要です。 詳細については、「クイック スタート」と チュートリアルの「機能管理」 セクションを参照してください。

Spring プロファイルでは、特定の環境または特定のライブラリを使用している場合にのみ使用できるよう、構成などアプリケーションの一部を分離できます。

キー値のラベルは、Spring プロファイルに合わせて設定することをお勧めします。 ラベル フィルターが明示的に設定されていない場合、App Configuration Spring プロバイダー ライブラリは、既定で現在のアクティブな Spring プロファイル (${spring.profiles.active}) に一致するラベルを持つキー値を読み込みます。 アクティブな Spring プロファイルが設定されていない場合は、"ラベルのない" キー値が読み込まれます。

たとえば、プロファイル dev と prod では、次のラベルを使用して、それぞれのキー値を作成します。

Spring プロファイルが dev に設定されている場合、config.message 値は Hello from dev になります。 Spring プロファイルが prod に設定されている場合、config.message 値は Hello from prod になります。

この既定の動作は、ブートストラップ ファイルでラベル フィルターを設定することでオーバーライドできます。 Spring プロバイダー ライブラリは、アクティブな Spring プロファイルに関係なく、指定したラベルのキー値を読み込みます。

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

他のラベルと Spring プロファイルを選択するには、ラベルのないすべてのキーと、Spring プロファイルに一致するものが選択される ',${spring.profiles.active}' などのラベル フィルターを使用できます。 キーの重複が見つかった場合、右端のラベルが優先されます。

バージョン 3.1.0 以降、Microsoft.FeatureManagement ライブラリでは、依存関係の挿入ベースの .NET アプリケーションで、機能フィルターを含む機能管理サービスをスコープ付きサービスとして実行できるようになりました。 この機能を利用するには、次のコード スニペットに示すように、コード内の AddFeatureManagement 呼び出しを単に AddScopedFeatureManagement に置き換えます。

services.AddScopedFeatureManagement();

機能フィルターは、HTTP 要求のプロパティに基づいて機能フラグを評価できます。 これは通常、シングルトンの IHttpContextAccessor パターンを通じて HttpContext を検査することにより実行されます。 ただし、このパターンは、スコープ付きサービスを代わりに使用する必要がある Blazor サーバー アプリケーションでは機能しません。 この場合は、AddScopedFeatureManagement メソッドを使用する必要があります。

GitHub のお知らせ用のリポジトリにサブスクライブしてください。

GitHub から直接お寄せいただけます。

• Azure App Configuration について