データ駆動型のネットワーク管理

(1)

招待論文

Softwarized されたネットワークシステムのディスアグリゲーションと

データ駆動型のネットワーク管理

塩本公平

^†^a)

Data-Driven Network Management for Dis-Aggregated Softwarized Network System

Kohei SHIOMOTO

^†^a)

あらまし本論文では，最近のコンピュータネットワークの研究における大きなトレンドであるデータセンタネットワーク，ネットワーク仮想化・ソフトウェア化，機械学習や人工知能のコンピュータネットワークへの応用の研究を振り返りながら，2020年以降のコンピュータネットワークの発展の方向性を展望する．特に，データセンタネットワーク，ネットワークの仮想化・ソフトウェア化，ネットワークシステムをブラックボックスとして捉えてその入出力のデータを測定し測定された多量のデータに基づきネットワークシステムをモデル化しマネジメントを行うアプローチであるデータ駆動型マネジメントについてこれまでの研究状況を振り返り今後の方向性を展望する．

キーワードネットワーク仮想化，ビッグデータ，機械学習，人工知能，コンピュータネットワーク

1.

^{まえがき}

インターネットは，

1990

年代に商用化されて以来，

世界規模の自律分散型経路制御，

DNS

による階層的なドメイン名の分散管理，

World Wide Web (WWW)

などによりコンピュータネットワークの世界的な基盤となり，

90

年代後半に常時接続，

ADSL

や

FTTH

によるブロードバンドアクセスにより各家庭での高速なインターネットアクセスが可能となった．

90

年代後半から普及し始めた携帯電話を用いたインターネットアクセス，無線

LAN

技術の普及，第三世代携帯電話以降の移動体通信網により，モバイル通信は普及し，

高速化が進んできた．このようなトラヒック増加に対応するため

IP

網のバックボーンに光ネットワーク技術を導入するための研究が

2000

年代に活発になされた

[1]

〜

[17]

．

ムーアの法則は半導体の集積度が

18

ヶ月で

2

倍になると述べている．半導体の集積度向上による計算

†東京都市大学，東京都

Tokyo City University, Tokyo, 158–8557 Japan a) E-mail: [email protected]

DOI:10.14923/transcomj.2018PHI0001

能力の発達によってコンピュータそのものの更なる発達が続くといった相乗効果を生みながら，過去

50

年あまりでコンピュータの処理能力は指数関数的に向上してきた．コンピュータ関連の技術の発展により高性能なサーバのハードウェアを安価に購入できるようになった．通信機器の製造においてもマーチャントシリコンのチップを用いたホワイトボックススイッチが製造されるようになり，高性能なスイッチのハードウェアを安価に購入できるようになった．半導体の集積度の向上速度が鈍化しても，並列化や光部品の導入などにより，同じコストで入手可能なコンピュータの処理能力は指数関数的な向上は今後も続くと期待される．ムーアの法則に従いながらコンピュータの処理能力は

10

年でおおよそ

100

倍の性能向上が図られてきており，それによってもたらされるルータの高速化や高性能化やネットワーク仮想化などによりネットワークのアーキテクチャの抜本的な変化が生じ量的変化が質的変化を起こすようになる．近年，安価になった高性能ハードウェアの上でソフトウェアで機能を実現する

Software-Deﬁned Netwroking (SDN)

や

Network

Function Virtualization (NFV)

などの仮想化技術が進展している．

(2)

2007

年に

iPhone

が発表・販売されて以来，

2008

年からは

Android

端末のスマートフォンが販売開始

された．スマートフォンにはカメラ，

GPS

や様々なセンサが搭載され，それらの機能を意識したオンラインインターネットサービスが登場してきた．電子メール，

Web

ブラウジング，情報検索，映像ストリーミング，ソーシャルメディア，オンラインストレージなどのサービスが普及し，トラヒックの増加につながっている．データセンタネットワーク内での帯域需要は，

広域インターネットの増加率を凌ぐ速度で増加しており，

12

から

15

ヶ月で

2

倍に増加している

[18], [19]

．

Google

，

Amazon

，

Yahoo!

，

Microsoft

などのオンラインインターネットサービス事業者により様々なサービスが提供されるようになる一方で，これらの事業者はハイパースケールデータセンタと呼ばれるデータセンタを世界中の拠点に構築するようになっていった．

これらのデータセンタにはエンドユーザの様々な情報が蓄積されるようになり，これらのデータを分析することで自社のサービス改善を行うようになっていった．

データの蓄積が進む中で機械学習や人工知能がこの

20

年余りで飛躍的に発達した．

昨今

Internet of Things (IoT)

が喧伝されているように，今後はあらゆるモノがインターネットにより接続されて，情報を収集・蓄積し，機械学習や人工知能を用いたビッグデータ分析技術を用いることで，あらゆる産業，交通・自動運転，ヘルスケア，エネルギー，

環境，行政，教育，防災が進化する時代が到来することが期待される．本論文では，最近のコンピュータネットワークの研究における大きなトレンドであるデータセンタネットワーク，ネットワーク仮想化・ソフトウェア化，機械学習や人工知能のコンピュータネットワークへの応用の研究を振り返りながら，

2020

年以降のコンピュータネットワークの発展の方向性を展望する．

特に，これからのネットワークアーキテクチャの進化を主導していくであろうデータセンタネットワーク，

ネットワークシステムをディスアグリゲートしクラウド型サービスを用いることで機敏に対応しコスト競争力のある迅速なネットワークサービスを提供するネットワークの仮想化・ソフトウェア化，ネットワークシステムをブラックボックスとして捉えてその入出力のデータを測定し測定された多量のデータに基づきネットワークシステムをモデル化しマネジメントを行うアプローチであるデータ駆動型マネジメントについて述べる．本論文の構成は以下のとおりである．

2.

^におい

てデータセンタネットワークに関する研究動向を振り返る．

3.

においてネットワーク仮想化・ソフトウェア化に関する研究動向を振り返る．

4.

^{においてデータ駆} 動型マネジメントと機械学習・人工知能のコンピュータ・ネットワークへの応用に関する研究動向を振り返る．

5.

において本論文のまとめと今後の展望について述べる．

2.

データセンタネットワーク

オンラインインターネットサービス事業者は急増するトラヒックに対応するためにハイパースケールデータセンタと呼ばれるデータセンタを世界中の拠点に構築している．これらのハイパースケールデータセンタ内のトラヒックの増加はインターネットのトラヒックの増加量を凌ぐ速度でトラヒックが増え続けており，これからのネットワークアーキテクチャの進化を主導していくであろう．このように多量のトラヒックを運ぶデータセンタネットワークが今後のネットワークアーキテクチャの変化に大きな影響を与えていくと予見される．ここではデータセンタネットワークに関するこれまでの研究について振り返る．

2. 1

データセンタネットワークのトポロジー：

Fat Tree

オンラインインターネットサービス事業者は電子メール，

Web

ブラウジング，情報検索，映像ストリーミング，ソーシャルメディア，オンラインストレージなどのサービスの急激な普及に伴いデータセンタを拡張していった．データセンタネットワーク内での帯域需要は，広域インターネットの増加率を凌ぐ速度で増加しており，

12

から

15

ヶ月で

2

倍に増加しており

[18], [19]

，急増するトラヒック需要に迅速に対応しながら低コストで拡張性のあるデータセンタネットワークを構築する一方で，ハイパースケールデータセンタと呼ばれるデータセンタを世界中の拠点に構築するようになっていった．データセンタネットワークの初期の研究では

Fat Tree

型等の規則的な構造をもつトポロジーのものが活発に研究されてきた

[18]

〜

[26]

．

DCell [21]

と

BCube [22]

はサーバを相互接続する再帰的なトポロジー構造をもつアーキテクチャであり，異なるレベルの

Dcell

と複数のリンクにより接続しながら，上位レベルの

DCell

は多数の下位レベルの

DCell

からなる完全結合グラフとして構成される．

安価な汎用のスイッチを用いて低コストで帯域効率の良いデータセンタネットワークを構築するために，

(3)

図1 データセンタネットワークのFat Tree型のトポロジー

Fig. 1 Fat Tree topology of data center networks.

図

1

にあるような

Fat Tree

型のトポロジーのものが提案された

[20]

．

Portland [24]

も

Fat Tree

型のトポロジーである．集中制御型のネットワークマネージャがネットワーク全体の状態を把握し，

ARP

解決，耐故障性，マルチキャストをハンドリングし，スイッチが軽量なプロトコルを用いてトポロジーにおける自分の位置を発見する．各ホストに割り当てられる階層的な擬似

MAC

アドレスを用いて，レイヤ

2

によるスケーラブルなパケット転送とルーティングを実現している．

VL2 [23]

も

Fat Tree

型のトポロジーである．

Valiant Load Balancing (VLB)

により複数の経路のトラヒック負荷を分散させることで任意の交流トラヒックパターンに対処している．レイヤ

2

と

3

の間に

Shim

レイヤ

(

レイヤ

2.5)

を設けて，ホストとネットワーク間の機能分離を行っている．

Hedera [25]

は集中型のマネージャがスイッチからフローに関する情報を収集し，各フローが競合しないような経路を計算し，

スイッチに経路を設定しトラヒックを迂回させることで，ハッシュ型の

ECMP

負荷分散よりも高い帯域使用効率を上げることを示している．

F10 (Fault-Tolerant Engineered Network) [26]

は

Fat Tree

型トポロジーの対称性に若干の歪を加えて効率的な局所的な迂回を可能とすることで耐故障性を向上させている．これらの提案

[20], [23], [24]

においては，

Fat Tree

型のトポロジーが用いてポートカウントや帯域の拡張性を確保している．

ハイパースケールデータセンタにおいてはクラスタは

16

ラックで構成されており，各ラックは

40

台のサーバが設置され，クラスタあたり

640

台のサーバを収容しているものが多い．ハイパースケールデータセンタにおいては，複数のクラスタがビル内で相互に接続され，複数のビルがキャンパス内で相互に接続されているのが一般的である．

Singh

ら

[18], [19]

は

Google

における

5

世代にわたるデータセンタネット

ワークについて報告している．マルチステージの

Clos

ネットワークを構築するに当たり，汎用のハードウェ

アコンポーネントであるマーチャントシリコンのスイッチチップを用いてスイッチハードウェア装置を開発しデータセンタネットワークを構築している．インターネットと異なりデータセンタは集中型の制御と管理を行い複数の等価経路によるパケット転送を行う．

集中型のコントローラが信頼性の高い

Out-of-band

の

C

プレーンを用いて動的なリンクステートを収集し再配布し各スイッチがリンクステートを用いてフォワーディングテーブルを計算する．データセンタは世界の数十拠点で稼働し

10

年間で

100

倍の容量拡張を行い

1Pb/s

以上の帯域を運んでいると報告されている．

2. 2

データセンタネットワークにおけるトラヒック特性

データセンタネットワークのアーキテクチャやトポロジー設計を考える上でデータセンタネットワーク内の交流トラヒックやトラヒック特性を把握することが重要である．以下ではデータセンタネットワークにおけるトラヒック特性の研究についてサーベイする．

データセンタと言っても様々な形態のものがありトラヒックやワークロードの特徴はデータセンタごとに異なってくる．大学キャンパスや企業においては自組織内の

IT

サービスの統合整理を進めるために数百台から数千台のサーバからなるデータセンタをオンサイトで構築している．一方で，ハイパースケールのオンラインインターネットサービスプロバイダは数万台以上ものサーバからなるデータセンタを世界中の拠点に分散させて，電子メール，

Web

サーバ，ストレージ，

Web

検索，ゲーム，インスタントメッセージ等の多様なクラウドサービスを提供したり，インデクシングや多量データセットの分析などのインハウスでの多量のデータ処理も行っている．このように様々なワークロードがあり分散されたデータストアに対して

Map

Reduce

型のデータ処理を行うワークロードもあれば，

電子メールやインスタントメッセージなどの

Web

リクエストに対する応答を返すワークロードもある．

ハイパースケールデータセンタの計算機資源の単位であるクラスタにおいては，検索インデックスの生成，

Web

検索，広告提供などの多数の相互に関連するアプリケーションが走っており多量のデータを互いに共有している．ネットワークへのアクセスを多用するデータ処理のパイプラインは，増加しづつけるデータセット上で動作し，個々のリクエストのクリティカルパス上にある多くのデータへアクセスする必要がある．このようなアプリケーションにとっては帯域が潤沢にあ

(4)

るほうが有利であるため，クラスタは大きくなる傾向にある．クラスタの規模が大きくなるほど，ジョブのスケジューリング効率が高くなり，計算機資源が枯渇してジョブスケジューリングが失敗する状況が発生する頻度を抑えることができる．大規模化するクラスタ内にわたってストレージが分布するため，データの信頼性を高めるために，ラックや電源に冗長性をもたせるようになる．すなわち，データはクラスタ内に広範囲に分散されトラヒックの局所性は小さくなりクラスタ内にわたり大きな帯域が必要となる．このように，

データの配置とジョブスケジューリングはほとんど局所性を示さなくなる．

Kandula

ら

[27]

は多量のデータセットのマイニングを行うために用いられている

Microsoft

のデータセンタネットワークのトラヒック特性を分析した．ソケットレベルのログを収集するためのソフトウェアを各サーバにインストールし，データセンタネットワークのトラヒックを収集した．交流トラヒック行列に関して，

多くのトラヒックの塊が同じラックのサーバ間でやり取りされることで発生する

work-seek-bandwidth

型のトラヒックパターンと，ある特定のサーバがクラスタ内の多数のサーバに対してデータのプッシュとプルを行うことで発生する

scatter-gather

型のトラヒックパターンの二つを見出した．後者のトラヒックパターン

は

Map Reduce

型のワークロードによるものであり，

データが多数の小さな塊に分割されて多数のサーバで分散処理される

Map Reduce

のジョブで多数のサーバで処理された結果が集計されている様子が反映されていると分析している．また，ほとんどのフローは短小であり

80%

のフローは

10

秒以内で終了し，

200

秒以上継続するフローは

0.1%

以下であり，長く継続するフローはほとんどないことを見出した．トラヒックの変化は非常に急激に起こり過渡的なスパイクもあればしばらく持続するスパイクもあり，激しいスパイクの中にはネットワーク全帯域の半分以上の帯域を占めることがあり，通信パターンで全二重通信を行っているものはほとんどないことを見出した．更に交流トラヒック行列内の総トラヒック量が同じでもサーバ間のトラヒックについてはかなり変化していることを見出した．

Greenberg

ら

[23]

は

Microsoft

のデータセンタネットワーク内の交流トラヒックの性質についてクラスタリングを適用して分類を行った．一日分のトラヒックデータである

864

の交流トラヒック行列のデータに

関してクラスタリングを適用した結果，

50

から

60

のクラスタに分類できることを明らかにした．交流トラヒック行列は将来の予測に役立つような周期性も示さずに変化を続けていることを見出した．このような周期性の欠如はデータセンタ内で走っているアプリケーションの性能を向上するためにランダム性などが用いられていることに起因していると考察している．

Benson

ら

[28]

は三つの異なるタイプのデータセンタに関して，

10

のデータセンタのトラヒックの性質を分析した．データセンタのタイプとしては，

Web

サー

ビスや

Map Reduce

型ジョブを走らせているクラウ

ドデータセンタ，ファイルストレージ，認証サービス，

業務アプリケーション，その他様々なサービスを走らせている大学キャンパスや企業のデータセンタ等の異なるタイプのデータセンタのトラヒックの性質を分析した結果，以下を明らかにしている．

（

1

）アプリケーションの配置はラックにまたがり均一であることはない．

（

2

）大半のフローはサイズが小さく

10KB

以下である．

（

3

）トラヒックは

Heavy-Tail

分布をもつ

On-Oﬀ

パターンである．

（

4

）クラウドデータセンタでは多数のトラヒックは同じラック内にいるサーバにとどまっているのに対し大学キャンパスや企業のデータセンタでは大半のトラヒックラック外に出ていきデータセンタネットワークを転送されて行く．

（

5

）リンク使用率はコア階層以外の階層では低い．

（

6

）使用率が低いリンクにおいてもパケット損失が発生しておりこれはスパイクによるものであると推定される．

（

7

）リンク使用率は日単位の変動や週単位の変動を示し特にクラウドデータセンタの多くにおいてはコアリンクでは一桁近く大きな変動となる．

Roy

ら

[29]

は

Facebook

のデータセンタのトラヒックの性質を分析している．

Facebook

における

Map

Reduce

型ジョブのトラヒックの特性については，文

献

[23], [27], [28]

で報告されているものと同じように振舞っている一方で，

Facebook

のサービスアーキテクチャのかなりの部分は

Map Reduce

型のジョブが示すトラヒック特性とは大きく異なり，以下の三つの測定結果を得ている．

（

1

）トラヒックはラック局所的でなく均一に分散しているわけでもない．

(5)

（

2

）多くのフローは長時間持続しているが多量のデータを運んでいるわけではない．

（

3

）パケットサイズは小さく非

Map Reduce

型ジョブの場合は中間値は

200

バイト以下であり

On-Oﬀ

パターンを示していない．

Ghobadi

ら

[30]

は

100

から

2500

ラックからなる四つの商用クラスタの

20

万台以上のサーバからのトラヒックトレースを分析した．ワークロードとしては，

Map Reduce

型ジョブ，検索インデックス生成ジョブ，

データベースやストレージシステムなどのジョブなどの混在のものである．ラック間のトラヒックを分析した結果，ほとんどのラックのペアではほとんど通信が行われておらず

46–99%

のラックペアは全くトラヒックを交換しておらず

0.04–0.3%

のラックペアがトラヒックの

80%

を占めていることを見出した．この観測結果から

Clos

や

Fat Tree

のような均一な帯域容量をもつデータセンタネットワークのトポロジーは過剰なリンク設備のため帯域が余るか，逆にリンク設備が不十分で帯域が不足するかのどちらかとなり，非効率であると考察している．

2. 3

データセンタネットワークの再構成可能なトポロジー

データセンタネットワーク内のトラヒック特性に関する最近の研究

[30]

によると，大規模データセンタでは幾つかのホットスポットが発生していることが報告されている．ホットスポットを緩和するため，

光

[25], [30]

〜

[37]

や無線

[38], [39]

を利用して，

TOR

スイッチの間に直接回線を設定し，トポロジーを再構成する方法が提案されている．例えば，図

2

のように光スイッチを

Tier-1

で用いると，トラヒックの偏りが生じ，特定の

Tier-2

スイッチ間の交流トラヒック量が大きい場合に，光スイッチを用いて二つの

Tier-2

スイッチ間を光パスで直接接続することでトラヒックの偏りに対応することが可能となる．このようなアー

図2 光スイッチを用いたデータセンタネットワークのトポロジー

Fig. 2 Topology of data center networks utilizing optical circuit switch.

キテクチャを実現する上でキーとなる高次元で低遅延の光スイッチや受動カプラと高速チューナブルトランシーバを用いた放送選択型の光スイッチの実用化を見据えた提案もなされている

[37]

．

Helios [32]

は電気によるパケットスイッチと光による回線スイッチを融合し，運用中のトラヒックパターンの変化に基づき，トラヒックの中で光回線で運ぶのに適したものを見つけて，動的にネットワークトポロジーを変更するアーキテクチャである．フル実装したパケットスイッチによるネットワークと同じ性能を，

大幅に安いコストで，ケーブリング，フットプリント，

設置作業量などの負担を大幅に減らし，低消費電力で実現できることを示している．

c-Through [31]

も電気によるパケットスイッチと光による回線スイッチを融合したアーキテクチャであり，サーバを活用して，送信側のサーバにおいてバッファを行い，光回線を使うのに見合う十分なだけのトラヒックを蓄積したら，光回線を設定し転送を行う．

Head of line (HoL)

ブロックや余計な遅延が生じないようにしてトラヒックをバッファする．

Helios

がトラヒック推定やトラヒック分離の機能をスイッチ側で行うのに対し，

c-Through

はサーバ側がこれらを行い，データをバッファし光回線が使えるようになったらバッファに蓄積したデータを送出する．

c-Through

と

Helios

が

1

ホップの大容量光回線で課題解決を図ったのに対し，

OSA [33], [40]

は，

1

ホップの光回線を乗り継いで，フルメッシュの接続性を作り，

mice

フローやバースト性の高いフローをそれらの複数の光パスを乗り継いで運ぶものである．

1

ホップ型のアーキテクチャでは対応が困難な

Fan-in

や

Fan-out

が高いホットスポットをもつようなワークロードに対応する．また，トラヒック需要の変化に応じて，動的に光回線の容量を細かい粒度で調整する．

Traﬃc Matrix Scheduling [34]

はアプリケーションの情報を活用して短期間の需要を見積もり，回線の短期間のスケジューリングを決定する．スケジューリングにより決められたとおりに選択された端点間の組に光回線を設定し光回線を高速に切り替えることでバッファリングや遅延を抑制する．

ToR

スイッチにはこのスケジューリングを知らせておき，宛先ごとに最も多くの帯域が利用可能な時間を知っておくことで，スケジュールに合わせてパケットを送出することで，短いフローと長いフローの両方を光回線スイッチにオフロードする．

(6)

REACToR [35]

も電気によるパケットスイッチと光による回線スイッチを融合したもので，

C

プレーンがエンドホストの送信と光回線の割当を同期させることで，エンドホストであるサーバから見ると

TOR

スイッチがパケットスイッチに見えるように工夫している．

C

プレーンのプロトタイプを作成し，高速に再構成できる光スイッチを用いることで，全体を電気によるパケットスイッチで構成する場合に比べて圧倒的な低コストでパケットスイッチと同等の性能を実現できることを示した．

FireFly [36]

はフリースペースオプティクス

(free space optics: FSO)

を用いたラック間の接続ネットワークであり，

FSO

を用いることで，

RF

無線の干渉の問題を回避している．以下の三つの点が大きな特徴である．

(1)

全てのリンクが再構成可能である．

(2)

全てのリンクが無線である．

(3) TOR

スイッチを除く全てのコアスイッチを不要とする．また，

dynamic bisection bandwidth (DBW)

という概念を提唱し，ランダム正則グラフ

(random regular graph)

を用いることで

DBW

を最適化することを提案し，最適に近い性能を達成するためのトポロジー選択とトラヒックエンジニアリングの発見的アルゴリズムを提案している．

ProjecToR [30]

もフリースペースオプティクスを用いたラック間の接続ネットワークである．

12

マイクロ秒以内に何万通りにも光の方向を変化させることができる

Digital micro mirror device (DMD)

を用いて，高い

Fan-out

と迅速性を可能とした．小さなフローを複数ホップも許容しながら運ぶための専有型

(Dedicated)

トポロジーと大きなフローをシングルホップで運ぶための機会型

(Opportunistic)

トポロジーの二つのトポロジーを組み合わせてトラヒックを運ぶ．専有型トポロジーの再構成は長時間スパンで行い，機会型トポロジーの再構成は現在のデマンドに応じて即座に実行される．

光技術を用いたトポロジー再構成については

IP over

Optical

ネットワークの研究においても活発に研究さ

れており

[1]

〜

[17]

，その研究成果はデータセンタネットワークのトポロジー再構成の研究にも参考になろう．

文献

[9]

〜

[14]

は仮想トポロジー設計に関する初期の代表的な研究であり光ネットワーク上で構成される

IP

ネットワークのトポロジーの設計法を提案している．

光ネットワーク上での

IP

ネットワークのトポロジー設計問題を混合整数線形問題として定式化して発見的なアルゴリズムを提案している．文献

[2], [8], [15], [16]

は

IP

ネットワークに加わる交流トラヒックが時間とともに変化することに対応するため，光ネットワーク上で構成される

IP

ネットワークのトポロジーを動的に再構成する方法を提案している．文献

[1]

〜

[7]

は

GMPLS

を用いた

IP over Optical

のマルチレイヤネットワークの制御に関するので特に文献

[5], [6]

は

PCE

を用いたマルチレイヤネットワーク制御に関するものであり，

文献

[4], [7]

はマルチレイヤネットワークサービスに関するものであり，近年のネットワークスライスに関する先行研究と捉えることもできる．

2. 4 Fat Tree

型トポロジーと異なる静的トポロジー

データセンタネットワーク内の交流トラヒックはデータセンタの用途によって大きく異なる．

Clos

や

Fat Tree

のような均一な帯域容量をもつデータセンタ

ネットワークのトポロジーは過剰なリンク設備のため帯域が余るか，逆にリンク設備が不十分で帯域が不足するかのどちらかとなり

[30]

，様々な交流トラヒックに対応するトポロジーについての検討が近年注目を集めている．

Jerryﬁsh [41]

や

Xpander [42]

などは

Fat Tree

型のもの

[20]

と異なり，ネットワークを階層化しておらず，

TOR

スイッチが直接接続されてデータセンタネットワークを構成している．

Fat Tree

型や

Clos

型のトポロジーでは利用可能なスイッチのポートカウントによって全体のネットワークの構成が決まってしまい，設計範囲が非常に粗くなり，容量を拡張する際に多くのネットワークエレメントの置き換えと多量のケーブルのつなぎ変えが発生するため，逐次的な容量拡張が極めて困難である．この課題を解決するために

Jellyﬁsh [41]

が提案されており，次数制約のあるランダムグラフトポロジーを

TOR

スイッチ間に適用することで，サーバの追加を数本のエッジのつなぎ変えにより逐次的な容量拡張が可能となっている．また，異なるポートカウントとリンク速度をもつスイッチからなる異種のネットワークに対応することができるので，高密度で高速リンクのスイッチが利用できるようになったらそれを組み込むことが可能となる．均一負荷の条件の基での同一スイッチを用いた任意のトポロジーのネットワークスループットの上限を求め，ランダムグラフがこの上限に近いスループットを達成することを示している．

Slim Fly [43]

は，スイッチの次数が与えられた場合，ネットワークの半径を小さくすることで，スイッチやケーブルなどのネットワーク資源を減少させることに着目して

(7)

図3 Expander Graphによるデータセンタネットワークのトポロジー

Fig. 3 Expander Graph topology of data center networks.

いる．

最適値に近い性能を達成できる

Xpander [42]

は，

ネットワークトポロジーとして

Expander Graph

を採用することで多数の短い経路によってトラヒックを効率的に運ぶアーキテクチャを提案している

(

図

3)

．

Expander

ネットワークはネットワークの全てのカッ

トは多数のリンクがまたがっており，ノード間のトラヒックが少数のリンクの組においてボトルネックとならないようになっている．小半径ネットワーク

(low-diameter network)

である

Slim Fly [43]

やランダムグラフである

Jerryﬁsh [41]

も

Expander

と共通の機能的特徴があることが示されている．

Kassing

ら

[44]

は交流トラヒック行列の歪がスタティックなトポロジーとダイナミックなトポロジーにどのような影響を与えるかを分析し，交流トラヒック行列に歪がある場合でも，これらのタイプのスタティックなトポロジーのほうがダイナミックなトポロジーよりも性能上有利であることを明らかにした．

Expander

型のネットワーク

[41], [42]

は最悪の交流トラヒックパターンに対しても，どのサーバがアクティブであるかなどの情報が分からなくても，十分な帯域を得ていることを示した．

2. 5

今後の方向性

オンラインインターネットサービス事業者はサービスの急激な普及に伴いデータセンタを拡張していった．

急増するトラヒック需要に迅速に対応しながら低コストで拡張性のあるデータセンタネットワークを構築するため初期の研究では

Fat Tree

型等の規則的な構造をもつトポロジーのものが検討されてきたが，データセンタネットワーク内の交流トラヒックはデータセンタの用途によって大きく異なり，

Clos

や

Fat Tree

のような均一な帯域容量をもつデータセンタネットワークのトポロジーは過剰なリンク設備のため帯域が余る

か，逆にリンク設備が不十分で帯域が不足するかのどちらかとなる

[30]

