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

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

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

次の 2 つの価格レベルがあります。

• Free レベル
• Standard レベル

Standard レベルの導入前にストアを作成した場合、それは一般公開時に自動的に Free レベルに移行されます。 Standard レベルへのアップグレードか Free レベルの維持を選択できます。

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

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

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

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

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

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

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

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

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

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

• コスト: Standard レベルのストアには、毎日の使用料金があります。 1 日あたりで最初の 200,000 件の要求は、1 日の料金に含まれています。 また、1 日の割り当てを超えた要求に対しては超過料金が発生します。 Free レベルのストアを使用する場合、コストはかかりません。

いつでも Free レベルから Standard レベルにアップグレードすることができます。

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

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

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

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

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

Free レベルの構成ストアでは、1 日あたりの要求数が 1000 件に制限されています。 Standard レベルの構成ストアでは、要求レートが 1 時間あたり 30,000 要求を超えると、一時的な調整が発生する場合があります。

ストアが Standard レベルの制限に達すると、1 時間の終わりまでに実行された一部の要求に対して HTTP 状態コード 429 が返される場合があります。 応答の retry-after-ms ヘッダーは、要求を再試行するまでの推奨される待機時間 (ミリ秒) を示します。

アプリケーションで HTTP 状態コード 429 の応答が定期的に発生する場合は、行われる要求の数を減らすために、アプリケーションを再設計することを検討してください。 詳細については、App Configuration に対する要求を減らす方法に関する記事を参照してください。

HTTP 状態コード 429 応答は、次のような状況で返されます。

• Free レベルのストアの 1 日あたりの要求上限を超えている。
• Standard レベルのストアの 1 時間あたりの要求上限を超えている。
• 要求のバーストが大量にあったため、一時調整されている†。
• 帯域幅の過剰使用による一時調整†。
• ストレージ クォータを超過しているときに、キーを作成または変更しようとしている。

要求が失敗した具体的な理由について、429 応答の本文を確認します。

†構成ストアで要求のバーストを大量に受け取った場合や過剰な量のデータを転送した場合、一時調整が発生するおそれがあります。 App Configuration の Azure SDK、構成プロバイダー ライブラリ、Azure Pipelines タスクなどのクライアントでは、要求の調整で再試行が自動的に行われます。 これらのクライアントのいずれかを使用しているアプリケーション、または要求の調整で再試行されるカスタム クライアントでは、この一時調整が発生した場合でも気付くことはありません。

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

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

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

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

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

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

Standard レベルのすべての 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 について