Azure Event Hubs は、待機時間が短く信頼性が高く、大量のイベントとデータを取り込んで処理するスケーラブルなイベント処理サービスです。 1 秒あたり何百万ものイベントを受信して処理できます。 イベント ハブに送信されるデータは、リアルタイム分析プロバイダーまたはバッチ処理およびストレージ アダプターを使用して変換および格納できます。
Event Hubs の使用の詳細については、 Azure Event Hubs のドキュメント を参照して、Event Hubs を使用して接続されているデバイスとアプリケーションから 1 秒あたり数百万のイベントを取り込む方法について説明します。
Event Hubs を使用してワークロードのオペレーショナル エクセレンスと信頼性を実現する方法を理解するには、次の記事を参照してください。
次のセクションは、適切に設計されたフレームワークの観点から Azure Event Hubs に固有のものです。
- 設計に関する考慮事項
- 構成チェックリスト
- 推奨される構成オプション
- ソース成果物
設計に関する考慮事項
Azure Event Hubs では、アップタイム SLA が提供されます。 詳細については、 Event Hubs の SLA を参照してください。
チェックリスト
オペレーショナル エクセレンスを念頭に置いて Azure Event Hubs を構成しましたか?
- イベントパブリッシャーとコンシューマーの SendOnly ポリシーと ListenOnly ポリシーをそれぞれ作成します。
- SDK を使用して Event Hubs にイベントを送信する場合は、再試行ポリシー (
EventHubsExceptionまたはOperationCancelledException) によってスローされた例外が正しくキャッチされていることを確認します。 - 高スループットのシナリオでは、バッチ 処理されたイベントを使用します。
- すべてのコンシューマーは、Event Hubs SKU でサポートされている 1 つのパーティションから最大パーティションまでのイベントを読み取ることができます
- 新しいアプリケーションを開発するときは、クライアント SDK として
EventProcessorClient(.NET と Java) またはEventHubConsumerClient(Python と JavaScript) を使用します。 - ソリューション全体の可用性とディザスター リカバリー戦略の一環として、Event Hubs geo ディザスター リカバリー オプションを有効にすることを検討してください。
- ソリューションに多数の独立したイベント 発行元がある場合は、イベント パブリッシャーを使用してきめ細かなアクセス制御を行う方法を検討してください。
- 特定のパーティションにイベントを発行しないでください。
- イベントを頻繁に発行する場合は、可能な場合は AMQP プロトコルを使用します。
- パーティションの数は、実現できるダウンストリーム並列処理の度合いを反映します。
- 使用するアプリケーションごとに個別のコンシューマー グループが使用され、コンシューマー グループごとにアクティブなレシーバーが 1 つだけ配置されていることを確認します。
- キャプチャ機能を使用する場合は、特にイベント ボリュームが少ない場合は、時間枠とファイル サイズの構成を慎重に検討してください。
構成に関する推奨事項
Azure Event Hubs を構成するときの信頼性を最適化するには、次の推奨事項を検討してください。
| 勧告 | 説明 |
|---|---|
SDK を使用して Event Hubs にイベントを送信する場合は、再試行ポリシー (EventHubsException または OperationCancelledException) によってスローされた例外が正しくキャッチされていることを確認します。 |
HTTPSを使用する場合は、適切な再試行パターンが実装されていることを確認します。 |
| 高スループットのシナリオでは、バッチ 処理されたイベントを使用します。 | サービスは、1 つのイベントを含む配列ではなく、複数のイベントを含む json 配列をサブスクライバーに配信します。 使用するアプリケーションは、これらの配列を処理する必要があります。 |
| すべてのコンシューマーは、Event Hubs SKU でサポートされている 1 つのパーティションから最大パーティションまでのイベントを読み取ることができます。 | 使用しているアプリケーションの側で最大スケールを実現するには、すべてのコンシューマーが 1 つのパーティションから読み取る必要があります。 |
新しいアプリケーションを開発するときは、クライアント SDK として EventProcessorClient (.NET と Java) または EventHubConsumerClient (Python と JavaScript) を使用します。 |
EventProcessorHost は非推奨となりました。 |
| ソリューション全体の可用性とディザスター リカバリー戦略の一環として、Event Hubs geo ディザスター リカバリー オプションを有効にすることを検討してください。 | このオプションを使用すると、別のリージョンにセカンダリ名前空間を作成できます。 アクティブな名前空間だけが、いつでもメッセージを受信します。 メッセージとイベントはセカンダリ リージョンにレプリケートされません。 リージョンフェールオーバーの RTO は 最大 30 分です。 このRTOが顧客の要件に合っていること、そしてより広範な可用性戦略に適合していることを確認します。 より高い RTO が必要な場合は、クライアント側のフェールオーバー パターンの実装を検討してください。 |
| ソリューションに多数の独立したイベント 発行元がある場合は、イベント パブリッシャーを使用してきめ細かなアクセス制御を行う方法を検討してください。 | イベント パブリッシャーは、パーティション キーをパブリッシャー名に自動的に設定するため、この機能は、イベントがすべてのパブリッシャーから均等に生成された場合にのみ使用する必要があります。 |
| 特定のパーティションにイベントを発行しないでください。 | 順序付けイベントが不可欠な場合は、ダウンストリームに順序付けを実装するか、代わりに別のメッセージング サービスを使用します。 |
| イベントを頻繁に発行する場合は、可能な場合は AMQP プロトコルを使用します。 | AMQP はセッションの初期化時にネットワーク コストが高くなりますが、 HTTPS 要求ごとに TLS オーバーヘッドが必要です。 AMQP は、頻繁に公開するユーザーのパフォーマンスが高くなります。 |
| パーティションの数は、実現できるダウンストリーム並列処理の度合いを反映します。 | 最大スループットを実現するには、Event Hub の作成時に SKU でサポートされるパーティションの最大数を使用します。 パーティションの数を増やすと、同時処理エンティティをパーティションに合わせてスケーリングできるため、最適な送受信の可用性が確保されます。 |
| キャプチャ機能を使用する場合は、特にイベント ボリュームが少ない場合は、時間枠とファイル サイズの構成を慎重に検討してください。 | Data Lake gen2 では、トランザクション サイズが最小限に抑えられます。 ファイルが最小サイズに達していないほど時間枠を低く設定すると、追加コストが発生します。 |
ソース成果物
Basic SKU で Event Hubs 名前空間を検索するには、次のクエリを使用します。
Resources
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name