Taste of Tech Topics

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

Storm0.9.0の新機能(Topology毎のログ出力)を試してみます

こんにちは。kimukimuです。

Storm0.9.0-rc系がリリースされてから正式版が出るのを待っている今日この頃ですが、
Storm0.9.0はApacheプロジェクトに入る前の最終リリースとなるということで、かなり大きなマイルストーンになりそうです。
そのため、検証のためまだ正式版が出るまでにはかかりそうです。

なので、正式版が出る前ですが、Storm0.9.0で追加/変更された機能を順に試してみることにします。
今回は、実際にStormを使っている方にとっては非常にありがたく感じる
「Topology毎のログ出力切り分け」について。

1.StormのTopologyログ出力はわかりにくい?

実際にStormを使ったことがある方だとわかるかと思いますが、StormTopologyのログ出力先はわかりにくいです。
理由は、以下の2点。

  1. どのTopologyがどのログに出力されているか」がファイル名からではわからない
  2. 同じファイルに複数のTopologyのログが混在して出力される

1点目の理由ですが、StormTopologyのログはログ出力先ディレクトリ配下に以下のようにworker-XXXX.logとして出力されます。
名前からではどのTopologyのログが出力されているかはわかりません。

> ls -l
-rw-r--r-- 1 root root     6966 10月 30 07:03 2013 drpc.log
-rw-r--r-- 1 root root    27424 10月 31 08:27 2013 nimbus.log
-rw-r--r-- 1 root root    36220 10月 31 07:43 2013 supervisor.log
-rw-r--r-- 1 root root     3348 10月 31 07:43 2013 ui.log
-rw-r--r-- 1 root root 42834753 10月 31 07:43 2013 worker-6701.log
-rw-r--r-- 1 root root 86293078 10月 31 07:43 2013 worker-6702.log
-rw-r--r-- 1 root root 86295346 10月 31 07:43 2013 worker-6703.log

Storm-UIのコンポーネント詳細画面の以下の部分を見て、どのログがどのTopologyのものかわかる・・・
という形になっています。
f:id:acro-engineer:20131101071248j:plain

2点目の理由ですが、StormではWorkerプロセスのIDは使いまわされます。
そのため、後で起動したTopologyのログが過去に起動したTopologyのログに追記されてしまい、
複数Topologyのログが1ファイル内に存在してしまう・・・という状態になります。

結果、Stormのログは見にくく、問題が発生した際に追うのが困難となってきます。

2.Storm0.9.0でのTopologyログ出力

同じようなことを考えていた方が他にもいたようで、Storm0.9.0からはログ出力先がTopology毎にログの出力先が切り分けられるようになっています。
但し、デフォルトでは有効になっていません。

そのため、実際に設定をして試してみますね。

ログ出力先の切り分け用設定

設定は簡単で、【Stormのインストール先】/logback/cluster.xmlの設定を以下のように修正するだけです。
■cluster.xml(修正前)

<!-- 省略 -->
<file>${storm.home}/logs/${logfile.name}</file>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
  <fileNamePattern>${storm.home}/logs/${logfile.name}.%i</fileNamePattern>
  <minIndex>1</minIndex>
  <maxIndex>9</maxIndex>
</rollingPolicy>
<!-- 省略 -->


■cluster.xml(修正後)

<!-- 省略 -->
<file>${storm.home}/logs/${storm.id:-}${logfile.name}</file> <!-- storm.id追記 -->
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
  <fileNamePattern>${storm.home}/logs/${storm.id:-}${logfile.name}.%i</fileNamePattern> <!-- storm.id追記 -->
  <minIndex>1</minIndex>
  <maxIndex>9</maxIndex>
</rollingPolicy>
<!-- 省略 -->

Storm0.9.0からWorkerのJVMオプションにはTopologyのIDが"storm.id"として含まれるようになったため、それを利用しています。
Worker以外のプロセスで名称がおかしくならないよう、「デフォルト値は空」として設定しています。

動作確認

