Azure Event Hubs の機能と用語

Azure Event Hubs は、大量のイベントやデータを取り込んで処理するスケーラブルなイベント処理サービスで、短い待機時間と高い信頼性を実現します。 概要については、「Event Hubs とは」を参照してください。

概要記事内の情報に基づいて作成されたこの記事では、Event Hubs のコンポーネントと機能に関する実装の技術的な詳細を説明します。

ヒント

Apache Kafka クライアント (バージョン 1.0 以降) のプロトコル サポートにより、任意のクライアントで Apache Kafka を使用するように構築されたアプリケーションで、Event Hubs を使用できるようにするネットワーク エンドポイントが提供されます。 既存の Kafka アプリケーションのほとんどは、Kafka クラスターのブートストラップ サーバーではなく、イベント ハブの名前空間を指すように簡単に再構成できます。

コスト、運用の作業量、信頼性の観点から見ると、Azure Event Hubs は、独自の Kafka および Zookeeper クラスターをデプロイして運用したり、Azure にネイティブではないサービスとしての Kafka を提供したりすることに代わる優れた手段です。

Apache Kafka ブローカーと同じコア機能を利用できるだけでなく、Azure Event Hub の機能にアクセスすることもできます。これには、Event Hubs Capture 経由の自動のバッチ処理とアーカイブ、自動のスケーリングと分散、ディザスター リカバリー、コストに依存しない可用性ゾーンのサポート、柔軟で安全なネットワーク統合、ファイアウォールに適した WebSocket 経由の AMQP プロトコルを含むマルチプロトコル サポートなどがあります。

名前空間

Event Hubs 名前空間は、イベント ハブ (Kafka 用語ではトピック) の管理コンテナーです。 これにより、DNS 統合ネットワーク エンドポイントと、一連のアクセス制御およびネットワーク統合管理機能 (IP フィルタリング仮想ネットワーク サービス エンドポイントPrivate Link など) が提供されます。

Event Hubs 名前空間を示す図

イベント発行元

イベント ハブにデータを送信するエンティティはすべて、"イベント発行元" ("イベント プロデューサー" と同義) です。 イベント発行元は、HTTPS、AMQP 1.0、または Kafka プロトコルを使用してイベントを発行できます。 イベント発行元は、OAuth2 で発行された JWT トークンか、イベント ハブ固有の Shared Access Signature (SAS) トークンによる Azure Active Directory ベースの承認を使用して、発行アクセス権を取得します。

イベントの発行

AMQP 1.0、Kafka プロトコル、または HTTPS 経由でイベントを発行できます。 Event Hubs サービスは、イベント ハブにイベントを発行するための REST API.NETJavaPythonJavaScriptGo の各クライアント ライブラリを備えています。 その他のランタイムとプラットフォームには、 Apache Qpidなどの任意の AMQP 1.0 クライアントを使用できます。

AMQP または HTTPS のどちらを使用するかは、使用シナリオによって決まります。 AMQP では、トランスポート レベルのセキュリティ (TLS) または SSL/TLS に加えて、永続的な双方向ソケットを確立する必要があります。 AMQP ではセッション初期化時のネットワーク コストが高くなりますが、HTTPS では要求ごとに追加の TLS オーバーヘッドが必要になります。 AMQP は、頻度の高い発行元に対して非常に高いパフォーマンスを備えており、非同期発行コードと共に使用すると、はるかに短い待機時間を実現できます。

イベントは、個別に発行することもバッチ処理することもできます。 1 つのイベントかバッチ処理かに関係なく、1 回の発行には 1 MB の制限があります。 このしきい値を超えるイベントの発行は拒否されます。

Event Hubs のスループットは、パーティションとスループット ユニットの割り当てを使用してスケーリングされます (以下を参照)。 発行元は、イベント ハブ用に選択された特定のパーティション分割モデルは使用せずに、関連するイベントを同じパーティションに一貫して割り当てるために使用される "パーティション キー" の指定だけを行うことをお勧めします。

パーティション キー

Event Hubs によって、1 つのパーティション キー値を共有するすべてのイベントが一緒に格納され、到着順に配信されます。 パーティション キーと発行元ポリシーを併用する場合は、発行元の ID とパーティション キーの値が一致する必要があります。 そうでない場合、エラーが発生します。

イベントの保持

発行されたイベントは、構成可能な時間ベースの保持ポリシーに基づいてイベント ハブから削除されます。 重要な点がいくつかあります。

  • 既定値および指定可能な最小保持期間は 1 日 (24 時間) です。
  • Event Hubs Standard の場合、最大保持期間は 7 日です。
  • Event Hubs の Premium および Dedicated の場合、最大保持期間は 90 日間です。
  • 保持期間を変更すると、既にイベント ハブ内にあるイベントを含むすべてのイベントに適用されます。

Event Hubs は構成された期間にわたりイベントを保持します。これは、すべてのパーティションに適用されます。 保持期間が経過するとイベントは自動的に削除されます。 保持期間を 1 日に指定すると、イベントは、その受領からちょうど 24 時間で利用できなくなります。 イベントを明示的に削除することはできません。

許可された保持期間を超えるイベントをアーカイブする必要がある場合は、Event Hubs Capture 機能を有効にすることにより、Azure Storage または Azure Data Lake に自動的に格納できます。 そのようなディープ アーカイブを検索または分析する必要がある場合は、それらを Azure Synapse または他の同様のストアや分析プラットフォームに簡単にインポートできます。

Event Hubs でデータの保持期間に上限を設けている理由は、タイムスタンプによってのみインデックスされ、順次アクセスしかできない大きなストアに、過去に発生した大量のカスタマー データが無造作に取り込まれるのを避けるためです。 このようなアーキテクチャが採用されている理由は、履歴データには、Event Hubs や Kafka で提供されているリアルタイム イベントのインターフェイスよりも高度なインデックス作成とより直接的なアクセスが必要であると考えられるからです。 イベント ストリーム エンジンは、イベント ソーシングのデータ レイクや長期アーカイブの用途には適していません。

Note

Event Hubs はリアルタイムのイベント ストリーム エンジンであるため、データベースや、無期限に保持されるイベント ストリームの永続的なストアの代わりとして使用されるように設計されていません。

イベント ストリームの履歴が多いほど、特定のストリームの特定の履歴スライスを見つけるために多くの補助インデックスが必要になります。 イベント ペイロードとインデックス作成の検査は、Event Hubs (または Apache Kafka) の機能の範囲内にはありません。 したがって、データベースや、Azure Data Lake StoreAzure Data Lake AnalyticsAzure Synapse などの専用の分析ストアおよびエンジンの方が、履歴イベントの保存にはずっと適しています。

Event Hubs Capture は Azure Blob Storage および Azure Data Lake Storage に直接統合されており、その統合を通じてイベントを Azure Synapse に直接フローさせることができます。

発行元ポリシー

Event Hubs では、 発行元ポリシーを介してイベント プロデューサーをきめ細かく制御できます。 発行元ポリシーは、多数の独立したイベント発行元を支援するために設計されたランタイム機能です。 発行元ポリシーでは、次のメカニズムを使用してイベント ハブにイベントを発行する際に、各発行元は独自の一意の識別子を使用します。

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

前もって発行元名を作成しておく必要はありませんが、独立した発行元 ID を保証するために、発行元名はイベントを発行するときに使用される SAS トークンと一致する必要があります。 発行元ポリシーを使用する場合は、PartitionKey の値を発行元の名前に設定する必要があります。 適切に機能するために、これらの値が一致する必要があります。

キャプチャ

Event Hubs Capture を使用すると、Event Hubs のストリーミング データを自動的にキャプチャし、BLOB ストレージ アカウントまたは Azure Data Lake Storage アカウントのいずれかを選択して保存できます。 Azure portal からキャプチャを有効にし、キャプチャを実行する最小サイズと時間枠を指定できます。 Event Hubs Capture を使用して、独自の Azure Blob Storage アカウントとコンテナー、または Azure Data Lake Storage アカウントを指定し、そのいずれかに、キャプチャされたデータを格納します。 キャプチャされたデータは、Apache Avro 形式で書き込まれます。

Event Hub のデータの Azure Storage または Azure Data Lake Storage へのキャプチャを示す図

Event Hubs Capture によって生成されたファイルには、次の Avro スキーマがあります。

キャプチャされたデータの構造を示す図

注意

Azure portal でコード エディターを使用しない場合は、Event Hubs のストリーミング データを Parquet 形式のAzure Data Lake Storage Gen2 アカウントでキャプチャできます。 詳細については、「方法: Parquet 形式で Event Hubs からデータをキャプチャする」「チュートリアル: Parquet 形式で Event Hubs データをキャプチャし、Azure Synapse Analytics を使用して分析する」を参照してください。

メジャー グループ

イベント ハブでは、イベント ハブに送信されたイベントのシーケンスを 1 つまたは複数のパーティションにまとめて整理します。 新しいイベントが到着すると、このシーケンスの末尾に追加されます。

Event Hubs

パーティションは "コミット ログ" として考えることができます。 イベント本体、イベントを表すユーザー定義のプロパティ バッグ、メタデータ (パーティションにおけるオフセット、ストリーム シーケンスにおける番号、イベントが受理されたサービス側のタイムスタンプなど) を含んだイベント データがパーティションに格納されます。

古いものから新しいものへのイベントのシーケンスを表示する図。

パーティションを使用する利点

Event Hubs の目的は、大量のイベントの処理を支援することです。パーティションは、2 つの方法でそれを支援します。

  • Event Hubs は PaaS サービスであるとはいえ、根底には物理的な現実があります。イベントの順序を保持するログを維持するためには、根底にあるストレージとそのレプリカにそれらのイベントがまとめて保持されている必要があるため、そのようなログにはスループットの上限が生じます。 パーティションに分割することにより、同じイベント ハブで複数の並列ログを使用できるため、生の IO の処理に利用できるスループット容量が増えます。
  • 個々のアプリケーションは、イベント ハブに送信される量のイベントの処理に遅れずついていくことができなければなりません。 これは複雑で、相当にスケールアウトされた並列処理能力が必要となる場合があります。 イベントを処理する 1 つのプロセスの容量は限られているため、複数のプロセスが必要になります。 パーティションを使用することで、そうしたプロセスにイベントをフィードしながら、各イベントの処理の所有者を明確化することができます。

パーティションの数

パーティションの数は、イベント ハブの作成時に指定します。 この数は、1 から、各価格レベルで許可されている最大パーティション数の間である必要があります。 各レベルのパーティション数の制限については、こちらの記事を参照してください。

アプリケーションの負荷がピークに達している状態で必要となる以上のパーティションを、その特定のイベント ハブに選択することをお勧めします。 専用クラスターおよび Premium レベルのイベント ハブを除き、イベント ハブの作成後に、そのパーティション数を変更することはできません。 専用の Event Hubs クラスター内のイベント ハブのパーティション数は、イベント ハブの作成後に増やすこともできますが、パーティションへのパーティション キーのマッピングが変わるので、パーティション全体に対するストリームの配分が変化します。そのため、アプリケーションの中でイベントの相対的な順序が重要な場合は、そのような変更は極力避けるようにしてください。

パーティション数を上限に設定したくなるかもしれませんが、複数のパーティションの利点を実際に活かせるようにイベント ストリームを構築する必要があることを常に念頭に置いてください。 すべてのイベントについて、または一部のサブストリームのみについて、絶対的な順序を保持する必要がある場合、多くのパーティションを活用できないことがあります。 また、パーティション数が多いと処理する側もより複雑になります。

イベント ハブに含まれるパーティションの数は、料金には関係ありません。 名前空間または専用クラスターの価格ユニット (Standard レベルではスループット ユニット (TU)、Premium レベルではプロセッシング ユニット (PU)、専用レベルでは容量ユニット (CU)) によって決まります。 例えば、名前空間の容量が 1 TU に設定されている場合、パーティションが 32 個でも 1 個でも、Standard レベルのイベント ハブで発生するコストはまったく同じです。 さらに、パーティション数とは関係なく、お使いの名前空間上の TU または PU、あるいは専用クラスターの CU をスケーリングできます。

パーティションはデータを並列で発行および使用できるデータ編成メカニズムであるため、スケーリング ユニット (TU、PU、または CU) とパーティションのバランスを取りながら、最適なスケールを実現することをお勧めします。 一般に、ユーザーはパーティションあたり 1 MB/秒の最大スループットを維持し、処理する最大スループットに合わせてパーティション数を選ぶことをお勧めします。 たとえば、ユース ケースで 20 MB/秒が必要な場合は、最適なスループットを実現するために、少なくとも 20 個のパーティションを選択することをお勧めします。

ただし、アプリケーションで特定のパーティションに対してアフィニティが設定されているモデルがある場合は、パーティションの数を増やすことによる利点がない場合があります。 詳細については、[可用性と一貫性]に関するページを参照してください。

パーティションへのイベントのマッピング

パーティション キーを使用すると、データ編成を目的として受信イベント データを特定のパーティションにマップすることができます。 パーティション キーは、送信者によって指定され、イベント ハブに渡される値です。 これは、パーティション割り当てを作成する静的なハッシュ関数で処理されます。 イベントを発行するときにパーティション キーを指定しないと、ラウンド ロビン割り当てが使用されます。

イベント発行元は、そのパーティション キーのみを認識し、イベントの発行先となるパーティションは認識しません。 このようにキーとパーティションを分離することにより、送信者はダウンストリーム処理について余分な情報を把握しなくてもよくなります。 デバイスごとまたはユーザーの一意の ID は適切なパーティション キーになりますが、地理的条件などのその他の属性を使用して関連するイベントを 1 つのパーティションにまとめることもできます。

パーティション キーを指定すると、関連するイベントを同じパーティションにまとめて、到着時とまったく同じ順番で保存することができます。 パーティション キーは、アプリケーションのコンテキストから得られる文字列で、イベントの相互関係を識別するものです。 パーティション キーによって識別される一連のイベントが "ストリーム" です。 パーティションは、そのようなたくさんのストリームが混在するログ ストアです。

Note

イベントはパーティションに直接送信できますが、特に、高可用性が重要な場合は推奨されません。 イベント ハブの可用性がパーティション レベルにダウングレードされます。 詳細については、可用性と一貫性に関するページを参照してください。

SAS トークン

Event Hubs は、名前空間とイベント ハブのレベルで利用可能な Shared Access Signature を使用します。 SAS トークンは、SAS キーから生成されるものであり、特定の形式でエンコードされた URL の SHA ハッシュです。 Event Hubs では、キー (ポリシー) の名前とトークンを使用してハッシュを再生成し、送信者を認証することができます。 通常、イベント発行元の SAS トークンは特定のイベント ハブへの送信特権のみを付加して作成されます。 この SAS トークン URL のメカニズムは、発行元ポリシーに導入された発行元識別のための基盤です。 SAS を使用する方法の詳細については、「Service Bus による Shared Access Signature 認証」を参照してください。

イベント コンシューマー

イベント ハブからイベント データを読み取るエンティティは、いずれも "イベント コンシューマー" です。 Event Hubs のすべてのコンシューマーは AMQP 1.0 セッションを介して接続します。イベントは使用可能になると、このセッションを使用して配信されます。 クライアントがデータの可用性をポーリングする必要はありません。

コンシューマー グループ

Event Hubs の発行/サブスクライブのメカニズムは、"コンシューマー グループ" によって有効になります。 コンシューマー グループは、イベント ハブ全体のビュー (状態、位置、またはオフセット) を表します。 コンシューマー グループを使用することにより、複数のコンシューマー アプリケーションは、イベント ストリームの個別のビューをそれぞれ保有し、独自のペースで独自のオフセットによってストリームを別々に読み取ることができます。

ストリーム処理アーキテクチャにおいて、各ダウンストリーム アプリケーションはコンシューマー グループに相当します。 (パーティションからさらに) 長期的なストレージにイベント データを書き込む場合、そのストレージ ライター アプリケーションはコンシューマー グループとなります。 複雑なイベント処理は、別の異なるコンシューマー グループで実行できます。 パーティションにはコンシューマー グループを介してのみアクセスできます。 イベント ハブには必ず、既定のコンシューマー グループが存在します。対応する価格レベルに応じたコンシューマー グループの最大数まで作成できます。

コンシューマー グループごとに 1 つのパーティションに同時に接続できるリーダーは最大で 5 つですが、コンシューマー グループごとのパーティションのアクティブ レシーバーは 1 つだけにすることをお勧めします。 1 つのパーティション内で、各リーダーがすべてのイベントを受信します。 同じパーティションに複数のリーダーがある場合、重複したイベントを処理します。 お使いのコード内でこれを処理する必要があり、相応の作業量が生じる場合があります。 ただし、これは一部のシナリオで有効な手法です。

Azure SDK によって提供される一部のクライアントはインテリジェントなコンシューマー エージェントです。これは、各パーティションに 1 つのリーダーがあり、イベント ハブのすべてのパーティションが読み取られていることを確認するための詳細を自動的に管理します。 これにより、コードではイベント ハブから読み取られるイベントの処理に注力できるため、パーティションの詳細の多くを無視できます。 詳細については、「パーティションに接続する」を参照してください。

コンシューマー グループ URI 表記の例を次に示します。

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

次の図は、Event Hubs ストリーム処理のアーキテクチャを示しています。

Event Hubs のアーキテクチャ

ストリームのオフセット

"オフセット" は、パーティション内のイベントの位置です。 オフセットは、クライアント側のカーソルと考えることができます。 オフセットはイベントのバイト位置です。 このオフセットにより、イベント コンシューマー (リーダー) は、イベント ストリーム内でのイベント読み取りの開始点を指定することができます。 オフセットは、タイムスタンプとして、またはオフセット値として指定することができます。 Event Hubs サービスの外部で独自のオフセット値を格納する場合は、コンシューマーの責任で行います。 パーティション内では、各イベントにオフセットが含まれます。

パーティションのオフセット

チェックポイント機能

"チェックポイント処理" とは、リーダーがパーティションにおけるイベント シーケンス内の位置をマークまたはコミットするために使用する処理です。 チェックポイント処理はコンシューマーの責任で行います。この処理はコンシューマー グループ内でパーティションごとに発生します。 つまり、コンシューマー グループごとに、各パーティション リーダーは、イベント ストリーム内でのその現在の位置を追跡する必要があり、データ ストリームが完了したと見なしたときにサービスに通知することができます。

リーダーがパーティションから切断し、その後再び接続すると、該当するコンシューマー グループ内の該当するパーティションの最後のリーダーによって最後に送信されたチェックポイントから読み取りが開始されます。 リーダーは接続の際に、このオフセットをイベント ハブに渡して、読み取りを開始する場所を指定します。 このように、チェックポイント処理を使用することで、ダウンストリーム アプリケーションごとにイベントに "完了" のマークを付けると共に、異なるコンピューター上で実行中のリーダー間でフェールオーバーが発生した場合に回復性をもたらすことができます。 このチェックポイント処理で、より小さなオフセットを指定すると、古いデータに戻ることができます。 このメカニズムにより、チェックポイント処理ではフェールオーバーの回復性とイベント ストリームの再生の両方を実現できます。

重要

オフセットは、Event Hubs サービスによって提供されます。 イベントが処理されるときにチェックポイント処理を行うのはコンシューマーの責任です。

Note

Azure で一般公開されているものとは異なるバージョンの Storage Blob SDK をサポートする環境で、チェックポイント ストアとして Azure Blob Storage を使用している場合は、コードを使用して、Storage Service API バージョンをその環境でサポートされている特定のバージョンに変更する必要があります。 たとえば、Azure Stack Hub バージョン 2002 上で Event Hubs を実行している場合、Storage Service で利用可能な最も高いバージョンは 2017-11-09 です。 この場合は、コードを使用して、対象にする Storage Service API のバージョンを 2017-11-09 にする必要があります。 特定の Storage API バージョンを対象にする方法の例については、GitHub の次のサンプルを参照してください。

一般的なコンシューマー タスク

すべての Event Hubs コンシューマーは、AMQP 1.0 セッション (状態に対応する双方向の通信チャネル) を介して接続します。 各パーティションには、パーティションによって分離されたイベントの転送を容易にする AMQP 1.0 セッションがあります。

パーティションに接続する

パーティションに接続する場合は、特定のパーティションへのリーダーの接続を調整するためにリース メカニズムを使用するのが一般的です。 このため、コンシューマー グループ内のどのパーティションもアクティブなリーダーが 1 つだけである可能性があります。 チェックポイント処理、リース、およびリーダーの管理は、インテリジェントなコンシューマー エージェントとして機能する Event Hubs SDK 内のクライアントを使用して簡略化されます。 次のとおりです。

イベントを読み取る

特定のパーティションに対して AMQP 1.0 のセッションおよびリンクが開かれると、Event Hubs サービスによってイベントが AMQP 1.0 クライアントに配信されます。 この配信メカニズムでは、HTTP GET などのプル ベースのメカニズムよりも高いスループットおよび短い遅延時間を実現します。 イベントがクライアントに送信されるとき、イベント データの各インスタンスには、イベント シーケンスでのチェックポイント処理を容易にするために使用されるオフセットやシーケンス番号などの重要なメタデータが含まれます。

イベント データ:

  • Offset
  • Sequence number
  • Body
  • ユーザー プロパティ
  • システム プロパティ

オフセットを管理するのはユーザーの責任になります。

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

アプリケーション グループは、セキュリティ コンテキスト (共有アクセス ポリシーや Azure Active Directory (Azure AD) アプリケーション ID) などの一意の識別条件を共有する Event Hubs 名前空間に接続するクライアント アプリケーションのコレクションです。

Azure Event Hubs を使用すると、特定のアプリケーション グループの調整ポリシーなどのリソース アクセス ポリシーを定義し、クライアント アプリケーションと Event Hubs の間でイベント ストリーミング (公開または使用) を制御できます。

詳細については、アプリケーション グループを使用したクライアント アプリケーションのリソース ガバナンスに関するページを参照してください。

次のステップ

Event Hubs の詳細については、次のリンクを参照してください。