Storm0.8.2公開、運用や問題解析時の便利機能が追加されました！

こんにちは。kimukimuです。

先日、Stormの最新版、0.8.2の正式版リリースが公開されました。
http://storm-project.net/2013/01/11/storm082-released.html

前回のStorm0.8.1が開発を行いやすくする機能が追加されていましたが、
今回はStormUIが主に機能追加対象となり、運用や問題解析を行いやすくする機能がそろっています。

では、追加された主な機能について挙げてみますね。

1.Topologyごとにホストマシンを占有させるIsolation Schedulerの追加

Stormクラスタ上で複数のTopologyを動作させる際、
特定のTopologyに対してホストを占有させる設定が可能となりました。

これによって、商用のTopologyは常時3個のホストを占有し、
検証用のTopologyとは混ざらないようにする。。。といったことが出来ます。

実際にStormクラスタを複数用意するのは大変ですので、
１クラスタ上で検証と運用をうまくバランスさせるには便利そうですね。

2.StormUIの改善

StormUIに下記のように操作ボタン、情報が追加され非常に使いやすく改善されました。
−activate、diactivate、kill、rebalanceといったTopologyへの操作ボタン追加
−Boltの現状のキャパシティ目安（イベント処理可能数）表示
−Ack待ちのTuple数を表示
−ClusterやTopologyの設定値を表示

実際まず見る情報はStormUIのため、UIから操作が可能になったというのは非常にうれしいですね！

3.StormUIがNimbusと同ホストでなくても配置でき、複数設置可能になった

StormUIがNimbusと別ホストに配置可能になりました。

Storm0.8.1まではStormUIは問答無用でlocalhostにアクセスして情報を取得していたため、
Nimbusと同じホストにしか配置できませんでした。

Storm0.8.2では別ホストに配置可能となったため、柔軟に対応できることに加え、
StormUIを複数のホストに配置することも可能になりました。
画面だけいろんなところで見たい、ということにも対応できるようになったわけですね。

4.StormUIに表示されるエラーの数を絞ることが可能になった

「7.Workerを殺さずに〜」にも関連するのですが、
StormUIはStorm動作中に発生したエラーを表示する機能を持っています。

Storm0.8.1まではエラー表示件数は発生しただけ表示されていました。
そのため、エラーが大量に発生すると画面から溢れてしまうことが多々ありました。

Storm0.8.2では画面に表示するエラーの数を時間や回数で区切ることが可能となったため、
無駄な情報を省くことが可能になりました。

5.StormにTopologyをSubmit時、バリデーションが可能になった

StormにTopologyをSubmitする際にバリデーションが可能になりました。

Storm0.8.1まではTopologyをSubmitするときには自前でバリデーション処理を作りこみ、
自前のコードの中ではじく必要がありましたが、それをStorm側が提供した枠組みの中で可能になった・・・
というわけですね。

6.Workerを殺さずにStormUIにエラーを表示するReportedFailedExceptionの追加

これは思いっきり開発より＆内部の話になってしまいますが・・・
StormUIにはTopology内部で発生した例外を補足して表示する機能がありますが、
表示される例外は「Spout/Boltを停止させるレベルの例外」のみでした。

StormではSpout/Boltが停止するとそのWorkerプロセスも併せて停止するため、
StormUIに例外が表示された時点でプロセスがフェールオーバーして
クラスタ内を飛び回っている状態になります。
結果、問題を追うのが大変・・・というのが多々ありました。

ReportedFailedExceptionは「StormUIには表示されるが、Spout/Boltの動作は継続する」例外です。
そのため、実際にクラスタ上で動かす場合にエラーのレベルを定義できるようなノリですね。

ユーザに知らせたいけどそのまま動作を継続したい場合はReportedFailedExceptionを投げ、
どうしようもない場合は今までどおりの例外を投げてプロセスごと再起動・・・が選択可能になりました。

言うなれば、WARNとERRORの切り分けができるようになった感じでしょうか。

7.総括して、何がうれしくなったの？

全体的に見て、実際に動かしてみて困る内容への対処がそろっています。
また、Topologyのバリデーションなどで事前に問題を検知できるようになったのもうれしいですね。

もしStormを使おうか考えている方がいれば、今回を機にぜひ使ってみてください。

それでは。

SmartSantanderの紹介

Hola!(「オラ!」と読みます。一日中使えるスペイン語の挨拶です)
束野です。

みなさんは「スマートシティ」って聞いたことがありますか？
簡単に言うと、ICTを使ってインフラを有効利用できるようにすることで、利便性を向上させたり、エネルギー利用を効率化させる取り組みです。日本を含め、世界中で実証実験が行われています。
サンタンデールの町でも、地元カンタブリア大学等が中心となって「SmartSantander」というスマートシティプロジェクトが行われています。今日はカンタブリア大学のLuiz Munos先生から説明してもらった、この「SmartSantander」について紹介します。

写真の真ん中の人がLuiz Munos先生で、このプロジェクトを進めている方です。

SmartSantanderはスペイン初のスマートシティプロジェクトで、「Future Internet Award」という賞も貰っているようです。

SmartSantanderはiPhoneやAndroidのアプリとして提供されており、無料で誰でも使えます。
ただ、サンタンデールで使わないと面白くない点が要注意です。
私はiPhone版を使ってみました。ちなみに同じ携帯電話を世界中で使えるのは、標準化のお陰ですね。

アプリを起動すると、こういう画面が表示されます。アプリの中身はスペイン語ですが、言いたいことは分かる気がします。
下のメニューから「TRANSPORTE」を選択すると、次の画面が出てきます。

いわゆるARの世界ですね。
スマホを向けた方向あるバス停の情報が画面に表示されます。
バス停のアイコンをタップすると、詳細な情報が表示されます。

このバス停までは374mの距離だと書いてありますね。

さて、こういうシステムを実現するために、どんな仕掛けをしているのでしょうか。

例えば、サンタンデールの街灯をよく見ると、支柱にアンテナ付きの機械が取り付けられています。
これはセンサで、明るさ・気温・騒音等の情報を集めています。

センサは単に情報を集めるだけではなく、ネットワークを構成する機器の一つにもなっています。
町中の至る所にセンサがあり、各センサは「リピータ」というネットワーク機器と同じ役割を担っています。
センサ同士が通信して、町全体でネットワークを構成しているんですね。

ある程度数のセンサの集まりには親玉がいて、cluster headと呼ばれています。
センサとはちょっと違う形のネットワーク機器です。

ここから地下に張られた光回線にセンサから収集した情報を渡し、サーバ側でセンサ情報を処理しています。

これが実物のセンサとcluster headです。

間近で見ると、結構大きいですね。また、センサから情報をGoogle Mapと関連付けて、PCに表示していますね。

バス停の位置が分かる他にも、天候や駐車場の空き具合等も分かるそうです。
サンタンデールに来てから、移動にタクシーを使うことが多いので、「このアプリでタクシーを呼べるようして欲しい」と言ったところ「in plan」だそうです。
サンタンデールは観光地なので、このプロジェクトを通して、観光客の利便性が上がったり、また来たくなったりすると、良いですね。

これはおまけ。
白い建物はサンタンデールにあるカジノです。スペインにはカジノがあるんですね。

ちなみに、左下に併設されている赤い扉の所は銀行です。
カジノに銀行が併設されているんですね。日本だと馬券売り場の隣に銀行があるイメージでしょうか。
いや〜商売上手だと感じました。

次回は、スペインの街や、いろいろトラブルがあった交通関係について、ご紹介します。
それではまた〜