Facebookのデータセンタネットワーク
これはhttp://www.adventar.org/calendars/440の２日目の記事です．
はじめに
本エントリでは，最近のデータセンタNWのトポロジについて，データセンタNWの最先端を走っているfacebookの事例をベースに，論文/blog等交えて簡単に紹介したいと思います．
一般的なデータセンタNW
まず，現在のDC向けネットワークトポロジの基本となるFat-Treeについて。
Fat-Treeは，一般的なツリーでボトルネックとなる上位階層のリンク帯域を太く/多重化したツリー構成を持つNWトポロジです。
各段のスイッチの上流/下流が同じ帯域幅を提供するように構成することで、Fat-Treeに接続するノードが全体全の通信を一斉に行う最悪のケースにおいても、リンク帯域の食い合いを発生させることなく、ノード間通信の帯域を保証することが出来ます。
このように構成されたネットワークの事をフルバイセクションネットワークと呼びます。
ネットワークがフルバイセクションであることは、特にMPI等のall-to-all通信を頻繁に行うHPC分野では重要な特性ですが、一般的なDCネットワークでは、ノードの収容効率を高めるため下流に比べて上流が細い(oversubscription)構成が一般的でした。
このへんの話はこのスライドがオススメです（Infinibandですが基本的な考え方は変わりません）
"4-post" Architecture
FacebookのDCにおいても、2013年頃に公開された論文によると，
Fat-Treeにリングを追加した亜種のようなトポロジを採用しており，上流下流の接続だけを見ると，CSWスイッチで10:1,FCスイッチで4:1のoversubscriptionがされています．
このトポロジは，DC内のInter-Clusterの通信帯域を一部犠牲にして，ノードの収容効率を高めたトポロジと言えます．
論文よりトポロジ図を引用します．
論文によると，当時の時点でこの巨大なCSW/FCスイッチに依存するトポロジは以下の点で問題があったと書かれています．
- CSW/FCスイッチに障害が発生した場合，それぞれintra/inter clusterの帯域幅が25%失われる
- CSWスイッチのサイズがclusterのサイズを決定づける．そのため，非常に大きいclusterとなる
- スイッチを提供可能なベンダが限られ，結果としてOPEX/CAPEXの増加を招く
- スイッチ内部のfabric自体がoversubscriptionしていることがあり，全てのポートをwirerateで同時に利用できないことがある
- 巨大なスイッチは数売れるものではないため，ベンダのバグフィックスに時間がかかり，カスタムプロトコルなどの実装も困難
この問題に対して，上記論文では他のHPCなどで利用されているトポロジ等を参考に，柔軟にscale-out可能で，高性能スイッチに依存しないトポロジの検討が行われています．
fabric Architecture
検討の結果が結実したと思われるのが，2014年11月にdeployされたFacebook Altoona Data Centerです．
Altoona DCの新しいネットワークアーキテクチャに関しては，Facebook Engineer blogに情報があります．
この新しいネットワークアーキテクチャでは，4-post architectureに関する論文で指摘のあった問題に加え，指数的に増加するDC内のノード間通信(west-east traffic)に対応するために工夫がされています．
トポロジ構成
トポロジ構成上のポイントは以下のとおりです．
- 48台のToRを4台のFabricスイッチで束ねた単位(pod)をunit of networkとして定義し，pod単位での柔軟なコンピューティング能力の拡張を可能にした
- intra-cluster/inter-cluster/north-south trafficそれぞれについて，Planeという単位で分割を行うことで，それぞれ独立した性能拡張を容易に
- 指数的に増加するeast-west trafficに対応するため，oversubscriptionを基本的にはしない構成とした(pod内fabric switchは上流下流共に同一ポート数)
以下，blogよりトポロジ構成図を引用します．
この図からは，小さいpodという単位をベースに，intra/inter/north-south traffic用のplaneが分割されていることがわかると思います．
結果，computing resourceを追加する場合はpodを，intra-clusterの帯域を増強するためにはspineスイッチを，north-southの帯域増強のためにはedge pod/uplinkを増強するなど柔軟な機能拡張を行うことが可能になっています．
ネットワーク制御
DC内は，ToRからedgeまですべてBGPベースのL3ネットワークで構成されています．
装置側は一般的なBGP Stackを用いている一方，blogにはcentralized BGP controller というものを開発したとあり，基本的にはBGPの一般的な経路制御を行い，一部集中制御で明示的にパス決定し，BGP経由で注入できる仕組みが入っているようです．
この辺りは詳細の記述がblogにないため，続報が待たれるところです．
物理構成（フロアプラン）
podで小さなクラスタを作ることで，論理トポロジを柔軟に拡張可能であることは前述したとおりですが，
この柔軟性は，物理構成にも同様の柔軟性を与えています．
以下，blogより物理構成図を引用します．
inter-clusterの相互接続を提供するspine-planeがBDF roomと呼ばれる部分に集約されており，実際のコンピューティングノード(pod)が収容されているMDF roomとは直線的に配線されています．
そのため，施工がしやすく，podを追加する場合もMDF roomのBDF roomに近い側から順次サーバラックを増設していくことで物理構成上も見通しの良い拡張が可能となっています．
まとめ
本エントリでは主にFacebookのDCネットワークについて，論文/blogからの引用をベースに紹介を行いました．
今回紹介した内容以外にも，Altoona DCの構成についてはFacebook Engineer blogにその他いろいろ情報があるので，気になった方はblog本体を参照することをオススメします．
おまけ
FacebookのDCネットワークに関しては，SIGCOMM2014で発表されたFastPassなども関連があるようです．
現状productionで動いているわけではない？ようですが，著者にFacebookの方が入っており，評価も実DCでやったような事が書かれています．
詳しくはまだ読んでいないのですが，ネットワークワイドにパケットの送出タイミングを集中制御するアービタを実装することで，パケットがスイッチのキューに貯まることを防ぎ，east-west trafficのRTTを改善するようなもののようです．
アービターというとPCI Busのようなガチガチのタイミング制御を思い浮かべるのでIPネットワークでアービタ？ホントにできるの？という感じが若干していて気になるので，今週末のシステム系論文輪読会３で読もうかなと思ってます．
