外部設定ストアパターン

アプリケーション展開パッケージから一元化された場所に構成情報を移動します。 この方法により、構成データの管理と制御が容易になり、アプリケーションとアプリケーション インスタンス間で構成データを共有できます。

コンテキストと問題

ほとんどのアプリケーション ランタイム環境には、アプリケーションと共にデプロイするファイルに構成情報が含まれています。 場合によっては、これらのファイルを編集して、アプリケーションをデプロイした後のアプリケーションの動作を変更できます。 ただし、構成を変更するには、アプリケーションを再デプロイする必要があります。 再デプロイすると、多くの場合、許容できないダウンタイムやその他の管理オーバーヘッドが発生します。

ローカル構成ファイルでは、構成も 1 つのアプリケーションに制限されます。 シナリオによっては、複数のアプリケーション間で構成設定を共有することが必要になる場合があります。 たとえば、データベース接続文字列、UI テーマ情報、関連する一連のアプリケーションで使用されるキューとストレージの URL などです。

アプリケーションの複数の実行中のインスタンス間でローカル構成に対する変更を管理することは困難です。 この課題により、更新プログラムのデプロイ中に異なる構成設定を使用するインスタンスが発生する可能性があります。

アプリケーションとコンポーネントの更新には、構成スキーマの変更が必要になる場合もあります。 多くの構成システムでは、さまざまなバージョンの構成情報がサポートされていません。

ソリューション

構成情報を外部ストレージに格納し、構成設定をすばやく効率的に読み取って更新するために使用できるインターフェイスを提供します。 外部ストアの種類は、アプリケーションのホスティング環境とランタイム環境によって異なります。 クラウドでホストされるシナリオでは、外部ストレージは通常、クラウドベースのストレージ サービスまたは専用の構成サービスです。 また、ホストされているデータベースまたはその他のカスタム システムである場合もあります。

構成情報用に選択するバッキング ストアには、一貫性があり使いやすいアクセスを提供するインターフェイスが必要です。 正しく型指定され、構造化された形式で情報を示す必要があります。 実装では、構成データを保護するためにユーザーのアクセスを承認する必要がある場合もあります。 開発、ステージング、運用など、複数のバージョンの構成 (各構成の複数のリリース バージョンを含む) を格納するのに十分な柔軟性が必要な場合があります。

多くの組み込み構成システムは、アプリケーションの起動時にデータを読み取り、データをメモリにキャッシュして高速アクセスを提供し、アプリケーションのパフォーマンスへの影響を最小限に抑えます。 使用するバッキング ストアの種類とこのストアの待機時間によっては、外部構成ストア内にキャッシュ メカニズムを実装することが必要になる場合があります。 詳細については、 キャッシュガイダンスを参照してください。 次の図は、オプションのローカル キャッシュを使用した外部構成ストア パターンの概要を示しています。

問題と考慮事項

このパターンを実装する方法を決定するときは、次の点を考慮してください。

• 許容可能なパフォーマンス、高可用性、堅牢性を提供するバッキング ストアを選択します。 アプリケーションのメンテナンスと管理プロセスでバックアップできることを確認します。 クラウドでホストされるアプリケーションでは、これらの要件を満たすために、クラウド ストレージ メカニズムまたは専用の構成プラットフォーム サービスを使用します。

• バッキング ストアのスキーマを設計して、保持できる情報の種類を柔軟に設定できるようにします。 型指定されたデータ、設定のコレクション、複数のバージョンの設定、アプリケーションで必要なその他の機能など、すべての構成要件に対する機能が提供されていることを確認します。 スキーマは、要件が変更されたときに、より多くの設定をサポートするために簡単に拡張できる必要があります。

• バッキング ストアの物理的な機能、構成情報の格納方法との関係、およびパフォーマンスへの影響を考慮してください。 たとえば、構成情報を含む XML ドキュメントを格納するには、構成インターフェイスまたはアプリケーションがドキュメントを解析して個々の設定を読み取る必要があります。 解析によって設定の更新方法が複雑になりますが、設定をキャッシュすることで、読み取りパフォーマンスの低下を補うことができます。

• 構成インターフェイスで構成設定のスコープと継承の制御を許可する方法を検討します。 たとえば、組織、アプリケーション、コンピューター のレベルで構成設定のスコープを設定する必要がある場合があります。 構成インターフェイスでは、さまざまなスコープへのアクセスの制御を委任し、個々のアプリケーションによる設定のオーバーライドを禁止または許可することが必要になる場合があります。

• 構成インターフェイスで、型指定された値、コレクション、キーと値のペア、プロパティ バッグなど、必要な形式で構成データを公開できることを確認します。

• 設定にエラーが含まれている場合、またはバッキング ストアに存在しない場合の構成ストア インターフェイスの動作を検討してください。 既定の設定とログ エラーを復元することが必要な場合があります。 また、構成設定キーまたは名前の大文字と小文字の区別、バイナリ データを格納および処理する方法、null または空の値を処理する方法についても考慮してください。

