Googleのデータセンター

Googleがスタンフォード大学に拠点を置いていた頃に使用されていたオリジナルのハードウェア（1998年頃）には、以下のものが含まれていました。^{[ 78 ]}

• デュアル200MHzプロセッサと256MBのRAMを搭載したSun Microsystems Ultra II 。これは、初代Backrubシステムのメインマシンでした。  
• Intel社から寄贈された2台の300MHz デュアルPentium IIサーバーには、合計512MBのRAMと10台の9GBハードドライブが搭載されていた。主要な検索処理はこれらのサーバー上で実行された。  
• IBMから寄贈されたF50 IBM RS/6000には、4つのプロセッサ、512MBのメモリ、および8台の9GBハードディスクドライブが搭載されていた。  
•  追加の2つの箱には、それぞれ9GBのハードドライブが3台と 4GBのハードディスクドライブが6台入っていた（Backrubの元のストレージ）。これらはSun Ultra IIに接続された。
• IBMから寄贈された、SSDディスク拡張ボックスと、さらに8台の9GB ハードディスクドライブ。
• 自作のディスクボックスには、9GBのSCSIハードディスクドライブが10台収められて いた。

2003年のGoogleのインフラストラクチャの状態は、Luiz André Barroso、Jeff Dean、およびUrs Hölzleによるレポートで「信頼性の低い汎用PCのクラスターによる信頼性の高いコンピューティングインフラストラクチャ」と表現された。^{[ 79 ]}

当時、平均して1回の検索クエリは約100MBのデータを読み込み、$\displaystyle \sim 10^{10}}$CPUサイクル。ピーク時には、Googleは1秒あたり約1000件のクエリを処理していました。このピーク負荷に対応するため、コスト削減を目的として、高価なスーパーコンピュータではなく、約1万5000台の汎用PCで構成されたコンピューティングクラスタを構築しました。ハードウェアの信頼性が低いことを補うため、耐障害性の高いソフトウェアを開発しました。

クラスターの構造は5つの部分から構成されています。中央のGoogle Webサーバー（GWS）はパブリックインターネットに接続されています。ユーザーからのリクエストを受信すると、Google Webサーバーはスペルチェッカー、広告サーバー、多数のインデックスサーバー、多数のドキュメントサーバーと通信します。これら4つの部分はそれぞれリクエストの一部に応答し、GWSはそれらの応答を統合して最終的な応答をユーザーに提供します。

元のドキュメントは約100TB、インデックスファイルは約10TBでした。インデックスファイルはシャーディングされており、各シャードはインデックスサーバーの「プール」によって提供されます。同様に、元のドキュメントもシャーディングされています。インデックスファイルへのクエリごとにドキュメントIDのリストが生成され、そのリストがドキュメントサーバーに送信されて、タイトルとキーワードを含むスニペットが取得されます。

 使用されていたCPUは、シングルプロセッサの533MHz Intel-Celeronベースのサーバーから、デュアル1.4GHz  Intel Pentium IIIサーバーまで、複数の世代に及んでいた。各サーバーには、それぞれ80GBのハードドライブが1台以上搭載されていた。インデックスサーバーは、ドキュメントサーバーよりもディスク容量が少なかった。各ラックには、両側に1台ずつ、合計2台のイーサネットスイッチが設置されていた。両側のサーバーは、100Mbpsの回線で相互接続されていた。各スイッチは、すべてのラックに接続されている中央スイッチへ、約250MB/秒のアップリンクで接続されていた。

設計目標は以下のとおりです。

• 信頼性の低い民生用ハードウェアを使用し、耐障害性の高いソフトウェアでそれを補う。
• 例えば、大規模なインデックスにおける単一のドキュメント一致検索を、多数の小規模なインデックスに対するMapReduceに分割するなどして、並列処理を最大限に活用する。
• クラスターは大規模な共有メモリマシンであるため、通信を最小限に抑え、サーバー間で負荷を均等に分散させるために、インデックスデータと計算処理を分割します。
• すべてのソフトウェアを社内で開発することで、システム管理の負担を最小限に抑える。
• 絶対的な性能ではなく、価格対性能比が最大となるハードウェアを選びましょう。
• レイテンシよりもスループットの高いハードウェアを選択してください。これは、クエリは大規模な並列処理で処理され、依存関係のあるステップが非常に少なく、サーバー間の通信も最小限であるため、レイテンシが高くても問題にならないからです。

大規模な並列処理のおかげで、ハードウェアをスケールアップするとスループットが線形的に向上します。つまり、コンピューティングクラスタを2倍にすると、1秒あたりに処理できるクエリの数も2倍になります。

このクラスターは、2種類の構成のサーバーラックで構成されています。1つは片側40台の1Uラックを2面配置したもの、もう1つは片側20台の2Uラック を2面配置したものです。消費電力はラック1台あたり10kW、密度は400W/ft²で、月間10MWhを消費し、月額費用は1,500ドルです。

2014年現在、Googleは大幅にカスタマイズされたDebian Linuxを使用しています。2013年にRed Hatベースのシステムから段階的に移行しました。^{[ 80 ]}

カスタマイズの目標は、絶対的なパフォーマンスではなく、1ドルあたりの最高のパフォーマンスを提供するCPU世代を購入することです。これがどのように測定されるかは不明ですが、サーバー全体の運用コストが含まれる可能性が高く、CPUの消費電力が重要な要素となる可能性があります。^{[ 81 ]} 2009年から2010年のサーバーは、2つのプロセッサ（それぞれ複数のコア^{[ 82 ]}）、ダブルハイトDIMMを収容する8つのDIMMスロットに分散されたかなりの量のRAM、および非標準のATXサイズの電源ユニットを介して接続された少なくとも2つのSATAハードディスクドライブを含むカスタムメイドのオープントップシステムで構成されていました。^{[ 83 ]}サーバーは、より多くのサーバーをラックに収めることができるようにオープントップでした。CNETとJohn Hennessyの著書によると、各サーバーにはコストを削減し電力効率を向上させるための新しい12ボルトバッテリーが搭載されていました。^{[ 82 ] [ 84 ]}

Googleによると、 2010年までに同社のグローバルデータセンターの運用電力は500～681メガワットの範囲であった。 ^{[ 85 ] [ 86 ]}これらのサーバーの合計処理能力は、 2008年には20～100ペタフロップスに達した可能性がある。^{[ 87 ]}

Googleの全世界のプライベートネットワークの詳細は一般には公開されていませんが、Googleの出版物^{[ 88 ] [ 89 ]}では、Level 3に次いで3番目に大きなISPとしてGoogleをランク付けした「Atlas Top 10」レポートに言及しています。

このような大規模なネットワークを、可能な限り多くのISPに直接接続し、可能な限り低いコストで運用するために、Googleは非常にオープンなピアリングポリシーを採用しています。^{[ 90 ]}

このサイトから、Google ネットワークは世界中の 67 か所のパブリック交換ポイントと 69 か所の異なる場所からアクセスできることがわかります。2012 年 5 月の時点で、Google は 882  Gbit/s のパブリック接続を持っていました (Google が最大規模の ISP と締結しているプラ​​イベートピアリング契約は含みません)。このパブリックネットワークは、Google ユーザーにコンテンツを配信したり、インターネットをクロールして検索インデックスを構築したりするために使用されています。ネットワークのプライベート側は秘密ですが、Google の最近の開示^{[ 91 ]}によると、広域ネットワークにはカスタム構築された高基数スイッチルータ(128 × 10ギガビットイーサネットポートの容量を持つ) を使用していることが示されています。データセンターごとに少なくとも 2 台のルータ (冗長性のため) を稼働させることで、Google ネットワークはテラビット/秒の範囲で拡張できると結論付けることができます (2 台のルータが完全に稼働している場合、2 セクションの帯域幅は 1,280 Gbit/s になります)。  

これらのカスタムスイッチルーターは、ダークファイバーを介してデータセンターと接続拠点（PoP）を相互接続するために、 DWDMデバイスに接続されます。

データセンターの観点から見ると、ネットワークはラックレベルから始まり、19インチラックはカスタムメイドで、40～80台のサーバー（両側に20～40台の1Uサーバー、新しいサーバーは2Uラックマウントシステム）を収容します。 ^{[ 92 ]}各ラックにはイーサネットスイッチ があります。サーバーは1 Gbit/sイーサネットリンクを介してトップオブラックスイッチ（ToR）に接続されます。ToRスイッチは、複数のギガビットまたは10ギガビットアップリンクを使用してギガビットクラスタスイッチに接続されます。 ^{[ 93 ]}クラスタスイッチ自体は相互接続され、データセンター相互接続ファブリックを形成します（おそらく、従来のバタフライレイアウトやフラットバタフライレイアウトではなく、トンボデザインを使用しています^{[ 94 ]}）。

運用面から見ると、クライアントコンピュータがGoogleに接続しようとすると、ラウンドロビンポリシーによって複数のDNSサーバーが複数のIPアドレスに解決されます。さらに、これは負荷分散の第一段階として機能し、クライアントを異なるGoogleクラスタに誘導します。Googleクラスタには数千台のサーバーがあり、クライアントがサーバーに接続すると、負荷が最も低いWebサーバーにクエリを送信するために追加の負荷分散が行われます。これにより、Googleは最大かつ最も複雑なコンテンツ配信ネットワークの1つとなっています。^{[ 95 ]}www.google.com

Google は世界中に多数のデータセンターを分散させています。少なくとも 12 か所の主要な Google データセンター施設が米国にあります。既知の最大のセンターは、オレゴン州ザ・ダルズ、ジョージア州アトランタ、バージニア州レストン、ノースカロライナ州レノア、サウスカロライナ州モンクスコーナーにあります。^{[ 96 ]}ヨーロッパでは、既知の最大のセンターは、オランダのエムスハーフェンとフローニンゲン、ベルギーのモンスにあります。^{[ 96 ]} Google のオセアニアデータセンターは、オーストラリアのシドニーにあります。^{[ 97 ]}

耐障害性をサポートし、データセンターの規模を拡大し、低基数スイッチに対応するために、Google は過去にさまざまな改良型Closトポロジーを採用してきました。 ^{[ 98 ]}

Google 最大のデータセンターの 1 つは、ポートランドから約 80 マイル (129 km) 離れたオレゴン州コロンビア川沿いのザ ダルズという町にあります。「プロジェクト 02」というコードネームのこの複合施設は 2006 年に建設され、アメリカンフットボール場2 面ほどの大きさで、冷却塔は4 階建てです。^{[ 99 ] [ 100 ]}この場所が選ばれたのは、安価な水力発電を利用し、ドットコム ブームの名残であるこの地域の大量の光ファイバーケーブルの余剰を利用するためです。この場所の設計図は 2008 年に公開されました。^{[ 101 ]} 

2009年2月、Stora EnsoはフィンランドのハミナにあるSumma製紙工場をGoogleに4000万ユーロで売却したと発表した。^{[ 102 ] [ 103 ]} Googleはこの場所にデータセンターを建設するために2億ユーロを投資し、2012年にはさらに1億5000万ユーロの投資を発表した。^{[ 104 ] [ 105 ]} Googleはこの場所を再生可能エネルギー源の入手可能性と近接性から選んだ。^{[ 106 ]}

2013年、報道機関はカリフォルニア州（トレジャーアイランドのビル3）とメイン州の沿岸にGoogleの浮体式データセンターが存在することを明らかにした。開発プロジェクトは厳重な秘密の下で進められた。データセンターは長さ250フィート、幅72フィート、深さ16フィートである。海洋データセンター冷却技術の特許は2009年にGoogleによって購入された^{[ 107 ] [ 108 ]}（2008年には波力発電式船舶データセンターの特許も取得している^{[ 109 ] [ 110 ]}）。その後まもなく、Googleは秘密裏に建設された2つの巨大なインフラは単なる「インタラクティブな学習センター、[...]人々が新しい技術について学ぶことができる空間」であると宣言した^{[ 111 ] 。}

Googleは2013年後半にバージの作業を中止し、2014年にバージの売却を開始した。^{[ 112 ] [ 113 ]}

ほとんどの操作は読み取り専用です。更新が必要な場合、クエリは他のサーバーにリダイレクトされ、一貫性の問題が簡素化されます。クエリはサブクエリに分割され、それらのサブクエリは並列に異なるダクトに送信できるため、レイテンシ時間が短縮されます。^{[ 92 ]}

