何らかの『連携を前提としたSDN』を採用する前に考えるべきこと。

はじめに

このエントリーはvExpert Advent Calendar 2019の12/16分として公開されています。…ですが、一切VMware製品について明示的な記載はありません。また、このページはあまり技術的な内容にはあえて踏み込んではいません。どちらかといえば、これは読み物です。そういう意味では、あまりQiitaに書くべき内容ではないのかもしれません。しかし、全ての技術は何らかの課題を解決する手段として用いられるべきものであり、そういう意味では技術を適切に使うためには、その細部の検討を始める前にはまずブレない軸を明確に打ち立てるべきであるという思いから、このタイトルで、このエントリーを書かさせて頂いています。

技術を扱っていると、どうしてもその技術自体が目的に思えてきてしまいますが、技術自体は究極的にはどこまでいっても手段であるべきです。全ての課題を解決する夢のような理想的な技術は存在しません。だからこそ、技術を選定する上ではまず技術によって「解決したい課題」を可能な限り明確化し、それが最終的な目的(仕事としての技術であれば、ビジネス上の利益やサービス向上等)とどうつながるのか、という意識は忘れないようにしなければなりません。

立場の明確化

このページの記載内容は「何らかの連携を前提としたSDN」の採用に対して検討を促すスタンスで書かれています。視点には強いバイアスがあり、意見としてかなり偏っている内容となっていることは自覚しています。しかし、すでにSDNというもの自体に対する過度な期待が持たれているフェーズは過ぎ去りつつあると考えており、現実的に課題解決の手段としての技術を検討することができる状況になりつつあるからこそ、技術はメリットだけではなくデメリットを含めた両面を冷静に見極めた上で選定されるべきです。

もちろん、技術的ではない様々な理由や事情で技術を選定せざるを得ないケースも多々あることも理解しています。また、立場によって同じ技術に対しても見方や意味合いが違ってくることもまた事実です。Qiitaに公開される多くの情報は、対象とする技術の良さ、つまりはメリットの側面を伝えるスタンスで書かれていますが、その技術の課題を明確にすることもまた大切なことであると思いますし、本ページの情報はSDNという技術を採用するにあたって考慮すべきことについて、あくまでも個人としての1つの見解として書かさせて頂いています。反論もあると思いますし、あるべきです(ぜひコメントをお寄せ下さい)。しかし、様々な視点でSDNを語ること自体には立場を超えた意味があるはずです。

技術を利用する側も提要する側も、この↓有名な教訓？を他人事とせずに心に留めておきたいものです。

SDNを検討する目的はなんですか？

安定して変化しないことが逆にリスクになってしまう!?

あなたの目的は、究極的にはSDN製品を導入することでも、ネットワークを仮想化することでもないはずです。ビジネスを支える基盤としてのITリソースに求めることが俊敏性や迅速性なのであれば、そのために最適な手段を幅広く検討するべきなのであり、SDNの導入自体は目的にはなり得ません。

しかしSDNを検討する、という時点ですでにあなたは現状のネットワークに何らかの課題を感じられてはいるはずです。もしくは、従来のネットワークのままでは困難もしくは不可能であったことに対応したいと考えられているのかもしれません。そのためには、従来の「何も問題がない限り触らない」「どうしても必要にならない限り変更もアップグレードもしない」というスタンスでネットワークを扱うのではなく、「価値を提供することができるサービス」としてネットワークを捉えることができるようにするための新たな仕組みが必要となることは確かであり、たとえそれがチャレンジだとしても前進しようというスタンスがネットワークの世界にも求められる様になりつつあることは確かです。

ソフトウェアとハードウェア

まず前提として、ソフトウェアだけで実現するネットワークがSDN、ではありません。最近ではどのメジャーなPublic Cloudプロバイダもがハードウェアへの積極的な投資と開発に勤しんでいることからもわかるように、ソフトウェアとハードウェアは両輪として適切に組み合わせてこそ、最も大きな価値を発揮することが可能です。

ITにおいて、ソフトウェアのないハードウェアは基本的には存在しません。しかし、少し前まではソフトウェアはあくまでも主役であるハードウェアを使うための脇役的な存在という位置づけとして扱われていました。しかし今やソフトウェアの重要性はハードウェアと同等もしくは上回っていることは誰もが理解するところです。皮肉なことに、ハードウェアの進化がソフトウェアの重要性を高めた、とも言えます。潤沢なリソースと高速な処理性能を提供するハードウェアによりソフトウェアで処理することのオーバーヘッドは最小化し、使い方次第ではハードウェアの制約を乗り越える手段としてソフトウェアが活用されるようになっていきました。物理的なサーバに依存しない仮想マシンや、RAIDコントローラに依存しないクラスタファイルシステム等は、その利便性の高さからあっという間に普及し、当たり前のように使われるようになりました。

