データドリブンなサービスを支えるネットワークの作り方〜 ヤフーのデータセンターネットワーク紹介

ヤフーのプロダクションネットワークの設計・構築・運用を担当している津秦です。

ヤフーではオンプレミスで大量に物理サーバーを導入し、社内向けプライベートクラウドや、データ分析基盤などに利用しております。もちろんそのサーバーを接続するためのネットワークも、自分たちで設計・構築・運用を行っております。

今回はデータセンター内ネットワークの中でも、最近取り入れているClosネットワークというものに着目して、ヤフーのデータセンターネットワークをご紹介したいと思います。

なお、大量に物理サーバーを導入する点では、昨年末に同じくインフラを担当する藤見から、サーバーの調達に関する取り組みを紹介しました。合わせて参照いただければ、ヤフーのインフラ部門の取り組みに、より触れていただけるのではないかと思います。

大規模オンプレミスなヤフーのサーバーインフラの裏側 〜 サーバー調達や運用の流れを紹介します

「North-South」トラフィックと「East-West」トラフィック

データセンター内ネットワークでは、「North-South」や「East-West」という方角を用いた言葉をよく用いることがあります。これはネットワーク構成図を書いたときに、上の方に外部ネットワークや基幹ネットワークを描き、下の方に末端のサーバーやアプリケーションを描くことが多いためで、この構成図の中でトラフィックの方向性を示すのに、これらの言葉が利用されています。

ヤフーでは「North-South」というのは「インターネットからの利用者が、ヤフーの各サービスへアクセスするトラフィックのこと」としており、初期のネットワークとしてはこのトラフィックが多く重視されてきました。「North-South」のネットワークでは、インターネットに近いところは帯域を広く確保し、末端に行くほど細くなるといった構成を取ることが、多く見られていました。

対して「East-West」トラフィックは、ネットワーク構成図の左右の通信、つまり末端のサーバーやアプリケーション間の通信を示します。

2010年代前半の頃から、多くのデータセンター内では、「North-South」のトラフィックに比べて、「East-West」のトラフィックの方が増加を示してきました。これはユーザーからのアクセスによるトラフィックに比べて、データセンター内のサーバー間・VM間・ストレージ間などのトラフィックの方が、増加傾向にあったことによります。もともと「North-South」トラフィック用に構成されていたネットワークでは、末端の帯域が細いことが多いため、このトラフィックパターンの変動には耐えられず、トラフィックを詰まらせてネットワーク管理者を困らせたのではないでしょうか。

ヤフーでも、データ解析に利用していたHadoopのネットワーク環境にて、この「East-West」のトラフィック問題が発生しました。Hadoopは大規模なログデータなどの分析処理を並列・分散して行えるオープンソースのミドルウエアです。ヤフーでも各種サービスのログを分析して、サービスの改善に役立てるため、複数のHadoopクラスタを利用しています。各サービスの大量のログデータを分散して保管・処理を行うため、必然的にサーバー間の通信量は多くなります。多くなったサーバー間のトラフィックにネットワークが悲鳴を上げて、システムとしてのボトルネックになってしまった訳です。

これまでもこの「East-West」トラフィックに対して、いくつかの対策を取ってきました。

• StackやVirtualChassisというネットワーク機器メーカー独自の技術の利用
• L2 fabricと呼ばれる技術の利用

各対策、一定の効果は見られるものの、どちらもいわゆるL2ネットワークの拡張となるため、

• スケールアウトの限界
• ブロードキャストパケットなどのBUMトラフィック処理によるオーバーヘッド
• ネットワーク機器メーカーの独自実装によるものが多い

などの点で問題が残っていました。

これらの問題を解決するために、今回紹介するClosネットワークという構成の利用を開始しました。

Closネットワークとは

ClosネットワークのClosとは、このネットワークトポロジーの原案を考案されたCharles Clos氏から、名付けられています。シンプルな2層の以下のネットワーク図を利用して、特徴を説明します。

