今年最後の記事は、Microsoft AzureのEvent Hubsです。
Event Hubsって何か？？って言われたときに、
まだ自分は、すっきり答えられないです。
自分の中では、異なるアプリ間でのデータ送受信を行うインターフェースの一つで、
今までは、ファイルやデータベースが担っていたデータプールと同じようなイメージです。
ただ、DBやファイルと比べてEvent Hubsの特徴は、下記のようなところだと思います。
・データの保持期間が永続的ではなく、一時的なもの
・クラウド上のマネージドサービスであり、99.9%以上の可用性がSLAで保証されている
・数百万件/秒に耐えうる送受信を提供しているサービス
(参考)
■Service Busの概要
http://azure.microsoft.com/ja-jp/services/service-bus/
■Microsoft AzureのSLA
http://azure.microsoft.com/ja-jp/support/legal/sla/
秒間に数百万件もやり取りすることないしーって方もいると思いますが、
別に費用が合えば、数件でもいいと思います。
なんせ、アプリ間のメッセージ交換という、一番ダウンさせたくないサービスを、
クラウド上で可用性を担保できるわけですから、オンプレミスで運用した場合の
コスト＋運用にかかわる人件費を勘案してどちらが望ましいか選択した方がいいと思います。
■Event Hubsの料金
http://azure.microsoft.com/ja-jp/pricing/details/event-hubs/
前置きが長くなってしまいましたが、サンプルアプリを作ってみましたので、紹介したいと思います。
今回作成するアプリは、送信側はフォームアプリで、受信側はコンソールアプリです。
(って、めっちゃレトロな感じっすよね。。)
別に、WPFでもWebアプリでも全然OKなのですが、なんとなく昔からある技術でも使えちゃうんだよ感を出したくてフォームアプリとコンソールアプリにしちゃいました。
ざっくりとした手順は下記の通りです。
あと、今回のアプリの作成にあたっては、下記のサイトを参考にさせて頂きました。
(受信側アプリは、ほとんどそのままソースをコピーさせて頂いちゃいました)
http://okazuki.hatenablog.com/entry/2014/12/03/222424
１．Azure管理ポータルより、Event Hubsを作成
２．送信側アプリの作成
３．受信側アプリの作成
ちなみに、開発環境はVisual Studio 2013 update4です。
１．Azure 管理ポータルより、Event Hubsの作成
(1).Service Bus 名前空間の作成
Service Busの名前空間を作成します。
ここにEvent Hubsを追加していくような構成となります。
一つも作成してない場合は、ポータルのメニューより、「SERVICE BUS」を選択すると下記の画面となります。
Event Hubsを作成する際は、種類を「メッセージング」を選択します。
(2).Event Hubsの追加
管理ポータルより、新規作成します。
今回は、簡易作成にしました。
作成後は、アクセス権を設定します。
今回は、送信と受信のアクセス権をもつロールを、「message」と命名しました。
作成後は、アプリで使うために接続情報を確認します。
下記のような形で接続文字列を取得できます。
キー情報なども入ってますので、取扱いには注意が必要です。
２．送信側アプリの作成
ひとまず、フォームアプリでプロジェクトを作成します。
Event Hubsを使うのに、フォームアプリである必要はないですけどね。
NuGetより、Microsoft Azure Service Busをインストールします。
フォームのデザインは、こんな感じにしました。
メッセージが飛ばせればいいので。
ソースはこんな感じです。
送信ボタンをクリックしたら、Event Hubsに、実行時間とその上のテキストボックスの内容をそのまま送るだけのアプリです。
using Microsoft.ServiceBus.Messaging;
using System;
using System.Text;
using System.Windows.Forms;
namespace EventHubDemo01Send
{
public partial class Form1 : Form
{
private EventHubClient client;
public Form1()
{
InitializeComponent();
client = EventHubClient.CreateFromConnectionString(
"[Event Hubsの接続情報]","y0eventhubdemo01");
}
private void btnSend_Click(object sender, EventArgs e)
{
var strMsg = DateTime.UtcNow.AddHours(9).ToString(
"yyyy-MM-dd HH:mm:ss") + "：" + txtMessage.Text;
var data = new EventData(Encoding.UTF8.GetBytes(strMsg));
client.Send(data);
}
}
}
３．受信側アプリの作成
受信側のアプリは、下記ですが参考にしたサイトのをほとんどそのままです。
プロジェクトは、コンソールアプリで、NugetからMicrosoft Azure Service Busをインストールします。
ソースはこんな感じで、フォームアプリから送信されたメッセージを、残っている分を受信してコンソールに表示する感じです。
using Microsoft.ServiceBus.Messaging;
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading.Tasks;
namespace AzureServiceBusDemo02
{
class Program
{
static void Main(string[] args)
{
var client = EventHubClient.CreateFromConnectionString("
[Event Hubsの接続情報]","y0eventhubdemo01");
var g = client.GetDefaultConsumerGroup();
foreach (var p in client.GetRuntimeInformation().PartitionIds)
{
g.RegisterProcessor<MyEventProcessor>(
new Lease { PartitionId = p }, new MyCheckpointManager());
}
}
}
class MyCheckpointManager : ICheckpointManager
{
public Task CheckpointAsync(Lease lease, string offset, long sequenceNumber)
{
throw new NotImplementedException();
}
}
class MyEventProcessor : IEventProcessor
{
public Task CloseAsync(PartitionContext context, CloseReason reason)
{
return Task.FromResult(0);
}
public Task OpenAsync(PartitionContext context)
{
return Task.FromResult(0);
}
public Task ProcessEventsAsync(PartitionContext context,
IEnumerable<EventData> messages)
{
foreach (var message in messages)
{
var data = Encoding.UTF8.GetString(message.GetBytes());
Console.WriteLine(data);
}
return Task.FromResult(0);
}
}
}
４．実行結果
実行結果は、見てもつまらないのですが、フォームアプリで入力した結果が、
コンソールアプリに表示されました。
５．まとめ
今回みたいに、入力するアプリと出力するアプリが異なるようなケースで、
入力の順序性を気にしなくてOKで、かつ、送信元となるアプリが多くのデバイスに展開されるようなケースでは、Event Hubsはとても便利で簡単にアプリが作れるので面白いと思います。
IoTなどのセンサーアプリは、展開した場合の数がとても多くなるので、そんな時の効果は大きいと思います。
スマホアプリでデータを飛ばしてくるようなパターンにも適用しやすいような気もしますし、定期的に位置情報をドンドン送ってくるようなアプリも面白いですよねー。
また、ロールの与え方で、送信のみの権限だったり、受信だけの権限だったりという構成で送信側だけを公開しちゃうとかもありなのかもしれないです。
オンプレミスでシステムを構成する場合、データ量を減らすことを考えたり、24時間365日のサービス展開のためにデータを送受信する部分を複雑に冗長構成を組んだりとあった部分が、クラウドならでは解決ができるところが、また面白いと思っています。
この辺を理解していくと、アプリケーションの設計の仕方自体も変わっていくのかなーって感じます。
もちろん、インターフェースの部分をこれまで通りDBでやっていくことも全然ありですので、その辺は使い分けが大切っすね。