Event Hubs によるスケーリング

Event Hubs によるスケーリングに影響する 2 つの要素があります。

  • スループット ユニット
  • [ パーティション]

スループット ユニット

Event Hubs のスループット容量は、"スループット ユニット" によって制御されます。 スループット ユニットとは、購入済みの容量ユニットのことです。 1 つのスループットでは次が可能です。

  • イングレス: 1 秒あたり最大で 1 MB または 1,000 イベント (どちらか先に到達した方)
  • エグレス: 1 秒あたり最大で 2 MB または 4,096 イベント

購入済みのスループット ユニットの容量を超えると、イングレスが調整され、ServerBusyException が返されます。 エグレスではスロットル例外は発生しませんが、購入済みのスループット ユニットの容量に制限されます。 発行率の例外を受信するか、より高いエグレスが予想される場合は、名前空間に対して購入したスループット ユニットの数を確認してください。 スループット ユニットは、Azure Portal の名前空間の [スケール] ブレードで管理できます。 Event Hubs API を使用して、プログラムでスループット ユニットを管理することもできます。

スループット ユニットは事前に購入し、1 時間ごとに課金されます。 スループット ユニットを購入すると、少なくとも 1 時間の料金が課金されます。 Event Hubs の名前空間に対して最大 20 のスループット ユニットを購入でき、その名前空間内のすべてのイベント ハブで共有されます。

Event Hubs の 自動インフレ 機能は、使用量のニーズに合わせてスループット単位の数を増やすことで、自動的にスケールアップします。 スループット単位を増やすことで、以下の状況で必要になる調整シナリオを防ぐことができます。

  • データの受信レートが、設定されたスループット単位を超えている。
  • データの送信要求レートが、設定されたスループット単位を超えている。

負荷が最小しきい値を超えていて、ServerBusy エラーなどで失敗した要求がない場合、Event Hubs サービスでスループットが増えます。

自動インフレ機能の詳細については、スループット単位の自動的なスケーリング に関する記事を参照してください。

プロセッシング ユニット

Event Hubs Premium は、マネージド マルチテナント PaaS 環境で優れたパフォーマンスと分離性を提供します。 Premium レベルのリソースは CPU とメモリのレベルで分離され、各テナント ワークロードが分離して実行されます。 このリソース コンテナーを "プロセッシング ユニット" (PU) と呼びます。 各 Event Hubs Premium 名前空間に対して 1、2、4、8、または 16 のプロセッシング ユニットを購入できます。

プロセッシング ユニットで取り込みおよびストリーミングできる量は、プロデューサー、コンシューマー、取り込みと処理の速度など、さまざまな要因によって異なります。 十分なパーティションがあり、ストレージが調整要因とならない場合、1 つのプロセッシング ユニットでは、約 5 から 10 MB/秒のイングレスと 10 から 20 MB/秒のエグレスのコア容量を提供できます。


Event Hubs organizes sequences of events sent to an event hub into one or more partitions. As newer events arrive, they're added to the end of this sequence.

Event Hubs

A partition can be thought of as a "commit log". Partitions hold event data that contains body of the event, a user-defined property bag describing the event, metadata such as its offset in the partition, its number in the stream sequence, and service-side timestamp at which it was accepted.

Diagram that displays the older to newer sequence of

Advantages of using partitions

Event Hubs is designed to help with processing of large volumes of events, and partitioning helps with that in two ways:

  • Even though Event Hubs is a PaaS service, there's a physical reality underneath, and maintaining a log that preserves the order of events requires that these events are being kept together in the underlying storage and its replicas and that results in a throughput ceiling for such a log. Partitioning allows for multiple parallel logs to be used for the same event hub and therefore multiplying the available raw IO throughput capacity.
  • Your own applications must be able to keep up with processing the volume of events that are being sent into an event hub. It may be complex and requires substantial, scaled-out, parallel processing capacity. The capacity of a single process to handle events is limited, so you need several processes. Partitions are how your solution feeds those processes and yet ensures that each event has a clear processing owner.

Number of partitions

The number of partitions is specified at creation and must be between 1 and the maximum partition count allowed for each pricing tier.

We recommend that you choose at least as many partitions as you expect to require in sustained the throughput units (TU), processing units (PU) or capacity units (CU) during the peak load of your application for that particular Event Hub.

You should calculate with a single partition having a throughput capacity of pricing unit(TU, PU or CU) of each tier. You can scale the TUs or PUs on your namespace or the CUs of your dedicated cluster independent of the partition count. For example, an Event Hub of the standard tier with 32 partitions or an Event Hub with 1 partition incur the exact same cost when the namespace is set to 1 TU capacity.

The partition count for an event hub in a dedicated Event Hubs cluster can be increased after the event hub has been created, but the distribution of streams across partitions will change when it's done as the mapping of partition keys to partitions changes, so you should try hard to avoid such changes if the relative order of events matters in your application.

Setting the number of partitions to the maximum permitted value is tempting, but always keep in mind that your event streams need to be structured such that you can indeed take advantage of multiple partitions. If you need absolute order preservation across all events or only a handful of substreams, you may not be able to take advantage of many partitions. Also, many partitions make the processing side more complex.

Mapping of events to partitions

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. 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.

Specifying a partition key enables keeping related events together in the same partition and in the exact order in which they arrived. The partition key is some string that is derived from your application context and identifies the interrelationship of the events. A sequence of events identified by a partition key is a stream. A partition is a multiplexed log store for many such streams.


While you can send events directly to partitions, we don't recommend it, especially when high availability is important to you. It downgrades the availability of an event hub to partition-level. For more information, see Availability and Consistency.


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