はじめに

従来, L2モデルによるネットワーク設計は拡張性や高可用性の観点から, DCの弱点とされてきました. これはL2で使用されるプロトコルが多数のデバイス間でトラフィックを大量に送信するため, 冗長化構成を取りながらもフレーミングストームを回避するための策を講じる必要があったためです.
また, 従来のネットワークトポロジは, スケールインモデルであることから, ネットワーク帯域を拡張する際は, より大きくて高価な機器に交換します. さらに, 大きな機器ほど多くの機器と接続するため, 故障した際の影響範囲が大きくなることが懸念されます. そのため, DCネットワークは拡張に伴いますます複雑化し, 運用面やコスト面においてスケーラビリティは限界を迎えようとしていました.

近年では, これらの問題を受け, 多くのDCでIP-Closと呼ばれる, Closネットワークの原則を適用したIP-fabricが採用されています. Closネットワークは, L3ベースのアーキテクチャを用いることで, ブロードキャスト等のBUMトラフィックによる帯域圧迫を排除し, 安定性と拡張性を向上させます. また, BGPとBFDはベンダーに依存せず, L3で経路を制御するため, トラブルが発生した際も, 従来のIPのトラブルシューティングが適用可能になります.

今回の記事では, 実際に日本でIP-Closが採用されているヤフーにてClosネットワークの構築を経験してきたので, これを機に聞いた話や知見を含め, IP-Closについて調査・紹介しようと思います.

従来のDCネットワーク

一般的にDC内ネットワークでは, トラフィックを大きく「North-Southトラフィック」と「East-Westトラフィック」に分けて区別します. これは, ネットワーク構成図を描いた際に, 上部に外部ネットワークや基幹ネットワークを描き, 下部にいくにつれて末端スイッチやサーバ, その上で動作するアプリケーションを描くことが多いためです.

図に示す構成図において, インターネットトラフィックの方向性を示す際に, これらの言葉が利用されます.

North-Southトラフィックは, ユーザが各サービスへアクセスするトラフィックを指し, East-WestトラフィックはDC内の各サーバ間のトラフィックを指します. 従来, DC内のネットワークでは, インターネットに近い箇所では大量のトラフィックが入ってくるため, 帯域を広く確保し, 末端に行くほど帯域を細くする構成が多く見られました.
しかし, 2010年代前半の頃から, 多くの大規模DCではNorth-Southトラフィックに比べて, East-Westトラフィックが増加を示し始めました. これは, クラウド上のVM間通信やマイクロサービスアーキテクチャ等の発展に伴い, ユーザからのアクセスによるトラフィックよりもサーバ間やストレージ間の通信が増大したことに起因します.
そのため, 元々, North-Southトラフィック用に構成されていたネットワークでは, 末端の帯域が細いことが多いため, このトラフィックパターンの変動には耐えられず, 帯域を詰まらせてしまうことが問題 （East-Westトラフィック問題） になっていました.

East-Westトラフィック問題を受け, StackやVirtualChassis, L2-fabricによって対策を講じてきましたが, 各対策で一定の効果は見られるものの, どちらもL2ネットワークの拡張となるため, スケールアウトにおいて課題が残されていました.

スケーラビリティの限界

サーバスケールは数百台単位だったものが, 現在では多いもので数十万台単位にまで増加
近年ではコンテナ単位でインスタンスにデプロイし, 大規模クラスターによる運用が一般化しつつある.
BUMトラフィック処理によるオーバーヘッドの増加
時にはARPパケットやNDPパケットが帯域を食い潰すなんてこともあったらしい...
ネットワーク機器メーカーによって独自に実装されていることが多い
CiscoやTP-Linkは機器間でネイバーを発見するため, CDP等の独自プロトコルが用いられる.
導入や運用が複雑化し, メンテナンスコストも増大
冗長構成を取りながらもフレーミングストームを回避するための策を講じる必要があるため, アグリゲーション時などに思わぬ人的ミスを招く可能性がある.
また, Active-Standby方式ではフェールオーバーに伴うムダが少なからず発生する.

障害発生時におけるサービス提供のレジリエンス

L2ベースのアーキテクチャは単一機器の障害がトポロジ全体に影響する可能性がある.

これらの問題を解決するために, 近年では, 多くの大規模DC（Google, Facebook, Microsoft, ヤフーなど）でIP-Closと呼ばれるDCネットワークアーキテクチャが採用され, DCのネットワークトポロジが変遷してきました.

IP-Clos

