Googleのデータセンターのネットワーキングインフラストラクチャ、10年間の進化の過程

2014-09-30_1420

Googleは今日(米国時間8/18)、家庭のWiFiの高速化技術を発表したが、同社内部ではこれまで長年、それよりもずっと複雑なネットワーキングの問題に取り組んできた。Googleのデータセンターを構成するマシンの数は数十万のオーダーだから、そこらのふつうのルータやスイッチでそれらを接続することはできない。サーバ間を流れるすべてのデータを管理するためにGoogleは、独自のハードウェアとソフトウェアを作ってきたが、今日は同社の研究部門のブログ記事などで、同社のネットワーキングインフラストラクチャの進化の軌跡を紹介している。

Googleの内部ネットワークの現在のセットアップはJupiterネットワークと呼ばれ、その容量は第一世代のネットワークの100倍、全体の二分割帯域幅(bisection bandwidth)*は毎秒1ペタバイトに達する。Googleによると、このスピードは、10万台のサーバが合衆国国会図書館のデジタル化された全データを、1/10秒以下で読み取る速度に相当する。〔*: bisection bandwidth, ネットワークを二分割したとき両部分間に存在する全帯域の合計。〕

ブログ記事の中で筆者のAmin Vahdat(Googleのフェロー)は。“このようなネットワークパフォーマンスがGoogleのサービスの能力をすさまじく強力にしてきた”、と書いている。“しかも帯域の高低差がないから、技術者たちは帯域のいろんなレベルに合わせてコードを最適化する必要がない。たとえば初期には、サーバの配置によって性能やエラー率に差が生じたため、データをどこに置くかという悩ましい問題がつねにあった。すべてのサーバをラックの最上位の(最高速の)スイッチにぶら下げたりすると、たった一つのスイッチのトラブルで大きな被害が生じたりするのだ”。

image02

10年前のGoogleのネットワークは、まだこれほどの性能に達していなかった。当時はYouTubeを買収する前、そしてGmailやGoogle Earth、Google Mapsなどのサービスを立ち上げた直後だった。そのあとの短い10年間で、同社のネットワーキングニーズはきわめて急速に変わっていったのだ。

2005年当時のマシンは、こんな感じだ:

  1. fh10_board.jpg

  2. firehose1-1_chassis.png

  3. copy-of-fh_cabling-1.jpg

その10年を振り返った論考によれば、同社は2004年にはまだ、標準的なサーバクラスタを配置していたが、上図の2005年のマシンは、同社のFirehose 1.0データセンターアーキテクチャで配置(デプロイ)したネットワークの最初の機種だ。その2005年のマシンの目標は、1万台のサーバ間で1 Gpsの二分割帯域幅を実現することだった。それを達成するためにGoogleは、スィッチングのファブリックを内製のサーバに直接統合しようとしたが、しかしそうすると、“サーバのアップタイムが理想に達しなかった”。

Firehose 1.1でGoogleは初めて、カスタムのデータセンタークラスタファブリックをデプロイした。“FH1.0の経験から、通常のサーバにスイッチのチップを入れてはいけないことを学んだ”、と当時の技術者の一人が書いている。そこでGoogleはカスタムのエンクロージャーを作り、Closアーキテクチャと呼ばれるデータセンターネットワークへ移行した。

2008年に、FH 1.1はWatchTowerへと進化した。ケーブルは、通常のネットワーキングケーブルではなく10Gのファイバを使った。Googleはこのバージョンのデータセンターネットワークを、全世界のデータセンターで展開した。

それは、こんなラックだ:

WT2

1年後に、WatchTowerはSaturnに変身した。WatchTowerのファブリックは87 Tbpsまでスケールできたが、Saturnはその混みあったラック上で207 Tbpsまでスケールアップした。

  1. saturn_chassis.png

  2. wtbundles.jpg

  3. pluto-png.jpg

Saturnは、Googleによく仕えた。その後3年間もGoogleのデータセンターネットワークのアーキテクチャは、Saturnで十分間に合ったのだ。

上記論考には、こう書かれている: “サーバ一台あたりの帯域要求が継続的に成長していくだけでなく、データセンターのすべてのクラスタの、むらのない均一な帯域も求められた。40G対応の高密度商用チップの登場に伴い、Closファブリックをデータセンター全体に拡張して、クラスタ間ネットワーキングの層もそこへ入れることを、検討できるようになった”。

それは、一つのデータセンターを一つの巨大なコンピュータのように扱えるアーキテクチャだ。ソフトウェアが計算資源とストレージ資源の分散を管理し、ネットワーク上のすべてのサーバからそれらを可利用にしている。

Jupiterのハードウェアはたしかに、同社の初期の内製ネットワーキングハードウェアとは外見的にも異なっているが、しかし多くの点で、同社がそもそもの初期からSoftware Defined Networking(SDN)の考え方を採用して、イノベーションのスピードを上げてきたことも事実だ。

Googleは今日、同社のネットワーキングのセットアップを、いろんな側面から詳説する4つの小論を発表した。Googleは現行のハードウェアやソフトウェアのアーキテクチャの限界に他社よりも早くぶつかる方だから、Googleからのこの種の情報提供によって同社の外での新しいイノベーションが、これまでも生まれてきている。

すべてのスタートアップが自前のデータセンターを構えるわけではないが、でも他のデータセンターの運用者たちは確実に、これらの論考の細部から多くを学び、自らのソリューションに、そして結果的にはユーザの利益に、反映していくことだろう。

Jupiter-superblock3

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

投稿者:

TechCrunch Japan

TechCrunchは2005年にシリコンバレーでスタートし、スタートアップ企業の紹介やインターネットの新しいプロダクトのレビュー、そして業界の重要なニュースを扱うテクノロジーメディアとして成長してきました。現在、米国を始め、欧州、アジア地域のテクノロジー業界の話題をカバーしています。そして、米国では2010年9月に世界的なオンラインメディア企業のAOLの傘下となりその運営が続けられています。 日本では2006年6月から翻訳版となるTechCrunch Japanが産声を上げてスタートしています。その後、日本でのオリジナル記事の投稿やイベントなどを開催しています。なお、TechCrunch Japanも2011年4月1日より米国と同様に米AOLの日本法人AOLオンライン・ジャパンにより運営されています。