【ネットワーク】OpenRで考える物事の順序。。やっぱり下からなんですよね。【Facebook】

ちょうど、おんなじようなこと考えていたんですが・・
OpenR
メッセージング転送はZMQ
Thift2は、
boost graph lib
で？作ったのは、
いいね:
関連

ちょうど、おんなじようなこと考えていたんですが・・

ちょっと違うんですが、NWにモジュールを入れてSDN的なことをやって行くのに、ドローン等の通信を補償するマルチホップ等の方法を検討しながら、ROSあたりで、Pubsub系のメッセージングを、NWのコントロールプレーンと、ドローン等の物理的な物のコントロールをして、映像や三次元のデータストリームなどをデータープレーンでやれるような仕組みを考えたら面白いなぁ～なんて、考えていたところだったんで・・・FacebookがOpenRっていう分散型のルーティングプラットフォームをオープン化したって話が出てて、ちょっと萎えています(笑)

で、ちょっと勉強してみようかと。。調べてみました。（間違っているかも知れないけど）

OpenR

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

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

SDNというSoftware Defined Networkの動きがかれこれ１０年ほど前からでていて、GoogleはEspressoなどを出していますし、各社いろんな動きがありますね。Googleがクラウド側（コンピュータの集まり）からの発展であるとすると、このFacebookは、ワイヤレスのNWからの進化系のようです。

これを見て、面白いなぁ～って思ったのは、いつも進化というかイノベーションは、端部の細部から始まるんですね。そして、軽いところから。。決して正常進化からは生まれてこない。（GoogleはPCどおしをつないだところの課題から、Facebookは、Terragraphという無線パスをつないだところの課題から発展しています）ある意味で課題を持っているところからすると、正常進化なのですが、今の仕組みを前提にしたところから生まれてこないという意味で正常進化ではないんですよね。

Terragraphって、60GHzを使ったWiFiのバックホールのようなものです。

イノベーションのジレンマの通りかもしれません。

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)

ドキュメントは、下記にあるようです。

新しいルーティングプロトコルというより、ルーティングをするプラットフォームと言っていますが、ルーティングの手順を完全に変えていますね(^^;

それを考えられるのが素晴らしいんですが。。

中のものは、

メッセージ転送バスとしてはZMQを、メッセージエンコーディングにはThriftを使用します。2つのモジュール（Store＆Sync、別名KvStore + Link MonitorのSpark）は、隣人と話し合います。伝統的なネットワークプロトコルとは異なり、ワイヤフォーマットやインタラクションロジックに焦点を当てるのではなく、これはThriftとZMQに委ねられています。

モジュールそれぞれは、boost graph lib, thrift2, ZMQ　という枯れた技術をしっかり使って開発されているんだそうです。

メッセージング転送はZMQ

こいつは、メッセージを、転送するんですが、１対１、Pub/Sub、マルチキャストなどいろんな転送方式をもっているもののようです。

概要は、

Overview of ZeroMQ from pieterh

が分かりやすいかな？

OpenStackなどでは、AMQPとかがサーバー間の通信で使われてて、IoTではMQTTが有名ですね。ZeroMQは、そういう意味では比較的新しいメッセージ転送の方法ですが、Terragraphはこれを使っていたということなんでしょうねぇ。

Thift2は、

Hbase（Hadoop）などのデータベースとのやり取りを行う方法ですね。

これを読むと、

Thriftは、インタフェース定義言語であり、多数の言語のサービスを定義して作成するために使用されるバイナリ通信プロトコルです^[1]。^[2]これはリモートプロシージャコール（RPC）フレームワークとして使用され、Facebookで “スケーラブルなクロスランゲージサービス開発”のために開発されました。ソフトウェアスタックとコード生成エンジンを組み合わせて、ActionScript、C、C ++、^[3] C＃、Cappuccinoなどのさまざまな言語およびフレームワークで記述されたアプリケーションに接続できるクロスプラットフォームサービスを構築します。、^[4] ココア、デルファイ、アーラン、囲碁、ハスケル、ジャワ、Node.jsの、Objective-Cの、OCamlで、パール、PHP、Pythonの、ルビーとのSmalltalk。^[5]のFacebookで開発されたが、それは今あるオープンソースのプロジェクトは、Apache Software Foundation。この実装は2007年4月のFacebookで公開された技術論文に記述されました。現在、Apacheでホストされています。^[6]^[7]

今はApacheがオープンソースとしてメンテしていますが、もともとFacebookのRPCとして開発されたものなんですね。Google で言うと、ｇRPCか。。

boost graph lib

ルーチングなどをするのには、グラフ理論というか、どういう風に枝を作っていくかとか、どのルートが最適かなどのことを考えないといけないのですが、それを担っているのが、こいつということなんでしょうね。

これ読んでも分からないから・・・こっちから読む方がいいですね。

bgl design and shortest path from Akira Takahashi

で？作ったのは、

サーバー間を繋ぐための経路を調べて、状態を覚えて、監視するプラットフォームですね。

KV-STORE：分散通信と状態複製を可能にする複製されたキー値ストアとして機能します。
スパーク：リンクローカルマルチキャストを使用してインターフェイス上でネイバー検出（隣のルータを検出する）を実行し、ネイバーアクティビティを報告します。
LinkMonitor：プラットフォーム経由でシステムインターフェイスを監視し、それらのSparkセッションを管理し、KV-STOREで検出されたネイバーをアドバタイズします。
PrefixManager：随時設定のための自動プレフィックスサブアロケーションを実行します。
決定：KV-STOREを介して学習されたトポロジ情報に基づいてルーティング情報を計算します。
FIB：プラットフォーム経由で計算されたルートをプログラミングするためのプロキシとして機能し、転送状態（計算されたルート）を維持します。
プラットフォーム：ターゲットハードウェアプラットフォーム用のルートプログラミングおよびインターフェイス検出ロジックを実装します。

らしいです(笑)。　もうそろそろ分からないけど、これが・・OpenComputeProjectのエッジスイッチとかに実装されて

FacebookのバックボーンNWに実装されている。

そして、オープンにした。

Google の　Espressoは、自分のクラウドを張り出して、CDNのような形で使って高速化をはかってて、これは、WAN、データセンターファブリック、ワイヤレスメッシュなどのNWのトポロジ（形というか、使われ方かな？）がなんでも同じ方法でコントロールしましょうっていう方向性で、どちらも、アプリケーションを早く、楽に動かそうってことですね。

本当に楽に早くなるのかは、まだ、実際は分からないでしょうけど。。

スゴイな。。って思った。

Alibabaとか、中国も、どんどん自分たちのバックボーンは独自に変えていってるんだろうなぁ~