Azureを学ぶ Azure App Configuration を実装する

本記事は Microsoft Learn の「Azure App Configuration を実装する」というモジュールをまとめたものである。

Azure App Configuration の概要

分散したアプリケーションの設定や機能フラグを一元管理するフルマネージドサービス。設定の散在によるトラブルを防ぎ、運用を効率化する。

1. 主なメリット

• 一元管理：全コンポーネントの設定を1か所に集約
• 柔軟な操作：ラベル（タグ）付けや、過去のある時点の設定を復元する「再生機能」を搭載
• 高い安全性：マネージドIDによる認証や、転送中・保存時の暗号化をサポート
• 機能管理：専用UIで「機能フラグ（機能のON/OFF）」をリアルタイム制御可能
• 統合性：主要なフレームワークとネイティブに連携し、数分で導入可能

2. Key Vault との使い分け
App Configuration は Azure Key Vault を補完する 役割を担う

• Key Vault：パスワード、証明書などの「機密情報（シークレット）」を保管
• App Configuration：「環境設定」や「機能フラグ」を保管。Key Vault 内のシークレットへの参照（ポインタ）を保持することも可能

3. 主な活用シナリオ

• 階層管理：開発・テスト・本番、あるいは地域ごとに異なる設定を階層的に一括配布
• 動的更新：アプリを再起動・再デプロイすることなく、設定変更を即座に反映
• 機能制御：特定の機能をリアルタイムで有効化・無効化する

App Configuration の接続方法

アプリケーションに App Configuration を導入する際は、Microsoft 提供のクライアントライブラリを使用するのが最も効率的。

1. 言語・フレームワーク別の接続ツール
環境に合わせて最適化されたライブラリが用意されている。

言語 / フレームワーク	接続に使用するツール
.NET / ASP.NET Core	.NET 用 App Configuration プロバイダー
.NET Framework / ASP.NET	.NET 用 App Configuration ビルダー
Java Spring	Spring Cloud 用 App Configuration プロバイダー
JavaScript / Node.js	JavaScript 用 App Configuration プロバイダー
Python	Python 用 App Configuration プロバイダー
その他（上記以外）	App Configuration REST API を直接利用

2. ライブラリを使用するメリット

• ネイティブ統合：各言語の標準的な設定システム（.NET の IConfiguration など）にそのまま組み込める
• 自動更新：設定が変更された際に、アプリを再起動せず自動で読み直す「動的リフレッシュ」の実装が容易
• 簡便性：認証処理（マネージド ID 等）やリトライ処理が内蔵されており、コード量が削減できる

キーと値のペアを作成する

キー

App Configuration における「キー」は、設定値を識別するための名前であり、柔軟な設計が可能。

1. キーの構造化（階層管理）

• 名前空間の整理：/ や : などの区切り記号を使い、階層的に管理するのが一般的
  • 例：AppName:Service1:ApiEndpoint
• フレームワークとの整合性：.NET の : や Spring Cloud の命名規則など、使用するフレームワークの慣習に合わせるのがベスト
• 柔軟性：階層の深さに制限はなく、論理的なグループ分けによって可読性と管理性が向上する

2. キーの技術的特性

• 大文字・小文字を区別：app1 と App1 は別のキーとして扱われるため、厳密な管理が必要
• Unicode 対応：ほとんどの文字が使用可能だが、特定の予約文字には注意が必要
  • 予約文字：* , \ はシステム予約済み
  • エスケープ：これらを使用する場合は {文字} の形式でエスケープする
• サイズ制限：「キー + 値 + 属性」の合計で 10,000 文字 が上限

3. システム側の動作

• 非介入の原則: App Configuration 自体はキーの階層構造を解析したり、特定のルールを強制したりしない。単なる「一塊の文字列」として扱う

キーの名前空間設計

App Configuration で設定を管理する際、キーの名前付け（名前空間）は「階層型」にするのが効率的。

1. 2つの命名方法

• フラット型：AppNameService1ApiEndpoint のように、区切りなく繋げる方法
• 階層型：AppName:Service1:ApiEndpoint のように、区切り記号（/ や :）で分ける方法

