2008年3月27日

西田圭介 / Googleを支える技術 - 巨大システムの内側の世界

いつもお読みいただきありがとうございます。

たつをのChangeLogさんにエントリーされていました。

西田圭介 / Googleを支える技術 - 巨大システムの内側の世界
は、そろそろ出るみたいですが、読みたいですね。

目次


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


すべての章が興味深いですが、やはり、第6章 Googleの開発体制が読んでみたいですね。
というわけで、購入決定!^^;

いずれも、パブリックな論文やWebから情報をひっぱってきているようで、本にするのは無理でも技術リサーチはできそうですね。

グーグルの論文は、ここに公開されていますね。

0 件のコメント: