Azure Event Hubs に対する Azure Well-Architected フレームワークの分析観点
Azure Event Hubs は、大量のイベントやデータを取り込んで処理するスケーラブルなイベント処理サービスで、短い待機時間と高い信頼性を実現します。 1 秒間に何百万ものイベントを受信して処理することができます。 イベント ハブに送信されたデータは、任意のリアルタイム分析プロバイダーやバッチ処理/ストレージ アダプターを使用して、変換および保存できます。
Event Hubs の使用方法の詳細については、 Azure Event Hubs のドキュメントを参照してください。 Event Hubs を使用して、接続されているデバイスやアプリケーションから 1 秒間に数百万ものイベントを取り込む方法について説明します。
Event Hubs を使用してワークロードのオペレーショナル エクセレンスと信頼性を実現する方法については、次の記事を参照してください。
次のセクションは、Well-Architected フレームワークの分析観点から 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 の方が高パフォーマンスになります。 |
| パーティションの数は、実行できるダウンストリーム並列処理の次数を反映しています。 | スループットを最大化するには、イベント ハブを作成するときに、SKU でサポートされる最大数のパーティションを使用します。 パーティションの数を増やすと、同時処理エンティティをパーティションに合わせてスケーリングできるため、最適な送受信の可用性が確保されます。 |
| キャプチャ機能を使用する場合は、時間枠とファイル サイズの構成を慎重に検討してください (特に低イベント ボリュームの場合)。 | Data Lake gen2 では、料金のトランザクション サイズが最小限に抑えられます。 ファイルが最小サイズに達しないほど時間枠を短く設定すると、追加コストが発生します。 |
ソース成果物
Basic SKU を使用する Event Hubs 名前空間を検出するには、次のクエリを使用します。
Resources
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name