Googleを支える技術……巨大システムの内側の世界（技術評論社） [電子書籍]

Googleを支える技術……巨大システムの内側の世界（技術評論社） の 商品概要

• たとえば，ふだんなにげなく行っているWeb検索。背後には，想像以上に膨大な計算，多数のコンピュータの働きがあります。
  
  本書では，論文やWebなどで公開されているパブリックな情報をもとに，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　まとめ
  

Googleを支える技術……巨大システムの内側の世界（技術評論社） の商品スペック