Event Hubs によるスケーリング
Event Hubs によるスケーリングに影響する 2 つの要素があります。
- スループット ユニット (Standard レベル) または処理ユニット (Premium レベル)
- [ パーティション]
スループット ユニット
Event Hubs のスループット容量は、"スループット ユニット" によって制御されます。 スループット ユニットとは、購入済みの容量ユニットのことです。 1 つのスループット ユニットにより、次のことが可能になります。
- イングレス: 1 秒あたり最大で 1 MB または 1,000 イベント (どちらか先に到達した方)。
- エグレス: 1 秒あたり最大で 2 MB または 4,096 イベント。
購入済みのスループット ユニットの容量を超えると、イングレスが調整され、Event Hubs によって ServerBusyExceptionがスローされます。 エグレスではスロットル例外は発生しませんが、購入済みのスループット ユニットの容量に制限されます。 発行率の例外を受信するか、より高いエグレスが予想される場合は、名前空間に対して購入したスループット ユニットの数を確認してください。 スループット ユニットは、Azure portal の名前空間の [スケール] ページで管理できます。 Event Hubs API を使用して、プログラムでスループット ユニットを管理することもできます。
スループット ユニットは事前に購入し、1 時間ごとに課金されます。 スループット ユニットを購入すると、少なくとも 1 時間の料金が課金されます。 Event Hubs の名前空間に対して最大 40 のスループット ユニットを購入でき、その名前空間内のすべてのイベント ハブで共有されます。
Event Hubs の自動インフレ機能は、使用量のニーズに合わせてスループット単位の数を増やすことで、自動的にスケールアップします。 スループット単位を増やすことで、以下の状況で必要になる調整シナリオを防ぐことができます。
- データの受信レートが、設定されたスループット単位を超えている。
- データの送信要求レートが、設定されたスループット単位を超えている。
負荷が最小しきい値を超えていて、ServerBusy エラーなどで失敗した要求がない場合、Event Hubs サービスでスループットが増えます。
自動インフレ機能の詳細については、スループット単位の自動的なスケーリングに関する記事を参照してください。
プロセッシング ユニット
Event Hubs Premium は、マネージド マルチテナント PaaS 環境で優れたパフォーマンスと分離性を提供します。 Premium レベルのリソースは CPU とメモリのレベルで分離され、各テナント ワークロードが分離して実行されます。 このリソース コンテナーを "プロセッシング ユニット" (PU) と呼びます。 各 Event Hubs Premium 名前空間に対して 1、2、4、6、8、10、12、16 のプロセッシング ユニットを購入できます。
プロセッシング ユニットで取り込みおよびストリーミングできる量は、プロデューサー、コンシューマー、取り込みと処理の速度など、さまざまな要因によって異なります。
たとえば、Event Hubs Premium 名前空間には 1 つの PU と 1 つのイベント ハブ (100 のパーティション) があり、およそのコア容量が AMQP ワークロードと Kafka ワークロードのどちらでもイングレスが約 5 - 10 MB/秒、エグレスが 10 - 20 MB/秒 です。
Premium レベルの名前空間の PU の構成については、「処理ユニットの構成」を参照してください。
注意
クォータと制限の詳細については、「Azure Event Hubs - クォータと制限」を参照してください。
メジャー グループ
イベント ハブでは、イベント ハブに送信されたイベントのシーケンスを 1 つまたは複数のパーティションにまとめて整理します。 新しいイベントが到着すると、このシーケンスの末尾に追加されます。
パーティションはコミット ログと考えることができます。 パーティションには、次の情報を含むイベント データが保持されます。
- イベントの本文
- イベントを記述するユーザー定義プロパティ バッグ
- パーティション内のオフセット、ストリーム シーケンス内の数などのメタデータ
- 受け入れられたサービス側のタイムスタンプ
パーティションを使用する利点
Event Hubs の目的は、大量のイベントの処理を支援することです。パーティションは、2 つの方法でそれを支援します。
- Event Hubs は PaaS サービスであるとはいえ、根底には物理的な現実があります。 イベントの順序を保持するログを維持するためには、根底にあるストレージとそのレプリカにそれらのイベントがまとめて保持されている必要があるため、そのようなログにはスループットの上限が生じます。 パーティションに分割することにより、同じイベント ハブで複数の並列ログを使用できるため、生の入出力 (IO) のスループット容量が増えます。
- 個々のアプリケーションは、イベント ハブに送信される量のイベントの処理に遅れずついていくことができなければなりません。 これは複雑になる場合があり、相当にスケールアウトされた並列処理能力が必要になります。 イベントを処理する 1 つのプロセスの容量は限られているため、複数のプロセスが必要になります。 パーティションを使用することで、そうしたプロセスにイベントをフィードしながら、各イベントの処理の所有者を明確化することができます。
パーティションの数
パーティションの数は、イベント ハブの作成時に指定します。 この数は、1 から、各価格レベルで許可されている最大パーティション数の間である必要があります。 各レベルのパーティション数の制限については、こちらの記事を参照してください。
アプリケーションの負荷がピークに達している状態で必要となる以上のパーティションを、その特定のイベント ハブに選択することをお勧めします。 Premium および専用レベル以外のレベルの場合、イベント ハブの作成後にイベント ハブのそのパーティション数を変更することはできません。 Premium または専用レベル内のイベント ハブの場合、イベント ハブの作成後にパーティション数を増やすことはできますが、それらを減らすことはできません。 パーティションへのパーティション キーのマッピングは変化するため、パーティション全体に対するストリームの配分は、それが実行される際に変化します。そのため、お使いのアプリケーション内でイベントの相対的な順序が重要な場合は、そのような変更は極力避けるようにしてください。
パーティション数を上限に設定したくなるかもしれませんが、複数のパーティションの利点を実際に活かせるようにイベント ストリームを構築する必要があることを常に念頭に置いてください。 すべてのイベントについて、または一部のサブストリームのみについて、絶対的な順序を保持する必要がある場合、多くのパーティションを活用できないことがあります。 また、パーティション数が多いと処理する側もより複雑になります。
イベント ハブに含まれるパーティションの数は、料金には関係ありません。 名前空間または専用クラスターの価格ユニット (Standard レベルではスループット ユニット (TU)、Premium レベルではプロセッシング ユニット (PU)、専用レベルでは容量ユニット (CU)) によって決まります。 例えば、名前空間の容量が 1 TU に設定されている場合、パーティションが 32 個でも 1 個でも、Standard レベルのイベント ハブで発生するコストはまったく同じです。 さらに、パーティション数とは関係なく、お使いの名前空間上の TU または PU、あるいは専用クラスターの CU をスケーリングできます。
パーティションは、データの発行と使用を並列して行うことができるデータ編成メカニズムです。 最適なスケールを実現するには、スケーリング ユニット (Standard レベルの場合はスループット ユニット、Premium レベルの場合は処理ユニット、または Dedicated レベルの場合は容量ユニット) とパーティションのバランスを取ることをお勧めします。 一般に、パーティションあたり最大スループットは 1 MB/s にすることをお勧めします。 したがって、パーティションの数を計算するための経験則は、予想される最大スループットを 1 MB/s で除算することです。 たとえば、ユース ケースで 20 MB/s が必要な場合は、最適なスループットを実現するために、少なくとも 20 個のパーティションを選ぶことをお勧めします。
ただし、アプリケーションで特定のパーティションに対してアフィニティが設定されているモデルがある場合、パーティション数を増やすことは有効ではありません。 詳細については、
パーティションへのイベントのマッピング
パーティション キーを使用すると、データ編成を目的として受信イベント データを特定のパーティションにマップすることができます。 パーティション キーは、送信者によって指定され、イベント ハブに渡される値です。 これは、パーティション割り当てを作成する静的なハッシュ関数で処理されます。 イベントを発行するときにパーティション キーを指定しないと、ラウンド ロビン割り当てが使用されます。
イベント発行元は、そのパーティション キーのみを認識し、イベントの発行先となるパーティションは認識しません。 このようにキーとパーティションを分離することにより、送信者はダウンストリーム処理について余分な情報を把握しなくてもよくなります。 デバイスごとまたはユーザーの一意の ID は適切なパーティション キーになりますが、地理的条件などのその他の属性を使用して関連するイベントを 1 つのパーティションにまとめることもできます。
パーティション キーを指定すると、関連するイベントを同じパーティションにまとめて、到着時とまったく同じ順番で保存することができます。 パーティション キーは、アプリケーションのコンテキストから得られる文字列で、イベントの相互関係を識別するものです。 パーティション キーによって識別される一連のイベントが "ストリーム" です。 パーティションは、そのようなたくさんのストリームが混在するログ ストアです。
Note
イベントはパーティションに直接送信できますが、特に、高可用性が重要な場合は推奨されません。 イベント ハブの可用性がパーティション レベルにダウングレードされます。 詳細については、可用性と一貫性に関するページを参照してください。
次のステップ
Event Hubs の詳細については、次のリンク先を参照してください: