NFVにおけるクラウドネイティブ技術適用の挑戦

Transcript

1. NFVにおけるクラウドネイティブ技術適⽤の挑戦 2021/3/11-12 ⽇本電信電話株式会社 NTTネットワークサービスシステム研究所 篠原 健太
2. 1 Copyright 2021 NTT CORPORATION ⾃⼰紹介 篠原 健太 @ NTTネットワークサービスシステム研究所 • 業務︓コンテナ・クラウドネイティブのテレコム適⽤の研究 › CKA: CKA-2000-006814-0100 › CKS: 勉強中.. • 略歴 › ひかり電話（IMS／NGN）開発 › ⾼可⽤サーバプラットフォーム（分散系）の研究 › 仮想化基盤の要素技術研究（OpenStack, DPDK等） • sinohara@twitter • 趣味 › FPSゲーム（プレーしたり／Youtuber動画⾒たり／プレー動画を cv2+tensorflow+tesseractで分析したり）
3. 2 Copyright 2021 NTT CORPORATION Nutrition Facts 1 serving per container Serving size 30 minutes * https://bit.ly/3qSvtp4 ◦ NFV領域の簡単な動向 × 各種クラウドネイティブOSS 等のテクニカルな内容 ◦ 動作検証で確認したデータ ◦ 検討しているシステム構成 material SpeakerDeck*
4. 3 Copyright 2021 NTT CORPORATION NFV(Network Function Virtualisation) • ネットワーク機器の機能を汎⽤サーバの仮想化基盤上でソフトウェアとして実装する⽅式 • ETSIが主導し，2013年にシステムアーキテクチャが標準化 • OpenStack等のオープンソースを活⽤した商⽤化が国内外で進められている <NFV’s system architecture> 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
5. 4 Copyright 2021 NTT CORPORATION 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)
6. 5 Copyright 2021 NTT CORPORATION クラウドネイティブのベストプラクティス CI/CD DevOpS Containerization Microservices •ベンダ開発の⼯程が必要 であり，組織としての⼀ 体化が難しい •NW特有のプロトコル処理 がありステートレス化が難 しい •テレコムシステムはマルチベ ンダでのシステム構築が基本 →CI/CDが構築しづらい
7. 6 Copyright 2021 NTT CORPORATION NFVでのクラウドネイティブ活⽤の難しさ • コンテナ型仮想化はテレコムには適していない部分有り • VM技術も含めて，適切な技術の取捨選択が必要 • コンテナだけでなく，マイクロサービス型のアプリケーションアーキテクチャ や開発フロー，開発・運⽤のあり⽅にまで踏み込んでいくことが必要 NW特有プロトコル処理 のステートレス化 (containerization) コンポーネント粒度 の変化 NW構成の変化 (多段接続) 冗長化構成の変化 （ACT/SBY -> N- ACT） 開発手法の変化 保守運用の変化
8. 7 Copyright 2021 NTT CORPORATION NFVにおけるクラウドネイティブ技術適⽤の挑戦 • （⼤いなる何かの⼒で）コンテナが導⼊されはじめている • 「流⾏りの技術だから」という不純な動機 • ベンダにとっては開発効率化のモチベーションがある • 世の中のクラウドネイティブのベストプラクティスをそのままテレコ ムに持ち込むと，サービス品質が下がり，オペレーションが出来なく なる未来が⾒える • クラウドネイティブの技術を正しく使い，テレコムにおけるベストプ ラクティスを確⽴することで，クラウドネイティブの本来の価値をテ レコムにおいても享受したい
9. 8 Copyright 2021 NTT CORPORATION 今⽇お話すること • これまでの取組みを紹介 • クラウドネイティブ技術を取り⼊れたアーキテクチャ⾒直し • 検証を通じた現状の課題 • OpenStack/kubernetesの連携に向けたOSS活動 • クラウドネイティブなアプリケーション開発・パブクラでの基盤構築 • 同じ様な悩みを抱えてる⽅と是⾮意⾒交換したいです︕ • 新しい技術や課題解決のアプローチについても意⾒募集
10. 9 Copyright 2021 NTT CORPORATION クラウドネイティブ化のアプローチ Try! https://aws.amazon.com/jp/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/
11. 10 Copyright 2021 NTT CORPORATION アーキテクチャ⾒直し • モノリシックからの脱却として，通信制御系のレガシー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の統 合制御・管理 ・各種障害時のオートヒーリ ング動作検証 連携
12. 11 Copyright 2021 NTT CORPORATION A) モノリシック型APL B）プロトコル分離 C）永続データ(ユーザ データ)分離 D）セッションデータ分 離 E）シナリオ詳細化 （マイクロサービス） F）関数駆動 （FaaS) アーキテクチャ 概要 システムを単体の呼制御 サーバ内で構成 プロトコルを分離して電 番単位でロードバランサ が呼制御サーバを振り分 け ユーザデータを分離して セッション単位でロード バランサが呼制御サーバ を振り分け セッションデータを分離 して、トランザクション 単位でロードバランサが 呼制御サーバを振り分け 呼制御サーバのシナリオ をコンポーネント単位に 分散して、コンポーネン ト連携しながら呼制御を 実施 コンポーネントを関数単 位に分散して、関数駆動 しながら呼制御を実施 主な効果 ー 複数ノードを集約可能 セッション単位での負荷 分散が可能 ユーザ数に応じたスケー ラビリティを実現 トランザクション単位で の負荷分散が可能 セッション数に応じたス ケーラビリティを実現 サービス需要に応じたス ケーラビリティを実現 収容効率のさらなる向上 主な技術的課題 － プロトコルーシナリオ間 でのデータ通信⽅式 シナリオからのデータア クセス⽅式 ラウンドロビンでの負荷 分散、及び、データ競合 対策⽅式 コンポーネント間の連携 （シナリオ制御）⽅式 ステートフルアプリケー ションの実現⽅法 1st Step: アプリケーション分離の⽬標 • モノリシック型アプリケーションのクラウドネイティブ化に向けた1st Stepとして，データ・ロジックの分離を⽬標に設定 呼制御サーバ プロトコル シナリオ ブロック セッション 加⼊者 LB data data data data data data data 当面の目標
13. 12 Copyright 2021 NTT CORPORATION 1st Step:三層分離APLの実機検証︓APL構成 • EPC(PGWの呼処理機能部)をサンプルとし，モノリシックAPLから三層分離化 のプロトタイピングを実施し，実機検証を実施 課⾦管理 課⾦管理 課⾦管理等 IP管理 IP管理 SGW シナリオブロック UP管理 UP管理 PGW シナリオブロック KVS(data) 対向装置（擬似） プロトコル 呼処理 プロトコル処理部 GTP DIAMETER RADIUS MME PCRF RADIUS U-Plane管理 UP対向 ステート管理
14. 13 Copyright 2021 NTT CORPORATION 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/アムダールの法則
15. 14 Copyright 2021 NTT CORPORATION 2nd Step:コンテナ化 • データ・ロジック分離でステートレス化されたシナリオ部をまずコンテナ化 • NFVアーキテクチャに準拠しつつ，VM/コンテナ両⽅を扱える基盤構成 VNF NFVI シナリオ プロトコル シナリオ 保守系機能部 VIM Generic VNFM VM VM VM VM Kubernetes worker Kubernetes worker シナリオ シナリオ VM データベース コンテナ コンテナ EMS コンテナ管理 Kubernetes master 監視
16. 15 Copyright 2021 NTT CORPORATION 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構成
17. 16 Copyright 2021 NTT CORPORATION • コンテナは⼲渉を受けやすいため，コンテナを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)への負荷
18. 17 Copyright 2021 NTT CORPORATION 効果 • 今回のプロトタイプでの検証では，リソース収容効率やオペレーションの迅速 化の観点で効果を確認 効果 結果 設備ｺｽﾄ削減 増設時の必要リソース量 (CPU)12コア→0.5コア コアあたりのスループット性能 +50%向上 保守運⽤効率化 初期構築 ±0 増設 85%時間削減 減設 61%時間削減 復旧 71%時間削減
19. 18 Copyright 2021 NTT CORPORATION 2. 技術課題と今後の展望 • ⼤きく3つの技術領域に 取り組んでいく必要がある 1. 監視・オペレーション 2. クラウドネイティブに 即した仮想化⽀援技術 3. NW要件とキャリアグレード を両⽴するAPL構成技術 運⽤ 開発 基盤 APL 障害時に呼損が 発⽣する 三層分離アーキテク チャにはスケール限 界が存在する． ネットワーク機能間で構築・維 持が必要なセッションを， microservice/k8sでどう持つ べきか FPGA/GPUをk8s環境 で公平にPodにスケ ジューリングできない SR-IoVのようなNWの 仮想化⽀援技術が利⽤ できない ベンダNFVを組み込ん だCI/CDパイプライン の構築が困難 仮想リソースがコンテ ナ・VMにまたがり，監 視が複雑化 VNFが細分化され，監 視が複雑化 マイクロサービス型 アーキテクチャはモノ リシック型APLと⽐較 し遅延が増加 VM/コンテナ混在型 アーキテクチャはアッ プデートが従来より複 雑化する ① ② ③
20. 19 Copyright 2021 NTT CORPORATION 3. OpenStack/kubernetesの連携に向けたOSS活動 • これまではVNF=VMであり， OpenStackを前提としたVNF ライフサイクル管理を実施 • クラウドネイティブ化により VM・コンテナの管理が必要 • OpenStack/kubernetesを ベースに，VNFのデプロイメ ントをできる必要がある
21. 20 Copyright 2021 NTT CORPORATION 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
22. 21 Copyright 2021 NTT CORPORATION 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
23. 22 Copyright 2021 NTT CORPORATION 【参考】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]
24. 23 Copyright 2021 NTT CORPORATION コンテナ主流型アーキテクチャ • 将来的にはVM/コンテナの管 理がk8sに集約されると想定 • KubeVirt, AirShipなどのOSSや 製品評価を実施中
25. 24 Copyright 2021 NTT CORPORATION 3. クラウドネイティブなアプリケーション開発・基盤構築 • クラウドネイティブ化の促進には内製開発も重要 • 今後，NFVにおいてもパブリッククラウドも候補になるか も知れない • 認証サーバ(radius)をサンプルに，kubernetesベースのコ ンテナ基盤を試作 • クラウド基盤はAWSを利⽤
26. 25 Copyright 2021 NTT CORPORATION 時間がないので割愛します NTT Tech Conference #4 (公開イベント) にて紹介してるので良かったら⾒てね https://speakerdeck.com/sinohara/amazon-eksshang-defalsevnfkai-fa-fen-dou-ji
27. 26 Copyright 2021 NTT CORPORATION まとめ • テレコムにおけるクラウドネイティブのベストプラクティスの確⽴に 向けて，既存システムのアーキテクチャ⾒直し・VM/コンテナを組み 合わせた基盤構成により実施した検証について紹介 • 基本的な動作が問題ないことや⼀定の効果は確認出来ている⼀⽅で， 様々な課題がある • 現状の課題を踏まえ，3つの技術領域を今後検討していきたい • OpenStack/kubernetesの連携に向けたOSS活動を推進中
28. Your Value Partner