NFVにおけるクラウドネイティブ技術適用の挑戦

NFVにおけるクラウドネイティブ技術適⽤の挑戦
2021/3/11-12
⽇本電信電話株式会社
NTTネットワークサービスシステム研究所
篠原健太

View Slide

1
Copyright 2021 NTT CORPORATION
⾃⼰紹介
篠原健太 @ NTTネットワークサービスシステム研究所
• 業務︓コンテナ・クラウドネイティブのテレコム適⽤の研究
› CKA: CKA-2000-006814-0100
› CKS: 勉強中..
• 略歴
› ひかり電話（IMS／NGN）開発
› ⾼可⽤サーバプラットフォーム（分散系）の研究
› 仮想化基盤の要素技術研究（OpenStack, DPDK等）
• [email protected]
• 趣味
› FPSゲーム（プレーしたり／Youtuber動画⾒たり／プレー動画を
cv2+tensorflow+tesseractで分析したり）

View Slide

2
Nutrition Facts
1 serving per container
Serving size 30 minutes
* https://bit.ly/3qSvtp4
○ NFV領域の簡単な動向 × 各種クラウドネイティブOSS
等のテクニカルな内容
○ 動作検証で確認したデータ
○ 検討しているシステム構成
material SpeakerDeck*

View Slide

3
NFV(Network Function Virtualisation)
• ネットワーク機器の機能を汎⽤サーバの仮想化基盤上でソフトウェアとして実装する⽅式
• ETSIが主導し，2013年にシステムアーキテクチャが標準化
• OpenStack等のオープンソースを活⽤した商⽤化が国内外で進められている

ETSI GS NFV 002 V1.1.1 (https://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf)
https://portal.etsi.org/nfv/nfv_white_paper.pdf
Network Functions Virtualisation – Introductory White Paper, Issue 1

View Slide

4
NFVへのクラウドネイティブの導⼊
• CNF(Cloud-Native Network Function/VNF)が定義され，Network
Functionのクラウドネイティ化・k8sの概念がNFVにも取りれられつつある
https://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/011/03.01.01_60/gs_nfv-eve011v030101p.pdf
https://static.sched.com/hosted_files/kccncna19/b7/CNCF%20Telecom%20User%20Group%20Kickoff%20%281%29.pdf
CNCF TUG(Telecom User Group) ETSI GS NFV-EVE 011 V3.1.1 (2018-10)

View Slide

5
クラウドネイティブのベストプラクティス
CI/CD
DevOpS
Containerization
Microservices
•ベンダ開発の⼯程が必要
であり，組織としての⼀
体化が難しい
•NW特有のプロトコル処理
がありステートレス化が難
しい
•テレコムシステムはマルチベ
ンダでのシステム構築が基本
→CI/CDが構築しづらい

View Slide

6
NFVでのクラウドネイティブ活⽤の難しさ
• コンテナ型仮想化はテレコムには適していない部分有り
• VM技術も含めて，適切な技術の取捨選択が必要
• コンテナだけでなく，マイクロサービス型のアプリケーションアーキテクチャ
や開発フロー，開発・運⽤のあり⽅にまで踏み込んでいくことが必要
NW特有プロトコル処理
のステートレス化
(containerization)
コンポーネント粒度
の変化
NW構成の変化
(多段接続)
冗長化構成の変化
（ACT/SBY -> N-
ACT）
開発手法の変化保守運用の変化

View Slide

7
NFVにおけるクラウドネイティブ技術適⽤の挑戦
• （⼤いなる何かの⼒で）コンテナが導⼊されはじめている
• 「流⾏りの技術だから」という不純な動機
• ベンダにとっては開発効率化のモチベーションがある
• 世の中のクラウドネイティブのベストプラクティスをそのままテレコ
ムに持ち込むと，サービス品質が下がり，オペレーションが出来なく
なる未来が⾒える
• クラウドネイティブの技術を正しく使い，テレコムにおけるベストプ
ラクティスを確⽴することで，クラウドネイティブの本来の価値をテ
レコムにおいても享受したい

View Slide

8
今⽇お話すること
• これまでの取組みを紹介
• クラウドネイティブ技術を取り⼊れたアーキテクチャ⾒直し
• 検証を通じた現状の課題
• OpenStack/kubernetesの連携に向けたOSS活動
• クラウドネイティブなアプリケーション開発・パブクラでの基盤構築
• 同じ様な悩みを抱えてる⽅と是⾮意⾒交換したいです︕
• 新しい技術や課題解決のアプローチについても意⾒募集

View Slide

9
クラウドネイティブ化のアプローチ
Try!
https://aws.amazon.com/jp/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/

View Slide

10
アーキテクチャ⾒直し
• モノリシックからの脱却として，通信制御系のレガシーAPLのクラウ
ドネイティブ化を進めつつ，基盤構成を進化させていった事例紹介
VNFM
プロトコル処理
(VM)
シナリオ処理
(ｺﾝﾃﾅ)
…
ステート管理
(VM)
<クラウドネイティブ型VNF>
NFVI
(baremetal/KVM)
VIM
(OpenStack)
VNFM
(Tacker)
ｺﾝﾃﾅ管理
(Kubernetes)
Step 主な⽬的主な確認観点
1st
APLの3層分離化による効
果・SLA影響確認
・設備コスト削減効果
・増減設・復旧時間短縮効果
・レイテンシ悪化等の影響有
無
2nd
コンテナ型APLのNFV基盤
上への搭載に向けたコンテ
ナ管理部の基本動作確認・
性能影響確認
VNFMによるクラウドネイ
ティブ型VNFのInsta/ﾋｰﾘﾝ
ｸﾞ等の動作実証
・コンテナ管理のLCM機能
・NFVIのVMレイヤ有無によ
る性能影響
・VM/コンテナ混在VNFの統
合制御・管理
・各種障害時のオートヒーリ
ング動作検証
連携

View Slide

11
A) モノリシック型APL B）プロトコル分離
C）永続データ(ユーザ
データ)分離
D）セッションデータ分
離
E）シナリオ詳細化
（マイクロサービス）
F）関数駆動
（FaaS)
アーキテクチャ
概要
システムを単体の呼制御
サーバ内で構成
プロトコルを分離して電
番単位でロードバランサ
が呼制御サーバを振り分
け
ユーザデータを分離して
セッション単位でロード
バランサが呼制御サーバ
を振り分け
セッションデータを分離
して、トランザクション
単位でロードバランサが
呼制御サーバを振り分け
呼制御サーバのシナリオ
をコンポーネント単位に
分散して、コンポーネン
ト連携しながら呼制御を
実施
コンポーネントを関数単
位に分散して、関数駆動
しながら呼制御を実施
主な効果ー複数ノードを集約可能
セッション単位での負荷
分散が可能
ユーザ数に応じたスケー
ラビリティを実現
トランザクション単位で
の負荷分散が可能
セッション数に応じたス
ケーラビリティを実現
サービス需要に応じたス
ケーラビリティを実現
収容効率のさらなる向上
主な技術的課題－
プロトコルーシナリオ間
でのデータ通信⽅式
シナリオからのデータア
クセス⽅式
ラウンドロビンでの負荷
分散、及び、データ競合
対策⽅式
コンポーネント間の連携
（シナリオ制御）⽅式
ステートフルアプリケー
ションの実現⽅法
1st Step: アプリケーション分離の⽬標
• モノリシック型アプリケーションのクラウドネイティブ化に向けた1st
Stepとして，データ・ロジックの分離を⽬標に設定
呼制御サーバ
プロトコルシナリオ
ブロック
セッション加⼊者
LB
data
data
data
data
data
data
data
当面の目標

