第23回InfoTalkに参加してみました。
10/15に産業技術大学院大学が主催するInfoTalkの第23回に参加してきました。
InfoTalk#23では、分散ストレージの発表があり、Webサービスを開発する自分としては大いに興味のある内容でした。
18:30 - 19:00までの30分
自分は18:30スタートだと思い、仕事をぶっちして会場に駆け込みました。
しかし、、、
発表は、19:00スタートのことです。この30分は、何か面白い話が聞けるかも、もしくは連絡・お知らせの時間とのことです。そのため、自分には必要ないと思えば、19:00までに会場に入ればOKかもしれません。ただし、今回はあまり話すことが無かったために発表が少し前倒しで開始されました。時間があるようならば、18:30から会場にいるのがいいと思います。
発表1：グリーの大規模分散ストレージ戦略
グリーさんが自社で開発して使い始めているというnanofs（ナノエフエス）についての説明が聞けました。基本的な内容は、グリーさんのエンジニアブログ、グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineers' Blogとグリーの大規模分散ストレージ戦略(nanofs) Vol.2 | GREE Engineers' Blogの内容だったように思います。
全体的な所感としては、nanofsはまだ開発中といったステータスなのかなと思いました。分散ストレージの基盤部分は実装済ですが、運用を考えるとまだ機能不足のように思えました。これからもっと良いものになっていくのだと思います。
直近で自分に必要なものか？と考えると、決して必須なものではないように思いました。前述のブログの内容にあるような第一世代、第二世代辺りを使用して、その後導入を考えるような気がします。
nanofsはバイナリ形式で保存しているため動画なども対応可能です。
まー、そうなりますよね。
ワーカーを並列に処理させる場合に考えること。
発表後、質疑の中に興味深いものがありました。それは、nanofsのワーカー（キューの内容に従いコピー＆削除をおこなう）を並列に処理させた場合に起こる事象についてです。
例えば、ファイルAという1つのファイルに対して1.更新、2.削除といった命令が外部より依頼されたとします。これらの命令はキューに登録され、それをワーカーが処理します。この時、ワーカーを並列で処理させるように設計すると、何らかの理由（ワーカー側の処理の遅延など）により、1,2で受け付けた命令が2,1の順で実行されてしまう可能性がでてきてしまいます。この場合の対処をどうしているのか？というものでした。
今のnanofsの実装では、マネージャーベースで適切にファイル情報の管理しているため、ゴミは残ってしまうが対外的には矛盾した状態は発生しないということでした。
確かに、コピー、削除の実行についてマネージャーに問合せをおこないながらおこなえばメタ情報は正しい状態に保つことは可能だと思いました。別の方法としては、ワーカーの実行を制御するなどの一捻りを入れるなどなのでしょう。これはこれで実装が面倒そうですね。
今回のことで、並列して処理を実行させる場合の注意すべき項目を一つ教えて頂けた気がします。
発表2：kumofsの設計と実装
kumofsは、実用性を重視した分散データストアとのことです。"分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi"や"The Kumofs Project"、"kumofs関連資料まとめ - Blog by Sadayuki Furuhashi"の情報をを参照下さい。
なんといいますか、説明を聞いていてすごすぎて私ごときではコメントできないぐらいのシステムでした。とは言え、折角お話を聞いてきましたので、いくつかメモります。ほんと、話を聞くだけでワクワクするようなシステムでした。
アルゴリズベースで保存先を決定します。
ファイルを保存する先をアルゴリズムで決定するとのこと。前述のnanofsは、マネージャーベースであるため基本部分が異なるようです。ハッシュの考え方を導入しているため、計算にて求めるわけです。この場合、マネージャーへの問合せが必要ないため色々なメリットがあるようです。結局Consistent Hashingはなんとなくしか理解出来ませんでした。
Consistent Hashing、Virtual node、Double hash table
Consistent Hashingは開発者ご本人のブログ"kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi"に説明が記載されていました。
コンシステントハッシュ法で保存先を決めてるようですね。ノードに関しては、物理的なサーバの数に依存するのではなく、仮想的なノード（Virtual node）を作成してノード数を増やしいるようですね。Double hash tableですが、問合せと更新のテーブルが異なるという点しか自分では理解できませんでした。更新処理中で処理が完了していない状態に問合せがくるとまずいため、ハッシュのテーブルを分けて処理していると自分は理解しました。
