Internet Infrastructure Review（IIR）Vol.57
2022年12月26日

2. フォーカス・リサーチ（1）

IIJの新バックボーンネットワーク「VX」

2.1 はじめに

2022年6月にIIJでは広帯域で柔軟なクラウド接続を実現する新たなネットワークサービス「IIJプライベートバックボーンサービス/SmartHUB」（以下SHBサービス）の提供を開始しました。SHBサービスのネットワーク基盤として、新たなバックボーンネットワークとなるVX（Virtualization eXchange 社内呼称：ブイエックス）を構築し、リリースを行っています。本稿では、IIJの新たなバックボーンネットワークとして仲間入りをしたVXの概要と構築に至った経緯、これまでのバックボーンネットワークとの違いを様々な観点から深く掘り下げます。

2.2 IIJバックボーンの歴史を振り返る

最初に今まであまり多くを語られてきていないと思われるIIJのバックボーンネットワークについて歴史を紐解いていきたいと思います。

VXはIIJのバックボーンネットワークの中では4世代目のネットワーク基盤となります。世代ごとに少しまとめてみましょう。第1世代は、IIJ設立初期からあるレイヤー3のIPネットワーク（以下BB）です。IIJ設立当初、192kbpsの回線から始まったBBは、その後、日本国内にとどまらず、世界一周を果たすまで大きくなりました。当初の192kbpsの回線は、2022年現在は100Gbpsの広帯域が主力となり、次世代の400Gbpsの導入を検討するところまで来ています。そして現在もIIJのインターネット接続サービスに始まり、様々なサービスのインターネット基盤として拡大を続けています。

拡大する

図-1 2006年頃のIPバックボーンマップ（大阪-東京間をスクエアで構成していた時期）

その第1世代のバックボーンネットワークであるBBも2010年代に転機を迎えます。それまでのBBは物理構成と論理構成を同一トポロジーとするポリシーで構築されており、ルータや回線を用いてトラフィックを如何に効率良くかつ安定的に運ぶかを追求したネットワークでした。当時のBBは東京と大阪にコアルータを2台ずつ置いたスクエア構成であり、東日本のリーフ拠点がV字構成で接続していました。このネットワークトポロジーは一見効率が良さそうに見えますが、東京-大阪間で最もトラフィックの多い箇所の帯域を常に50%以下にしておく必要がありました。そして片系統で障害やメンテナンスが発生した際には、もう片系統にすべてのトラフィックを迂回させなければならず、実際の対応においても運用的な負担やコストが高いことが課題でした。そこで耐障害やトラフィックバランスの効率を最大限に高めるため、バックボーンファブリック（BF）と呼ばれるコアルータ間のメッシュネットワークをキャリア回線や自前のWDM装置を用いて作成し、コアルータ間をN+1構成で接続できる仕組みを導入しました。当時のBFを構成したルータは東京に6台、大阪に4台、最終的にはUSの西海岸と東海岸まで広げました。BF構成にしたことで東京-大阪間のトラフィック効率は極限まで高まり、コアルータがスクエア構成のときよりもトラフィック影響を最小限に安定的に通信を運べるようになったと思います。BF構成は10Gbpsイーサネットや9.6GbpsのSONET/SDH回線で作っていましたが、IIJはキャリアではないため自前の回線網を持っていませんでした。回線網を持っていないことで回線利用料のコスト負担が増えるデメリットこそありましたが、それ以上に回線事業者を自由に選択でき、かつ回線本数が多くなるBF構成において回線経路の選択肢を広げて調達できるという利点がありました。

拡大する

図-2 2013年頃のIPバックボーンマップ（BF構成を作成していた頃）

そのような理想を実現したBFも、あるときを境に構成維持に限界を迎えることになりました。BFを最大限に利用するためにはコアルータからBFへの接続リンクをフルメッシュで構成する必要があり、増速時に多数のバックボーンリンクを作る作業負担がとても大きくなってきてしまったのです。当時のネットワークトポロジーのポリシーは、物理構成＝レイヤー3の論理構成として構成や運用を行う際はシンプルに考えることを前提にしていました。しかしながら、物理的な構成維持が限界を迎えてしまったので、物理構成=論理構成という考え方を改めることになりました。そして、IIJのバックボーンネットワークは第2世代へと進化しました。