• 構成データを保護し、適切なユーザーとアプリケーションにのみアクセス権を付与する方法を検討してください。 通常、構成ストア インターフェイスにはこの機能が用意されていますが、ユーザーとアプリケーションが適切なアクセス許可なしでバッキング ストア内のデータに直接アクセスできないようにする必要もあります。 構成データの読み取りと書き込みに必要なアクセス許可を厳密に分離します。 また、構成設定の一部またはすべてを暗号化する必要があるかどうか、および構成ストア インターフェイスでこの暗号化を実装する方法についても検討してください。

  また、監査ログを有効にして、構成値の読み取りまたは変更を行うユーザーと、これらのアクションがいつ発生するかを記録する必要があります。 構成データのローカル フォールバック コピーに同じ監査要件を適用します。

• 非センショティブな構成値をシークレットから分離します。 機能フラグやエンドポイントなどのルーチン設定は、構成設定に保持します。 接続文字列、API キー、証明書、パスワードなどのシークレットを、暗号化と制御されたアクセスを提供する専用のシークレット管理システムに格納します。

• 実行時にアプリケーションの動作を変更する、一元的に格納された構成が重要です。 アプリケーション コードのデプロイに使用するのと同じメカニズムを使用して、それらをデプロイ、更新、管理します。 たとえば、完全にテストおよびステージングされたデプロイ アプローチを使用して、複数のアプリケーションに影響する可能性のある変更を実行して、この構成を使用するすべてのアプリケーションに変更が適していることを確認する必要があります。 管理者が 1 つのアプリケーションを更新するように設定を編集すると、同じ設定を使用する他のアプリケーションに悪影響を与える可能性があります。 Azure App Configurationなどの製品は、リビジョン履歴、ポイントインタイム リカバリー (PITR)、不変スナップショット、プログレッシブ ロールアウト パターンなどの組み込み機能によって、このリスクを軽減するのに役立ちます。

• アプリケーションが構成情報をキャッシュする場合は、構成が変更されたときにアプリケーションに警告する必要があります。 キャッシュされた構成データの有効期限ポリシーを実装して、この情報が定期的に自動的に更新されるようにすることができます。 アプリケーションは変更を確認し、それらを実装します。

• キャッシュされた構成データは、外部構成ストアがアプリケーションの実行時に発生する一時的な接続の問題に対処するのに役立ちますが、通常、この方法では、アプリケーションの起動時に外部ストアが停止しても問題は解決されません。 アプリケーションのデプロイ パイプラインで、起動時にアプリケーションがライブ値を取得できない場合に使用する構成ファイル内の最後の既知の構成値のセットを指定できることを確認します。

このパターンを使用する場合

このパターンは次の状況で使用します。

• 複数のアプリケーションまたはインスタンス間で構成設定を共有するか、それらの間で標準構成を適用する必要があります。

• 標準構成システムでは、イメージや複雑なデータ構造など、必要なすべての設定の種類がサポートされているわけではありません。

• 一部の設定には補完的なストアが必要ですが、アプリケーションは一元的に格納された値の一部またはすべてをオーバーライドできます。

• 構成ストアへのアクセスを記録することで、複数のアプリケーション間での管理を簡略化し、必要に応じて構成の使用状況を監視する必要があります。

このパターンは、次の場合に適さない場合があります。

• 構成は単純で、1 つのアプリケーションに対してローカルであり、通常のリリース サイクル中にのみ変更されます。 この場合、外部構成ストアによって、不要な操作の複雑さが増す可能性があります。

ワークロード設計

ワークロード設計で外部構成ストア パターンを使用して、Azure Well-Architected Framework の柱で説明されている目標と原則に対処する方法を評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。

このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。

例

次の例では、Azureで外部構成ストア パターンを実装する方法を示します。 最初の例では、App Configuration とクライアント ライブラリを使用します。 2 番目の例では、特殊な実装を必要とするシナリオにカスタム バッキング ストアを使用します。

App Configuration

ほとんどのアプリケーションでは、カスタム構成ストアではなく App Configuration を使用できます。 App Configuration では、名前空間を適用できる キーと値のペア がサポートされています。 App Configuration では、構成の 変更できないスナップショット もサポートされているため、インスタンスを実行するリスクなしに構成の変更を検査、ロールバック、または段階的にデプロイできます。

スナップショット参照を使用して、コードの変更や再デプロイを行わずに、実行時にアプリケーションでスナップショットを切り替えることができます。 構成値をエクスポートして、アプリケーションの起動時にサービスに到達できない場合に使用するバックアップとしてコピーがアプリケーションに付属するようにすることができます。

App Configuration では、 キー と 値 は Unicode 文字列であり、各キーと値のペアには、 ラベルベースのバリアント や コンテンツ タイプなどの省略可能なメタデータがあります。 アプリケーションで値を解釈する方法を説明するために、コンテンツタイプを使用します。これには、JSON や組み込みのアプリケーション設定の種類が含まれます。 また、App Configuration は PITR を使用してリビジョン履歴を保持します。これは、以前のキーと値のペアを確認して回復するのに役立ちます。

回復性を確保するには、 可用性ゾーン をサポートするリージョンにストアをプロビジョニングし、 geo レプリケーション を有効にして、リージョンの停止時に最も近いレプリカから読み取り、レプリカ エンドポイントを切り替えるようにアプリケーションを構成できるようにします。 Azure Key Vault参照を使用して、資格情報を構成ストアに直接格納するのではなく、シークレットをKey Vaultに保持し、App Configuration から参照します。 アプリケーションを App Configuration に対して認証するには、接続文字列の代わりに 管理 ID と Azure ロールベースのアクセス制御 (Azure RBAC) を使用します。

Azure Kubernetes Service (AKS)で実行されるワークロードの場合、App Configuration Kubernetes Provider は、ワークロード コンテナーでコードを変更することなく、ストアから直接 ConfigMap とシークレットを生成できます。 また、App Configuration を使用して、安全なデプロイ プラクティスで、対象となるロールアウトやバリアントベースの実験などの機能フラグを管理することもできます。

ネットワークを分離するためには、App Configuration の プライベート エンドポイント を使用して、クライアント トラフィックを Azure Private Link 経由でプライベート IP アドレスを利用するようにします。 プライベート アクセスを設定したら、 パブリック アクセスをオフに して、パブリック エンドポイントの公開を減らすことができます。 geo レプリケートされたデプロイでは、1 つのプライベート エンドポイントですべてのレプリカにアクセスできますが、リージョンの回復性を高める場合は、各レプリカ リージョンにプライベート エンドポイントをプロビジョニングし、それに応じてドメイン ネーム システム (DNS) を設定できます。

クライアント ライブラリ

クライアント ライブラリには、上記の機能の多くが用意されています。 クライアント ライブラリはアプリケーション ランタイムと統合され、値のフェッチとキャッシュ、変更時の値の更新、App Configuration での一時的な停止の処理に役立ちます。

次の App Configuration sync GitHub Action と組み込みのAzure Pipelines タスクも使用できます。

• アプリ構成エクスポート
• App Configuration のインポート

カスタム バッキング ストアの例

ホストをAzureするアプリケーションでは、Azure Storageを使用して構成情報を外部に格納できます。 この方法では、回復性と高パフォーマンスが提供されます。 既定では、Storage は 1 つのデータセンター内でデータを 3 回レプリケートします。 リージョン間の geo 冗長性のために、手動フェールオーバー機能を使用して geo レプリケーションを設定できます。 Azure Table Storageは、値に柔軟なスキーマを使用できるキーと値のストアを提供します。 Azure Blob Storageは、個別に名前が付けられた BLOB 内の任意の種類のデータを保持できる、階層型のコンテナー ベースのストアを提供します。

このパターンを実装するときは、Blob Storageを抽象化し、アプリケーション内で設定を公開する必要があります。 また、実行時に更新プログラムを確認し、それらの更新に対応する方法を決定する必要があります。

次の例は、単純な構成ストアとBlob Storageを使用して構成情報を格納および公開する方法を示しています。 BlobSettingsStore クラスは、構成情報を保持するためのBlob Storageを抽象化します。 これは、単純な ISettingsStore インターフェイスを実装します。

public interface ISettingsStore
{
    Task<ETag> GetVersionAsync();
    Task<Dictionary<string, string>> FindAllAsync();
}

このインターフェイスは、構成ストアが保持する構成設定を取得するためのメソッドを定義し、最近の構成設定の変更を検出するために使用できるバージョン番号を含みます。 BlobSettingsStore クラスは、BLOB の ETag プロパティを使用して、バージョン管理を実装できます。 ETag プロパティは、BLOB が書き込まれるたびに自動的に更新されます。

ExternalConfigurationManager クラスは、BlobSettingsStore インスタンスのラッパーを提供します。 アプリケーションでは、このクラスを使用して構成情報を取得できます。 このクラスでは、Microsoft Reactive Extensions などの変更通知メカニズムを使用して、システムの実行中に構成の更新プログラムを発行できます。 また、設定の Cache-Aside パターン を実装して、回復性とパフォーマンスを向上させます。

次の例は、 ExternalConfigurationManager クラスを実装する方法を示しています。

static void Main(string[] args)
{
    // Start monitoring configuration changes.
    ExternalConfiguration.Instance.StartMonitor();

    // Get a setting.
    var setting = ExternalConfiguration.Instance.GetAppSetting("someSettingKey");
    …
}

次のステップ

• App Configuration のサンプル
• Helm を使用して App Configuration と Kubernetes デプロイを統合する
• App Configuration で機能フラグを管理する
• キャッシュのガイダンス
• App Configuration のベスト プラクティス

関連リソース

• Cache-Aside パターン