SlideShare a Scribd company logo
1 of 14
Osaka University
コアペリフェリー構造を有する
NFV ソフトウェアシステムの有効性評価
大阪大学 大学院情報科学研究科
村田研究室 津久井佑樹
2019 / 10 / 25
Osaka University
• ネットワークへのユーザ要求の多様化[1]
• スマートフォンなどのデバイスの世界的普及
• ビッグデータなどネットワークの新たな利用形態の登場
→ ネットワークにはこれらへの対応が求められる
• NFV (Network Function Virtualization) への期待
• ソフトウェア化されたサービスコンポーネントを仮想環境上で実行
• 複数のサービスコンポーネントが単一の汎用サーバ上で動作し、省電力・省スペース
• ユーザが要求するネットワーク化サービスをより柔軟に収容
• サービスコンポーネントをネットワークを介して連結することで収容可能
• 加えて、実装コスト抑制のため NFV ソフトウェアの適切な設計も重要
• 実装コストが少なければ、多様なユーザ要求への対応がより容易に
2
研究背景
[1] Cisco, VNI, “Cisco visual networking index: Forecast and
trends, 2017–2022,” White Paper, Nov. 2018.
Osaka University
• 生物システムなどで確認されるコアペリフェリー構造[12]
• システム要素を”コア”と”ペリフェリー”に分類
• NFV ソフトウェアはコアペリフェリー構造と解釈可能
• サービスコンポーネントを”コア機能”と”ペリフェリー機能”に分類
• コア機能: 複数のネットワーク化サービス収容に用いられるサービスコンポーネント
• ペリフェリ-機能: 1 種類のネットワーク化サービス収容にのみ用いられる
サービスコンポーネント
3
コアペリフェリー構造による NFV ソフトウェアの解釈
ペリフェリー機能 コア機能
サービス 1
サービス 2
サービス 𝑛
NFV ソフトウェアシステムコアペリフェリー構造
コア
変化が少ない
コスト制約
ペリフェリー
積極的に変化
環境変化を吸収
ペリフェリー
積極的に変化
環境変化を吸収
対応
[12] P. Csermely, A. London, L.-Y. Wu, and B. Uzzi, “Structure and
dynamics of core/periphery networks,” Journal of Complex Networks,
vol. 1, pp. 93–123, Oct. 2013.
Osaka University
• コア機能数の大小に応じて実装するペリフェリー機能数が変化
→ NFV ソフトウェアの実装コストを抑制するコア機能数の決定が必要
• 研究目的
• アプローチ
• コアペリフェリー構造に基づいて実装コストをモデル化
• 異なる数のコア機能を有した設計指針の実装コストを比較・議論
4
研究目的
全体の実装コストを抑制する NFV ソフトウェアの設計指針の獲得
サービス 1
サービス 2
サービス 𝑛
サービス 1
サービス 2
サービス 𝑛
コア機能数 ↑
ペリフェリー機能数 ↓
コア機能数 ↓
ペリフェリー機能数 ↑異なる実装コスト
Osaka University
• 時間の経過に伴い新たなユーザ要求が生じ
収容するネットワーク化サービスの種類数 𝑛 が増加
• 𝑛 の増加に伴ってコア機能やペリフェリー機能を追加
• ネットワーク化サービスあたりの収容に用いる
平均サービスコンポーネント数 𝑘
• 𝑛 が増加しても 𝑘 は変化しないと仮定
5
ネットワーク化サービス収容のモデル化
時間経過
新たなユーザ要求の発生
サービス 2
サービス 1
サービス 3
サービス 2
サービス 1
サービス 3
サービス 4
サービス 5
𝑛 = 3 𝑛 = 5
𝑘 個のサービスコンポーネント 𝑘 個のサービスコンポーネント
Osaka University
• 全体の実装コスト
𝑐 𝑎𝑙𝑙 𝑛 = 𝑖=0
𝑓𝑐(𝑛)
𝑐 𝑐(𝑖) + 𝑗=0
𝑛
𝑘 𝑝 𝑗 𝑐 𝑝(𝑗)
• 𝑖 種類目のコア機能の実装コスト
𝑐 𝑐 𝑖 = 𝛼𝑖
• 𝑗 種類目のネットワーク化サービスの
ペリフェリー機能あたりの実装コスト
𝑐 𝑝(𝑗) = 𝑒−𝛽𝑓𝑐(𝑗)
• 𝑗 種類目のネットワーク化サービス
あたりのペリフェリー機能数
𝑘 𝑝(𝑗) = 𝑘 − 𝑘𝛾𝑓𝑐(𝑗)
• サービスコンポーネントの総数
𝑓𝑎𝑙𝑙(𝑛) = 𝑓𝑐(𝑛) + 𝑓𝑝(𝑛)
• ペリフェリー機能数
𝑓𝑝(𝑛) = 𝑗=0
𝑛
𝑘 𝑝 𝑗
6
NFV ソフトウェアの実装コストの定義式
𝑛 ネットワーク化サービスの種類数
𝑘 ネットワーク化サービスあたりの
平均サービスコンポーネント数
𝑓𝑎𝑙𝑙(𝑛) サービスコンポーネントの総数
𝑓𝑐(𝑛) コア機能数
𝑓𝑝(𝑛) ペリフェリー機能数
𝑘 𝑝(𝑗) 𝑗 種類目のネットワーク化サービス
あたりのペリフェリー機能数
𝑐 𝑎𝑙𝑙(𝑛) 全体の実装コスト
𝑐 𝑐(𝑖) 𝑗 種類目のコア機能の実装コスト
𝑐 𝑝(𝑗) 𝑗 種類目のネットワーク化サービスの
ペリフェリー機能あたりの実装コスト
𝛼 実装済みのコア機能数に比例した
𝑐 𝑐(𝑖) の増加度を決定するパラメータ
𝛽 コア機能数の増加に伴った
𝑐 𝑝(𝑗) の減少度を決定するパラメータ
𝛾 𝑓𝑐(𝑛) 個のコア機能が 𝑗 種類目のネットワーク化
サービスの収容に用いられる頻度を表すパラメータ
変数・パラメータ
Osaka University
• 各サービスコンポーネントの実装コストの和として定義
• 𝑐 𝑎𝑙𝑙 𝑛 = 𝑖=0
𝑓𝑐(𝑛)
𝑐 𝑐(𝑖) + 𝑗=0
𝑛
𝑘 𝑝 𝑗 𝑐 𝑝(𝑗)
• 𝑓𝑐 𝑛 個のコア機能それぞれに実装コスト 𝑐 𝑐 𝑖 が必要
• 𝑛 種類のネットワーク化サービスそれぞれの収容に
𝑘 𝑝(𝑗) 個のペリフェリー機能を利用
• それぞれのペリフェリー機能に実装コスト 𝑐 𝑝 𝑗 が必要
7
NFV ソフトウェア全体の実装コストのモデル化
サービス 1
サービス 2
サービス 𝑛
NFV ソフトウェア
全体の実装コスト 𝑐 𝑎𝑙𝑙 𝑛 コア機能の
実装コストの和
𝑖=0
𝑓𝑐 𝑛
𝑐 𝑐 𝑖
ペリフェリー機能の
実装コストの和
𝑗=0
𝑛
𝑘 𝑝(𝑗)𝑐 𝑝 𝑗
+=
Osaka University
• 実装済みのコア機能数に比例して追加のコア機能の実装コストが増加
• コア機能は複数のサービスコンポーネントとの連結を可能にするために
汎用化が必要
• より多くの連結を可能にするための汎用化に、より多くの実装コストを要求
• 𝑐 𝑐 𝑖 = 𝛼𝑖
• α: 実装済みのコア機能数に比例した 𝑐 𝑐 𝑖 の増加度を決定するパラメータ
8
コア機能の実装コストのモデル化
サービス 1
サービス 2
サービス 𝑝
𝑖 番目に追加するコア機能
実装コストは 𝑐 𝑐 𝑖
連結が想定される
実装済みの 𝑖 − 1 個のコア機能
新たなサービス 𝑞
連結が想定される、後に追加
されるサービスコンポーネント
複数との連結のため汎用化
多くの実装コストを要求
Osaka University
• コア機能数が増加するとペリフェリー機能の実装コストが減少
• 役割の一部を実装済みのコア機能で代用することで開発が容易に
• コア機能数が増加するほど代用できる機会が増加
• ただしコア機能数増化に伴う
ペリフェリー機能の実装コスト減少は一定の値に収束
• 実際に代用される機能は一定のものに限定されるため
• 𝑐 𝑝(𝑗) = 𝑒−𝛽𝑓𝑐(𝑗)
• 𝛽: コア機能数の増加に伴う 𝑐 𝑝(𝑗) の減少度を決定するパラメータ
9
ペリフェリー機能の実装コストのモデル化
パターンマッチング役割の一部を
実装済みの
コア機能で代用
セッション管理ロードバランサ
ファイアウォール
ペリフェリー機能の
開発が易化
実装コスト 𝑐 𝑝(𝑗) 低下
Osaka University
• コア機能数が増加するとネットワーク化サービス収容に用いる
ペリフェリー機能数が減少
• コア機能数が増加すると
ネットワーク化サービスの収容にコア機能を利用する機会が増加
• 𝑘 𝑝 𝑗 = 𝑘 − 𝑘𝛾𝑓𝑐 𝑗
• ネットワーク化サービスあたりの収容に用いるコア機能を 𝑘𝛾𝑓𝑐 𝑗
• 𝛾: 𝑓𝑐 𝑛 個のコア機能が、あるネットワーク化サービスの収容に用いられる
頻度を表すパラメータ
10
サービス収容に用いるペリフェリー機能数のモデル化
サービス
サービス
実装済み
コア機能少
実装済み
コア機能多
コア機能の利用少
(𝑘𝛾 × 1 = 1)
用いる
ペリフェリー機能少
(𝑘 𝑝 = 2)
用いる
ペリフェリー機能多
(𝑘 𝑝 = 3)
𝑘 = 4
コア機能の利用多
(𝑘𝛾 × 3 = 2)
Osaka University
• 0 ≤ 𝑛 ≤ 1000 の範囲で 𝑛 が増加をするシナリオを想定
• コア機能数の異なる設計指針の実装コストを比較
• 各設計指針で収容するネットワーク化サービスの種類は同一と想定
• 変数およびパラメータも共通
• 時間経過に伴い、新たに多様なユーザ要求が生じても
実装コストを抑えてネットワーク化サービスを収容可能かを重視
• 𝑛 = 1000 時点の NFV ソフトウェア全体の実装コスト 𝑐 𝑎𝑙𝑙(1000) を比較
11
数値結果の導出シナリオ
パラメータ 値
𝑘 10
α 0.05
𝛽 0.001
𝛾 0.001
変数・パラメータ設定
Osaka University 12
• 図のようにコア機能数を設定した四つの設計指針
• no core
• コア機能を用いず
ペリフェリー機能のみを用いてネットワーク化サービスを収容
• forecast
• 将来のサービス収容を予測し、それに基づきコア機能を事前に実装
• 予測は正確で、事前に実装したコア機能が十分に再利用され
実装コストを最小化可能であると仮定
• unadaptive
• forecast と同様に予測に基づきコア機能を実装
• 予測は不正確と仮定し
𝑛 の増加に伴い生じる想定外のサービスの
収容のためコア機能を追加
• adaptive
• 新たなネットワーク化サービスの収容に伴って
コア機能の設計を見直し追加することを想定
比較に用いる設計指針
各設計指針のコア機能数の設定
Osaka University
• 𝑐 𝑎𝑙𝑙(1000) は adaptive < no core < unadaptive
• forecast は予測が正確であるという仮定があるため、他の設計指針がより現実的
• コア機能とペリフェリー機能両方を有することで実装コストを抑制
• adaptive の 𝑐 𝑎𝑙𝑙 1000 は
no core と比べ約 15% 削減
• コア機能数が多いと
実装コストが増加
13
数値結果: コア機能数の異なる設計指針の実装コストの比較
各設計指針の実装コスト
adaptive のようにコア機能を少量とし、新たなユーザ要求発生に伴い追加する
設計指針がより現実的に全体の実装コストを抑制することを確認
adaptive が
no core と
unadaptive
を下回る
Osaka University
• まとめ
• NFV ソフトウェアの実装コストに着目
• コアペリフェリー構造による NFV ソフトウェアの解釈
• 複数のネットワーク化サービスの収容に用いられるコア機能
• 一種類のネットワーク化サービスの収容に用いられるペリフェリ-機能
• コア機能数の大小によりペリフェリー機能数が変化
• コア機能を少量とし、新たなユーザ要求発生に伴い追加する設計指針が
より現実的に全体の実装コストを抑制することを確認
• 今後の課題
• コア機能およびペリフェリー機能の物理インフラへの配置方法の考察
• 物理インフラのリソース制約のため、サービスコンポーネント数を考慮
• 複数個所に複製したサービスコンポーネントを配置するシナリオが想定されるため
コア機能およびペリフェリー機能の複製の容易さを考慮
14
まとめと今後の課題

More Related Content

Similar to Y tsukui dpf

Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月
Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月
Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月VirtualTech Japan Inc.
 
事例でわかるBIGLOBEクラウドホスティング
事例でわかるBIGLOBEクラウドホスティング事例でわかるBIGLOBEクラウドホスティング
事例でわかるBIGLOBEクラウドホスティングビジネスBIGLOBE
 
高速ネットワーク技術と周辺動向(特別講義)
高速ネットワーク技術と周辺動向(特別講義)高速ネットワーク技術と周辺動向(特別講義)
高速ネットワーク技術と周辺動向(特別講義)Naoto MATSUMOTO
 
Contrail overview open stack days tokyo-feb2015
Contrail overview open stack days tokyo-feb2015Contrail overview open stack days tokyo-feb2015
Contrail overview open stack days tokyo-feb2015Nachi Ueno
 
OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月
OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月
OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月VirtualTech Japan Inc.
 
第2章アーキテクチャ
第2章アーキテクチャ第2章アーキテクチャ
第2章アーキテクチャKenta Hattori
 
【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏
【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏
【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏Developers Summit
 
【Interop tokyo 2014】 Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?
【Interop tokyo 2014】  Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?【Interop tokyo 2014】  Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?
【Interop tokyo 2014】 Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?シスコシステムズ合同会社
 
さくらのクラウド サービス開発とデータセンター運用
さくらのクラウド サービス開発とデータセンター運用さくらのクラウド サービス開発とデータセンター運用
さくらのクラウド サービス開発とデータセンター運用SAKURA Internet Inc.
 
自律連合型基盤システムの構築
自律連合型基盤システムの構築自律連合型基盤システムの構築
自律連合型基盤システムの構築Kazuhiko Kato
 
【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...
【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...
【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...Juniper Networks (日本)
 
[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践
[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践
[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践Amazon Web Services Japan
 
【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略
【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略
【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略シスコシステムズ合同会社
 
Jtf2014 sdi and_contrail_22th-apr-2014_s
Jtf2014 sdi and_contrail_22th-apr-2014_sJtf2014 sdi and_contrail_22th-apr-2014_s
Jtf2014 sdi and_contrail_22th-apr-2014_sJunya Arimura
 
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密VIOPS Virtualized Infrastructure Operators group ARCHIVES
 

Similar to Y tsukui dpf (20)

Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月
Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月
Yahoo!Japan北米DCでOCPのツボをみせてもらってきました - OpenStack最新情報セミナー 2016年5月
 
事例でわかるBIGLOBEクラウドホスティング
事例でわかるBIGLOBEクラウドホスティング事例でわかるBIGLOBEクラウドホスティング
事例でわかるBIGLOBEクラウドホスティング
 
高速ネットワーク技術と周辺動向(特別講義)
高速ネットワーク技術と周辺動向(特別講義)高速ネットワーク技術と周辺動向(特別講義)
高速ネットワーク技術と周辺動向(特別講義)
 
Contrail overview open stack days tokyo-feb2015
Contrail overview open stack days tokyo-feb2015Contrail overview open stack days tokyo-feb2015
Contrail overview open stack days tokyo-feb2015
 
OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月
OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月
OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月
 
第2章アーキテクチャ
第2章アーキテクチャ第2章アーキテクチャ
第2章アーキテクチャ
 
Virtual Chassis Fabric for Cloud Builder
Virtual Chassis Fabric for Cloud BuilderVirtual Chassis Fabric for Cloud Builder
Virtual Chassis Fabric for Cloud Builder
 
【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏
【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏
【A-2】何の変哲もないIaaS型クラウドサービス「さくらのクラウド」とは? 鷲北賢 氏
 
【Interop tokyo 2014】 Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?
【Interop tokyo 2014】  Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?【Interop tokyo 2014】  Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?
【Interop tokyo 2014】 Cisco ACIとOpenStackで実現するネットワークプロビジョニングとは?
 
さくらのクラウド サービス開発とデータセンター運用
さくらのクラウド サービス開発とデータセンター運用さくらのクラウド サービス開発とデータセンター運用
さくらのクラウド サービス開発とデータセンター運用
 
自律連合型基盤システムの構築
自律連合型基盤システムの構築自律連合型基盤システムの構築
自律連合型基盤システムの構築
 
VIOPS04: NTTコミュニケーションズのクラウド戦略
VIOPS04: NTTコミュニケーションズのクラウド戦略VIOPS04: NTTコミュニケーションズのクラウド戦略
VIOPS04: NTTコミュニケーションズのクラウド戦略
 
【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...
【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...
【Interop Tokyo 2015】 真のビジネスアジリティを実現するSDNソリューションとは? Contrail SDN controller 最新...
 
【さくらのクラウド】サービス概要カタログ 2018年1月号
【さくらのクラウド】サービス概要カタログ 2018年1月号 【さくらのクラウド】サービス概要カタログ 2018年1月号
【さくらのクラウド】サービス概要カタログ 2018年1月号
 
[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践
[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践
[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践
 
2014-ShowNetステージ-Network
2014-ShowNetステージ-Network2014-ShowNetステージ-Network
2014-ShowNetステージ-Network
 
【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略
【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略
【Cisco Data Center Forum 2015】 データ センター ネットワークの動向と Cisco ACI の戦略
 
TS_InteropConf2022_MCN.pptx
TS_InteropConf2022_MCN.pptxTS_InteropConf2022_MCN.pptx
TS_InteropConf2022_MCN.pptx
 
Jtf2014 sdi and_contrail_22th-apr-2014_s
Jtf2014 sdi and_contrail_22th-apr-2014_sJtf2014 sdi and_contrail_22th-apr-2014_s
Jtf2014 sdi and_contrail_22th-apr-2014_s
 
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
 

Y tsukui dpf

  • 2. Osaka University • ネットワークへのユーザ要求の多様化[1] • スマートフォンなどのデバイスの世界的普及 • ビッグデータなどネットワークの新たな利用形態の登場 → ネットワークにはこれらへの対応が求められる • NFV (Network Function Virtualization) への期待 • ソフトウェア化されたサービスコンポーネントを仮想環境上で実行 • 複数のサービスコンポーネントが単一の汎用サーバ上で動作し、省電力・省スペース • ユーザが要求するネットワーク化サービスをより柔軟に収容 • サービスコンポーネントをネットワークを介して連結することで収容可能 • 加えて、実装コスト抑制のため NFV ソフトウェアの適切な設計も重要 • 実装コストが少なければ、多様なユーザ要求への対応がより容易に 2 研究背景 [1] Cisco, VNI, “Cisco visual networking index: Forecast and trends, 2017–2022,” White Paper, Nov. 2018.
  • 3. Osaka University • 生物システムなどで確認されるコアペリフェリー構造[12] • システム要素を”コア”と”ペリフェリー”に分類 • NFV ソフトウェアはコアペリフェリー構造と解釈可能 • サービスコンポーネントを”コア機能”と”ペリフェリー機能”に分類 • コア機能: 複数のネットワーク化サービス収容に用いられるサービスコンポーネント • ペリフェリ-機能: 1 種類のネットワーク化サービス収容にのみ用いられる サービスコンポーネント 3 コアペリフェリー構造による NFV ソフトウェアの解釈 ペリフェリー機能 コア機能 サービス 1 サービス 2 サービス 𝑛 NFV ソフトウェアシステムコアペリフェリー構造 コア 変化が少ない コスト制約 ペリフェリー 積極的に変化 環境変化を吸収 ペリフェリー 積極的に変化 環境変化を吸収 対応 [12] P. Csermely, A. London, L.-Y. Wu, and B. Uzzi, “Structure and dynamics of core/periphery networks,” Journal of Complex Networks, vol. 1, pp. 93–123, Oct. 2013.
  • 4. Osaka University • コア機能数の大小に応じて実装するペリフェリー機能数が変化 → NFV ソフトウェアの実装コストを抑制するコア機能数の決定が必要 • 研究目的 • アプローチ • コアペリフェリー構造に基づいて実装コストをモデル化 • 異なる数のコア機能を有した設計指針の実装コストを比較・議論 4 研究目的 全体の実装コストを抑制する NFV ソフトウェアの設計指針の獲得 サービス 1 サービス 2 サービス 𝑛 サービス 1 サービス 2 サービス 𝑛 コア機能数 ↑ ペリフェリー機能数 ↓ コア機能数 ↓ ペリフェリー機能数 ↑異なる実装コスト
  • 5. Osaka University • 時間の経過に伴い新たなユーザ要求が生じ 収容するネットワーク化サービスの種類数 𝑛 が増加 • 𝑛 の増加に伴ってコア機能やペリフェリー機能を追加 • ネットワーク化サービスあたりの収容に用いる 平均サービスコンポーネント数 𝑘 • 𝑛 が増加しても 𝑘 は変化しないと仮定 5 ネットワーク化サービス収容のモデル化 時間経過 新たなユーザ要求の発生 サービス 2 サービス 1 サービス 3 サービス 2 サービス 1 サービス 3 サービス 4 サービス 5 𝑛 = 3 𝑛 = 5 𝑘 個のサービスコンポーネント 𝑘 個のサービスコンポーネント
  • 6. Osaka University • 全体の実装コスト 𝑐 𝑎𝑙𝑙 𝑛 = 𝑖=0 𝑓𝑐(𝑛) 𝑐 𝑐(𝑖) + 𝑗=0 𝑛 𝑘 𝑝 𝑗 𝑐 𝑝(𝑗) • 𝑖 種類目のコア機能の実装コスト 𝑐 𝑐 𝑖 = 𝛼𝑖 • 𝑗 種類目のネットワーク化サービスの ペリフェリー機能あたりの実装コスト 𝑐 𝑝(𝑗) = 𝑒−𝛽𝑓𝑐(𝑗) • 𝑗 種類目のネットワーク化サービス あたりのペリフェリー機能数 𝑘 𝑝(𝑗) = 𝑘 − 𝑘𝛾𝑓𝑐(𝑗) • サービスコンポーネントの総数 𝑓𝑎𝑙𝑙(𝑛) = 𝑓𝑐(𝑛) + 𝑓𝑝(𝑛) • ペリフェリー機能数 𝑓𝑝(𝑛) = 𝑗=0 𝑛 𝑘 𝑝 𝑗 6 NFV ソフトウェアの実装コストの定義式 𝑛 ネットワーク化サービスの種類数 𝑘 ネットワーク化サービスあたりの 平均サービスコンポーネント数 𝑓𝑎𝑙𝑙(𝑛) サービスコンポーネントの総数 𝑓𝑐(𝑛) コア機能数 𝑓𝑝(𝑛) ペリフェリー機能数 𝑘 𝑝(𝑗) 𝑗 種類目のネットワーク化サービス あたりのペリフェリー機能数 𝑐 𝑎𝑙𝑙(𝑛) 全体の実装コスト 𝑐 𝑐(𝑖) 𝑗 種類目のコア機能の実装コスト 𝑐 𝑝(𝑗) 𝑗 種類目のネットワーク化サービスの ペリフェリー機能あたりの実装コスト 𝛼 実装済みのコア機能数に比例した 𝑐 𝑐(𝑖) の増加度を決定するパラメータ 𝛽 コア機能数の増加に伴った 𝑐 𝑝(𝑗) の減少度を決定するパラメータ 𝛾 𝑓𝑐(𝑛) 個のコア機能が 𝑗 種類目のネットワーク化 サービスの収容に用いられる頻度を表すパラメータ 変数・パラメータ
  • 7. Osaka University • 各サービスコンポーネントの実装コストの和として定義 • 𝑐 𝑎𝑙𝑙 𝑛 = 𝑖=0 𝑓𝑐(𝑛) 𝑐 𝑐(𝑖) + 𝑗=0 𝑛 𝑘 𝑝 𝑗 𝑐 𝑝(𝑗) • 𝑓𝑐 𝑛 個のコア機能それぞれに実装コスト 𝑐 𝑐 𝑖 が必要 • 𝑛 種類のネットワーク化サービスそれぞれの収容に 𝑘 𝑝(𝑗) 個のペリフェリー機能を利用 • それぞれのペリフェリー機能に実装コスト 𝑐 𝑝 𝑗 が必要 7 NFV ソフトウェア全体の実装コストのモデル化 サービス 1 サービス 2 サービス 𝑛 NFV ソフトウェア 全体の実装コスト 𝑐 𝑎𝑙𝑙 𝑛 コア機能の 実装コストの和 𝑖=0 𝑓𝑐 𝑛 𝑐 𝑐 𝑖 ペリフェリー機能の 実装コストの和 𝑗=0 𝑛 𝑘 𝑝(𝑗)𝑐 𝑝 𝑗 +=
  • 8. Osaka University • 実装済みのコア機能数に比例して追加のコア機能の実装コストが増加 • コア機能は複数のサービスコンポーネントとの連結を可能にするために 汎用化が必要 • より多くの連結を可能にするための汎用化に、より多くの実装コストを要求 • 𝑐 𝑐 𝑖 = 𝛼𝑖 • α: 実装済みのコア機能数に比例した 𝑐 𝑐 𝑖 の増加度を決定するパラメータ 8 コア機能の実装コストのモデル化 サービス 1 サービス 2 サービス 𝑝 𝑖 番目に追加するコア機能 実装コストは 𝑐 𝑐 𝑖 連結が想定される 実装済みの 𝑖 − 1 個のコア機能 新たなサービス 𝑞 連結が想定される、後に追加 されるサービスコンポーネント 複数との連結のため汎用化 多くの実装コストを要求
  • 9. Osaka University • コア機能数が増加するとペリフェリー機能の実装コストが減少 • 役割の一部を実装済みのコア機能で代用することで開発が容易に • コア機能数が増加するほど代用できる機会が増加 • ただしコア機能数増化に伴う ペリフェリー機能の実装コスト減少は一定の値に収束 • 実際に代用される機能は一定のものに限定されるため • 𝑐 𝑝(𝑗) = 𝑒−𝛽𝑓𝑐(𝑗) • 𝛽: コア機能数の増加に伴う 𝑐 𝑝(𝑗) の減少度を決定するパラメータ 9 ペリフェリー機能の実装コストのモデル化 パターンマッチング役割の一部を 実装済みの コア機能で代用 セッション管理ロードバランサ ファイアウォール ペリフェリー機能の 開発が易化 実装コスト 𝑐 𝑝(𝑗) 低下
  • 10. Osaka University • コア機能数が増加するとネットワーク化サービス収容に用いる ペリフェリー機能数が減少 • コア機能数が増加すると ネットワーク化サービスの収容にコア機能を利用する機会が増加 • 𝑘 𝑝 𝑗 = 𝑘 − 𝑘𝛾𝑓𝑐 𝑗 • ネットワーク化サービスあたりの収容に用いるコア機能を 𝑘𝛾𝑓𝑐 𝑗 • 𝛾: 𝑓𝑐 𝑛 個のコア機能が、あるネットワーク化サービスの収容に用いられる 頻度を表すパラメータ 10 サービス収容に用いるペリフェリー機能数のモデル化 サービス サービス 実装済み コア機能少 実装済み コア機能多 コア機能の利用少 (𝑘𝛾 × 1 = 1) 用いる ペリフェリー機能少 (𝑘 𝑝 = 2) 用いる ペリフェリー機能多 (𝑘 𝑝 = 3) 𝑘 = 4 コア機能の利用多 (𝑘𝛾 × 3 = 2)
  • 11. Osaka University • 0 ≤ 𝑛 ≤ 1000 の範囲で 𝑛 が増加をするシナリオを想定 • コア機能数の異なる設計指針の実装コストを比較 • 各設計指針で収容するネットワーク化サービスの種類は同一と想定 • 変数およびパラメータも共通 • 時間経過に伴い、新たに多様なユーザ要求が生じても 実装コストを抑えてネットワーク化サービスを収容可能かを重視 • 𝑛 = 1000 時点の NFV ソフトウェア全体の実装コスト 𝑐 𝑎𝑙𝑙(1000) を比較 11 数値結果の導出シナリオ パラメータ 値 𝑘 10 α 0.05 𝛽 0.001 𝛾 0.001 変数・パラメータ設定
  • 12. Osaka University 12 • 図のようにコア機能数を設定した四つの設計指針 • no core • コア機能を用いず ペリフェリー機能のみを用いてネットワーク化サービスを収容 • forecast • 将来のサービス収容を予測し、それに基づきコア機能を事前に実装 • 予測は正確で、事前に実装したコア機能が十分に再利用され 実装コストを最小化可能であると仮定 • unadaptive • forecast と同様に予測に基づきコア機能を実装 • 予測は不正確と仮定し 𝑛 の増加に伴い生じる想定外のサービスの 収容のためコア機能を追加 • adaptive • 新たなネットワーク化サービスの収容に伴って コア機能の設計を見直し追加することを想定 比較に用いる設計指針 各設計指針のコア機能数の設定
  • 13. Osaka University • 𝑐 𝑎𝑙𝑙(1000) は adaptive < no core < unadaptive • forecast は予測が正確であるという仮定があるため、他の設計指針がより現実的 • コア機能とペリフェリー機能両方を有することで実装コストを抑制 • adaptive の 𝑐 𝑎𝑙𝑙 1000 は no core と比べ約 15% 削減 • コア機能数が多いと 実装コストが増加 13 数値結果: コア機能数の異なる設計指針の実装コストの比較 各設計指針の実装コスト adaptive のようにコア機能を少量とし、新たなユーザ要求発生に伴い追加する 設計指針がより現実的に全体の実装コストを抑制することを確認 adaptive が no core と unadaptive を下回る
  • 14. Osaka University • まとめ • NFV ソフトウェアの実装コストに着目 • コアペリフェリー構造による NFV ソフトウェアの解釈 • 複数のネットワーク化サービスの収容に用いられるコア機能 • 一種類のネットワーク化サービスの収容に用いられるペリフェリ-機能 • コア機能数の大小によりペリフェリー機能数が変化 • コア機能を少量とし、新たなユーザ要求発生に伴い追加する設計指針が より現実的に全体の実装コストを抑制することを確認 • 今後の課題 • コア機能およびペリフェリー機能の物理インフラへの配置方法の考察 • 物理インフラのリソース制約のため、サービスコンポーネント数を考慮 • 複数個所に複製したサービスコンポーネントを配置するシナリオが想定されるため コア機能およびペリフェリー機能の複製の容易さを考慮 14 まとめと今後の課題