インテントベースネットワーキングは「失敗した」テクノロジーですか?

2010年代半ば、テクノロジーマーケティングの達人もアナリストも同様に、インテントベースネットワーキング(IBN)と呼ばれるテクノロジーに夢中になり、広く宣伝されました。

10年近く経った今、IBNのことはあまり耳にしません。しかし、だからといってそれがなくなったわけではありません。

この記事では、IBNの歴史と、今日の最新のクラウドインフラストラクチャ、およびクラウドセキュリティに対するその重要な基盤について詳しく説明します。

2010 年代初頭: クラウド ネットワーキングの急速な変化への適応

これに先立ち、HP Networking では、CTO のオフィスでは、クラウド ネットワークの新しい規模と変化の速度に適応しようとする複数のグループによって、同様の新しいネットワーク抽象化が個別に発明されているのを目の当たりにしました。この作業の多くは、オープンソースプロジェクト(OpenStack、Open Day Lightなど)で行われていました。

HP は、この作業を統合するためにリソースを投資することを決定し、2013 年に パロアルトの HP ラボで「IBN サミット」を主催しました。Cisco、HP、RedHat、IBM、Huawei、Brocade、Microsoft、NEC、VMWare などの関係者を含む、SDN およびクラウド プロジェクトのネットワーク ポリシー ソリューションに取り組んでいることがわかっているすべての人に招待状が届きました。さまざまな関係者がこの分野での作業の側面を発表し、共通のAPIへの道を見つけることに同意しました。

2010年代半ば:IBNの定義

その後、私が議長を務めている間、これらの企業の多くの代表者は、Open Networking Foundation (ONF) の North-Bound Interface (NBI) ワーキング グループで協力を続けました。2016年10月、ONFは、IBNシステムの定義と技術概要に関するメンバーのコンセンサスを提示することを目的とした文書を公開しました。

ドキュメント「インテント NBI - 定義と原則」は こちらからお読みください。

このドキュメントの定義は、1 種類の黄金律で要約できます。インテントには、プラットフォームまたはインフラストラクチャに固有の実装の詳細は含まれていません。

インテントは、ビジネス用語で望ましいネットワーク動作に関する宣言文で構成されます。これとは別に、インフラストラクチャの現在の構成/状態/トポロジーにインテントを実装する方法を知っているマッピング プロセスがあります。

批評家たちは、私たちが実装を捨てて無視しているので、価値がないと主張しました。私たちはそれを捨てるのではなく、マッピングプロセスの制御下で別の場所に移動することを指摘しました。「純粋な」インテントを宣言するには、ポリシー作成者がインフラストラクチャ テクノロジの専門家である必要はなく、ポリシーのビジネス上の制約を理解するだけで済みます。

そのドキュメントでは、ONF 定義はコントローラ内の「インテント アクティブ ループ」について説明しています。

「この要素は、リポジトリからのアクティブなサービス インテントとマッピング、および SBI ハンドラーからのネットワーク情報を継続的に評価する責任があります。検出されたインテント変更(リポジトリ)、および/またはマッピング変更(リポジトリ)、および/またはインテントNBIの関数として、新しいサービス構成をインスタンス化する、または既存のサービス構成を適切に変更するために必要なアクションを実行する。

インテントのアクティブループの説明は、宣言的なインテントをシステム動作に変換するコントローラーを、インフラストラクチャ内で宣言されたインテントの実装を継続的に維持する継続的調整ループ(CRL)上に構築されていると説明するKubernetesでよく知られるようになった用語と一致しています。

この記事では、継続的調整ループ (CRL) という用語を使用して、このようなすべての技術的アプローチを指します。

2017年:IBNは「次の大きなもの」

この文書を公開して間もなく、ガートナーが2017年にIBNという用語を作り、 ブログ記事でIBNを「次の大きなもの」と呼んだとき、業界はIBNについて語り始めました。

マーケティング担当者は最終的に、すべてのベンダーが常にIBNを持っていたと主張することによって、IBNを無意味にしました。そしてその結果、人々は最終的にそれについて話すのをやめました。

これだけの騒ぎの後、振り返ってみると、IBNは実際的に失敗したのだろうかと疑問に思うかもしれません。

答えはノーです - 実際、まったく逆です。

現在: IBN は最新のクラウド インフラストラクチャで健在です

IBNについてはあまり語りませんが、最新のクラウドインフラストラクチャでは遍在しています。

3 つの例は、大規模な本番環境でのこのアプローチの使用の幅広さを示しています。

Kubernetes ネットワークポリシー

K8 のコンテナ ネットワーク インターフェイス (CNI) ポリシー コントローラーである証明書失効リスト (CRL) は、すべてのポッド/エンドポイント、仮想スイッチ、サイドカー プロキシ、ゲートウェイ、NAT などの状態を認識します。また、実装のマッピング(IPアドレス、ポート、プロトコル、ID、承認、ラベル、名前空間など)も認識し、継続的な調整ループを実行して、実装をネットワークポリシーと一貫性を保ちます。

開発者は、実装の詳細(インテント)なしで Kubernetes ネットワークポリシー(KNP)を提供し、コントローラーはそれを行います。KNP を使用すると、ユーザーは IP アドレスやポートなどの下位レベルの属性を指定できますが、ベスト プラクティスは、ローカル ポリシー宣言でラベルベースのセレクターを使用して、KNP エンジンの分散状態自動化の恩恵を受けることです。

Illumio Policy Compute Engine(PCE)およびIllumio VEN(エージェント)

イルミオには、同様のラベルベースの抽象化を使用してベアメタル、仮想マシン、コンテナに意図的な価値提案をもたらす、成熟した広く展開されているエンタープライズ製品があります。これは、CRL コントローラーを使用して複数の動的インスタンスにまたがり、ポリシー制約を維持します。

分散コントローラ (PCE) は、抽象化された動的なラベルベースのポリシーで事前に設定されており、継続的な調整ループを使用して、現在のインフラストラクチャの状態とトポロジのコンテキストでこれらのポリシーを実装します。

この場合、実際のポリシー適用は、さまざまなオンプレミスおよびパブリッククラウドインフラストラクチャプラットフォーム用の低レベルのネイティブツールをプログラミングすることによって行われます。

Juniper/Apstra

Apstra IBNには、抽象的なポリシーを特定のインフラストラクチャ実装に変換するための自動化を備えた宣言型モデルもあります。ただし、解決する問題は、前の例とは少し異なります。

Kubernetesネットワークポリシーとイルミオのプラットフォームはどちらも、「オーバーレイ」ネットワークテクノロジーとして分類できます。物理デバイス間の基本的な接続が既にあるネットワークの上に、仮想ネットワークの機能を作成および制御します。

ジュニパーのApstraソリューションには、ケーブルで接続されたデータセンターデバイスでいっぱいのラックを含む「Äúunderlay」ネットワークを作成および制御する機能があります。ただし、上記の例と同様に、宣言型ポリシーとネットワークを継続的に調整することで一貫性が維持されます。  

IBN:大規模なクラウドパフォーマンスのバックボーン

インテントベースのアプローチによって提供される抽象化レイヤーの追加は、クラウドワークロードに必要なスケール、変化率、パフォーマンスを達成するために必要です。

「アプリケーション」の動的なインスタンスが数千以上あり、常に変化している場合、人間はポリシーを更新するための迅速な道に乗ることができません。インテントベースのインターフェースは、ユーザーの視点からルール空間を「圧縮」し、それを実現するためのすべての魔法をそのインターフェースの背後に隠します。これにより、類似/同一の動作を持つインスタンスを、ポリシーを適用できるグループとして扱うことができます。

「グループ A のモノはグループ B のモノと通信できる」という意図がある場合は、変更する必要のない単純なルールを 1 つ作成します。これは正しいルールであり、1 つのサーバー上にインスタンスがない場合でも、1 つ、2 つ、3 つ、または 10 億個のインスタンスが存在しない場合でも、数百万のインスタンスが存在しなくても、正しい動作につながります。ルールは 1 つしかありませんが、大規模なシステムに実装するには、10 万のファイアウォール内の 10 億のファイアウォール ルールを動的に更新する必要がある場合があります。

これらの巨大で分散された自動化された連続調整ループ コントローラーの開発により、グローバル企業によってクラウド上に構築されることが増えている大規模な分散システムにグローバル ネットワーク ポリシーを実装することが可能になりました。

すべてのファイアウォールのルールを含むExcelスプレッドシートの時代はとうの昔に過ぎ去り、大規模なシステム用の「ファイアウォールのプログラミング」に対する手動の個別のアプローチも同様に時代遅れです。

最新のクラウドセキュリティはIBNに依存しています

IBNは誇 大広告サイクルの全過程を静かに乗り越えてきた。それは現代のネットワーキングの基盤に深く織り込まれているため、もはやバズワードは関係ありません。

複数の当事者が概念的に類似した解決策を単独で発明したという事実は、常に何か重要なことが起こっていることを示す強い兆候です。この作業を行った人々はほとんど知られていませんが、今日のクラウドでできる素晴らしいことを可能にするのに役立ったことは知っています。

サイバー脅威が増加し、特にゼロトラストネットワークの保護がさらに重要になるにつれて、この機能の重要性はさらに高まっています。IBNの信頼性とスケーラブルな性質により、イルミオのようなプラットフォームはクラウドで信頼性が高くスケーラブルなセキュリティを提供できます。

Illumio CloudSecureがハイブリッドクラウドの侵害をどのように封じ込めているかについては、 こちらをご覧ください。

イルミオゼロトラストセグメンテーションでクラウドネットワークを保護することに興味がありますか?ご相談とデモについては、今すぐお問い合わせください。