前回はGoogleの分散システムのうち、大規模化に伴うスケールアウト戦略と検索クラスタについてまとめた。今回は大量の情報をどのように保存・管理しているかという、分散ストレージについて解説する。 すなわちGFS、Bigtable、Chubbyの３つである。
１ Google File System—分散ファイルシステム
分散ファイルシステムとは、多数のマシンを組み合わせて巨大なストレージ（外部記憶装置）を作り上げる技術である。この巨大なディスク空間を実現するために、Googleが独自に開発したのがGFS（Google File System）である。
GFSは、ネットワークを通してファイルを読み書きするためのシステムである。GFSにおける１つのファイルは、ハードディスクに収まらないほど大きくすることができるため、膨大なデータの通り道となる。
基本設計
GFSはまた、データ転送に特化された基本設計をしている。ソフトウェアによる障害対策、大容量のファイルの読み書き、ファイルをキュー（待ち行列）として用いるといったものである。
GFSのファイル操作のためのインタフェースとしては、専用のコマンドを用いるか、クライアント用ライブラリを使用する。その機能は読み込み、書き込みのほかスナップショットやレコード追加などがある。スナップショットはコピーライトで高速化されているため、非常に少ないコストでファイルのコピーを作ることができる。
GFSの３要素
GFSは大きく分けて３つの要素から構成されている。まず、マスタはGFS全体の状態を管理しコントロールする中央サーバである。マスタの管理下には多数のチャンクサーバがあり、これらが実際にハードディスクへの入出力を担当する。最後にクライアントはGFSを利用してファイルを読み書きするアプリケーションである。個々のチャンクは、通常３つのチャンクサーバに自動的に複製される。特にマスタには、負荷が偏らないようにバランスを保つ重要な役割がある。
読み込み・書き込みの特徴
読み込みは最寄りのサーバから行われ、書き込みは複数のサーバへ実施される。しかし、同時書き込みで不整合が起こることがある。この不整合を防ぐためには、書き込みの順番を保証するロック機構が必要だが、GFSではそれを提供していない。その代わりにレコード追加によるアトミックな書き込みを可能にしている。ファイルの末尾にひとまとまりのデータを効率的に追加するように設計されているのである。
障害への対策
最後に、GFSはチャンク、チャンクサーバ、マスタといったあらゆる障害への対策を行っている。その性能は読み書きともにスケールし、データ管理の基盤として働いているため、Googleにとってなくてはならない技術である。
２ Bigtable—分散ストレージシステム
GFSは大量のデータを一度に扱うのには向いているが、小さなデータの読み書きには不向きである。そのため巨大なデータベースとして構築されたのが、Bigtableである。
RDBとの最大の違いはデータモデル
Bigtableが既存のRDB（Relational Database）と比べて決定的に異なるのは、そのデータモデル（データをどのように格納するか）である。RDBよりも複雑なテーブル構造（多次元マップ）を持ち、構造化されたデータを格納することを特徴とする。つまりBigtableでは、「行キー」「コラムキー」「タイムスタンプ」の３つを指定することで、１つのデータが得られるのである。
抽象化の実例
実際の使い方として、読み書きがアトミックに実行されるようになるRowMutationとScannerという抽象化（実行の詳細を隠して開発者に見せないようにする手法）が公開されている。また、Bigtableではテーブルを分割して管理されている。
Bigtableの３要素
Bigtableも基本的に３つの要素から構成されている。全体を統轄するマスタ、タブレットを管理するタブレットサーバ、そしてデータを読み書きするクライアントである。Bigtable全体にかかわる基本的な情報は、Chubbyと呼ばれるロックサーバによって管理されている（次回詳述）。
マスタは多数のサーバでテーブルを分散処理しており、タブレットサーバはGFSとメモリを使ってデータ管理をしている（SSTable、memtableの活用）。また、テーブルの大きさに応じた負荷分散になるように調整されている。さらに、ローカリティグループ、データの圧縮、読み込みのキャッシュ、コミットログの一括処理といったさまざまな工夫によって性能を向上させている。
このように、Bigtableは使い方次第で性能は大きく変わるため、現在でも改善が進められている。データベースと同等の役割を果たすことができ、大規模なデータ管理に利用できるBigtableは、今後もより便利で大規模な分散ストレージシステムへと発展を遂げるだろう。
３ Chubby—分散ロックサービス
Chubbyは小容量ながらも、高い信頼性といくつかの便利な機能を提供する分散ストレージである。単体で使われるだけでなく、GFSやBigtableなどの他の分散システムを構築するための基盤としても用いられている。
分散ストレージはここから始まる
Chubbyの提供する機能は「ロックサービス」と呼ばれている。これは分散システムにおいて排他制御（ロック）を行うしくみである。複数のシステムが共通のリソース（同一のファイルなど）を利用するときには、データが壊れることのないように排他制御を行わなければならない。
５つのコピーが作られる
Chubbyは通常、５台のマシンから構成される。この集まりを「Chubbyセル」と呼ぶ。セルの各マシンは「レプリカ」と呼ばれ、そのすべてが同等のデータベースを保持している。レプリカの中から全体をまとめる「マスタ」が選ばれるが、すべてのレプリカは同じデータを持っているので、いつでもマスタになることができる。
Chubbyの持つ３つの機能
第一に、ファイルシステムとしてのインタフェースを持ち、GFSと同様にファイル名を使ってデータへとアクセスできる。特別なセル名としてlocalとglobalという２つの名前があり、前者が今いる場所、後者が世界中からアクセス可能なChubbyセルを表している。Chubbyではマスタがすべてのデータを保持しており、ファイルの読み書きはすべてマスタに対して要求している。
第二に、ロックサービスとして利用することができる。すべてのChubbyファイルはロックすることが可能であり、これによって他の分散システムは起動時の排他制御の問題を解決することができる。ファイルのロック（共有ロック／排他ロック）、外部リソースのロック、シーケンサによる保護、フェイルオーバー（サーバに障害が発生した場合に、代替サーバが処理やデータを引き継ぐ機能）といった様々な工夫がされている。
第三に、イベント通知を活用することができる。Chubbyファイルを作成したり、その内容を書き換えると、それを監視しているクライアントにイベント（特定の現象が発生した時に発する信号）を送ることができる。また、Chubbyファイルを読み込むと、その内容はクライアント側でキャッシュされるようになっている。
Chubbyにはこういった便利な機能が備えられているため、今やGoogleではChubbyをDNSの代わりとして広く用いられている。
マスタは投票で決められる
前提として、マスタが選ばれるためには、半数以上のレプリカがつながっていなければならない。つまり、Googleの分散システムが正常に機能するには、常に３つ以上のレプリカと通信できる状態でなければならない。
Chubbyのマスタは、レプリカ自身の合意によって決定される。この１つの合意に達するための方法をコンセンサスアルゴリズムといい、Chubbyでは「Paxos」と呼ばれる方法が用いられている。Paxosでは、提案→約束→受託→承認という４つのプロセスを経て、合意が形成される。しかし、毎回Paxosを実行すると手間がかかるため、マスタリースと呼ばれる一定の時間が与えられ、いきなり「受託」から始めることで時間短縮を図っている。
最後に
GFSは大量のデータを効率よく転送し、安全に保管するよう設計された分散ファイルシステムである。BigtableはGFSを利用しながら、小さなデータでも効率的に読み書きできるようにした分散ストレージである。Chubbyはこうした分散システムのさらに基盤となるシステムで、排他制御の行える小さなファイルシステムを提供する。
Googleはさまざまなサービスを提供するために運営しているデータセンターについて、その外部や内部、携わっている従業員などを多数の写真で紹介するギャラリー サイトを10月17日に開設した。同社がデータセンター内部の様子を公開するのは、これが初めてとのことである（参考記事）。
大量のコンピュータを活用するこうした基盤システムの支えがあってこそ、Googleという世界規模の検索エンジンは実現されている。
次回は分散データ処理についてまとめる。
 |