IP-Closは, スケールアウトが容易なLeaf-SpineアーキテクチャをL3ベースで構築する技術です.
IP-Closの "Clos" とは, Closネットワークトポロジの原案を考案したCharles Clos氏に由来しています.
以下に, シンプルな2層からなるIP-Closを例に挙げて説明します.

ネットワーク機器にはSpineスイッチ, Leafスイッチと呼ばれる2種類のスイッチがあります. 図で一番上にあるのがSpineスイッチで, その下にあるのがLeafスイッチです. ここで全Leafスイッチは, 全Spineスイッチに接続されており, 全サーバは各々のLeafスイッチに接続されます.
Closネットワークはスケールアウトモデルで, 帯域の拡張にはSpineスイッチを追加することで対応が可能になります. また, 拡張が必要な場合, スイッチの層を増やすことで, より大規模なClosネットワークを構築することも可能です.

Closネットワークでは, 従来のネットワークで使用していたL2ブリッジングの代わりにL3ルーティングを使用します. L3を採用することで, ネットワークのスケーラビリティが高まるだけでなく, L2で利用されるSTPやVRRP等のプロトコルが不要になるため, ネットワークの安定性が高まり, トラブルシューティングの負担が大幅に削減されます.

Closネットワーク内のルーティングプロトコル

Closネットワークでは, ルーティングプロトコルとして BGP を利用します.
通常, DC内（AS内）では, OSPFやIS-ISを利用するケースが多いですが, リンクステート型のプロトコルは, リンクの状態の変化が他の機器に伝搬するという特性があります. 従って, 全スイッチ間を単一リンクで接続するIP-Closでは, 単一リンク障害時の影響がネットワーク全体に及ぶ恐れがあります. 故に, 規模が大きくなった際に, ネットワーク機器へのオーバーヘッドが大きくなるため, Closネットワークでの利用は推奨されません.
また, OSPFにはマルチプロトコルサポートがなく, IPv4ではOSPFv2, IPv6ではOSPFv3がそれぞれ必要になります. さらに, IS-ISはマルチプロトコルをサポートしているものの, ベンダー依存であるため, 機器の選択肢が制限されます.

一方, BGPはOSSも含めて成熟した堅牢な実装が多数存在します. また, 高速コンバージェンス可能な点や経路制御のしやすさなどからも, オープンスタンダードであるBGPを採用して構築されます.
BGPのDC内への適用は, これまでMicrosoft, Inc.のAzureチームが主導してきました.

ルーティングプロトコルの特徴まとめ

リンクステート型プロトコル：OSPF
- 同一AS内を接続する際に使用
- ルータ間で接続情報（LSP）を交換
- リンクコストによってルーティングを決定
- LSPのフラッディングによって全ルータがSPFツリーを構築し, ネットワークトポロジ全体を把握
  ➡︎ 一つの機器が故障すると, 他の全ての機器がSPFツリーを再構築しなければならない.
ディスタンスベクター型プロトコル：BGP
- 異なるAS間を接続する際に使用
- ルータ間で経路情報（ルーティングテーブル）を交換
- ホップ数によってルーティングを決定
- 隣接するルータ間でのみルーティングテーブルを交換するため, 各ルータはネットワークトポロジ全体を把握しない
  ➡︎ 一つの機器が故障しても, 隣接するルータ（関係するルータ）のみがルーティングテーブルを更新すれば良い.

Closネットワークのリンク

Closネットワークでは, ノード間は1本のリンクで構成することが推奨されます.
これは, Closネットワークで採用されるBGPがECMPによる負荷分散を行うためです.

また, 以下の図のようにport-channel等により複数のリンクを使用する場合, ノード間で1本のリンク障害が発生しても, BGPのECMPと見なされ続けます. 従って, 帯域が半分になったリンクに同量のトラフィックが送信され続けるため, ECMPでもパケットロスや遅延が増加します.

Equal Cost Multi Path: Leaf1-SW to Leaf2-SW
- Leaf1-SW => Spine1 => Leaf2-SW
- Leaf1-SW => Spine2 => Leaf2-SW

ここで, Leaf1スイッチからLeaf2スイッチへのECMPは2つありますが, Spine2スイッチとLeaf2スイッチの間のどちらかのリンクがダウンした場合, この間の帯域は他と比べて半分になります.

Closネットワークに収容できるサーバ台数

例えば, 以下の図のようにLeafスイッチのポート数がn, Spineスイッチのポート数がmのとき, この2層のClosネットワークに収容できるサーバの台数は, n * m / 2台になります. ここで2で割っているのは, LeafスイッチはSpineスイッチとサーバの両方に接続するためです.
概算では, Leafの上流と下流の帯域は1:1になっていますが, 実際には1:2や1:3などの構成も考えられます.
また, 同じポート数nのスイッチだけで構成する場合, サーバ収容台数はn^2 / 2台となります.

DCにClosネットワークを構築する場合, サーバとLeafスイッチの間は10Gbpsのような低速リンクで接続し, LeafスイッチとSpineスイッチの間は40Gbpsのような高速リンクで接続します.
なお, 今後はサーバとLeafスイッチの間で25Gbps, LeafスイッチとSpineスイッチの間では100Gbpsと, より高速化を実現可能な構成が主流になるそうです.

実際の値を考えると, 40Gbpsや100Gbpsの高速リンクのスイッチは大抵の場合, 最大32ポートです. また, 電力の制限があるため, 1ラック当たりに収容できるサーバは最大で40台となります. このとき, Closネットワークに接続できるサーバ台数は, 最大で32 * 40 = 1280台です.
さらに, 現在では64ポートのスイッチが登場しており, 将来的には128ポートのスイッチも出てくると考えられます. Closネットワークは帯域の拡張に, Spineスイッチを追加することで対応できるため, スケールアウトを容易に実現でき, より多くのサーバを収容することが可能となります.

IP-Closの運用

DC内ネットワークにIP-Closを採用することで, 帯域の拡張を容易に実現可能となり, L2-fabricのネットワークで起きていたBUMトラフィックによる帯域圧迫を排除し, 安定性と拡張性を向上することができます.
一方で, Closネットワークは構築時の配線本数の多さや, IPアドレス, ASN等の管理項目数の多さが, コスト面・運用面において課題となっています. さらに, 大規模DCの場合, サービスの発展と共に物理的にラックを増設して水平方向に拡張する必要があることから, 2層構造のClosネットワークでは, スケールアウトが難しくなるという問題がありました.

例えば, Spineスイッチ4個, Leafスイッチ100個からなるClosネットワークの場合, スイッチ間の配線本数は4 * 100 = 400本に及ぶ計算となります. また, 光ファイバーをSFPポートに接続するためのトランシーバは, 400 * 2 = 800個必要になります.
そのため, インフラの利用用途に応じてClosネットワークの構成内容を柔軟に変え, 効果的に運用していくことが重要になります.

運用方式と選定

ここでは, ヤフーを例に取り, Closネットワーク運用の実例を挙げたいと思います.
例えば, ヤフーで運用されている大規模なHadoopクラスターを用いたデータ分析基盤は, 図のようなClosネットワークを採用してもいくつかの問題が生じていました.
以下に, 具体的な問題と, ヤフーが実際に講じた策についてまとめます.

2層構造から3層構造へ
- データ分析基盤向けClosネットワークは, 図に示すように, 当初, Spineスイッチ4個, Leafスイッチ100個から構成され, 2層構造を採用していた.
- しかし, 200ラック規模のサーバルームを1, 2年に一度増設することを検討しており, Closネットワークを採用してもスケールアウトが厳しくなることが懸念され始める.
  ➡︎ Closネットワークの3層化を行い, 大規模なHadoopクラスターを1つのClosネットワーク配下に構築することで, サーバを柔軟に運用.
40G-LRから100G-LRへ
- 分析処理が発生したタイミングで瞬間的にトラフィックが増大し, Hadoopクラスターの台数増加に伴い, バーストトラフィックは40Gbpsでは賄いきれなくなった.
  ➡︎ 近年構築されるClosネットワークでは, 100G-LRのトランシーバーを利用することで対応.
大容量バッファを搭載したスイッチの導入
- 上述したバーストトラフィックは, ネットワークスイッチのバッファを高頻度で利用していることが確認された.
- 仮に, バッファ容量をオーバーしても, TCPの場合, 再送処理が走るため, パケットロスは回避できる.
- しかし, TCPの再送処理に伴い遅延が発生するという課題が残されている.
  ➡︎ 大容量のバッファを搭載したスイッチを導入してパケットをドロップさせない（しにくい）構成を取ることで予防

一方, 同じClosネットワークでも, プライベートクラウド向けに構築されるClosネットワークは, データ分析基盤向けClosネットワークとは異なる構成を取っています. これは, 双方でトラフィックの流れ方に大きな違いがあるためです.
プライベートクラウドでは, データ分析基盤で発生していたようなバーシティなトラフィックは確認されないため, データ分析基盤とは別に, プライベートクラウド用にClosネットワークを構築し, 展開することで, DCネットワークを柔軟かつ効率的に運用できます.
データ分析基盤とプライベートクラウド運用基盤では, 大きく以下の点が異なります.

ホワイトボックススイッチの導入
- バーストトラフィックが発生しない環境下では, 高価な大容量バッファを搭載したスイッチを利用する必要はない.
  ➡︎ プライベートクラウド環境では, スイッチ単体の性能よりもコストに着目して機器の選定を行い, 現在では, ホワイトボックススイッチを積極的に採用している.
3rd-party製トランシーバの導入
- ホワイトボックススイッチはハードウェアとNOS（Network OS）を個別に選択することができるため, 3rd-party製のトランシーバを容易に利用することが可能である.
  ➡︎ メーカー純正のトランシーバに比べ, 比較的安価で入手可能なため, 大規模なClosネットワークを構築した際にも, コストを抑制することが可能である.
Closネットワーク内全てをL3構成に
- HVからVMのIPアドレスをBGPで, 複数のLeafスイッチにアドバタイズし, VMに対する通信を冗長化.
  ➡︎ 伝統的なネットワークで採用されていたLACP構成による経路冗長化を撤廃し, L3化することでVMのIP単位で経路広報できるため, IPアドレスの効率的な利用が可能である.
Ansible等のIaCによるデプロイ
- ホワイトボックススイッチで利用されるNOSはLinuxをベースにしているものも多く, サーバ向けの構成管理ツールがネットワーク機器に適用可能である.
  ➡︎ 数十台〜数百台のスイッチをプロビジョニングする場合でも, config等の設定ファイルを生成してデーモンを再起動するだけで構築可能なため, トイルの撲滅に繋がる.

まとめ

ここまで, IP-Closの概要や特徴, 運用例について紹介してきました.
まとめると, 従来のネットワークとClosネットワークは以下のような違いがあります.

	Traditional-NW （従来のDCネットワーク）	Clos-NW （スケーラブルな次世代DCネットワーク）
想定するトラフィック	North-South	East-West
モデル	スケールイン	スケールアウト
アーキテクチャ	L2ベース	L3ベース
プロトコル	STP（Rapid-PVST）, VRRP, etc...	1つのルーティングプロトコルのみ（BGPのみ）
リンク	Trunk-VLAN, アグリゲーション, priorityによるActive-Standby	スイッチ間は単一リンクのみで接続
移植性	機器によりベンダー依存	複数ベンダーの混在が可能

また, ヤフーを例に取ると, 同じClosネットワークでも, 利用用途に応じて形態が異なります.

データ分析基盤向けネットワーク
- 分析処理の際にバーストトラフィックが発生
- 帯域不足のため3層構造を採用し, リンクも40G-LRから100G-LRにすることで対応
- 大容量バッファを搭載したスイッチを導入することで, パケロスしにくい環境を構築
プライベートクラウド向けネットワーク
- データ分析基盤で発生していたようなバーストトラフィックは確認されない
- スイッチ単体の性能よりもコストに着目して機器を選定
- 比較的安価なホワイトボックススイッチや3rd-party製トランシーバを利用

おわりに

今回の記事では, クラウドサービスやマイクロサービスを支える, 次世代DCネットワーク （IP-Clos） について紹介しました.
従来のDCネットワークでは, North-Southトラフィックを重視してDC付近で帯域を広く確保し, 末端に行くほど帯域を細くする構成が多く見られました. しかし, クラウドサービスやマイクロサービスの普及に伴い, サーバ間・VM間・ストレージ間の通信が多くなる環境では, トラフィックを円滑に流せない場面がありました.
IP-Closは, 急増するEast-Westトラフィックに対し, スケールアウトが容易なLeaf-SpineアーキテクチャをL3ベースで構築することで, スケーラビリティを担保します. 現在では, 大規模DCを保有する企業において, データ分析基盤やプライベートクラウド向けに独自のClosネットワークを用途に応じて構成の内容を変え, 各種の構築が進められています.
IP-Closは次世代インフラを支える技術の一つであり, インフラエンジニアを目指す身としてはとても興味を惹かれます. 今後のClosネットワークの普及動向や, 各企業での運用方式, アップデートには目が離せません.

参考・引用

読者の皆さんへ

本記事を読んで下さり, ありがとうございます.
誤字脱字や誤った内容を見つけた場合, 本記事にてフィードバックを下さると幸いです.
また, 意見や提案等がありましたら, 併せて本記事のコメント欄に記述して頂けると助かります. より良い記事を書くため, 改良の参考にさせて頂きます.

@ren510dev

【IP-Clos】スケーラブルなDCネットワーク設計