Googleを支える技術

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

第1章　Googleの誕生

1.1　よりよい検索結果を得るために

使う人にとっての便利を第一に考える
十分なハードウェアを用意する
Webページの順位付けに力を注ぐ
ランキング関数
1.2　検索エンジンのしくみ

下準備があればこその高性能
検索サーバは速度が命
検索バックエンドは事前の努力
インデックスは検索の柱
検索に適したインデックス構造
データ構造をインデックスする
1.3　クローリング -- 世界中のWebページを収集する

最も壊れやすいシステム
Webページを集めるには時間が掛かる
多数のダウンロードを同時に進める
終わることのないクローリング
1.4　インデックス生成 -- 検索用データベースを作り上げる

Webページの構造解析
単語情報のインデックス
リンク情報のインデックス
ランキング情報のインデックス
検索順位は検索するまでわからない
1.5　検索サーバ -- 求める情報を即座に見つける

検索結果に順位を付ける
複雑な検索も高速実行
ランキングの高速化は難しい -- 3段階のランキング
1.6　まとめ

第2章　Googleの大規模化

2.1　ネットを調べつくす巨大システム

安価な大量のPCを利用する
一つのシステムとして結び付ける
数を増やせばいいというものでもない
CPUとHDDを無駄なく活用する
検索エンジンを改良しよう
2.2　世界に広がる検索クラスタ

Web検索を全世界に提供する
近くのデータセンターに接続する
多数のサーバで負荷分散する
一定数のページごとにインデックスを分割
多数のインデックスを一度に検索
新しいWeb検索の手順
2.3　まとめ

第3章　Googleの分散ストレージ

3.1　Google File System -- 分散ファイルシステム

巨大なディスク空間を実現する
膨大なデータの通り道となる
データ転送に特化された基本設計
ファイル操作のためのインタフェース
ファイルは自動的に複製される
読み込みは最寄りのサーバから
書き込みは複数のサーバへ
同時書き込みで不整合が起こる
レコード追加によるアトミックな書き込み
スナップショットはコピーオンライトで高速化
負荷が偏らないようにバランスが保たれる -- マスタの役割
あらゆる障害への対策を行う
読み書きともにスケールする
データ管理の基盤として働く
3.2　Bigtable -- 分散ストレージシステム

巨大なデータベースを構築する
構造化されたデータを格納する
読み書きはアトミックに実行される
テーブルを分割して管理する
多数のサーバでテーブルを分散処理
GFSとメモリを使ってデータ管理 -- タブレットサーバ
テーブルの大きさに応じた負荷分散
さまざまな工夫によって性能を向上
使い方次第で性能は大きく変わる
大規模なデータ管理に利用されるBigtable
3.3　Chubby -- 分散ロックサービス

分散ストレージはここから始まる
5つのコピーが作られる
ファイルシステムとして利用する
ロックサービスとして利用する
イベント通知を活用する
マスタは投票で決められる
3.4　まとめ

第4章　Googleの分散データ処理

4.1　MapReduce -- 分散処理のための基盤技術

大量のデータを分散して加工する
キーと値でデータ処理を表現する
転置インデックスを作ってみる
MapReduceでできること
多数のワーカーによる共同作業 -- MapReduceの全体像
3つのステップで処理が進む
高速化には工夫が必要
実行過程には波がある -- MapReduceの過程
壊れたときにはやり直せばいい -- MapReduceにおける故障対策
驚きの読み込み性能 -- MapReduceの性能面
4.2　Sawzall -- 手軽に分散処理するための専用言語

分散処理をもっと手軽に
スクリプト言語のようなプログラム
副作用をもたらすことのない言語仕様 -- Sawzallの文法
標準で用意されるアグリゲータ
より実際的なプログラム例
エラーは無視することも可能
内部的にキーが生成されている -- Sawzallはどのように実現されているのか
スムーズにスケールする実行性能
4.3　まとめ

第5章　Googleの運用コスト

5.1　何にいくら必要なのか

少なからぬハードウェア費用
安価なハードウェアによるコスト削減
電気代はハードウェアほどには高くない
間接的に上乗せされる電力の設備コスト
増加傾向にある電力コスト
5.2　CPUは何に電気を使うのか

電力と性能の関係とは
CMOS回路の消費電力
消費電力を抑えるためにできること
クロック単位の処理効率を上げる
マルチコアによる性能向上
5.3　PCの消費電力を削減する

高クロックのCPUでは電力効率が悪い
マルチスレッドを生かして電力効率を上げる
電源の効率を向上させる
5.4　データセンターの電力配備

ピーク電力はコストに直結する
決まった電力で多くのマシンを動かしたい
電力配分を階層的に設計する
電力枠を使い切るのは難しい
マシンが増えれば電力も平準化される
省電力技術によりコスト効率が高まる
工夫次第で設備効率は二倍にもなる
5.5　ハードディスクはいつ壊れるか

10万台のハードディスクを調査する
故障の前兆となる要因は何か
長く使うと壊れやすくなるわけではない
よく使うと壊れやすくなるとも限らない
温度が高いほど壊れやすいということもない
いくつかのSMART値は故障率に大きく影響する
故障率に影響しないSMART値も多い
SMART値だけではいつ故障するかはわからない
ハードディスクと正しく向き合う
5.6　全米に広がる巨大データセンター

オレゴン州ダレス
ノースカロライナ州レノア
サウスカロライナ州バークレー郡
オクラホマ州プライア
アイオワ州カウンシルブラフス
次世代Googleのスケール感
データセンターに処理を集約させる -- Bigdaddy
5.7　まとめ

第6章　Googleの開発体制

6.1　自主性が重視されたソフトウェア開発

選ばれたプロジェクトだけが生き残る
少人数からなるプロジェクトチーム
コードレビューにより品質を高める
早い段階から性能について考えられる
新しいWebサービスが始まるまで
情報は徹底して共有する
6.2　既存ソフトウェアも独自にカスタマイズ

オペレーティングシステム
プログラミング言語
データベース
SCM（ソースコード構成管理）
レビューシステム
6.3　テストは可能な限り自動化する

プロジェクト横断的なチーム
自動テストを想定した設計を行う
基盤システムをテストする -- Bigtableの例
6.4　まとめ

グーグル先生、すげぇよ。

すげぇけど、その技術はほとんど謎のベールに包まれているもんだからよくわからない。
良くわからないけど、「どうやら発表されている技術レポートによるとこういうことらしい」ってのをまとめたのが本書。

やっぱり、グーグル先生は世界を支配しようとしてるイメージがあるなぁ。

でも、そんなグーグル先生も数台のサーバーからはじまったって事を考えるとなかなか感動的。

たんなる検索じゃなくてユーザーが欲しがっている情報を提供するっていうのは、画期的だったんだろうな。

ページランクとかのアルゴリズムも、いかにスパム等を減らして、もっともいい情報を提供するか？
をもとに組み立てられているらしいし。

求められるものを提供してきたグーグル先生はやっぱり素敵。