Azure Event Hubs の使い方 (環境構築編)

こんにちは。日山(@hiiyan0402)です。
Microsoft Azure のストリーミング処理基盤サービスこと「Event Hubs」の使い方について、何回かに分けて説明したいと思います。今回は管理ポータルにおけるサービスの作成について説明します。

Event Hubs とは?

ストリーミング処理基盤サービスです。
Azure Service Bus の1つの機能として提供されるサービスです。
機能の概要は、ハブに投入したメッセージ(Event Hubs では「イベント」と呼びます)をもう一方から取り出すことができる、といえます。これは Service Bus の Queue や Topic、Azureストレージの Queue と似ています。
しかし、Event Hubsは、同じイベントを同時に何度でも取り出すことができる、という点で異なります。

複数のクライアントで同時にイベントを取り出せる

Service Bus の Queue や、Azureストレージの Queue では、通常、1つのメッセージは、1つのクライアントでしか処理することができません。
これに対して Event Hubs では、1つのイベントを複数のクライアントで同時に受信することができます。そのため、同じデータソースを複数用途で同時に処理することができます。
例えば、サーバのパフォーマンスログを、監視処理、傾向分析処理、永続化処理、などの用途で、複数インスタンスで同時に処理することができます。

複数のクライアントで同時にイベントを取り出せる

同じイベントを何度でも取り出せる

Service Bus の Topic では、Event Hubs と同様に、同じメッセージを複数クライアントで同時に受信することができます。しかしメッセージの受信は1度きりで、過去のメッセージを何度も受信することができません。
これに対して Event Hubs では、メッセージはデータ保有期間内であれば何度でも受信することができます。そして各クライアントが各々のポイントからイベントデータを取得することができます。

同じイベントを何度でも取り出せる

上記の図の例を使って説明をすると、あるクライアントではEvent1→Event2→Event3→以降投入されるイベント(Event4以降)の順で受信でき、あるクライアントではEvent3→Event4→… とも受信することができます。

Event Hubs に接続する際にどこから受信をするか(オフセットといいます)を指定することができます。オフセットを指定しない場合、保管されている最も古いイベントから取得開始となります。なのでオフセットはクライアントサイドで管理する必要があります。管理をしないと、何度も同じイベントを受信することになってしまいます。

各クライアントが各々のペースでイベントを処理することができます。
そして、データ保管期間内であれば、何度でもデータストリームの再現も行うことができます。

Service Busの Queue/Topic や Azureストレージの Queue との違い

Service Busの Queue/Topic や Azureストレージの Queue とはデータの受け渡し、という点では似ていますが、これらは用途が全く異なります。
Queue(Service Bus/ストレージ)は「メッセージング」、Service Bus Topic は「ブロードキャスト」、そして Event Hubs は「ストリーミング処理」です。
なのでメッセージングを目的としているのであれば、Event Hubsではなく、Queueを使ったほうが効率が良いです。もちろん Event Hubs でも Queue のようにメッセージングができますが、処理やコスト的に効率が悪くなります。

Service Busの Queue/Topic や Azureストレージの Queue との違い

利用パターン

Event Hubs はIoTソリューションにおけるデバイスから送られてくるセンサーデータの受け口として使えます。
デバイスから Event Hubs へ AMQP でデータ投入、そのデータをクラウドサービスWorkerRoleで処理、または Stream Analytics で分析&BLOB等への格納、格納されたデータを Machine Learning や Power BI 等での分析、といった利用パターンが考えられます。

利用パターン

もっと詳しく知りたい

以下のMSDNがわかりやすいです。

Event Hubs の概要
https://msdn.microsoft.com/ja-jp/library/azure/dn836025.aspx

イベントハブ を作成する

現行管理ポータルでイベントハブを作成のやり方を説明します。
ここでの説明は2015/02/01時点での管理ポータルで行います。

イベントハブ を作成する1

画面左下の[+新規]ボタンをクリックし、[アプリケーションサービス]-[SERVICE BUS]-[イベントハブ]-[カスタム作成]、と選択します。

イベントハブ を作成する2

イベントハブ名とリージョン、そして所属する Service Bus のを指定します。
Service Bus はイベントハブと同時に作成することもできます。

イベントハブ を作成する3

パーティション数とメッセージ保有期間を指定して、イベントハブを作成します。
現状では、パーティション数は8~32、メッセージ保有期間は1~7日の範囲で指定することができます。

パーティション数はストリーミング処理の規模で決定します。
1つのデータストリーム利用グループにあたる1コンシューマグループにおいては、1パーティションにつき1スレッドでイベントを受信することになります。なので、8パーティションであると、1コンシューマグループにおいては、最大でも8インスタンスでしか処理することができません。
イベントを処理するために多くのインスタンスを要するのであればパーティション数は多いほうがいいです。8インスタンス以下でしか処理をしないのであれば、パーティション数は最低値の8個で十分です。

処理性能はイベントハブ全体で設定されているので、パーティション数が多ければ性能がよくなるというわけではない、という点にご注意ください。
また現状、イベントハブ作成後にパーティション数を変更することができないので、その点もご注意を。
(※これらの説明は後日のブログで行います)

メッセージ保有期間はデータストリームの再現を行う等の用途がなければ、最短の1日で問題ないと思います。

イベントハブ を作成する4

イベントハブが作成されました。

共有アクセスポリシーを作成する

プログラムからイベントハブを利用するためには共有アクセスポリシーを含む接続文字列が必要になります。
管理ポータルでの共有アクセスポリシーの作成方法、および接続文字列の確認方法を説明します。

共有アクセスポリシーの作成

共有アクセスポリシーの作成1

イベントハブ一覧画面で作成したイベントハブをクリックすると、そのイベントハブの管理をするための画面が表示されます。この画面では、以下の操作ができます。

  • メッセージ保有期間の確認/変更
  • パーティション数の確認
  • イベントハブの有効化/無効化
  • 共有アクセスポリシー(SAS)の確認/作成
  • コンシューマグループの作成/削除
  • メトリックの確認 (要求数やエラー数など)

共有アクセスポリシーの作成2

[構成]タブをクリックすると、共有アクセスポリシーの管理を行うことができる画面が表示されます。
アクセスポリシーはイベントハブを利用するために必要なアクセス情報になります。

以下の4種類のアクセスポリシーを作成することができます。

  • 管理用 (管理, 送信, リッスン)
  • 送信用 (送信)
  • 受信用 (リッスン)
  • 送受信用 (送信, リッスン)

「送信」と「リッスン」は名前の通り、それぞれ「イベントの送信」と「イベントの受信」を行うことができます。
「管理」はコンシューマグループの作成等ができます。

ここで作成したアクセスポリシーは、現在表示しているイベントハブでしか適用されません。
アクセスポリシーは Service Bus 自体にも作成することもできます。そのアクセスポリシーは Service Busに属するサービス(QueueやTopic, Event Hubsなど)全体に適用されます。
セキュリティ上の理由から、特定のサービスに対して、最低限の権限を持ったアクセスポリシーを作成することをオススメします。

接続文字列の確認

接続文字列の確認1

イベントハブ画面の画面下にある[接続情報]のボタンをクリックします。

接続文字列の確認2

各アクセスポリシーの接続文字列が表示されます。

まとめ

今回は Azure Event Hubs の説明と、管理ポータルにおける作成方法について説明しました。
次回は作成したイベントハブを使って、イベントの送信&受信を行うプログラムの作成方法について説明します。

今回も最後までご覧いただきありがとうございました!


TechTarget

クラウドエンジニア  日山 雅之による記事「Microsoft Azure スマート解説」がTechTarget Japanにて好評連載中です (全7回)