避けられないハードウェア障害の影響を軽減するため、ソフトウェアは耐障害性を備えるように設計されています。そのため、システムがダウンしても、データは他のサーバーで引き続き利用可能であり、信頼性が向上します。

ほとんどの検索エンジンと同様に、Google は転置インデックスと呼ばれるデータ構造を構築することでドキュメントをインデックス化します。このようなインデックスは、クエリワードによってドキュメントのリストを取得します。サーバーに保存されているドキュメントの数が多いため、インデックスは非常に大きくなります。^{[ 95 ]}

インデックスは、ドキュメント ID によってシャードと呼ばれる多数の断片に分割されます。各シャードは複数のサーバーに複製されます。当初、インデックスは従来の情報検索(IR) システムと同様にハードディスク ドライブから提供されていました。Google は、各シャードのレプリカの数を増やし、サーバー数を増やすことで、増加するクエリ量に対応しました。まもなく、メイン メモリにインデックス全体のコピーを保持するのに十分なサーバーがあることがわかり (ただし、複製は少ないかまったく行われませんでした)、2001 年初頭に Google はイン メモリ インデックスシステムに移行しました。この移行により、検索システムの「多くの設計パラメータが根本的に変更」され、スループットが大幅に向上し、クエリのレイテンシが大幅に低下しました。^{[ 131 ]}

2010 年 6 月、Google は、検索インデックスを継続的にクロールして更新できる次世代のインデックス作成およびサービス システム「Caffeine」を発表しました。以前は、Google はMapReduceジョブを使用して検索インデックスをバッチで更新していました。インデックスはいくつかのレイヤーに分割され、一部のレイヤーは他のレイヤーよりも速く更新され、メイン レイヤーは 2 週間も更新されないことがありました。Caffeine では、インデックス全体が継続的に増分更新されます。その後、Google は、Caffeine インデックス システムの基礎となっていると言われる分散データ処理システム「Percolator」^{[ 132 ]}を発表しました。^{[ 124 ] [ 133 ]}

Googleのサーバーインフラストラクチャはいくつかのタイプに分かれており、それぞれ異なる目的に割り当てられています。^{[ 92 ] [ 95 ] [ 134 ] [ 135 ] [ 136 ]}

• ウェブサーバーは、ユーザーから送信されたクエリの実行を調整し、結果をHTMLページにフォーマットします。実行プロセスは、インデックスサーバーへのクエリ送信、結果の統合、ランキングの計算、各ヒットの要約の取得（ドキュメントサーバーを使用）、スペルチェックサーバーへの候補の問い合わせ、そして最後に広告サーバーからの広告リストの取得で構成されます。
• データ収集サーバーは、ウェブを巡回するために常時稼働しています。GoogleのウェブクローラーはGoogleBotと呼ばれています。これらのサーバーは、インデックスとドキュメントのデータベースを更新し、Googleのアルゴリズムを適用してページにランキングを割り当てます。
• 各インデックスサーバーは、一連のインデックスシャードを保持しています。インデックスシャードは、特定のドキュメントID（「docid」）に対応するドキュメントにクエリワードが含まれるように、ドキュメントIDのリストを返します。これらのサーバーはディスク容量は少なくて済みますが、CPU負荷は最も高くなります。
• ドキュメントサーバーは文書を保存します。各文書は数十台のドキュメントサーバーに保存されます。検索を実行すると、ドキュメントサーバーはクエリ語に基づいて文書の要約を返します。また、要求に応じて文書全体を取得することもできます。これらのサーバーにはより多くのディスク容量が必要です。
• 広告サーバーは、 AdWordsやAdSenseなどのサービスが提供する広告を管理します。
• スペルチェックサーバーは、検索クエリのスペルに関する提案を行います。

また、「カナリアリクエスト」と呼ばれるものもあり、これはリクエストをまず1つまたは2つのリーフサーバーに送信して、応答時間が妥当かどうかを確認するものです。妥当でない場合は、リクエストは失敗します。これによりセキュリティが確保されます。^{[ 137 ]}