マルチテナント機能と Azure Event Hubs

  • [アーティクル]

Event Hubs はビッグ データのストリーミング プラットフォームであり、毎秒数百万のイベントを受け取って処理できるイベント インジェスト サービスです。 リアルタイム分析プロバイダーやバッチ処理/ストレージ アダプターを使用して、データを変換して格納できます。 Event Hubs と他の Azure メッセージング サービスの比較については、「Azure メッセージング サービスの中から選択する - Azure Event Grid、Event Hubs、および Service Bus」を参照してください。

この記事では、マルチテナント ソリューションで使用できる Event Hubs の機能と分離モデルについて説明します。

分離モデル

マルチテナント システムで Event Hubs を使用するときは、目的の分離レベルを決定する必要があります。 Event Hubs では、さまざまなマルチテナント機能をサポートしています。

  • 信頼されたマルチテナント機能: すべてのテナントが Event Hubs 名前空間を共有します。 この選択は、すべてのテナントが組織内にあるときに適しています。
  • 敵対的なマルチテナント機能: 各テナントに、共有されない独自の名前空間があります。 この選択は、テナントにうるさい隣人の問題がないようにするときに適しています。

1 つのシステムで、一部のテナントが名前空間を共有し、他のテナントが専用の名前空間を持つことで、両方のモデルを実装できます。 テナントは名前空間を他のテナントと共有できますが、専用のイベント ハブを持つこともできます。

次の表に、Event Hubs の主なテナント機能分離モデル間の相違点を要約します。 モデルについては、以降のセクションで詳しく説明します。

考慮事項 専用の名前空間 共有名前空間、専用イベント ハブ 共有の名前空間とイベント ハブ
データの分離 高 Medium なし
パフォーマンスの分離 最高。 各テナントの要件に基づいてパフォーマンスのニーズを管理します。 中。 うるさい隣人の問題の可能性があります。 低。 うるさい隣人の問題の可能性があります。
デプロイの複雑性 中。 サブスクリプション レベルで Event Hubs のクォータと制限を認識します。 中。 テナントごとに個別のメッセージ エンティティをデプロイする必要があります。 Event Hubs のクォータと制限を認識します。 テナントの数によっては、複数の名前空間が必要です。 低
操作の複雑さ 高。 テナントごとに名前空間を管理する必要があります。 中。 一部のテナントでは、メッセージ エンティティの詳細な管理が必要です。 低
シナリオ例 テナントごとに別個のアプリケーション インスタンス。 テナントごとに専用のイベント ハブ。 共有アプリケーション層と 1 つ以上の共有イベント ハブがある大規模なマルチテナント ソリューション。

Note

Event Hubs for Apache Kafka は、Event Hubs を Apache Kafka アプリケーションで使用できるように、Event Hubs 上にプロトコル ヘッドを提供する機能です。 アプリケーションは、Kafka トピックと同等のイベント ハブにイベントをストリーミングします。 詳細については、「Apache Kafka 用の Azure Event Hubs とは」を参照してください。

専用の名前空間

このモデルでは、テナントごとに Event Hubs 名前空間をプロビジョニングします。 この方法では、分離の最大レベルと、許容できるパフォーマンスをすべてのテナントに提供する能力がもたらされます。

次の手法を使用して、テナントの要件を満たすようにイベント機能を微調整できます。

Azure サブスクリプション内の Event Hubs 名前空間の最大数に達した場合は、デプロイ スタンプ パターンを使用して、異なるサブスクリプションにまたがって名前空間をデプロイできます。

分離モデルのデメリットは、時間の経過とともにテナントの数が増えるにつれて、名前空間の管理が複雑になることです。 もう 1 つのデメリットは、名前空間ごとに料金を支払うため、このモデルではコストが増大することです。

共有名前空間、専用イベント ハブ

名前空間が複数のテナントで共有されている場合でも、テナントを専用のイベント ハブに分離できます。 Shared Access Signature または Microsoft Entra ID を使ってアクセスを制御できます。

システム内のテナントの数が増えるにつれて、各テナントに対応するイベント ハブの数も増加します。 この増加により、運用コストが高くなり、組織の機敏性が低下する可能性があります。 名前空間あたりのイベント ハブの数には制限があります。 このため、システムに必要な名前空間の数は、テナントに必要なイベント ハブの数によって異なります。

名前空間が共有されていると、うるさい隣人問題が発生する可能性が高くなります。 たとえば、あるテナントのイベント エンティティによる名前空間リソースの消費量が不均衡になって、他のテナントの妨げになる可能性があります。 イベント ハブの名前空間には、処理ユニット (Premium レベル) または容量ユニット (専用レベル) と、名前空間へのブローカー接続の数に制限があります。 1 つのテナントが多すぎるリソースを消費する可能性があるかどうかを検討します。

共有の名前空間とイベント ハブ

すべてのテナントで共有される名前空間とイベント エンティティを持つことができます。 このモデルでは、運用の複雑さが減少し、リソース コストが削減されます。

ただし、共有名前空間を使用すると、うるさい隣人問題が発生して、一部のテナントの待機時間が長くなる可能性があります。 複数のテナントにサービスを提供するアプリケーションを実装する必要もあります。 共有イベント ハブと Kafka トピックでは、テナント間のデータ分離が提供されないため、アプリケーション ロジックでデータ分離要件を満たす必要があります。

