Event Hubs と信頼性

  • [アーティクル]

Azure Event Hubs は、大量のイベントやデータを取り込んで処理するスケーラブルなイベント処理サービスで、短い待機時間と高い信頼性を実現します。 1 秒間に何百万ものイベントを受信して処理することができます。 イベント ハブに送信されたデータは、任意のリアルタイム分析プロバイダーやバッチ処理/ストレージ アダプターを使用して、変換および保存できます。

Event Hubs の詳しい使い方については、「Azure Event Hubs のドキュメント」を参照してください。Event Hubs を使用して、接続されているデバイスやアプリケーションから 1 秒あたり数百万のイベントを取り込む方法が説明されています。

Event Hubs で信頼性の高いワークロードを作成する方法については、「Azure Event Hubs - geo ディザスター リカバリー」を参照してください。

以下のセクションでは、Azure Event Hubs と信頼性について具体的に説明します。

  • 設計上の考慮事項
  • 構成チェックリスト
  • 推奨される構成オプション
  • ソース成果物

設計上の考慮事項

Azure Event Hubs にはアップタイム SLA があります。 詳細については、「Event Hubs の SLA」を参照してください。

チェック リスト

信頼性を考慮して Azure Event Hubs を構成しましたか?

  • イベントの発行元とコンシューマーに対して、SendOnly ポリシーと ListenOnly ポリシーをそれぞれ作成します。
  • SDK を使用して Event Hubs にイベントを送信する場合は、再試行ポリシー (EventHubsException または OperationCancelledException) によってスローされた例外が適切にキャッチされていることを確認します。
  • 高スループットのシナリオでは、バッチ イベントを使用します。
  • すべてのコンシューマーは、1 から 32 個のパーティションからイベントを読み取ることができます。
  • 新しいアプリケーションを開発する場合は、クライアント SDK として EventProcessorClient (.Net と Java) または EventHubConsumerClient (Python と JavaScript) を使用します。
  • ソリューション全体の可用性とディザスター リカバリーに関する戦略の一環として、Event Hubs の geo ディザスター リカバリー オプションを有効にすることを検討します。
  • ソリューションに独立したイベント発行元が多数ある場合は、イベント発行元を使用してアクセスをきめ細かく制御することを検討します。
  • 特定のパーティションにイベントを発行しないようにします。
  • イベントを頻繁に発行する場合は、可能であれば AMQP プロトコルを使用します。
  • パーティションの数は、実行できるダウンストリーム並列処理の次数を反映しています。
  • コンシューマー アプリケーションごとに個別のコンシューマー グループが使用され、コンシューマー グループごとにアクティブな受信者が 1 つだけ存在することを確認します。
  • キャプチャ機能を使用する場合は、時間枠とファイル サイズの構成を慎重に検討してください (特に低イベント ボリュームの場合)。

構成に関する推奨事項

Azure Event Hubs を構成するときは、信頼性を最適化するための次の推奨事項を考慮してください。

推奨 Description
SDK を使用して Event Hubs にイベントを送信する場合は、再試行ポリシー (EventHubsException または OperationCancelledException) によってスローされた例外が適切にキャッチされていることを確認します。 HTTPS を使用する場合は、適切な再試行パターンが実装されていることを確認してください。
高スループットのシナリオでは、バッチ イベントを使用します。 サービスによって、1 つのイベントを含む配列ではなく、複数のイベントを含む json 配列がサブスクライバーに配信されます。 コンシューマー アプリケーションは、これらの配列を処理する必要があります。
すべてのコンシューマーは、1 から 32 個のパーティションからイベントを読み取ることができます。 コンシューマーアプリケーション側で最大スケールを実現するには、すべてのコンシューマーが 1 つのパーティションから読み取る必要があります。
新しいアプリケーションを開発する場合は、クライアント SDK として EventProcessorClient (.Net と Java) または EventHubConsumerClient (Python と JavaScript) を使用します。 EventProcessorHost の使用は非推奨とされました。
ソリューション全体の可用性とディザスター リカバリーに関する戦略の一環として、Event Hubs の geo ディザスター リカバリー オプションを有効にすることを検討します。 このオプションを使用すると、別のリージョンでセカンダリ名前空間を作成できます。 メッセージを受信するのはアクティブな名前空間だけです。 メッセージとイベントがセカンダリ リージョンにレプリケートされることはありません。 リージョン間フェールオーバーの RTO は "最大 30 分"です。 この RTO がお客様の要件と一致していることと、広範な可用性戦略に適合していることを確認します。 より高い RTO が必要な場合は、クライアント側のフェールオーバー パターンを実装することを検討してください。
ソリューションに独立したイベント発行元が多数ある場合は、イベント発行元を使用してアクセスをきめ細かく制御することを検討します。 イベント発行元はパーティション キーを自動的に発行元の名前に設定するため、この機能は、イベントがすべての発行元から均等に生成される場合にのみ使用してください。
特定のパーティションにイベントを発行しないようにします。 イベントの順序付けが不可欠である場合は、ダウンストリームの順序付けを実装するか、別のメッセージング サービスを使用します。
イベントを頻繁に発行する場合は、可能であれば AMQP プロトコルを使用します。 AMQP ではセッション初期化時のネットワーク コストが高くなりますが、HTTPS では要求ごとに TLS オーバーヘッドが必要になります。 発行の頻度が高い場合は、AMQP の方が高パフォーマンスになります。
パーティションの数は、実行できるダウンストリーム並列処理の次数を反映しています。 スループットを最大化するには、イベント ハブを作成するときに最大数のパーティション (32) を使用します。 最大数のパーティションを使用すると、同時に処理するエンティティ数を 32 にスケールアップでき、送受信の可用性を最大限に高められます。
キャプチャ機能を使用する場合は、時間枠とファイル サイズの構成を慎重に検討してください (特に低イベント ボリュームの場合)。 Data Lake では、ストレージの最小ファイル サイズ (gen1) または最小トランザクション サイズ (gen2) に対して課金されます。 ファイルが最小サイズに達しないほど時間枠を短く設定すると、追加コストが発生します。

ソース成果物

Basic SKU を使用する Event Hubs 名前空間を検出するには、次のクエリを使用します。

Resources 
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name

次のステップ

Event Hubs とオペレーショナル エクセレンス