まず、最初に書いておくがタイトルは釣りです。
TwitterによるHeronの論文にて結構ボロクソに言われていたStormなのだが、最近調べてみたら実は結構しっかりと成長をしていることがわかってきた。
特に、StormにおいてはHeron論文がネガキャンになってしまっている気配があるので、Heron論文があげている当時のStormの問題点が最近のStormではどうなっているかを中心にメモを起こしておこうと思う。
ちなみに、 TwitterによるHeronの論文 が 2015/6 で、その当時の Storm 最新版は0.9.5くらいだった。なお、論文をちゃんと読んでないので論文中のStormの正確なバージョンを特定できていない（というか、Stormのバージョン表記を論文内から見つけられず..。だが、Twitterの論文の比較対象Stormは0mq利用のように読めるので0.8系相当のStormの可能性が高い。)
なお、今回の調査対象 Storm バージョンは v1.0.x。（xは調査ソースにおいてマチマチ。あしからず）
以下に、 TwitterによるHeronの論文 のStormへの問題意識とそこへのStorm現状という感じで書いておく。
バックプレッシャー機能が無い
Heron論文当時には無かったがすでに実装されている。Heronの論文にあるSpout Backpressure に近い動きのものが実装されているような気配。
Storm 1.0.0 release note の Automatic Backpressure 参照。
タスク単位の利用リソースを意識したスケジューリングが無い
新Stormでは、Spout/Bolt単位でのリソース要求に対応したResource Aware Schedulerが登場し、この問題に対応している模様。
Stormでは1つのWorkerプロセス内に多数のタスクを動作させるが、各BoltやSpoutのタスクのリソース(CPU、Memory)利用量を考慮したスケジューリングが昔はできなかった。
この影響でJVMやサーバサイジング時にTwitterでは非常に安全率を高くとらざるを得ず効率が悪かったらしい。
Storm 1.0.0 release note の Resource Aware Scheduler 参照。
NimbusがSPOF
新StormではNimbus HAが実装されており、N重化が可能となっている。
Highly Available Nimbus Design
ZooKeeper負荷が高い
最新Stormでは、ZooKeeperを使わずに各Workerのheartbeatを処理できるようになっている。
Storm 1.0.0 release note の Pacemaker - Heartbeat Server 参照。
性能が出ない
特に v1.0がリリースされたタイミングで大幅な性能向上があった模様。
内部的な情報もあるけど出せないので、以下の公知の情報を参照されたい
MICROBENCHMARKING APACHE STORM 1.0 PERFORMANCE (v0.9.0.1 vs. v1.0.1)
一応 v0.9.0.1 でも Netty 対応をしているはずなのだが、v1.0.1 では
- メッセージ数のスループットで約1.7～5倍性能向上
- レイテンシで 13倍～242倍向上
とかなりチューンナップがされた模様。
この数字自体はHeron論文の対Storm(0.8系?)の性能比と比較しても遜色無い数値に思える。
その他
ほかにも、
- sliding window処理が trident 使わなくてもかける
- Redis連携によるステート処理がかける
- Debugやボトルネック解析のための細かい機能追加
等、さまざまな機能が追加されていてだいぶ使いやすくなっている。
（書いてて思ったが、ほとんど storm release note v1.0.0 をサマっただけだった。）