NICの研究開発

MANO基盤の開発

NIC　ネットワーク制御ソフトウェアプロジェクト

松井　裕太郎（まつい　ゆうたろう）

#MANO#コンテナ基盤

2026/4/23

はじめに

以前の記事にて、ネットワーク制御ソフトウェアプロジェクトで「仮想化制御機能部（MANO^[1]機能）」（以降、MANOと記載します）の開発についてご紹介しました。本開発では、MANOの主要部分である、仮想化基盤のリソース制御や仮想化されたネットワーク機能のライフサイクル制御（以降、MANOオペレーションと記載します）を担う各種機能部をコンテナ化されたアプリケーションとして開発しています。よって、MANOを動作させるためには、それらのコンテナ（以降、MANOアプリコンテナと記載します）を実行するコンテナ基盤が必要となります。本記事では、このコンテナ基盤の開発や、私たちの開発しているコンテナ基盤の概要についてご紹介します。

MANO基盤について

本開発では、MANOアプリコンテナが動作するために共通的に必要となる機能を、コンテナ基盤と併せてMANO基盤として開発します。私たちのMANOは商用サービスで利用することを想定して開発しており、例えば以下のような機能が必要となります。

MANOアプリコンテナは、その制御する対象の状態をデータとして保持しておくためにDB（データベース）を利用しますし、そのDBはデータを保存しておくためのPV（永続ボリューム）を必要とします。DBのデータ消失は許されず、データがバックアップ可能である必要もあります

商用ではセキュアな運用が求められます。それは許可された端末や外部システムのみをMANOへアクセス可能とするために証明書を管理・適用したり、各ユーザや部署毎の操作権限を管理したりする機能によって実現されます

商用サービスで運用するためには、MANOアプリコンテナやコンテナ基盤から出るログの確認や、システムの状態を監視し、故障等を検知できるような仕組みも必要となります

MANO基盤の役割は、そういったMANOアプリコンテナをデプロイし運用するための機能、および保守者によるログ・システム状態監視の仕組みを提供することです。
NICで開発しているMANOの全体像およびMANO基盤の構成を示すと下図のようになります。

MANO基盤は、Kubernetesベースのコンテナ実行環境に、MANOアプリコンテナの動作やシステム運用に必要な各種機能をデプロイすることで構築されます。デプロイされる機能には以下のようなものがあります。

ストレージ利用機能: DB等でPVの利用が必要となるため、コンテナが利用するPVのバックエンドとして外部ストレージを利用できるようにします

オブジェクトストレージ: MANOアプリコンテナのログやDBのバックアップデータ等、大量かつ巨大なデータを効率的に保存および利用するため、導入しています

コンテナレジストリ: インターネットに接続できない環境でも必要なコンテナをデプロイできるようにするため、コンテナイメージを格納しておくレジストリを準備します

証明書管理: MANO内の各HTTPSエンドポイントに適用する証明書を配布および自動更新する機能を導入し、MANOの初期構築時や運用中の保守コストを削減します

認証・認可: MANOオペレーションで利用・生成される情報の閲覧やMANOオペレーションの実行の権限を利用者毎に制御・管理します

DBaaS: MANOアプリコンテナはその動作にDBクラスタを必要とするため、MANO基盤内でDBクラスタを利用可能とするサービスを提供します

ロギング: 不正行為の証拠保全や不具合事象の解析等に利用できるようにするため、MANO基盤やMANOアプリコンテナにて出力されたログを収集・保存し、閲覧する機能を具備します

監視: MANOの全体や機能部毎の故障・不具合を検知するための監視機能を具備します

MANO基盤開発について

開発業務について

