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