ネットワーク機器にはSpineスイッチ、Leafスイッチと呼ばれる2種類の役割のスイッチがあり、全Leafスイッチは、全Spineスイッチに接続されています。またサーバーがLeafスイッチに接続されています。Closネットワークはスケールアウトモデルで、帯域の拡張にはSpineスイッチを追加することで対応が可能です。Spineスイッチを追加することでLeafスイッチからの合計帯域幅を容易に増やすことができ、Leafスイッチ間の帯域を増やすことが可能です。またさらに拡張が必要になる場合でも、スイッチの層を増やしていくことで、より大規模なClosネットワークを構築することも可能です。

またSpine/Leafスイッチ間のリンクも、L2でのブリッジ接続ではなく、L3のルーティングで接続しています。従来ネットワークで利用していた、STPやVRRPなどL2冗長のプロトコルは不要となり、ルーティングのみでネットワーク構成ができるため、ネットワークの安定性向上、トラブルシューティング時の確認ポイント数の削減が可能になりました。

利用するルーティングプロトコルですが、ClosネットワークではBGPを利用するのが一般的です。データセンター内では、OSPFを利用するケースも多いのではないかと思いますが、リンクステート型のプロトコルのため、単一リンク障害時の影響が全ネットワーク機器に伝搬します。このためClosネットワークの規模が大きくなった際に、ネットワーク機器へのオーバーヘッドが大きくなるため、Closネットワークでの利用は推奨されません。また経路の制御のしやすさなどからも、ヤフーのClosネットワークでもBGPを利用して構成しています。

このような特徴を持ったClosネットワークを、ヤフーでは2015年頃から検討、構築・利用を開始しています。2020年になった今では、データ分析基盤向けのClosネットワーク、プライベートクラウド向けのClosネットワークと、用途に応じて構成の内容を変えて、各種の構築を進めております。以下にてそれぞれの特徴などをお伝えできればと思います。

データ分析基盤向けClosネットワーク

ヤフーでのClosネットワークは、データ分析の基盤であるHadoop環境のネットワークから利用が始まりました。ヤフーでは国内外にデータセンターを保有していますが、2014年頃から構築・運用を進めて来たアメリカのデータセンターにて、電力などの運用コスト削減を見込めることから、大規模Hadoopクラスタを構築することになり、そのネットワークに、最初のClosネットワークを利用することになりました。

このとき構築したClosネットワークの特徴としては、

• Spineスイッチにシャーシタイプ、Leafスイッチにネットワークメーカースイッチとホワイトボックススイッチを採用
• Spine/Leaf間は40G-LRを4本
• 社内IPAMからコンフィグ生成+ZTPの本格利用を開始したデプロイ

などが挙げられます。

Closネットワーク化したことで、帯域の拡張ができ、またL2 Fabricのネットワークで起きていたBUMトラフィックで悩まされるといったことはなくなりました。代わって以下のような項目が新たな課題となったと記憶しております。

• 構築時の配線本数の多さ
• 管理項目数の増加（IPアドレス、AS番号など）

このときのClosネットワーク構築に関しては、日本のネットワーク運用者の集いでもあるJANOGの第38回Meetingにて、弊社の村越がお話しています。資料なども公開されていますので、詳細に関してはこちらもご確認ください。

ヤフーのIP CLOS ネットワーク

このときに構築したClosネットワークをベースに、これまで国内2拠点、国外1拠点のHadoop用ネットワークをClosネットワークで構築してきました。各環境細かくアップデートはありますが、現在は以下の構築方針をとっています。

• 多くのラックが確保できる海外拠点では2層構成でのスケールアウトが難しくなってきたため3層構成に
• 40Gリンクを4本の構成では帯域が不足してくる場面が出てきたため100Gを採用
• バーストトラフィック対策として大容量のバッファを搭載したスイッチを利用
• 機器のデプロイには商用ツールApstra AOSを利用

2層構成でのスケールアウトが難しくなってきたため3層構成に

現在海外で展開を進めているデータセンターは、ほとんどがデータ分析環境として利用されることになり、200ラック規模のサーバールームを1,2年に一度追加していくような形で増設が検討されています。このネットワークを構成するにあたり、2層の構成ではスケールアウトができなくなるため、3層化を行う予定です。これにより大規模なHadoopクラスタを1つのClosネットワーク配下で構成できるため、サーバーの運用を柔軟に行うことが可能となる予定です。