第2世代として誕生したのがWARP（社内呼称：ワープ）と呼ばれる仮想レイヤー2網です。WARPのコンセプトは物理構成に依存しない拠点間ネットワークの実現であり、BF時の課題点を改善することでした。そのためWARPからはIIJバックボーンネットワークでそれまで利用してこなかったMPLSを用いたラベルスイッチング技術による論理パスの作成を始めました。BF時は物理回線でレイヤー3のロードバランシングパスを作っていましたが、WARPで拠点間ネットワークの仮想化を行ったため直接物理的に接続していない拠点間のレイヤー2接続も自由に作成することができ、BBのトポロジーの自由度が上がりました。BFで物理的に構成していたネットワークノード間のフルメッシュ接続を、WARPを使って実現することができたのです。2022年現在もWARPを用いたIIJ拠点間のネットワーク構成は継続・拡大しており、BBのコアルータは日本国内+アメリカの主要ルータで仮想レイヤー2としてフルメッシュ構成をとっています。そしてレイヤー3ネットワークのOSPFにおいて最適な論理パストポロジーが実現できており、トラフィックエンジニアリングを精度高く実現できるようになっています。

拡大する

図-3 2022年現在のIPバックボーンの論理構成
※中心でメッシュ上になっている箇所をWARPのレイヤー2VPNで実現しています。

ここまではIIJの拠点間で発生するインターネットトラフィックを如何に効率よく安定的に通信できるかを考えたネットワークでしたが、第3世代のバックボーンネットワークは個別のサービス設備間の連携に視点を向けました。そして2010年代中盤に第3世代のバックボーンネットワークとしてサービス基盤提供を開始したのがMATRIX（社内呼称：マトリックス）です。MATRIXのコンセプトはマルチポイントをつなぐ広域なプライベートネットワークの提供で、これまで独立して存在したサービス設備用のネットワークとの相互連携を簡単に行うことです。WARPは仮想レイヤー2接続を提供するためのネットワークでしたが、MATRIXは異なるレイヤー3ネットワーク間を閉域網で接続するいわゆるレイヤー3VPNのネットワーク基盤です。MATRIXが誕生する前は、異なるレイヤー3ネットワークを相互接続するためには、個別に用意した閉域網を利用する以外は各設備でグローバルIPアドレスが必要で、各サービス設備間のネットワーク接続には第1世代のIPバックボーン経由で通信することが一般的でした。個別に閉域網を構築するためにも複数のWARP回線を用意したり、インターネットVPNのためにPEルータを個別で経由させるなど、どうしてもひと手間かかることが課題でした。そこでレイヤー3VPNの独立したネットワーク基盤をバックボーンネットワークとして用意することにより、サービス設備担当者側では閉域網を特に意識せず、必要なネットワーク間の相互接続を容易にできるようにしました。今でこそクラウド全盛期であるため当たり前となりつつありますが、異なるプライベートネットワークやインターネットを経由しないプライベートネットワークは社会的ニーズが非常に高いものです。MATRIXがサービス設備間のネットワークを柔軟に接続することで各サービス設備間でのネットワーク連携が強化され、IIJの提供サービスもより柔軟なものとなりました。そして現在でもIIJのクラウドサービス「GIO」や各種パブリッククラウドとの閉域接続サービスのネットワーク基盤としてサービスの拡大に寄与し、多くのお客様へ高品質な閉域網サービスを提供しています。

2.3 VXのコンセプトとVXコントローラの導入

少々長くIIJバックボーンネットワークを世代ごとに振り返ってきました。このように、IIJバックボーンネットワークはそのときの必要性や課題解決のために進化してきました。そしてVXも、IIJバックボーンネットワークのこれまでの課題の改善や世の中のICTサービスで要求されているサービスコンセプトの実現を目指して導入を進めてきました。IIJのお客様においても業務でのクラウド利用が進み、また2020年からの新型コロナウイルスの感染拡大の影響によって更にクラウド利用が加速しました。このような状況下では業務系システムクラウドのトラフィック量が急激に増加していくことになり、より広帯域なネットワーク帯域が要求されます。更に必要な帯域やクラウドリソースの確保においても、利用者が利用したいときに利用したい分だけフレキシブルにそれらを利用できる柔軟なサービスが求められており、IIJのサービスとしても必要な要素です。しかしながらMATRIXではネットワークの安定性やセキュリティといった要素はサービス基盤として提供できていましたが、お客様からいただく広帯域化に対する要望にどうしても増速スピードが追いつかなかったり、お客様のデリバリ作業を人手によるマニュアル作業で対応するという運用スタイルのためIIJ内部の運用負荷が高まったりと、ネットワーク基盤として改善すべき課題がありました。昨今のパブリッククラウドではネットワークは抽象化され、クラウド機能の一部としてユーザが物理的な仕組みを意識せずにネットワークを自由に利用できますし、コントロールパネルから自身で必要なインスタンスを立ち上げその瞬間にクラウドリソースを利用できるなど、ユーザのスピード感にマッチした提供形態が一般化してきています。そこでよりお客様の求めるサービスをIIJで提供できるようにするために、第4世代のバックボーンネットワークとしてVXを検討しました。

