NFV基盤のOpenStack更新 ～9世代バージョンアップへの挑戦～

イベントグループ：日本OpenStackユーザ会
イベント名：日本OpenStackユーザ会 第51回勉強会
日時：2025年2月25日(火) 18時30分
場所：NTTソフトウェアイノベーションセンタ
イベントページ：https://openstack-jp.connpass.com/event/343743/

Transcript

1. ©2025 DOCOMO, INC. ALL Rights Reserved. NFV基盤のOpenStack更改 〜9世代バージョンアップへの挑戦〜 2025年2月25日 日本OpenStackユーザ会 第51回勉強会 NTTドコモ 鎌田 亨、早川 雅人
2. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 自己紹介 1 早川 雅人 鎌田 亨 • OpenStack”絶賛”勉強中 • 2015年からNFV基盤開発一筋
3. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 本日の内容 2 ドコモではOpenStackの9世代バージョンアップに挑戦しました その中で様々な苦労や課題に直面してきました（今も） 本日はドコモが直面した苦労や課題を共有したうえで、 効率的なバージョンアップ⽅法に関して議論をさせていただきたい
4. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 目次 1. ドコモのネットワーク仮想化基盤の概要 2. ドコモのネットワーク仮想化基盤の歴史 3. 一般的なローリングアップグレード方式 4. Openstack複数世代Skipの課題と取り組み 5. 商⽤更改時の故障サーバ対応の課題と取り組み 6. まとめと議論ポイント 3
5. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 1. ドコモのネットワーク仮想化基盤の概要 1/2 ドコモでは2016年以来、ETSI ISG NFV規格に準拠した仮想化基盤を構築し、コアネットワー クシステムを収容・運⽤ Data Centers 27 Clusters 100 Servers 11,000＋ Virtual Network Function 20＋ Virtual Machines 200,000＋ VNF VM VM VM VM 4
6. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 1. ドコモのネットワーク仮想化基盤の概要 2/2 • OpenStack, KVMベースのIaaS基盤上で様々なアプリケーションを運⽤ • 一部のアプリケーションについてはContainer on VMの形式でデプロイ • 全国に約100のクラスタが存在 KVM+qemu VM VM APL APL VM Container APL 5 ︓各地域やデータセンタに配置された独⽴した OpenStack Clusterを指す
7. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 6 これまでに3回のVersion UPを実施 • 2016年導⼊からIcehouse・Mitakaを経てVictoriaへ更改中 • 現在は初の複数世代バージョンアップ＆サービス無中断に挑戦中 Icehouse導⼊ Icehouse→Mitaka更改 再構築⽅式 ※初の複数世代UP Mitaka→Mitaka更改 ローリングアップグレード⽅式 ※初のサービス無中断 Mitaka→Victoria更改 ローリングアップグレード⽅式 ※初の複数世代UP＆サービス無中断 2016年 2017年 2019年 2023年 OpenStackはバージョンがaから始まり、アルファベット順である 今回
8. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 1/4 7 2016年に初期導入 • 2つのOpenStack RegionにvEPCをデプロイ。 • ベアメタルのEPCとプール構成を組むことで、問題発生時のサービス影響を極小化。 Icehouse vEPC （ベンダA） vEPC （ベンダB） Icehouse EPC （ベンダA） EPC （ベンダA） EPC （ベンダA） EPC （ベンダA） EPC （ベンダA） EPC （ベンダB）
9. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 2/4 8 2017年に初のVersionUP • Openstack Icehouse -> Mitaka にVersionUP • 小規模なのでサービスを止めたうえで再インストールする手法を選択。4世代のバージョンアップ Icehouse vEPC EPC （ベンダA） EPC （ベンダA） EPC Mitaka vEPC EPC （ベンダA） EPC （ベンダA） EPC Mitaka vEPC EPC （ベンダA） EPC （ベンダA） EPC ターミネーション 再インストール 再インスタンシエーション
10. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 3/4 9 2019年に再びVersionUP • 導⼊から3年経過し、運⽤規模が⼤きくなっていた。 DC︓9 OpenStack Cluster︓33 サーバ台数︓4000台 • サービスを止めずにVersionUPする手法に挑戦。 Mitaka vEPC Mitaka Mitaka vEPC Mitaka Mitaka vEPC vEPC Mitaka vEPC VM移動 アップグレード アップグレード
11. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 2. ネットワーク仮想化基盤導入・VersionUPの歴史 4/4 10 2023年に再々度VersionUP • 導⼊から6年経過し、運⽤規模が更に⼤きくなっていた。 DC︓24 OpenStack Cluster︓75 サーバ台数︓9000台 • 前回同様サービスを止めずにVersionUPする手法に挑戦 ローリングアップグレードでOpenStackをMitakaからVictoriaへ更改。9世代バージョンアップ Mitaka vEPC Mitaka Victoria vEPC Mitaka vEPC vEPC vEPC 9世代Skipに挑戦 Victoria Victoria
12. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 Controller 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）1/4 11 Compute Gen N vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC N世代で運用中 ControllerをN＋1世代へ更改
13. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 Controller 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）2/4 12 Compute vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Gen N＋1 vEPC vEPC VMヒーリング Compute更改
14. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）3/4 13 Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC vEPC vEPC 再度VMヒーリング 再度Compute更改
15. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 3. ローリングアップグレードの⽅式（同世代やN+1世代へ）4/4 14 Controller Compute Gen N＋1 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Gen N＋1 vEPC vEPC vEPC vEPC Compute HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC 順番にVMヒーリング・更改 バージョンアップ完了
16. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 余談 15 最近のOpenStackはN＋2世代までローリングアップグレード対応しているようですね ※OpenStack 2023.1 (Antelope) 以降
17. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 4. Openstack複数世代Skipのローリングアップグレードにおける課題 16 複数世代Skipしてしまうと・・・  根本的にOpenStackとしてローリングアップグレードが提供されていない 1. Controllerのアップグレードをどうするか・・ 2. 構造が変わっているデータベースの移⾏をどうするか・・・ 3. 新世代Controllerから旧世代Computeを制御出来ないがどうするか・・・  世代が新しくなりすぎるとAPI差分が大きい 4. 使っていたAPI VersionがDeleteされたり、オプションパラメータが増えたり減ったりしている・・
18. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 17 順に課題と対策を説明していきます 4. Openstack複数世代Skipのローリングアップグレードにおける課題
19. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 先に述べたように稼働中のOpenStackををそのままアップグレードすることが出来ない為、独 自にアップグレードを方式を考える必要があった。 以下のどちらの道を選ぶかは⼤きな判断ポイントであったが、ドコモでは案②を選択した。 ※サービス継続性を重視 案①旧世代Controllerを止めて新世代Controllerをインストールする 案②新世代Controllerを追加で新設する 18 4-1. アップグレード⽅式 Compute Controller Gen N Compute Controller Gen N Compute Controller Gen N＋9 Compute Controller Gen N Compute Controller Gen N Controller Gen N＋9 Compute Controller Gen N＋9 Compute Controller Gen N＋9 案① 案② 採用
20. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 4-1. アップグレード⽅式 19 Controller Compute Gen N vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Compute Gen N＋9 vEPC HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Gen N HostOS OpenStack Agent Mitakaで運用中 新Controllerデプロイ
21. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 20 Controller Compute Gen N＋9 vEPC HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC vEPC Controller Gen N HostOS OpenStack Agent Controller Compute Gen N＋9 vEPC HostOS OpenStack Agent HostOS OpenStack Agent vEPC vEPC Controller Gen N HostOS OpenStack Agent DB Migration OpenStack Agent OpenStack Agent 4-1. アップグレード⽅式 vEPC DBマイグレーション 互換性Agentインストール
22. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 21 Controller Gen N＋9 Controller Gen N Controller Compute Gen N＋9 HostOS OpenStack Agent HostOS OpenStack Agent Controller Gen N HostOS OpenStack Agent OpenStack Agent vEPC vEPC OpenStack Agent OpenStack Agent vEPC vEPC vEPC vEPC vEPC vEPC vEPC vEPC Compute HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent 4-1. アップグレード⽅式 VMヒーリング（互換Agent活用） Compute更改
23. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 22 Controller Gen N＋9 Controller Gen N Controller Gen N＋9 HostOS OpenStack Agent Controller Gen N HostOS OpenStack Agent OpenStack Agent vEPC vEPC vEPC vEPC vEPC vEPC Compute HostOS OpenStack Agent HostOS OpenStack Agent Compute HostOS OpenStack Agent vEPC vEPC vEPC vEPC HostOS OpenStack Agent 4-1. アップグレード⽅式 順次VMヒーリング・更改 バージョンアップ完了（旧Controller撤去）
24. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 Controllerノードを一時的に2世代デプロイする方式を選択し、そのうえで旧世代からデータ ベースを移⾏した。 データベースの移⾏においては、世代間のスキーマ構成差分を踏まえた変換が必要な点や移 ⾏中は運⽤中のデータベースが更新されないように運⽤制限を掛ける必要がありました。 4-2. データベース移⾏ 23 Controller Gen N Controller Gen N＋9 Controller Gen N Controller Gen N＋9 Controller Gen N DB Migration アップグレード未サポート 2世代デプロイ・DBマイグレ
25. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 Compute Compute 4-3. 互換Agent 24 新旧世代間でControllerノードとComputeノードのサービスがサポートされておらずローリン グアップグレードの肝となるVM移動が出来ない。 これに対し、旧世代のCompute上に新世代のControllerから制御出来る互換Agent開 発、インストールすることでVM移動を可能とした。 vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC Controller Gen N＋9 vEPC vEPC vEPC vEPC VM削除 VM作成 Compute Compute vEPC HostOS OpenStack Agent HostOS OpenStack Agent HostOS OpenStack Agent vEPC Controller Gen N＋9 vEPC vEPC vEPC vEPC VM作成 OpenStack Agent OpenStack Agent VM削除 互換Agent無し 互換Agentあり
26. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 25 4-4. API差分への対応 次にAPI差分の課題と対策を説明していきます
27. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 4-4. API差分への対応 26 OpenStack Mitaka OSS NFVO VNFM(A) VNFM(C) VNFM(B) VNFM(D) • 本課題は複数世代Skipならではの課題という訳ではありませんが、世代差 が広がるほど遭遇する可能性が高くなると思われます。 • 一般的にAPIを発⾏するオペレーション、もしくはシステム側で新たなAPIに 対応するのが基本ですが、ドコモの仮想化基盤は下図のようにAPIを発⾏する のは全てシステムで自動化されています。
28. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 4-4. API差分への対応 27 OpenStack Mitaka OSS NFVO VNFM (A) VNFM (C) VNFM (B) VNFM (D) OpenStack Victoria OSS NFVO API-GW VNFM (A) VNFM (C) VNFM (B) VNFM (D) その為、新たなAPIやパラメータに対応する為には複数の上位システムで追従 開発が必要になります。 これは開発期間やコストの観点で最適とは言えない状況であったため、ドコモで は下図の⽤にOpenStack側で世代間のAPI差分吸収するGWシステムを開発 することで開発期間やコストの最適化に取り組みました。 上位システム対応 OpenStack対応 開発 開発 開発 開発 開発 開発
29. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 28 ところが・・・ 4-4. API差分への対応
30. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 29 APIを発⾏しているシステム(≒サプライヤ)自⾝が発⾏しているAPI、 パラメータを開示できない問題に直面した。 OpenStackからのResponseを参照する動作仕様も不明というケースもあり、机上確認、実機からダンプデータ を取得する等で上流⼯程での確認には限りがあり、仕様・設計上の完全性は求めるべくもなかった・・ 「7割程度の精度の設計」「実機対向試験は問題が出ることが前提」の方針で取り組んだ。 4-4. API差分への対応 OpenStack Victoria OSS NFVO API-GW VNFM (A) VNFM (C) VNFM (B) VNFM (D) ︓IF仕様の開示可能かつ規定済 ︓IF仕様の開示不可 ︓収容VNF種が多く、APIの網羅性懸念あり
31. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 4. Openstack複数世代Skipのローリングアップグレードにおける課題 30 複数世代Skipしてしまうと・・・  根本的にOpenStackとしてローリングアップグレードが提供されていない 1. Controllerのアップグレードをどうするか →Controllerを増設する⽅式で解決 2. 構造が変わっているデータベースの移⾏をどうするか →運用制限を掛けながらデータ移⾏ 3. 新世代Controllerから旧世代Computeを制御出来ないがどうするか →互換Agentを開発  世代が新しくなりすぎるとAPI差分が大きい 4. 使っていたAPI VersionがDeleteされたり、オプションパラメータが増えたり減ったりしている・・ →後⽅互換性を提供するGWを開発することで解決
32. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 31 現在、商用で順次アップグレード中 5. 開発完了後の話 順に課題と対策(対応中)を説明していきます
33. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-1. アップグレード手順と所要期間 32 複数世代Skip更改では自動化プログラムを導⼊したが、更改日数は2.5倍。 更改途中に発生する故障サーバ対応は75日（想定外に⻑期化） 日数 実績 日数 計画 複数世代Skipの更改 日数 実績 同世代/N+1世代の更改 # - 6 新世代Controller新設 1 5 1 データベース移⾏（1回目）★ 2 1 自動VM制御停止 1 自動VM制御停止 3 4 4 上位システムとの通信を閉塞★ 2 上位システムとの通信を閉塞 4 互換Agentのインストール★ Controllerのアップグレード 5 新世代Controllerへサービス切り替え★ 6 1 1 上位システムとの通信を開放★ 1 上位システムとの通信を開放 7 自動VM制御再開★ 自動VM制御再開 8 15 7 Computeのローリングアップグレード★ 3 Storageのアップグレード 9 5 5 Storageのアップグレード★ 5 Computeのローリングアップグレード★ 10 30 25 Total 12 Total 75 - 故障サーバ対応（まばらに発生） ★は自動化 計4カ月
34. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 クラスタ 5-2. 故障サーバ対応の発⽣理由と更改停止箇所 33 • クラスタ内に故障サーバが存在すると 更改不可となる箇所が存在する • 更改前、及び更改中に故障サーバは 0台にしないといけない 故障サーバによる 更改停止箇所 複数世代Skipの更改 # 〇 新世代Controller新設 1 - データベース移⾏（1回目） 2 - 自動VM制御停止 3 - 上位システムとの通信を閉塞 4 〇 互換Agentのインストール 5 - 新世代Controllerへサービス切り替え 6 - 上位システムとの通信を開放 7 - 自動VM制御再開 8 〇 Computeのローリングアップグレード 9 〇 Storageのアップグレード 10 Controller Compute HostOS HostOS HostOS 物理 故障 STOP クラスタ内で物理故障サーバが存在すると更改⼯程ストップ
35. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-3. 更改前︓故障サーバ0化計画 34 更改開始に向けて故障サーバが存在していると更改を実施することができない 2カ月前から事前準備として故障サーバの交換を⾏い、更改前には故障サーバ を0台の状態にしている（更改しようと思ったらサーバが故障することも・・・涙） 事前準備 更改 クラスタを更改 Contoller、Compute、Storageの バージョンアップ 計画的に故障交換 クラスタを更改 Controller、Compute、Storageの バージョンアップ 計画的に故障交換 計7クラスタ（871台）を 並⾏で更改 計7クラスタでの故障サーバを0台へ Nカ月 N＋4カ月 N-2カ月 実績として34台の故障対応を実施 ※全体としては75クラスタ。約9000台
36. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-4. 更改中︓故障サーバ対応の流れ 35 更改中にもサーバの故障が発生することはある。その際は更改⼯程を中断し、 故障サーバを①クラスタから取り除く対応、または②故障サーバを交換する対応 が必要になってくる・・・A 更改の自動化プログラムとOpenStack状態をあわせ、⼯程を再開する・・・B クラスタ（更改中） Controller Compute HostOS HostOS HostOS Compute HostOS HostOS 更改後 更改前 対処必要 HostOS HostOS HostOS 物理 故障 HostOS HostOS ①故障サーバの減設 ②新規サーバと交換 故障 新品 日数 項目 75日 故障サーバ対応 40日 故障サーバ減設、交換・・・A 35日 自動化復旧、自動化エラー・・・B
37. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-4. 更改中︓故障サーバ対応の手順・・・A 36 対策② サーバ故障交換 対策① クラスタから減設 • リソース変化なし • リソース減 • 更改中の増設機能は実装無し クラスタリソース （クオリティ） • 物理的なサーバの故障交換が必要 • 1回あたり10営業日 （解析、交換部品確認、作業調整、 現地交換、組み込み、事後作業） • クラスタからの切り離しが必要 • 1回あたり2.5営業日 作業時間 （スピード） • クラスタリソースは減らないが、2週間 更改⼯程が停止 • 即時更改⼯程に復帰できるが、 クラスタリソースが減少 • 使いどころを⾒極める必要がある 総評 早く更改に復帰したいから 対策①を実施したい でもクラスタのリソースが・・・ 増設できれば・・・ 更改⼯程へ迅速に復旧するために、故障サーバを切り離ししたい（対策①） 。 しかし、一度切り離すとリソース増加手段がないため、安易には実施できない 「クラスタのリソース」「更改⼯程の進捗」「作業稼働」を考慮して、都度どちらの 案で対応するかを判断する
38. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-4. 更改中︓故障サーバ対応の改善策・・・A 37 更改⼯程の特定箇所での増設可否の 検証を⾏い、対策①の減設を主として対 応する方針に変更予定 効果︓スピード＆クオリティを向上 故障サーバ 対応要否 複数世代Skipの更改 # 〇 新世代Controller新設 1 - データベース移⾏（1回目） 2 - 自動VM制御停止 3 増設ポイント - 上位システムとの通信を閉塞 4 〇 互換Agentのインストール 5 - 新世代Controllerへサービス切り替え 6 - 上位システムとの通信を開放 7 - 自動VM制御再開 8 増設ポイント 〇 Computeのローリングアップグレード 9 増設ポイント 〇 Storageのアップグレード 10 対策① クラスタから減設 • リソース減 • 更改中の増設機能は実装無し クラスタリソース （クオリティ） • クラスタからの切り離しが必要 • 1回あたり2.5営業日 作業時間 （スピード） • 更改⼯程までではなく増設ポイントま でリソース調整が必要 • 減設のハードルを低減可能 総評 追加 追加 追加
39. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5-5. 更改中︓故障サーバ対応の状態戻し・・・B 38 更改中に故障サーバが発生するとOpenStackと自動化プログラムの状態が不 一致になる。状態を一致させるために、手動での更改や更改情報を自動化プロ グラムに反映する必要がある エラー発生時は手動で正常状態に戻す作業が⼤変。特にナレッジが無い時は 原因解析や対応手法の確⽴に時間がかかる 状態A 状態B 状態C 正常時 故障発⽣時 OpenStack 更改自動化 プログラム A→B B→C 状態A 状態B 状態C OpenStack 更改自動化 プログラム A→B B→C 故障 発生 手動で更改後、内容を 自動化プログラムへ反映 .iniや.yml情報を 更新しなければ︕ コマンドをポチポチ
40. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 5. 商用展開で判明した故障サーバ発⽣における今後の対応 39 複数バージョンアップでオリジナル更改を柔軟性が乏しい自動化していくと・・・  故障サーバ台数を0にしないと更改自動プログラムを実⾏できない 1. 更改開始する前までにクラスタ内の故障サーバ台数を0にする必要がある →2カ月前から計画的に故障サーバ対応を実施 2. 更改中に故障が発生したら、更改を中断して故障対応する必要がある →クラスタからの減設、または故障交換を実施 →工程の特定箇所で増設可否を検証中。今後は減設メインで対応を実施 →故障時に、OpenStackと自動化プログラムの状態合わせを実施（ナレッジをためる）
41. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 まとめ 40 9世代バージョンアップに挑戦︕ 製品未サポートのため、オリジナル手順を開発 ①手順工数増加により、バージョンアップ期間が増加（30日） ②柔軟性弱体化により、故障対応期間が増加（75日） 疑問、複数世代バージョンアップは最適だったのか︖
42. ©2025 DOCOMO, INC. ALL Rights Reserved. /41 議論ポイント 41 OpenStack更改はどのように実施するのがよさそうですか︖ • ローリングアップグレードやBlue/Greenを活⽤し、どれくらいの期間でバージョンアップするのか︖ • ローリングアップグレードする場合、OpenStackはN＋2世代以内でバージョンアップするのか︖ 一気に複数世代のバージョンアップするのか︖ • 故障等の異常・準正常に対して、柔軟に対応可能なアップグレード方式や実装を追い求める 方向性は妥当なのか︖ • OpenStack更改にあたりどのような苦労点があったのか︖ ＃他に将来に向けた課題で気になる点あれば、議論したいです ＜ドコモ側状況＞ • ローリングアップグレード方式で9世代のバージョンアップを実施。 • 新規手順の開発や故障対応での更改期間⻑期化に苦労している