Google File System に関するインタビューのサマリ

ACMのacmqueueにGFS: Evolution on Fast-forwardと題した興味深い記事があったので，サマリをメモしておく．Berkeley FSの設計をしたKirk McKusickと，GFSのリードであるSean Quinlanの対談．

GFSはシングルマスタ

GFSは大規模なシステムであるにもかかわらず，マスタが単一である．これはスケーラビリティに大きな影響を及ぼすだけでなく，単一障害点となりうる．この設計は，とりあえず利用できるものを短期間で作成するためになされたものであり，当時想定されていた用途では，それで十分なはずでもあった．

問題は，ストアされるデータの容量が増え何十テラバイトにもなったときに起こった．メタデータの容量が比例して大きくなってしまい，リカバリ時にメタデータをスキャンする際にも時間がかかるようになった．さらに，クライアントにとってもメタデータ操作がボトルネックになるようになった．例えばMapReduceのような枠組みを使うと，数千のタスクが同時に起動してファイルをオープンしようとするため，問題が起きやすい．

GFSがシングルマスタでも問題なかった理由の一つは，バッチ型のアプリケーションを対象としていたから．マスタが落ちた際に再起動してもそれほど問題にはならなかった．現在ではレイテンシ指向のアプリケーションが増えているので，これは許されない．

昔はGFSのマスタのフィエルオーバは手動で，しかも1時間ぐらいかかっていた．現在では数10秒程度．

マルチセルアプローチ

一つのチャンクサーバプールに対して，複数のGFSマスタを配置すること．個々のGFSマスタは別の「セル」を担当することになる．どの「セル」を選択するかは，アプリケーションが判断しなければならない．

個々のアプリケーションが特定の「セル」を利用することもあるし，静的な名前空間を切り分けてセルに割り当てて，複数のセルを利用することもできる．

Gobioff の名台詞

Because we built everything, we were free to cheat whenever we wanted to. We could push problems back and forth between the application space and the file-system space, and then work out accommodations between the two.

かくありたい物だ．

チャンクサイズとファイル数

GFSのチャンクサイズ はもともと64Mバイト．これは，初期のアプリケーションがクロールしたデータと，インデックスだったため．アプリケーションミックスの変動によって，小さいファイルをたくさん保持することになった．各ファイルはそれぞれメタデータを持ち，メタデータは，マスタのメモリ上に保持される．したがって，ファイル数が増えることは，マスタのメモリを多く消費することを意味する．

これをさけるために，アプリケーションの側で，複数のオブジェクトをまとめて一つのファイルにしなければならないこともあった．これは，ログのような追記のみのアプリでは比較的簡単だったが，オブジェクトを消去しなければならないようなアプリケーションでは，GCのようなことをしなければならないので大変.

ファイル数問題とBigTable

ファイル数問題を解決するための方法としてBigTableを使うことができる．BigTableはバックエンドとしてGFSを利用している．BigTableには遥かに多彩な機能があるが，GCはそれほど積極的に行わないので、容量の利用率は高くならない．

BigTableでトランザクションログをとる際には，2つのファイルを同時にオープンし，一つへの書き込みに時間がかかった際には、別のファイルに書き込む．リプレイ時にはこれらのファイルをマージする．このようにして，本来レイテンシ指向ではないGFSをレイテンシ指向のアプリケーションから利用している．

GFSとGmail

あるGmailアカウントの処理が滞ったら，そのアカウントの処理を別のデータセンターに移してしまう．この機能はアベイラビリティのためにいずれにしろ必要なのだが，GFSの問題を隠すためでもある．

分散マスタ GFS

まったく新しく作り直そうとしている．数百のマスタを持ち，それぞれのマスタが数億のファイルを保持できる．これでファイルサイズの平均が1MBになってもそれほど問題は無い．

すでに2年間開発が続いているようだ．