TwitterでつぶやいたStormの雑多な情報まとめ（その５

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその５です。
いや、思ったより呟いていた量多かったんですねｗ

○36.StreamGroupingのうち、FieldGroupingはキーのハッシュ値で配分先が決まるContext Hashing方式。
　ShuffleGroupingはラウンドロビン方式で配分先を決める。

○37.Taskに対するHeartBeat処理はTask自身の処理とは別スレッドで動作する。
　なので、内部でSleepを続けるBoltであっても、異常とはみなされない。

○38.SpoutのnextTupleメソッド、Boltのexecuteメソッドは１インスタンスにつき１スレッドでしか実行されない。
　そのため、SpoutのnextTupleメソッド、Boltのexecuteメソッドの中で行う処理はマルチスレッドで実行されることを考えなくていい。

○39.ZeroMQネイティブ領域にメッセージが蓄積されてリークすることもある。
　そのため性能を確認する際にはネイティブ領域も確認すること。

▼40.Workerスロットが足りない場合は残るWorkerスロットを確保してTopologyを動作させる。
　新たなクラスタマシンが加わったら自動的に足りなかったWorker分がアサインされる。
　→　・・・残るWorkerスロットに割り振った際に構成要素が足りないケースもありそう。

○41.ZooKeeperトラフィックが多い場合、「task.heartbeat.frequency.secs」でZKへのHB間隔は変更可能。

○42.max_spout_pendingはSpoutのインスタンス単位で蓄積される。Topology単位ではない。

43.Topology Rebalanceの動作は「Spoutからメッセージを取得するのを停止してタイムアウト時間だけ待って、Workerを再配分する」。
　そのため無停止で実施することはできない。

44.Workerが死んで、所属していたタスクが他の新規Workerに割り振られた場合、処理Tuple数はリセットされる。

45.Boltの内部で判定して処理をするか決めるなら、いっそCustomGroupingの中で破棄するのもあり。

46.NimbusがSPOFかというと微妙。
　なぜならNimbusが落ちても、元々起動していたTopologyは問題なく動作する。
　Nimbusのプロセスが単に死んだだけなら再起動すれば特に問題なく復旧する

47.localOrShuffleGroupingはローカルのホストに存在するかを確認するわけではなく、
　同じWorkerに次のTaskがあるか見ている。

48.StormClusterに新たなSupervisorを追加した場合、単にそれだけではタスクの移動は行われず、Rebalanceをうつ必要がある。

49.Topologyサブミット時にNimbusのローカルファイルとしてTopologyがシリアライズ化されて保存され、それがSupervisorにも送信される

50.Topologyに渡すConfigMapはJSONにシリアライズされてやりとりされている。
　そのためログから使用した設定を見ることが可能。・・・UIで見れるのであまり意味ないか？

○51.Supervisorノードにライブラリを追加した場合、Supervisorプロセスを再起動しないと
　Workerプロセス起動時に使用されない。

52.ZooKeeperサーバは10〜20台のStormクラスタで1台で賄える。
　但しこの場合ZookeeperがSPOFになるので、3台でクラスタを組んでおくのが無難。

53.同一Workerプロセス内でTupleをやり取りする際にはシリアライズが行われないため、
　性能的にかなり有利。

○54.Max Spout Pending のデフォルト値は無し。
　つまり、設定せずにサイジングミスった場合そのまま溢れる可能性がある。

さて、今回はここまで。
そろそろ折り返しに来たような気がします。

積み残しＡＩ：
メッセージIDとAck/Failの概念については別途まとめる
さらなるまとめサイトの必要性について
実際の実装を添付してまとめる