2. 階層型を選択するメリット

• 高い可読性：区切り記号がスペースの役割を果たし、意味が直感的に伝わる
• 論理的な整理：「アプリ名 ＞ サービス名 ＞ 設定項目」といった具合にグループ化できるため、管理が容易
• 柔軟な取得：「Service1:*（Service1に関する全設定）」のように、ワイルドカードを使ったパターンマッチングで、必要なデータだけを効率よく抽出できる

ラベルによるキーの識別と管理

同じ名前の「キー」であっても、「ラベル」を使い分けることで異なる設定値として保持できる。

1. ラベルの役割

• 重複の回避：同じキー（例：app1）に対し、ラベル A と ラベル B を割り当てることで、別々の設定として共存可能
• バリアント（変種）の作成：同一のキー名を使って、状況に応じた値の切り替え（バリエーション）を実現する

2. 主な活用シーン：環境の切り分け
同じキーに対して「環境名」をラベルとして付与し、値を管理するのが最も一般的な使い方。

• Test ラベル：テスト用 DB エンドポイント
• Staging ラベル：ステージング用 DB エンドポイント
• Production ラベル：本番用 DB エンドポイント

3. 注意点

• デフォルト状態：ラベルを指定しない場合、そのキーは「ラベルなし」となる
• 明示的な参照：ラベルがないキーをプログラム等から明示的に指すときは、\0（ヌル文字）を使用する

ラベルを使ったバージョン管理

App Configuration 自体には、キー値が変更された際の「自動的な履歴保存（バージョン管理）」機能はない。そのため、ラベルを応用して手動で履歴を管理する必要がある。

1. ラベルによるバージョン管理の手法
同じキーに対して、変更ごとに新しいラベルを付けて保存することで履歴を残す。

• 識別子としての利用：ラベルに「アプリのバージョン番号」や「Git のコミット ID」を記録する
• メリット：どのソースコードのバージョンが、どの設定値を使用していたかを正確に紐付けられる

2. 切り戻し（ロールバック）の簡素化

• 以前のバージョンに戻したい場合、読み込むラベルを過去の ID に指定し直すだけで済む
• 値を上書きして消してしまうリスクを抑え、安全な運用が可能

キー値の照会

App Configuration から設定を取得する際のルールと仕組み。

1. 一意識別のルール

• キー ＋ ラベル：この2つの組み合わせが揃って初めて、特定の「値」が一つに決まる
• ラベルなしの場合：内部的には \0（ヌル文字）というラベルが付いているものとして識別される

2. クエリ（照会）の仕組み

• パターン指定：取得したいキーやラベルの「パターン」を指定してストアに要求を送る
• 一括取得：条件に合致するすべてのキー・値・属性（ラベルや最終更新日など）がまとめて返される

値

App Configuration に格納される「値」の扱いと、安全に利用するための基本原則。

1. 値の仕様

• 形式：Unicode 文字列。あらゆる文字が使用可能
• コンテンツタイプ：オプションで「型（content-type）」を指定できる
  • これにより、アプリ側で「これは JSON だ」「これはエンコードされている」といった判断が可能

2. セキュリティと暗号化

• 標準保護：データの保存時および転送中は常に暗号化される
• マネージド ID：アクセス制御にマネージド ID を利用し、セキュリティを強化できる

3. Key Vault との使い分け（重要）

• シークレットは厳禁：パスワードや接続文字列などの「機密情報」を直接書き込むのは避けるべき
• 役割分担：
  • App Configuration：アプリの「設定」や「機能フラグ」を管理
  • Key Vault：「シークレット」を管理
• 補完関係：App Configuration 内で Key Vault の参照先を保持し、安全に橋渡しをするのが正しい設計

アプリケーションの機能を管理する

機能管理は、アプリケーションの「コードのデプロイ」と「機能の公開（リリース）」を切り離すための手法。

1. 機能フラグ（Feature Flag）とは

• 仕組み：コード内に「スイッチ（トグル）」を埋め込み、機能の有効・無効を制御する
• 別称：フィーチャー・トグル、機能スイッチなど
• メリット：アプリを再デプロイすることなく、設定一つで即座に機能の出し分けが可能