View Slide

12
1st Step:三層分離APLの実機検証︓APL構成
• EPC(PGWの呼処理機能部)をサンプルとし，モノリシックAPLから三層分離化
のプロトタイピングを実施し，実機検証を実施
課⾦管理
課⾦管理
課⾦管理等
IP管理
IP管理
SGW
シナリオブロック
UP管理
UP管理
PGW
シナリオブロック
KVS(data)
対向装置（擬似）プロトコル呼処理
プロトコル処理部
GTP
DIAMETER
RADIUS
MME
PCRF
RADIUS
U-Plane管理
UP対向
ステート管理

View Slide

13
1st Step:三層分離APLの実機検証︓結果
• APL構成の分離を⾏なっても遅延の劣化は極端に⼤きくならないことを確認
• ⼀⽅で，アムダールの法則に準じたスケール限界が存在することを確認
0
20
40
60
80
100
120
140
160
180
200
最
小
構
成
／
7,200e/h
PGW-C 2
台
構
成
／
14,400e/h
PGW-C 4
台
構
成
／
28,800e/h
PGW-C 7
台
構
成
／
50,400e/h
PGW-C 9
台
構
成
／
64,800e/h
PGW-C 10
台
構
成
／
72,000e/h
ｽﾃｰﾄﾚｽVM
各
10
台
構
成
／
72,000e/h
応
答
時
間
(ms)
遅延
最小
最大
平均
最頻
線形 (最小)
線形 (最大)
線形 (平均)
線形 (最頻)
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728
スループット(event/hour)
PGW-C台数
最⼤スループット傾向
並列度90%
並列度85%
約6倍
約10倍
アムダールの法則（アムダールのほうそく、英語: Amdahl's law）は、ある計算機システムとその対象とする計算についてのモデルにおいて、
その計算機の並列度を上げた場合に、並列化できない部分の存在、特にその割合が「ボトルネック」となることを示した法則である。コン
ピュータ・アーキテクトのジーン・アムダールが主張したものであり、アムダールの主張（アムダールのしゅちょう、英語: Amdahl's
argument）という呼称もある[1]。
https://ja.wikipedia.org/wiki/アムダールの法則

View Slide

14
2nd Step:コンテナ化
• データ・ロジック分離でステートレス化されたシナリオ部をまずコンテナ化
• NFVアーキテクチャに準拠しつつ，VM/コンテナ両⽅を扱える基盤構成
VNF
NFVI
シナリオ
プロトコル
シナリオ
保守系機能部
VIM
Generic
VNFM
VM VM VM VM
Kubernetes
worker
Kubernetes
worker
シナリオ
シナリオ
VM
データベース
コンテナコンテナ
EMS
コンテナ管理
Kubernetes
master
監視

View Slide

15
2nd Step:デプロイ形態評価
• コンテナを物理マシンに直接デプロイ/VM上にデプロイする両形態で評価を実施
• 今回の検証では，スループット性能の観点では最⼤10%程度PM構成の⽅が優位
0
500,000
1,000,000
1,500,000
2,000,000
2,500,000
3,000,000
1 3 6 9 1215182124273033363942454851545760636669727578
スループット(event/hour)
PGW-C台数
最⼤スループット傾向
PM VM(⼤) VM(⼩)
物理マシン
Hypervisor
OS
コンテナ
MW
APP
物理マシン
コンテナ
MW
APP
仮想マシン(VM)
OS
コンテナ
MW
APP
仮想マシン(VM)
OS
コンテナ
MW
APP
コンテナ on PM構成コンテナ on VM構成

View Slide

16
• コンテナは⼲渉を受けやすいため，コンテナをVMへの適切な配置が重要
0
200
400
600
800
1,000
18:35:00
18:35:41
18:36:36
18:37:03
18:37:24
18:37:36
18:37:47
18:38:00
18:39:17
18:39:49
18:40:08
18:40:24
18:40:36
18:40:47
18:41:52
18:42:32
18:42:54
18:43:12
18:43:23
18:43:35
18:44:20
18:45:13
18:45:39
18:46:00
18:46:12
18:46:23
18:46:35
18:47:53
18:48:24
18:48:44
18:48:59
18:49:11
18:49:23
18:50:31
18:51:09
18:51:30
18:51:48
18:51:59
18:52:10
18:53:00
18:53:50
18:54:15
18:54:35
18:54:47
18:54:58
応答時間(ms)
CPUリソース負荷終了
CPUリソース負荷開始
0
100
200
300
400
0
25
50
75
100
125
150
175
200
225
250
275
300
325
350
375
400
425
450
475
500
525
550
575
600
625
650
675
700
725
750
775
800
825
850
875
900
925
950
975
呼数
レイテンシ(ms)
2nd Step:⼲渉への影響
測定結果︓コンテナ基盤輻輳 Worker Node VM(Guest)への負荷

View Slide

17
効果
• 今回のプロトタイプでの検証では，リソース収容効率やオペレーションの迅速
化の観点で効果を確認
効果結果
設備ｺｽﾄ削減増設時の必要リソース量 (CPU)12コア→0.5コア
コアあたりのスループット性能 +50%向上
保守運⽤効率化初期構築 ±0
増設 85%時間削減
減設 61%時間削減
復旧 71%時間削減

View Slide

18
2. 技術課題と今後の展望
• ⼤きく3つの技術領域に
取り組んでいく必要がある
1. 監視・オペレーション
2. クラウドネイティブに
即した仮想化⽀援技術
3. NW要件とキャリアグレード
を両⽴するAPL構成技術
運⽤
開発
基盤 APL
障害時に呼損が
発⽣する
三層分離アーキテク
チャにはスケール限
界が存在する．
ネットワーク機能間で構築・維
持が必要なセッションを，
microservice/k8sでどう持つ
べきか
FPGA/GPUをk8s環境
で公平にPodにスケ
ジューリングできない
SR-IoVのようなNWの
仮想化⽀援技術が利⽤
できない
ベンダNFVを組み込ん
だCI/CDパイプライン
の構築が困難
仮想リソースがコンテ
ナ・VMにまたがり，監
視が複雑化
VNFが細分化され，監
視が複雑化
マイクロサービス型
アーキテクチャはモノ
リシック型APLと⽐較
し遅延が増加
VM/コンテナ混在型
アーキテクチャはアッ
プデートが従来より複
雑化する
①
②
③

View Slide