では、この状態でTopologyを実際に起動してみます。
Storm-UIで確認してみると、以下の画面の通り、「ExclamationTopology-2-1383257328」というTopologyが起動しているのがわかります。
f:id:acro-engineer:20131101072803j:plain
では、ログ出力先を確認してみると、以下のようになっています。
Workerのログ名称にTopologyのIDが付与され、どのTopologyのログかがすぐ分かるようになっていますね!
かつ、これなら複数のTopologyのログが1ファイル中に混在することもありません。

> ls -l
-rw-r--r-- 1 root root 10555253 11月  1 07:27 2013 ExclamationTopology-2-1383257328worker-6701.log
-rw-r--r-- 1 root root 21257836 11月  1 07:27 2013 ExclamationTopology-2-1383257328worker-6702.log
-rw-r--r-- 1 root root 21258738 11月  1 07:27 2013 ExclamationTopology-2-1383257328worker-6703.log
-rw-r--r-- 1 root root        0 10月 31 08:31 2013 access.log
-rw-r--r-- 1 root root     7046 10月 31 08:32 2013 drpc.log
-rw-r--r-- 1 root root     3897 10月 31 08:36 2013 logviewer.log
-rw-r--r-- 1 root root        0 10月 31 08:31 2013 metrics.log
-rw-r--r-- 1 root root    17817 11月  1 07:08 2013 nimbus.log
-rw-r--r-- 1 root root    35318 11月  1 07:08 2013 supervisor.log
-rw-r--r-- 1 root root     2022 11月  1 07:24 2013 ui.log

3.何が嬉しいの?

「StormTopologyのログ出力先はわかりにくい」の裏返しになりますが、以下の2点です。
実際にStormを使ったことがある方にはありがたさがわかっていただけると思います。

  1. どのTopologyがどのログに出力されているか」がファイル名からすぐわかるようになった
  2. 1ファイルには1Topologyのログが出力されるようになった

と、今回はこういった地味な機能でしたが、次回以降もStorm0.9.0で追加された機能について紹介していこうと思います。
それでは。
 
 

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


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

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

Storm0.9.0-rc1で何が新しくなったの?

こんにちは。kimukimuです。

最近気温の変化が激しくて、夜暑くて夏の格好で寝ると途中で寒くて目が覚める・・・
というのが普通にある今日この頃です。
皆さんもお大事に。

さて、先週StormがApacheプロジェクトとなったことについて投稿しましたが、
Stormで大きなニュースがまた一つ出ました。

Storm0.9.0-rc1のリリースです。
rcで正式版ではないのか、という突っ込みもありますが、
このバージョンは「0.9.0正式版リリースに向けた最終リリース確認バージョン」という位置づけのため、
そう遠くないうちに正式な0.9.0としてリリースされることが見込まれます。

1.Storm0.9.0の新機能/変更

Storm-Nettyの登場

まず、もっとも影響の大きな機能変更点として、「通信レイヤをZeroMQとNettyどちらを使うか選択可能になった」があります。

これまではStormの動作にZeroMQ(+Javaの言語バインディング)のインストールが必須となっていため、
ZeroMQをインストールできないWindows上では動作しなかったり、OS依存のパッケージがどうしても存在していました。

ですが、Nettyを選択可能になったことにより、PureJavaなアプリケーションとして動作するようになりました。
#正確に言うと「通信部分がプラグイン方式に変わった」という改修であるため、
#ZeroMQでもないNettyでもない通信コンポーネントを作りこめば、設定のみで差し替え可能になっています。
結果、OSへの依存が無くなり、インストールが容易になり、より広い環境で動作するようになった・・・というわけですね。
Windowsにそもそもインストールする方がいるのかという疑問はさておき。

ですが、機能的に実現できるようになったといっても、速度や負荷についてはまだ疑問が残ります。
なので、今度別個性能の比較はしてみようと思います。

その他新機能/変更点

Storm0.9.0のはStorm-Nettyの追加がメインで、それ以外は主にStorm0.8.2の機能改善が行われた形になります。
その中で個人的に気になった点をいくつかピックアップしますね。