2. 機能管理の利点

• 動的なライフサイクル管理：開発済みの機能を「無効」のままデプロイし、準備が整ったタイミングで「有効」に切り替えられる
• 迅速な対応：リリース後に不具合が見つかっても、コードを戻さずスイッチをオフにするだけで機能を隠せる
• テストの容易化：特定のユーザー（テスターなど）だけに機能を先行公開して検証が可能

機能管理の基本概念

機能管理を構成する主要な用語と、システムが動作する仕組みの要約。

1. 3つの重要用語

• 機能フラグ (Feature Flag)
  • 「オン/オフ」の状態を持つ変数
  • その状態によって、特定のコードブロックを実行するかどうかを制御する
• 機能マネージャー (Feature Manager)
  • アプリ内で機能フラグのライフサイクルを管理するパッケージ
  • フラグ状態のキャッシュや更新などの処理を担う
• フィルター (Filter)
  • フラグの「オン/オフ」を決定するルール
  • ユーザーグループ、デバイス、地域、時間帯などに基づいて動的に状態を評価できる

2. 実装に必要なコンポーネント
機能管理を成立させるには、以下の2つが連携する必要がある。

• アプリケーション: コード内に機能フラグを埋め込み、利用する側
• リポジトリ (外部リポジトリ): 機能フラグの設定値や現在の状態を保管する専用の場所（Azure App Configuration など）

コードでの機能フラグ実装

機能フラグの基本は、実行の可否を制御するシンプルな「条件分岐（if文）」である。

1. 基本パターン

• バイナリ制御：フラグが true なら実行、false ならスキップという単純な構造

if (featureFlag) {
    // Run the following code
}

2. フラグ状態の決定方法
フラグの値（true/false）をどのように決めるかには、いくつかの段階がある。

• 静的な設定：コード内で直接値を指定する

bool featureFlag = true;

• 動的な評価：特定の条件（メソッドの戻り値など）によって判定する

bool featureFlag = isBetaUser();

3. 条件の拡張

• else文の利用：フラグがオフの場合の代替処理も定義できる
• 柔軟な切り替え：新旧のロジックを両方記述しておき、フラグ一つで動作を切り替える

if (featureFlag) {
    // This following code will run if the featureFlag value is true
} else {
    // This following code will run if the featureFlag value is false
}

機能フラグの宣言

機能フラグの構成要素と、判定が行われる仕組みの要約。

1. 機能フラグの構成
各フラグは以下の2つの要素で成り立つ。

• 名前：フラグを識別するための固有名称
• フィルター一覧：「オン」にする条件（ユースケース）を定義したルールのリスト

2. フィルターの判定ルール（OR条件）
複数のフィルターが設定されている場合、判定は以下の順序で行われる。

• 順次評価：リストの先頭から順番にフィルターを確認する
• 早期確定：いずれか1つでも「オン」と判定すれば、その時点でフラグは「オン」に確定し、以降のフィルター評価はスキップされる
• デフォルトオフ：全てのフィルターが「有効」と判断しなかった場合のみ、フラグは「オフ」となる

3. 設定ファイル（JSON）での記述例
appsettings.json などで、フラグの状態やフィルターを構造的に定義できる。

• 単純なバイナリ：true（常にオン）や false（常にオフ）で指定
• 高度な制御：フィルター名（例：Percentage）とパラメータ（例：Value: 50）を組み合わせることで、「ユーザーの50%に対してのみオン」といった動的な制御が可能

"FeatureManagement": {
    "FeatureA": true, // Feature flag set to on
    "FeatureB": false, // Feature flag set to off
    "FeatureC": {
        "EnabledFor": [
            {
                "Name": "Percentage",
                "Parameters": {
                    "Value": 50
                }
            }
        ]
    }
}

機能フラグのリポジトリ

機能フラグを最大限に活用するためには、フラグをアプリ内部ではなく外部のリポジトリで管理することが不可欠。

1. なぜ「外部化」が必要か

