Azure App Configuration の FAQ

この記事では、Azure App Configuration についてよく寄せられる質問に回答します。

App Configuration と Azure Key Vault は何が違うのですか?

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

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

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

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

App Configuration にはシークレットを格納すべきなのでしょうか?

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

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

App Configuration によってデータが暗号化されるのですか?

はい。 App Configuration は、そこに格納されているすべてのキー値を暗号化し、ネットワーク通信を暗号化します。 キー名とラベルは、構成データを取得するためのインデックスとして使用され、暗号化されません。

App Configuration と Azure App Service 設定は何が違うのですか?

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 に格納されているキーや値に対するサイズ制限はありますか?

1 つのキー値には 10 KB の制限があります。これには、ラベル、コンテンツタイプ、タグ、その他のメタデータなどの属性が含まれます。

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

複数の環境 (テスト、ステージング、本番など) の構成は、どのように格納すべきでしょうか?

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

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

App Configuration のおすすめの使い方を教えてください。

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

App Configuration にはどのぐらいのコストがかかりますか?

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

  • Free レベル
  • Standard レベル

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

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

どの App Configuration レベルを使用すればよいですか?

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

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

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

  • リソースごとのストレージ: Free レベルでは、各構成ストアのストレージは 10 MB に制限されています。 Standard レベルでは、各構成ストアで最大 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 レベルには、99.9% の可用性の SLA があります。 Free レベルには SLA がありません。

  • セキュリティ機能: どちらのレベルにも、Microsoft のマネージド キーを使用した暗号化、HMAC または Azure Active Directory を介した認証、Azure RBAC サポート、およびマネージド ID、サービス タグなどの基本的なセキュリティ機能が含まれています。 Standard レベルでは、Private Link のサポートや、カスタマー マネージド キーによる暗号化など、より高度なセキュリティ機能が提供されます。

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

ストアを Free レベルから Standard レベルにアップグレードすることはできますか? ストアを Standard レベルから Free レベルにダウングレードすることはできますか?

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

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

App Configuration に格納されているデータはどこにありますか。

App Configuration に格納されている顧客データは、顧客の App Configuration ストアが作成されたリージョンに置かれています。 これは、利用可能なすべてのリージョンに適用されます。 顧客とエンド ユーザーには、場所を問わず、顧客データのグローバルな移動、コピー、アクセスが許可されます。

App Configuration では、データの高可用性はどのようにして確保されますか?

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

アメリカ ヨーロッパ アフリカ アジア太平洋
ブラジル南部 フランス中部 オーストラリア東部
カナダ中部 ドイツ中西部 インド中部
米国中部 北ヨーロッパ 東日本
米国東部 ノルウェー東部 韓国中部
米国東部 2 英国南部 東南アジア
米国中南部 西ヨーロッパ 東アジア
米国西部 2 スウェーデン中部
米国西部 3

App Configuration に対する要求の数に制限はありますか?

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

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

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

アプリケーションで HTTP 状態コード 429 応答を受信します。 なぜですか?

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

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

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

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

削除したものと同じ名前の App Configuration ストアを作成できないのはなぜですか。

Standard レベルのすべての App Configuration ストアで、論理的な削除機能が自動的に有効になります。 Standard レベルの App Configuration ストアが削除された場合は、その名前が保持期間だけ予約されます。 保持期間が経過する前に同じ名前のストアを再作成するには、そのストアで消去保護が有効になっていなければ、まず論理的に削除されたストアを消去する必要があります。 消去保護が有効になっている場合は、保持期間が経過するまで待つ必要があります。

後で説明されているように、App Configuration では以前、論理的に削除されたストアを上書きするオプションが提供されていました。 このオプションは、2022 年 4 月 30 日をもって廃止されます。 同じ名前のストアを頻繁に再作成する必要がある場合は、移行して消去機能を使用するか、またはより短い保持期間を設定します。

  • 保持期間が経過する前に同じ名前のストアを再作成することは可能ですが、そのストアは、元のストアと同じサブスクリプション、リソース グループ、リージョン内にある必要があります。 ストアを含むリソース グループが削除されている場合は、その中にストアを再作成する前に、最初に同じサブスクリプションで再作成する必要があります。
  • 保有期間を過ぎるまでは、App Configuration ストアを別のサブスクリプション/リソース グループで作成することはできません。 ただし、こちらの手順に従うことで、元のサブスクリプション/リソース グループでリソースを再作成し、その後、それらを新しいサブスクリプション/リソース グループに移動できます。
  • 保有期間中に App Configuration ストアを再作成することは、現在、Azure CLI で az appconfig createコマンドを使用した場合にのみサポートされます。

誤って削除した App Configuration ストアを復元する方法はありますか。

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

App Configuration に関する新しいリリースやその他の情報についてのお知らせを受け取るにはどうすればよいですか?

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

問題のレポート方法または提案の送信方法を教えてください。

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

次の手順