グーグルのクラウドを支えるテクノロジー　＞　第4回　利用用途の分析からデザインされたGoogle File System（パート2）

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー ＞ 第4回 利用用途の分析からデザインされたGoogle File System（パート2） 」を公開しました。

はじめに
　前回のコラムでは、2003年に発表された論文「The Google File System」から、Google File System（GFS）について、システム全体の概要を紹介しました。今回は、高いスループットを実現するファイルアクセスの仕組みと、データの信頼性を担保する仕組みを解説します。

物理経路を意識した「直列書き込み」処理
　前回説明したように、GFSでは、1つのファイルは64MBのチャンクに分割されて、多数のチャンクサーバーに分散保存されます。この際、冗長化のために、1つのチャンクは複数のチャンクサーバー（デフォルトでは3箇所）に保存されます。3箇所に保存する場合であれば、マスターサーバーによって、それぞれのチャンクに対して、1台のプライマリーサーバーと2台のセカンダリーサーバーが割り当てられます。
　そして、例えば、クライアントがファイルに追記を行う場合、クライアントは、マスターサーバーからチャンクサーバーの情報を取得して、書き込み対象のデータを送信します。この際、図1に示すように、3台のチャンクサーバーに対して直列にデータを流します。つまり、1台目のチャンクサーバーは、クライアントからデータの受信を開始すると、そのデータをメモリー上のキャッシュに保存すると同時に、そのデータを即座に次のチャンクサーバーへと転送を開始します。3台のチャンクサーバーは、それぞれ異なるラックにあるため、クライアントに近い方から順に転送した場合、転送経路上のネットワークスイッチやNICは、その帯域をフル活用することができます。

fig01

図1 チャンクサーバーへのデータ送信経路

　仮に、クライアントが3つのチャンクサーバーに並列にデータを転送した場合、クライアントのNICからは、先の場合に比べて3倍のデータを転送する必要があり、ネットワーク転送速度は明らかに遅くなります。GFSを構成するクラスター環境では、IPアドレスのレンジからラックの位置関係がわかるようになっており、物理的なネットワーク経路を意識して、最適な書き込み順序を実現しています。ちなみに、イーサネットワークは全二重通信ですので、受信経路と送信経路は、同じNIC／ケーブルを用いても問題ない点に注意してください。
　また、3台のチャンクサーバーのキャッシュにデータを転送すると同時に、クライアントからは、プライマリーサーバーに対して、データ受信確認の問い合わせが送られます（図2）。これを受けたプライマリーサーバーは、さらに、セカンダリーサーバーに受信確認を行います。すべてのチャンクサーバーのデータ受信を確認すると、クライアントは、改めて、プライマリーサーバーに書き込みの指示を出します。すると、プライマリーサーバーは、キャッシュ上のデータをチャンクファイルに書き込むと同時に、セカンダリーサーバーにも書き込みの指示を出します。

fig02

図2 データの受信確認と書き込み処理

　また、複数のクライアントが、同一のチャンクに書き込み処理を行った場合は、プライマリーサーバーが書き込み順序の制御を行い、セカンダリーサーバーに対しても同じ順序で書き込みを行うように指示を出します。図1と図2を比較すると分かるように、実データの転送と、データの整合性を保証するための制御命令について、異なる通信経路が使用されています。現代的な用語で言えば、データプレーンとコントロールプレーンの分離と言ってもよいでしょう。

この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai2/nakai204.html