「Googleを支える技術」
Googleを支える技術 ~巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)
posted with amazlet at 08.04.09
西田 圭介
技術評論社
売り上げランキング: 1406
技術評論社
売り上げランキング: 1406
1年ちょっと前、「グーグルが従業員を子供扱いすることでつなぎとめている件」というエントリーが一部でちょっとした話題になった。これを読んで、技術者の待遇について論じる人もいれば、「GFS(Google File System)の信頼性のなさ」という部分に反応する人もいた。
本書は、後者のような、GFS・Bigtable・MapReduce萌えな人が楽しめる本。Googleの技術者たちが書いた論文や公開資料を元に、主に分散処理の技術について、詳しくかつ平易な言葉で解説している。私のような非技術者にとって、各要素技術についてそれぞれ意味やメリットを説明しているところがありがたい。IT系名編集者の星さんが本書の企画に嫉妬しているけど、まったくだ。
ちなみに本書によると、上記の信頼性に対するGoogleの考えは、ハードウェアよりソフトウェアでの対策で動き続けるようにするというものだそうだ(本書pp.44〜45あたり)。
ちょうどGoogle App Engineがオープンしたし、Bigtableでいろいろ試すのも楽しいんじゃないでしょうか。
以下、自分のまとめとふりかえり。
- 初期の検索システム
- 単語インデックス、転置インデックス:Barrels
- ランキングは検索ごとに行わせる
- 検索システムの大規模化
- wordID切りでのインデックス分割から、docID切りでのインデックス分割へ
- 同じwordIDによる検索を分散する:shard
- wordID切りでのインデックス分割から、docID切りでのインデックス分割へ
- GFS(Google File System)
- 分散ファイルシステム
- 最低数百MBの大きなファイルが対象
- ロック機構なし
- キューになった追記が書き込みの基本
- 読み込みは最寄りから、書き込みは複数のサーバーへ
- 失敗したら成功するまでやりなおす
- コピーオンライトによるスナップショット
- Bigtable
- 自在な多元キーによるハッシュのような、一種のデータベース
- タイムスタンプを持つ
- データ型はない(BLOB相当)
- GFS上
- タブレットサーバーという単位で分散される(100〜200MB程度)
- 読み込み専用のSSTableから構成
- インデックスがメモリ上のmemtableに
- 書き込みはGFS上のコミットログ+memtableに
- memtableが大きくなると新しいSSTableに書き出される:マイナーコンパクション
- SSTableが増えすぎたら1つのSSTableに統合:メジャーコンパクション
- Chubby
- ロック機構のあるファイルシステム/データベース
- 大部分のデータは1KB未満
- Windowsのレジストリのようなもの
- 元はBerkeley DB上で実装
- GFSのデータのロックにも利用
- 内部のDNSがわりにも
- MapReduce
- 分散データ処理技術
- Map:各ノードで適用するフィルターのようなプロセス
- シャッフル:MapからReduceに行く前に、各ノードのデータをまとめる
- Reduce:各ノードの値を集計するプロセス
- Sawzall
- MapReduceを簡単に実行するためのDSL
- フィルタとアグリゲータを定義する
- 静的型
- 副作用なし
- アグリゲータは(Sawzallレベルでは)既存のものを指定
- 運用コスト
- マシン代がいちばん
- 電気代はハードウェアほどではない
- が、電力設備コストは大きい
- CPUの消費電力傾向もGoogleの実例からわかる
- インデックスサーバーは分岐予測ミスが多く、高クロック多段パイプラインのCPUは不利
- マザーボードの電源を12Vに統一することで電源ユニットのロスを劇的に減らす
- 種類の違うサーバーを同じPDU(電源ユニット)に配置することで、ピーク電力をならす
- HDDの故障傾向もGoogleの実例からわかる
- 使用期間、頻度、温度と故障の相関関係は高くない
- スキャンエラーやリアロケーション数は故障と相関関係が高い
- が、故障予測に使えるほどではない
- シークエラー、CRCエラー、パワーサイクル、振動とは相関関係は高くない
- 全米の大規模データセンター
- その土地の電力の価格や供給量に特色?
- 新しいクローラBigdaddy
- Web検索、ブログ検索、Google Newsなど複数のクローラのためのプロキシ
- 2006年時点で800TBのデータ
- User-AgentをMozillaにしてgzip圧縮が効くように(Accept-Encodingじゃなくて?)
コメント
コメントの投稿
トラックバック
http://emasaka.blog65.fc2.com/tb.php/384-72429c02

