17th - Google の DC 間接続

先日参加した台湾での SDN シンポジウムの話題を "シンポジウムの話題三つ" で取り上げたが、それ以外にもう一つ、Google のデータセンター間接続のことについてメモしておこうと思う。
SDN Use Case スピーカーは Victor Lin。Tech Lead Manager となっていた。後で少し聞いてみると彼はここ何年かで Google に join したそうで、この DC 間接続システムである B4 はもう動き出してから三年になるから、結局 Google に入ってからずっとこのことをやってるのだそうだ。
今日、彼のセッションのもとになったであろう論文、"B4: Experience with a Globally-Deployed Software Defined WAN" にようやく目を通した。（なお Lin は執筆者ではない）
これと彼が話したことから幾らかピックアップしておく。
B4 論文から： SDN というのは結局のところ「新しい（または必要な）機能をコントローラに（プログラムとして）実装する」ことに他ならない。その意味で B4 における彼らの SDN アプリケーションは Traffic Engineering だった、ということらしい。やはりシンポジウムでPica 8 の James Liao が「SDN における Killer Application は何か？」と問うてすぐ「実は無いんだ、その代わりにまわりにいっぱい（適用すべき事が）ある」と言っていたが、正にそう言うことなのだと思う。
Google はトラフィックエンジニアリングのために SDN を使った。以上。

source: Sushant Jain, et al., 2013
それ以外のことはない、というか、ある目的のために道具として OpenFlow を選び、まっすぐに自分達のために実装した、というのがとても良い。ただそこは Google で、論文では彼らは自分達の目的のために OpenFlow をそのまま使わず slightly extend version にしてまで最適化したと述べており、相変わらずだなあ、と思う。
（論文には他にも興味深いことがあるが今日はコメントしない。またいつか。）
セッションから： B4 とそのアプローチの良いところとして、Lin は幾つかのことを挙げていた。shadow mode によるテストのことなどいろいろあるが、ここでは逐一挙げない。
個人的にグッときたのは「新しい architecture choices」 として機能をコントローラに入れるかスイッチに入れるかどちらが良いか、といったことを挙げていたことだ。まあ link failure などに際してスイッチが局所的に素早くリカバリするか、global view のあるコントローラが全体最適解を出すのが良いか、とかそんな話なのだけれど、それだけでなくスイッチ上に載せるよりコントローラ側に載せる方が開発速度が早い、と言っている。このあたりはとても Google 的だ。
OpenFlow などの SDN 的なアイディアは基本的に全ての知的な処理をコントローラに集めろ、としているが、何しろ新しいアイディアなのだから、こうした様々なトレードオフについて継続的に考え続けなければ。固まるのはまだ早い。
そして固まる、というアイディアとは真逆に、Lin は「ところでもうSDN って（BGP みたいな）標準化が必要？」と恐ろしい事を言っていた。結局 API じゃないの？と。
僕は開発、トラブルシュートの支援が SDN にはどうしても必要だと思い続けている（15日の記事参照）ので、いやいやモニタリングツールみたいなものには絶対標準化が要るんですけど!!! と思ってしまった。
実際 Lin はすぐその後でコントローラに要求されるもの、として「より良いマネジメント、トラブルシュートのサポート」を挙げていた。これはコントローラが「目的の機能を実装する」こと以外にある程度以上関与すべきことであるし、また周辺のツールの仕事でもあると僕には思える。
彼はまた Web アプリみたいに開発には「良いツールが要る」と言っていた。そこは本当だと思うし、それはまたいかにも Google 的なコメントだなあ、と感じた。

References