第 6 章 5G 時代に考える エンドツーエンド オートメーション (2)
はじめに
前回は 5G に向けてのインフラ アーキテクチャの変革トレンドをおさらいし、運用上の課題と、その解決には自動化が必要であることを見てきました。第 2 回では、5G で求められるエンド ツー エンド オーケストレーションの視点から、その技術的要件やメリットについて考察します。
なお、本章ではオートメーション、自動化、オーケストレーションの用語を同じ意味で用いています。
6-4 エンドツーエンド での オーケストレーションへ
第 5 章（ネットワーク スライシング）で触れたように、エンドツーエンド スライシングは、ネットワークの各ドメイン （RAN、トランスポート、DC ファブリック、モバイルコア）ごとに配置されたドメイン コントローラと、中央に配置されたエンドツーエンド オーケストレータが連携しながらプロビジョニングおよび運用・監視を行うことが想定されています。
ところが、通信事業者のすべてのネットワーク ドメインに一斉に自動化を導入できるかというと、実際には困難と言えるでしょう。そもそもドメインごとに対象となるテクノロジーが大きく異なります。また、ドメインごとに開発・運用・建設といった役割が分かれているという組織上の課題も挙げられます。他方、ドメインを分割しておくことで影響の局所化が可能であったり、ビジネスの動向に合わせて投資メリットのあるドメインから徐々に自動化を実装するスモールスタートが可能といった利点もあります。
そこで、まずは各ドメインごとに自動化のクローズド ループの実現に取り組み、クロス ドメインのオーケストレーションを行う仕組みをその上に重ねるという階層的オーケストレーションが、現実的なアプローチと考えられています。これを表したのが図 6-3 です。
図 6-3 5G における エンドツーエンド オーケストレーション
ここで大事なことは、各ドメイン内の自動化にあたっても、ゴールであるエンドツーエンド オーケストレーションを見据えた設計を採用することです。それぞれのドメインが自由に自動化を設計してしまうと、ドメイン間の連携時に多大な開発コストがかかるおそれがあります。そこで、各ネットワーク ドメイン内でそれぞれ完結したクローズド ループを構築しつつも、各ドメインのオーケストレータが外部向けには抽象化したサービス モデルを提供することが重要です。これにより、ドメイン間を疎結合の API で相互連携させることが可能になります。
こうしたネットワーク ドメインの抽象化の考え方は、近年、IETF[5] や OpenConfig[6] などの標準化団体で積極的に議論され、具体的な標準モデルの策定が行われています。ここで登場したネットワークの「抽象化」と「モデル化」という考え方は大変重要ですが、長くなるため Appendix-A にて説明します。
図 6-4 に、モデル駆動形のオーケストレーションの概念図を示しました。
図 6-4 モデル駆動形オーケストレータと階層化アーキテクチャ
モデル化の考え方をもとにした自動化の考え方を「モデル駆動形」「モデル ベース」などと呼んでいます。モデル化のメリットとしては次が挙げられます。
- 外部連携のための API が標準的なモデル言語（YANG 言語）で定義されることで、システム間連携のためのインターフェイスを明確化し、個別開発することに伴うインテグレーションの労力を削減可能
- モデルが同じならば、ソフトウェア アップグレードなどで内部の構成が変わっても外部には影響を与えないため、システムの疎結合性・メンテナンス性が向上する
- 下位のオーケストレータのサービス モデルを上位のオーケストレータが取り込むことが容易なため、オーケストレータの階層化によりクロス ドメインの自動化を実現するのに適している
これらのポイントは、いずれもエンドツーエンド オーケストレーションを構築するうえで重要と言えます。ドメインごとの自動化を検討する場合、オーケストレータにモデル ベースのものを採用することで、エンドツーエンドの自動化にも容易に対応できます。スモール スタートが可能で、かつエンドツーエンドを見据えたアーキテクチャとして、モデル ベースの自動化は有力な選択肢と言えるでしょう。
6-5 まとめ: エンドツーエンドでの自動化がもたらすメリット
本章では、5G のシステム アーキテクチャ変革から、ネットワーク自動化の必要性と、自動化にあたって必要なソフトウェア スタック、そして重要な抽象化とモデル化の考え方について述べてきました。
もしかしたら、自動化は必要となるコンポーネントも考慮すべき要件も多く、大変な取り組みになると感じられたかもしれません。そこで、こうした自動化の取り組みには、労力とコストに見合う価値があるかどうかを最後に考えてみましょう。
エンドツーエンドでのネットワーク自動化が実現したあかつきには、通信事業者に次のようなメリットをもたらすと考えられます。
- APIが各レイヤ・各ドメインでオープンになることにより：
- プログラム的な手法による運用の進化、APIの公開による柔軟な新サービスが創出できる可能性 (NaaS; Network as a Service)
- API 連携の企業ユースケースの発掘により新たな収益源を創出できる可能性
- 最先端のアプリケーション開発・運用手法を取り込むことにより：
- CI/CD (Continuous Integration/Continuous Deployment) の手法、デプロイ自動化ツール群の取り入れによる開発・運用の進化、進化したソフトウェア テスト手法の採用による省人化・品質向上および信頼性向上
- 生産性の向上、技術部門の働き方改革を実現
- 大量のデータの分析により：
- ML/AI 手法を用いた分析により経験知や人手に頼らない分析と運用が可能に
- ソフトウェア スキルの活用により:
- ネットワーク業界においてもソフトウェア スキルで可能な開発やオペレーションが増加し、高度な IT 人材をひきつけることで企業および業界全体の価値の向上、さらなる投資やブレークスルーへの期待
これらは想像できる多くのメリットの一部にすぎませんが、このような理想となるアーキテクチャや自動化の姿をネットワーク業界全体で共有してオープンに議論することが求められているとは言えないでしょうか。
昨今、通信業界では、ユーザが低コスト・高品質・迅速なサービスを求め、競合が次々と参入する厳しいビジネス環境が続いています。そうした中で、本章で議論したような 5G によるシステム アーキテクチャの変革に伴う自動化の実現が必要になる日は、すでに訪れています。本章の内容が皆様の取り組みの一助になれば幸いです。
Appendix A: ネットワークの抽象化とモデル化
抽象化とは、あるドメインを外から見たときに、ドメイン内部の不要な情報がきちんと隠蔽され、必要な情報にアクセスするインターフェイス（API; Application Programming Interface） のみが公開されていることを意味します。これは、ドメインが独立して正常に動作することを担保し、外部からドメインに対する不当な変更や情報取得を防ぐために重要な考え方です。
一方で、モデル化とは、対象が持つ機能をわかりやすい設計図にすることを意味します。身近な喩えとして車のプラモデルを考えてみてください。本物の車が持つ細かい性質、たとえばエンジンの内部構造や配線等は捨象して、特徴がわかるような外見や骨格、色合い等を取り出したものになっています。それと同じように、ネットワーク ドメインでは物理配線や機器の種別、ルーティングのパラメータなどの細かい部分は無視し、外から見て意味がある情報（顧客識別 ID や拠点のネットワーク情報、SLA など）を切り出すことを指します。
モデル化には、モデルを記述するための適切な言語が必要です。モデル化のための言語として IETF で定義されたのが YANG [7]（RFC 7950）です。
モデルは、抽象化する対象に応じて ○○ モデルという形で呼ばれます。
サービス モデルという場合、たとえば VPN サービスのように外部の法人顧客から見たときに、意味がある情報を記述することになります。物理配線や機器の種別、ルーティングの内部パラメータは、法人顧客にとっては意味がないので捨象されます。一方、顧客識別 ID や拠点のネットワーク情報は重要なのでサービス モデルに含まれ、外部からのプロビジョニング対象として公開されることになります。
デバイス モデルという言葉もあります。これはネットワーク デバイスの OS 設定項目を構造化・パラメータ化したものです。たとえばルータで BGP を設定するコマンドは、OS によって、
router bgp 65000
だったり、ブラケット付きの
｛ routing { protocol bgp { as-number id 65000 } } ｝
だったりと違いがあります。デバイス モデルは、こうした文法上の構造の違いも含めて、そのデバイスの設定情報を構造化された形で記述したものと言うことができます。一方で、上記のような文法の違いは、ユーザからしてみれば意味のある違いではありません。そこで、サービス モデルでは設定として重要な情報である “bgp” と “65000” のみをパラメータとし、デバイス モデルの差分は自動的に吸収・変換されるような仕組みがモデル ベースのオーケストレータには実装されています。
参考文献
[5] IETF https://www.ietf.org/
[6] OpenConfig http://openconfig.net/
[7] RFC7950 The YANG 1.1 Data Modeling Language https://tools.ietf.org/html/rfc7950
用語集
OpenConfig: ベンダ非依存なネットワーク管理手法を志向しテレメトリを始めとするさまざまな手法やモデルを定義するワーキンググループ
CI/CD: Continuous Integration/Continuous Deployment. 継続的なソフトウェアの開発とデプロイメントのサイクル
ML/AI: Machinie Learning/Artificial Intelligence. 機械学習とそれを利用して自動的な判断・処理を行う人工知能に相当する機能を指す
Authors