サービスプロバイダー

5G－シスコが考えるサービスプロバイダー E2E アーキテクチャ第6章 5G 時代に考えるエンドツーエンドオートメーション（2）

佐々木俊輔
2020年1月23日

第 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” のみをパラメータとし、デバイスモデルの差分は自動的に吸収・変換されるような仕組みがモデルベースのオーケストレータには実装されています。

←「はじめに」へ戻る

第 6 章（1）へ

第 6 章（2）トップへ