．データセンタネットワークのアーキテクチャやトポロジー設計を考える上でデータセンタネットワーク内の交流トラヒックやトラヒック特性を把握することが重要である．データセンタで動作するアプリケーションの中にはトラヒックの平均的な振る舞いの把握だけでは不十分で，マイクロバーストなどを捉えることも必要となってくることが想定される．幸いにもデータセンタネットワークのトラヒック計測はサーバでの詳細な計測が可能である．また，スイッチもデータプレーンのプログラマブル化が進展すれば

[45], [46]

，これまで以上に詳細なトラヒック計測が可能となると想定される

[47]

．このような精度の高いトラヒック計測とネットワークの構築・運用のより精度の高い連携の研究が活発化するであろう．

3. Softwarization

ソフトウェア化（

Softwarization

）は，これまで垂直統合型のシステムであったネットワーク機器をディスアグリゲーションし，これらの課題を解決するものとして期待されている．ネットワーク機器がディスアグリゲーションされ，専用品であった装置を汎用サーバや汎用スイッチ上で動作するソフトウェアとして実現されるようになる．拡張性の高い汎用のハードウェアとソフトウェアコンポーネントを組み合わせて，エンドーエンドシステムを柔軟に構成できるようになる．

ソフトウェア化はデータセンタへの適用が先行したが，

今後は通信事業者への適用も進むものと考えられる．

ソフトウェア化によりネットワークシステムをディスアグリゲートし容量弾力性のあるクラウド型サービスを用いることで様々なニーズに機敏に対応しコスト競争力のある迅速なネットワークサービスを提供することが可能となる．すなわち，従来はハードウェアアプライアンスで提供していたネットワーク機能（ファイヤウォール，ロードバランサ，

NAT

など）を，汎用サーバ上で動作するソフトウェアとして実現することで，クラウドにある汎用サーバ上で要求性能やトラヒック負荷に応じた性能をもつネットワーク機能を提供することが可能となる．

これまでクラウド事業者が汎用製品を用いてインフラを構築することで享受してきた規模の経済性，サービスの迅速な展開，弾力性のある容量でサービスを提供する機敏性がもたらされると期待される．ここでは

Softwarization

に関するこれまでの研究について，

(8)

SDN

と

NFV

の

Softwarization

，

Declarative

なポリシー記述，

SDN

を用いた

Inter-DC

，キャリアエッジクラウドに焦点を当てながら振り返る．

3. 1 Softwarization

によるディスアグリゲーション

従来のネットワーク機器は，垂直統合型のシステムであり，個々のネットワーク機器ベンダが独自に製品のシステムアーキテクチャを決めて製造してきた．

ネットワーク機器ベンダが頻繁に機能追加を続けることで，数千もの機能や数千万行ものソフトウェア規模となり，これらの機器は複雑化している

[48]

．ネットワーク機器はブラックボックスとなり，ネットワークオペレータがネットワーク機器の故障が原因となって生じるネットワークサービスの障害診断や新しいサービス機能の追加が困難となっている．また，ネットワーク機器を構成するコンポーネントの製造・供給が止まると，ネットワーク機器全体の開発・維持管理が継続できなくなる恐れも生じる．ソフトウェア化

（

Softwarization

）は，これまで垂直統合型のシステムであったネットワーク機器をディスアグリゲーションし，これらの課題を解決するものとして期待されている．

Software-deﬁned networking (SDN)

と

network function virtualization (NFV)

はディスアグリゲーションの最初のステップとして，ネットワーク機器をソフトウェアとハードウェアのコンポーネントに分離する．

SDN [49]

はスイッチやルータ等のネットワーク機

器からコントロールプレーンを分離するものであり，

論理的には集中型のコントローラがネットワークを制御し，ルーティング，負荷分散，アクセス制御，セキュリティ，ネットワーク構成などを司る．

SDN

は，

RCP [50]

，

PCE [51]

等の先行技術を経て，

4D

アーキテクチャ

[52]

の提唱と初期の具体的な

SDN

実装である

SANE [53]

や

Ethane [54]

とそれらの実装を踏まえた

Openﬂow

アーキテクチャ

[55]

の提唱を経て，

世界的に研究開発が活性化した．

NFV [56], [57]

はミドルボックスにおいて実現されている様々なネットワーク機能をソフトウェア化し，

それらのネットワーク機能を汎用サーバ上で動作させるものである．サーバー仮想化技術の発展により，仮想マシンやコンテナ技術等を用いて，ネットワーク機能を実装する．ミドルボックスにおいてデータプレーンとして実装されているネットワーク機能は複雑であり（例えば，複数のプロトコルレイヤにまたがって処

図4 SDNによるディスアグリゲーション Fig. 4 SDN-driven disaggregation.

理，パケットの変更，セッションの終端・生成等），ソフトウェアで実現されていた．これまでアプライアンス装置として垂直統合型で実装されていたネットワーク機能を汎用サーバー上で動作するソフトウェアとして分離する．これにより，

NFV

は弾力性のある容量・

性能，リソースの効率的な利用，耐故障性，故障回復性等のメリットをもたらす．

SDN

はスイッチやルータ等のネットワーク機器からコントロールプレーンを分離するものであり，

NFV

はミドルボックスにおいて実現されている様々なネットワーク機能をソフトウェア化し，それらのネットワーク機能を汎用サーバ上で動作させるものである．

SDN

と

NFV

はディスアグリゲーションの最初のステップとして，ネットワーク機器をソフトウェアとハードウェアのコンポーネントに分離するものであるが，図

4

に示すように，

SDN

によってディスアグリゲーションされたコントロールプレーンが，更に細かい粒度の機能構成要素にディスアグリゲーションされて，これらの機能構成要素を組み合わせることで新しいコントロールプレーンを構成できるようになることが期待される．垂直統合で開発されてきたルータやスイッチはさまざまなニーズに合わせて多種多様なプロトコルを実装してソフトウェア規模は数千万行もの規模となっているが

[48]

，全てのユーザが，垂直統合で開発された製品の全ての機能を必ずしも必要としていない．

SDN

によってコントロールプレーンが分離されるが，コントロールプレーンを分離した上で，更に，ユーザが必要とする機能のみを選択して実装できるようにする必要がある．これまでコントロールプレーンを構成してきたネットワークソフトウェアを再利用可能な構成要素に分解し，それらを組み合わせてユーザが希望する機能が実装することができれば，ソフトウェアの開発規模を削減し，短期間で新しい機能を追加することも可能になると考えられる．

IoT

の進展に伴い，多種多様なデバイスが接続されて，さまざまなニーズに対

(9)

図5 NFVによるディスアグリゲーション Fig. 5 NFV-driven disaggregation.

応した機能をタイムリーにネットワークソフトウェアに機能追加する必要性が高まることが予見され，ソフトウェアの開発規模の削減や短期間での機能追加の必要性は高まるものと考えられる．

NFV

に関しても，

図

5

に示すようにファイヤウォールや

NAT

等のネットワーク機能が更にヘッダ操作，ペイロード操作，セッション終端等の機能構成要素にディスアグリゲーションされて，これらの機能要素を組み合わせることで新しいネットワーク機能を構成できるようになることが期待される．ファイヤウォールや

NAT

等のさまざまなネットワーク機能を組み合わせてサービスを実現するが，これらのネットワーク機能間で重複する処理が実現されていることがあり，ヘッダ操作，ペイロード操作，セッション終端等の機能構成要素にディスアグリゲーションして，新しいネットワーク機能を構成したほうが，無駄な処理を行わなくて済むといった利点もある

[58]

〜

[60]

．機能のモジュール化を取り入れたソフトウェアルータ

Click [61]

を用いた

NFV

の研究が活発に行われている

[62]

〜

[70]

．

3. 2 Declarative

なポリシー記述

Software-Deﬁned Networking (SDN)

の初期の取り組みはスイッチ装置から

C

プレーンを分離し，スイッチのフォワーディングテーブルを直接書き換えることに主眼が置かれていた

[52], [71]

．

SDN

ネットワークにおいては，汎用のスイッチハードウェアを使ってネットワークのデータプレーンを構築し，その上で，

革新的なネットワークのアプリケーションやサービスの創造が期待されているが，ネットワークオペレーティングシステム

(Network Operating System: NOS)

が様々な種類のスイッチハードウェアを抽象化するプラットホームとして重要な役割を担う

[72]

．

NOS

はネットワーク資源を管理すると同時にハイレベルな抽象化と

API

を提供することで，スイッチの管理・監視・プログラミングを可能とし，

C

プレーンをスイッチから分離するだけでなく，様々なプロトコルや

API

を介し

て得られる非常に広範囲の多量の有益なネットワークデータを用いて拡張されている

[73]

．多くの

SDN

プログラミング言語やコントローラフレームワークが提案されている

[74]

．

Declarative

にポリシーを記述するパラダイムが近年注目を浴びている．これまでネットワーク機器の設定においては，

Imperative

な設定方法が取られており，ネットワーク機器がどのように動作すべきかとい

う

“How”

を設定することで，ポリシーの設定を実現

していた．このような方法では，ネットワーク機器への設定内容が，ポリシーの目的の直感的な理解に必ずしも近くないため，ポリシー設定の誤りの原因となることがあった．これに対して，

Declarative

なポリシーの記述はネットワーク機器が何を達成しなければいけないかという目標である

“What”

を記述することでポリシーを記述するものである．

DEFO [75]

は

Declarative

なトラヒックエンジニアリング手法であり

Interior Gateway Protocol (IGP)

により

IP

パケットの到達性を確保しつつ，セグメントルーティング

(Segment Routing: SR)

を用いて，経路の最適化を行う．ポリシーを

Declarative

に記述するために，ドメイン固有言語

(domain speciﬁc language:

DSL)

の一つである

Scala

言語を採用しており，ハイレベルなネットワークの目標をトラヒック需要に適用される制約条件と目的関数で記述し，

DSL

で記述された抽象化されたハイレベルなネットワークの目標をネットワークの構成に反映する．目的関数としては最大負荷の最小化，最大遅延の最小化，最短経路からの乖離度合い，通過ノードや非通過ノードの指定等が用意されている．

SOL [76]

は，最適化ソルバと

SDN

コントローラの低レベルな詳細は抽象化し，

SDN

アプリケーション開発者がアプリケーションの高レベルな目的や制約条件を記述させる．ネットワークトポロジー，トラヒックパターン，最適化の目的が入力として与えられ，最適化ソルバの制約条件に翻訳され転送ルールが導出され，

SDN

スイッチのフォワーディングテーブルに設定する．トラヒックエンジニアリング，サービスチェイニング，トポロジー変更，オフロード等の多くの最適化のアプリケーションにおいては，

path-based

の定式化が可能であることに着目し，オフラインであらかじめ計算されたパスの候補を組み合わせて，オンラインで制約条件を満たし目的関数を最大化する適切なパスを選択する．

path-based

の定式化により一般化と効率性

(10)

を両立し，

SOL

はトラヒックエンジニアリング，サービスチェイニング，トポロジー変更，オフロード等の様々な目的をもつアプリケーションを簡潔に表現し，

最適解に近い解を得ることが可能であるとしている．

企業ネットワークへのアクセス制御を実現する

Ethane [77]

の

SDN

コントローラである

NOX

のポリシー記述言語としてネットワークワイドなフローごとのポリシーを記述するためのハイレベルな

Declarative

言語が提案されている

[78]

．ネットワークへのアクセス制御を実現するためのポリシーをステートメントの集合として記述し，各ステートメントは簡単な

if-then

関係を表現し，フローの先頭パケットがネットワークのポリシーに照らし合わせて，ネットワークへの流入の可否判断を行う．

Declarative

な方法はデータセンタネットワークのトポロジー設計でも提案されている．

Condor [79]

は

Declarative

なオブジェクト指向型のデータセンタネットワークのトポロジー設計言語

(topology description language: TDL)

である．大規模な複数経路をもつデータセンタネットワークの設計は大規模で複雑であり，全ての目的に合致するようなデータセンタネットワークの設計は困難である．コスト競争力のある，信頼性の高い，保守性の容易なデータセンタネットワークを設計する際に，数多くの基準のトレードオフを検討しなければならず，逐次的に拡張されていくデータセンタネットワークを設計することは困難を極める作業となる．

Condor

は構造的なビルディングブロック

（スイッチ，パッチパネル，ラック，

POD

等）や，それらの関係と制約条件を伴った接続可能性を規定し，

TDL

からトポロジーモデルの候補を生成する．トポロジーを簡潔かつ簡単に変更できる記述で表現し，トポロジー設計を制約条件充足問題に変換し，迅速なトポロジー合成アルゴリズムを適用することで，データセンタネットワークの容量拡張をサービス水準を維持したまま効率的に行うことができる．

数万台のネットワーク機器によって接続された数十万台のサーバからなる

Facebook

のデータセンタネットワーク管理では，設計，コンフィグ生成，展開，監視などの各フェーズで，モデル駆動型でトップダウン型のアプローチが用いられており

[80]

，オペレータの高レベルな意図をモデル化したものから低レベルなベンダ依存のコンフィグを生成し，展開し，監視している．

3. 3 SDN

による

DC

間接続

オンラインインターネットサービス事業者はパブリックなインターネットとピアリングしユーザへ提供するサービスのトラヒックを運ぶ一方で，ハイパースケールデータセンタを世界に分散配置し，これらのデータセンタ間を接続し，複数のサーバ間でやり取りされる様々な種類の内部サービスのトラヒックを運ぶ

Inter-DC WAN (Wide Area Network: WAN)

を構築し，運用管理している．これらのハイパースケールデータセンタを構築し，運用管理しているインターネットオンラインサービス事業者らは，汎用品の価格競争力の高いスイッチハードウェアを用いてデータプレーンを構築し，

SDN

によるネットワーク制御を行っている

[81]

〜

[84]

．

世界に分散しているデータセンタ間を接続する

Inter- DC WAN

トラヒックの大半

(

例えば，

85–95%)

をテラバイトやペタバイトクラスの大量のファイル転送が占めている

[81]

〜

[84]

．例えば，サーチエンジンは世界中に分散したデータセンタにある検索インデックスを同期し，あるデータセンタで新たに生成された検索インデックスを他の全てのデータセンタにコピーする．

また，金融機関は毎日の取引データのバックアップを複数の世界の拠点で同期を取るために多量のファイル転送を行う．あるいは，メディア企業は高精細映像コンテンツを複数の配信エリアにコピーする．