ロギングフレームワークLog4jから今時のフレームワークに換装されました。
Logbackだとログ出力設定の動的更新なども出来るため、ありがたいところですね。

  • WorkerプロセスのJVMオプションにTopologyId、Workerポート、WorkerIdが追加

これもある意味地味な更新ですが、これによってTopology毎に別々のログファイルに結果を出力することが可能になります。
これまではWorker-6700...という形でしかログファイル名を指定できず、
どのTopologyのログファイルかがわからなかったため嬉しいところですね。

  • メトリクス機構の追加

Stormの統計的な情報を取得するメトリクスの機構が追加されました。
これまでは性能としてわかるのはStorm-UIでわかる値くらいで、
それ以上は自前でTaskhookの機構を用いて作りこむか、ログを仕込むなどをしないとわからなかったのですが、
Storm側でそういった機構をより作りやすく提供されるようになりました。

  • Storm-UIでTopology名毎にソートされるようになった

Topology一覧が見やすくなりました。

  • 設定ファイルの設定誤りによるエラーログが見やすくなった

実際に設定をミスした際にどこが悪いかわかりやすくなっています。

ログ出力時にどのSpout/Boltで出力されたメッセージかがスレッド名から判別できるようになりました。
また、問題解析時のスレッドダンプ取得やリモートデバッグ時にも構成がわかりやすくなりました。

  • TridentSpoutが動作中に取得先を変えられるようになった

TridentSpoutが動作中にメッセージの取得先を変えることができるインタフェースが追加されました。
大きな問題には対応できませんが、若干動的な設定が可能になった・・・という形ですね。

  • Ackerスレッドのデフォルトスレッド数がWorkerプロセスあたり1個になった

Stormのメッセージ処理機構を使った際に鍵となるAckerプロセスのデフォルトスレッド数が変更されました。
Workerプロセスが多くなり、処理性能が増大すると真っ先にAckerがボトルネックとなり、スレッドを変更することが必要だったので
その設定がある程度自動的に行われるというのはうれしいですね。

Tupleのシリアライズを行うクラスを差し替え可能になったため、
極端に大きなTupleを送る場合などに効率的なシリアライズが可能になっています。

  • ビルド環境のleiningen 2.0化

・・・これを嬉しいと思うのは相当マニアックなのかもしれませんが、ビルド環境が最新になったのはうれしいところですね。
Stormのソースコード(Clojure部)の確認を行ったり、Storm自体の改造を行う際にわざわざ環境を古いものに切り戻さずに済むのは大きいです。

2.Storm0.9.0で解消された不具合

MLのチェンジログには載っていませんが、
Stormのローカルファイルの状態とZooKeeperの状態が食い違った状態になった際に
Supervisorが起動しなくなる問題が解消されています。
 → 解消するにはStormのローカルファイルを削除して再起動させる必要がありました。このためにClojureのコードと格闘したことが・・・
WorkerプロセスやSupervisorプロセスをkillコマンドで終了した際はかなりの頻度で起動に失敗する状態になっていたため、
頻繁に遭遇する問題が対処されているというのはうれしいですね。

3.Storm0.9.0で最終的に何が嬉しいの?

Storm0.9.0の改修内容をまとめると、大きく下記の2点になると思います。

  1. Storm0.8.2使用時に出ていた運用時/問題解析時の使いにくい点が改善された
  2. 様々なコンポーネントがプラグイン方式となり、アプリケーションに応じて適したプラグインを適用可能になった

以前のStorm-Tridentのように決して派手な機能が追加されたわけではありませんが、
実際にStormを実システムに適用した際に問題となる点が解消され、
後はプラグインによってアプリケーション別のカスタマイズの余地が拡大された形になっています。

個人的にはStorm-0.9.0はある意味「貯め」のバージョンで、
次に来ると思われるStorm-1.0.0でまた大きな機能の追加が行われるのではないかという期待がありますが・・・どうでしょう^^;