Note

テナントを分離に、Event Hubs のパーティションを使用しないでください。 Event Hubs でのパーティション分割により、イベントとスケーラビリティを処理できるようになりますが、これは分離モデルではありません。 イベントをパーティションに直接送信できますが、イベント ハブの可用性がパーティション レベルにダウングレードされるため、これを行うことはお勧めしません。 詳細については、「Event Hubs における可用性と一貫性」を参照してください。

マルチテナント機能をサポートする Event Hubs の機能

マルチテナント機能をサポートする Event Hubs の機能は次のとおりです。

これらの機能について、以降のセクションで説明します。

アプリケーション グループ

アプリケーション グループは、Event Hubs のデータ プレーンと対話する 1 つ以上のクライアント アプリケーションのコレクションです。 クォータとアクセス管理ポリシーは、グループ自体に適用することで、グループ内のすべてのアプリケーションに適用できます。

各アプリケーション グループのスコープは、1 つの Event Hubs 名前空間にも 1 つのイベント ハブにも設定できます。 セキュリティ コンテキスト (Shared Access Signature (SAS) または Microsoft Entra アプリケーション ID) などの、クライアント アプリケーションの一意に識別される条件識別子を使う必要があります。

詳細については、「アプリケーション グループを使用したリソース管理」を参照してください。

Microsoft Entra 認証

Event Hubs は Microsoft Entra ID と統合されています。 クライアントは、Microsoft Entra ID でマネージド ID を使って Event Hubs リソースに対して認証できます。 Event Hubs には、Event Hubs エンティティにアクセスするためにテナントに付与できる一連の組み込みロールが定義されています。 たとえば、Microsoft Entra 認証を使うと、そのテナントへのメッセージがあるイベント ハブに対するテナント アクセス権を付与できます。 この手法を使用して、テナントを他のテナントから分離できます。

Kafka アプリケーションでは、マネージド ID OAuth を使用して Event Hubs リソースにアクセスできます。

詳細については、次の記事を参照してください。

共有アクセス署名

Shared Access Signature (SAS) を使用すると、特定の権限を使用して、テナントに Event Hubs リソースへのアクセス権を付与できます。 イベント エンティティ レベルでテナントを分離することを選択した場合は、特定のテナントにのみ適用されるイベント ハブまたは Kafka トピックに SAS キーを付与できます。

詳細については、「Shared Access Signature (SAS) を使用して Event Hubs リソースへのアクセスを認証する」を参照してください

カスタマー マネージド キー

テナントでイベントの暗号化と暗号化解除に独自のキーが必要な場合は、一部のバージョンの Event Hubs でカスタマー マネージド キーを構成できます。

この機能は、専用の名前空間分離モデルを使用することを必要とします。 暗号化を有効にできるのは、新しいか空の名前空間のみです。

詳細については、「Azure Event Hubs の保存データを暗号化するためにカスタマー マネージド キーを構成する方法」を参照してください。

Event Hubs Capture

Event Hubs Capture 機能を使用して、Event Hubs からストリーミング データを自動的にキャプチャし、それを Azure Blob Storage または Data Lake Storage アカウントに格納できます。

この機能は、イベントのアーカイブに便利です。 たとえば、コンプライアンス上の理由からテナントのイベントをアーカイブする必要がある場合は、テナント固有の名前空間をデプロイし、Event Hubs Capture を有効にして、テナント固有の Azure Storage アカウントにイベントをアーカイブできます。 共有名前空間内のテナント固有のイベント ハブで Event Hubs Capture を有効にすることもできます。

詳細については、「Azure Event Hubs で Azure Blob Storage または Azure Data Lake Storage にイベントをキャプチャする」を参照してください

geo ディザスター リカバリー

geo ディザスター リカバリーでは、Event Hubs 名前空間の構成全体がプライマリ名前空間からプライマリとペアになったセカンダリ名前空間に継続的にレプリケートされます。 この機能は、リージョンの障害などの災害から復旧するのに役立ちます。

たとえば、テナントを名前空間レベルで分離する場合は、テナント名前空間の構成をセカンダリ リージョンにレプリケートして、プライマリの故障や障害に備えた保護を実現できます。

詳細については、「Azure Event Hubs geo ディザスター リカバリー」を参照してください。

Note

geo ディザスター リカバリーでは、運用の継続性を守るために、プライマリ名前空間の構成がセカンダリ名前空間にレプリケートされます。 イベント データはレプリケートされず、プライマリ名前空間に使う Microsoft Entra RBAC の割り当てもレプリケートされません。 詳細については、「マルチサイトとマルチリージョンのフェデレーション」を参照してください。

IP ファイアウォール規則

IP ファイアウォール規則を使用して、名前空間へのアクセス権を制御できます。 名前空間レベルでテナントを分離すると、許可された IP アドレスまたはアドレス範囲から発信されたクライアントからの接続のみを受け入れるように名前空間を構成できます。

詳細については、次を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Will Velida | カスタマー エンジニア 2、FastTrack for Azure

その他の共同作成者:

  • John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順