エッジ上のサービスプロバイダー: 共通の自動化フレームワークとスピードとセキュリティの妥協の終焉

サービス プロバイダーの分野には、それほど遠くない過去には、明確な境界線がありました。

一方では、ネットワークおよびセキュリティ チームが、ネットワークとセキュリティ機能の仮想化に重点を置いて、 NFV アーキテクチャへの進化を先導しました。 自動化の世界への進出は、せいぜい試行錯誤的なものでした。

一方、開発者はクラウド プラットフォーム、 DevOps方法論、CI/CD パイプラインによる自動化を熱心に受け入れました。 迅速なアプリケーションの導入と配信が、当時も今も重要な課題です。

エッジは、これら 2 つが集まる場所であり、アプリケーションはネットワーク機能と調和して共存できます。

エッジ コンピューティングは、その分散型の性質と、 5G の段階的な世界展開によって、ようやくサービス プロバイダーが収益源を増やし、ネットワーク転送コストを削減する新しいソリューションとサービスを提供できるようになってきました。

分析のためにデータをクラウドや中央データ ウェアハウスに送信するのではなく、ネットワークの「エッジ」で処理を実行することで、ネットワークの遅延が短縮され、帯域幅が増加し、応答時間が大幅に短縮されます。

自動運転車を例に挙げましょう。

アプリケーションとその関連データをパブリック クラウドなどの集中化された場所にホストすると、エンドツーエンドの遅延が数十ミリ秒になる可能性があります。 それはあまりにも遅すぎます。 アプリケーションを中央に残し、ネットワーク機能をエッジに移動した場合も同じ結果が得られます。 ただし、アプリケーションとネットワーク機能をエッジに移動すると、レイテンシを数ミリ秒にまで削減できます。 今、私たちはビジネスを始めました。

仮想化コンテンツ配信ネットワーク (CDN) も、もう 1 つの説得力のある例です。

これまで、サードパーティの CDN は、ピアリング ポイントまたは集中型データ センターでホストされる傾向がありました。 この状況は変わりつつあり、一部の賢明なサービス プロバイダーは、トランジットとバックホールのコストを節約しながら、ローカル ビデオ コンテンツと IPTV サービスをカバーするために、独自のエッジ コンピューティング ベースの CDN を構築しています。

こうした種類のユースケースを実現するために利用できるさまざまなビジネス モデルが存在します。

最も単純なシナリオは、サービス プロバイダーがエッジ コンピューティング サイトへの物理的なアクセスを許可することです。 サードパーティは独自のハードウェアを持ち込み、すべてを管理します。 サービス プロバイダーは、スペース、電力、接続性を担当します。これは、コロケーション モデルとも呼ばれます。

さらに興味深いアプローチは、サービス プロバイダーが共有エッジ コンピューティング プラットフォームを通じて、Infrastructure as a Service (IaaS) または Platform as a Service (PaaS) オプションをサード パーティに提供することです。 サービス プロバイダーは、これらを自社で構築することも、専門のパートナーと協力して構築することもできます。

自動化の力

自動化は、すべてを機能させるための秘密の要素です。

クラウド コンピューティングの分野では、開発者が新しいバージョンのコードを迅速かつ機敏に公開するには、自動化が不可欠です。

NFV のネットワークの世界では、自動化がサービス プロバイダーの運用コストを削減する鍵となります。 以前は、ネットワークとサービスのプロビジョニングは手動で時間のかかる作業でした。 現在、目的は異なるかもしれませんが、ツールとテクニックはネットワーク チームと開発チームの両方で同じ、または共有可能です。 エッジ コンピューティング環境では、アプリケーションとネットワーク機能が共存します。

では、開発者はどのようにしてクラウドでのアプリケーションと関連アプリケーション サービスの展開を自動化できるのでしょうか?

この記事では、アプリケーション サービスの自動化に焦点を当てます。 以下に説明する手順は、Ansible や Terraform などの一般的な構成およびプロビジョニング管理ツールに簡単に統合でき、さらに Jenkins などの CI/CD パイプライン ツールによって補完される点に注意してください。

最初のステップは、選択したクラウドにアプリケーション サービスを提供するために、仮想マシンをブートストラップまたは導入することです。

次はオンボーディングです。これは、ネットワークと認証パラメータ (IP アドレス、DNS サーバーなど) を含む基本構成を導入することを意味します。 最後に、宣言型アプリケーション プログラミング インターフェイス (API) を使用して、ADC やセキュリティ ポリシーなどのアプリケーション サービスを実際に展開します。

最後の点は重要です。

ほとんどのベンダーが備えている命令型 API は、あらゆる場面でシステムに何を実行するかを指示することを意味します。 ファイアウォールが良い例です。 アドレス リストを作成し、それをファイアウォール ルールに合わせる必要があります。 これらはポリシーにグループ化され、インターフェイスに割り当てられます。 REST API 呼び出しを順番に実行するための明確な手順と要件があり、そうでない場合はすべてが失敗します。 これらすべてを自動化ツールに組み込むのはコストがかかり、時間がかかります。

宣言型 API は別の話です。 システムに何を望んでいるかを伝えると、システムが今後の道筋を計算します。 たとえば、1 つの宣言 (JSON または YAML 形式) ですべての ADC およびセキュリティ サービス パラメータを定義し、それを 1 回の REST API 呼び出しでシステムに渡すことができます。 この場合、結果は成功 (サービスがデプロイされた) か失敗 (ただしシステム全体には影響なし) のいずれかになります。 自動化システムにはインテリジェンスは必要ありません。 インテリジェンスは構成中のシステム内に留まるため、自動化コストが大幅に削減されます。

NFV 環境で仮想ネットワーク機能をプロビジョニングする場合も、まったく同じ手順を実行できます。 宣言型 API により、エンドツーエンドの NFV オーケストレーション ツールとの統合が大幅に簡素化されます。 オーケストレーターは、サービスまたはネットワーク機能を構成するための個々の手順を知る必要はなく、システムがサービスをセットアップするために必要なパラメータを含む単一の JSON 宣言をプッシュするだけです。 繰り返しになりますが、サービスを構成する「方法」に関する情報は、構成しているシステム内に留まります。

ネットワークと開発の専門分野をより緊密に連携させることで、アプリケーションとネットワーク機能のための共通の自動化フレームワークを備えた分散型通信クラウドを構築できるようになりました。 中央データセンターから末端まで、さらにはパブリック クラウドに至るまで、スタックのあらゆるレイヤーで俊敏性とセキュリティを実現します。

業界全体では、今後数年間、特に 5G の展開が世界中で進むにつれて、アプリケーションとそのサービス、およびネットワーク機能の展開を可能にする共通の自動化フレームワークが標準になると予想されます。 サービスプロバイダーに対して、サイロを統合し、俊敏性を高め、エッジでの対応をさらに進めるよう求める圧力が高まっています。

また、ここをクリックすると、最近の SDN NFV World Congress でのエッジ コンピューティングに関する Bart Salaets の基調講演を視聴できます。