グーグルが構築した大規模システムの現実、そしてデザインパターン(3)~教訓編

2010年8月25日

グーグルが「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は変化していないため、ほかに影響を与えていない。

また、それぞれのサービスの開発サイクルを切り離すことも大事だ。

fig

そうするためには、サービスのインターフェイスを定義する何らかの言語が必須だ。そこで私たちが使っているProtocol Buffersの例を紹介しよう。

グーグル内部では、いくつかの言語ではこのプロトコルバッファの自動ラッパーがある。

fig

Protocol Bufferは高速で、バイナリフォーマットを使っている。構造化されたドキュメントもメッセージも扱える。オープンソースバージョンもある。

fig

性能の見積もりのために基本構造を知る

サービスを作るとき、パフォーマンスの見積もりをしなければならない。そのためには、コンポーネントごとにかかる処理時間を把握しておかなければならないだろう。

fig

例えば30枚のサムネイル画像を含むイメージサーチを作ろうとするとき。2つのデザインが考えられる。シリアルに読み込むか、パラレルに読み込むかだ。見積もりのテクニックが分かっていれば、それぞれにどれだけ時間がかかるか容易に把握できる。

fig

システムを構成する基本的なブロックの中身をよく知ること。BigTableのうえでサービスを構築するなら、BigTableのことをよくしらなければ、システムの見積もりをすることが困難だろう。

fig

次回は最終回、大規模システム構築におけるデザインパターンを紹介するデザインパターン編です。

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Google , クラウド , データセンター



≫次の記事
グーグルが構築した大規模システムの現実、そしてデザインパターン(4)~デザインパターン編
≪前の記事
グーグルが構築した大規模システムの現実、そしてデザインパターン(2)~BigTable編

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus