networking

Facebookが分散ネットワーキング〜ルーティングソフトウェアOpen/Rをオープンソース化

Facebookはこれまでも、内製のさまざまなソフトウェアやハードウェアをオープンソースのコミュニティに寄贈してきた。そして、今日(米国時間11/15)またまた同社がオープンソース化したのは、同社のモジュール構造のネットワークルーティングソフトウェアOpen/Rだ。

Facebookは当然ながら、ネットワークの運用に関してFacebookならではの、ど外れたスケールのニーズを抱えている。何十億ものユーザーがリアルタイムでメッセージングし、絶え間なくコンテンツをストリーミングしている。そのため、独特の問題を数多く抱えるFacebookは、中でもとくに、ネットワークのトラフィックに関して、従来的なプロトコルでは間に合わないのでそれらを使わないルーティング技術が必要、と痛感していた。

Facebookの技術部長Omar Baldonadoは、こう説明する: “Open/Rは、分散ネットワーキングアプリケーションのためのプラットホームだ。それは、ネットワークの、さまざまな部分の上で動く。そしてそのために、これまでのルーティングプロトコルを使わずに、現代のさまざまなネットワークをプログラミングしコントロールする自由度をわれわれに与える”。

それは最初、FacebookのワイヤレスのバックホールネットワークTerragraphのために開発されたが、Facebookのネットワークバックボーンなどそのほかのネットワークでも使えることに、すぐに気づいた。Facebookのネットワーク本体の中でさえも、それは使える。

同社のトラフィックは常時きわめて大きいし、その条件も頻繁に変化している。そんなネットワーク上では、トラフィックをルーティングするための新しい方法が必要だった。“ネットワーク全体にわたるトラフィックの動的な条件を考慮に入れながら、アプリケーションごとに最良の経路を見つけたい(ルーティングしたい)、と思った”、とBaldonadoは語る。

しかし、社内だけでもそれだけの応用性があるのなら、パートナー各社やそのほかのネットワーク運用者、それにハードウェアのメーカーらは、このツールの能力をさらに拡張できるはずだ。このツールでは実際にJuniperやAristaなどのパートナーとすでに協働していたが、完全にオープンソースにすれば、デベロッパーたちが、Facebookが考えもしなかったことをその上に実装していくだろう。というわけでFacebookの技術者たちは、これをオープンソースにすることの将来性と、それがもたらす価値について、前向きに考えるようになった。

Facebookもそうだが、そのほかの大手Web企業も、ネットワーキングのソフトウェアやハードウェアをますます多くオープンソース化し始めている。最初は完全に自分たちのコントロールの下(もと)にソフトウェアを完成させ、そのあと、それをオープンソースにして、ほかの人たちの能力による改良を期待するのだ。

“このツールは、ネットワークの分散化〜非集積化(バラバラ化)という今および近未来のトレンドの一環だと思う。ハードウェアと、その上のソフトウェアの両方をオープンにすれば、それは誰にとっても利益になる”、とBaldonadoは述べている。

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

インフラストラクチャのマーケットプレースInflectがサービスプロバイダー30社データセンターとピアリングロケーション2200を新たに加える

サンフランシスコのInflectは、企業が適切なコロケーションファシリティやネットワークサービス、エクスチェンジプロバイダーなどを見つけようとしているとき、それをより容易にしてくれるスタートアップだ。2か月前にローンチしたばかりの同社は今日(米国時間8/24)、そのデータベースに新たに30あまりのサービスプロバイダーと約2200のデータセンター、およびネットワーキングのピアリングロケーションを加えたことを発表した。新しいサービスプロバイダーには、CenturyLink, Cogent, Comcast, Equinix, Level 3, T5, Telstraなどこの業界のヘビー級のプレーヤーたちも含まれる。

ネットワーキングやコロケーションのプロバイダーの詳細情報や課金情報は、あまり簡単には得られない。データや通信の企業は、非常に古いタイプの営業過程を経て契約が決まることが多く、その過程は透明性が乏しい。シードで200万ドルを調達したInflectは、そういった過程を21世紀にふさわしいものにしたい、と考えている。同社はデータをプロバイダーやPeeringDBのデータベースから自分で集める。後者は、ネットワークのピアリング情報を得るためのデファクトスタンダードだ。InflectはPeeringDBのデータをもらい、それを同社独自の検証処理にかける。そして情報のどこをどう変えたかを、PeeringDBと共有する。

協同ファウンダーでCEOのMike Nguyenはこう語る: “ここまで数週間のローンチ直後の反応は、嬉しいものであると同時に、反省を迫られるものでもあった。ユーザーは私たちに、正確で特定ベンダーに傾かないデータを低コストで提供するInflectのようなプラットホームをずっと求めていた、と言う。しかし同時に、サービスプロバイダーたちは、実際にこれから買おうとしている買い手の目の前に、自分たちのサービスを置いてくれるようなプラットホームを探していた、と言うのだ”。

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

GoogleのCloud Platformが自社の高速ネットワークを使わない低能力な廉価版ネットワーキングを提供

Googleのクラウドプラットホーム(Cloud Platform)に、廉価版が加わる。これまでの高級版(Premium Tier)は、できるかぎりGoogle自身の高速ネットワークへユーザーのトラフィックをルートして、中継と距離を最小化する。そして今度の安価な標準版(Standard Tier)では、トラフィックを一般の公共的なインターネットにルートし、起こりうる速度低下や中継の増加を我慢していただく。これからのデベロッパーは、そのどちらかを選べる。

Googleのインフラ担当SVP Urs Hölzleは曰く: “これまでの18年間で、Googleは世界最大のネットワークを築き、今ではそれがインターネットの全トラフィックの25-30%を配達していると推定される。Premium Tierではその同じインフラを享受できるが、しかしユースケースによっては、安価で低能力なネットワーキングを選んでもよい。両者を合わせたサービスをNetwork Service Tiersと呼んでいるが、アプリケーションごとに、もっとも適したネットワークをお選びいただける”。

北米およびヨーロッパでは、標準版は高級版より24-33%安い。また課金方式は、高級版ではトラフィックの起点から終点までの距離で計算されるが、標準版は距離は関係なく、起点がどこにあるかによって、料金が異なる。

今現在は、Google Cloudの全ユーザーがいわゆるPremium Tierを使っている。トラフィックはできるかぎりGoogle自身のネットワークを通り、そして同社のエッジネットワーク上に存在する100あまりのグローバルポイントのどれかで、よりワイドなインターネットへ渡される。ちなみに、このように、できるかぎり長く起点ネットワークがトラフィックを保持する方式をcold-potato routing(コールドポテトルーティング)と呼ぶ。この方式では遅延が最小化され、トラフィックはGoogle自身のケーブルを通るから、パケットロスも少ない。このことは、アプリケーションからユーザーへの往路だけでなく、ユーザーからアプリケーションへの帰路についても、同様に言える。帰路ではトラフィックはできるだけ早くGoogleのエッジネットワークに渡され、そして企業のデータセンターへと旅をする。

新たにできたStandard Tierでは、トラフィックはGoogleのネットワークではなく一般的な(公共的な)インターネットへ渡される。そしてトラフィックは、ネットワークからネットワークへ、ISPからISPへと中継されるから、当然、単一のネットワーク上より遅くなる。クラウドサービスでも、Googleのような大きな自前ネットワークを持ってないところを使うと、このStandard Tierと同じ結果になる、とGoogleは宣伝っぽく言っている。

この二種類のネットワーキングのパフォーマンスの測定と公共的なモニタリングを、GoogleはCedexisと協働して行っている。当然ながらStandard Tierではスループットが遅く、遅延(レイテンシー)は高い。より顕著なのは、レイテンシーの違いよりもむしろ、スループットの違いである。

なお、Standard TierではGoogleのグローバルロードバランサーとCloud CDNが使えない。代わりに、リージョン内のロードバランサーを使わなければならない。

アプリケーションの特性やニーズによって、どちらのネットワーキングを使うべきか迷ったときは、Googleが作った下図のフローチャートを使ってみよう:

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

Google Cloud、新しいネットワーキングアルゴリズムでスループット向上へ

今日(米国時間7/20)Googleは、google.comやYouTubeなどのネットワークスループットを全世界で約4%改善した新しい輻輳制御アルゴリズム、TCP BBRを、Cloud Platformユーザーにも開放すると発表した

基本的な考えは、既存のインターネットトラフィック用輻輳制御アルゴリズムを改善することにある。現在使われているのは 1980年代からあるもので、パケットロスのことしか考慮していなかった(ネットワーキングバッファーがいっぱいになると、ルーターは新しいパケットを捨てる)。こうしたアルゴリズムは過負荷にならないためにはデバイスがどれだけ速くネットワークにデータを送ればよいかを決定する。最終目的地に到達しないデータパケットの存在にシステムが気づくと、データをゆっくり送る。理想的にはこれで輻輳を減らすことができる。これを実現する(そしていずれはまたスピードアップする)ためのアルゴリズムは数多く存在するが、核となる部分はみな同じパターンを踏襲している。

“Bottleneck Bandwidth and Round-trip propagation time”[ボトルネック帯域幅往復伝搬時間]を意味するBBRは、異なるアプローチをとる。パケットロスだけでなく、ネットワークが実際にデータを届ける速さを考慮する。「あるネットワーク接続について、ネットワーク転送速度および往復時間の最新データを使って、この接続で利用できる直近の最大帯域幅と、最低往復遅延時間を含む明示的モデルを構築する」とGoogleは説明する。次にBBRがこのデータを利用してデータを送る速さを決める。

その結果、このアルゴリズムは与えられた時間内に(パケットロス無しに)より多くのデータを送ることができる。長距離のリンクでは特に顕著だ。Googleは、あるベンチマークでスループットが2700倍になったと言っているが、もちろんそれは人工的なベンチマークの極端なケースだ。

GoogleがBBRについて公の場で話したのは昨年の論文が最初で、その後プロトコルをオーブンソース化した。GoogleはLinuxのカーネルTCPスタックにも貢献している。

[原文へ]

(翻訳:Nob Takahashi / facebook