VXの狙いはIIJが様々なサービスをお客様へ素早く柔軟に提供するためのネットワーク基盤を実現することです。先に述べたように、広帯域で安定的なネットワークはもちろんのこと、IIJサービスをNFVとしてお客様に提供する際にもサービス設備からの需要に応えられるネットワーク基盤として検討しました。VXのコンセプトを実現するためにIIJバックボーンワークとして初めてネットワークコントローラを使ったSDNでの制御を導入しました。昨今のSDNはオープンソースを活用して一からすべて組み上げて実現することもできますが、VXの構築にあたっては普段から密に連携しているベンダーのソリューションを最大限活用する方法を選択しました。VXの初期基盤にはシスコシステムズ合同会社のデータセンター向けSDNソリューションであるCisco ACI （Application Centric Infrastructure）を採用しています。Cisco ACIはネットワークノードにNexusシリーズのレイヤー3スイッチを利用し、SDNコントローラであるAPIC（Application Policy Infrastructure Controller）から各ネットワーク構成をコントロールすることにより簡単にネットワークファブリックを構築することができます。もともとはデータセンター内のサーバネットワークとして一般的なReaf/Spine構成のIP-Closネットワークを簡単に実現するためのソリューションとしての位置づけですが、IIJではデータセンター内の利用にとどまらず、複数の拠点間でユーザを終端するPOP、NFVのサーバ基盤、そして外部パブリッククラウド間を相互接続するネットワークとしてカスタマイズしながら利用しています。

SDNの導入によりバックボーンネットワーク運用では、CLIによるルータへのオペレーションが主な手段であった頃から、SDNのコントローラを介したネットワーク設定の投入やネットワーク全体の状況把握などコントローラを中心とした運用手法へと変換しました。SDNコントローラを導入して最も変わったことはAPIによるネットワーク制御が可能となったことです。Cisco ACI内部の設定もネットワークエンジニアだけではなくアプリケーションエンジニアでも利用できるように論理設定が抽象化され扱いやすい構造となっているのですが、それでも利用者に直接触ってもらうためには敷居が高いものでした。そこでVXではCisco ACIのAPIを利用して、利用者が扱いやすいモデルに更に自分たちでACIの設定からモデルを定義してシンプルな構成に見えるように構造を抽象化しました。利用者側ではVXの最低限の接続要素やパラメータだけで必要な拠点間を接続できるようなサービス提供形態としました。抽象化して構造をシンプルにしたことでVXと各IIJサービス設備をAPI連携させることも考えやすくなり、VXをNFVの基盤ネットワークとしてIIJサービス設備で有効利用しやすくなったと思っています。VXでは、VXコントローラ（少々紛らわしいのですが）という呼称で、APIインタフェースを用意しています。今まではバックボーンネットワークの運用者がお客様やサービス設備を接続するための設定を行ってきましたが、APIを開放することによりVXの利用者がオンデマンドに設定を投入することができるようにしています。人手をなるべく介さずにネットワークインフラが利用できることで、利用開始までのタイムラグを短くしたり、IIJサービスでよりNFV的にサービスを検討、展開することが容易になったと思っています。実際にはVXもAPIインタフェースも既に利用は開始されており、SHBのサービス提供はネットワーク基盤としてVXを利用しています。SHBで用意したコントロールパネルのバックエンドAPIサーバとVXコントローラがAPI連携することで、お客様がオンデマンドにIIJバックボーンネットワーク上でネットワーク制御を実現できる環境を提供し、IIJ内部サービスデリバリを自動することにも成功しています。

なお図-4はVXコントローラのGUI操作画面イメージのサンプルです。コンフィグを投入するというよりも必要なパラメータをGUIの設定画面に従い、ポチポチと入力していけばエンドエンドが作成できます。APIインタフェースも用意されているためGUIと同様の設定をAPI経由で行うことも可能です。

拡大する

図-4 VXコントローラのGUI操作画面イメージ

VXが柔軟で広帯域を提供できるNFV基盤となるためには、ネットワークの拡大・拡張がしやすいということも必要な要素として挙げられます。広帯域化の要素はCisco Nexusの高密度広帯域のポート構成を最大限に利用しています。もともとのMATRIXもキャリア向けの高性能ルータを使ってネットワークを構築していましたが、高性能ルータはどうしてもポート密度が少なかったり、ポート単価が高くなったりと有意義なポート増強を妨げる側面もありました。その点Nexusはレイヤー3スイッチであり、インターネットフルルートを前提としないIPファブリックを構成することに特化したネットワーク機器です。ネットワークの利用用途を絞ったことにより今までのIIJバックボーンルータで採用してきたキャリア向け高性能ルータとは求められる要件が異なり、より安価に広帯域な通信容量を確保することに一役買っています。上記のように機能を絞ったことにより、ネットワーク拡張によるイニシャルコストをある程度削減することに成功しています。そして、VXへの接続を容易にするためにスケールされたネットワークとしてVXとの接続ポイントを拡大することが必要です。ネットワークをより広げやすくしたことでIIJにおいてもサービス設備の展開がしやすくなり、多くのお客様がVXへ接続しやすくなるでしょう。ネットワークの拡大は柔軟なNFV基盤としては昨今MEC（Multi-access Edge Computing）に代表されるようにユーザにより近い箇所でトラフィックを交換するという考え方にも合っていると思います。MECを実現するためにもルータやスイッチ、ファイアウォールなどの機能がよりユーザに近い箇所に必要となりますが、VXとNFV基盤をセットでお客様に近い場所にIIJがサービス展開することで実現可能となります。物理的な拡張だけではなく、NFV基盤として各サービス設備の論理的な収容もしやすくなっています。VXを基盤として利用する各サービス設備をテナントという形で論理的に分けてサービス提供を行います。ネットワーク的な分離だけでなくサービス設備ごとに操作できる範囲を限定することで複数のサービスを仮想的に収容することができます。そのため1つのテナントでの影響を他のサービスに波及させることもありませんし、VXの利用者からみれば自身のサービス設備に関することをVXで意識するだけで良くなります。前項で述べたAPIの制御も保有テナントに限定されるため想定外の接続先に接続されるようなリスクもありませんので、VXの提供者としてもコントロールを渡しやすくなります。

簡単にVXの全体イメージを提示します（図-5）。階層としては3段階になっており、先に紹介したSNDコントローラ/VXコントローラで基盤全体をコントロールする層、各データセンター間の接続を行う層、各DC内でのPOP/NFV基盤/パブリッククラウドを収容するLeaf/Spineのファブリックネットワークと分かれています。各ノードも冗長構成を基本としており、単一障害ではサービス提供へ影響が出ない設計となっています。特にSDNコントローラはスタンバイ1台を含めた6台構成をそれぞれ3つのデータセンターに配備しています。安定稼働のためには最低3台が同時に稼働する必要があり、1つのデータセンターが利用不可となったとしても絶対にサービス提供が滞らないような設計となっています。また収容拠点が増えたり、収容するサービスが増えた場合はSpine/Leafの構成をスケールアウトしていきます。必要最低限の機器でVXの接続点を拡張することができるため、サービス展開がしやすくなりました。

拡大する

図-5 VX構成図

2.4 VXでのネットワーク監視

VXでのNFV基盤利用が加速すると設備の監視や利用状況のモニタリングも重要となります。今までのバックボーンネットワーク機器はICMP echoによる死活監視、SNMPによる情報取得やトラップ受信による監視が一般的でしたが、VXではそれらに加えてmetricsを利用したネットワーク状況のモニタリングや情報の可視化の有効化と利用者目線でネットワーク品質を監視できる仕組みを導入しました。metricsの取得と保管については昨今広く利用され始めているオープンソースのPrometheusを利用しています。Cisco ACIもmetrics取得のための監視エージェントに対応しており、簡単に時系列データを取得することができました。また監視エージェントで取得できないデータについても、特定のデータフォーマットで時系列データを作成することでデータを簡単に取り込めるexporterもPrometheusで用意されているため、様々なデータをPrometheus上で扱うことが可能です。集めたmetricsはオープンソースの可視化ツールであるGrafanaを用いてDashboard形式でデータを可視化してネットワークの正常性確認が簡単に行えるようになっており、モニタリング結果が特定のしきい値を下回ったりすればアラートとして検出、通知できるように社内の監視システムと連携を行っています。モニタリングは機器の正常性やエラーだけではなく、ネットワークの帯域利用状況や接続可能インタフェースなどのサービスキャパシティ情報も可視化データとして取り込んでおり、キャパシティ確認の自動化を行えるような取り組みもPrometheus+Grafana利用で実現しています。

