Jun 23, 2020

インテント型ネットワーキングの分類

カスタマやパートナーだけでなく、最近では投資家達までもが「各社のインテント型ネットワーキング(IBN)はどこがどう違うのか?」という疑問を抱えています。そして私が耳にする答えの多くは、主観的で説明的、またいかようにでも解釈できるものばかりです。しかし本当に求められているのは、IBNソリューションの成熟度を見極めることができる、具体的で事実に基づいた分類法なのです。この分類法を使うことで、レベル0(成熟度が低い/未完成)から要件に完全適合したIBNソリューションであるレベル3(成熟度が高い/完成)までの成熟度レベルにIBNソリューションをマッピングすることができます。

アプストラ社は2016年6月にインテント型ネットワーキング(Intent-base Networking)と自律運用型ネットワーク(Self-Operating Networks™)というコンセプトを打ち出しました。そして様々なIBNシステム構築の成熟度レベルを分類することで、ネットワーク運用担当者が誇張されたマーケティングに惑わされることなく、適切な購入判断ができるようになることを目的として、弊社ブログにてIBNの定義と各レベルでIBNシステムが提供する機能を全て網羅したリストを掲載いたしました。

レベル0の IBN: 基本的な自動化

IBNが成熟するにつれて、当初のシステムには必須機能全てが実装されていなかったということがわかってくることもあります。レベル0システムに含まれているべき機能は:

  • 宣言型の仕様をもとに、例えばアンシブルモジュールを実行するスクリプトやNAPALMのような宣言型ライブラリーとして装置のコンフィギュレーション設定が作成できる。
  • 異機種混在(ヘテロ)なインフラに対応できる。
  • プロトコルや伝送系に拘わらずネットワーク状態をリアルタイムに取り込むことができる。

レベル0に欠けておりレベル1に上がるために必要な機能は、意図とネットワークの運用状態の両方を格納している「信頼できる唯一の情報源(SSoT)」です。意図が正しく実現されているか否かが確認できることは鍵となる主要な要件であり、IBN構築の成熟度を測る基本要素の一つです。今日のIBNベンダーの大半がまだレベル0にとどまっています。

レベル1の IBN: 信頼できる唯一の情報源(SSoT)

レベル1に分類されるシステムには、意図とネットワークの運用状態を格納しているSSoT(信頼できる唯一の情報源)が実装されていなければなりません。これは、設計、構築、展開、検証と言ったネットワークサービスライフサイクルの全ての側面に関するデータと状態を持っているデータベースです。このSSoTには意図とネットワーク運用状態のコンテキスト等の両方が潤沢なデータとして揃っていることが非常に重要です。そもそも意図が保存されていなければ、ビジネス要件(意図)が実現されているか否かを判断することは不可能だからこそ、この分類定義は重要なのです。.また、コンテキストがわからなければ、ネットワーク障害がビジネスゴールに与える影響を把握することができません。 そしてビジネスルールの変更の妥当性(例えば、この変更を実装しても既存のビジネスゴールやサービスに影響が出ないか)も判断できないでしょう。状態は、例えていえば、指揮者も見ている(意図)と同時に他の演奏者の音も聞いている(運用状態)ことによってはじめて自分の楽器にもっとも適切な演奏ができるというオーケストラの演奏のようなものです。

SSoTが実装されているかはどうやって検証しますか? これは比較的簡単です―その答えを得るためのクエリをSSoTに投げるAPIがあれば良いのです。言い換えれば、そのAPIで 例えば「ペプシのトラフィック用の全回線の稼働率はどれだけか?」や「もし回線Xがダウンしたり輻輳したりした場合、どのカスタマに影響が出るか?」というクエリに回答できるかを確認すれば良いのです。

もしSSoTが無かったら、どのようにしてこのようなクエリが出せるでしょうか?おそらく下記の手順を踏むことになるのでしょうね。

  1. ネットワークマップを確認する:
    1. そのマップが物理的に現在のネットワークの状態を反映しているかを確認する。
    2. 全回線の運用状態を確認する。
  2. テナントのコンフィギュレーションを確認する:
    1. エンドポイントはどこにあるのか
    2. ステップ1のネットワークマップにエンドポイントをオーバーレイする。
  3. 全データを収集する:
    1. ステップ1とステップ2を実施し、必要なカウンター全てに対してNMSを確認する。
    2. 回線障害によるトラフィックの経路変更の影響を手計算する。

