GFS：故障を前提に巨大ファイルを扱う分散ファイルシステム

この論文が解いた問題

横にスクロール

2000年代初頭のGoogleは、Web全体をクロールした膨大なデータを保存し、検索インデックスの構築のような巨大な処理を日々走らせていた。扱うデータは数百テラバイト規模に達し、それを支えるのは高価な専用ストレージではなく、安価なコモディティサーバーを何千台も並べたクラスタだった。既存の分散ファイルシステムは、この規模とこの前提に噛み合わなかった。

GFSの論文（Ghemawat・Gobioff・Leung、2003年）が非凡なのは、ファイルシステムの「当たり前」を一度すべて疑ったことにある。彼らが置き直した前提は4つだ。

第一に、故障は例外ではなく常態である。数千台ものコンポーネントを並べれば、ディスク・メモリ・ネットワーク・電源のどれかが常に壊れている。したがって耐障害性と自動回復は、後付けの機能ではなくシステムの土台に据えるべきものになる。

第二に、ファイルは巨大である。数キロバイトの小さなファイルを何十億個も管理するのではなく、数ギガバイト級の大きなファイルに多数のオブジェクトを詰め込むのが実態だった。設計はこの大きなファイルに最適化すればよい。

第三に、書き込みの大半は既存データの上書きではなく末尾への追記である。いったん書かれたファイルは、その後はほとんど順次読み出しされるだけだった。

第四に、アプリケーションとファイルシステムを一緒に設計できる。APIを自分たちの都合に合わせて作れるなら、POSIXの厳密な整合性を捨て、性能と単純さを取る余地が生まれる。

これら4つの前提は、それぞれが独立した思いつきではない。安価なコモディティサーバーを大量に使うという出発点から、故障の常態化も、巨大ファイル前提も、追記中心のワークロードも自然に導かれる。既存のファイルシステムが「信頼できるハードウェアの上で、多数の小さなファイルをPOSIXどおりに扱う」ことを暗黙に仮定していたのに対し、GFSは仮定そのものを現実のワークロードへ合わせて組み直した。解くべき問題を定義し直したことこそが、この論文の最初の、そして最大の貢献である。

核心アイデア

GFSの構成はきわめて明快だ。システムは、メタデータを一手に握る単一のマスタと、実データを保持する多数のチャンクサーバーからなる。

ファイルは64MBという大きな固定サイズの「チャンク」に分割される。各チャンクにはグローバルに一意なIDが振られ、既定で3つの複製が別々のチャンクサーバーに分散して置かれる。たとえ複数台が同時に壊れても、残った複製がデータを守る。マスタはチャンクサーバーと定期的にハートビートを交換して状態を監視し、複製数が既定を下回れば自動的に新たな複製を作り直す。故障を前提に据えるとは、こうした仕組みを標準装備することだ。

ここで決定的なのは、マスタがデータの通り道に立たないことである。マスタが持つのは名前空間、ファイルからチャンクへの対応、各チャンクの配置といったメタデータだけで、実データのバイト列には一切触れない。クライアントはまずマスタに「このファイルのこの位置はどのチャンクサーバーにあるか」を問い合わせ、以降は該当するチャンクサーバーと直接データをやり取りする。こうしてマスタは制御に専念し、帯域を食う実データ転送はチャンクサーバー群へ水平に分散される。

この分離は読み出しの流れに端的に表れる。クライアントはファイル名とチャンク番号でマスタに問い合わせ、対象チャンクの複製がどのチャンクサーバーにあるかを受け取る。この対応はしばらくキャッシュされるため、同じチャンクを続けて読む間はマスタへ再び問い合わせる必要がない。実際のバイト列は、選んだチャンクサーバーとの間だけを流れる。マスタ1台に全クライアントのデータ転送が集中する事態は、こうして構造的に避けられている。

64MBという大きなチャンクサイズも、この設計を支えている。一般的なファイルシステムのブロックが数キロバイト程度なのに比べ、GFSのチャンクは桁違いに大きい。チャンクが大きいほど、同じ容量を表すのに必要なメタデータの総量は小さく保たれ、マスタはクラスタ全体の情報を扱いやすくなる。クライアントがマスタへ問い合わせる回数も減り、一度の問い合わせで長い範囲を読み書きできる。小さなファイルを大量に扱う用途では無駄が出うるが、巨大ファイルを順次読み書きするというGFSの前提では、この大きさがちょうど噛み合う。

さらにGFSは整合性モデルをあえて緩めた。その目玉が「アトミックな追記（record append）」で、複数のクライアントが同じファイルへ同時に追記しても、各レコードが最低1回はまるごと書かれることだけを保証する。書かれる位置やバイト単位の一致までは約束しない代わりに、重いロックなしに高いスループットを引き出す。追記中心という割り切りが、この単純化を許した。

故障への回復も、この構成の上で淡々と回り続ける。マスタは各チャンクの複製がいくつ生きているかを把握しており、あるチャンクサーバーが応答しなくなって複製が既定の3つを割り込めば、別のチャンクサーバーへ複製をコピーして数を戻す。どのチャンクをどこに置くかという配置の判断もマスタが握り、特定のサーバーに負荷や複製が偏らないよう分散させる。こうして個々の故障は、運用者が夜中に駆けつける緊急事態ではなく、システムが自律的に吸収する日常の一コマになる。冒頭の「故障は常態」という前提が、ここで具体的な仕組みへと結実している。

その後の影響

GFSが与えた影響は、一つの社内システムの枠をはるかに超えた。

最も直接的な継承者が、Apache HadoopのHDFS（Hadoop Distributed File System）だ。マスタに当たるNameNode、チャンクサーバーに当たるDataNode、64MBチャンクに当たるブロックと、対応はほとんど一対一で、GFS論文の設計をオープンソースで再現したものと言ってよい。これによりGFSの思想は、Googleの外の無数の企業へ広まった。

GFSはまた、Googleの主要な基盤の土台にもなった。大規模な並列処理を担うMapReduceは、GFS上に置かれたデータの近くで計算を走らせることで、ネットワーク転送を抑える。構造化データを扱うBigtableも、その永続化の実体をGFSに預けている。GFSという土台があってはじめて、その上のレイヤーが成立した。

そして何より、「安価なサーバーを複製で束ね、故障を前提に耐える」という設計思想そのものが、その後の大規模データ基盤の共通言語になった。高価で壊れない一台に頼るのではなく、壊れる前提の多数をソフトウェアと複製で束ねる——スケールアウトという言葉が当たり前になった今から振り返れば当然に見えるこの発想を、実運用の規模で最初に示したのがGFSだった。今日のクラウドストレージやデータレイクの根底にも、GFSが実証したこの考え方が流れている。

まとめ

GFSの本質は、新しいアルゴリズムの発明ではなく、前提の置き換えにある。故障は常態、ファイルは巨大、書き込みは追記が中心——現実を正しく見据えたうえで、単一マスタと64MBチャンクの3複製、そしてマスタをデータの通り道から外すという構成で、それに応えた。制御とデータを分離し、整合性を賢く緩めるこの割り切りは、HDFSへ受け継がれ、MapReduceやBigtableの土台となった。分散システムを支える論文をさらに辿るには、論文で辿る分散システムの一覧から次の一本へ進みたい。