図-6は実際に利用しているVXのモニタリング用Dashboardのイメージサンプルです。各リソースやアラート状況を網羅的に確認できるようになっています。ネットワーク機器が正常なときは慣例的に緑色で表され、異常が発生すればオレンジ/赤色で示されることが多くあります。

拡大する

図-6 VXモニタリング用Dashboardイメージ

IIJがお客様へ提供しているネットワークの状況を利用者と同等の環境で把握することは難しいと感じています。バックボーンネットワークを構成するルータやスイッチなどのサービス提供用機器の監視を行うことはできますが、IIJ設備の監視だけではどうしても検出できず気づけないこともあります。実際に利用しているお客様が異変を検出しIIJへ問い合わせることにより障害が発覚するケースも残念ながら稀に起こってしまいます。いわゆるサイレント障害と呼ばれるもので、機器のアラームやログでは異常発生がないものの、お客様は通信ができない状態となってしまうことです。サイレント障害は我々ネットワークエンジニアがサービス提供をする上で長年の課題です。サイレント障害を如何にお客様より早く検出してサービス提供可能状態へ復旧するためにできることはないかと方法を模索してきました。VXはNFV基盤として多くのサービス設備間を柔軟に接続することを想定していますので、サイレント障害による影響が大きくなると考えています。そのためVXでは基盤利用者とできる限り同じ条件で通信状況をモニタリングができる仕組みを監視として導入しました。VXの各サービスエッジは品質監視用のサーバにすべて接続しており、各サーバ間でVXサービスエッジを介した通信が問題なくできているかを監視しています。基盤利用者と同じ目線で通信状況を把握できるため、万が一通信品質の悪化があればサービス設備の監視でアラート検出がなくとも何かしらのトラブルが発生しているということが確認できます。全サービスノード間の通信状況を監視するための手法を後付で構築することは、ネットワークが大きくなればなるほど手間や時間がかかるものです。VXでは設計当初から基盤利用者目線の監視の導入を並行して検討してきましたので、基盤提供開始に合わせてスムーズに始めることができました。

図-7はユーザ目線の監視のモニタリング画面です。時系列で各ノード間の通信状況が視覚的に分かるようになっています。画面上で赤色になっている箇所は実際にネットワークのメンテナンスを行った時間帯であり、一部通信に影響が出たことが分かります。また、特定のしきい値を下回った場合アラートがオペレーションセンターへ通知されます。

拡大する

図-7 VXサービスエッジ間の監視モニタリング画面

2.5 おわりに

今回はIIJの基盤ネットワークであるバックボーンネットワークを世代ごとに振り返りながら新たなにリリースしたVXの取り組み、コンセプトを紹介しました。1つ重要なことを最後に述べると、今までIIJは第1世代から第4世代まで複数のバックボーンネットワーク基盤を構築してきましたが、新しい世代のネットワークを作ったからといって前世代のネットワークを廃止・統合することはありません。それぞれのネットワークが最適な役割や機能を持ち、各バックボーンネットワークを相互に利用しながら全体最適を取っていくことを考えています。そして今ではどのネットワークもIIJのサービス提供において欠かせないネットワーク基盤となりました。新しく提供を始めたVXも前世代のバックボーンネットワークを置き換えるものではなく、様々なネットワークやNFV基盤、各種クラウドサービスを連携させる新たなバックボーンネットワークとして最大限活用し、お客様へ価値あるIIJサービスを提供していきますのでどうぞよろしくお願いいたします。

2. フォーカス・リサーチ（1） IIJの新バックボーンネットワーク「VX」

• 2.1 はじめに
• 2.2 IIJバックボーンの歴史を振り返る
• 2.3 VXのコンセプトとVXコントローラの導入
• 2.4 VXでのネットワーク監視
• 2.5 おわりに