某社のMANO/NFV Orchestratorのベースデザインした話
メリークリスマス
通信業界アドベントカレンダー2021の12/24分のポエムです
もう通信事業者を離れてしまった為、最新の事ではないが、2019年頃に某社のMANOの設計を行った。
その備忘録として、残しておこうと思う。
書けば書くほど、単語の説明をしなければならない事態になってしまったため、各種用語は、適宜ググってほしい。
ここでは、要点となる部分だけ、抑えてほしい。
逆を言えば、この程度の知識であってもベース部分は作れるのだと。
ちなみに、ベース機能のプロトタイプに要した時間はわずか2週間である。
OpenSourceを活用する案もあったのだが、たいてい公開されているOpenSourceは無駄に複雑なことや、メンバーのスキルセットがアーキテクトではなくソフトウェアエンジニアであることを省みて実装する方が理解がすすむ、と考えたためである。
この記事では、大雑把な理解をしてもらうことが目的であり、情報の正確性はそこまで気にしていない。正確な情報を期待する読者にむけては、きっとほかの記事がその助けになるはず。
(と言うか、細かいことは正直覚えてないし、細かいことを知らなくても実装はできるし、秘密保持契約に抵触する可能性とか考えるとポエムが一番良いと思う）
MANOとは？
もはや、MANOと聞いて何か特殊なものかと言われれば、もはやコモディティ化されてしまっている気がするが、通信業界以外の人も見ているため、書いておこう。
誤解を恐れずに言うのであれば、通信事業者向けのクラウド・データセンターの運用システムである。
NFVの方が注目のキーワードであるが、通信事業者が興味が多くあるのは、MANOの方である。
MANOは、Management ANd Orchestrationの略であり、名前の通り管理やオーケストレーションを行うためのアーキテクチャである。
OSS/BSSやNFVIと連携し、5Gのネットワークの構成・運用のためのシステムである。
ref: 第5回 次世代ネットワークの運用管理を実現する技術
と書くと、難しいもののように感じるだろうが、ブレイクダウンしていくと、
Kubernetesや、OpenStack、クラウドのオペレーションシステムの代表であるAWS・GCP、マイクロサービスといったものだと思ってもらえればよい。
クラウドを使ったシステム運用をしている人であれば、想像がつくと思うが、
オートスケーリングや、オートヒーリングをサポートした、Web上から様々なサービスをデプロイができる。
自分たちで作った運用・監視システムと連携して、イベント・アラームを上げて、特殊な動作を行う（例えば、特定のモジュールが故障したので切り離しを行う、ソーシャルゲームのイベントで事前にオートスケールしておく）といったものである。
私とMANO
そもそも、私がMANOと出会ったのは2016年くらいの頃だったと思う。
前前職にて、泣きながらOpenStackの案件を一人でしていた。
仮想ネットワークなどのデバッグなど人に任せながらやるのが困難であったため、
一人でOpenStack環境を構築しながら、まだ見たことのないMANOに対応すると、要求され、MANOに対応するにはと言う事で、ESTIの仕様を読みすすめた。
その期間3か月ほどである。
OpenStackの構築やデバッグには、それより多くの時間を要していた事から、逆にコンセプトの理解だけでいうのであれば、そこまで大変ではない、という印象。
（ただしSpecに合わせて実装するのはひたすら苦痛）
会社は、そもそもOSS/BSSのシステムを取り扱っており、背景情報として、どのようにシステムが成り立っているのか、を知れたことは非常に大きいと思われる。
その他、クラウドやオープンソースなど様々な背景知識も助けてくれたと考えている。
（私の考える）MANOのキーテクノロジー
ずばり、Closed Loop Automationとワークフローエンジン、ルールエンジンの３つである。
この３つのコンセプトがわかっているのであれば、十分に実装が可能だと考えている
Closed Loop Automationは、より最近の潮流に合わせて語るのであれば、Reconcile Loopと言ってもよいと考えている。
MANOの中で管理されたStateと、そのStateの変化を扱うイベントを扱うルールエンジン、そして様々なオペレーションを扱うワークフロー。
この概念が理解できるのであれば、十分に実装が可能と考えている。
MANOの一般的な構成
MANOの詳細を見ていこう。
MANOは、NFV Orchestrator、VNF Manager, VIMの3つから構成されている。
ref: What is the best NFV Orchestration platform? A review of OSM, Open-O, CORD, and Cloudify
VIMとVNF Managerは、OpenStackをイメージしてもらうのが良い。
それぞれ近いものを上げるのだとすると
VNF Managerは、OpenStack Heat
VIMは、OpenStack全体
となる。
OpenStack Heatは、KubernetesのDeploymentのような機能をもっており、AutoHealingや、AutoScaleといった操作が行える（オペレーション的には、十分にみえるが、NW機器を扱うには不十分であるが、ここでは理解が大事なため扱わない）
OpenStackは、まぁご存じの通り仮想マシンや仮想NWを扱うものである。
では、残りのNFV Orchestratorとはなにか？
ここが、ユーザー向けに抽象的なオペレーションを提供する部分である。
運用において、必要な様々なオーケストレーションを行うものである
単体のOpenStackでは閉じない情報・操作を扱うレイヤという味方もあると思う。
クラウド上で様々なシステムの構築を行った人であれば想像はつくと思うが、
クラウドで楽になったとは言え様々な細かいオペレーションがある。
それを自動化するためのレイヤだと思ってくれれば良い。
NFV Orchestratorは何を楽にしてくれるのか？
TerraformやAnsibleのような物を想像してくれれば良いと思う。
なんでも、楽にしてくれる（様に作り上げる）のだ。
何個も何個も環境を立ち上げてくれて、なんでも細かいオペレーションができる（用に作れる）のである。
そういう意味で言えば、Ansible Towerのようなものだと思ってくれれば良い。
代わりにAnsibleのInventoryや、KubernetesのようにJobを実行したり、など、様々な物が規定されている為、これらが組み合わさって使いやすくなった？システムだと思ってくれれば良い。
これが、NetworkSlice等の数多くのデプロイを担当してくれる。
そして、その管理ができるもの、と考えるのが良いだろう。
キーテクノロジー改め
Closed Loop Automation
ざっくりとここまで書いてみたところで、なんとなくのイメージはついたと思われる。
しかし、ソフトウェアは持ってきただけでは動作しない。
幸いにして、そもそもTelecom業界には、KubernetesのReconcileLoopと同様の考え方がもともと存在していたため、この考えに基づいて実装を行った。
数々のネットワーク機器のステートを情報をOrchestrator側に伝搬させる、逆にOSS側で何らかのコンフィグを行い、それをNW機器に伝搬させる。
そういった仕組みがもともと考えられていた。
簡単に図示するのであれば以下
他にもClosed Loop Automation等のキーワードで検索すればイメージがつくだろう。
このくらいの抽象度で見れば、Kubernetes同様にうまく行くことに自信が持てることだろう。
Rule Engine
ルールエンジンについて語ろう
最近IoTの隆盛もあり語るまでもないと感じているが、改めて書き記すのであれば、ルールエンジンそのものが大事なわけではなく、ルールエンジンから様々な情報が参照できること、というのが大事と付け加えておこう。
NW機器は、サーバー単体と異なり、相互作用が大事だと考えている。
具体的には、トラフィックを流した先のサーバーがSaturationし(サチっ)ていたり、そもそも前段のNWがNW断になっているため、トラフィックが流れてこない、など条件が複雑になりがちである。
こういった情報を以下にルールエンジンに渡してくるか？が鍵になっていると考えている。
そのためには、以下にデバイスの情報をサーバー側に反映させるか？と言ったアーキテクチャが重要になってくる。
そのために必要なたくさんのコンポーネントに対し、必要な情報が含まれている、と言った印象だ。
ワークフローエンジン
システムの内部構造に自信が持てたところで、次に大事なのはそのシステムとどうインタラクションするか？ということである。
必要なオペレーションの数だけ、UIを作ってAPIを叩きまくるのも良いですが、叩くAPIの数が多くなりすぎるので、BFFやGatewayパターンのように一度データ入力と受け取りを抽象化するレイヤを挟んだほうがうまく行くと考えている。
また、この受け取ったリクエストを複数のバックエンドと代理でやり取りするためのがワークフローエンジンであり、オーケストレーションレイヤだ。
Aの次にBを実行して、BがCになるのを待ち、Dを並列実行する。こういった具合に裏側のシステムと連携する事で動作する。と言った具合だ。
こういったキーテクノロジーの組み合わせを持って、標準化された様々なインターフェースを持つコンポーネントのAPIを実行することでシステムが成り立っている。
改めて振り返ってみて
ネット上で様々な事が書かれているが、VNFカタログなど汎用的なマーケットプレイスから様々なVNFがインスタンシエーションできて、オペレーションできる、見たいなイメージが語られているが、世間の人がそんなものに注目するか？と言えばNoであるように、MANOであっても同様にそのような機能が求められているか、といえばNoだと思っている。
CloudFoundryがもてはやされているか？といえば、実はそうでもないと思っている。（Cloud Foundryさんごめんなさい）
と言う事もあって、今のところカタログなんかの機能はまぁ優先度が低い、と考えている。
なので、力業であっても、オペレーターに対して抽象的なオペレーションが提供できればよい、と、当初考えていた。（今も一緒だが）
その他、ここでは書かかなかったが、マルチデータセンターに対応したり、色々短期間のうちに対応し、有意義な経験であった。
その後どうなったか？
開発が私の手を離れて、ベンダーの手に渡ってしまったのでどうなったのかはわからない。
超少人数で開発していたものを、数百人のベンダーに渡して彼らが頑張って解析をして、開発を続けているのだろう。
もし、私たちがベースをつくらなかったら、ベンダーに高いライセンス費を要求されて、それを支払っていた事だろう。
その方向性を変えるだけの働きはしたと自負しているが、ベンダーに渡してやらせるのであれば、最初からオープンソースを活用するアプローチをしていたらどうなったのか、など後悔は多く残る。
一方でメンバーたちも、ベンダーの言うよくわからない説明に対して耐性がつき、自信をもって働いてくれるのが非常に良かった。
もっと、VNFFG（VNF Forwarding Graph)といったNWの抽象化や、p4といったSDNライクな事に踏み込んでいきたかったが、事業者的にはそこはまずは重要ではない、という雰囲気があったため、燃え尽きた。
5GCになって、BGP FlowSpecみたいな仕組みも入っていってるので、テレコムのノードと、
NW一般の技術の融合が進んでいった、という話も聞いていて、楽しそうな世界だな。
と思っていたが、周りにそういうことに興味のある人が居ないので楽しくなかった。
技術者が楽しめる会社を作っていこうと頑張っていたが、そもそも会社のフェーズとしてなんとかシステムを実現しよう、それさえすればなんとかなる、と言う空気が好きではなかったので辞めた。
今はエッヂ方面の事業開発に携わっているが、これまで得た知識が役に立っているが、少し物足りない。
更にどこかチャレンジングな仕事はないだろうか？
Discussion