• デプロイ不要の変更：アプリのコードを書き換えたり、再デプロイしたりすることなく、外部からフラグの「オン/オフ」を切り替えられる
• 即時反映：設定を変更した瞬間に、稼働中のアプリの動作を迅速かつ確実に操作できる

2. リポジトリとしての Azure App Configuration
Azure App Configuration は、機能フラグの中央管理所として機能する。

• 一元管理：複数のアプリやサービスにまたがる大量のフラグを一箇所で把握・操作可能
• 多様な定義：単なるオン/オフだけでなく、複雑な条件付きフラグも定義できる
• 高い親和性：専用ライブラリ（SDK）により、様々なプログラミング言語から簡単にフラグの状態を読み取れる

アプリ構成データをセキュリティで保護する

カスタマーマネージドキーによる暗号化

Azure App Configuration のデータ保護には、標準の暗号化に加え、ユーザー自身が管理するキーを使用するオプションがある。

1. 基本的な暗号化の仕組み

• 標準保護：既定で 256 ビットの AES 暗号化を使用。Microsoft が管理する独自のキーで自動暗号化される
• 対象：格納されている「キーと値」のペアの「値」が暗号化の対象

2. カスタマーマネージドキー（CMK）の動作
より高い制御が必要な場合、独自のキー（Azure Key Vault 内）で暗号化を強化できる。

• 認証：App Configuration インスタンスの「マネージド ID」を使用して Microsoft Entra ID で認証
• キーのラップ：管理している Azure Key Vault のキーを呼び出し、App Configuration 側の暗号化キーを「ラップ（さらに暗号化）」する

3. 可用性とパフォーマンスの維持

• キャッシュ：ラップを解除したキーは App Configuration 内に 1 時間キャッシュされる
• 定期更新：1 時間ごとにキーを更新（再ラップ解除）することで、常に最新のセキュリティ状態と可用性を両立

カスタマーマネージドキー（CMK）の有効化手順

Azure App Configuration で独自のキーを使用するために必要なリソースと、設定のステップを整理。

1. 必須コンポーネント
設定を始める前に、以下の準備が必要。

• App Configuration：Standard レベル以上のインスタンス（Free レベルは不可）
• Azure Key Vault：以下の保護機能が有効であること
  • 論理的な削除 (Soft Delete)
  • 消去保護 (Purge Protection)
• 暗号化キー：Key Vault 内の RSA または RSA-HSM キー
  • 有効期限内で「有効」な状態であること
  • 「キーのラップ (Wrap)」と「キーのラップ解除 (Unwrap)」の権限が付与されていること

2. 有効化の 2 ステップ
リソース準備後、以下の設定を行う。

• マネージド ID の割り当て：App Configuration インスタンスに「システム割り当て」または「ユーザー割り当て」のマネージド ID を付与する
• アクセス許可の付与：ターゲットの Key Vault で、上記 ID に対して以下のアクセス許可を設定する
  • GET（キー情報の取得）
  • WRAP（キーのラップ）
  • UNWRAP（キーのラップ解除）

プライベート エンドポイントによる接続保護

Azure App Configuration のプライベート エンドポイントを利用することで、インターネットを経由しないセキュアな構成管理が可能になる。

1. 仕組み

• プライベートリンク：仮想ネットワーク（VNet）内のプライベートIPアドレスを使用してストアにアクセス
• バックボーン経由：トラフィックは Microsoft の内部ネットワークのみを通過し、パブリックインターネットに一切露出しない

2. 導入のメリット

• 完全な閉域化：ファイアウォールでパブリックアクセスを遮断し、外部からの攻撃や閲覧を防御
• 漏洩防止：VNet 内に通信を限定することで、機密性の高い設定情報の流出リスクを最小化
• オンプレミス連携：VPN や ExpressRoute を通じて、社内拠点から App Configuration へ安全に接続可能

マネージド ID の活用

マネージド ID を使用すると、Azure App Configuration から Key Vault などの保護されたリソースへ、パスワード管理なしで安全にアクセスできる。

1. マネージド ID の特徴

• 管理の自動化：Azure 側で ID を管理するため、シークレット（パスワード）の発行や定期的な更新（ローテーション）が不要
• 高いセキュリティ：コード内に認証情報を記述する必要がない

2. 2 種類の ID
用途に応じて使い分ける。

• システム割り当て ID：
  • 特徴：App Configuration インスタンスに直接紐付く
  • ライフサイクル：インスタンスを削除すると ID も自動消去される
  • 制限：1 つのストアにつき 1 つまで
• ユーザー割り当て ID：
  • 特徴：独立した Azure リソースとして作成
  • ライフサイクル：ストアを削除しても ID は残る
  • 柔軟性：1 つのストアに複数割り当て可能で、複数のリソース間で共有もできる。

3. Azure CLI での構成例

• システム割り当て ID の追加：

az appconfig identity assign \ 
    --name myTestAppConfigStore \ 
    --resource-group myResourceGroup

• ユーザー割り当て ID の追加：

まず ID リソースを作成 (az identity create)

az identity create --resource-group myResourceGroup --name myUserAssignedIdentity

作成した ID のリソース ID をストアに割り当てる。

az appconfig identity assign --name myTestAppConfigStore \ 
    --resource-group myResourceGroup \ 
    --identities /subscriptions/[subscription id]/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myUserAssignedIdentity

演習 - Azure App Configuration から構成設定を取得する

az group create コマンドを使って、リソースグループを作成する。

az group create --name myResourceGroup --location eastus

変数を作成する。

resourceGroup=myResourceGroup
location=japaneast
appConfigName=appconfigname$RANDOM

az provider register コマンドを使って、Microsoft.AppConfiguration プロバイダーがサブスクリプションに登録されていることを確認する。

az provider register --namespace Microsoft.AppConfiguration

az appconfig create コマンドを使って、App Configuration リソースを作成する。

az appconfig create --location $location --name $appConfigName --resource-group $resourceGroup --sku Free

ユーザー名を変数に保存する。

userPrincipal=$(az rest --method GET --url https://graph.microsoft.com/v1.0/me --headers 'Content-Type=application/json' --query userP
rincipalName --output tsv)

リソースIDを変数に保存する。

resourceID=$(az appconfig show --resource-group $resourceGroup --name $appConfigName --query id --output tsv)

az role assignment create コマンドを使って、ロールを割り当てる。

az role assignment create --assignee $userPrincipal --role "App Configuration Data Reader" --scope $resourceID

キーバリューをセットする。

az appconfig kv set --name $appConfigName --key Dev:conStr --value connectionString --yes

構成情報を取得するためのコンソールアプリを作成する。
作業用ディレクトリを作成し、移動する。

mkdir appconfig
cd appconfig

コンソールアプリを作成する。

dotnet new console

必要なパッケージを追加する。

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.AzureAppConfiguration

Proguram.cs を修正する。

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Configuration.AzureAppConfiguration;
using Azure.Identity;

// Set the Azure App Configuration endpoint, replace YOUR_APP_CONFIGURATION_NAME
// with the name of your actual App Configuration service

string endpoint = "https://YOUR_APP_CONFIGURATION_NAME.azconfig.io";

// Configure which authentication methods to use
// DefaultAzureCredential tries multiple auth methods automatically
DefaultAzureCredentialOptions credentialOptions = new()
{
    ExcludeEnvironmentCredential = true,
    ExcludeManagedIdentityCredential = true
};

// Create a configuration builder to combine multiple config sources
var builder = new ConfigurationBuilder();

// Add Azure App Configuration as a source
// This connects to Azure and loads configuration values
builder.AddAzureAppConfiguration(options =>
{

    options.Connect(new Uri(endpoint), new DefaultAzureCredential(credentialOptions));
});

// Build the final configuration object
try
{
    var config = builder.Build();

    // Retrieve a configuration value by key name
    Console.WriteLine(config["Dev:conStr"]);
}
catch (Exception ex)
{
    Console.WriteLine($"Error connecting to Azure App Configuration: {ex.Message}");
}

アプリを実行する。

dotnet run

Azure portal の構成エクスプローラーからも確認できる。

機能マネージャーから機能フラグを作成、管理できる。