40Gリンクを4本の構成では帯域が不足してくる場面が出てきたため100Gを採用

最近のHadoopネットワークに利用しているSpineスイッチのおよそ半日のトラフィック状況です。分析処理のタスクが走ったタイミングなどで、トラフィックが高騰することが確認でき、数十秒間でサマリしたグラフでも1リンクあたり50Gbps弱のトラフィックが出ていることが確認できます。Hadoopクラスタの台数増加に伴い、瞬間的なトラフィックは40Gbpsでは賄いきれなくなったため、近年の構築に関しては100Gのトランシーバーを利用しています。

バーストトラフィック対策として大容量のバッファを搭載したスイッチを利用

HadoopのClosネットワークを運用していくにあたり、Hadoopの処理が実行されたタイミングで、バーストトラフィックが発生、スイッチのバッファを高頻度で利用していることが確認できました。仮にバッファ容量をオーバーしても、パケットのドロップはTCPを利用していれば、再送処理が行われますが、処理としては遅延が発生してしまいます。これを予防するため基本的には大容量のバッファを搭載したスイッチを利用する方針にして、パケットをドロップさせない（しにくい）構成としています。

機器のデプロイには商用ツールApstra AOSを利用

初期のClosネットワーク構築では、社内の構成管理ツールからスクリプトを利用して機器のコンフィグを作成していましたが、もともとClosネットワークを想定した作りになっていなかったため、イレギュラーな形で構成管理ツールに情報を登録せねばならず、構築にかかる工数が増大しておりました。これに対する形で、社内でのツール作成や商用ツールを利用する方向で検討・検証を行い、このタイプのClosネットワーク構築には、Apstra社のAOSというツールを利用しています。

プライベートクラウド向けClosネットワーク

データ分析基盤向けとは別に、昨年よりヤフー社内のプライベートクラウド用にClosネットワークの構築・展開を進めてきました。データ分析基盤向けのClosネットワークと異なるポイントとしては、以下の点が挙げられます。

• ホワイトボックススイッチの積極的採用、3rd party製トランシーバーの利用
• Leafスイッチ/サーバー間を含めてAll L3構成に
• AnsibleなどOSSを利用したデプロイ

先述したとおり、データ分析基盤向けのネットワークでは、データ分析の処理が走った際のバーストトラフィックに耐えることを目的として、スイッチに搭載しているバッファの容量が大きいものを選択・利用しています。対して今の所プライベートクラウド環境では、このようなバーストトラフィックは見られないため、高価な大容量バッファを搭載したスイッチを利用せずとも、トラフィックを流すことができる状況でした。このため、プライベートクラウド環境では、スイッチの単体の性能よりコストに着目して機器の選定を行いました。結果、ホワイトボックススイッチと呼ばれるスイッチを積極的に採用しております。

ホワイトボックススイッチの積極的採用、3rd party製トランシーバーの利用

ホワイトボックススイッチは、従来のネットワーク機器のようなハードウエアとネットワークOS（NOS）を組み合わせて販売されているようなスイッチではなく、ハードウエアとNOSを個別に選択することが可能になりました。またホワイトボックススイッチを利用した恩恵として、3rd party製のトランシーバーの利用が容易になったことが挙げられます。3rd party製のトランシーバーは、メーカー純正のトランシーバーに比べて、大幅に安価に手に入れることができます。

Closネットワークは、これまで述べてきたとおり、多数のネットワーク機器や、それらの機器をつなぐリンクに分散させることで、広帯域なネットワークを安定して提供できます。反面、規模が大きくなればなるほど、スイッチ間を接続するリンク数が増大し、そのコストが膨れ上がるという弱点がありました。例えば4Spineスイッチと100LeafスイッチからなるClosネットワークでは、スイッチ間の配線は400本、トランシーバーの数は800個が必要です。1つ1つは大きなコストではない部品でも、大量に調達する必要があることから、最終的なコスト面でホワイトボックススイッチ化したメリットが得られております。