SDNの視点に戻れば、仮想スイッチ、仮想ルータ、仮想ファイアウォール、仮想ロードバランサなどを利用すること自体は目的ではないはずです。物理的な調達を必要とせず、高い処理性能を必要としなければ、仮想アプライアンスが便利な存在であることは確かです。しかし主役がソフトウェアになったとしても、逆にハードウェアを重要な脇役として上手くソフトウェアから使えてこそ両輪は成立します。つまりSDNはソフトウェアがもたらす価値を最大化することを重要視した新しいネットワークの作り方、といえるかもしれません。

ソフトウェアは新たな価値を生み出し、ハードウェアは実用的な性能とスケーラビリティを実現します。SDNをソフトウェアだけで考えることも、ネットワークFabricをハードウェアだけで考えることも、いずれも片目を閉じて運転するに等しい行為です。ソフトウェアが得意な部分とハードウェアが得意な部分を上手く組み合わせた仕組みを活用することが、「解決したい課題」を最もシンプルかつ現実的に解決する手段となり得るのではないでしょうか？

※上図ではCisco ACIをハードウェアとソフトウェアを組み合わせた仕組みの例としていますが、それぞれのお客様毎にソフトウェアとハードウェアのどちらにどれだけ比重を置くのか、どのようなソリューションを採用するのかの判断は異なるはずです。しかし、いずれにしろどちらかだけではない、ソフトウェアとハードウェアを組み合わせるべきであるという点は、どのようなソリューションを選択するとしても重要な視点です。

SDNとFabric

SDNでソフトウェアとしてのネットワークの価値を最大化できるのだから、その通信を支える物理ネットワークは単なる土管としてシンプルで安定した物理的な可用性を担保してくれるだけのFabricネットワークとしての役割さえ果たしてくれれば良い、という考え方があります。しかしこのSDNとFabricを分離した実装では、Overlayとしてのソフトウェアで構成された仮想ネットワークと、Underlayとしてのハードウェアで構成された物理ネットワークの2面を管理することとなります。ネットワークが2面に分離するということは、全てのコンピューティングリソースは、Overlay側に属するのか、Underlay側に属するのかで分離することを意味します。また、OverlayとUnderlayをつなぐためには、どこかに橋渡しをするGatewayが必要となります。たとえUnderlay側としてどんなに可用性と性能に優れたネットワークを構築したとしても、Overlay側とUnderlayをまたぐ通信が必要になる限り、結果として可用性も性能もその全てはGatewayによって決まってしまいます。その結果、Underlay側のファイアウォールやロードバランサといったネットワークサービスすらOverlay側からは使いづらくなってしまい、コンピューティングリソースのみならず各種ネットワークサービスすらUnderlay側とOverlay側のそれぞれで管理が必要になってしまうかもしれません。そしてそのOverlay側のネットワークサービスのために使われてしまうコンピューティングリソースは、本来、ユーザに対してサービスを提供するために使うことができたはずのものだったはずです。

SDN

特定のHypervisorや、コンテナソリューションに依存したSDNは、その範囲においては最適化されていますが、ネットワーク全体から見て最適化されることはありません。今は部分最適で構わないと判断して導入したとしても、1年後、3年後にそのSDNの利便性がデメリットを上回っているかどうかは誰にもわかりません。特定のコンピューティングリソースに依存したネットワークは、逆に新たなコンピューティングリソースの仕組みを取り入れづらくなることや、最適化の対象とする範囲以外のコンピューティングリソースに対しては障壁になり得てしまう、ということ等は、忘れてはならない考慮点です。

Fabric

Fabricと呼ばれる統合されたネットワークは、それ単体でも物理スイッチの統合管理や可視化など様々な価値を提供しますが、SDNとFabricをバラバラに実装するのではなくそれらを一体化することによるメリットは非常に大きいと言えます。どちらをどちらに組み込むか、という視点で考えてみると、FabricにSDNを組み込むことはできても、逆はないのではないかと思います(Fabricの上でSDNを使うことはあっても、SDNの前提がFabricであることはないので)。しかしFabricにSDNが組み込まれることによって、特定のコンピューティングリソースに依存しないSDNを実装することができますし、ロードバランサやファイアウォールといったネットワークサービスについても既存の物理アプライアンスを利用することも、新たに仮想アプライアンスを利用することもどちらにも対応することができます。そしてなんと言ってもコンピューティングリソースの種類ごとに境界が発生しないので、どのような種類のコンピューティングリソースを使っていたとしてもそれらに共通のSDNを提供することが可能となります。

ネットワークとサーバ

ITの黎明期において、サーバとネットワークは一体でした。ネットワークはサーバ同士を回線で接続したことから始まり、最初はサーバの中にネットワークの要素が含まれていました。しかしその後の発展の中で、ネットワークは明確にサーバとは分離されるようになりました。なぜならば、サーバにとってはネットワークを切り離すことが、ネットワークにとってはサーバに依存しないことが、運用管理性の面でも機能進化の面でも理にかなっていたからです。

コンピューティングリソースの使い方

サーバは究極の汎用ASICとも言えるCPUと人類の英知の結晶の1つであるOSを組み合わせることによって、アプリケーションの実行基盤として最適なコンピューティングリソースとして進化してきました。つまりサーバはサービスを提供するアプリケーションのためにそのリソースを最大限活用することが、最もその価値を最大化する利用方法であるはずです。L4-L7のネットワークサービスを提供するNFVも一種のサービスを提供するアプリケーションと考えるのならば、仮想アプライアンスの利用もコンピューティングリソースの使い方として価値を発揮できる範囲と言えるでしょう。

ネットワークリソースの使い方

ネットワークを構成する様々な要素の中でも、特に高い処理性能を求めるL2/L3スイッチでは通信のフォワーディング処理に最適化されたASICを活用することによって超高速で低遅延なネットワークを実現しています。DPDKや各種オフロード機能を活用したとしても、汎用的な処理を行うためのCPUとDRAMをMemoryを使ったネットワークが、パケット処理に最適化された専用ASICとTCAMで実装されたネットワークの性能を上回ることはありません。また、DPDK等の仕組みは性能と引き換えに高いCPU負荷を必要とする技術であり、結果的にコストパフォーマンスとして見てもネットワーク専用機であるスイッチやルータの利用と比較して必ずしも優れているとは言えないケースもあり得ます。

また、ソフトウェアなSDNへの移行は、従来のネットワークの運用管理とは全く異なる すべてが新しい仕組みを使った運用管理が求められることにつながります。Fabricに融合されたSDNであれば、フォワーディング処理自体はハードウェアが持つASICの処理性能と信頼性をそのまま活用することができますし、スイッチングにしろルーティングにしろ、その処理自体は長年の実績を持つ仕組みを使いつつ、SDN的な統合された管理性や自動化などにつながる連携などを実現することができます。

ネットワークリソースがコンピューティングリソースに依存することの課題

せっかくネットワークとサーバが分離したにもかかわらず、ソフトウェアなSDNを導入するということはコンピューティングリソースの中にネットワークリソースを再度持ち込んでしまうことにつながります。単なる仮想スイッチなのであれば当該サーバ上の仮想マシンに対する接続性を提供するだけの存在ですのでVMを利用する以上どうしても必要な要素ですが、仮想アプライアンスがホスト上で動作していれば、当該ホスト自体もしくはそのホストと物理ネットワークの間で通信の問題が発生した場合には、広い範囲のネットワーク通信に影響が及ぶことになります。つまりその仮想アプライアンスとしての仮想ルータや仮想ファイアウォール、仮想ロードバランサなどに依存したネットワーク範囲においては、ネットワークの性能も信頼性も可用性もそれら全てをこの仮想アプライアンスが決定してしまうこととなります。またホスト側にOverlayネットワークの境界となるTEP(VTEP)が配置された場合には、物理ネットワークとしての通信の見え方とOverlay側ネットワークとしての通信の見え方が異なる状況となるため、問題発生時にはUnderlay側とOverlay側の両面からの切り分けが必要となってしまいます。

適切に繋がりあえる、とはどういうことか

従来、ネットワークはコントロールプレーンレベルでの経路情報交換とデータプレーンレベルでのヘッダ情報に基づくフォワーディング処理を行う仕組みがその全てでした。SDNにおいては何らかのコントローラがマネジメントプレーンとしてさらに追加されることによって、ヘッダ情報以外の様々な情報に基づいた通信の管理と制御が可能となっています。しかしその前提としては引き続きデータプレーン及びコントロールプレーンにおけるネットワークの制御が重要であることには変わりなく、それらの仕組みをどう実装しているのかは技術を選定する上でとても重要な要素です。

密結合であることの課題