今回のバージョンアップでかなり使いやすくなったため、
これまでStormを使ったことが無い方も、使ったことがある方も是非最新のバージョンを使ってみてください。
このブログでも一部の機能については実際に試して結果を書いてみようと思います。

それでは。

StormがApache Incubatorプロジェクトになりました!

こんにちは。kimukimuです。

最近台風が多かったから・・・というわけではありませんが、久々のStormのニュースです。

Stormについて嬉しい発表がありました。

Stormが2013/09/18にApache Incubatorプロジェクトになりました!

ページも出来ています。
http://incubator.apache.org/projects/storm.html

最近StormのリードコミッタのNathanさんが事業を立ち上げてそちらに時間を使っているせいか、
不具合対応バージョンの0.8.3やZeroMQを使わず、新機能が追加されてモジュールも整理された0.9.0の
WIPバージョンばかりが積み重なっている状態になっていました。

そのため、Apache Incubatorプロジェクトとして安定的に開発が進む土壌ができたというのは非常にありがたいですね。

Storm自体は0.8.2で運用や不具合解析の際に使用しやすい機能が拡充されて一つの到達点には至ったと思います。
ですが、その後使ってみると「これってできないのかな?」「ここは使いにくいな。」という点が出てきています。
そのため、その一部が対応されている新しいバージョンを首を長くして待っていたところ、今回の発表があったというわけです。

今後もStormが広がっていくことを楽しみにしながら、ページを確認していこうと思います。
何か新しい情報が出てきたらまたお知らせしますね。

最近、こんな記事を執筆しました

こんにちは。
最近、ちょくちょく雑誌やWeb媒体に記事を書く機会が増えてきた @ です。

ただ、あまり計画性のない僕のことですから、いつも「締め切り直前まで熟慮するメソッド」で
自分を追い込んで(追い込まれて?)います(><)


なんて思いながら振り返ってみたら、ウチの会社全体でいろいろな記事を書いていることに気付きました。
そんなわけで、『こんな記事を書きました』っていう紹介です。


日経ソフトウエア 特集1「そのコードは古い」

5月24日に発売された日経ソフトウエア7月号の
特集1「そのコードは古い」のPart2「Java編」を執筆しました。
http://itpro.nikkeibp.co.jp/NSW/

この特集の裏話をちょっとだけリークしちゃうと、
元々、同僚と一緒に日経ソフトウエア
Javaのイケてるコード、残念なコード」という記事を連載をしていました。

そのうちの一つ、「Javaの新定石を学ぶ」が好評を得たため、
特集記事を組もうという話が持ち上がったことがキッカケで、この特集記事に繋がりました。

ぜひ、読んでみてください!


Javaのイケてるコード、残念なコード

せっかくなので、その連載も紹介しておきますね。

Javaのイケてるコード、残念なコード」というタイトルで
2012年7月号から、2013年4月号まで連載していました。

平たく言うと、Javaコードのbefore/afterのようなものを、テーマ別に説明しています。


第1回 読みやすいJavaコードを書く技術
第2回 拡張しやすいJavaコードを書く技術
第3回 性能が高いJavaコード書く技術
第4回 5カ条で学ぶ堅牢性を考慮したJavaコードを書く技術
第5回 テストしやすいコードを書く技術
第6回 記述するコードを減らす技術
第7回 Javaの新定石を学ぶ
第8回 Javaの新定石を学ぶ (後編)
第9回 静的解析ツールを駆使してイケてるコードを書こう
第10回 イケてるコードを書くステップ


当初は3、4回ぐらいのつもりで書き始めたのですが、
あれよあれよと10回まで伸びてしまいました。

