クラウド&データセンター完全ガイド：特集
SDNの現在位置と新たなアプローチ データセンターネットワーク最新動向
「Software Defined」インフラ刷新に今、着手すべき理由[Part2]
2016年10月7日 16:15
「Software Defined」インフラ刷新に今、着手すべき理由
[Part2] Technology Focus 01
SDNの現在位置と新たなアプローチ データセンターネットワーク最新動向
IT業界のあらゆる製品分野に冠せられるようになった「Software Defined」だが、データセンター全体のソフトウェア化・仮想化を考えるうえでコアになるのはやはり、ネットワークだ。本パートでは、SDN（Software Defined Networking）、Ethernetファブリックとその発展形とも言えるIPファブリック、サーバー間トラフィックを重視したリーフ＆スパイン型ネットワークといった、ネットワーク分野での最新動向をまとめてみる。
ハードウェア面でのネットワーク強化アプローチ
データセンターネットワークの強化・改善に取り組む場合、ハードウェア的な変更とソフトウェア的な変更を検討することになる。まずはハードウェア面から見ていくことにしよう。
仮想サーバー環境でのネットワーク運用状況
ハードウェア面での取り組みとして、まず、新しいネットワーク規格の導入による高速化が主な手段として挙げられる。Ethernetの進化は着実に進んではいるものの、現時点でのLANの主流は10ギガビットEthernet（10GbE）で、この速度が主流になって久しい。また、用途によっては1GbEもいまだに現役で活用されているところもあろう。
サーバー接続に関して言えば、サーバー仮想化の広範な普及によって、ネットワークインタフェースに対する要求も多様化していった。物理サーバーを仮想化し複数の仮想サーバーに分割して活用する場合、ネットワークインタフェースも高速なポートが1つあるよりも、低速でも多数のポートを確保できるほうが使い勝手がよいという事情からだ。10GbEまではともかく、その上の40GbEや100GbEといった規格になると価格が跳ね上がる。そのため、むしろ低価格な1GbEを複数利用して各仮想サーバーに確実に帯域を割り当てるやり方のほうが一般的だと思われる。
仮想サーバーの成り立ちからして当然ではあるが、データセンターに多数収容されるWeb系のサービスを稼働するサーバー個々に要求されるパフォーマンスレベルはさほど高いものではない。このことは、物理サーバーのプロセッサ処理能力を複数の仮想サーバーに割り当てても問題なく対応できていることからもわかる。ネットワーク接続に関しても同様で、WAN経由でアクセスしてくるユーザーが期待するレベルのレスポンスが実現できればよく、際限なく高速化する必要に迫られることはない。
並列化を軸とした運用面での工夫改善が必要
一方で、HPC（High Performance Computing）やビッグデータ分析処理などの用途ではサーバー間で大量のデータのやりとりが発生する場合があり、ここでは現状のネットワーク帯域では足りないという状況も生じている。ただし、Apache Hadoopが広く使われている状況を見てわかるとおり、こうした分野でも分散化／並列化によって現実的な解決を目指す方向が主流であり、物理層を高速化することで正面突破を目指すような状況にはなっていない。
Ethernetの規格自体の進化は今後も継続するものの、技術的には飛躍的な高速化はもう望めそうにない。実際に提案されている高速規格を見ても既存規格を内部的に複数束ねて十分な総帯域を確保する手法がほとんどだ。そのため、並列化を軸とした運用面での工夫改善で帯域幅の確保を行っていくというアプローチが当面続くものと考えられる。
SDN市場を切り開いたOpenFlowの現在位置
続いて、本題として、ソフトウェア面でのネットワーク強化アプローチを見ていく。ここでは、SDN（Software Defi ned Networking）と総称されるネットワークのソフトウェア化（仮想化）が大きな潮流としてあり、実現する手段としていくつかの技術／アプローチが存在する。
SDNの実装に関して最初に認知されたのは、OpenFlowによるホップバイホップ（Hop by Hop）型アーキテクチャであった。OpenFlowは、SDNのコントロールデータプレーンインタフェース（またはサウスバウンドインタフェース）の1実装である（図1）。
OpenFlowのメリットをかみくだいて説明すると、従来のスイッチやルーターが内部に抱え込んでいたルーティング情報を外部のコントローラに抜き出して動的に制御できるようにすることで、従来のルーター／スイッチでは実現が困難だった柔軟な構成が可能になり、かつ運用管理を一元化できるというものだ。
純粋な形でのOpenFlowネットワークはOpenFlow対応のスイッチを必要とし、従来のネットワークとは異なる新しいネットワークとして構築される。対応製品が必須なこともあって、商用データセンターやエンタープライズ（ユーザー企業の大規模データセンター）での導入例は一部にとどまっている。キャリアやWAN事業者では、パケット制御をきめ細かく行えるなどのというメリットがあることから内部的に活用されている例もあるが、少なくともデータセンターに対して、エンドユーザーからOpenFlowをサポートしてほしいという要望が寄せられるケースは考えにくいのが現状だ。
SDNの主流になりつつあるオーバーレイ型ネットワーク仮想化
事業者やエンタープライズユーザーのデータセンター内部でのSDN導入状況として、OpenFlowが限定的な導入にとどまっているのに対し、オーバーレイ型のネットワーク仮想化アーキテクチャはより勢力を増してきている感がある。
オーバーレイ型ネットワーク仮想化は、パケットのカプセル化の技術を活用し、実際のネットワークの構成から完全に独立した形の仮想ネットワークを文字どおり“重ね合わせて”作り出す仕組みをとる（図2）。物理的なネットワーク構成に依存しないため、まさにSoftware-Definedという言葉からイメージされる柔軟な運用環境を手に入れられる。
問題点も存在する。やはりハードウェアで直接制御するのに比べて余分な処理が発生し、オーバーヘッドが生じる点や、もともとEthernetなどのLANハードウェアを想定して実装された機能であるブロードキャストパケットなどの処理に工夫を要する点などだ。
それでも、現状でのSDNは、ほぼオーバーレイのかたちでネットワーク仮想化を軸に推移していると見ることができる。データセンターの内部で実装した場合、仮想サーバーの提供と同時にオーバーレイ型の仮想ネットワークを提供することで、仮想サーバーの柔軟性や俊敏性と同じスピード感でネットワークの構成変更が可能になり、運用管理面で多くのメリットが得られる。
ソフトウェアアプライアンスを実現するNFV
NFV（Network Function Virtualization：ネットワーク機能仮想化、図3）は、広義のSDNに含まれる技術だが、SDN/NFVといった並列表記もよくなされる。NFVについては、登場当初のあり方とは違った形で市場に定着しつつあるようだ。最初期のNFVは、「キャリアグレードの交換機やハイエンドルーターが実装していた各種の機能をハードウェアから切り離して利用できないか」という、いわばユーザー側からベンダーに突きつけられた要求だった。
その背景には、ハードウェアとソフトウェアが密接に関連づけられていることでベンダー／プラットフォームロックインが生じ、ユーザー側での機器選定の自由度が制約されたり、過去の投資が無駄になるリスクが生じたりといった状況を、仮想化技術の活用によって改善したい意図があった。しかし、その後のNFVは、従来、ハードウェアアプラアンスに搭載される形態で提供されてきた各種のネットワーク機能をソフトウェアアプライアンスとして提供するさまを指すようになっていった。
例えば、ファイアウォールやロードバランサーなどがこれまで「ネットワークに機能やサービスを付加するハードウェアアプライアンス」として利用されてきたわけだが、これらがハードウェアのままだと、現在の仮想サーバーやクラウドサービスの柔軟かつ俊敏な展開に追従することが困難になる。仮想サーバーを複数台契約してWebサーバーファームを構成し、ロードバランサーで負荷分散を行うといった場合にロードバランサーがハードウェアだと、その設置や設定に手間と時間を要し、即時に利用開始というわけにはいかない。しかし、それが仮想アプライアンスとして提供されていれば、仮想サーバーのデプロイメントと同様のスピード感で利用可能になる。
現在のNFVはおおむねこうした意味を帯びており、クラウドサービス事業者が仮想サーバーと同時に提供するオプションサービスといった位置づけで認識されている。アプライアンスを販売するベンダーも、現在ではハードウェア製品のみというところはほぼ皆無だ。
かつては「ワイヤースピード」が重視され、パケット処理に特化した高性能な専用ハードウェアが製品の最大の魅力となっていた分野であり、ソフトウェアアプライアンス化するとパフォーマンス面でどうしても専用ハードウェアには及ばない点は今も同じだ。それでも使い勝手の差は圧倒的であり、ソフトウェアアプライアンスの採用拡大は今後も続くと思われる。
クラウドサービスではユーザーがセルフサービスでネットワークを構成できるのが一般的になりつつある。そうした現在の状況を考えても、ネットワーク機器をソフトウェアアプライアンスに置き換えるのに大きな障害は特に見あたらないだろう。
注目が急速に高まるIPファブリック
現在、最新のトレンドとして急速に注目が高まっているIPファブリックをご存知だろうか。ごく単純に表現するなら、「従来、L2で実現されてきたEthernetファブリックと同様のメリットが得られる構成をL3で実現する手法」となる。ハイパースケールと呼ばれる超大規模なクラウド環境を運営するフェイスブックやマイクロソフト、グーグルといった企業がデータセンターの内部に実装し活用しているということで注目されるようになった。まずは、その前身的存在と言えるEthernetファブリックの登場の背景までさかのぼり、それとのアーキテクチャの比較をしながらIPファブリックのメリットを確認してみることにしよう。
Ethernetの制約を回避する試み
Ethernetファブリックは、もともとは「STPを排除する」ことで注目されたネットワークアーキテクチャである。STP（Spanning Tree Protocol）は、Ethernetで禁止されているループ経路を発見し、当該経路を遮断することでネットワークの正常性を保つプロトコルである。そもそものEthernetがシンプルなアクセスコントロール機構やブロードキャストによるアドレス解決（ARP）などによってデバイスの複雑化を回避し、低コストで高速なネットワークを実現することに主眼に置くため、こうした制約が生まれることになった。
Ethernetのループ経路禁止の制約は、現在のLAN環境においては「並列化による帯域確保が困難」という問題につながる。サーバー接続の際にも、万一の機器故障に備えてあらかじめ複数のネットワーク接続を用意しておくことは一般的な手法と言える。しかし、例えば1台のサーバーに対して2本のEthernetケーブルを接続した場合、この2本を同時に有効にはできない。禁を破ってループ経路を構成してしまうことになるからだ。
そこで、STPを用いて一方を遮断し予備経路としておき、メインの経路に何らかの障害が生じて通信不能になったことが検出された際には、STPによって予備経路の遮断が解除され、回線の切り替えが行われるという仕組みが生まれた。
この仕組みは、バックアップという観点では正しい動作だが、リソースの有効活用という観点からすれば「存在するリソースの半分しか活用できていない」無駄があることになる。
上述したようにEthernet規格自体の高速化が技術やコストの面から困難になった今、比較的安価に導入可能な1GbEや10GbEを複数本束ねて帯域拡大を図る手法が検討されるが、単純に複数のインタフェースを接続するだけでは帯域拡大にはならないのである。
Ethernetファブリックのメリット
こうしたEthernetの仕様上の制約を回避し、複数経路を同時に使えるような手法はないだろうかという検討がなされた。そこで、新たなベンダー独自仕様として製品化されたのがEthernetファブリックである（図4）。
メッシュ状に構成したネットワークのすべてのリンクを活用して負荷分散や耐障害性の向上につなげるというEthernetファブリックの手法は、Ethernet以外のネットワークではむしろ普通に行われていることだ。例えば、この分野の製品化で先行したブロケード コミュニケーション システムズは、SANスイッチの技術を応用してEthernetファブリックを実現している。
わかりやすく言うなら、インテリジェントなスイッチを用いることで、STPを使わずにループ経路がネットワークの健全性を損なうことを避け、複数の経路を同時併用できるように制御しているということだ。逆に言えば、スイッチに実装された独自機能であるため、基本的には単一ベンダー製品で統一された環境でないとEthernetファブリックを構成できないという問題がある。
つまり、マルチベンダー環境にはならないのだが、環境が統一されるメリットのほうを取れば複数のスイッチを仮想的に統合して1つの巨大な仮想スイッチのように見せることができる。これによって運用管理が簡素になり、スイッチの追加によってネットワークのトポロジーがどう変わるかといった問題に煩わされることなく、シンプルに「スイッチを追加すれば利用可能な総帯域が拡大する」という発想で、スケールアウト型拡張が実現できるようになる。
Ethernetファブリックの制約
このように、Ethernetファブリックのメリットは明快で、エンタープライズユーザーを中心に導入事例も多い。特に仮想サーバーを多数運用する環境や、SDNによるオーバーレイネットワークを構築するような環境では、下層の物理ネットワークをEthernetファブリックとすることで十分な帯域を確保しつつ運用管理の負担を増大させないシンプルなL2ネットワークを実現できるメリットが評価されている。
しかし、Ethernetファブリックにもいくつかの制約があり、特に大規模な事業者での採用が進まない理由ともなっている。最大の制約は、ファブリックを構成できるスイッチ数に上限が存在することだ。これは、スイッチの追加をシステム側で自動的に認識するなどの仮想統合による運用管理の簡略化機能が提供されていることからも容易に推測できることだが、無制限に規模を拡大していくことはできない。ベンダーや製品仕様によって異なるものの、おおよそ数十台規模で上限に達する。
もちろん、各スイッチに実装されているポート数を掛け合わせて算出される総ノード数は相当な規模に達する。そのため、一般的なエンタープライズユーザーの環境でスイッチ数の仕様上の上限がシステム規模の制約となった例はないというのがベンダー側の主張だ。大規模クラウドサービス事業者のネットワークの規模はそれこそエンタープライズユーザーとはケタが違うレベルであり、早々にEthernetファブリックは採用できないという結論が出たようだ。
一方で、経路を並列化できるメリットなどには捨てがたいものがあることから、ハイパー／メガスケールのクラウドサービス事業者がそれぞれ独自の工夫で実装を試みたのがIPファブリックということになる。
IPファブリックの特徴
IPファブリックを理解するうえでのポイントは次の2つである。
1.特定のベンダー／特定の技術による実装ではなく、インターネット標準に基づいてユーザー側で実装されたものである
2.仮想サーバーの実用化以来、ネットワークの大前提となっていたL2ネットワークの制約がついに取り払われている
IPファブリックという名称からもうかがえるとおり、基本的な実装はIP層（L3）から上のプロトコル群によって行われている。ループ経路を正しくハンドリングできないのはEthernetの仕様上の制約であり、これはL2でネットワークを構築する際には避けて通ることができない大問題となるが、ネットワークをL3にすればいろいろな解決策が生まれてくる。実際に、L3で経路制御されているWANの世界では複数の経路を同時に運用して帯域確保を行いつつネットワーク全体の耐障害性を高めるという手法が普通に行われている。
そして、複数存在する経路のうちのどこにパケットを通すかという判断のために各種のルーティングプロトコルが存在し、これによって問題が生じないように制御できる仕組みがすでに確立されている。IPファブリックでは、こうしたインターネット／WAN環境で運用されている技術を、従来LAN技術でカバーしてきたサーバールーム内部まで持ち込むことでL2ネットワークに起因する制約を取り払った格好だ（図5）。
大規模ネットワーク発のアプローチ
IPファブリックはその確立にあたって、特定ベンダーによる開発や標準化団体による規格制定といったプロセスを経たわけではない。グーグルやフェイスブックなどのハイパースケール企業が、自分たちが必要とする環境を自力で構築したという経緯から生まれた技術だ。したがって、「これがIPファブリックだ」と言えるような定義や典型例があるわけではない。強いて言うなら“フェイスブック流”“グーグル流”“マイクロソフト流”といったいくつかのパターンを示せるといった程度の大まかな分類になる。
そのような経緯から、各社がそれぞれ自社の環境を詳細に公表しているとは限らず、多少情報が古かったり、独自のノウハウの部分が秘匿されていたりする可能性もある。おおむね共通する要素としては、サーバーの直前のところまでL3でパケットを制御する仕組みをとり、サブネットの粒度はラック単位からサーバー単位までいろいろなパターンがあるようだ。
こうすると、サーバールーム内に膨大な数のネットワークが並列し、それが網の目状に複雑に相互接続されている状況ができあがるが、実のところこの状況はインターネットのありようそのものだとも言える。
つまり、IPファブリックは、L3ネットワークを採用することで従来の技術では明確に分かれていたLANとWANの境界をなくし、サーバールームの内部もインターネットと同じ技術、同じ手法で接続／管理していくアプローチだととらえることができよう。
典型的なパターンとしては、ファブリックを構成するスイッチをそれぞれ独立したAS（Autonomous System：自律システム）と位置づけ、BGP（Border Gateway Protocol）でルーティングする仕組みとなる。ファブリックの拡大はASの追加であり、これはインターネット上で日々行われていることそのものだ。ゆえに、規模の上限としては「現状のインターネットと同等規模まで問題なく拡張可能」という考え方になる。事実上、サイズの上限は無制限だと言ってよい。
最大の課題は複雑な運用管理
IPファブリックにはEthernetファブリックに比べて明らかに劣っている点もある。それは運用管理性の部分だ。
ベンダー固有の運用管理インタフェースが提供されるEthernetファブリックでは、ファブリック全体をあたかも単一の仮想スイッチであるかのようにシンプルに管理することが可能で、構成の詳細は隠蔽されることになる。逆に、IPファブリックの場合はスイッチをASとして動作させるために個々に正しい設定を行わなければならないなど、構成の詳細を正しく理解しつつ適切な運用管理を行う手間が避けられないのである。
つまり、後発の技術としてEthernetファブリックのいくつかの欠点を解消してはいるものの、それを完全に置き換えられるわけではない。企業の場合、現状、IPファブリックを必要とするのは、標準的なエンタープライズネットワークの規模を越える大規模な環境を抱える大手企業に限られるだろう。
一方で、データセンターやクラウドサービス事業者の場合は、規模によってはIPファブリックの導入でかなりのメリットを得られると考えられる。実際、IDCフロンティアは2016年7月下旬に発表した事業戦略の中で「Data Centric Cloud」というコンセプトを掲げてシームレスなデータ利用を重視するネットワークを構築するという方針を明らかにしている。その際、一環としてIPファブリックの導入を表明している。
このとき同社は「CLOS Fabric」という用語を使っているのだが、IPファブリックに「CLOS Fabric」という呼称を与えたのはジュニパーネットワークスだと言われている。Ethernetファブリック製品も手がけてきた同社は、データセンターネットワークの次の姿として、L3ルーティングの利点に着目したIPファブリックの実装に積極的に取り組んでおり、顧客企業のネットワークでの導入支援などを行っている（図6）。
「L2接続を放棄する」か否か
IPファブリックに関して最後に残る問題は、L2接続を放棄するという点だ。そもそもL2接続によるネットワークがこれほどまでに利用されるようになったのは、サーバー仮想化が広範に普及し、仮想マシン（VM）を動作中のまま別のサーバーに移動できるライブマイグレーション機能が活用されるようになったためだ。
ライブマイグレーションでは、サーバーの状態を一切変更せずに別の物理サーバー上にVMを移動させるために、IPアドレスも変更せずに使い続けられなくてはならない。しかし、IPアドレスは内部にネットワーク部を含んでおり、つまり同じIPアドレスを使い続けるためには同じネットワーク内にとどまっている、すなわちL3境界を越えずにL2の範囲内にとどまっている必要がある。このため、サーバー仮想化の利用拡大に伴ってサーバー接続のためのネットワークがL2のままで大規模化する状況に陥ったという経緯だ。
この制約を回避してL3ネットワークでもよいという形になれば多くの問題が解消できるわけだが、現状では、あれこれ工夫してL3に移行するよりもL2を維持するほうがまだましという考え方が主流だ。
IPファブリックでは、仮想化のためにL2を維持することは放棄し、L3への移行を前提とする。その結果、仮想サーバーのライブマイグレーションはそのままでは行えないという問題があるが、この点に関しては、前半で述べたオーバーレイ型ネットワーク仮想化を組み合わせることで問題を回避することができる。
ライブマイグレーションの前後で仮想サーバーをホストする物理サーバーがL3境界を越えていたとしても、オーバーレイネットワークによるトンネリングを活用することでIPアドレスを変更することなく運用を継続することが可能になる。もちろんシステム的には複雑になるし、どこでトンネリングを行うかによっては耐障害性にも影響が生じるだろう。
物理サーバー間でトンネルを構築する場合には、物理サーバーが障害を起こしてダウンした場合にはトンネルが切断されてしまうリスクがある。スイッチ側でトンネリングの処理を行えば耐障害性という観点からはサーバーよりは安心だが、スイッチがトンネリングに対応したものである必要が出てくる。
こうして、さまざまに制約があることから、仮想サーバーの柔軟な運用を第一に考えるのであればやはりIPファブリックよりもL2ネットワークを維持するほうが手間はかからないと思われる。判断のポイントは、サーバーファームとしてどのくらいの規模が必要かという点であり、Ethernetファブリックや従来型のL2ネットワークで足りる規模であればそのまま、その制限を超える規模まで拡張するのであればIPファブリックに移行という判断が成り立つ。
IPファブリックの実用化は、米国ではここ数年でほぼ完成の域に達しつつあると見られている。こうした動向を受けて、日本国内では今年に入ってからにわかに脚光を浴び始めているという状況だ。データセンター事業者やクラウドサービス事業者が今後のネットワークアーキテクチャを考える際には、新たに検討すべき選択肢として無視できない存在になってきたと言える。
今日のワークロードに対応しやすいリーフ＆スパイン型ネットワーク
エンドユーザーからのWebアクセスを中心に考えていた時代には、インターネットからのトラフィックを効率よくWebサーバーに導くことが重視され、コア／アグリゲーション／アクセスの3階層スイッチが一般的なトポロジーとして普及した。
しかし、現在では、Webアプリケーションの処理の複雑化や高度なデータ処理が求められるようになり、データセンター内部でのサーバー間のトラフィックが急増している。これを、従来のインターネットからサーバーへというトラフィックの方向を縦／南北（South-North）と見立てる発想から、横／東西（East-West）トラフィックと表現するようになった。特に最近は南北一辺倒ではなく、東西の帯域拡大／レイテンシ減少に意を配るネットワーク構成が主流となってきている。
従来型の3階層トポロジーの問題点は、サーバー間の東西トラフィックのレイテンシのばらつきが大きくなることだ。同一ラック内のサーバー間であればトップオブラック（ToR）スイッチの内部で完結するが、異なるラックのサーバーとの通信ではアグリゲーションスイッチや場合によってはコアルータまで行ってから折り返してくる形になる。こうしたトラフィックが増大するとインターネットからの南北トラフィックの処理にも影響を与えてしまうなどの問題が生じてきた。
こうした状況を受けて、現在は段数を減らして極力フラットな構成となることを意図した「リーフ＆スパイン（Leaf and Spine）トポロジー」（図7）と呼ばれる2階層のネットワークの採用例が増えてきている。ビッグデータ分析処理などではサーバー間で大量のデータのやりとりが発生する場合があるため、関連するサーバー間で1～2ホップでの通信が可能となるようにネットワークを構成することでレイテンシを一定レベルに抑えるように配慮するというものだ。
インターネットからWebサーバーへの大量アクセスが発生しうるという点に関しては現在でも事情はまったく変わっていない。だが、Webアプリケーションが高度化した結果、アクセスを受けたアプリケーションがバックエンドのデータベースやアプリケーションサーバーとの間で大量のトラフィックを発生させるケースも増えている。こうした処理を効率よくさばくためには、やはり東西トラフィックの増大を見越したネットワークトポロジーへの移行は必須と言える。
リーフ＆スパイン型ネットワークは比較的汎用性の高い構成であり、さまざまな用途に活用できるものだ。かつての3階層のアーキテクチャに比べても特に目立つ欠点はないことから、今後は段階的にリーフ＆スパイン型への移行が進行していくものと見られる。
なお、上述のIPファブリックに関してもトポロジー的にはリーフ＆スパイン型となっている例が多いようだ。この場合、スパインスイッチをメッシュ構成にしてファブリックを構成する例が一般的と見られる。今後のネットワーク構成の典型例の1つとして注目しておく価値があるだろう。