Skip to content

MS_AzureEventHubs

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 2 revisions

Azure Event Hubs

概要

ビッグ データのパイプライン（テレメトリおよびイベント ストリーム データの
キャプチャ、保持、再生）の開発を容易にする。

  • 任意のソースから毎秒数百万のイベントをストリーミングする。
  • AMQP や HTTP といった
    プロトコルを使って、大量のメッセージを中継することができるハブ
    • メッセージをイベントと記載している。
    • OSS 製品だと RabbitMQ などが近い。
    • MQTT はサポートしていない模様。
  • Kafka プロトコルを使用
    • バージョン 1.0 以降をサポート
    • マネージド Kafka エクスペリエンスを実現
    • 既存の Kafka クライアント（およびアプリが）
      Event Hubs と通信できるように設定できる。

補足（Kafka 互換の意味）: 「Kafka プロトコルを使用できる」ことの
実務上の価値は大きい。

  • 既存の Kafka アプリを、接続文字列の変更だけで移行できる
  • Kafka の運用（ZooKeeper / ブローカー / パーティション再配置）が不要
  • Kafka Connect / Spark / Flink などのエコシステムがそのまま使える

つまり「Kafka の API を持つマネージド サービス」として使える。
ただし Kafka の全機能ではなく、
Kafka Streams や一部の管理 API は非対応である点に注意が要る。

詳細

機能

プロトコル

HTTP、AMQP 1.0、または Kafka プロトコルを使用。

クライアント

  • REST API（WebAPI）
  • 各クライアント ライブラリ
    • .NET / Java / JavaScript / Python / Go
    • Kafka クライアント（プロトコル互換）

ストア

  • リアルタイムのイベント ストリーム エンジンであるため、
    永続的なストアの代わりとして使用されるように設計されていない。
  • Capture を有効にすると、
    任意の BLOB ストレージ アカウント または Azure Data Lake アカウントに
    永続化できる。

補足（保持期間に注意）: Event Hubs は
**既定で 1 日（Standard は最大 7 日、Premium/Dedicated は最大 90 日）**しか
データを保持しない。

用途 手段
短期のリアルタイム処理 Event Hubs のまま
長期保存・再処理 Capture で Blob / Data Lake へ自動保存

Capture はコードを書かずに Avro 形式で書き出せるため、
「取り込みは Event Hubs、蓄積は Data Lake」という
ラムダ アーキテクチャ的な構成を簡単に組める。

用語

用語 内容
イベント・パブリッシャー Event Hubs にデータを送信するエンティティ。パーティション分割モデルを認識せず、パーティション キーのみ指定するのがベスト プラクティス
パブリッシャー・ポリシー 多数の独立したイベント発行元を支援するランタイム機能
名前空間 イベント ストリームのエンドポイント（DNS 統合、アクセス制御）
パーティション イベント ストリームを整理する単位。スケーリングの単位
コンシューマ・グループ パーティションへの個別のビュー。オフセットを持つ
イベント・コンシューマー Event Hubs からイベント データを読み取るエンティティ

パーティション

  • 送られてきたイベントのシーケンスを 1 つまたは複数のパーティションに整理
  • パーティションとスループット ユニットの割り当てを使用してスケーリングされる。

コンシューマ・グループ

  • パーティションにはコンシューマー・グループを介してのみアクセス可能
  • コンシューマ・グループは、
    • パーティション毎にオフセットを持ち、
      イベント ストリームの個別のビューとして機能する。
    • チェックポイントでオフセットを管理し以下を実現できる。
      • フェールオーバーの回復性
      • イベント ストリームの再生
  • 仕様と推奨
    • 推奨: コンシューマー・グループ毎、
      1 つのパーティションには 1 つのイベント・コンシューマーが接続。
      1 つのコンシューマーが複数のパーティションに接続するのは OK。
    • 仕様: 1 つのパーティションは、最大 5 つのコンシューマーから接続可能。

補足（パーティション数は後から変えられない）: Event Hubs の設計で
最も重要な決定がこれである。

事項 内容
並列度の上限 パーティション数 = 同時に読める最大数
変更 作成後は変更できない（Standard の場合）
順序保証 同一パーティション内でのみ保証される

少なすぎるとスケールしない、多すぎるとコンシューマー側が複雑になる。
将来の並列度を見越して決める必要がある。

また、「パーティション キーのみ指定し、パーティション番号を指定しない」
というベスト プラクティスは、キーのハッシュで自動配分させることで
偏りとパーティション数への依存を避けるためである。

参考

Microsoft Learn

開発基盤部会 Wiki

Tags: 移行, クラウド, IoT, ビッグデータ, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally