KDDI固定電話ネットワーク、NFV化の5年間の道のり のメモ
はじめに
KDDIさんがJANOG49で仮想化を振り返る内容のセッションを行っていたのを見つけ、紹介しようと考えていたところ、7/2の未明から、au網にて大障害が発生している模様です。これを書いている7/2の22時現在ではまだ復旧しておらず、かつてない規模の障害となってしまいました。
事故の詳細や対処内容など、今後明らかになり次第、noteにてメモをアップ予定ですが、ここでは、そこと直接関係していない固定網の仮想化がどのように行われたのか、公開されている情報にて振り返っておきたいと思います。
なお、資料では、あくまで担当者の個人的な見解であると注釈がついておりました。
KDDIさんの仮想化の概要
仮想化の背景
KDDIさんの発表によると、1200万超の加入者を擁するIP電話サービスを、aTCAという専用設備で構築していたところ、保守期限を迎えることになり、2016年からNFVでの検討を開始し、2021年10月にNFVに移行させたとのことです。
KDDIさんのNFVは、ETSIなどで定義されているとおりに、以下のような構成になっているようです。
仮想化構成
仮想化の振り返り
そこでいきなり仮想化を総括されていますが、移行は成功し、運用を自動化できた、という反面、本来の意味での仮想化に至らなかったとされています。本来の意味の仮想化とはどのようなものなのでしょうか？
仮想化コレジャナイ
本来の仮想化とならなかった要因として、以下を挙げられています。
結局、機能をそのままにマイグレさせようとすると、特殊要件化、魔改造された専用基盤になってしまい、共通基盤とはかけ離れたものが出来上がってしまったようですorz。
仮想化の目的
仮想化の共通基盤を作る壮大な構想があったものの、難しいことが分かり、目的を以下の通りに設定されたとあります。
仮想化の壁
楽天がモバイル事業に参入したあたりをピークでしたが、インフラは仮想化すればすべてが解決みたいな風潮がありました。しかし、仮想化しても仮想化レイヤという新たなオーバーヘッドができ、ソフトウェアの管理コストもばかにならないようです。楽天さんの大赤字もこのあたりから来ているのでは、と邪推されます。
最終的には、仮想化プロジェクトとしては、品質を重視して安全に倒した、ということでした。
自動化できることできないこと
仮想化のもう一つの目玉の自動化についてですが、どうやら仮想化しても、OpenStackの制御とインスタンス立上げはできるものの、運用の自動化はからきし、ってところがあるようです。標準化機関やベンダなどの誇大広告に踊らされた世界中のプロバイダは、このあたりどのように解決されているのでしょうか。楽天さんなんかの事例も気になります。
結果こうなりました
結局はAnsibleが仮想化ファンクションの間に入って大活躍しているようです。IaCではあるものの、カスタムメイドになるので、柔軟性が持てないように思えます。
仮想化マイグレーション
最終的には、だいたいうまくいったとのことです。JANOGセッション限りの情報もあったようで内容が気になります。VLANを延伸し、加入者情報をコピーした上で、閉塞GARP切替え、というところで何か起きたのでしょうか。。
ともあれば無事に移行完了し、お疲れさまでした。
最後に
なかなかのボリュームの資料で読むのが大変でしたが、率直な感想としては、大手のKDDIさんには優秀な人材がいるんだな、というところです。
社員3名程度での運用を内製化をしたようですが、今までハードウェア追加作業、ベンダ設計、作業等、 3カ月以上かかっていた作業が、一週間程度で完了するようになったとのことです。これは、仮想化でなければ成し遂げられなかったのではないでしょうか。
まだ障害が発生中のモバイル網でも、原因究明し、レジリエンスなNWにしていただければと思います。
この記事が気に入ったらサポートをしてみませんか？