いやはや、ここまで連載が伸びてしまうとは。
恨むべくは、溢れんばかりの己の才能ですね(ドヤァ

# いやもちろん、僕だけじゃなく、同僚の力もあっての事なんですけどね (--;;


halookで始めるHadoop/HBaseトラブルシューティング

連載と言えば、後輩の @ がgihyo.jpで「halook」の連載記事を書いています。
halookは、Hadoop/HBaseのトラブルシューティングツールです。

連載 halookで始めるHadoop/HBaseトラブルシューティング

第1回 halookでHadoop/HBaseを可視化しよう
第2回 halookのセットアップ
第3回 PartitionerとCombiner
第4回 投機的実行
第5回 Fair Schedulerによる複数ジョブの同時実行
第6回 Capacity Scheduler による複数ジョブの同時実行
第7回 halookを支える技術「ENdoSnipe」

Hadoop等の内部動作を可視化しながら説明しているのは、なかなか面白い試みなので
たとえhalookを使わなくとも、Hadoopを使っている方や知りたい方にオススメです。


ちなみにこの記事を書いた @ は、
Hadoop Conference JapanやJJUG CCCなどでも精力的に発表しています。

JJUG CCC 2012 Fall発表資料
Hadoop, HBase可視化ソフトウェアhalook

Hadoop Conference Japan 2013 Winter発表資料
トラブルシューティングのために欲しかった、Hadoopがまるっと分かる可視化ツール


春の嵐吹く,リアルタイム分散処理Storm

最後に、技術評論社つながりでもう一つ。
先輩の @技術評論社Software Designの6月号にStormの記事を書きました。

春の嵐吹く,リアルタイム分散処理Storm
http://gihyo.jp/magazine/SD/archive/2013/201306

Strormは、Twitterが作ったストリームデータ処理のプロダクトですね。

Stormはただでさえググラビリティが低い名前の上に、
まだまだ日本語情報が少ない状態ですので、
まとまったStormの入門記事として参考になると思います。


そんなわけで @ のドヤ顔マーケティングをお送りしました! #ドヤマ


なんて、このエントリー自体、
某記事の執筆追い込み中に書いてるだなんて、恐ろしくて言えやしない・・・。

よし、頑張ろう! (^^;

メッセージを処理する度に共通処理を行う方法は?

こんにちは。kimukimuです。

少し宣伝を。
2013年5月18日発売のSoftware Design 2013年6月号に、
「春の嵐吹く,リアルタイム分散処理Storm」という形でStormの記事が掲載されています。

Stormの概要や実際に外部のプロセスと組み合わせてTopologyを動かす方法が載っていますので、
興味がある方はぜひ読んでみてください。

というわけで(?)、本題に入ります。

1.StormのTuple処理に対して共通的に処理を行わせることは出来ないの?

Stormを実際に動かしていて大変なこととして、「どのイベントがどう流れたかがわからない」というものがあります。

一応、Topologyを起動するときにパラメータを指定すればデバッグモードで起動して、
個々のイベントについてもログ出力がされます。
・・・なのですが、Spout/Boltで処理した全イベントに対して一律でログが出力されるため、
量が多すぎて追うこと自体が非常に大変な状態になってしまいます。

元々、Storm自体がストリーム処理ということで秒間数千数万のイベントを処理することを前提としていますので、
全イベントに対して一律ログ出力した場合の量は推して知るべし・・・というわけですね。

そんな困ったことに応えるための機構として、StormにはTaskhookという機構があります。
読んでみると、Tupleを処理するごとにイベントを呼び出すことができるというものの模様。

そのため、まずは今回はTaskhookを動かしてみて動作を確認します。

2.Taskhookの作り方は?

実装方法は比較的単純で、BaseTaskHookクラスを継承して行いたい処理を記述するのみです。

そのため、まずはTuple処理時の内容を全てログ出力するTaskhookを下記のように作成しました。

public class PrintTaskHook extends BaseTaskHook
{
    /** ロガー */
    private static final Logger logger = Logger.getLogger(PrintTaskHook.class);

    /**
     * パラメータを指定せずにインスタンスを生成する。
     */
    public PrintTaskHook()
    {}

    @Override
    public void prepare(Map conf, TopologyContext context)
    {
        logger.warn("TopologyContext=" + context.toJSONString());
    }

    @Override
    public void cleanup()
    {
        logger.warn("cleanuped");
    }

    @Override
    public void emit(EmitInfo info)
    {
        logger.warn("EmitInfo=" + ToStringBuilder.reflectionToString(info, ToStringStyle.SIMPLE_STYLE));
    }

    @Override
    public void spoutAck(SpoutAckInfo info)
    {
        logger.warn("SpoutAckInfo=" + ToStringBuilder.reflectionToString(info, ToStringStyle.SIMPLE_STYLE));
    }

    @Override
    public void spoutFail(SpoutFailInfo info)
    {
        logger.warn("SpoutFailInfo=" + ToStringBuilder.reflectionToString(info, ToStringStyle.SIMPLE_STYLE));
    }

    @Override
    public void boltAck(BoltAckInfo info)
    {
        logger.warn("BoltAckInfo=" + ToStringBuilder.reflectionToString(info, ToStringStyle.SIMPLE_STYLE));
    }

    @Override
    public void boltFail(BoltFailInfo info)
    {
        logger.warn("BoltFailInfo=" + ToStringBuilder.reflectionToString(info, ToStringStyle.SIMPLE_STYLE));
    }

    @Override
    public void boltExecute(BoltExecuteInfo info)
    {
        logger.warn("BoltExecuteInfo=" + ToStringBuilder.reflectionToString(info, ToStringStyle.SIMPLE_STYLE));
    }
}

見ての通り、イベントが発生した際にその時の情報を出力する・・・というものです。
実はTaskhook作成に必要な内容はこれだけです。

後は実際にTopologyに組み込んで動作を確認してみます。

3.Taskhookの設定方法は?

Taskhookを実際に起動するには下記2つの手順が必要です。

  1. TopologyのJarファイルにTaskhookを含める
  2. Stormの設定でTaskhookを登録するよう設定する

1の方はTopologyと同じプロジェクトに入れてビルドを行えば、JarファイルにTaskhookも含まれます。
そのため、2の説明を行いますね。

Stormの設定でTaskhookを登録するにはyamlファイルに下記のように設定を記述します。

topology.auto.task.hooks:
    - "storm.sample.taskhook.PrintTaskHook"

これで、準備は完了。
実際にTopologyを動作させて試してみましょう。

4.Taskhookを実際に動作させてみる

まず、3の設定を行った状態でTopologyを起動します。

すると・・・・Stormのログに下記のように各イベント発生時のログが出力されていることがわかります。

2013-05-20 15:43:36 PrintTaskHook [WARN] TopologyContext={"task->component":{"1":"JudgeBolt","2":"JudgeBolt","3":"JudgeBolt","4":"JudgeBolt","5":"LongWord","6":"LongWord","7":"LongWord","8":"LongWord","9":"ShortWord","10":"ShortWord","11":"ShortWord","12":"ShortWord","13":"WordSpout","14":"WordSpout","15":"WordSpout","17":"__acker","16":"WordSpout"}}
2013-05-20 15:45:22 PrintTaskHook [WARN] EmitInfo=[mike],ShortWord,2,[10]
2013-05-20 15:45:22 PrintTaskHook [WARN] BoltExecuteInfo=source: JudgeBolt:2, stream: ShortWord, id: {}, [mike],10,<null>
2013-05-20 15:45:22 PrintTaskHook [WARN] BoltAckInfo=source: JudgeBolt:2, stream: ShortWord, id: {}, [mike],10,<null>

これでまずTaskhookが起動可能なことと、概要の動作について把握することができました。

5.Taskhookを使うと何が嬉しいの?

今回の結果だけだと単にログを出力するのみで終わりますが、下記のような利点が考えられると思います。

  • 1.デバッグモードと異なり、「特定の条件を満たした場合にログ出力」が可能になる

一律で全出力のデバッグモードと異なり、必要な場合にのみログ出力を行うということが可能になります。
それによってログ出力の負荷を抑制し、必要な情報を出力できるというのが利点としてあげられると思います。

  • 2.ログ出力だけでなくデータの集計/出力も可能となる

ログ出力という固定の処理だけでなく、イベントの結果をどこかに保存しておいて集計したり、加工した上での出力も可能となります。

もし、デバッグモードで使いにくい点があると感じている方は是非使ってみてください。
それでは。

Topologyを起動中にどこまで何が変更できるの?

こんにちは。kimukimuです。

4月になり、花粉も徐々に収まってきたので最近快適ですね!
花粉症仲間(?)の皆さまであれば同意していただけると思います。

にしても、スギ花粉が何故こんなに飛んでいるのかというと、
本の森林の3割はスギとヒノキでしめられているから・・・だそうです。

別に偶然というわけではなく、人間がスギを植え続けた結果、今日みたいな状況を招いたようですね。
もしかすると、当時は花粉症なんてものが存在せず、花粉症が広まることもわからなかったのかもしれません。

ともあれ、花粉対応ということでStormという名前のプロダクトを使い続けようと思います。
・・・冗談ですよ、冗談。

1.Topologyを起動したまま、何が変えられるのか?

前回Topologyの切り替えを行うためにTopologyの起動を早くするための方法について書きました。
そのため、今回はその関連ということで、「Topologyを起動したまま、何が変えられるのか?」について確認してみます。

Stormにはrebalanceコマンドがあり、Workerプロセスその他の再配分が可能になっています。
このコマンドで何がどこまで出来るのかを確認してみます。

まずは、stormコマンドのヘルプを確認します。

[root@hyperion storm]# bin/storm help rebalance
Syntax: [storm rebalance topology-name [-w wait-time-secs] [-n new-num-workers] [-e component=parallelism]*]

確認すると、設定可能な項目は下記の3点のようです。

  1. -w Rebalanceにおける待ち時間(Topologyをdeactivateしてからの待ち時間)
  2. -n Workerプロセスの数
  3. -e 各コンポーネントに対するExecutorの数

上記のうち実際に構成を変更するパラメータはWorkerプロセスの数と、Executorの数です。
2パラメータを実際に設定して試してみます。

2.Workerプロセス数の変更

では、早速Workerプロセス数を変更してみます。
まず、実行前のStormクラスタの状態が下記。Workerプロセス数は2であることがわかります。

その後、下記のコマンドを実行します。

[root@hyperion storm]# bin/storm rebalance DecisionTest -w 10 -n 1

すると、rebalanceが開始して・・・

Workerプロセスが1個になりました。

同じように下記のコマンドを実行すると・・・

[root@hyperion storm]# bin/storm rebalance DecisionTest -w 10 -n 4


今度はWorkerプロセスが4個になりました。
Workerプロセスの数はこうやってrebalance出来ることがわかりましたね。

3.Executor数の変更

では、次はExecutor数の変更です。
これは個々のコンポーネント(今回の場合、WordSpout、JudgeBolt等)に割り振ったスレッド数を
Taskの並列度(今回の場合、4)までの範囲で増減させることが可能になっているようです。

実際に試してみますね。
まず、最初にコンポーネントとスレッドの一覧を確認します。

コンポーネントの並列度は4で、Executorも4ずつ割り振られていることがわかります。

では、下記のコマンドを実行します。

[root@hyperion storm]#bin/storm rebalance DecisionTest -w 10 -n 2 -e WordSpout=2

すると、WordSpoutのExecutorの数が2になっていることがわかります。
Taskの並列度については変更できないようです。

更に下記のコマンドを実行します。

[root@hyperion storm]# bin/storm rebalance DecisionTest -w 10 -n 2 -e JudgeBolt=2 -e LongWord=3

すると、JudgeBoltとLongWordのExecutor数が変わることも確認できました。
WordSpoutのExecutor数変更も維持されるようです。

4.これらのパラメータってStorm-UIからも変更できるの?

こういうことが出来るんだとわかると、気になってくるのがStorm-UI(GUI)からどこまで出来るんだろうということですね。
そのため、実際にオプションを指定して試してみます。

すると・・・!

あらま。どうやらStorm-UIからはRebalanceにおける待ち時間しか設定できないようです。

残念ですが、構成を変更するにはコマンドラインから入力する必要があるというわけですね。

そのことがわかったところで、今回はここまでです。
それでは、また。

StormでTopologyを素早く起動させる方法は?

こんにちは。kimukimuです。

最近花粉で駆逐される側に回っている今日この頃です。

アレグラFX、ザジテン等普通に薬局で買える薬も強力なものがそろってきているんですが、
それ以上に花粉の症状がひどく、例年になく苦しんでいる状態です。
・・・ただ、マスクすると息が吸えずに苦しく、それはそれで問題なんですよね。

ともあれ、では本題に入りましょう。

1.Topologyを起動するのには時間がかかります

実際にStormクラスタを扱ったことがある方であればわかるかと思いますが、
StormでTopologyを起動する際には下記のように時間がかかります。
#当然、マシンの性能で変わりますがCorei7やXeon E3といったCPUを積んだエントリサーバクラスだと下記くらいです。

  1. TopologyをSubmitするJavaコマンドを起動するのにかかる時間:3秒
  2. TopologyをSubmitする時間:2秒
  3. TopologyをSubmitしてから実際に走り出すまでの時間:5秒

10秒、とこれだけ書くとそれほど大きく感じないかもしれませんが、
この10秒でも下記のようなケースでは問題になります。

2.Topologyの起動が遅くて困るシチュエーション

上記に書いた時間がかかって一番困るのは、
個人的には「Toopologyのアップデート」というタイミングだと思います。

当然、Stormを使うような場所はそれだけ大量のデータが流れるわけでして、
そんな中で待つ必要がある・・・というのはやはり大きな制約でしょう。

3.Topologyの有効無効は切り替えられる

ですが、Storm-0.8.2にバージョン更新されたStorm-UIを見てみると
下記のように「Activate」「Deactivate」「Rebalance」「Kill」というボタンがあります。

ここで「Deactivate」のボタンを押してみると・・・・
下記のようにTopologyの状態が「INACTIVE」に切り替わります。

次にボタンを押せるようになるまで数十秒ほどかかりますが、
押せるようになった後であれば「Activate」のボタンを押せばすぐに「ACTIVE」の状態に戻ります。

ということは、下の流れのように
「あらかじめINACTIVEの状態で新しいバージョンのTopologyを用意しておいて、
 Activateさせればすぐに新しいバージョンのTopologyに切り替わるのではないか?」というわけですね。

1.新バージョンのTopologyをINACTIVE状態で用意

2.旧バージョンのTopologyを終了

3.新バージョンのTopologyを「Activate」

4.Topologyを「無効」の状態で起動してみます

ですが、これを実行するためには「TopologyをINACTIVE状態でSubmitする」ことが必要になります。
で、Storm-0.8.2から丁度「Topologyの初期状態を指定できる」機能が加わっています。

そのため、実際に出来るかどうか試してみましょう。

実際に「TopologyをINACTIVE状態でSubmitする」には下記のようにコードを記述します。
尚、毎度のようにソース全ては「GitHub(StormSample)」を参照ください。

// Topology起動時にINACTIVE状態でSubmitするよう設定
SubmitOptions options = new SubmitOptions(TopologyInitialStatus.INACTIVE);
// TopologyをSubmit
StormSubmitter.submitTopology("DecisionTest", conf, builder.createTopology(), options);

上記のコードで実際にSubmitをしてみると、下の画面のように「INACTIVE」状態で初期化されました。

これで、「INACTIVE状態で起動して素早くACTIVEに切り替える」ということが可能、ということがわかりました。

5.何が嬉しいの?

一度書いていますが、応用することで
「バージョン更新などの際に素早くバージョンを切り替えることができる」
が嬉しい点として挙げられると思います。

もしStormのTopologyを起動するのに時間がかかって困るという方がいたら、
是非試してみてください。

それでは。