Google File System 勉強中

Google Wave, App Engine, MapReduce などなど、凄く面白そうではあるが、どうもよくわかった気がしないので自分なりにまとめようと思う。

まずは、、、

SOSP'03 "The Google File System", gfs-sosp2003.pdf

Google File System II ( http://www.publickey.jp/blog/09/google_file_system.html ) なんて話もあるらしいですが、まずは Google File Syetem について。論文を客観的にまとめてから、主観を書こうと思ったが、既に良いメモがあるので客観的まとめは省略

• http://dev.ariel-networks.com/column/tech/google_file_system

まとめ（主観まじりですので注意）：

• 概要
  
• 安いPCで分散ファイルシステム
• 例： 1000+の strage node, 300+TBの disk, 数百の client
  
• 想定
• failure are the norm rather than the exception.
• ファイルは大きい
• 現実のアクセスパターン
  
• Co-design Application and File System API.
• 特殊なAPIを作ってでも、現実的な課題を解決する。
• アプリケーションもうまくGFSを使わないといけない。
  
• アーキテクチャ
• 構成
• single master server, multiple chunkservers and multiple clients
  
• single master server
  
• メタデータの保持. メモリ上におくのがポイント
• 故障対策をいろいろがんばっている
• single なのは simple にするため。single の欠点には触れてないっぽい
  
• chunk (fixed size, 64MB)
• chunk が大きいほどメタデータを小さくできる。
• chunk が大きいと、ファイルが小さ場合に分散されないのがデメリット。
• でもだいたいファイルは大きいからいいよ！
• 分散実行しようとしたバッチファイルに負荷が集中しちゃった！
• chunk毎に処理するバッチ. 
• いっぱいファイルをreplicateして、時間をずらして解決
• API
  
• POSIXなどでないが、一般的な操作はできる。
• client が libGFS をリンクすると、ごっそりGFSをアクセスするようになったりするのでは？　知らんけど。
• cache
• client cache は効かないのでない。coherence 問題から解放される。
• メタデータは client でキャッシュする
• chunkserver は Linux 君が良きにキャッシュしてくれる。　Linux のファイルシステムの上に乗っかるのでこの辺は枯れた技術が使える。
• metadata
• これを小さくするのが大事！ master server でも client cache でも効く
• 64B for 64MB chunk
• 100TB chunk だと 100MB　のmetadata になりますな。
• 64GB memory だと 64PB ぐらいいけますかな。
• 64-B for namespace data for file
• ファイルのパスの圧縮も大事
• logging とか　chunk location の管理
• サーバ故障、chunkserver 故障などの対策は重要。
• 多少のダウン時間は許容する設計になっている。まあそういう用途向けってことか。
  

Section 3,4,5 はさほど興味ないので斜め読みした。情報を取りこぼしてる可能性あり。

感想：

• 重要そうなデザインに関する選択について
• chunk size = 64MB に関して
• メタデータを小さくオンメモりにするために大きく設定されている。
• デメリットもあるので、性能が低下しない範囲で小さくしたいところではある。
• お安い感じで、4GB を chunk 用 metadata に使えるとすると
• 4GB chunk-metadata = 4PB
• レプリケーションを４とすると 1PB ぐらいまでは余裕ですかね。
• 2桁PBぐらいで満足する人たちとは思えないが。
  
• single master server
• 故障時等のリカバリにかかる時間は結構長そうだ。この辺は今となっては課題だろうな。少なくともダウンタイムをほぼ０にしたいだろう。
• リクエストをさばくのが１台だけというのも問題になりえるか。
  
• chunkserver あたりのディスクが増えると、、、
• ディスク容量あたりのCPUパワー、メモリが減ることになる。
• Atom + 4G mem + 1TB SSD みたいな構成でいいのか？
• 全体として故障の影響が小さくなるような構成にして、現実や近未来のアプリケーションにあわせてCPUやメモリを積むんだろうね。まあ、どういう故障が起こるかの統計を持ってない以上、深読みに意味はないか

調べる前に気になっていた点：

• 今でも現役？
• まだ行けそうだが、そろそろつらいかもね。
  
• コスト比較
• まあ、NetApp と比較してもしょうがないか、という気がしてきた。
  
• MapReduce とかとの関係は？
• MapReduce はともかく、m-producer-1-consumer パターンを対象のワークロードとして作ってある。m-producer-1-consumer パターンと MapReduce の関係は、、、MapReduce ももうちょっと勉強するか。
  
• その手のフレームワーク？を使わない場合は、結構うまく使うのは大変に思える。ちょっとこの辺は要勉強だな。MapReduceの適用範囲とか、その他のフレームワークの可能性とか、逆に cloud application から求められる機能とか。BigTableとか。
  
• 一般人には必要ないもの？適用領域は？
• まあ、直接GFS　APIをたたくことはないだろうな。
• Open source になったところで、お家に置こうとは思えない。おうち用の分散ファイルシステムはもっと別の物だろう。その手のプロジェクトがきっとあるはず
• USB HDD をいっぱい刺せるとか、複数のNASをまとめて一つに見せるとか、そんなの。でもまだ先かな。Time Capsule ぐらいが現実解なのかも。
  
• データベースとの関係は？
• むー、まあ、使われ方をもうちょっと理解する必要があるな。super MySQL の土台に best match とは思えない。BigTable？
  

うーん、感想とか考察が幼稚だな。ま、もっと勉強を進めないとダメだな。まだよくわかってません。これが2003年だもんなー。今更論文読んでる自分が恥ずかしい、、。