Home > Uncategorized > The Goog Life：グーグルが従業員を子供扱いすることでつなぎとめている件

The Goog Life：グーグルが従業員を子供扱いすることでつなぎとめている件

2007-01-05 (Fri) 10:19
Uncategorized

しかし、十分な時間 Google 社員とつるんでみれば、彼らが GFS（訳注：Google File System）の信頼性のなさや、実は負荷に対応するのに十分なコンピュータがないのに不平を言うのを聞くことになるだろう。

GFSは不安定なのか。

GFSの論文が出たのは3年も前なので今はアーキテクチャが全然変わっているかもしれないが、やっぱりMaster & Slaveモデルだと何万台(何十万台?)ものSlaveがいる場合にMasterへの負荷が凄いことになってしまうのかなぁ。以下は論文を読んで得られた情報からの適当な予想です。
GFSの長所としては「ファイルのレプリケーション」「データの分散が透過的に行える」「ファイルの追記が出来ること」という2点だと思う。
1つ目の性質は検索のインデックスなど壊れると困るようなものに使われているのだと思う。あとはGMailなんかの無くなると困るユーザーデータについてもこの性質が役に立つ。GMailでも使われているというのは勝手な予想だけど、メールデータの管理というのはデータの追記と削除で間に合いそうなのでGFSのモデルにマッチしそうというのと、使っていてデータ転送が多少もたつく気がするのでたぶんそうだと思う。
2つ目の性質はMapReduceのような分散計算の仕組みと組み合わせる事で威力が発揮される。データを生成してGFSという論理的な格納庫に入れておくと、どのマシンからもそのデータが見える事になる。そうするとMapReduceのMapperとかReducerを作るさいには「データがどこに有って、どこから転送してきて」という様な事を気にせず実装する事が出来る。まぁファイルのlocalityなんかはもちろんスケジューリングされてるだろうけど。
3つ目はおそらく集めてきたWebのデータだとかメールだとかをどんどん入れるGoogleのアプリケーションに上手くマッチするんだろう。
短所としてはやっぱり「Master & Slaveモデルであること」「ロックが適当」という事だろか。
1つ目はやっぱりMasterに負荷が集中するのと、Masterが落ちたときにダメージがでかそうと言うことだろうか。読み込み時だけShadow Masterを使って負荷を軽減なんて話も有るが、「GFSの信頼性のなさ」に文句が出るとすれば一番にやばそうなのはこの点だろう。
2つ目はロックが適当そうという点で、論文見る限り/home/gfs/hogeに書き込む際には/home, /home/gfsのread lockを取ってから/home/gfs/hogeのwrite lockを取るような方式を使っているらしい。ここで心配になるのはlockの取り方というよりはlockの外し方のほう。lockを取ったマシンがunlock要求を出す前に死んでしまうことも十分ありうる。
そうなるとロックを管理しているMasterは、ある一定期間以上unlock要求が来なかったら自動的にロックを解除とかやるんだろう。どうもこの辺が気持ち悪くて問題が発生しそうな気がしているのだが、でもよく考えるとこれ以外に良い方法がなさそうなので商用のDBとかもこうなっているのかもしれない。
livejournalのMogile FSという奴もまぁMySQLの機能に頼りつつこんな感じで適当に割りきって実装されてるんだと思う。
しかしアカデミックからもうちょっと上手いFileSystemが登場しないもんかなぁ。滅茶苦茶スケールして、レプリケーションして、分散ロック管理して、普通のファイルシステムみたいに使える奴。RedHatのGlobal File System(名前狙いすぎ)が気になるけど、あんまり資料がない。GPLとかいいつつソースどこやねん。