MANO基盤開発のミッションは、MANOのシステム要件や事業会社の要件を満たす、MANOアプリコンテナ実行環境を提供することです。コンテナ実行環境やMANO基盤に必要な各種機能を実現するソフトウェアは、市中製品やOSSが存在しており、それらの組み合わせで私たちの求める基盤は実現可能です。そのため、開発規模・コストや開発期間も鑑み、MANO基盤はゼロベースでの開発ではなく、それらを利用して開発しています。このような開発においては、MANO基盤を構成する機能部の構築手順の確立や動作確認検証が業務の多くを占めます。特に、市中製品やOSSは設定方法や依存関係が環境によって異なり、MANO基盤が求める環境へそのまま適用できるとは限りません。したがって、製品やOSSの公式マニュアルに基づきながら、MANO基盤向けの正しい構築手順を整理することや、採用する複数の製品・OSSの組み合わせ・相互作用によって実際にMANO基盤が求める期待動作ができるかどうかの検証が必要となります。
具体的に手順の確立・動作確認検証を行う対象としては、

コンテナ実行環境の構築や各種機能のデプロイ手順

MANOアプリコンテナが利用する機能の利用手順(DBaaSを利用したDBクラスタの構築手順等)

ログ閲覧・システム監視手順

MANO基盤の障害復旧手順

等が挙げられます。また、それらの組み合わせにより

MANOオペレーションが不足なく動作できるか

保守運用に必要なログの取得・閲覧や監視が不足なく実現できるか

その他、要求仕様に基づく要件を満たせているか

をMANOアプリコンテナの開発者とも連携しながら確認します。
ただし、それらの組み合わせだけでは全ての要件を満たせませんので、そういった要件を満たすためのMANO基盤独自の開発も必要となります。

MANO基盤に込められた工夫

ここでは、各要件を満たしたり、発生する運用課題へ対処したりするためにMANO基盤開発チームが独自に開発した工夫ポイントを例示します。

開発①コンテナ障害自動復旧

要件や運用課題: 単一機能故障時は自動復旧が求められるが、一部の機能は、ノード故障やネットワーク断等に起因するコンテナ障害発生時に自動で復旧されない

Kubernetesベースのコンテナ実行環境は自動修復機能を兼ね備えており、ノード不接等によりコンテナやそれを動かしているPodが故障した際には、自動的にそれらの再起動や正常なノードへの退避等（まとめてフェイルオーバーと記載します）を行って可用性を確保します。しかし、一部機能のPodについてはフェイルオーバーが自動で行われず、機能の性能劣化や動作停止を引き起こしてしまいます^[2]。具体的にはDBクラスタや監視機能が該当しており、DBクラスタ故障はMANOオペレーションそのものに影響を与えること、監視機能はそれ自体が故障しても監視画面を見ている保守者にはそれが分からず故障を検知できないこと等、クリティカルな影響をこの問題は及ぼしていました。

この問題に対処するため多方面から検討を行った結果、MANO基盤開発チームでは「障害ノードに載っている障害Podを検知して自動削除し、フェイルオーバーを促す仕組み」を開発することで、この問題を解決に導きました。
この問題は既知であり、Kubernetesコミュニティ等でソリューションが提案されています。そのソリューションは例えばコンテナ基盤に新たなOperatorを導入することですが、Operatorの導入にはMANO基盤の設計や試験の見直し、影響範囲の再調査が必要となります。我々の開発した仕組みは一定時間毎に数行のスクリプトを走らせるだけであり、コンピュートリソースの消費が軽微であることや、この仕組みを導入しても定常的な背景負荷を発生させないことといった利点があり、MANO基盤に適した開発であると考えています。

開発②PVデータ削除済領域解放

要件や運用課題: PVのドライブ上の使用領域が単調増加し続け、最終的に設定した容量上限に達してデータが書き込めなくなる

MANO基盤では、外部ストレージをシンプロビジョニングしてPV用途に利用しています。通常、ストレージ上でデータを削除するとそのデータサイズ分の空き容量が増え、他のデータを書き込めるようになります。しかし、シンプロビジョニングされたストレージでは以下のような挙動となります。

ストレージを利用しているコンテナ側でファイルを削除しても、それをストレージ側では検知せず、ディスク領域使用中と認識し続ける

コンテナ側のファイルシステムは、データ削除によって空いた領域を新規データ書込に再利用せず、別の未使用領域に書き込んでしまう^[3]

結果として、コンテナ側ではPV容量を使い切らないような実装（ログローテーション等）がされていても、ストレージ側ではディスク領域を消費し続け、いずれはディスクフルとなってPVへのデータ書込ができなくなってしまいます。
この問題の解決にはspace reclamation（空き領域回収）が必要となります。これは、ファイルシステムにて不要になった領域をストレージに返却し、ストレージ側でその領域を回収する仕組みです。これによってPod内で再利用されない領域を抱え続けることがなくなり、またストレージ側でも回収されたディスク領域分、PVの使用量が下がったと認識することができます。

MANO基盤開発においては、このspace reclamationを、Kubernetesを構成するノード上でPVの実体に対してMANOオペレーションの閑散時間帯に実行するというアプローチをベースに機能を開発し、この問題を解決しました。
このspace reclamationが必要となる問題自体も既知であり、様々なアプローチが提案されています。例えば、PVの構成設定でspace reclamationが自動・即時に行われるファイルシステムを採用したり、space reclamationを実行するKubernetesのカスタムリソースを適用したりすることが挙げられます。しかし、前者ではIO性能への影響が懸念される^[4]、後者は利用するストレージ製品に依存性がある、といった制約があり、それらと比較すると本開発のアプローチは製品を選ばず、MANOオペレーションへの性能影響を最小限に収めているという点で優位な実装であると考えています。

MANO基盤開発チームについて

以前の記事で紹介している通り、MANOの開発はその工程において複数のサブシステム単位のチームを編成しています。MANO基盤については、それ自体を一つのサブシステムとし、一つの開発チーム(MANO基盤開発チーム)で開発を行っています。
「MANO基盤開発」の章に記載した通り、MANO基盤を構成する機能は多種多様です。それを一つの開発チームで開発していくことから、MANO基盤開発チームでは技術ドメインベースでさらに小さな(2～4名程度の)グループ分けを行っています。例えば

ロギングと監視はいずれも保守運用に関わる機能なので一つのドメインに集約する

認証・認可機能はDBクラスタを利用するため、DBaaSと同じ担当者が開発業務を行う

といったグループ分けです。このグループ分けにより、以下のようなメリットを得ることができ、開発品質の向上に役立っています。

グループのメンバが継続して同じ技術ドメインの開発業務を行うことで、開発が効率化されるとともに、深い開発ナレッジを開発チームに蓄積できる

複数人が同じドメインの開発を担当しナレッジを共通して持てることで、多少のメンバ入替や欠員が発生しても業務を滞らせない

また、新規にプロジェクトへ参加したチームメンバに関しては、いくつかの開発をグループの有識者とペアプログラミングによって進めることで、開発業務の理解や実務知識の習得等の早期実現を図っています。

おわりに

本記事では、MANOアプリコンテナを実行するMANO基盤の概要と、MANO基盤開発チームが進めている開発内容についてご紹介しました。本記事を通じて、MANOのような大規模システムにおける基盤部分の開発やNICで取り組んでいるプロダクト開発について、興味を持っていただけましたら幸いです。
また、開発対象のMANOの詳細な技術については、技術ジャーナルの記事もご覧ください^[5]。

脚注（用語解説）

[1] Management and Orchestration：ネットワーク仮想化において、ネットワークサービスやリソースを統合的に管理・制御・最適化する機能

[2] KubernetesにおけるStatefulSetや、同様にステートフルな管理が要求される一部のカスタムリソースがこのような挙動となる

[3] MANO基盤におけるStorageClassで指定しているext4やxfsの挙動によるもの。データ削除によって生まれた断片化された領域ではなく、連続した新しい領域へ優先してデータ書込を行う。通常のストレージであれば、そのような断片化はデフラグを行って解消するが、シンプロビジョニング環境でデフラグを行うと、データの再配置によって確保済領域外の未割り当てブロックを確保・消費してしまい、「必要な分だけストレージを使う」というメリットを得られない。また、ストレージへのIO増加によるパフォーマンス劣化を引き起こす可能性があることからデフラグは推奨されない

[4] space reclamation自体はストレージに対する比較的重めの処理であり、MANO基盤にて閑散時間帯に実行するようにしたのもそのため

参考文献

[5] 無線アクセスネットワーク（RAN）運用管理のインテリジェント化を実現するコグニティブ・ファウンデーション（CF）連携基盤技術