そして、自分自身で情報を集計する、もしくはスクリプトを書く、もしくはコンサルタントを雇って点を繋いで線にしてもらうわけです。もし、自分自身で情報を連携させる必要がある場合には、そのシステムはレベル0のシステムだということになります。上記のクエリの回答を出すのはIBNの仕事です。しかもこれは次の成熟度レベルに進むための基礎を築く機能なのです。

 もしSSoTが実装されていなかったら、他にできないことは何があるでしょうか? 障害解析が必要な事態が発生しても、ネットワークエンジニアがIBNソリューションに適切なクエリを掛けられず、自分達で問題を掘り下げ解析しなければならないという事態が発生します。このような解析作業は往々にして、手作業で反復性の高い単純作業であることが多く、時間(やコスト)がかかるのみならず、解析者の不満の原因にもなります。運用状態だけ情報があっても意図がわからなければ、何が正しく何が間違っているのか判断できません。たとえインターフェイスが「ダウン」していたとしても、そもそもそこにケーブル接続する意図がなければ、ダウンしていても全く問題ないかも知れないのです。逆に、インターフェイスが「アップ」になっているという状態は、ハッカーがネットワークに侵入してきたことを意味しているかも知れないのです。このような単純な例でさえ、何が正しく何が間違っているか、どうしたら判断できますか?装置のコンフィギュレーションを確認すれば良いと思ったかも知れませんが、もし誰かが誤った情報を設定してしまっていたとしたらどうしますか?コントロールプレーンのプロトコルにしても不具合やバグがあればいつもアテにできるとは限りません。今の装置の状態は必ずしもその装置のあるべき状態を表しているとは限らないのです。

AOS® は、後付けではなく、開発当初からデータ中心かつSSoTをその基本原則として構築されてきました。メッセージバスとの統合ではメッセージ中心に過ぎず、データ中心とは言えないのです。

レベル1を一言で言うと、意図と運用状態を連携させるSSoTが存在しており、意図が正しく実現されているかが確認できるというレベルです。即ちSSoT無しにはそのソリューションはIBNとは程遠いとも言えます。

レベル1はそのインフラと意図の実現状態を確認するクエリに回答できるレベルだと言い換えることもできます。そして次のレベル2は、ネットワークエンジニアや運用者の代わりに、IBN自身が適切なタイミングで適切なクエリを投げてくれるようになるというレベルです。

Level 2 のIBN:リアルタイムでの変更確認

レベル2の重要機能:意図が正しく実現されているかをリアルタイムで確認する。

変更は不可避なものであり、変更をどう処理するかこそがIBNの神髄とも言える役割です。変更によっては、 ビジネスルールやポリシー変更という形で運用側から上がってくる意図的なものもあるでしょう。けれども、それよりもさらに対応が難しいのは、運用状態の変更や障害という形で発生するインフラ側から上がってくる変更です。(しかもこれらは運用者がコントロールできない性格の変更です。)もし何かが故障しても、確認クエリが出せなければ、その障害を検知することは難しいでしょう。

.監視対象にしているイベントが発生した時に通知を受け取るようなサブスクリプションが設定されていれば、リアルタイムでこの通知を受け取ることができます。これがリアルタイム性の一つです。一定の間隔でスケジュール化されたバッチ処理を実行しているIBNシステムはリアルタイムではありません。内容によってはバッチ処理が適しているものもありますが、バッチ処理では全く役に立たないという場合もあります。

問題が発生している領域を対応可能なサイズに分割することで、複雑な環境でも拡張性が出せるようにする仕組みがサブスクリプションです。一つ一つの変更を全員に通知する必要はありません。固有の動作はそれ自身のモジュールとして実装し、その動作に関連するイベントの分だけサブスクライブすれば良いのです。

リアルタイム性がこの要件の中核ではありますが、確認機能がどのように実装されているかという点において、「プログラム化された確認」も忘れてはなりません。検証という観点から、例を使いながらこのコンセプトを紹介していきましょう。

まず、「テナントもしくはセキュリティーゾーンを一つ追加する」というビジネスルールがIBNシステムに提出されたという例を考えてみましょう。実際に変更する前に、IBNシステムは下記のクエリを発出します。

  • この要求は既存のポリシーに違反するか?
  • (IPやVNI等)どのようなリソースが使われるか?

別な例を考えてみましょう。運用担当者がリーフスイッチを1台保守モードに変更するという例です。この要求を実行する前にIBNシステムは下記を確認するはずです。

  • この時間枠はこの変更を実施するタイミングとして適切か?
  • 他に保守モードになっているリーフスイッチはあるか? 何台が保守モードになっているか?
  • このリーフスイッチに接続されているサーバーの内、基幹系アプリケーションが動いているサーバーがあるか?