Leafスイッチ/サーバー間を含めてAll L3構成に

またプライベートクラウド向けClosネットワークでは、スイッチ・サーバー間を含めてL3接続の構成を採用しました。これにより、HVからVMのIPアドレスをBGPで、複数のLeafスイッチに広報を行い、VMに対する通信も冗長化することができました。（但し、HVのOSインストール時のみ、L2接続も利用します）

もともとLeafスイッチの冗長として、mlag構成を取る手法がありました。mlag構成では同一のVLANを保有したスイッチに対して、サーバー側のBondingなどの機能でLACP構成を取り、サーバー・スイッチ間の経路冗長をしていました。サーバーへのアクセス経路冗長としてはこの方法でもよかったのですが、L3化することでVMのIP単位で経路広報することから、IPアドレスの効率的な利用ができるメリットが出てきます。またVMを別ラックのサーバへマイグレーションすると行ったことも容易にできるようになります。

AnsibleなどOSSを利用したデプロイ

3つ目の特徴にAnsibleなど、サーバー向けの構成管理ツールが利用できることが挙げられます。ホワイトボックススイッチで利用されるNOSはLinuxをベースにしているものが多く、設定もファイルをコンフィグファイルを生成してデーモンの再起動を行うといった、サーバーと同じような形で作業を行うことができます。Closネットワークを構築するにあたり、同時に数十台〜数百台といった台数のスイッチに設定を適用していくために、1台1台手作業というはもちろん現実的ではありません。

ヤフーでもホワイトボックススイッチでのコンフィグデプロイにAnsibleを利用し、数十〜百台のスイッチに対しての設定を行っております。

物理構成

プライベートクラウド向けClosネットワークの特徴を説明したところで、物理面の紹介もいたします。

Closネットワークは3層の構成をとり、Spine/Fabric/Leafスイッチとそれぞれ呼んでいます。スイッチ間の配線はすべて100Gを利用しており、スイッチ同士が近くに置かれている場合は100G-SR4を、ラック列が離れて置かれている場合は、100G-CWDM4を利用しています。またLeafスイッチとサーバー間は、25G-DACケーブルを利用した配線を行っております。

Spineスイッチは4グループで構成されており、Closネットワークの拡張とともに、グループ内のSpineスイッチを増やしていく形で拡張性を担保しています。Leafスイッチはサーバーとの接続を冗長化するため、1ラックに2台格納しており、これを100Gのポートを64個を持ったFabricスイッチに接続しています。Fabricスイッチのポートの半分をダウンリンク（Leafスイッチ向け）、残りの半分をアップリンク（Spineスイッチ向け）として利用するため、32Leafスイッチ（16ラック）を1Podとして、Pod単位での拡張を容易にした構成となっております。

Spineスイッチも100Gポートを64個持ったスイッチを利用しているため、理論上は1Spineグループに32台スイッチを並べる構成を作れば、64Pod構成つまり1024ラックを収容できるClosネットワークの設計になっています。ただし現実的には、ラック配置やデータセンター構内の配線が爆発的に増えコストがかかることから、1つの拠点をまるまる1つのClosネットワークに収容することは考えておりません。現在の予定としては、8または16Podを1つのClosネットワークとして、このClosネットワークを外部接続用のスイッチ配下に増設していく形で今後の増設を検討しています。

まとめ

従来のネットワークでは「North-South」トラフィックを流すのに重きをおいていたため、データ分析基盤のようなサーバー間の通信が多くなる環境では、トラフィックを円滑に流せない場面がありました。この対策として「East-West」に強いClosネットワークを採用して、構築・運用を進めてきました。Closネットワークの社内展開を始めて5年ほど経過、ノウハウを習得しながら構成を徐々にアップデートを進め、社内のプライベートクラウドにも展開できる状態になりました。今後も引き続きプロダクションネットワークへの展開を進めていきます。

今後もいちネットワークエンジニアとして、データを生かすサービスづくりにインフラ面から貢献できるよう、ネットワークのアップデートを行っていきたいと思います。