目次
はじめに
従来の DC ネットワーク
スケーラビリティの限界
障害発生時におけるサービス提供のレジリエンス
IP-Clos
Clos ネットワーク内のルーティングプロトコル
Clos ネットワークのリンク
Clos ネットワークに収容できるサーバ台数
IP-Clos の運用
運用方式と選定
まとめ
おわりに
参考・引用

はじめに

従来、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 パケットが帯域を食い潰すなんてこともあったらしい...。
ネットワーク機器メーカーによって独自に実装されていることが多い
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 ネットワークの普及動向や、各企業での運用方式、アップデートには目が離せません。

目次