GoogleはなぜJupiterネットワークを独自に開発したのか
中井氏は、書籍『How Google Works』のまえがきにある、Googleの共同創業者であるラリー・ペイジ氏の言葉
世に蔓延する常識を受け入れるのではなく、現実世界を動かす第一原理にもとづいて思考する自由
を引用し、ITエンジニアは過去にとらわれずに現実の世界で何ができるかを考えていくことが重要なのではないかと提言した。Googleは「Datacenter as a Computer」という考えのもと、データセンター内の数千台のサーバーを分散ソフトウェア技術により束ねて、あたかも1台のコンピュータのように利用できる環境を提供している。現実的に見える目標でも、達成するまでにはたくさんの課題に直面し、途中で挫折することも多い。失敗してもそれを乗り越えてきたからこそ、Googleの今がある。中井氏は、ITエンジニアの本質を考える題材として、GoogleのJupiterネットワークの事例を取り上げた。
JupiterネットワークはGoogle独自のデータセンターネットワークで、複数のサーバークラスタを均一の帯域で接続している。メッシュ型のClosトポロジーを採用し、L2でソフトウェアによるマルチパスのロードバランシングを行う点が特徴的だ。開発を開始したのは2005年頃。当時データセンター内では、同ラック内でのサーバー間通信は1Gbpsだが、ラック間は100Mbps、クラスタ間は1Mbpsまで低下することが問題視されていた。Googleが開発するアプリケーションは分散型で、複数のコンポーネントが多量のサーバー上で並列稼働して機能を提供するが、ネットワークの帯域が均一でないとコンポーネント間の通信がボトルネックとなってしまう。同じアプリケーションのコンポーネントを距離の近いラックにまとめてデプロイするといった対処が必要で、クラスタを越えてスケールできないといった課題があった。
この課題を解決するには、データセンター内ではラック、クラスタに関係なく、サーバー間通信の帯域を全て同じにすればよい。これを実現するために採用されたのがClosトポロジーである。
例えば、スイッチに接続している状態でサーバーだけを追加していくと、サーバー間通信の帯域が低下し、ボトルネックが発生してしまう。そこで、サーバーとスイッチをペアで追加し、そのペアのグループを複数の上位レイヤーで相互接続して、縦にレイヤーを増やすと同時に横にもサーバーを増やすことで、サーバー1台あたりが利用できる帯域を低下させずにサーバーを追加できるようにする。Googleらしさが垣間見えるのは、ルーティングをソフトウェアで行っている点だ。各スイッチは、最初はデフォルトの構成情報が投入されるが、その後は周囲との接続を適宜確認し、切断を検出するとその情報をマスタースイッチに送信する。マスタースイッチは最初の情報と各スイッチからの情報をもとに全体の状態を把握し、ルートを決定して各スイッチに差分の構成情報を送ってアップデートする。スイッチの構成情報を集中管理する、今でいえばSDN（Software Defined Network）のコントロールプレーンに相当する仕組みを12年前に考えていたのだ。
この技術的チャレンジはスムーズに進んだわけではない。特に難しかったのは性能と信頼性の確保だ。Googleはスイッチのラインカードや筐体は独自に設計・製作し、スイッチチップは既存品を購入して利用していたが、チップのバッファ容量の不足により性能が出ない、信頼性が低く壊れやすいといった問題が発生していた。この問題に対し、Googleのエンジニアはサーバーのネットワーク設定をチューニングすることで対応。スイッチはGoogleのデータセンター専用のものであり、Googleのエンジニアは自分たちが利用しているデータセンターネットワークについて理解している。だからこそ、バッファの容量不足をサーバー設定のチューニングで補うという発想ができ、全体的に最適な構成管理が可能になったといえる。
