今の分散システムはZooKeeperに依存し過ぎではないだろうか。ワークロード毎に最適化のポイントは違うのにそれをすべて1つのクラスターにやらせるのは分散合意の実装が困難で、やりたくないからだろうか。
2013-11-16 11:11:33メタデータ管理のZooKeeperと状態遷移のストレージクラスターの性能評価なしに、サービスの分散システムのサーバだけの性能評価をしたところで改善には限界があると思うが、どうだろう。そこはやらない方針か
2013-11-16 11:14:54@masayh 使っていて思いますが、メンバシップ管理のところが面倒かつ分散システム組む上では必須で、そこのワークロードに関しては多くの部分が ZK でカバーできているからこそ使われているのだと思いますよ。
2013-11-16 11:18:34@oza_x86 メンバーシップ管理くらいなら十分だと思っています。問題はそれ以外のもっとヘビーに使う場合。
2013-11-16 11:21:01@oza_x86 クラスターのための状態管理はその状態量や状態遷移のタイミングなどがそれぞれ違うので、アーキテクチャーを作るときにそのワークロードを設計段階で検証して、性能面と、ZKの動的振る舞いが可用性の観点で許容されるかどうかくらいは検討しないと。
2013-11-16 11:27:28Jim Nisbet, Loggly CTO breaking down our use of #Storm from Twitter and the marriage of data and resources. http://t.co/FEAuvhbX0O
2013-11-16 06:52:59最近、StormのZooKeeperへの状態保存があまりよろしくない気はします。状態遷移を伴うようなものならともかく、性能情報履歴まで突っ込んで頻繁に更新しているのはやりすぎではないですかねぇ・・・
2013-11-16 11:33:56ZooKeeperの存在のおかげで個々のプロセスの処理がシンプルに保てている側面もあるので当然いい面もあるのですが、用途的には多分あまりよろしくない使い方なんでしょうね。
2013-11-16 11:39:53@oza_x86 StormはZKに頻繁に更新する性能情報を入れているのであまり筋のよい使い方ではないとは思いますね・・・ 明らかに「状態管理」の域をオーバーしていますので。
2013-11-16 11:45:22と言いつつ、性能情報をどこに入れるかというと・・・また何か別プロセス立てる?という話になってしまうのが厄介な所ではあるのですが。
2013-11-16 11:46:51そのあたりの子タスクの情報管理などはMesos等でも当然やっているのでしょうけどZooKeeperにはMasterのメンバーシップ情報しか入っていないわけで・・ ちとモデルを確認してみますかね。
2013-11-16 11:54:11@kimutansk ですね。その情報を何に使うのかにもよりますが、例えばアラートに使うだけなら単体で持っておいて通知だけZKでする、落ちたら諦めるとか、そういう割り切りが必要ですよね。
2013-11-16 12:07:44@oza_x86 そのあたりの割り切りは重要ですね。 ただ、Stormの場合管理画面で表示する情報全てZooKeeperに保存してしまっており、割り切れないのでさすがにそれはやり過ぎかな、という印象です。
2013-11-16 12:16:17Supervisor 自体は ZK に対してそんなにヘビーな負荷はかけてないと思ったけど。一部の Spout が batch ごとにチェックポイントを書き込みに行くくらいじゃないかな。 https://t.co/t6iSi9gJCR #stormjp
2013-11-16 16:11:52Supervisorは軽いんですが、WorkerのTaskの性能情報を数秒に1回、書いてるんですよね。以前ZooKeeperの中身見たらそうでした・・・>RT @okapies: そんなことしてるんだ…。 https://t.co/fAUa8XbQXC #stormjp
2013-11-16 16:16:25