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

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

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

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




タグクラウド

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

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

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

最新記事10本