Inter-DC WAN

が運ぶトラヒック量はインターネットよりも高い成長率で増え続けている

[81]

．サービス事業者は事業面で激しい競争にさらされており，持続可能な設備投資

(CAPEX: Capital Expenditure) Inter-DC WAN

を構築しなければならず，

Inter-DC WAN

の構築においては

SDN

が期待されるようになった．これらのハイパースケールデータセンタを構築し，運用管理しているインターネットオンラインサービス事業者らは，

汎用品の価格競争力の高いスイッチハードウェアを用いてデータプレーンを構築し，

SDN

によるネットワーク制御を行っている

[81]

〜

[84]

．

Google

の

B4 [81]

と呼ばれる

Software-Deﬁned

WAN

は既存の分散型

IP

ルーティング

(BGP/ISIS)

と集中型の

Openﬂow

型のトラヒックエンジニアリングを組み合わせて，アプリケーションの優先度に合わせて帯域を割当て，動的にトラヒック需要パターンをシフトさせ，従来の手法では

30–40%

程度に抑えられているリンク使用率を

100%

に近くまで向上させている．

Microsoft

の

SWAN: Software-deﬁned

(11)

WAN [82]

と呼ばれる

Software-Deﬁned WAN

も

B4

と同様に

Inter-WAN DC

の使用率を向上させることを目標としている．このため，各アプリケーションの需要に合わせて，いつどれだけの帯域を運ぶかを

SDN

により制御し，過渡状態でも輻輳が発生しないようにパスの再構成を行う．小さなスクラッチ容量を各リンクに留保しておき，最小のステップ数で過渡的な輻輳を起こさずにパスを再構成するアルゴリズムを

SDN

により実現している．

数千もの個別のアプリケーションが

Inter-DC WAN

上で走っており，これらは大別すると次の三つに分類される．

•

ユーザデータ

(

例，電子メール，ドキュメント，

音声

/

画像ファイル等

)

の冗長化のため遠隔のデータセンタへのコピー

•

分散して配置されたデータが必要となる計算のために遠隔のデータセンタにあるストレージへのアクセス

•

複数のデータセンタ間の同期のための多量のデータの遠隔のデータセンタへのコピー

これらのアプリケーションのタイプは，この順番にデータ量は大きくなり，遅延への要求は緩くなる．これらは

(1)

インタラクティブ，

(2)

エラスティック，

(3)

バックグランドの三つのサービスクラスに分類される．インタラクティブサービスはユーザエクスペリエンスのクリティカルパス上にあり遅延や損失に非常に敏感である．エラスティックサービスはユーザエクスペリエンスのクリティカルパス上になく遅延や損失にはそれほど敏感ではないが，期限付きであったりしてタイムリーな配信を必要とする．バックグランドサービスはメンテナンスやプロビジョニングのためのトラヒックで帯域を消耗するが，遅延に関する要件はさほどないものである．

多量のファイル転送は転送期限があることが

Inter- DC

トラヒックの特徴の一つである．多くのアプリケーションにとって転送期限を保証することは重要でありファイル転送の遅延はサービス品質や収益に直結することがある．例えば，検索インデックスの転送が遅れることは，検索結果の品質を低下させることになる．

転送期限のクラスとしてはハードな期限とソフトな期限があり，ハードな転送期限を要求するファイル転送ではその期限が守られなければ意味がなくなってしまう．一方，ソフトな転送期限を要求するファイル転送では期限が守られない場合にはその転送の価値が下が

るものの転送を完了する必要がある．

SWAN [82]

と

B4 [81]

はトラヒッククラスに対して完全優先制御を行うものの転送期限の保証を行わない．これに対して

Tempus [83]

は転送期限を意識した帯域管理を行い，各ファイル転送要求に対して，期限内に全てが転送できない場合でも最大量の転送が完了するように制御する．オンラインでファイル転送のスケジューリングを行い，長い時間続いているファイル転送をパスに詰め込みつつも，将来の変化に備えて容量に余裕をもたせて制御する．混合パッキング被覆線形問題を解くことで，効用関数を最大にしながら，期限内に完了する最小の転送数が最大となるようにスケジューリングする．

Amoeba [84]

も転送期限を意識したファイル転送のための帯域管理を行う．データ量と転送期限を各テナントに申告させて，各テナントに真の要求を申告させるようなプライシングメカニズムを働かせながら，時空間の帯域割当アルゴリズムを用いる．新しい要求を埋め込むときには適応型スケジューリング

(Adaptive Scheduling: AS)

を起動し，新しい要求に対してより良い転送完了時間を提供するために既存の要求のリスケジュールが発生した場合には，

機会型スケジューリング

(Opportunisitc Scheduling:

OS)

を起動し，局所拡張

(Local Stretching: LS)

と結合リスケジューリング

(Joint Rescheduling: JR)

を行う．

Owan [85]

は光回線を組み合わせた方法で，

recon- ﬁgurable add-drop multipexer (ROADM)

とルータでネットワークを構成し，

ROAM

の設定を変更し，動的に

IP

レイヤのトポロジーを変更し，バルクデータ転送のトラヒックスケジューリングを行う．トラヒック需要の変化に適応して，光回線の設定，ルーティング，レート割当を行い，転送完了時間を最適化し，転送期限内に転送を完了する．焼きなまし法

(Simulated Annealing: SA)

を用いて，現在のトポロジーを起点として最大のスループットが得られるトポロジーを求める方法である．

3. 4

キャリアネットワークにおける分散クラウド

SDN

は当初は

Inter-DC WAN

やデータセンタネットワークといったクラウド事業者への適用が進んだが，

今後は通信事業者への適用も進むものと考えられる．

通信事業者は加速し続けるトラヒック需要や顧客へ新しい魅力あるサービスをタイムリーに提供するといった課題に直面しており，例えば，

at&t

は最近の

8

年間で

1000

倍のデータトラヒック量の増加があり，全

(12)

米

100

都市に光ファイバアクセスを展開している

[86]

．しかしながら，

at&t

では

4700

の電話交換局があり，

そのうち幾つかは最大

300

種類ものハードウェアが配備されているように

[87]

，通信事業者のネットワークのエッジは様々な専用装置はほとんど一貫性や統一的なアーキテクチャがなく，過去何十年にわたって配備されてきた．クラウド事業者は数種類の汎用製品を用いてインフラを構築することで規模の経済性や迅速に展開し弾力性のある容量でサービスを提供する機敏性を享受しており，通信事業者のネットワークのエッジにこそ，クラウド事業者が享受している規模の経済性や機敏性が必要とされている．

通信事業者は交換局のインフラを有しており，交換局のビル設備を用いて，ローカルなデータセンタを構築し，これらのデータセンタ間を自身が所有するネットワークで接続することで，エンドーエンドのクラウドを構築し，ネットワークとクラウドを統合管理し，今日のクラウド事業者が提供しているのと同様に容量弾力性のある迅速なサービス指向型のオペレーションモデルを採用することができる

[88]

．通信事業者は既に所有する分散した

PoP

を活用して，小規模のクラウド環境を構築し，更には，顧客の拠点まで拡張することができる

(

図

6)

．

CLOUD4NFV

は

Proof-of-concept

プラットホームであり，サービス機能を

as-a-service

の形態で提供し，

Service Function Chaining (SFC)

によりサービスを生成することを実証した

[88]

．また，

動的な

SDN

制御により，柔軟なクラウド管理手法と連携させて，通信事業者にネットワークの状態やユーザの変化する要件に自律的に適応する

NFV

ソリューションを提供することを示した

Proof-of-concept

デモも報告されている

[89]

．

CORD (Central Oﬃce Re-architected as Dat- acenter) [87]

は，通信事業者の電話局において，

Software-Deﬁned Networking (SDN)

や

Network Function Virtualization (NFV)

に加えて，容量弾力性のあるクラウド型サービスを用いることで，コスト

図6 ハイパーデータセンタとエッジクラウド Fig. 6 Hyper data center and edge cloud.

競争力のある迅速なアクセスネットワークを構築するための

Network Opearatoin System (NOS)

を含めたプラットホームである．

SDN

により

C

プレーンと

D

プレーンを分離し，マーチャントシリコンを使って製造された安価なホワイトボックスのスイッチを使う．

NFV

によりハードウェアのアプライアンス装置からデータプレーンを分離し，汎用サーバ上で動作する仮想マシン

(VM)

に移植することで高価なハードウェアのアプライアンス装置から安価な汎用サーバへ移行し，

機敏で容量弾力性のあるオーケストレーションを実現する．

CORD

は装置をディスアグリゲーションすることで，専用品であった装置を汎用サーバや汎用スイッチ上で動作するソフトウェアとして実現する．汎用のハードウェアとソフトウェアコンポーネントを組み合わせて，拡張性の高い，機敏なエンドーエンドシステムを構成できるような統一的な抽象化を定義している．

CORD

はディスアグリゲートされたソフトウェアコンポーネントを組み合わせてサービスグラフを構成しエンドーエンドサービスを提供する．

3. 5

今後の方向性

ハイパースケールクラウド事業者のデータセンタ内のトラヒックの増加率がインターネットのそれを凌ぐようになり，これからはデータセンタネットワークがコンピュータネットワークのアーキテクチャの方向性を決めるようになると想定される．通信事業者においても従来の電話局の設備を利活用したデータセンタが普及すると想定される．これらのデータセンタ間を自身が所有するネットワークで接続することで，エンドーエンドのクラウドを構築し，ネットワークとクラウドを統合管理し，今日のクラウド事業者が提供しているのと同様に容量弾力性のある迅速なサービス指向型のオペレーションモデルを採用していくであろう．

仮想化・ソフトウェア化はデータセンタへの適用が先行したが，今後は通信事業者への適用も進むものと考えられる．仮想化により装置がディスアグリゲーションされ，専用品であった装置を汎用サーバや汎用スイッチ上で動作するソフトウェアとして実現されるようになり，拡張性の高い汎用のハードウェアとソフトウェアコンポーネントを組み合わせて，機敏なエンドーエンドシステムを構成するようになると期待される．

4.

データ駆動型マネジメント

システムが複雑になるとシステムの性能指標が様々なパラメータによって影響を受け，ランダムに変化す

(13)

るこれらのパラメータが相互に影響を及ぼし合い，何らかの公式によりシステムの性能を評価することが困難になることが多い．これらのパラメータと性能指標の相関や依存関係の有無がデータとして測定できるような場合に，測定した様々なデータからシステムの性能指標を評価しマネジメントに活かすことが期待される

[90]

．本論文ではこのような方法をデータ駆動型マネジメントと呼ぶ．

SDN

や

NFV

によるディスアグリゲーションにより，

システムの構成要素数が増すことで，運用管理に複雑さが増す要因ともなる．個々の構成要素のメカニズムを完全に把握して，ネットワークシステムをマネジメントすることは困難であり，システム全体をブラックボックスとして捉えて，その入出力のデータを測定し，

測定された多量のデータに基づきネットワークシステムをモデル化し，マネジメントを行うアプローチが有望であると考えられる．すなわち，ディスアグリゲーションによりシステム構成要素数が増えたときの全体マネジメント方法として，以下の方法がある．

方法

A

個々の要素のメカニズム（仕様）を完全に把握して全体管理する方法（従来の延長）

方法

B

仕様把握を諦め，入出力測定により全体をモデル化し，全体管理する（データ駆動型マネジメント）

これらの方法は排他的なものではなく，互いに補完し合うものである．マネジメントの全てが方法

B

のデータ駆動型に置き換わるものではなく，方法

A

の仕様を完全に把握する従来の延長ではカバーしきれない場合に対応するために方法

B

のデータ駆動型マネジメントが必要となる．

システムが個々の構成要素にディスアグリゲーションされる状況においても，長い時間をかけて，方法

A

の個々の構成要素の仕様やメカニズムを完全に把握して全体管理する従来の延長のマネジメントも可能である．しかしながら，ディスアグリゲーションすることは，構成要素間のインタフェースを標準化し，構成要素の単位での更改を可能とすることを意味している．

そして，構成要素単位の更改は従来のシステム全体の更改よりも頻繁に行われることが期待される．ディスアグリゲーションされた構成要素ごとに入れ替わりが頻繁に起きる場合には，仕様を完全に把握する前に，

新しいものに入れ替わることもある．この場合にはデータ駆動型のマネジメントを用いることで状況を改善することが期待できる．

また，一般的に，システムの振る舞いを仕様書で完

図7 データ駆動型ネットワークマネジメント Fig. 7 Data-driven network management.

全に規定することは困難であると考えられており，仕様の解釈間違いによりシステムのバグが生じうる．インターネットの標準仕様を策定している

IETF

ではラフコンセンサスとランニングコードの精神の元で標準化が行われており，これはインターネットというグローバルなコンピュータネットワークが稼働している大きな要因の一つと考えられている．仕様書で規定しきれていない部分を実装で補完する方法で，これも従来のマネジメントの延長であると考えられる．その結果，実装が固定化・寡占化されていき，新しい構成要素に更改したり，新しい機能を追加することが困難となってきたことが問題視されたこともある

[91]

．ディスアグリゲーションにより，新しい構成要素に更改したり，新しい機能を追加することが容易になるが，システムの仕様の不安定性は増すことになり，システムの仕様を把握する従来のマネジメントの延長だけでは対応できない部分をデータ駆動型のマネジメントが補完するのが有効であると考えられる．

データ駆動型マネジメントにおいては，機械学習や深層学習を用いたデータマイニングが重要な役割を果たし

[92]

，測定データからネットワークシステムのモデル化を行う

(

図

7)

．ここでは，データ駆動型マネジメントに関するこれまでの研究について述べる．まず，

機械学習と深層学習の急激な発展の背景について振り返り，それらがネットワークマネジメントにどのように応用されているかについて，状態の可視化と異常の検出，故障原因の特定，ネットワーク運用ポリシー，

資源割り当てを取り上げて振り返る．

4. 1

機械学習と深層学習

機械学習や深層学習はデータにアルゴリズムを適

データ駆動型のネットワーク管理

招待論文

Softwarized されたネットワークシステムのディスアグリゲーションと