上記の3つの例はいずれも、リソース配分、ポリシー、運用状態の情報を持っているSSoTに対して何等かのクエリを投げることが必要です。このクエリの回答はコールバック関数によって処理されますが、「プログラム化された確認(Programmatic Reasoning)」は、これら固有の動作を、標準化された再現性のあるパターンとして実装するのに必要な要件です。 大抵のシステムはソフトウエアとして構築することが可能ですが、我々は、試験可能、保守可能なソフトウエアの必要性を強調しています。どうやってこれをIBNベンダーに担保してもらいますか?いくつかの個別の動作を追加してもらい、そのプロセスがどこまで再現性があり解釈可能なのか様子を見るだけですか?

もしこれらの機能が無かったらどうなるでしょうか?何か障害が発生したのに、解析はバッチ処理で10分後でないと何が起きたのかわからないとしたら、それでは遅すぎるかも知れませんよ。もしSSoTとパブ/サブサポートが無ければ、コンフィギュレーション設定と運用状態をクローズループにするだけの付け焼刃のインテグレーションでは、変更を掛けた途端にシステムがダウンしてしまう可能性が大きいです。このようなインテグレーションでシステムがいつ落ちるか予測できるでしょうか? 管理者がポリシーやサービスを変更したり、大事なカスタマの「ペプシ」に割り当てられたインフラリソースを変更した場合でも、誇りに思っている自社サービスをちゃんと担保することができるでしょうか?異常発生の検知のトリガーとなる閾値は、ネットワークエンジニアが介入せずとも、その時の運用状態に基づいてダイナミックに設定されるようになっていますか?スパインスイッチを保守モードに切り替えれば、残りの装置のトラフィック量は増加するはずですよね? 貴社のIBNシステムはその変更を認識して閾値が調整されるようになっていますか?それともこのような場合には、「想定された」異常による大量のアラームを避けるために監視機能をオフにしていますか?でもオフにすると本当の異常も見逃してしまうリスクがあります。コストがかかり過ぎて全てのリソースを対象に常時実施することはできなかったデータ収集や解析を、異常状態をトリガーとして、必要な時に(リアルタイムで)適切な場所の(パブ/サブの活用)データを収集解析し、深い洞察が得られるようになっていますか?

AOSはリリース当初からグラフベースの表現の上にパワフルなパブ/サブの仕組みがレイヤー化されていました。しかもこれこそが弊社の今後のイノベーションの柱の一つなのです。メッセージ型パブ/サブでは、 今日の先進型基盤に存在する意図やリソース、サービス、ポリシー、機能と言った要素の間の多様な関係をサポートするのに必要な複雑さのほんの表面を掠ることができません。しかも純粋なグラフデータベースには、リアルタイムのパブ/サブメカニズムがサポートされていないのです。

プログラム化された確認(Programmatic Reasoning)は、(例えば「ファブリックのECMPは総合的なバランスが崩れているか?」のような)複雑な症状の根本原因の解析(RCA)のような高度な機能を実現するイネーブラーの一つです。少なくともレベル2の成熟度が無ければ、拡張性を持ったIBNの構築は難しいでしょう。

Level 3のIBN: 自律運用

確認可能性によって意図と運用状態がクローズループにできたら、次は監視できたことに対して、必要に応じてアクションを取が取れるというのが最後のステップです。この究極のレベルに達するには対応措置が用意されている事が必要で、このレベルになるとIBNは自律運用型ネットワークに向かってその道を進むことになります。しかし、レベル2と3において確固たる基礎を築いておかなければこの自律運用型ネットワークを目指すことは到底不可能です。レベル1から3までで構築しておいた機能があれば、この自律運用型ネットワークの実現は技術的にはさほど難しくないように見えるかも知れませんが、現在の運用方法やコントロールをソフトウエアに任せることに対してどれだけ運用担当者の抵抗や躊躇があるかによって、導入の速度が変わってきます。IBNソリューションの成熟度が高まれば、レベル3のIBNが提供してくれる機能に対する受け入れ度も上がってくるはずです。

AOSは現時点ではレベル2のIBNソリューションですが、それは技術力の問題ではありません。技術自体は出来上がっているのです。技術の進歩だけでは変革を起こす触媒にはなりません。技術によってもたらされた商機に対して業界としてどう対応していくのかが変革の実現につながるのです。このデジタル変革が人間や組織に浸透してくると、自律運用型ネットワークも動き出し始めるのです。

完成度と拡張性

IBNソリューションには、 成熟度モデルに基づいたレベル分類の他にも、考慮が必要な制約が存在しているかも知れません。IBNソリューションを評価する際に熟考すべき制約事項:

  • ベンダー固有のソリューションである
  • 特定のリファレンスアーキテクチャに特化したソリューションで、汎用性を持たせる計画がない
  • ネットワークサービスライフサイクルフェーズを部分的にしかフォーカスしていない(設計、構築、展開、検証の一部)
  • 特定の機能にフォーカスしたソリューション(セキュリティ、到達可能性、など)
  • 意図のみもしくは運用状態のみにフォーカスしたSSoTを使っている
  • 拡張性に制約がある

もし上記のような制約が存在する場合は、分類に条件を付けることも考えられます。例えば、

  • レベル1 (ネットワークの到達可能性のみ)
  • レベル2 (ベンダーX社にのみ対応、展開のみ)

何等かの制約が存在する場合、システムの更改とともに将来的にはその制約が排除されるのかの評価が重要になってくる場合もあります。言い換えれば、そのシステムは、特定の領域にのみ適用可能なサイロ型のソリューションにとどまるのか、それともサイロを壊し制約が撤廃されるものなのかということです。複数のサイロ型ソリューションを「バンドル化」して束ねても、束ねたそのソリューションの成熟度はレベル0の場合が多いです。なぜならば、SSoT(信頼できる唯一の情報源)という基本的な条件を満たしていないからです。

(「ホワイトボックス」ソリューションを含む)シングルベンダーソリューションも選択の自由が妨げられます。今日現在は、イノベーションの速度にしてもサポートの充実にしても、その信頼するベンダーに満足しているかも知れませが、 同じような理由で将来は別なベンダーに切り替えたいもしくはホワイトボックスソリューションに切り替えたいと思うことがあるかも知れません。ホワイトボックスのオープン性は気に入っているけれど、コストや性能の長所短所を鑑みながら、戦略的には信頼できるブライトボックスの品質やサポートレベルも取り入れたいと考えることもあるかも知れません。どこにそのトレードオフの線引きをするかはあなた自身の判断なのです。

 制約があるということは、設計やモデル化の早い段階において既に特定の前提条件が存在しているということを意味します。後になってそれらの制約を排除するのは難しいかも知れません。IBNソリューションの下にあるプラットフォームは柔軟性があるのか、新たなリファレンスデザインやイノベーションと歩調を合わせて進化することができるかなども理解しておく必要があります。

だからこそ、展開するシステムは今後進化することができるのかをちゃんと理解しておくことが重要なのです。

結論

IBNだと自称する様々な提案を、先述した成熟度レベルにマッピングしてみましょう。どのレベルに該当するかがわかれば、機能という点から見た場合の制約が理解できるでしょう。次に行うべきは、そのマッピングされたレベルにおいて、そのIBNソリューションがどれだけの完成度と拡張性があるかの確認です。真剣にIBNの構築を検討しているのであれば(真剣に検討すべきだと思いますが)逆に成熟度レベルの分類を使って、自社のネットワークに対してどのような機能が必要なのか、また各々の機能にどれだけの拡張性とスコープが必要なのかを要件として考えることもできます。

そして、選んだソリューションが今後進化できるのかも考えておくべきでしょう。我々の遺伝子の中にあるコードは、その発現に変動性があり、環境の変化に応答する能力を持っています。これを発現可塑性と言います。例えば、より多くの食糧と運動量に応答する能力がある哺乳類は筋肉量を増加させることができますが、ヘビは筋肉量を増加させることができません。このような可塑性について、IBNベンダーのDNAを確認すべきではないでしょうか。もしヘビを購入したのであれば、新たな要件に対応して筋肉量を増やすということは期待できません。でもそこでベンダーは、より大型の筋肉の多いヘビを売りつけようとするかも知れませんね。たくさんのヘビを飼うつもりはなく、かつ環境の変化に適応する必要があり、広く選択肢を確保することによって競争力を維持したいのであれば、ヘビではなく哺乳類を購入すべきなのです。

この説明を読んで、ヘビと哺乳類の違いが明らかになったでしょうか? IBNソリューションにとってSSoTはオプションではなく、必須項目です。SSoTに意図と運用状態の両方が格納されているかもオプションではなく、必須項目です。IBNソリューションにリアルタイム性と粒度の細かいパブ/サブの仕組みが備わっており、適切なタイミングで正しい回答が得られることもオプションではなく、必須条件なのです。

IBNソリューションに、マルチベンダー環境のサポートが内蔵されているか、理論的にではなくちゃんと実装されているかも必須条件です。各々のレベルは、明確に定義されており、白黒がはっきりしています。そしてこのブログで解説したように各々の技術的な機能はメリットに明確にマッピングできるのです。この情報があれば、自分自身で判断できるはずです。

サーシャ・ラトコビッチ

CTO, 創設者

 


Sasha Ratkovic

Sasha Ratkovic

CTO, Founder