19
3. OpenStack/kubernetesの連携に向けたOSS活動
• これまではVNF=VMであり，
OpenStackを前提としたVNF
ライフサイクル管理を実施
• クラウドネイティブ化により
VM・コンテナの管理が必要
• OpenStack/kubernetesを
ベースに，VNFのデプロイメ
ントをできる必要がある

View Slide

20
OpenStack Tackerのねらい
• VM/コンテナ差分を吸収し、統⼀IFで操作可能なMANO機能 (VNFM)
• OpenStack/Kubernetes上でVM/コンテナのライフサイクル管理
統⼀IF (ETSI NFV準拠)によるマルチベンダー化キャリア要件のOSS実装によるコスト削減
VNF VNFM
Company a
NFVO
Company α
Supported
Group A
VNF VNFM
Company b
NFVO
Company β Supported
Group B
and
/or
VNFM
Tacker
NFVO
VNF
VNF
Unified IF
Possible
Pattern
• ⾼可⽤/⾼性能向け機能の開発/検証負担の縮⼩
• レガシー基盤との共存運⽤
OSS
Tacker
High-Availability
High-performance
Products
OSS
Tacker
High-Availability
High-performance
Hardware
Interoperability
&
Unified Control

View Slide

21
OpenStack Tackerで実現したいこと
統⼀IF (ETSI NFV準拠)によるマルチベンダー化
1. 多様なVNFを運⽤可能なGeneric-VNFMとしてデファクト化
キャリア要件のOSS実装によるコスト削減
2. オンプレManaged Kubernetes（Kubernetes VIM/PaaS）の実現
1. 多様なVNFを運⽤可能なGeneric-VNFMとしてデファクト化
• 任意のNFVO/VNF組み合わせで運⽤
• ベンダー製品のベースOSSとして活⽤
2. オンプレManaged Kubernetes（Kubernetes VIM/PaaS）の実現
• オンプレKubernetes環境でVNFとして運⽤
• Public Cloud相当の冗⻑構成、クラスタ拡張機能の提供
G-VNFM
Tacker
NFVO
from A社
VNF
from α社
VNF
from β社
VNF Package
from α社
VNFD
VNF Package
from β社
VNFD
ETSI NFV
Public Cloud
On-premises
• Start quickly with single-click clusters
• High-availability master node
• Auto scaling worker node
• Auto-repair, auto-upgrade
MANO
ETSI NFV
High-Availability
High-performance

View Slide

22
【参考】Tackerを使ってみませんか︖
Victoriaリリース
(2020.10)
• VM/コンテナ統⼀IF
ライフサイクル実装完了
Wallabyリリース
(2021.5)
• Kubernetesクラスタ
ライフサイクル実装完了
Xenaリリース
(2021.10)
• ETSI NFV標準IF
複数バージョン対応 and more...
• 基本的なライフサイクルは実装済み、動かして試せるステータスです︕
• 公式ドキュメント｜ https://docs.openstack.org/tacker/latest/user/index.html
• コンテナ関連実装をETSI
NFV標準へフィードバック中
• ETSI NFVとのWorkshop
開催に向けて調整中
[latest]

View Slide

23
コンテナ主流型アーキテクチャ
• 将来的にはVM/コンテナの管
理がk8sに集約されると想定
• KubeVirt, AirShipなどのOSSや
製品評価を実施中

View Slide

24
3. クラウドネイティブなアプリケーション開発・基盤構築
• クラウドネイティブ化の促進には内製開発も重要
• 今後，NFVにおいてもパブリッククラウドも候補になるか
も知れない
• 認証サーバ(radius)をサンプルに，kubernetesベースのコ
ンテナ基盤を試作
• クラウド基盤はAWSを利⽤

View Slide

25
時間がないので割愛します
NTT Tech Conference #4 (公開イベント)
にて紹介してるので良かったら⾒てね
https://speakerdeck.com/sinohara/amazon-eksshang-defalsevnfkai-fa-fen-dou-ji

View Slide

26
まとめ
• テレコムにおけるクラウドネイティブのベストプラクティスの確⽴に
向けて，既存システムのアーキテクチャ⾒直し・VM/コンテナを組み
合わせた基盤構成により実施した検証について紹介
• 基本的な動作が問題ないことや⼀定の効果は確認出来ている⼀⽅で，
様々な課題がある
• 現状の課題を踏まえ，3つの技術領域を今後検討していきたい
• OpenStack/kubernetesの連携に向けたOSS活動を推進中

View Slide

Your Value Partner

View Slide

NFVにおけるクラウドネイティブ技術適用の挑戦

NFVにおけるクラウドネイティブ技術適用の挑戦

Kenta Shinohara

More Decks by Kenta Shinohara

Other Decks in Technology

Featured

Transcript