グーグルは「異形」のメーカー。ここが違う10個のポイント

グーグルは世界有数のハードウェアメーカーであり、ソフトウエアメーカーである。1990年代末に他に先駆けて「情報爆発」に直面し、いち早くそれに対応したグーグルのコンピュータは、従来のコンピューティングと比較すると常識外れにすら見える進化を遂げた。グーグルコンピューティングの特異さを10個紹介しよう。

(1)自前主義
 グーグルは売上高をみると「広告会社」あが、その実態は7000人を超えるエンジニアを抱える世界有数のメーカーである。しかもコンピューティングの在り方は、従来型のそれと大きく異なる。グーグルが「異形」のメーカーなのは、同社がハードもソフトも自前主義を貫いているからだ。
 使用するサーバーはすべて自社開発だ。一部報道では、グーグルはダイスベースで米デルや米ヒューレット・パッカードに次ぐ「世界第3位」のサーバーメーカーだという。

 サーバーだけではない。2007年、大手ネットワーク機器メーカーに不穏な空気が流れた。次の大型商材として期待する「10Gビット・イーサネット・スイッチ」の受注が、グーグルから全く入らなかったのだ。「そのころ、ネットワーク機器メーカーの営業に会うと、みな一様にがっかりしていた」(あるネットワーク機器商社の米国駐在員)。07年末には「グーグルが10Gビット・イーサネット・スイッチの自作を開始した」という報道が流れ、懸念は現実のものとなった。

 データセンターもグーグルは自作する。08年秋に米国で「グーグルが潮力発電や海水を使ったサーバー冷却をおこなう『水上データセンター』の特許を取得した」という報道があった。同社が既に水上データセンターを実用化していたとしても、さほど驚くに値しない。既に同社は03年に「コンテナ型データセンター」の特許を取得し、05年から実運用を開始している。

 自前主義はネットワーク回線にも及ぶ。10年第1四半期には、最大7.68Tビット/秒の伝送速度の海底ケーブルが日本と米国をつなぐ。08年2月に、KDDIなど通信事業5社と海底ケーブルを敷設するコンソーシアム「Unityコンソーシアム」を設立した。

 データセンターを支える基盤ソフトも内製だ。競争力の源であえる分散処理システム基盤は、すべて自社開発。オープンソース化もしていない。詳細は学会などで発表される論文からしかうかがいしれない。関連記事『ソースコードから見るグーグル気質』にもあるように、グーグルはオープンソースの利用や、自社ソフトのオープンソフト化に積極的だ。しかしそれらは同社にとって公開しても構わないものでしかない。

 検証環境が不十分な他社には頼れない

 自社開発する基盤ソフトは多岐にわたる。グーグルの基幹事業であるWeb検索は、解析対象のデータが日々飛躍的に増加する。つねに増え続けるデータに対応するため、まず各調整の高い分散ファイルシステム「Google File System (GFS)」を開発した。次にGFS上での分散処理を容易にするため、並列プログラミングモデル「MapReduce」と、GFSとMapReduceを使った並列プログラムを開発するための専用プロシージャ言語「Sawzall」を開発した。

 並行して、GFS上で構造化データを扱うキー・バリュー型データストアである「BigTable」を開発。GFSが処理するデータの整合性を保つための分散ロックシステムとして「Chubby」を開発した。これらは現在、Web検索だけでなく「Gmail」や「Googleドキュメント」といったSaaS(ソフトウェア・アズ・ア・サービス)、「Google App Engine」のようなPaaS(プラットフォーム・アズ・ア・サービス)の基盤としても利用されている。

 グーグルは09年5月に発表したホワイトペーパー「The Datacenter as a Computer」で、自前主義を貫く理由をこう説明している。「巨大なクラスタ(システム)を保有しないサードパーティ・ソフトウェア・プロバイダが、ソフトウェアのテストやチュー日んぐを純分な水準で行ううのは困難だ」。グーグルが運用するデータセンターの規模はあまりに巨大であるため、自社以外にグーグル向けのソフトウェアの開発は不可能だとういうわけだ。

(2)情報爆発
グーグルが基盤ソフトウェアの内製を決断した背景には、同社が創業した90年代末にコンピュータ業界で顕在化した「情報爆発」という現実がある。

 情報爆発とは、人類が生み出す情報(デジタルデータ)が現在、爆発的な勢いで増加していることを表す。人類が1年に生み出す情報は、99年には3.2エクサバイト(1テラバイトの320万倍)だったが、11年には1800エクサバイト(1.8ゼタバイト、1テラバイトの18億倍)に達するとみられる。

 爆発的に増加する情報を人が使いやすい形に整理するというグーグルのミッションが、いかに困難なものであるのか。AT&Tベル研究所で「UNIX」を生み出し、現在はグーグルに所属するコンピュータ技術者、ケン・トンプソン氏は本誌の取材にこう語る。

 「クラウドコンピュータは、開発が非常に困難だ。なぜなら同時に(性格の異なる)二種類のジョブをこなす必要があるからだ。一つは、(Web検索のインデックス作成のような)とても巨大なジョブを、数万台のコンピュータに小さいジョブとして振り分けて実行し、それぞれを失敗させないこと。もう一つは、利用者が自宅で実行するとても小さなジョブ、つあり日記を書いたり、ビデオを見たりするといったジョブを、利用者が自宅のコンピュータを使って実行するよりも、もっと信頼性が高い状態で実行することだ」

グーグルの技術こそが基盤を支える

ちなみにトンプソン氏は「クラウドコンピューティング」ではなく「クラウドコンピュータ」という言葉を好んで使用する。自分たちが開発している技術こそが「クラウドコンピュータ」の基盤を支えているという自負によるものだ。

(3)スケールアウト

 トンプソン氏が言う「クラウドコンピュータ」を実現する上でグーグルが採用したアプローチが「スケールアウト」だ。グーグルは処理の高速化を実現するのに、高価なSMP(対象型マルチプロセッサ)サーバーを使う「スケールアップ」ではなく、安価なPCサーバーを大量に並列処理するスケールアウトという手法を好んでいる。

 サーバーを増やすほど処理が高速化するスケールアウトを実現するためには、並列処理、分散処理を実現する基盤ソフトが欠かせない。グーグルはそのために自社で、GFSやMapReduce, BigTableなどを開発した。これらの論文には必ず「巨大なデータ処理を、信頼性を確保した上で、コモディティ(日用品)ハードウェアをつかて実現する」ことが開発の目的だと明示してある。

 スケールアウトを選んだ最大の理由は、価格/性能比である。先に紹介したThe atacenter as a Computerでグーグルは、HPのItanium搭載サーバー「HP Intergrity Superdome」と低価格サーバー「HP Proliant ML350 G5」とを比較して、Proliantのほうが価格/性能比がおよそ20倍は優れると主張している。

 もちろん、SMPサーバーにも性能上の利点がある。システム応答速度だ。1台のSMPサーバーで処理を実行する場合、システムの応答速度はプロセサとメモリー間の応答速度である1000万分の1秒が見込める。それに対して、ネットワークを介して複数のサーバー連携するシステムでは、応答速度はネットワークの応答速度である1万分の1秒のレベルに落ちる。

 しかし、グーグルは「(我々の)ワークロードはあまりに巨大なので、どんな大きなSMPサーバーでお1台ではまかないきれない」と断言する。SMPサーバーであってもどこかでネットワーク連携が必須なら、遅延時間は遅くならざるを得ない。安価なPCサーバーを使うのと結果的に変わらないというのだ。

(4)メニーコア

 グーグルは何千~何万台ものサーバーを連携させるコンピューティングの在り方を「ウエアハウス(倉庫)・スケール・コンピューティング(WSC)と」述べる。そして同社は、WSCが近い将来、一般的なコンピューティング形態になるとも指摘する。その背景にあるのは、1個のプロセサに搭載されるプロセサコアの個数が増える「マルチコア」「メニーコア」の進展だ。

プロセサの発展がWSCを当たり前にする

 米インテルなど主要プロセサメーカーは現在、プロセサの動作周波数向上ではなく、マルチコア/メニーコア化を進めている。近い将来、数十個のx86プロセサコアを集約したプロセサも登場するだろう。そうなれば、サーバーが数10台入る「ラック」が、今のデータセンターに匹敵するプロセサを内包するようになる。そのときには、誰もがデータセンター単位でシステムを連携させるWSCの概念を受け入れざるをえなくなるというのだ。

