Azure Event Hubs

解決する課題

大量のイベントを単一のエンドポイントで受け止め、複数のダウンストリームへ流すための取り込み層を提供します。

• 大量データを リアルタイム に取り込みたい（毎秒数百万イベント規模）
• 複数の処理系で 同じストリームを並行処理 したい（コンシューマーグループ）
• ストリームを Blob Storage / Data Lake へ自動保存 したい（Capture）
• Kafka クライアントを コード変更なし で Azure 側に向けたい（Kafka 互換エンドポイント）

主要概念と用語

• 名前空間（Namespace）: Event Hubs を束ねる管理コンテナ。スループット単位や課金の境界となる
• イベントハブ（Event Hub）: Kafka の「トピック」に相当する個々のストリーム
• パーティション: イベントハブを構成する順序付きシーケンス。並列度とスループットの単位（AWS の「シャード」相当）
• パーティションキー: 同じキーを持つイベントを同一パーティションへ振り分け、順序を保証する
• コンシューマーグループ: ストリーム全体の独立した「ビュー」。各グループが自分のオフセットで読み進める
• スループット単位（TU）/ 処理単位（PU）/ キャパシティ単位（CU）: Standard は TU、Premium は PU、Dedicated は CU でスケールする
• Event Hubs Capture: イベントを Blob Storage / Data Lake Storage Gen2 へ Avro 形式で自動保存する機能
• Kafka エンドポイント: Apache Kafka プロトコル（1.0 以降）互換のエンドポイント。Standard 以上で利用可

仕様・制限・クォータ

• スループットは単位（TU/PU/CU）で決まる。1 TU = 入力 1 MB/秒（または 1,000 イベント/秒）、出力 2 MB/秒が目安
• Auto-Inflate（Standard）で TU を上限まで自動拡張できる（自動縮小はしない）
• 保持期間: Basic は 1 日固定、Standard は最大 7 日、Premium / Dedicated は最大 90 日。保持期間内はオフセット指定で再読み込み可能
• パーティション数は作成後に増やせる場合があるが、原則は作成時に決める設計対象（順序保証はパーティション内のみ）
• 1 イベントの最大サイズ: Basic / Standard は 1 MB、Premium / Dedicated は 1 MB（バッチ送信が基本）
• 名前空間あたりのイベントハブ数・パーティション数には SKU ごとの上限がある

内部の仕組み

Event Hubs は、送信されたイベントをパーティションキーに基づいて パーティションへ分散し、各パーティション内では 追記専用（append-only）の順序付きログとして保持します。保持期間内であれば、複数のコンシューマーグループがそれぞれのオフセットから読み直せるのが特徴です（キューの Service Bus は取り出すと消えるのに対し、Event Hubs は読んでも消えません）。

• パーティションキーを指定しない送信は、パーティション間にラウンドロビン的に分散される
• 読み取り側は オフセットまたはシーケンス番号で位置を管理し、チェックポイント（通常は Blob Storage）に保存して再開する
• Capture を有効にすると、ストリームと並行してイベントが Blob / Data Lake へ Avro 形式で自動保存され、バッチ分析やアーカイブに使える

設計パターン / ベストプラクティス

• 取り込み＝ Event Hubs、ストリーム処理／集計＝ Azure Stream Analytics または Functions、保存＝ Capture → Blob/Data Lake
• パーティションキー設計で「ホットパーティション」を回避し、スループットを均等化する
• スループットが読めなければ Auto-Inflate（Standard）または Premium（CPU/メモリ分離）を採用
• 既存の Kafka 資産があるなら Kafka エンドポイントで接続し、コード変更を最小化
• コンシューマーは イベントプロセッサー（EventProcessorClient） を使い、パーティション割り当てとチェックポイントを SDK に任せる

運用・監視・トラブルシュート

• Azure Monitor のメトリクスで監視: IncomingMessages / OutgoingMessages / IncomingBytes / ThrottledRequests（スロットル）
• コンシューマーの遅延は チェックポイントのオフセットと最新オフセットの差で検知する（Kinesis の IteratorAge に相当する考え方）
• ThrottledRequests が出たら TU/PU 不足またはホットパーティションを疑う
• 診断設定でキャプチャ／実行時ログを Log Analytics へ送り、送受信・エラーを可視化

コスト

SKU（価格レベル）の選択がコスト最適化の肝です。Standard は TU、Premium は PU、Dedicated は CU で課金されます。

セキュリティ

• Microsoft Entra ID + RBAC で送受信権限を制御（Azure Event Hubs Data Sender / Data Receiver ロール）。資格情報のハードコードを避ける
• 共有アクセス署名（SAS）も利用可能だが、原則は Entra ID 認証を推奨
• 保存データはサービス側で暗号化（SSE）。Premium / Dedicated は カスタマーマネージドキー（Key Vault） に対応
• プライベートエンドポイント / ネットワーク規則で公開アクセスを制限し、転送は TLS で保護

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Event Hubs 名前空間を作成（Standard レベル）
az eventhubs namespace create \
  --resource-group demo-rg \
  --name demo-ehns-0603 \
  --location japaneast \
  --sku Standard

# 名前空間の中にイベントハブ（ストリーム）を作成（4パーティション・保持3日）
az eventhubs eventhub create \
  --resource-group demo-rg \
  --namespace-name demo-ehns-0603 \
  --name events \
  --partition-count 4 \
  --cleanup-policy Delete \
  --retention-time-in-hours 72

# 専用のコンシューマーグループを追加（処理系ごとに独立して読む）
az eventhubs eventhub consumer-group create \
  --resource-group demo-rg \
  --namespace-name demo-ehns-0603 \
  --eventhub-name events \
  --name analytics-consumer