2026.07.23 インフラ

Azure Event Hubsとは｜大量イベントを取り込むKafka互換ストリーミング基盤の仕組みと採用判断

Azure Event Hubs（アジュール イベントハブス）は、IoT機器やアプリケーション、Webのクリックストリームなどが絶え間なく出す大量の「イベント」を、毎秒単位で受け止めて後続の処理へ流す、フルマネージドのリアルタイムストリーミング基盤です。ポイントは、届いたイベントを追記専用のログにためて、パーティションという単位で分散・並列処理できるようにする点にあります。この記事で扱うのは、名前空間・イベントハブ・パーティションという3階層の構成、プロデューサーとコンシューマーグループ・オフセット・チェックポイントによる読み取りの仕組み、AMQP・Kafka・HTTPSの3プロトコルとKafkaエンドポイント、保持期間とCaptureによる長期保存、Basic/Standard/Premium/Dedicatedの課金体系、そしてService BusやAWS Kinesis・GCP Pub/Subといつ使い分けるかの判断です。似た名前のEvent GridやEventBridgeとは役割の層が違うため、その線引きも整理します。

目次

まとめ：Event Hubsは大量イベントを取り込むKafka互換のストリーミング基盤

先に結論を示します。Event Hubsは、送り手が投げた大量のイベントを追記専用ログに時系列で受け止め、複数のパーティションに分けて並列にさばく「取り込み口（インジェスト）」です。IoTのテレメトリ、アプリケーションログ、クリックストリームのように、秒間に何千・何万と流れてくるデータを取りこぼさず受け、後段の分析やストレージへ渡す土台になります。サーバーの管理は不要で、必要なスループットの分だけ容量ユニットを確保する従量制のPaaSです。

向くのは、大量のイベントを高スループットで受けたい、複数の処理系（分析・保管・アラートなど）が同じストリームをそれぞれの進み具合で読みたい、既存のKafka資産をコードを変えずにクラウドへ寄せたい、といったケースになります。逆に、注文処理のように1件ずつ確実に処理してから消したいキュー用途や、状態変化を条件で振り分けるルーティング用途では、Service BusやEvent Gridのほうが素直に収まります。まず「ストリームを丸ごと取り込んで並列に読ませたいか」を起点に考えると、Event Hubsの持ち場がはっきりするはずです。

Event Hubsの基本｜名前空間・イベントハブ・パーティションの3階層

Event Hubsを理解する近道は、リソースの入れ子構造と、その中を流れるイベントの持ち方をつかむことです。ここでは全体像から入ります。

名前空間・イベントハブ・パーティションという入れ子の構成要素

Event Hubsは3階層で組み立てられています。いちばん外側が名前空間で、ネットワークアクセスやスケーリングをまとめて制御する管理コンテナです。その中に置くのがイベントハブで、これはイベントを時系列でためる追記専用ログにあたり、Apache Kafkaでいうトピックに相当します。さらにイベントハブの内側がパーティションで、届いたイベントの順序付きシーケンスを1本の列として保持する単位です。送り手はイベントハブへイベントを投げ、Event Hubsが内部でパーティションへ振り分けてため、受け手がパーティション単位で読み出す、という流れになります。既存のKafkaの語彙で言うなら、名前空間がクラスタ、イベントハブがトピック、パーティションがそのままパーティションと対応させて考えると迷いません。

パーティションがスループットと並列処理の上限を決める基本の仕組み

パーティションは、Event Hubsのスループットと並列度を左右する中心的な部品です。1つのパーティションはコミットログのように振る舞い、新しいイベントは末尾に追記されて、そのパーティション内では到着順が保たれます。イベントハブを複数のパーティションに分けると、並列に書き込み・読み出しができるぶんだけ処理能力が上がる仕組みです。パーティション数はイベントハブの作成時に指定し、Standardレベルなど一部のレベルでは作成後に変更できないため、負荷のピークを見込んで多めに取るのが定石になります。注意したいのは、パーティションを増やすとコンシューマー側の並列インスタンスをその数まで増やせる反面、ストリーム全体で絶対的な順序を守りたい場合は分散のメリットを活かしにくい点です。パーティションキーで関連イベントを同じパーティションへ寄せれば、その範囲での順序は保てます。なお、パーティション数そのものは料金に影響せず、課金は後述の容量ユニットで決まります。

