Google File System

入院中に読んだ paper, 今さらだけど覚書。

Google のデータ処理アプリケーションによるファイルシステム利用特性を踏まえた上で、分散ファイルシステムを再設計してみましたという話。

利用特性

• ファイルサイズは100MB～数GB程度が中心。小さなファイルも使用できる必要はあるが、最適化の対象外。
• 読み出しのワークロードは、主に大きな連続読み出し（一度に数100KBから1MB以上、往々にして連続して次の領域読み取りが続く）と、小さなランダム（指定オフセット値からの数KB)読み出し。
• 更新のワークロードは、主に大きな追記（一度に数100KBから1MB以上、往々にして連続して次の追記が続く）。
• 複数クライアントからの同時アクセスが多く、特に同一ファイルへの並列追記処理を効率的に行う必要あり。
• 帯域重要、レイテンシはさほど重要ではない。

この前提の下、さらに使用するハードウェアは低価格な汎用品、具体的には一般的なPCとローカルHDD, あとは Fast Ethernet, GbE の組み合わせて実現したいというリクエストあり。

利用特性を見ると、確かに一般的なファイルシステムへの要求とはずいぶんと違っている。

汎用のファイルシステム、たとえば NTFS とか FFFS だと、既存の API (Win32 API, POSIX) をサポートすることや大量の小さなファイルを効率的に扱うことやレイテンシなどが重要になる一方で、同時に複数クライアントから追記要求がきた場合に効率的に処理することなどは想定外。また、対障害性などはファイルシステムレベルでも当然考慮はするが、ある程度以上となったら、その下のハードウェア層でもRAIDを組むなどの対策を組むことが前提となる。

私は分散ファイルシステムはあまり知らないのだけど、ローカルファイルシステムのセマンティクスをなるべく崩さずにネットワーク対応させた NFS, CIFS なんかとは明らかに違うし、最初から壊れるマシンがいること前提なあたり AFS とも大分違う。対故障性や帯域重視というと RDBMS も考えられるが、今度は想定されるワークロードにズレがある。

paper では、以上の前提を述べた上で GFS のアーキテクチャと設計について解説している。前提が違うので、結果としてアーキテクチャもラディカルに違ったものになっているが、利用している個々の技術やアルゴリズムはきわめて一般的。読んで難しいところは何もない。

アーキテクチャ設計とバランス感覚が秀逸だね。個人的には、こういうシステム好きだ。

追記

読みかけの「Distributed Systems: Principles and Paradigms 2nd Ed.」 Chaper 11 で分散ファイルシステムが取り上げられているので、ちょっと途中スキップして覗いてみたら 11.1.2 Cluster-Based Distributed File Systems で Google File System (GFS) 取り上げてる。

タネンバウム本に載ってるということは、分散屋さんの間ではもはや常識なのか。