Azure App Configuration は 、アプリケーションの構成設定を格納するのに役立ちます。 App Configuration を使用すると、 外部構成ストア パターンをより簡単に実装できます。 この記事では、マルチテナント システムを使用する場合に便利な App Configuration の機能の一部について説明します。 提供されているリンクから、マルチテナント ソリューションで App Configuration を使用する方法のガイダンスと例を示します。
分離モデル
ストアは、App Configuration サービスの 1 つのインスタンスを参照します。
マルチテナント ソリューションでは、次の 2 種類の設定を使用するのが一般的です。
共有設定: グローバル設定や、 デプロイ スタンプ内のすべてのテナントに適用される設定など、複数のテナントに適用します。 多くの場合、共有 App Configuration ストア内にグローバル設定を格納することをお勧めします。 この方法に従うと、設定値の変更時に更新する必要がある場所の数を、最小限に抑えることができます。 また、この方法により、設定が同期を失うリスクも最小限に抑えられます。
テナント固有の設定: 各テナントのデータベース名または内部識別子を指定します。 これらの設定を使用して、テナントごとに異なるログ レベルを指定できます。 たとえば、特定のテナントによって報告された問題を診断し、そのテナントからの診断ログのみを収集する必要があるとします。 複数のテナントのテナント固有の設定を 1 つのストアに結合するか、テナントごとに 1 つのストアをデプロイするかを選択できます。 要件に基づいて決定します。 ソリューションで複数のテナントに単一の共有アプリケーション層が使用される場合には、テナント固有のストアを使用するベネフィットが最小限に抑えられる可能性があります。 しかし、テナント固有のアプリケーション インスタンスをデプロイする場合には、テナント固有の構成ストアをデプロイして、同じ方法をミラーリングするように選択することもできます。
次の表は、App Configuration の主なテナント分離モデルの違いをまとめたものです。
| 考慮事項 | 共有ストア | テナントあたりのストア |
|---|---|---|
| データの分離 | 低。 キー プレフィックスまたはラベルを使用して、各テナントのデータを識別します。 | 高 |
| パフォーマンスの分離 | 低 | 高 |
| デプロイの複雑性 | 低 | 中程度から高い |
| 操作の複雑さ | 低 | 中程度から高い |
| リソース コスト | 低 | 中程度から高い |
| シナリオ例 | 共有アプリケーション層を備えた大規模なマルチテナント ソリューション | 完全に分離されたデプロイを備えた Premium レベルのテナント |
共有ストア
ソリューション全体に共有 App Configuration ストアをデプロイすることも、スタンプごとに 1 つデプロイすることもできます。 その後、すべてのテナントの設定に同じストアを使用できます。 キー プレフィックスまたはラベルを使用して区別します。
テナントごとに大量のデータを格納する必要がある場合、または多数のテナントにスケーリングする必要がある場合は、 1 つのストアのリソース制限を超える可能性があります。 このシナリオでは、展開と管理のコストを最小限に抑えるために、一連の共有ストア間でテナントを共有できるかどうかを検討します。
この方法に従う場合には、適用される リソースのクォータと制限 について理解していることを確認してください。 特に、使用するサービス レベルの合計ストレージ制限に注意し、1 時間あたりの最大要求数を超えないようにしてください。
テナントあたりのストア
代わりに、テナントごとに App Configuration ストアをデプロイすることもできます。 App Configuration Standard レベル は、サブスクリプションに無制限の数のストアをデプロイするのに役立ちます。 ただし、多くの場合、この方法は、より多くのリソースをデプロイして構成する必要があるため、管理が複雑になります。
次のいずれかの状況が該当する場合は、テナント固有のストアを考慮してください。
- カスタマー マネージド キー (CMK) を使用する必要があります。キーはテナントごとに異なります。
- お客様のテナントでは、構成データを他のテナントのデータから分離する必要があります。 App Configuration のアクセス許可はストア レベルで制御されるため、個別のストアを展開することで、個別のアクセス許可を構成できます。
マルチテナントをサポートする App Configuration の機能
マルチテナント アプリケーションで App Configuration を使用する場合、テナント固有の設定を格納および取得するために使用できる機能がいくつかあります。
キー プレフィックス
App Configuration では、アプリケーション設定を表すキーと値のペアを操作します。 キーは、構成設定の名前を表します。 キーに階層的な名前の構造体を使用できます。 マルチテナント型のソリューションでは、キーのプレフィックスとしてテナント識別子を使用することを考慮してください。
たとえば、アプリケーションのログ レベルを示す設定を保存する必要があるとします。 単一テナント ソリューションでは、この設定に LogLevel という名前を付けることもできます。 マルチテナント型のソリューションでは、テナント 1 に tenant1/LogLevel、テナント 2 に tenant2/LogLevel など、階層的なキー名を使用するように選択することもできます。
階層内の長いキー名と複数のレベルを指定できます。 長いキー名を使用する場合は、 キーと値のサイズ制限を理解していることを確認してください。
アプリケーション内に単一のテナントの構成を読み込む場合は、 キー プレフィックスのフィルター を指定して、そのテナントのキーのみ読み込むことができます。 また、アプリケーションで使用できるようにする前に、 キー プレフィックスをキーからトリミング するように App Configuration 用のプロバイダー ライブラリを構成することもできます。 キー プレフィックスをトリミングすると、アプリケーションにとってキー名が一貫性のあるものとなり、そのテナントの値がアプリケーション内に読み込まれます。
ラベル
App Configuration では ラベルもサポートされています。 ラベルを使用すると、同じキーを使用する個別の値を定義できます。
ラベルは、バージョン管理、複数のデプロイ環境の操作、またはソリューション内のその他の目的に役立ちます。 テナント識別子はラベルとして使用できますが、それ以外の場合はラベルを使用できません。 そのため、マルチテナント ソリューションの場合は、通常、テナント固有の設定を管理するために キー プレフィックス を使用し、他の目的でラベルを使用することをお勧めします。
テナントごとにラベルを使用する場合、アプリケーションは ラベル フィルターを使用して特定のテナントの設定のみを読み込むことができます。 この方法は、テナントごとに個別のアプリケーションデプロイがある場合に役立ちます。
アプリケーション側のキャッシュ
App Configuration を使用する場合は、設定を使用するたびに読み込むのではなく、アプリケーション内に設定をキャッシュすることが重要です。 App Configuration プロバイダー ライブラリは設定をキャッシュし、自動的に更新します。
また、アプリケーションが 1 つのテナントまたはすべてのテナントの設定を読み込むかどうかを決定する必要があります。
テナント ベースが拡大するにつれて、すべてのテナントの設定を一緒に読み込むのに必要な時間とメモリが増える可能性があります。 そのため、ほとんどの状況では、アプリケーションにとって必要な時点で、テナントごとに個別に設定を読み込むのが良い方法です。
各テナントの構成設定を個別に読み込む場合、アプリケーションは設定の各セットを他の設定とは別にキャッシュする必要があります。 .NET アプリケーションでは、 メモリ内キャッシュ を使用してテナントの IConfiguration オブジェクトをキャッシュし、キャッシュ キーとしてテナント識別子を使用できます。 メモリ内キャッシュを使用すると、要求ごとに構成を再読み込みする必要はありませんが、アプリケーションにメモリ不足がある場合は、キャッシュで未使用のインスタンスを削除できます。 テナントの構成設定ごとに有効期限切れの時刻を構成することもできます。
寄稿者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主執筆者:
- ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
その他の共同作成者:
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
- 鎮蘭王 |プリンシパル ソフトウェア エンジニアリング マネージャー、アプリ構成
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。