Googleの大規模分散処理技術

Scale-out戦略 Googleは、インターネット・クラウド技術の完成者としてのクラウドの歴史に画期を築きました。その技術のエッセンスはエンタープライズ・クラウドにも引き継がれ今日に至るも、あらゆるクラウド技術に決定的な影響を与えています。今回はそのGoogleの大規模分散処理技術を見ていきた

丸山 不二夫

2009年9月16日 20:00

Scale-out戦略

 Googleは、インターネット・クラウド技術の完成者としてのクラウドの歴史に画期を築きました。その技術のエッセンスはエンタープライズ・クラウドにも引き継がれ今日に至るも、あらゆるクラウド技術に決定的な影響を与えています。今回はそのGoogleの大規模分散処理技術を見ていきたいと思います。

 近年、「全世界の情報」は加速度的に増大を続けており、「全世界の情報をアクセス可能にする」というGoogleの夢は、いまだ達成されてはいないように思えます。

 ただ、Webスケールの情報の大きさに初めて気づいた彼らが、それに対してどのように立ち向かおうとしたのかを振り返ることは無駄ではありません。

 彼らがとったのは、処理量の大きさには処理するシステムの規模を拡大して対応するというやり方でした。そこまでは普通ですが、超大型のスーパー・コンピューターを建設しようとしたのではないところがユニークです。

 彼らは、膨大な数の安価なマシンをネットワーク上に並べて、それを協調動作させる道を選びました。こうしたアプローチを「Scale-out」と言います。

 Scale-outの戦略を選択した背景には、ハイエンドなマシンより、コモディティ化したPCの方が技術革新の恩恵を受けるファクターが大きいという認識がありました。

 同じ能力でも、ハイエンドの大型マシンはPCのクラスタより30倍以上コストがかかるという試算をしています。Googleの目に見えない競争力の一つは、システムのこうした抜群のコスト・パフォーマンスの良さにあるのです。

 また、Scale-outのもう一つの背景には高速なネットワーク環境が安価に手が入るようになった事情もあります。

Availability(可用性)

 Scale-outの戦略には、一つ問題があります。

 それは、安価な(それは壊れやすいということを意味します)マシンを多数並べて、一つのシステムを作ることにより、システムの故障にいつも脅かされることです。

 普通平均して3年に一度故障するようなマシンでも、それが1,000台集まれば、一日にそのうち一個のマシンが故障する計算になります。数千台のマシンからなるシステムなら、一日に何回もシステムに不都合が起きるということになります。

 ここでも、Googleのとった対応はユニークなものでした。マシンは故障してはならないという想定を捨て、例外なく必ず故障するものだという前提に立ち、この故障がシステム全体のダウンを招かないように、あらゆる手段をとりました。

 また、それには故障率の低い高価なマシンを導入するのではなく、あくまでもソフトの力で障害対策を行おうとしたのです。

 Googleのシステムでは、Availabilityを維持するための恒常的なモニタリング、エラーの検出、誤りに対する強さや自動的な回復機能が、必ずシステムに組み込まれています。見かけは派手ではありませんが、これなしにはScale-outの経済的なメリットが生きません。Googleの技術のもっとも重要な構成要素と言ってもいいのが、このAvailabilityの技術です。

 筆者は、Googleの人が、次のように語るのを聞いて、とても感心したことがあります。

 「だから、なぜ、みなさんは、高価な信頼性の高いハードのことで思い悩んでいるのでしょう?信頼性の高いハードは、ソフトウエア技術者を怠け者にするだけです。障害に強いソフトウエアが安いハードを役に立つものに変えるのです。」

 でも、そうした障害に強いソフトを作り上げることが容易なことではないのは明らかです。

この記事のキーワード :

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30