グーグルが構築した大規模システムの現実、そしてデザインパターン（3）～教訓編
グーグルが「Evolution and Future Directions of Large-Scale Storage and Computation Systems at Google」（グーグルにおける、大規模ストレージとコンピュテーションの進化と将来の方向性）という講演を、6月に行われたACM（米国計算機学会）主催のクラウドコンピューティングのシンポジウム「ACM Symposium on Cloud Computing 2010」で行っています。
講演の内容を4つの記事（MapReduce編、BigTable編、教訓編、デザインパターン編）で紹介しています。この記事はBigTable編の続き、教訓編です。
大規模分散処理システムの構築から学んだこと
ここからは、グーグルがたくさんのシステムを経験して学んだことと、それらのデザインパターンなどを紹介していきたい。
まず、大きく複雑なシステムを開発する場合には、それを多くのサービスに分解することだ。
システムの構造からみると、分解したサービスの依存が少ない方がそれぞれのテストや運用が容易になるし、ほかのシステムがダウンしたときにも影響が少ない。テストと運用も容易になる。
実はグーグルはこの10年で7回くらいWeb検索システムを作り直しているが、APIは変化していないため、ほかに影響を与えていない。
また、それぞれのサービスの開発サイクルを切り離すことも大事だ。
そうするためには、サービスのインターフェイスを定義する何らかの言語が必須だ。そこで私たちが使っているProtocol Buffersの例を紹介しよう。
グーグル内部では、いくつかの言語ではこのプロトコルバッファの自動ラッパーがある。
Protocol Bufferは高速で、バイナリフォーマットを使っている。構造化されたドキュメントもメッセージも扱える。オープンソースバージョンもある。
性能の見積もりのために基本構造を知る
サービスを作るとき、パフォーマンスの見積もりをしなければならない。そのためには、コンポーネントごとにかかる処理時間を把握しておかなければならないだろう。
例えば30枚のサムネイル画像を含むイメージサーチを作ろうとするとき。2つのデザインが考えられる。シリアルに読み込むか、パラレルに読み込むかだ。見積もりのテクニックが分かっていれば、それぞれにどれだけ時間がかかるか容易に把握できる。
システムを構成する基本的なブロックの中身をよく知ること。BigTableのうえでサービスを構築するなら、BigTableのことをよくしらなければ、システムの見積もりをすることが困難だろう。
次回は最終回、大規模システム構築におけるデザインパターンを紹介するデザインパターン編です。