(5)ソフトウェアベースの耐障害性対策

 通常の大型サーバーでは、プロセサやメモリーの二重化といったハードウェアベースの耐障害性(フォールトレランス)対策が施されている。グーグルはこれらハードウェアベースの耐障害性対策も不要だという。

 グーグルは、耐障害性対策そのものが不要だと言っているわけではない。数万台規模のPCサーバーを連携させるWSCの世界では、ハードウェアベースの耐障害性対策など意味がないと言いたいのだ。なぜなら連携させるサーバーの台数が万を超えると、MTBF(平均故障間隔)が30年という(30年に1回しか故障しない)超高信頼性ハードウェアを使ったとしても、データセンター全体では常時何台かが故障している計算になる。

 常にハードやソフトに障害が発生しているのが現実ならば、一部で障害が起きたとしても全体では安定して動作するソフトを開発するしかないと、グーグルは力説する。

 実際にGFSやMaReduce,BigTableといったソフトウェアには必ず、耐障害性対策が組み込まれている。例えばGFSは、ファイルを64Mバイトの「チャンク」(ファイルを分割する単位)と呼ぶブロックに分割し、各チャンクの複製を少なくとも三つ、別のノードに配置する。もしどこかのサーバーが故障したとしても、チャンクは別のサーバーから読み出せる。

 電子メールサービス「Gmail」で、あるユーザーのメールボックスに障害が発生した場合、そのユーザーの接続は、即座に別のデータセンターに切り替わる。メールボックスは常に、ほかのデータセンター全体やネットワークに障害が発生した場合でも、処理を継続できるようにしている。

(6)関数型言語

 グーグルは、スケールアウトと耐障害性対策を同時に実現するソフトを、どのようにして開発したのだろうか。その秘密が「開発型言語」である。

 グーグルは論文「MapReduce: Siplified Data Processing on Large Clusters」で、MapReduceという並列プログラミングモデルの仕組みを「Lispなどの関数型言語に刺激を受けて生み出した」と説明する。関数型言語の動作モデルを参考に、ミドルウエアを開発したというのだ。

 関数型言語とは、関数の定義と関数の適用(呼び出し)だけでプログラムを書く言語である。LispやScheme ,Haskell,Erlangなどが代表例だ。

各プロセスが独立して動く

 CやPython,Visual Basicといった現在主流の言語は「手続き型言語」と呼ばれる順るに属する。JavaやRuby、C#のようなオブジェクト指向言語も手続きが他言語の一種だ。

 手続き型言語は、記述された命令を逐次的に実行し、処理の結果に応じて変数の内容を変化させる。それに対して関数型言語では、変数は一度値をあたえられたら変更されない。

 手続き型言語と関数型言語は、マルチスレッド・マルチプロセスを実現する場合に、実行モデルに大きな差が出る。手続き型言語は、メモリー上のデータを変更することによって計算を行う。つまり各スレッドが共有メモリーにアクセスしながら処理を行う。手続き型言語では、あるスレッドが共有メモリーにアクセスしながら処理を行う。手続き型言語では、あるスレッドが共有メモリーに加えた変更が、他のスレッドに影響を及ぼす危険がある。

 関数型言語では、各プロセスが自分用にデータをコピーした上で、計算を実行する。各プロセスは独立して動いているため、互いに影響を与えない。独立して動く関数型言語の各プロセスは、それぞれを異なるコンピュータに移すことも容易である。

 グーグルは、関数型言語の「各プロセスが独立して動く」という特徴を、MapReduceに実装した。

 MapReduceは、データ抽出処理(フィルタリング)を行う「Map処理」と、抽出したデータを集約して計算を行う「Reduce」は、Lispが備える関数名が元になっている。大量のデータから特定のデータを探し出すような処理に向いており、グーグル社内ではWeb検索やログ解析の基盤技術として利用している。

 MapReduceは、データ抽出処理(フィルタリング)を行う「Map処理」と、抽出したデータを集約して計算を行う「Reduce処理」の2つの処理の組み合わせで構成される。「Map」や「Reduce」は、Lispが備える関数名が元になっている。大量のデータから特定のデータを探し出すような処理に向いており、グーグル社内ではWeb検索やログ解析の基盤技術として利用している。

 MapReduceでは、各処理が動作するサーバーは独立して働く。各サーバーが自分用にデータをコピーして処理をじこくするので、スケールアウト型システムでの展開が容易だ。また障害によってあるサーバ0での処理が失敗しても、その処理をやり直せば済む。

