外部構成ストア パターン

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

コンテキストと問題

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

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

アプリケーションの複数の実行インスタンス全体でローカル構成の変更を管理することが困難になります。クラウドホスト型のシナリオの場合は特に困難です。 インスタンスは異なる構成設定を使用することになりますが、更新プログラムはデプロイされます。

さらに、アプリケーションとコンポーネントの更新プログラムでは、構成スキーマの変更が必要になることがあります。 多くの構成システムは、異なるバージョンの構成情報をサポートしていません。

解決策

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

構成情報のために選択するバッキング ストアには、一貫した使いやすいアクセスを提供するインターフェイスがあるものをお勧めします。 正しく入力され、構造化された形式で情報を公開します。 実装では、必要に応じてユーザーのアクセスを認可して、構成データを保護するようにします。また、複数バージョンの構成 (それぞれの複数リリース バージョンを含め、開発、ステージング、運用など) のストレージを許容できるように柔軟にします。

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

問題と注意事項

このパターンの実装方法を決めるときには、以下の点に注意してください。

許容できるパフォーマンス、高可用性、堅牢性を提供し、アプリケーション保守と管理プロセスの一部としてバックアップすることができるバッキング ストアを選択します。 クラウドホスト型アプリケーションの場合、これらの要件を満たすには、通常、クラウド ストレージ メカニズムまたは専用構成プラットフォーム サービスを使用することをお勧めします。

保持できる情報の種類に柔軟性を持たせるようにバッキング ストアのスキーマを設計します。 型指定されたデータ、設定のコレクション、複数バージョンの設定、使用するアプリケーションに必要なその他の機能など、すべての構成要件に備えるようにします。 要件の変更に応じて追加の設定をサポートできるように、拡張しやすいスキーマにします。

バッキング ストアの物理機能、構成情報を格納する方法と関連付ける方法、およびパフォーマンスに対する影響を検討します。 たとえば、構成情報を含む XML ドキュメントの保存には、個々の設定を読み取るために、ドキュメントを解析できる構成インターフェイスまたはアプリケーションが必要です。 設定の更新は複雑になりますが、設定のキャッシュによって、読み取りパフォーマンスの低下と相殺することができます。

構成インターフェイスで、構成設定の範囲と継承の制御を許可する方法を検討します。 たとえば、構成設定の範囲を組織、アプリケーション、およびコンピューター レベルに設定する要件が考えられます。 必要に応じて、異なる範囲に対するアクセスの制御の委任をサポートし、個々のアプリケーションが設定をオーバーライドすることを禁止または許可します。

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

設定にエラーが含まれる場合、または設定がバッキング ストアに存在しない場合の、構成ストア インターフェイスの動作方法を検討します。 既定の設定とログ エラーを返すことが適切な場合もあります。 また、構成設定のキーや名前の大文字と小文字の区別、バイナリ データの保存と処理、null 値または空の値の処理方法などの側面も検討します。

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

一元的に保存されている構成で、実行時にアプリケーションの動作を変更する構成は非常に重要です。アプリケーション コードのデプロイと同じメカニズムを使用して、デプロイ、更新、および管理することをお勧めします。 たとえば、複数のアプリケーションに影響する可能性がある変更は、その構成を使用するすべてのアプリケーションにその変更が適切できることを確認するために、完全なテストと段階的なデプロイ手法を使用して実施する必要があります。 管理者が 1 つのアプリケーションを更新するように設定を編集する場合、同じ設定を使用する他のアプリケーションに悪影響が出る可能性があります。

アプリケーションが構成情報をキャッシュしている場合、構成が変更されたときにアプリケーションは通知を受ける必要があります。 その情報が定期的に自動更新され、すべての変更が取得 (および実行) されるように、キャッシュされている構成データに対して有効期限ポリシーを実装することができます。

構成データをキャッシュすると、アプリケーション ランタイムでの外部構成ストアとの接続に関する一時的な問題に対処できますが、通常、アプリケーションを最初に起動したときに外部ストアが停止している場合、問題は解決されません。 アプリケーションで起動時にライブ値を取得できない場合に、構成ファイル内の最後に認識された構成値のセットをフォールバックとしてアプリケーション配置パイプラインで提供できることを確認します。

このパターンを使用する状況

このパターンは次の目的に役立ちます。

• 複数のアプリケーションとアプリケーション インスタンス間で構成設定を共有する場合、または標準の構成を複数のアプリケーションとアプリケーション インスタンス全体に適用する必要がある場合。

• 画像や複雑なデータ型の格納など、必要なすべての構成設定をサポートしない標準の構成システム。

• 一元的に保存されている設定の一部またはすべてをアプリケーションでオーバーライドできるようにする場合など、アプリケーションの一部の設定の補完的なストアとして。

• 複数のアプリケーションの管理を簡易化する方法として。また、必要に応じて、構成ストアに対する一部またはすべての種類のアクセスをログに記録して、構成設定の使用を監視するため。

ワークロード設計

設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、外部設定ストア パターンをワークロードの設計でどのように使用できるかを評価する必要があります。 次に例を示します。

設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。

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

Microsoft Azure でホストされるアプリケーションの場合、構成情報を外部に保存するために可能な選択肢は、Azure Storage を使用することです。 Azure Storage は回復力があり、パフォーマンスが高く、自動フェールオーバーで 3 回レプリケートされるので、高可用性を実現できます。 Azure Table Storage には、値に柔軟なスキーマを使用できる機能を持つキー/値のストアが用意されています。 Azure Blob ストレージには、個別の名前の BLOB に任意の種類のデータを保持できる階層型でコンテナーベースのストアが用意されています。

このパターンを実装する場合は、お客様が Azure Blob ストレージを抽象化し、アプリケーション内の設定を公開する責任があります。これには、実行時の更新の確認と、それらにどのように対応するかが含まれます。

次の例は、構成情報の格納と公開に使用する単純な構成ストアを BLOB ストレージで構想する方法を示しています。 構成情報を保持できるように BlobSettingsStore クラスで BLOB ストレージを抽象化し、単純な ISettingsStore インターフェイスを実装できます。

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

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

設計により、この単純な例では、すべての構成設定を型指定された値ではなく文字列値として公開します。

ExternalConfigurationManager クラスでは、BlobSettingsStore インスタンスのラッパーを提供できます。 アプリケーションではこのクラスを使用して、構成情報を取得できます。 このクラスでは、Microsoft リアクティブ拡張機能などを使用して、システムの実行中に構成に加えられた変更を公開できます。 また、設定のキャッシュアサイド パターンを実装して、回復性とパフォーマンスを向上させる役割もあります。

次のように使用します。

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

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

Azure App Configuration の使用

状況によっては、カスタム構成ストアの構築が必要になる場合がありますが、多くのアプリケーションでは代わりに Azure App Configuration を使用できます。 Azure App Configuration では、名前空間を設定できるキーと値のペアがサポートされています。 キーは型指定され、個別にバージョン管理されます。 Azure App Configuration では、構成の特定の時点のスナップショットもサポートしているので、以前の構成値を簡単に検査またはロールバックすることができます。 アプリケーションの開始時にサービスに到達できない場合のために、構成のコピーをアプリケーションと共に配布できるように、構成値をエクスポートできます。

クライアント ライブラリ

これらの機能の多くは、アプリケーション ランタイムと統合されるクライアント ライブラリを通じて公開されます。これにより、値のフェッチとキャッシュ、変更時の値の更新、App Configuration サービスの一時的な停止への対応が容易になります。

クライアント ライブラリに加えて、Azure App Configuration の同期 GitHub アクションと Azure App Configuration のプルおよび Azure App Configuration のプッシュ Azure DevOps タスクもあります。これにより、構成手順をビルド プロセスに統合できます。

次のステップ

• App Configuration のその他のサンプルを確認する
• Azure App Configuration を Kubernetes デプロイと統合する方法を学習する
• Azure App Configuration を使用して機能フラグを管理する方法を学習する