目次
第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の例