高度な連携、つまり密結合であることは、一見とても価値があるように感じます。深い連携が可能となりますので、従来は不可能であった様々な機能を実現することが可能となります。しかし、SDNを検討する上では導入時点だけではなく、その後に続く運用フェーズにおける管理性やメンテナンス性、そして将来におけるバージョンアップや拡張などまでを考慮に入れておく必要があります。

サーバ側にネットワークの機能が組み込まれることは、ネットワークのメンテナンスの際にサーバを考慮する必要が生じるということを意味しており、サーバのメンテナンスの際にはネットワークを考慮する必要が生じるということも意味します。また、仮想アプライアンスの増加は、管理対象となるネットワークを構成するコンポーネントが運用フェーズの中で増加していくことを意味します。

たとえばHypervisorに組み込むことが必須であるSDNを選定した場合には、何らかの理由でHypervisor側のアップデートが必要になった場合に、組み込まれているSDN側のアップデートも必要になることによってネットワークへの影響が発生したり、逆にSDN側のアップデートが必要になった場合にHypervisor側もアップデートしなければならなくなるなど、運用管理上の密結合はネットワークとサーバの間で相互の依存性を高めてしまうことに繋がります。

疎結合な連携のメリット

SDNという使い方を考えた場合、課題はあれど連携することのメリットは数多くあります。連携には何らかのモジュールやプラグインを組み込むタイプのいわば密結合な連携と、単に相互もしくは一方通行でAPIレベルで連携するだけの疎結合な連携があります。

疎結合な連携は密結合な連携と比較して相互の依存度が低くなるため、連携することによるメリットを享受しつつ、連携することによる管理・メンテナンス性の低下というデメリットを最小化することができます。連携の方法と実装が密結合なのか疎結合なのかは、同じ連携といっても大きな違いがあり、運用メンテナンス性を考慮するのであれば重要な確認ポイントの1つと言えます。

連携しない、という選択肢の重要性

多くのSDNソリューションが、何らかの連携を前提としています。しかし、連携するということは前述の通り大なり小なり何らかの依存関係を生じさせることであり、メリットと引き換えにデメリットも生み出します。Fabricに組み込まれたSDNソリューションは、コンピューティングリソースとは一切連携しないという選択肢も持っているということが、実は最大のメリットなのではないかと考えています。なぜならば、連携しないFabric側に組み込まれたSDNはコンピューティングリソース側に一切の要件を求めないからです。メインフレームやUNIXなどのレガシー資産への対応はもちろん、逆に今は存在しなくても今後登場するかもしれない新たなコンピューティングリソースの形態が生まれたとしても、EthernetやIPで通信する仕組みさえ持っているのであればそれらを組み入れることが可能です。

SDNを検討する際に、ついついベンダー側も利用者側もメリットの方にばかり目が行きがちです。しかし部分最適となってしまわないためにも、そして対象範囲外との間に境界を作ってしまわないためにも、全体にとって、そして何よりも「解決したい課題」に対する手段として、その選択が最適なのかどうかはしっかりと検討した上で技術の採用は決定されるべきだと思います。

ITリソースとアプリケーションの垣根は次第に曖昧になっていく

SDNに限らず、ITリソースは次第に構成するものからプログラムするものへと変化しつつある過渡期にあると感じています。なぜならば、プログラマビリティを持つことは、自動化や高度な統合を実現するためには欠かせない手段であるからです。

そして、ネットワークにプログラマビリティをもたらす仕組みとして、SDN + Fabricという手段はとても有効です。大きく変化しつつあるからこそ、私達は適切な手段を選択するための技術の視点と、目的を意識して技術を選定するためのビジネスの視点の両方を持ち合わせることがより求められるようになっていくでしょう。

最後に & vExpertについて

現在、vExpert 2020のRegistration期間ですが、来年もvExpertの継続を目指すべきかどうか、悩んでいます。とてもありがたいことに、10年間もの間このタイトルを頂き続け、vExpert として多くの方々と知り合い、とても有意義な経験をさせて頂いてきました。そのつながりは私にとって大きな財産の1つであり、今後も可能な限りつながり続けていきたい方々ばかりです。

同時に、10年の間に私のVMwareとの関わり方も大きく変化してきたこともまた事実です。VMwareのコミュニティやソリューションに貢献することがvExpertに求められる要件なのであれば、私の現在の関わり方はちょっと異質な気もしますし、ちょうど10年という区切りもいい機会なのかもしれないとも思っています。このエントリーに対するコメントなどを頂ければ、そうした声も考慮した上で判断していきたいと思います。

長文なエントリーを最後までお読み頂いてありがとうございました。