Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

JavaOne 2015発表してきました!

Hello Japan,
サンフランシスコで西海岸の風を感じている @ デス!
別に横浜と大して変わんないですけどね、ハハッ!

さて、今年もやってきました、世界最大規模のJavaイベント、JavaOne
もう何度目かの参加か分からなくなってきましたが、おととしに続き、今年もBoFセッションで登壇できることになりました。
しかも今年はJava 20周年、そんな節目となる記念の年に登壇できるというのは、ありがたいことですね。

ただ、
渡航前にひいた風邪のせいで、熱が出るわ、咳が出るわ、寝られないわで、
なかなか発表準備もままならない感じでしたが *1 なんとか無事に発表を終えてきました。
発表には反省が残る部分もありましたが、笑いあり、スベりあり、スベりありで、日本と変わらぬ楽しい発表ができました。

すでに感想をブログに書いてくださった方もいらっしゃるので、ピックアップしておきますね。

JavaOne 2015 3 日目 - Java 言語の設計者たちはチェック例外をどう考えているのか - Appresso Engineer Blog
http://appresso.hatenablog.com/entry/2015/10/28/184815

JavaOne2015 3日目メモ (10/27) - 見習いプログラミング日記
http://n-agetsuma.hatenablog.com/entry/2015/10/28/152424


ところで、
今年のJavaOneはキーノートでもこれと言った目玉となる大きな発表はなかったのですが、
各セッションを見ていると、来年リリース予定のJava9の話題が聞こえてきたり、
また今年はMicroservicesや、DevOps、Elasticsearchなどを用いたログ収集など、
話題のバズワードに乗ったセッションが多い印象ですね。

セッションレポートについては、また改めて書きたいと思います。
また11月14日(土)には、日本Javaユーザグループ(JJUG)主催のJavaOne報告会も予定されています。
今年のJavaOneでのトレンドや、雰囲気、各セッションのフィードバックなどを聞きたい方は、ぜひ参加してください。
https://jjug.doorkeeper.jp/events/33374

東京以外でも、大阪での開催なども検討していますので、情報公開をお待ちください。

それでは!
See you!!

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ

*1:風邪は全く関係ないという説も。

ENdoSnipe Ver6.0 リリース

f:id:acro-engineer:20150218031813p:plain

こんにちは、fujiiです。

先日、EaaS(ENdoSnipe as a Service)のプレスリリースを行いましたが、
発表に合わせて、
ENdoSnipeをバージョンアップし、Ver6.0をリリースしました!


そこで今回はENdoSnipe Ver6.0の変更点を簡単に紹介したいと思います。
おっと、その前に「ENdoSnipeって何?」という方は、ぜひ 技術評論社さんのサイトの連載 を読んでみてください!


今回のバージョンアップでは、監視機能の強化をメインに行いました。

Java 8 対応

ENdoSnipe Ver6.0では、動作保証環境にJava SE 8を追加しました。
Java SE 8上で動作するアプリケーションにENdoSnipeを適用する場合には、Ver6.0を利用してください。

プロファイラ機能の追加

ENdoSnipeで計測したプロファイリング情報を、Dashboardで参照できるようになりました。
これでどのメソッドボトルネックになっているのか、見つけやすくなります。

f:id:acro-engineer:20151006001849p:plain

オンラインでの設定変更機能の追加

ENdoSnipeの設定を、ブラウザから変更できるようになりました。

f:id:acro-engineer:20151006001850p:plain

メール通知機能の追加

Ver5.2 でシグナル機能を追加しましたが、
Ver6.0では、閾値を超えた場合や回復した場合に、画面表示だけでなくメール通知もできるようになりました。


今回紹介した機能の他に、ENdoSnipe Ver6.0では、デザインの変更、通信のSSL/TLS化対応なども行いました。

追加した機能の詳細については、次回紹介しますね。

ENdoSnipeここからダウンロードできますので、是非感想等をお知らせください。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ

Amazon ECS 関連のエンジニアの方々と!

こんにちは。@takanorig です。

本日、Amazon Elasticsearch Service(略して Amazon ES) がローンチされましたね。

フルマネージドサービスということで、サーバを用意することなく、Elasticsearch+Kibanaが利用できるのは利便性が高そうです!

ただ、EC2(Elastic Compute Cloud)、ECS(EC2 Container Service)、ES(Elasticsearch Service)と、だんだんと、'E' 始まりのサービス名で混同しそうです。


さて、今回の内容は、その混同しそうな、ECS(EC2 Container Service) に関する話です。

f:id:acro-engineer:20151002124947p:plain

ECSは、Dockerをベースとした、コンテナ管理サービスです。
EC2インスタンスをリソースとして、複数のサービスやアプリケーションをクラスタ全体でコントロールできます。


当社のIoTアプリケーションプラットフォームである「Torrentio」でECSを利用しているのがキッカケで、先日、来日していた AWS ECS 関連の米マネージャ、および、日本アーキテクトの方々と、意見交換をさせて頂きました!


中心の御三方、左から(敬称略)、
 Andrew Thomas (Senior Product Manager)
 Jafar Shameem (Business Development Manager)
 岩永 亮介(ソリューションアーキテクト)



詳細はお話できないのですが、ECSの活用方法などについてディスカッションさせて頂き、今後の展開も楽しみな状況です。
このような貴重な場を設けて頂けたことに大変感謝致します!

当社としてもECSのメリットを活かして、Torrentioのサービスを拡大していきたいと思います。

・Torrentioについて

www.youtube.com

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ

"Reactive Streams" の実装はどうなっているの?

こんにちは。@です。
夏の日差しが日に日に増し、セミも盛んに鳴きはじめましたが、皆さん夏バテなどされていませんか?

さて、今回の内容は、非同期ストリーム処理界隈で注目の「Reactive Streams」です。

先月のJJUGナイトセミナーでも取り上げられており、私は残念ながら参加はできなかったのですが
後から資料を読んで勉強させていただきました。jjug.doorkeeper.jp

1. Reactive Streamsとは何か?

Reactive Streamsとは、JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準」で、
様々な非同期ストリーム処理のインタフェースを共通化して標準的に扱えるようにしようというものです。

分散環境での非同期ストリーム処理においては、
「上流のコンポーネント群の方が処理能力が高く、下流のコンポーネント群が処理しきれずに溢れる」というのは
既存の非同期ストリーム処理でかなり頻発する事象でした。
こうなるとネットワーク/システム全体に影響して、システム停止に繋がってしまいます。
私もStormを触っている中で、この問題にかなり悩まされました。


このような中でReactive Streamsが注目され、標準化につながったのだと思います。

なお、Reactive Streamsについては下記の解説記事がとても詳しいです。

okapies.hateblo.jp

okapies.hateblo.jp

takezoe.hatenablog.com

さて今回は、実際にReactive Streamsを実現しているプロダクトを動かしてみたいと思います。

2. 実際にReactive Streamsを実現しているプロダクトは?

実際にReactive Streamsを実現している代表的なプロダクトには下記があります。

というわけで? これらを実際に動かしてみましょう。
今回はAkka Streamsを用いて、RabbitMQをバックエンドとするScalaConsultants/reactive-rabbit · GitHubを用いて試してみます。

3. まずは動かしてみると・・?

というわけで、RabbitMQをローカルマシンにインストールし、reactive-rabbitを動かしてみたのですが、
RabbitMQに対しては何のメッセージの送受信も行われず、以下のコードで「invoices」というキューを作成して
メッセージを投入してみたのですが、やはり何もおきませんでした・・・

import akka.actor.ActorSystem
import akka.stream.ActorMaterializer
import akka.stream.scaladsl.{Sink, Source}
import io.scalac.amqp.Connection


// streaming invoices to Accounting Department
val connection = Connection()
val queue = connection.consume(queue = "invoices")
val exchange = connection.publish(exchange = "accounting_department",
  routingKey = "invoices")

implicit val system = ActorSystem()
implicit val mat = ActorMaterializer()

Source(queue).map(_.message).to(Sink(exchange)).run()

中身を追っていきたい気持ちもありますが、
今回の記事の目的はまず動かすことなので、まずは動かすことを優先します(^^;

4. reactive-rabbitを利用するプロダクトを探してみる

というわけで、更に「reactive-rabbit」を使っているプロダクトを探してみました。
そうすると、Akka-Streamでreactive-rabbitを使っているサンプルがあったため、そちらを見てみました。
Processing RabbitMQ messages using Akka Streams - Typesafe Activator | @typesafe | Typesafe

ただ、こちらはこちらでReactive Streams 0.4.0準拠で、
APIが更新されたReactive Streams 1.0.0では動作しないという状況!

あちこち探してみたのですが、良いサンプルが見つからなかったため、
rabbitmq-akka-streamをReactive Streams 1.0.0準拠するバージョンに更新してみました。

ソースは下記になります。
kimutansk/reactive-streams-example · GitHub

で、実行してみると下記の結果になりました。

[DEBUG] [07/14/2015 05:07:00.259] [main] [EventStream(akka://rabbit-akka-stream)] logger log1-Logging$DefaultLogger started
[DEBUG] [07/14/2015 05:07:00.261] [main] [EventStream(akka://rabbit-akka-stream)] Default Loggers started
05:07:00.686 [rabbit-akka-stream-akka.actor.default-dispatcher-5] INFO  c.g.kimutansk.reactive.ConsumerApp$ - Exchanges, queues and bindings declared successfully.
05:07:00.833 [rabbit-akka-stream-akka.actor.default-dispatcher-5] INFO  c.g.kimutansk.reactive.ConsumerApp$ - Starting the flow
05:07:00.945 [rabbit-akka-stream-akka.actor.default-dispatcher-5] INFO  c.g.kimutansk.reactive.ConsumerApp$ - Starting the trial run
05:07:01.018 [rabbit-akka-stream-akka.actor.default-dispatcher-5] DEBUG c.g.k.reactive.DomainService$ - message: 'message 1'  will be held for 2558 ms
05:07:03.580 [rabbit-akka-stream-akka.actor.default-dispatcher-4] DEBUG c.g.k.reactive.DomainService$ - message: 'message 2'  will be held for 1873 ms
05:07:03.585 [rabbit-akka-stream-akka.actor.default-dispatcher-3] DEBUG c.g.k.reactive.DomainService$ - message classified as 'safe'
05:07:03.599 [rabbit-akka-stream-akka.actor.default-dispatcher-7] INFO  c.g.kimutansk.reactive.ConsumerApp$ - 'message 1 [message processed]' delivered to censorship.ok.queue
05:07:05.454 [rabbit-akka-stream-akka.actor.default-dispatcher-6] DEBUG c.g.k.reactive.DomainService$ - message classified as 'safe'
05:07:05.454 [rabbit-akka-stream-akka.actor.default-dispatcher-4] DEBUG c.g.k.reactive.DomainService$ - message: 'message 3'  will be held for 1915 ms
05:07:05.458 [rabbit-akka-stream-akka.actor.default-dispatcher-7] INFO  c.g.kimutansk.reactive.ConsumerApp$ - 'message 2 [message processed]' delivered to censorship.ok.queue
05:07:07.371 [rabbit-akka-stream-akka.actor.default-dispatcher-4] DEBUG c.g.k.reactive.DomainService$ - message classified as 'safe'
05:07:07.372 [rabbit-akka-stream-akka.actor.default-dispatcher-6] DEBUG c.g.k.reactive.DomainService$ - message: 'message 4'  will be held for 1364 ms
05:07:07.374 [rabbit-akka-stream-akka.actor.default-dispatcher-9] INFO  c.g.kimutansk.reactive.ConsumerApp$ - 'message 3 [message processed]' delivered to censorship.ok.queue
05:07:08.737 [rabbit-akka-stream-akka.actor.default-dispatcher-6] DEBUG c.g.k.reactive.DomainService$ - message: 'message 5'  will be held for 1125 ms
05:07:08.737 [rabbit-akka-stream-akka.actor.default-dispatcher-9] DEBUG c.g.k.reactive.DomainService$ - message classified as 'safe'
05:07:08.740 [rabbit-akka-stream-akka.actor.default-dispatcher-9] INFO  c.g.kimutansk.reactive.ConsumerApp$ - 'message 4 [message processed]' delivered to censorship.ok.queue
05:07:09.862 [rabbit-akka-stream-akka.actor.default-dispatcher-6] DEBUG c.g.k.reactive.DomainService$ - message classified as 'safe'
05:07:09.865 [rabbit-akka-stream-akka.actor.default-dispatcher-5] INFO  c.g.kimutansk.reactive.ConsumerApp$ - 'message 5 [message processed]' delivered to censorship.ok.queue
05:07:09.865 [rabbit-akka-stream-akka.actor.default-dispatcher-5] INFO  c.g.kimutansk.reactive.ConsumerApp$ - Trial run finished. You can now go to http://localhost:15672/ and try publishing messages manually.

どうやら、RabbitMQに対してメッセージの投入と取得、処理が行われたようです。
実際にRabbitMQの管理画面からもメッセージが送受信された旨が表示され、キューが作られていることがわかります。

f:id:acro-engineer:20150623064313j:plain
f:id:acro-engineer:20150623064515j:plain

また、RabbitMQの「censorship.inbound.queue」というキューにメッセージを投入してみると、
下記のように処理した旨のメッセージも表示されました。

05:07:53.525 [rabbit-akka-stream-akka.actor.default-dispatcher-7] DEBUG c.g.k.reactive.DomainService$ - message: 'Test Input Manual Message'  will be held for 1380 ms
05:07:54.906 [rabbit-akka-stream-akka.actor.default-dispatcher-10] DEBUG c.g.k.reactive.DomainService$ - message classified as 'safe'

というわけで、とりあえずサンプルを動かしてみることは出来ました。
ですが、これだけだと中身でどんな事が行われているかは分かりませんし、
バックプレッシャーを体感することもできません。

なので、次回以降は実際に中身を追っていこうと思います。

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ

MQTT Broker比較~性能比較編

こんにちは、ツカノ(@)です。

MQTT Broker 比較の第二弾です。

前回は、機能の比較を行いました。


実際のシステムへの適応を考えると、性能は特に気になるところ。
ということで、今回は性能比較を行ってみました。
ベンチマークは環境や測定方法、バージョンによっても大きく異なりますので、
あくまで一例として参考にしてもらえればと思います。

f:id:acro-engineer:20150618200645p:plain

ベンチマークに利用したプログラムは、Goで開発された以下の MQTT-Bench を利用しています。


ベンチマークの条件は以下の通りです。

  • 構成、メッセージ長
    • MQTT Broker に対して、500connections で同時処理
    • 1つのメッセージ長は 1024byte
  • マシンスペック
    • OS: CentOS 6.5 (64bit)
    • CPU: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (4コア HT有効)
    • メモリ: 32GB
    • NIC: 1Gbps
  • MQTT Broker のバージョン
    • Mosquitto(1.4.2)
    • Apollo(1.7.1)
    • RabbitMQ(3.5.3)
    • Mosca(0.29.0)
    • eMQTTD(0.8.6-beta) クラスタに対応しているが、1プロセスで処理
    • VerneMQ(0.9.4) クラスタに対応しているが、1プロセスで処理

計測内容

計測は、以下のパターンで行っています。

  1. Publish(Retainなし)
    • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainなしの場合は、最後にPublishされたメッセージをBrokerが保持しません。
  2. Publish(Retainあり)
    • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainありの場合は、最後にPublishされたメッセージをBrokerが保持します。
  3. Subscribe
    • MQTT Broker から、クライアントがメッセージを受信する処理になります。MQTTの特性として、接続されているときのみメッセージを受信するため、Subscribeしている間、それとは別プロセスでPublish(Retainなし)の処理を行っています。

計測結果は、以下のグラフになりますが、グラフの縦軸は、「処理したメッセージ数/秒」です。
また、機能的に対応していない箇所はグラフを記載していません。

※RabbitMQ のQoS=1の場合のSubscribeの処理は、Publishされたメッセージが内部のキューを介するようで、今回のSubscribeの計測方法では、性能があまり出なかったため、計測結果からは除いています。

Publish性能(retain=false)

f:id:acro-engineer:20150626061010p:plain

Publish性能(retain=true)

f:id:acro-engineer:20150626061220p:plain

Subscribe性能

f:id:acro-engineer:20150626061250p:plain

結果

  • 全体として、Mosquitto/Apollo/VerneMQの性能が良いです。
  • 以前は、Mosquittoの性能はいまひとつ、という話がありましが、現在のバージョンでは、他と比べてもトップレベルの性能になっているようです。
  • VerneMQ は、Retainありの場合は性能が低くなる傾向がありますが、1プロセスでもトップレベルの性能になっています。クラスタ構成を組むことで、分散して処理することができるため、さらに性能を向上できる可能性があります(クラスタ構成での性能は、今回未計測です)。


さて、2回に分けて、MQTT Brokerの機能比較と性能比較を行ってきましたが、
この1~2ヶ月の間にも、MQTT Brokerがバージョンアップされて機能や性能が改善したり、
VerneMQのような新しいプロダクトがリリースされたりと、動きが大きい分野だと感じています。


これからも、IoTとともにMQTT Brokerは要注目、ですね!

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ

MQTT Broker比較~機能比較編

こんにちは、ツカノ(@)です。

このところ IoT(Internet of Things)関連のニュースを目にすることが増えました。
最近であればPepper君の一般販売などが大きなニュースでしたが、
システムの足回りが大好きな自分としては、IoTと言えば、そう、MQTTですね!(強引!)
f:id:acro-engineer:20150618200645p:plain

Googleトレンドで調べてみたら、こんな感じでした。ここ1-2年で急速に伸びていますね。
f:id:acro-engineer:20150619070315p:plain

MQTTは、Message Queue Telemetry Transport の略ですが、Pub/Sub型モデルのメッセージキュー"プロトコル"であり、MQ(Message Queue)と言いつつ、メッセージを蓄積はしないんですよね。よく勘違いされる点なので、注意が必要です。

MQTTの詳しい説明は、以下のサイトが参考になります。


さて、そんなMQTTですが、メッセージをやり取りするには、仲介役となる MQTT Broker が必要になります。
OSSの MQTT Broker も多く登場してきているのですが、それぞれ実装されている仕様も異なっているため、利用時には注意が必要です。

そこで、自分としてもどのような差分があるのか知りたくなり、代表的なOSSの MQTT Broker について調査してみました。

MQTTの参照実装と言われる Mosquitto をはじめとして、利用されるケースが多い、Apollo、RabbitMQ、eMQTTD、Mosca について機能比較を行いました。


その結果が以下の表です(○:対応あり、×:対応なし)。

Broker(version) 開発言語 対応しているMQTT version QoSレベル Retain Will WebSocket UI 冗長化
Mosquitto(1.4.2) C MQTT 3.1/3.1.1 0,1,2 × ×
Apollo(1.7.1) Java MQTT 3.1 0,1,2 ×
RabbitMQ(3.5.3) Erlang MQTT 3.1 0,1 × ×
Mosca(0.29.0) Node.js MQTT 3.1 0,1 × × ×
eMQTTD(0.8.6-beta) Erlang MQTT 3.1/3.1.1 0,1,2 ×
VerneMQ(0.9.4) Erlang MQTT 3.1/3.1.1 0,1,2 ×

Brokerのversionは調査時のものです。


以下、今回比較した観点について、簡単に説明します。

  • MQTT 3.1と3.1.1の違いは以下に解説されています。3.1.1では、曖昧な点の仕様を明確にしたり、Client IDのサイズ拡張等が行われています。
  • QoS(Quality of Service)はメッセージ配信に関する品質保証のレベルで、以下の3段階存在します。
    • QoS 0: At most once - 最高1回配信します。(1回も配信されない可能性があります)
    • QoS 1: At least once - 少なくとも一回配信します。(2回以上配信される可能性があります)
    • QoS 2: Exactly once - 正確に一回配信します。
  • Retainに対応していると、トピックにSubscribeしたときに、最新のメッセージが配信されます。
  • Willは「Last Will and Testament」のことで、Publisherが切断した際に予め決めておいたメッセージを、Subscriberに配信する流す仕組みがあります。
  • WebSocketは、MQTTのメッセージをWebSocketのプロトコルを使って配信できるかどうかです。
  • UIは、Brokerの管理画面などがUIで提供されているかどうか表します。Webブラウザを使って管理できると便利ですよね。


各Brokerに対して寸評を書くと。。。

  • Mosquitto
    • 冗長化が無いものの(MQTTの仕様上は、冗長化は必要ありません)、参照実装だけあって、QoSやretain等の仕様は全て対応されています。
  • Apollo
    • 機能的には良いのですが、動作をさせてみたところ、MQTTのメッセージのヘッダが標準と多少異なるようで、MQTTクライアントのAPIの種類によっては、Subscribeできないケースがありました。
  • RabbitMQ
    • 以前から普通のMQとして利用することも多かったので、期待していたのですが、未だに、QoS=2に対応していなかったり、retainに対応していなかったり(開発は進んでおり、v3.6.0で対応する予定があるようです)する点は、残念な状況です。
  • Mosca
    • MQTTとしての機能は不足している感じがします。ただし、MoscaはStandaloneでもEmbedded(他アプリ内で動作する)でも動作する、という特徴があります。
  • eMQTTD
    • クラスタ構成を組むことができるため、冗長化にも対応しており、機能的には良いですね。現在、バージョンアップも頻繁に行われています。
    • ただ、次回紹介しますが、性能が他Brokerに追いついていないところがあり、そこは今後に期待ですね。
  • VerneMQ
    • 直近の2015年5月に、最初のリリースが行われましたが、MQTTの仕様も網羅されている上に、クラスタ構成にも対応しているため、OSSのMQTT Brokerとしてはかなり有力候補となるプロダクトですね。
    • ドキュメントも充実して分かりやすいです。


また、今回はそのままインストールして利用するのではないため、比較の対象からは外していますが、750,000 Messages/sec を達成したという、Goで実装された SugeMQ (MQTT Broker/Client ライブラリ、という位置づけ)なんかもあったりします。


バージョンが変わると、また状況は変わってくるかもしれませんが、MQTT Broker を利用する際の参考なれば、と思います。
#できれば、商用の MQTT Broker も対象にしたかったのですが、それはまた今度の機会に。

次回はこれらの MQTT Broker に対して、皆さん気になるベンチマークした結果を紹介したいと思います!


2015/06/26 更新
MQTT Brokerの動きも早く、短期間の内にバージョンアップされていたり、新しいBrokerが登場していました。
それらに関してコメントを頂いたため、内容を更新しました。

  • 調査対象のバージョンを、2016/06/26時点で最新のものに更新しました。
  • Will、WebSocket の項目を追加しました。
  • 調査対象にVerneMQを追加しました。

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ

JJUG主催Pepperハッカソンに参加してきました!

Java Developerの皆さん、こんにちは。
ボクの名前は @IPアドレスは192.168.254.254

・・・というPepperのモノマネはさておき、@です。

6月6日にPepperハッカソンに参加してきました!
【東京】JJUG主催Pepperハッカソン ( https://jjug.doorkeeper.jp/events/25442 )

Pepperハッカソンって?

Pepperハッカソンは、あのヒューマノイドロボットPepperを使って、実際にプログラムを組んで動かしてみようというイベントです。
今回のイベントはPepperJava NAOqi SDKで開発できるようになることを記念されて開催されたものです。
Java NAOqi SDK ( http://doc.aldebaran.com/2-1/dev/java/index_java.html )

そう、JavaPepperのプログラミングができる! というわけですね。

自分のプログラムで動かせると考えると、最初は気味悪かったPepper君の顔も心なしか可愛く見えます。
f:id:acro-engineer:20150609070309j:plain

ハッカソンのようす

さて、会場の風景を・・・といっても、当日はひたすらPepper君をハックしていたのみのため、
Pepper君の雄姿ばかりになりますが、紹介させてもらいますね。

Pepper君達
f:id:acro-engineer:20150609070318j:plain
・兄のNAOと並んだPepper
f:id:acro-engineer:20150609070327j:plain

ハッカソンということもあり、皆さん黙々と開発を進めていました。
ただ、Pepper君が動作確認の時にしゃべるので、それがきっかけで笑いが起こることが多いという、謎な雰囲気でした^^;

イベントの最後には、自分たちで作ったプログラムの発表が行われました。





また、このTwitterの中にはないのですが、JJUGの槙さんによる、SpringBootで作ったPepperの管理画面などは、とても興味深かったです。


え、、、私が作ったもの・・・?
私はPepperのロボットとしての機能(センサー、カメラ、ポーズ、移動など)を駆使して
癒し系のマスコットのようなものを作りたかったのですが、
SDKのドキュメントに無い個所を試しながら掘り下げていって時間切れ。

癒しではない、うざいPepper君になってしまいました^^;

PepperJava SDKはどうだったのか?

今回、参加した理由として、ハッカソンとしてものづくりを楽しみたかった一方で、
PepperJava SDKがどれぐらい使えるのかを知りたいという目的もありました。

実際に使ってみたJava SDKですが、正直なところ、やや使いづらい印象でした。

  1. ドキュメント、サンプルが無い。
    • いまのところ「どんな機能があるのか?」について分かるドキュメントがありません。
    • JavaDocはあるのですが、ほとんど自動生成されたJavaDocのみで、パラメータの意味などもわからないものでした。
    • 分からないからってデコンパイルに走る猛者も
    • ドキュメントはこれから充実すると思いますし、利用者によるブログやまとめも増えそうですよね。
  2. 数百ものイベント検知を1つ1つ設定する必要がある。
    • Pepperには数百ものイベント(頭に触られた、人間が近づいた)があるのですが、それを検知するためには1イベントごとに検知するコードを書く必要があります。
    • イベントは「EngagementZone/PersonEngage」のように階層構造になっているので、MQTTのようにTopicにワイルドカード指定をする形でSubscribe出来ると使いやすくなると思います。
  3. コールバックの型がイベントごとに異なり、扱いにくい。
    • 上記のイベント検知のハンドリングにはコールバックを使用するのですが、そのコールバックの引数型がイベントごとに異なるため、共通的なコールバックのクラス階層を作りにくいです。
    • 今はお試しレベルなのでそう大きな問題にならないのですが、大きなアプリケーションを作る場合にはコードの統制がとりにくいAPIでした。

なんかちょっと細かいところまで書いてしまいましたが。
ただ、ハッカソン後のイベントでスタッフの方と話したところ、
現状のJavaAPIはあくまでβ版であり、今回のイベントでのコメントを受けてブラッシュアップしていくという強い意志を感じました。

何より、これまでのJavaの開発資産を用いることで、
外部サービスとの連携等が容易になるということは、非常に大きな進展だと思います。
その証拠に皆さん、とにかくtwitter4jを使っていましたし(笑)

また今回のような機会があれば是非参加して、PepperJavaで何ができるか、考えながら手を動してみたいと思います。

おまけ

・イベントが終了し、お休みのPepper君達
f:id:acro-engineer:20150609070341j:plain

Pepperステッカー
f:id:acro-engineer:20150609070356j:plain

皆さんも、ぜひPepperJava SDK、試してみてください!

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 キャリア採用ページ