第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　まとめ