(7)エラー忘却型コンピューティング

 耐障害性をソフトで実現するために、グーグルはエラー忘却型コンピューティング」という2000年代に生まれた新しい概念も取り込んでいる。GFSとMapReduceを使ったプログラムを開発する言語「Sawzall」に、エラー忘却型コンピューティングのアイデアが実装されている。

エラーを無視し耐障害性を高める

 Sawzallは、リレーショナルデータベース(RDB)における「SQL」に相当する、データの操作に特化したプロシージャ言語だ。分散処理の経験がないエンジニアでも、分散処理ソフトであるGFSやMapReduceを使いこなせるよう独自に開発した。グーグル以外では一切使われていないが、グーグル社内ではとても人気が高い言語という。

 Sawzallはインタープリタによってコードを逐次実行する言語だが、「ゼロ除算」のようなデータのエラーが発生したとしても、プログラムを中止せず「エラーがあった」というフラグを立てるだけで処理を継続する機能がある。通常のインタープリタ型プログラムは、エラーがあるとそこで処理を停止する。それに対してSawzallは、エラーを「なかったこと」にして(忘却して)処理を進める。このような処理の在り方を「エラー忘却型コンピューティング」と呼ぶ。

 グーグルが処理する数百ペタバイト級のデータの中には、ハードやソフトのエラーによって時として開発者の予期しないような無効なデータが混ざる。Sawzallはそのようなエラーを無視することで、耐障害性を高めている。

 エラー忘却型コンピューティングは、米マサチューセッツ工科大学(MIT)のマーティン・リナード氏らが2004年に提唱した概念。グーグルがSawzallでその概念を取り入れたのは、わずか1年後の2005年である。

(8)キー・バリュー型データストア

 グーグルは、関数型言語やエラー忘却型コンピューティングのような、新しいアイデアの取り込に意欲的だ。その点で言えば、リレーショナルデータベース(RDB)ではなく、「キー・バリュー型データストア」であるBigTableを大規模に使っている点も見逃せない。

 データを「キー」とそれに対応する「バリュー(値)」として保存するキー・バリュー型データストアは、RDBと比べて複数のサーバーに処理を分散させやすい。グーグルが扱う膨大なデータを処理するためには、RDBではなくスケールアウトしやすいデータベースが必要だったのだという。BigTableはその名の通り、データを表形式で保存可能だ。

BigTableは、データがどのサーバーのどの行に保存されているかというメタデータや、最近書き込まれたデータなどを、サーバーのメモリー上に保存する。データの保存場所としてハードディスクを使用するGFSよりも、データ処理の応答性が高い。BigTableは現在、GmailやGoogle Mapsのような、高い応答性能を求められる大規模アプリケーションの基盤として広く使われている。

 最もBigTableの場合、データ更新の一貫性を保証するトランザクション処理は、テーブルの行単位でしか行えない。行やテーブル、データベース単位でトランザクション処理が行えるRDBとは大きく異なる。

(9)クエリ―処理中心

 厳格なトランザクション処理を省いたBigTableや、「エラーを無視する」Sawzallは「ACID」を重視するえんたープライズシステムとは相いれない存在に見受けられる。ACIDとは、原子性(Atomicity)、一貫性(Consistency)、独立性(Isolation)、耐久性(Durability)の頭文字を組み合わせたもの。RDBは必ずACID特性を満たすように設計されている。

書き込みの高速化に向けた見直しも

 グーグルが、データの一貫性などにさほどこだわらない仕組みを採用するのは、同社が実行する処理が、「Web検索」のようなデータを更新しないクエリ―処理や、「Web検索のインデックス処理」といったバッチ処理が中心だったからだ。またグーグルが扱うデータは、書き込みよりも読み出しが圧倒的に多い。このためGFSやMapReduceは、読み出しの高速化に重きを置き、データの書き換えの高速化や一貫性の維持にはそれほど気を配る必要はなかった。

 しかし現在、グーグルのデータ処理ニーズは大きく変わりつつある。GmailやGoogleドキュメントのように、大量の利用者が頻繁にデータを書き込む処理が増えたのだ。読み出しだけでなく、書き込みの高速化も求められるようになった。そこでグーグルは、GFSの抜本的な見直しを始めている。

(10)メモリ

 グーグルは09年8月、米コンピュータ学会(ACM)が発行する雑誌「ACM Queue」で、同社がGFSの改良を進めていることを明らかにした。

GFSでは、Web検索のインデックス処理といったバッチ処理向けに開発したソフトで、GmailやGoogleドキュメントのようなデータ書き込みの多いアプリケーションに向いていない。

 例えばGFSでは、チャンク(ファイルを分割する単位)をどのサーバーに保存するかを管理するマスターサーバーが、数千台規模のクラスタ単位につき1台しかない。いわゆる「シングルマスター構成」だ。マスターに障害が発生した場合、処理は他のサーバーに引き継がれるが、その引き継ぎに最短でも1分かかる。その間、ユーザーへの応答がストップする。この点が問題となっていた。

 時期GFSでは、マスターを常に複数台置き、1台に障害が発生しても数秒単位で別のマスターに処理が引き継がれる「マルチマスター構成」をとる。

 GFSのチャンクが64Mバイトと大きい事も問題だった。巨大なチャンクは、データ更新が少ないバッチ処理には向いていた。しかし、小さいファイルを大量に更新するのには向いていない。そこで時期GFSでは、チャンクのサイズを1Mバイトに小さくする。

先にメモリーに移った競合

 国立情報学研究所アーキテクチャ科学研究系の佐藤一郎教授は、チャンクを1Mバイトにすることが、「データ保存にハードディスクではなくSSD(半導体ディスク)を採用する布石ではないか」とみる。チャンクのサイズを小さくすると、ファイルの読み書き操作が増加する。それによる性能低下を避けるためには、ハードディスクよりも遅延の少ないSSDを使用するのが合理的だ。SSDの価格が急激に低下している現在、価格/性能比的にも問題がなく、サーバーの消費電力も削減できる。

 現時点でグーグルは、データ保存をSSDに移行するとは明言していない。しかし、グーグルコンピューティングにきわめてよく似たコンピューティングの開発を始めた競合他社は、データ保存の場をハードディスクからメモリーに移しつつある。

 その競合とは、米アマゾン・ドット・コムと米マイクロソフトである。クラウドコンピューティングの動向に詳しい早稲田大学大学院客員教授の丸山不二夫氏は、アマゾンやマイクロソフトの分散処理ソフトウェアが、グーグルの影響を色濃く受けていると指摘する。そして、ソフトウェアの開発時期や採用する技術の新規性に基づいて、グーグルのGFSやMapReduce、BigTableなどを「クラウドコンピューティング技術の第一世代」、アマゾンのキー・バリュー型データストア「Amazon Dynamo」を「第二世代」、マイクロソフトのクラウドコンピューティング基盤技術「Windows Azure」を「第三世代」と位置付ける。

 時期GFSが実装するマルチマスター構成は、Amazon DynamoやWindows Azureのキー・バリュー型データストア「Azure Storage」が採用済み。Amazon Dynamoはコンシステントハッシングというマルチマスター構成を採用し、Azure Storageはピア・ツー・ピア技術の基盤である「分散ハッシュテーブル」というマルチマスター構成を採用する。

 Amazon DynamoやAzure Storageは、データの主たる保存先をサーバーの物理メモリーとすることで、システムの応答性を向上するというアプローチを採用している。これまで、「データの永続化」とはハードディスクにデータを保存することを指していた。しかし十分な数の複製を複数のサーバーに作成すれば、保存先がメモリーでもデータの永続化が図れれるというのが、Amazon DynamoやAuzre Storateの発想だ。

 グーグルコンピューティングは、アマゾンやマイクロソフトといった競合に多大な影響を与えた。そして今グーグル自身も、アマゾンやマイクロソフトに対抗すべく、自身のコンピューティングを今後も劇的に変化させるただ中にいる。