グーグルが構築した大規模システムの現実、そしてデザインパターン(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

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

あわせて読みたい

クラウド Google データセンター




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

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

最新記事10本