Azure Event Hubs の機能と用語Features and terminology in Azure Event Hubs

Azure Event Hubs は、大量のイベントやデータを取り込んで処理するスケーラブルなイベント処理サービスで、短い待機時間と高い信頼性を実現します。Azure Event Hubs is a scalable event processing service that ingests and processes large volumes of events and data, with low latency and high reliability. 概要については、「Event Hubs とは」を参照してください。See What is Event Hubs? for a high-level overview.

概要記事内の情報に基づいて作成されたこの記事では、Event Hubs のコンポーネントと機能に関する実装の技術的な詳細を説明します。This article builds on the information in the overview article, and provides technical and implementation details about Event Hubs components and features.

名前空間Namespace

Event Hubs 名前空間は一意のスコープ コンテナーを提供します。このコンテナーは、1 つ以上のイベント ハブまたは Kafka トピックを作成する完全修飾ドメイン名によって参照されます。An Event Hubs namespace provides a unique scoping container, referenced by its fully qualified domain name, in which you create one or more event hubs or Kafka topics.

Apache Kafka 用 Event HubsEvent Hubs for Apache Kafka

この機能は、顧客が Kafka プロトコルを使用して Event Hubs に接続できるようにするエンドポイントを提供します。This feature provides an endpoint that enables customers to talk to Event Hubs using the Kafka protocol. この統合によって顧客に Kafka エンドポイントが提供されます。This integration provides customers a Kafka endpoint. これにより、顧客は Event Hubs に接続するように既存の Kafka アプリケーションを構成できるため、独自の Kafka クラスターを実行するための代替手段が提供されます。This enables customers to configure their existing Kafka applications to talk to Event Hubs, giving an alternative to running their own Kafka clusters. Apache Kafka 用の Event Hubs は、Kafka プロトコル 1.0 以降をサポートしています。Event Hubs for Apache Kafka supports Kafka protocol 1.0 and later.

この統合により、Kafka クラスターを実行したり、Zookeeper を使用してそれらを管理したりする必要はありません。With this integration, you don't need to run Kafka clusters or manage them with Zookeeper. また、これにより、キャプチャ、自動インフレ、geo ディザスター リカバリーなどの Event Hubs の最も要求の厳しい機能のいくつかを操作することもできます。This also allows you to work with some of the most demanding features of Event Hubs like Capture, Auto-inflate, and Geo-disaster Recovery.

この統合ではまた、Mirror Maker などのアプリケーションまたは Kafka Connect などのフレームワークが、構成変更だけでクラスターなしで動作できます。This integration also allows applications like Mirror Maker or framework like Kafka Connect to work clusterless with just configuration changes.

イベント発行元Event publishers

イベント ハブにデータを送信するエンティティは、イベント プロデューサー ("イベント発行元") です。Any entity that sends data to an event hub is an event producer, or event publisher. イベント パブリッシャーは、HTTPS、AMQP 1.0、または Kafka 1.0 以降を使用してイベントを発行できます。Event publishers can publish events using HTTPS or AMQP 1.0 or Kafka 1.0 and later. イベント発行元は、Shared Access Signature (SAS) トークンを使用してイベント ハブに対して身元を明らかにし、一意の ID を備えることも共通の SAS トークンを使用することもできます。Event publishers use a Shared Access Signature (SAS) token to identify themselves to an event hub, and can have a unique identity, or use a common SAS token.

イベントの発行Publishing an event

AMQP 1.0、Kafka 1.0 (以降)、または HTTPS 経由でイベントを発行できます。You can publish an event via AMQP 1.0, Kafka 1.0 (and later), or HTTPS. Event Hubs は、.NET クライアントからイベント ハブへのイベント発行で使用できるクライアント ライブラリとクラスを提供します。Event Hubs provides client libraries and classes for publishing events to an event hub from .NET clients. その他のランタイムとプラットフォームには、 Apache Qpidなどの任意の AMQP 1.0 クライアントを使用できます。For other runtimes and platforms, you can use any AMQP 1.0 client, such as Apache Qpid. イベントを個別に発行することも、複数のイベントを一括して発行すること (バッチ) もできます。You can publish events individually, or batched. 単一イベントまたはバッチのどちらであるかには関係なく、単一パブリケーション (イベント データ インスタンス) には 1 MB の制限があります。A single publication (event data instance) has a limit of 1 MB, regardless of whether it is a single event or a batch. このしきい値より大きいイベントを発行すると、エラーが発生します。Publishing events larger than this threshold results in an error. 発行元にとっては、イベント ハブ内のパーティションを意識せずに、次のセクションで説明する "パーティション キー" のみを指定するか、または SAS トークンを介して ID のみを指定するのがベスト プラクティスです。It is a best practice for publishers to be unaware of partitions within the event hub and to only specify a partition key (introduced in the next section), or their identity via their SAS token.

AMQP または HTTPS のどちらを使用するかは、使用シナリオによって決まります。The choice to use AMQP or HTTPS is specific to the usage scenario. AMQP では、トランスポート レベルのセキュリティ (TLS) または SSL/TLS に加えて、永続的な双方向ソケットを確立する必要があります。AMQP requires the establishment of a persistent bidirectional socket in addition to transport level security (TLS) or SSL/TLS. AMQP ではセッション初期化時のネットワーク コストが高くなりますが、HTTPS では要求ごとに追加の SSL オーバーヘッドが必要になります。AMQP has higher network costs when initializing the session, however HTTPS requires additional SSL overhead for every request. 発行の頻度が高い場合は、AMQP の方が高パフォーマンスになります。AMQP has higher performance for frequent publishers.

Event Hubs

Event Hubs によって、1 つのパーティション キー値を共有するすべてのイベントが、正しい順序で同じパーティションに確実に配信されます。Event Hubs ensures that all events sharing a partition key value are delivered in order, and to the same partition. パーティション キーと発行元ポリシーを併用する場合は、発行元の ID とパーティション キーの値が一致する必要があります。If partition keys are used with publisher policies, then the identity of the publisher and the value of the partition key must match. 一致しないと、エラーが発生します。Otherwise, an error occurs.

発行元ポリシーPublisher policy

Event Hubs では、 発行元ポリシーを介してイベント プロデューサーをきめ細かく制御できます。Event Hubs enables granular control over event publishers through publisher policies. 発行元ポリシーは、多数の独立したイベント発行元を支援するために設計されたランタイム機能です。Publisher policies are run-time features designed to facilitate large numbers of independent event publishers. 発行元ポリシーでは、次のメカニズムを使用してイベント ハブにイベントを発行する際に、各発行元は独自の一意の識別子を使用します。With publisher policies, each publisher uses its own unique identifier when publishing events to an event hub, using the following mechanism:

//[my namespace].servicebus.windows.net/[event hub name]/publishers/[my publisher name]

前もって発行元名を作成しておく必要はありませんが、独立した発行元 ID を保証するために、発行元名はイベントを発行するときに使用される SAS トークンと一致する必要があります。You don't have to create publisher names ahead of time, but they must match the SAS token used when publishing an event, in order to ensure independent publisher identities. 発行元ポリシーを使用する場合は、 PartitionKey 値を発行元名に設定します。When using publisher policies, the PartitionKey value is set to the publisher name. 適切に機能するために、これらの値が一致する必要があります。To work properly, these values must match.

キャプチャCapture

Event Hubs Capture では、Event Hubs のストリーミング データを自動でキャプチャし、任意の BLOB ストレージ アカウントまたは Azure Data Lake Service アカウントのいずれかに保存することができます。Event Hubs Capture enables you to automatically capture the streaming data in Event Hubs and save it to your choice of either a Blob storage account, or an Azure Data Lake Service account. Azure Portal から Capture を有効にし、キャプチャを実行する最小サイズと時間枠を指定できます。You can enable Capture from the Azure portal, and specify a minimum size and time window to perform the capture. Event Hubs Capture を使用すると、キャプチャされたデータを格納するための独自の Azure Blob Storage アカウントとコンテナーまたは Azure Data Lake Service アカウントを指定することができます。Using Event Hubs Capture, you specify your own Azure Blob Storage account and container, or Azure Data Lake Service account, one of which is used to store the captured data. キャプチャされたデータは、Apache Avro 形式で書き込まれます。Captured data is written in the Apache Avro format.

パーティションPartitions

Event Hubs は、パーティション化されたコンシューマー パターンを使用してメッセージ ストリーミングを実現します。このパターンでは、各コンシューマーはメッセージ ストリームの特定のサブセット (またはパーティション) のみを読み取ります。Event Hubs provides message streaming through a partitioned consumer pattern in which each consumer only reads a specific subset, or partition, of the message stream. このパターンでは、イベント処理能力を水平方向に拡張 (スケールアウト) することができ、キューおよびトピックでは利用できない、ストリームに重点を置いたその他の機能が利用できます。This pattern enables horizontal scale for event processing and provides other stream-focused features that are unavailable in queues and topics.

パーティションは、イベント ハブで保持される順序付けされた一連のイベントです。A partition is an ordered sequence of events that is held in an event hub. 新しいイベントが到着すると、このシーケンスの末尾に追加されます。As newer events arrive, they are added to the end of this sequence. パーティションは "コミット ログ" として考えることができます。A partition can be thought of as a "commit log."

Event Hubs

Event Hubs は構成されたリテンション期間にわたりデータを保持します。この期間は、イベント ハブのすべてのパーティションに適用されます。Event Hubs retains data for a configured retention time that applies across all partitions in the event hub. イベントの有効期限は時間で設定されます。イベントを明示的に削除することはできません。Events expire on a time basis; you cannot explicitly delete them. パーティションは独立していて、それぞれ独自のデータ シーケンスを含んでいるため、多くの場合、拡大するペースは異なります。Because partitions are independent and contain their own sequence of data, they often grow at different rates.

Event Hubs

パーティションの数は作成時に 2 ~ 32 の間で指定する必要があります。The number of partitions is specified at creation and must be between 2 and 32. パーティションの数は変更できないため、設定については長期的な規模で検討する必要があります。The partition count is not changeable, so you should consider long-term scale when setting partition count. パーティションはデータ編成メカニズムであり、コンシューマー アプリケーションで必要とされるダウンストリーム並列処理に関連します。Partitions are a data organization mechanism that relates to the downstream parallelism required in consuming applications. イベント ハブでのパーティションの数は、予想される同時接続のリーダー数に直接関連します。The number of partitions in an event hub directly relates to the number of concurrent readers you expect to have. Event Hubs チームに連絡すれば、パーティションの数を 32 より大きくすることができます。You can increase the number of partitions beyond 32 by contacting the Event Hubs team.

パーティションは識別可能であり、パーティションに直接送信できますが、パーティションに直接送信することはお勧めしません。While partitions are identifiable and can be sent to directly, sending directly to a partition is not recommended. その代わり、「イベント発行元」と「容量」のセクションで紹介する、より高いレベルの構造を使用できます。Instead, you can use higher level constructs introduced in the Event publisher and Capacity sections.

パーティションには一連のイベント データが格納されます。イベント データには、イベント本文、ユーザー定義のプロパティ バッグ、メタデータ (パーティションでのオフセットやストリーム シーケンスでの番号など) が含まれます。Partitions are filled with a sequence of event data that contains the body of the event, a user-defined property bag, and metadata such as its offset in the partition and its number in the stream sequence.

パーティションの詳細および可用性と信頼性のトレードオフについては、「Event Hubs のプログラミング ガイド」と「Event Hubs における可用性と一貫性」をご覧ください。For more information about partitions and the trade-off between availability and reliability, see the Event Hubs programming guide and the Availability and consistency in Event Hubs article.

パーティション キーPartition key

パーティション キーを使用すると、データ編成を目的として受信イベント データを特定のパーティションにマップすることができます。You can use a partition key to map incoming event data into specific partitions for the purpose of data organization. パーティション キーは、送信者によって指定され、イベント ハブに渡される値です。The partition key is a sender-supplied value passed into an event hub. これは、パーティション割り当てを作成する静的なハッシュ関数で処理されます。It is processed through a static hashing function, which creates the partition assignment. イベントを発行するときにパーティション キーを指定しないと、ラウンド ロビン割り当てが使用されます。If you don't specify a partition key when publishing an event, a round-robin assignment is used.

イベント発行元は、そのパーティション キーのみを認識し、イベントの発行先となるパーティションは認識しません。The event publisher is only aware of its partition key, not the partition to which the events are published. このようにキーとパーティションを分離することにより、送信者はダウンストリーム処理について余分な情報を把握しなくてもよくなります。This decoupling of key and partition insulates the sender from needing to know too much about the downstream processing. デバイスごとまたはユーザーの一意の ID は適切なパーティション キーになりますが、地理的条件などのその他の属性を使用して関連するイベントを 1 つのパーティションにまとめることもできます。A per-device or user unique identity makes a good partition key, but other attributes such as geography can also be used to group related events into a single partition.

SAS トークンSAS tokens

Event Hubs は、名前空間とイベント ハブのレベルで利用可能な Shared Access Signature を使用します。Event Hubs uses Shared Access Signatures, which are available at the namespace and event hub level. SAS トークンは、SAS キーから生成されるものであり、特定の形式でエンコードされた URL の SHA ハッシュです。A SAS token is generated from a SAS key and is an SHA hash of a URL, encoded in a specific format. Event Hubs は、キー (ポリシー) の名前とトークンを使用することで、ハッシュを再生成し、送信者を認証できます。Using the name of the key (policy) and the token, Event Hubs can regenerate the hash and thus authenticate the sender. 通常、イベント発行元の SAS トークンは特定のイベント ハブへの送信特権のみを付加して作成されます。Normally, SAS tokens for event publishers are created with only send privileges on a specific event hub. この SAS トークン URL のメカニズムは、発行元ポリシーに導入された発行元識別のための基盤です。This SAS token URL mechanism is the basis for publisher identification introduced in the publisher policy. SAS を使用する方法の詳細については、「Service Bus による Shared Access Signature 認証」を参照してください。For more information about working with SAS, see Shared Access Signature Authentication with Service Bus.

イベント コンシューマーEvent consumers

イベント ハブからイベント データを読み取るエンティティは、いずれも "イベント コンシューマー" です。Any entity that reads event data from an event hub is an event consumer. Event Hubs のすべてのコンシューマーは AMQP 1.0 セッションを介して接続します。イベントは使用可能になると、このセッションを使用して配信されます。All Event Hubs consumers connect via the AMQP 1.0 session and events are delivered through the session as they become available. クライアントがデータの可用性をポーリングする必要はありません。The client does not need to poll for data availability.

コンシューマー グループConsumer groups

Event Hubs の発行/サブスクライブのメカニズムは、"コンシューマー グループ" によって有効になります。The publish/subscribe mechanism of Event Hubs is enabled through consumer groups. コンシューマー グループは、イベント ハブ全体のビュー (状態、位置、またはオフセット) を表します。A consumer group is a view (state, position, or offset) of an entire event hub. コンシューマー グループを使用することにより、複数のコンシューマー アプリケーションは、イベント ストリームの個別のビューをそれぞれ保有し、独自のペースで独自のオフセットによってストリームを別々に読み取ることができます。Consumer groups enable multiple consuming applications to each have a separate view of the event stream, and to read the stream independently at their own pace and with their own offsets.

ストリーム処理アーキテクチャにおいて、各ダウンストリーム アプリケーションはコンシューマー グループに相当します。In a stream processing architecture, each downstream application equates to a consumer group. (パーティションからさらに) 長期的なストレージにイベント データを書き込む場合、そのストレージ ライター アプリケーションはコンシューマー グループとなります。If you want to write event data to long-term storage, then that storage writer application is a consumer group. 複雑なイベント処理は、別の異なるコンシューマー グループで実行できます。Complex event processing can then be performed by another, separate consumer group. パーティションにはコンシューマー グループを介してのみアクセスできます。You can only access partitions through a consumer group. イベント ハブには既定のコンシューマー グループが常に存在します。Standard レベルのイベント ハブに対して最大 20 個のコンシューマー グループを作成できます。There is always a default consumer group in an event hub, and you can create up to 20 consumer groups for a Standard tier event hub.

コンシューマー グループ内の 1 つのパーティションが同時に接続できるリーダーは最大 5 つですが、コンシューマー グループごとのパーティションのアクティブな受信者は 1 つだけにすることをお勧めしますThere can be at most 5 concurrent readers on a partition per consumer group; however it is recommended that there is only one active receiver on a partition per consumer group. 1 つのパーティション内で、各リーダーがすべてのメッセージを受信します。Within a single partition, each reader receives all of the messages. 同じパーティションに複数のリーダーがある場合、重複したメッセージを処理します。If you have multiple readers on the same partition, then you process duplicate messages. お使いのコード内でこれを処理する必要があり、相応の作業量が生じる場合があります。You need to handle this in your code, which may not be trivial. ただし、これは一部のシナリオで有効な手法です。However, it's a valid approach in some scenarios.

コンシューマー グループ URI 表記の例を次に示します。The following are examples of the consumer group URI convention:

//[my namespace].servicebus.windows.net/[event hub name]/[Consumer Group #1]
//[my namespace].servicebus.windows.net/[event hub name]/[Consumer Group #2]

次の図は、Event Hubs ストリーム処理のアーキテクチャを示しています。The following figure shows the Event Hubs stream processing architecture:

Event Hubs

ストリームのオフセットStream offsets

"オフセット" は、パーティション内のイベントの位置です。An offset is the position of an event within a partition. オフセットは、クライアント側のカーソルと考えることができます。You can think of an offset as a client-side cursor. オフセットはイベントのバイト位置です。The offset is a byte numbering of the event. このオフセットにより、イベント コンシューマー (リーダー) は、イベント ストリーム内でのイベント読み取りの開始点を指定することができます。This offset enables an event consumer (reader) to specify a point in the event stream from which they want to begin reading events. オフセットは、タイムスタンプとして、またはオフセット値として指定することができます。You can specify the offset as a timestamp or as an offset value. Event Hubs サービスの外部で独自のオフセット値を格納する場合は、コンシューマーの責任で行います。Consumers are responsible for storing their own offset values outside of the Event Hubs service. パーティション内では、各イベントにオフセットが含まれます。Within a partition, each event includes an offset.

Event Hubs

チェックポイント機能Checkpointing

"チェックポイント処理" とは、リーダーがパーティションにおけるイベント シーケンス内の位置をマークまたはコミットするために使用する処理です。Checkpointing is a process by which readers mark or commit their position within a partition event sequence. チェックポイント処理はコンシューマーの責任で行います。この処理はコンシューマー グループ内でパーティションごとに発生します。Checkpointing is the responsibility of the consumer and occurs on a per-partition basis within a consumer group. つまり、コンシューマー グループごとに、各パーティション リーダーは、イベント ストリーム内でのその現在の位置を追跡する必要があり、データ ストリームが完了したと見なしたときにサービスに通知することができます。This responsibility means that for each consumer group, each partition reader must keep track of its current position in the event stream, and can inform the service when it considers the data stream complete.

リーダーがパーティションから切断し、その後再び接続すると、該当するコンシューマー グループ内の該当するパーティションの最後のリーダーによって最後に送信されたチェックポイントから読み取りが開始されます。If a reader disconnects from a partition, when it reconnects it begins reading at the checkpoint that was previously submitted by the last reader of that partition in that consumer group. リーダーは接続の際に、このオフセットをイベント ハブに渡して、読み取りを開始する場所を指定します。When the reader connects, it passes the offset to the event hub to specify the location at which to start reading. このように、チェックポイント処理を使用することで、ダウンストリーム アプリケーションごとにイベントに "完了" のマークを付けると共に、異なるコンピューター上で実行中のリーダー間でフェールオーバーが発生した場合に回復性をもたらすことができます。In this way, you can use checkpointing to both mark events as "complete" by downstream applications, and to provide resiliency if a failover between readers running on different machines occurs. このチェックポイント処理で、より小さなオフセットを指定すると、古いデータに戻ることができます。It is possible to return to older data by specifying a lower offset from this checkpointing process. このメカニズムにより、チェックポイント処理ではフェールオーバーの回復性とイベント ストリームの再生の両方を実現できます。Through this mechanism, checkpointing enables both failover resiliency and event stream replay.

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

すべての Event Hubs コンシューマーは、AMQP 1.0 セッション (状態に対応する双方向の通信チャネル) を介して接続します。All Event Hubs consumers connect via an AMQP 1.0 session, a state-aware bidirectional communication channel. 各パーティションには、パーティションによって分離されたイベントの転送を容易にする AMQP 1.0 セッションがあります。Each partition has an AMQP 1.0 session that facilitates the transport of events segregated by partition.

パーティションに接続するConnect to a partition

パーティションに接続する場合は、特定のパーティションへのリーダーの接続を調整するためにリース メカニズムを使用するのが一般的です。When connecting to partitions, it is common practice to use a leasing mechanism to coordinate reader connections to specific partitions. このため、コンシューマー グループ内のどのパーティションもアクティブなリーダーが 1 つだけである可能性があります。This way, it is possible for every partition in a consumer group to have only one active reader. チェックポイント処理、リース、リーダー管理は、.NET クライアントの EventProcessorHost クラスを使用して簡略化されます。Checkpointing, leasing, and managing readers are simplified by using the EventProcessorHost class for .NET clients. イベント プロセッサ ホストはインテリジェントなコンシューマー エージェントです。The Event Processor Host is an intelligent consumer agent.

イベントを読み取るRead events

特定のパーティションに対して AMQP 1.0 のセッションおよびリンクが開かれると、Event Hubs サービスによってイベントが AMQP 1.0 クライアントに配信されます。After an AMQP 1.0 session and link is opened for a specific partition, events are delivered to the AMQP 1.0 client by the Event Hubs service. この配信メカニズムでは、HTTP GET などのプル ベースのメカニズムよりも高いスループットおよび短い遅延時間を実現します。This delivery mechanism enables higher throughput and lower latency than pull-based mechanisms such as HTTP GET. イベントがクライアントに送信されるとき、イベント データの各インスタンスには、イベント シーケンスでのチェックポイント処理を容易にするために使用されるオフセットやシーケンス番号などの重要なメタデータが含まれます。As events are sent to the client, each event data instance contains important metadata such as the offset and sequence number that are used to facilitate checkpointing on the event sequence.

イベント データ:Event data:

  • OffsetOffset
  • Sequence numberSequence number
  • 本文Body
  • ユーザー プロパティUser properties
  • システム プロパティSystem properties

ユーザーはオフセットを管理する必要があります。It is your responsibility to manage the offset.

次の手順Next steps

Event Hubs の詳細については、次のリンクを参照してください。For more information about Event Hubs, visit the following links: