Azure EventHubsとは
Microsoftが挙げているポートフォリオの一つに、Service Busというものがあります。
これは、アプリケーションとAzureサービスの間で信頼性の高いメッセージングサービスを
提供するというもの。
EventHubsは、何百万ものアプリケーション・デバイスから送信されるメッセージを受け付ける
ことのできる、パブリッシュ/サブスクライブサービス。
何がうれしいのか？
-
1秒間あたり数百万規模のメッセージを受け付けることができる。
-
デバイスから送信されるログを集約するWebサーバを構築するのにくらべて、
安く、楽に、高可用性（スケール）、高信頼性(認証)、高耐障害性(バッファリング)な環境を構築することができる。 -
受け付けたメッセージをリアルタイムに処理を行うことに適している。
- ETL, リアルタイムウィンドウ集計のためのストリームとして。
EventHubsとKinesisの機能比較
| Azure EventHubs | Amazon Kinesis | |
|---|---|---|
| Consumer | EventConsumer | Record |
| Streamの単位 | Partition(Partition key) | Shard ( partition Key) |
| offset | Sequence number | Sequence number |
| ストリームPUT | 1MB, 1000レコード | 1MB, 1000レコード |
| ストリームGET | 2MB | 2MB |
| ストリーム受信 | PUSH | PULL |
| プロトコル | AMQP, HTTPS | TCP,HTTPS |
| 開発ツール | EventProcessorHostクラス | Kinesis Client Library |
共通の特徴
-
クライアントから投入されたeventデータは、ストリーム内で複数のパーティションを設定でき、１パーティションに対して１つのConsumerが処理を行うことで並列処理が可能。
-
パーティション同士でのeventデータの処理順序は保障されない。
-
必ず、同じプロセッサーに処理させたい。投入されたeventデータごとの処理順序を保障したい場合は、パーティションキーを利用してパーティションを指定し投入する。
-
eventデータは最大7日間分が保持される。シーケンスナンバーを指定することで特定のメッセージを取得することができる。逆に保持されたeventデータを即時消すことはできない。
EventHubsの利点
- Amazon Kinesisと比べてEventHubsの良いなと思った点。
-
AMQPプロトコルなので、デバイスから直接AMQPプロトコルでEventHubsにデータを投入することができる。Kinesisの場合は、SDKをデバイスに組み込んだり、Brokerを組み込むなどしないといけない。
-
SQLクエリによる集計(Stream Analytics)が利用できる。(まだ、AWSはサービスが一般に公開されていない)
-
所感
-
Stream AnalyticsのSQLを少し触ってみて
- 複数EventHubsからメッセージの統合、整形、分離が便利そうだと感じた。
- ストリームに格納されているデータを削除できない。
- データの遅延などを図るためにある程度の負荷をかけたあと、データを削除する手段がないので開発時面倒だった・・・。
-
ストリーム内のパーティションのスプリットが大変。
- 自動でスケールする仕組みがないので手で実装する必要がある。