プロデューサーとコンシューマー｜送受信とコンシューマーグループ

誰がどうイベントを送り、誰がどう読むか。ここがEvent Hubsを実装するうえで最初に設計する部分です。

プロデューサーの発行方法とパーティションキーによる振り分けの流れ

プロデューサー（パブリッシャー）は、イベントハブへイベントを送るアプリケーションを指します。送信手段は幅広く、.NET・Java・Python・JavaScript・GoのAzure SDK、軽量なHTTP POSTのREST API、既存資産をそのまま使えるKafkaクライアント、汎用のAMQP 1.0クライアントから選べます。イベントは1件ずつでも、まとめてバッチでも発行でき、1回の発行操作あたり最大1MBという上限がある点は要注意です。振り分けの鍵になるのがパーティションキーで、送り手が指定した文字列（デバイスIDやユーザーIDなど）をハッシュして送り先パーティションを決める仕組みです。同じキーのイベントは同じパーティションへ集約され、到着順のまま保存されます。キーを指定しなければラウンドロビンで分散されるため、順序を意識しないなら未指定で負荷を平準化する選び方が現実的です。認証はMicrosoft Entra ID（OAuth 2.0のRBAC）か、送信・リッスンの権限を絞ったSASトークンを使います。

コンシューマーグループ・オフセット・チェックポイントによる読み取り

コンシューマーは、イベントハブからイベントを読むアプリケーションです。Event Hubsはプルモデルを採り、受け手が必要なタイミングでイベントを要求して取りに行きます。ここで効いてくるのがコンシューマーグループで、これは同じイベントストリームに対する独立したビューを指します。分析用・アーカイブ用・アラート用というように処理系ごとに別のグループを作れば、それぞれが自分の進み具合で同じデータを読めるわけです。読み取り位置を表すのがオフセットで、パーティション内のイベントの位置を示すカーソルにあたり、特定のオフセット・タイムスタンプ・ストリームの先頭や末尾から読み始められます。そして、どこまで読んだかを保存するのがチェックポイントで、通常はAzure Blob Storageに記録する形です。これがあることで、コンシューマーが切断しても最後のチェックポイントから再開でき、別インスタンスへのフェールオーバーや、過去オフセットを指定した再生も可能になります。実装ではEventProcessorClient（.NET/Java）やEventHubConsumerClient（Python/JavaScript）を使うと、パーティションの割り当てや負荷分散、チェックポイント処理を自動でさばいてくれます。

プロトコルとKafka互換｜AMQP・Kafka・HTTPSの使い分け

どのプロトコルで送受信するかは、既存資産と処理特性で決まります。3つの選択肢とKafka互換の意味を押さえます。

AMQP・Apache Kafka・HTTPSという3つのプロトコルの選び方

Event Hubsは3種類のプロトコルに対応します。AMQP 1.0は送受信の両方に使え、永続的な双方向接続で高スループット・低遅延を狙う本命で、Azure SDKが内部で使うのもこれです。Apache Kafkaも送受信に対応し、バージョン1.0以降のKafkaクライアントがそのままEvent Hubsと通信できます。HTTPSは送信のみの対応で、単純なHTTP POSTで投げられるぶん、常時接続が張れない軽量クライアントやファイアウォールの厳しい環境からの、たまの少量発行に向きます。恒常的に大量のイベントを流すならAMQPかKafka、接続を張り続けられない環境からの散発的な送信ならHTTPS、という当て方が実務の目安です。受信はAMQPかKafkaに限られる点も設計時に押さえておきます。

KafkaエンドポイントによるKafka資産の無改修でのクラウド移行

Event Hubsには、Kafkaのプロデューサーとコンシューマーをそのまま受け付けるKafkaエンドポイントが備わっています。これにより、Kafkaで作った既存アプリケーションは、接続先のブートストラップサーバーをEvent Hubsの名前空間へ差し替えるだけで、コードを書き換えることなく動かせます。自前でKafkaクラスタを構築・運用する負担を負わずに、マネージドなKafka互換の受け皿を得られる、というのが実務での効きどころです。Kafkaそのものの特徴や、なぜ選ばれるのかという背景はApache Kafkaが選ばれる理由の解説で整理しているので、Kafka互換の意味をつかむ補助になります。オンプレミスや他クラウドのKafkaからAzureへ寄せる移行の第一歩として、この互換性は現実的な選択肢になります。

保持期間とCapture・料金｜データ管理と課金体系のとらえ方

取り込んだイベントをどれだけ持ち、どう長期保存し、何にいくらかかるか。運用に直結する部分を整理します。

保持期間の自動削除とCaptureによる長期保存という二段構え

Event Hubsはデータベースではなくストリーミングエンジンなので、イベントは時間ベースの保持ポリシーで自動的に消えていきます。既定の保持は1時間で、上限はStandardレベルで7日、PremiumとDedicatedでは90日まで延ばせます（2026年時点）。イベントを1件ずつ明示的に削除する操作はなく、保持期間を過ぎたものから使えなくなる仕組みです。そのため、あとから何度も読み返したいデータや長期に残したいデータは、Captureを使ってAzure Blob StorageやData Lake Storageへ自動保存します。Captureは最小サイズと時間枠を条件に、流れてくるストリームをファイルとして書き出す機能で、既定のフォーマットはAvro、Parquetでの出力も選べます。ストリームは取り込みと近リアルタイム処理に、長期保管はCaptureで別ストレージに、と役割を分けて設計するとデータの持ち方が破綻しません。

Basic〜DedicatedのレベルとTU・PU・CUの課金体系

料金は、確保する処理容量の単位と、取り込んだイベントの量で決まる従量制です。容量の単位はレベルごとに分かれ、Standardはスループットユニット（TU）、Premiumは処理ユニット（PU）、Dedicatedは容量ユニット（CU）を確保する形になります。Standardではおおよそ1パーティションあたり最大1MB/秒の取り込みと2MB/秒の読み出しが目安とされ、必要なスループットからTU数を見積もります。押さえておきたいのは、パーティションの数は料金に関係しない点で、同じ1 TUなら32パーティションでも1パーティションでもコストは変わりません。エントリー向けのBasicはKafkaエンドポイントやCapture、複数コンシューマーグループが使えないなど機能が絞られ、専有リソースや長い保持が要るならPremiumやDedicatedへ上げる判断になります。取り込みイベント数の単価やCaptureの追加料金といった具体的な金額は改定されるため、2026年時点の値としてAzure公式の料金ページで最新を確認するのが確実です。ここではレベルとTU/PU/CUという課金の骨格を押さえておけば、見積もりの土台になります。

Event Hubsと類似サービスの違い｜キュー・ルーターとの対比

名前や用途が近いサービスと並べると、Event Hubsの持ち場がくっきりします。役割の層で切り分けます。

Azure Service BusやEvent Gridとの役割差

Azure内で混同しやすいのがService BusとEvent Gridです。Service Busは、注文や決済のようなメッセージを1件ずつ確実に届け、受け手が処理し終えたら消す、業務メッセージング向けのキュー/トピックを指します。Event Gridは、リソースの状態変化などの「起きた事実」を、条件に合う購読先へ振り分けて配るイベントルーターです。これに対しEvent Hubsは、大量のイベントをストリームとして丸ごと取り込み、複数の受け手が同じデータをそれぞれの位置で読む、高スループットの取り込み基盤という違いがあります。1件ずつの確実な受け渡しならService Bus、状態変化の条件振り分けならEvent Grid、テレメトリやログの大量ストリームならEvent Hubs、と用途で選び分けるとぶつかりません。実際には、Event Hubsで受けたストリームを分析基盤へ、業務系の指示はService Busで、という併用構成もよく取られます。

AWS・GCPの類似サービス（Kinesis・Pub/Sub）との対応

他クラウドの経験がある場合は、対応するサービスに置き換えると理解が早まります。Event Hubsに最も近いのは、AWSのKinesis Data Streams（パーティション＝シャードで大量ストリームを取り込む）で、GCPではPub/Subが近い立ち位置です。GCPのPub/Subの考え方はCloud Pub/Subの基本概念の解説で確認でき、メッセージング基盤としての役割を対比の軸にできます。一方で、名前が似ているAWSのEventBridgeやAzureのEvent Gridは、イベントを条件で振り分けるルーター層のサービスで、ストリームを丸ごと取り込むEvent Hubsとは役割の層が異なるものです。EventBridgeがどんな連携を担うのかはAmazon EventBridgeとはの解説に整理があり、読み比べると「取り込み（Event Hubs/Kinesis/Pub/Sub）」と「ルーティング（EventBridge/Event Grid）」の線引きが腑に落ちます。同じ「イベント」でも層が違う点を押さえると、サービス選定を誤りません。

Event Hubsを採用すべき条件と見送って別方式に寄せる場面

ここは言い切ります。Event Hubsはあらゆるイベント処理の正解ではありません。向く条件と、あえて選ばない場面を分けて示します。

Event Hubsの採用が向く条件｜大量ストリームと複数系統の並列読み取り

効果が出るのは、秒間に多数のイベントが流れる高スループットの取り込みを、サーバー管理なしで実現したいケースです。IoTデバイスのテレメトリ収集、アプリケーションログやメトリクスの集約、Webのクリックストリーム分析、そして複数の処理系（リアルタイム分析・長期保管・異常検知）が同じストリームをそれぞれの進み具合で読む構成が典型になります。既存のKafkaアプリケーションをコードを変えずにクラウドへ寄せたい移行案件でも、Kafkaエンドポイントが受け皿になるはずです。Azure上でこうしたストリーミングやデータ基盤を設計・実装したい、既存のバッチ集約をイベント駆動へ組み替えたいといった相談はAWS・Google Cloud・Azureを含むインフラ構築の受託で受け付けています。設計から運用までを外部に任せたい場合の入口として使ってください。

見送るべき場面｜1件ずつの確実な処理や条件振り分けが主目的のケース

逆に見送ったほうがよい場面もあります。注文や決済のように、メッセージを1件ずつ確実に処理して完了したら消す、という業務トランザクション型の受け渡しでは、デッドレターや重複排除を備えるService Busのほうが適します。状態変化を条件で判定して特定の宛先だけへ配るルーティングが主目的なら、Event GridやEventBridgeを選ぶ判断です。また、ストリーム全体で厳密な全体順序を守りたい要件も、パーティションをまたぐと順序は保証されないため、パーティションキー設計で吸収できる範囲かを事前に見極める必要があります。判断の順序としては、まず「大量ストリームを取り込んで複数系統に並列で読ませたいか」を確かめ、当てはまらなければキュー型やルーター型へ寄せる、という進め方が堅実です。

よくある質問

Event Hubsの位置づけや他サービスとの違いなど、導入前に迷いやすい点をまとめます。

Azure Event HubsとService Busはどう違いますか？

Event Hubsは大量のイベントをストリームとして取り込み、複数の受け手が同じデータを並列に読む取り込み基盤です。Service Busはメッセージを1件ずつ確実に届けて処理後に消す、業務メッセージング向けのキュー/トピックにあたります。テレメトリやログの大量ストリームならEvent Hubs、注文や決済のような確実な受け渡しならService Bus、という使い分けになります。

Event HubsはApache Kafkaの代わりになりますか？

多くの用途で代替になります。Event HubsはKafkaエンドポイントを備え、バージョン1.0以降のKafkaクライアントが接続先のブートストラップサーバーを差し替えるだけで、コードを変えずに使えるのが強みです。自前でKafkaクラスタを構築・運用せずに、マネージドなKafka互換の受け皿を得たい場合に向いています。

パーティションの数はいくつにすればよいですか？

必要なスループットと、読み取り側で並列に動かしたいコンシューマー数から見積もります。パーティション数はコンシューマーグループあたりの並列読み取りの上限になり、Standardなど一部のレベルでは作成後に変更できません。負荷のピークを見込んで少し多めに取るのが目安ですが、全体順序を厳密に守りたい場合は分散の利点を活かしにくい点に注意します。

取り込んだイベントを長期に保存できますか？

Event Hubs自体の保持は時間ベースで自動的に消え、既定1時間・Standardで最大7日、Premium/Dedicatedで最大90日です（2026年時点）。長期に残したいデータはCapture機能でAzure Blob StorageやData Lake Storageへ自動保存します。既定はAvro形式で、Parquetでの出力も選べます。

Event Hubsの料金はどのように決まりますか？

確保する処理容量の単位（Standardはスループットユニット、Premiumは処理ユニット、Dedicatedは容量ユニット）と、取り込んだイベントの量で決まる従量制です。パーティションの数は料金には影響しません。取り込みイベント単価やCaptureの追加料金は改定されるため、具体的な金額はAzure公式の料金ページで2026年時点の最新値を確認するのが確実です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る