複数の内部および外部サービスを含む分散アプリケーションには、非同期メッセージングとイベント ドリブン通信が必要です。 マルチテナント ソリューションを設計するときは、異なるテナントに属するメッセージを共有またはパーティション分割する方法を決定する必要があります。
すべてのテナントでメッセージング システムまたはイベント ストリーミング サービスを共有して、運用コストと管理の複雑さを軽減できます。 また、テナントごとに専用のメッセージング システムを使用して、データの分離を改善し、データ漏えいのリスクを軽減し、 ノイズの多い近隣の問題を排除し、Azure のコストをより簡単にテナントに請求することができます。
この記事は、ソリューション アーキテクトがマルチテナント ソリューションでメッセージングまたはイベント インフラストラクチャを使用する方法を決定するのに役立ちます。
メッセージ、データ ポイント、個別イベント
イベントを配信するサービスとメッセージを送信するシステムの違いを理解する必要があります。 イベントは、条件または状態の変化に関する軽量の通知です。 イベントは通常、既に発生した内容を表します。 メッセージには、サービスが他の場所で使用または格納するために生成する生データが含まれています。 メッセージは暗黙的な命令または要求です。
次の表では、主要なメッセージングの種類と、その種類のエンティティを使用する可能性があるマルチテナント ソリューションの例について説明します。
| エンティティ型 | 内容 | 例示 |
|---|---|---|
| 個別イベント: | 発行アプリケーションが実行する特定のアクションに関する情報 |
|
| 系列イベント | 連続するストリーム内の情報データポイント |
|
| メッセージ | 受信サービスがワークフローまたは処理チェーンでステップを実行するために必要な情報 |
|
詳細については、「 データに適した Azure メッセージング サービスを選択する」を参照してください。
Azure には、メッセージング要件をサポートできるメッセージング サービスがいくつか用意されています。 これらのサービスには、 Azure Event Hubs、 Azure Event Grid、 Azure Service Bus が含まれます。 詳細については、「 Azure メッセージング サービスの選択」を参照してください。
また、仮想マシン (VM)、コンテナー、または Azure Kubernetes Service (AKS) などのサービスに独自のメッセージング サービスをデプロイして管理することもできます。 この方法では、メッセージング インフラストラクチャをデプロイ、管理、および保守する必要があります。
主な考慮事項と要件
ソリューションに対して選択する デプロイとテナント モデル は、セキュリティ、パフォーマンス、データの分離、管理、テナントへのリソース コストのクロスチャージ機能に影響します。 この分析を行う場合は、メッセージングおよびイベント インフラストラクチャ用に選択したモデルも検討してください。 次のセクションでは、マルチテナント ソリューションでメッセージング システムを計画する際に行う必要がある主な決定事項について説明します。
スケール
メッセージングまたはイベント インフラストラクチャを計画する場合は、テナントの数、メッセージ フローとイベントストリームの複雑さ、メッセージの量、予想されるトラフィック プロファイル、分離レベルを考慮してください。
まず、容量を計画し、メッセージング システムの最大スループット容量を確立します。 この計画は、通常のトラフィックとピーク時のメッセージの予想される量を適切に処理するのに役立ちます。
ソリューションで多数のテナントを処理し、テナントごとに個別のメッセージング システムがある場合は、一貫した自動化戦略を適用します。 この戦略では、各インフラストラクチャのデプロイ、監視、アラート、スケーリングを自動化する必要があります。
たとえば、プロビジョニング プロセス中にテナントのメッセージング システムをデプロイするには、Terraform、Bicep、Azure Resource Manager テンプレート (ARM テンプレート) などのコードとしてのインフラストラクチャ (IaC) ツールと、Azure DevOps や GitHub Actions などの DevOps システムを使用します。 詳細については、「 マルチテナント ソリューションのデプロイと構成のアーキテクチャアプローチ」を参照してください。
メッセージング システムのサイズは、時間単位のメッセージで最大スループットで設定できます。 システムが動的自動スケーリングをサポートしている場合は、予想されるサービス レベル アグリーメント (SLA) を満たすために、トラフィックの状態とメトリックに基づいて容量を自動的に増減できます。
パフォーマンスの予測可能性と信頼性
1 つのメッセージング システムが機能スループット要件を満たし、総保有コスト (TCO) を削減できるテナントはごくわずかです。 マルチテナント アプリケーションは、複数の顧客間で同じメッセージング エンティティ (キューやトピックなど) を共有する場合があります。 また、テナントの分離を強化するために、テナントごとに専用のコンポーネント セットを使用することもできます。 ただし、複数のテナント間で共有メッセージング インフラストラクチャを使用すると、ソリューション全体が ノイズの多い近隣の問題にさらされる可能性があります。 1 つのテナントのアクティビティによって、他のテナントのパフォーマンスと操作性が中断される可能性があります。
この場合は、ピーク時に予想されるトラフィック負荷を維持するために、メッセージング システムのサイズを適切に設定する必要があります。 理想的には、システムは自動スケールをサポートする必要があります。この自動スケールは、トラフィックが増加したときに動的にスケールアウトされ、トラフィックが減少したときにスケールインされます。 テナントごとに専用のメッセージング システムを使用すると、ノイズの多い近隣のリスクを軽減することもできますが、多くのメッセージング システムを管理すると、ソリューションの複雑さが増します。
マルチテナント アプリケーションでは、ハイブリッド アプローチを使用できます。 このアプローチでは、コア サービスは、1 つの共有メッセージング システムで同じキューとトピックのセットを使用して、内部の非同期通信を実装します。 これに対し、他のサービスでは、各テナントの専用のメッセージング エンティティ グループや専用メッセージング システムを採用して、ノイズの多い近隣の問題を軽減し、データの分離を保証できます。
管理と運用の複雑さ
最初から、メッセージングおよびイベント インフラストラクチャの運用、監視、保守の方法と、マルチテナント アプローチが運用とプロセスに与える影響を計画します。 たとえば、次の要因を考えてみましょう。
複数のテナント間でメッセージング システムを共有する場合は、ソリューションが各テナントの使用状況メトリックを収集して報告する方法、または各テナントが送受信できるメッセージの数を調整する方法を定義します。
テナントを別の種類のメッセージング サービス、別のデプロイ、または別のリージョンに移動する必要がある場合は、それらを移行する方法を決定します。
メッセージング システムでサービスとしてのプラットフォーム (PaaS) オファリングを使用する場合は、次の考慮事項を考慮してください。
テナントが要求する機能と共有または専用の分離レベルに基づいて、各テナントの価格レベルをカスタマイズします。
テナント固有のマネージド ID と Azure ロールの割り当てを作成して、テナントがアクセスするメッセージング エンティティにのみ適切なアクセス許可を割り当てます。 たとえば、「 Service Bus リソースにアクセスするための Microsoft Entra ID を使用してマネージド ID を認証する」を参照してください。
アプリケーションで使用するメッセージング システムを専用の VM またはコンテナー (テナントごとに 1 つ) でホストすることを選択した場合は、これらのシステムのデプロイ、アップグレード、監視、スケールアウトの方法を定義します。
[コスト]
一般的に、お使いのデプロイ インフラストラクチャに対するテナントの密度が高いほど、そのインフラストラクチャのプロビジョニング コストは低くなります。 しかし、共有インフラストラクチャは 、ノイズの多い隣人の問題のような問題の可能性を高めます。 トレードオフを慎重に検討してください。
考慮すべきアプローチとパターン
メッセージングを含むマルチテナント ソリューションを計画する場合は、テナント間の分離レベルを検討してください。 次の考慮事項と観察を確認します。
暗号化キー: メッセージの暗号化と暗号化解除にテナントが独自のキーを必要とする場合は、メッセージング サービスでキーの分離がどのようにサポートされているかを確認します。 たとえば、Service Bus を使用する場合は、独自のキーを必要とするテナントごとに個別の Service Bus Premium 名前空間を作成する必要がある場合があります。 この分離により、 カスタマー マネージド キー (CMK) を使用できます。
ビジネス継続性: 高レベルの回復性とビジネス継続性を必要とするテナントを特定します。 利用可能な場合は、これらのテナントのゾーン冗長性、ジオ冗長性、ジオ災害復旧機能を検討してください。
ワーカー処理: テナントごとに個別のキュー リソースまたは専用メッセージング システムを使用する場合は、テナントごとに個別のワーカー プロセス プールを採用できます。 この方法により、データ分離レベルが向上し、複数のメッセージング エンティティを管理する複雑さが軽減されます。
処理システムの各インスタンスは、専用メッセージング システムにアクセスするために、接続文字列、サービス プリンシパル、マネージド ID などの異なる資格情報を採用できます。 この方法により、テナント間のセキュリティと分離が向上しますが、ID 管理の複雑さが増します。
共有メッセージング システム
1 つの Service Bus 名前空間などの共有メッセージング システムをデプロイし、すべてのテナントで共有できます。
この方法では、インフラストラクチャにテナントの密度が最も高く、TCO 全体が削減されます。 多くの場合、単一のメッセージング システムまたはリソースを管理してセキュリティで保護するだけで済むため、管理オーバーヘッドが軽減されます。
ただし、複数のテナント間でリソースまたはインフラストラクチャ全体を共有する場合は、次の制限事項を考慮してください。
リソースの制約、スケーリング機能、クォータ、制限を考慮してください。 たとえば、 1 つの名前空間内の Event Hubs の最大数や最大スループット制限は、最終的に、より多くのテナントをサポートするためにアーキテクチャが拡大すると阻害要因になる可能性があります。
複数のテナント間でリソースを共有する場合、特にビジー状態のテナントやテナントが他のテナントよりも高いトラフィックを生成している場合は、 ノイズの多い近隣の問題 が要因になる可能性があります。 これらの影響を軽減するには、 調整パターン または レート制限パターンを検討してください。 たとえば、1 つのテナントが一定期間内に送受信できるメッセージの最大数を制限できます。
アクティビティを監視し、個々のテナント のリソース消費量を測定 するのに苦労する場合があります。 Service Bus の特定のレベルなど、一部のサービスはメッセージング操作に対して課金されます。 複数のテナント間で名前空間を共有する場合、アプリケーションは、各テナントが生成するメッセージング操作の数と、それに関連するチャージバック コストを追跡する必要があります。 一方で、同じレベルの詳細情報を提供していないサービスもあります。
テナントには、セキュリティ、リージョン内の回復性、ディザスター リカバリー、または場所に関する要件が異なる場合があります。 これらの要件がメッセージング システムの構成と一致しない場合は、1 つのリソースのみで対応できない可能性があります。
シャーディング パターンを使用する
シャーディング パターンには、シャードとも呼ばれる複数のメッセージング システムをデプロイする必要があります。 各シャードには、キューやトピックなどの1つまたはそれ以上のテナントのメッセージングエンティティが含まれています。 デプロイ スタンプとは異なり、シャードはインフラストラクチャ全体を複製することを意味しません。 ご自身のソリューション内で他のインフラストラクチャを複製またはシャード化せずに、メッセージング システムをシャード化できます。
すべてのメッセージング システムまたは "シャード" は、信頼性、SKU、場所という点で特性が異なる場合があります。 たとえば、パフォーマンス、信頼性、データ保護、またはビジネス継続性の場所や要件に基づいて、複数のメッセージング システム間でテナントをシャード化できます。
シャーディング パターンを使用する場合は、 シャーディング戦略を 使用して、特定のテナントを、そのキューを含むメッセージング システムにマップする必要があります。 ルックアップ戦略では、マップを使用して、テナント名または ID に基づいてターゲット メッセージング システムを識別します。 複数のテナントが同じシャードを共有する場合がありますが、1 つのテナントが使用するメッセージング エンティティは 1 つのシャード内にとどまります。
マップは、各テナント名をターゲット メッセージング システムの名前または参照にリンクするディクショナリとして実装できます。 マルチテナント アプリケーションのすべてのインスタンスがアクセスできる分散キャッシュにマップを格納したり、リレーショナル データベースやストレージ アカウントのテーブルなどの永続的なストアに格納したりできます。
シャーディング パターンは、複数のテナントをサポートするようにスケーリングできます。 ワークロードによっては、テナントがシャードに高密度に分散されることでコスト削減につながる可能性があります。 シャーディング パターンを使用して、 Azure サブスクリプションとサービスのクォータ、制限、制約に対処することもできます。
テナントごとに専用メッセージング システムでマルチテナント アプリを使用する
また、テナントごとに専用メッセージング システムを使用する 1 つのマルチテナント アプリケーションをデプロイすることもできます。 このテナント モデルには、コンピューティング リソースなど、いくつかの共有コンポーネントが含まれています。 シングルテナントの専用デプロイ アプローチを使用して、他のサービスをプロビジョニングおよび管理します。 たとえば、次の図に示すように、1 つのアプリケーション層を構築し、テナントごとに個別のメッセージング システムをデプロイできます。
特定のコンポーネントによってシステムの負荷の大部分が生成され、テナントごとにこれらのコンポーネントを個別にデプロイできる場合は、水平方向にパーティション分割されたデプロイを使用して、ノイズの多い近隣の問題を減らします。 たとえば、1 つのインスタンスが複数のテナントによって生成されるトラフィックに対応できない場合は、テナントごとに個別のメッセージングまたはイベントストリーム システムを使用します。 テナントごとに専用メッセージング システムを使用する場合、1 つのテナントからの大量のメッセージまたはイベントが共有コンポーネントに影響を与える可能性がありますが、他のテナントのメッセージング システムには影響しません。
テナントごとに専用リソースをプロビジョニングするため、多くの場合、この方法は共有ホスティング モデルよりもコストがかかります。 ただし、使用するリソースに対して各テナントに課金する簡単な方法も提供されます。 この方法を使用すると、コンピューティング リソースなどの他のサービスの高密度を実現し、これらのコンポーネントのコストを削減できます。
水平方向にパーティション分割されたデプロイでは、マルチテナント アプリケーションのサービス (特に 1 つのテナントが使用するサービス) をデプロイおよび管理するための自動化されたプロセスが必要です。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパル作成者:
- パオロ・サルヴァトリ |プリンシパル カスタマー エンジニア、FastTrack for Azure
その他の共同作成者:
- ダフネ・チョン |シニア パートナー ソリューション アーキテクト
- ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
- クレメンス・ヴァスターズ |プリンシパル アーキテクト、メッセージング サービスおよび標準
- アルセン・ウラジミルスキー |プリンシパル カスタマー エンジニア、FastTrack for Azure
関連リソース
メッセージングの設計パターンの詳細については、次のリソースを参照してください。