JTF2017 基調講演
「ITエンジニアリングの本質」を考える
2017/08/27
Google Cloud, Cloud Solutions Architect
中井 悦司 / Etsuji Nakai

Etsuji Nakai
Cloud Solutions Architect at Google
Twitter @enakai00
$ who am i
https://www.dlmarket.jp/products/detail/501016
（同人誌）

「ITエンジニアリングの本質」とは？

「ITエンジニアリングの本質」とは？

「ITエンジニアリングの本質」とは？
When I was younger and first started
thinking about my future, I decided to
either become a professor or start a
company. I felt that either option would
give me a lot of autonomy
--- the freedom to think from first principle
and real-world physics rather than having
to accept the prevailing "wisdom."
「世に蔓延する常識を受け入れるのではな
く、現実世界を動かす第一原理にもとづい
て思考する自由」

Datacenter as a computer!

1Pbps のデータセンタースイッチ！
素朴な疑問
● どういう意味において1Pbpsなの？
● 何が目的で開発したの？
● 開発中に苦労した事は？
● などなど・・・
本日のお題：Jupiter Network

元ネタはこちら
https://research.google.com/pubs/pub43837.html
https://www.youtube.com/watch?v=DfaPcbofT2c

● データセンターネットワーク
○ 複数のサーバークラスターを均一な帯域で接続する高速ネットワーク
○ ソフトウェア制御の Clos トポロジーによるロードバランシング
● B2 ネットワーク
○ インターネットと相互接続するためのグローバルネットワーク
● B4 ネットワーク
○ データセンター間を相互接続するグローバルな内部ネットワーク
○ OpenFlow を用いたトラフィックエンジニアリングにより、パケットの優先順位に
応じてパケットの経路と帯域を自動制御
Google ネットワークの全体像
今日はここの話！

● Clos トポロジー：メッシュ型の多重経路で接続された L2 ネットワーク
● 複数経路をロードバランスすることで、特定のリンクがボトルネックになることを回避
● ロードバランスのための経路情報をソフトウェアで自動制御
データセンターネットワークの特徴

データセンター
ネットワーキング
Jupiter Rising: A Decade of Clos Topologies and
Centralized Control in Google’s Datacenter
Network (Sigcomm 2015 での論文)

● 複数クラスターを構成する数万台のサーバー
● 12 年前は帯域が分離されてボトルネックが発生
○ アプリ側で通信の局所性の考慮が必要
○ CPU / メモリーの有効活用が困難
○ スケーラビリティーに影響
データセンター ネットワーキングの大きな課題
Datacenter
1 Gbps /
machine
within rack
100 Mbps /
machine
within small
cluster
1 Mbps /
machine
within
datacenter

● 技術的挑戦 : すべてのサーバ一で帯域を均一化
○ ジョブ スケジューリングの簡素化
○ アプリ配置の最適化で CPU／メモリーを有効活用
○ スケーラビリティの向上
データセンター ネットワーキングの大きな課題
X Gbps / machine
flat bandwidth
Datacenter

● マーチャント シリコン : 汎用部品、
コモディティ価格、容易に入手可能
● Clos トポロジー :リンク数の少ない
チップを用いながら、レイヤーを追
加することで、自由にスケーリング
● 集中制御 / 管理
設計上の基本方針

Google データセンターを支えてきた 5 つの世代の
ネットワーク スイッチ
Edge Aggregation
Block 1
Edge Aggregation
Block 2
Edge Aggregation
Block N
Spine
Block 1
Spine
Block 2
Spine
Block 3
Spine
Block 4
Spine
Block M
Server racks with
ToR switches

課題
● 大規模でのオペレーション
● 拡張性の高いルーティング / 大規
模マルチパスによるルーティング
● 外部ベンダーとの相互運用性
Google のアプローチ
● 集中的な構成と管理
● 分散環境を論理的に集中管理
● 境界ルータでの BGP スタックの統合
データセンタースイッチの特徴 : 制御と管理

ソフトウェアによる経路制御 : Firepath
Firepath Master
Firepath
Client 1
Firepath
Client 2
Firepath
Client N
Interface state update
Link State database
FMRP protocol
コントロール
プレーン
FMRP

ソフトウェアによる経路制御 : Firepath
Firepath Master
Firepath
Client 1
Firepath
Client 2
Firepath
Client N
(Border router)
Firepath Client,
BGP 1
(Border router)
Firepath Client,
BGP M
External BGP peers
Interface state update
Link State database
FMRP protocol
eBGP protocol (inband)
FMRP
コントロール
プレーン

Firepath のソフトウェアスタック

課題
● チップ上のバッファ容量不足
● 安価 / 信頼性の低い部品の可用性
Google のアプローチ
● スイッチ（ECN など）とホスト
（DCTCP など）のチューニング
● ソフトウェアによる冗長性担保
● 必要なものだけを実装
パフォーマンスと信頼性の実現

Saturn
Firehose
1.0
1T
10T
100T
1000T
‘04 ‘05 ‘06 ‘08 ‘09 ‘12
Bisection
B/w
Year
Watchtower
Firehose
1.1
4 Post
Jupiter

Saturn
Firehose
1.0
1T
10T
100T
1000T
‘04 ‘05 ‘06 ‘08 ‘09 ‘12
Bisection
B/w
Year
Watchtower
4 Post
Jupiter
+ 2012年 データセンター内で 1.3Pbps
Firehose
1.1

Google データセンターにおけるネットワーク スイッチの変遷
Firehose 1.1
(2006)
Watchtower
(2008)
Saturn
(2009)
Jupiter
(2012)

データセンター内トラフィックの増加
Traffic generated by servers in our datacenters
Aggregatetraffic
50x
1x
Jul ‘08 Jun ‘09 May ‘10 Apr ‘11 Mar ‘12 Feb ‘13 Dec ‘13 Nov ‘14
Time

論文から読み解く
Jupiter 開発の歴史

第１世代：Firehose 1.0
● サーバー筐体に PCI 経由で制御するスイッチングチップボードを搭載
○ Linux の起動時間と HW の信頼性に課題
○ 本番採用は見送り

第２世代：Firehose 1.1
● ネットワークチップを収める専用筐体（ラインカード）を設計
● ６枚のラインカードを１台のシャーシに搭載
○ シャーシは、スイッチ間を内部接続するバックプレーンを持たない
○ ポート間接続には CX4（10G対応のメタルケーブル）を使用

第２世代：Firehose 1.1
● その結果
○ ケーブル地獄・・・
○ CX4 ポートをファイバーに
変換する専用コネクタを
発注・・・

第２世代：Firehose 1.1
● はじめての本番投入！
○ 安全のため既存のルーターシステムと並列に接続
○ 問題発生時は、既存のルーターにフォールバック

第３世代：Watchtower
● バックプレーン付きのシャーシを
採用
● ファイバーバンドル（複数のファイ
バーを束ねたケーブル）を採用
○ すっきり！

第４世代：Saturn
● Watchtower の性能向上版
● チップあたりのポート数増加
● ToR にも 10Gbps ポートを採用

第５世代：Jupiter
● バックプレーンを持たない構造を再び採用
● Centauri モジュールを組み合わせるブロック方式を採用
● 40Gbps / 4 x 10Gbps 切り
替え型チップを採用

第５世代：Jupiter
● Centauri x 1：ToR スイッチ
● Centauri x 4：Middle Block
● Middle Block x 8 : Aggregation Block
○ ラック 2 本に 1 つの Aggregation Block
がちょうど収まる構成
● Middle Block x 6 : Spine Block
● Spine Block x 256 + Aggregation Block x 64
の最大構成で総帯域 1.3Pbps を達成
Middle
Block

まとめ

「ITエンジニアリングの本質」とは？
JTF2017 の会場でお話します！

（補足）分散ストレージを支える仕組み
● すべての計算ノードがすべてのストレージノードに同じ帯域で接続可能
計算ノード
ストレージ
ノード
ストレージ
ノード
ストレージ
ノード
分散ストレージ
ノンブロッキング・ネットワーク
計算ノード 計算ノード 計算ノード
ストレージ
ノード
ストレージ
ノード
ストレージ
ノード
分散ストレージ
ノンブロッキング・ネットワーク
計算ノード追加

Google のインフラを一般開放した Google Cloud Platform
VIRTUAL NETWORK
LOAD BALANCING
CDN
DNS
INTERCONNECT
Management Compute Storage Networking Data
Machine
Learning
STACKDRIVER
IDENTITY AND
ACCESS
MANAGEMENT
CLOUD MLE
SPEECH API
VISION API
TRANSLATE API
NATURAL
LANGUAGE API

公開論文から読み解くインフラ技術の「思想」
● 「謎技術」の実体は、徹底的な合理主義
● 「技術的制約」に対する恐ろしいほどの洞察力
○ この制約を受けいれることが何が可能になるのか？
○ この制約を打破することで何が可能になるのか？
http://www.school.ctc-g.co.jp/columns/nakai2/

参考文献
● Jupiter Rising: A Decade of Clos Topologies
and Centralized Control in Google’s
Datacenter Network (Sigcomm 2015)
● B4: Experience with a Globally-Deployed
Software Defined WAN (Sigcomm 2013)
● BwE: Flexible, Hierarchical Bandwidth
Allocation for WAN Distributed Computing
(Sigcomm 2015)
● Evolve or Die: High-Availability Design
Principles Drawn from Google's Network
Infrastructure (Sigcomm 2016)

Thank You.