西田圭介「Googleを支える技術」

GFS論文もMapReduce論文もBigTable論文もすべて途中で挫折した自分にとってはぴったりの本。色んな人が書評しているということもあり早速買ってみた。
1章まで読んだけど、ちょっと平易に書きすぎていて技術的にもっと面白いところが省略されすぎているような気がした。途中で挫折した割りには偉そうな感想ですが。

読み終えたら後で感想を書くこと。
(2008/08/29追記)
ようやく感想、というか理解メモをまとめてみた。

    • Googleの大規模化
      • wordID(単語)ではなく docID(ページ)によってインデックスを分割。この個々のインデックスは sharedと呼ばれる。
    • Googleの分散ストレージ
      •  GFS(Google File System)
        • 大量のデータ(最低数百MB)を 1つのファイルに詰め込んで、あとは読みだすだけという用途に特化。書き換えには向いていない。
        • ロック制御はなし。ファイルの末尾にレコードを追加。
        • 1台のマスタと複数のチャンクサーバで構成
        • GFSのファイルは 64MBを 1ブロックとするチャンクに分割
        • 1チャンクは 3つのチャンクサーバにコピー
        • write時は同じレコードが複数回追記される可能性があることを許容
        • スナップショットは、チャンク情報のコピーだけ。チャンクに変更が発生したタイミングでチャンク自体のコピーが発生する。
      • Bigtable
        • 小さいけれど大量のデータを読み書きするための分散ストレージシステム。データベースみたいなもの。
        • 列は行キーとカラムファミリーで構成
        • 行キーは行を特定できるキー。プライマリキーみたいなものか。
        • カラムファミリーは横にいくつでも伸ばせる。さらにそれぞれのセルはタイムスタンプで区別できる過去のデータを保持できる。すなわち縦方向(というか高さ、z軸)にもデータが伸びていくイメージ。
        • テーブルは複数の行を 1つの単位として分割。個々の単位は tabletと呼ばれる。
        • 1台のマスタと複数のタブレットサーバから構成。実際のデータそのものは GFSに置かれる。タブレットサーバはタブレットの管理のみを行う。
        • tabletの大きさは 100〜200MB程度。GFSのチャンクとは異なり、1つの tabletは 1つのタブレットサーバに割り当てられる(実体は GFSで複数管理されているけどね)。
        • 排他制御は Chubbyと呼ばれるサービスで実現。後で出てくる。
        • tablet自体も Bigtableで階層管理されている。深さは 3階層。
      • Chubby
        • 小さな分散ファイルシステム。
        • 大まかに言うと、ファイルシステム、ロックサービス、イベント通知の機能を備えたシステム。
        • 大部分は 1KB未満のファイル。ファイルシステムというよりは Windowsのレジストリに近いイメージ。
        • 5台のマシンから構成。Chubbyセルと呼ぶ。各マシンはレプリカと呼ばれ、すべてが同等のデータを保持する。1台がマスタとして機能するが、もちろん他のマシンもいつでもマスタとして動作することが可能。
        • Googleでは Chubbyを DNSの代わりとして広く利用。
    • Googleの分散データ処理
      • MapReduce
        • 分散データ処理技術
        • Mapと Reduceという 2つの方法の組み合わせ。
        • Mapはキーと値のペアから、新しいキーと値のペアからなるリストを作る。
        • Reduceはそのリストから同じキーの値を統合し、スカラーを生成する。
        • 開発者は Mapと Reduceの処理ロジックのみを記述すればよく、実際の分散処理は MapReduceが勝手にやってくれる。
      • Sawzall
        • 分散処理用専用言語。静的手続き型。
        • データベースにおける SQLの存在と似ている。GFSにおける Sawzall。
    • Googleの運用コスト
      • ハードディスクはいつ壊れるか
        • 長く使うと壊れやすくなるわけではない。
        • よく使うと壊れやすくなるわけでもない。
        • 温度が高いほど壊れやすいということもない。
        • SMART値のうち、スキャンエラー、リアロケーション数、オフラインリアロケーション、リアロケーション前のセクタ数の 4つは故障率に大きく関連がある。
        • とは言っても、割合としては何の手がかりもなしにいきなり壊れるドライブのほうが多い。上記の 4つの値が見られたものに限ると、全体の半分にも満たない。
        • したがって壊れるものは使い始めてすぐ壊れてしまい、生き残ったものは利用頻度に関係なく動き続ける、と言える。
    • Googleの開発体制
      • コードレビュー必須。
      • ドキュメントを書くことを重視。
      • ソースコードは SCMで管理。Perforceを使用。
      • すべての開発者は Googleレジュメ(履歴書)を書く。また snippetと呼ばれる週報も書くことになっている。
      • テストは専門のテストエンジニアが担当。可能な限り自動化させる。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください