エッジを活用するサービスプロバイダー：共通の自動化フレームワークで、スピードとセキュリティのトレードオフを解消

Bart Salaetsフィールド最高技術責任者 | F5

少し前まで、サービスプロバイダーの世界には明確な一線が引かれていました。

一方では、ネットワークチームとセキュリティチームが、ネットワーク機能とセキュリティ機能の仮想化に重点を置き、NFVアーキテクチャへの移行を主導していました。自動化への取り組みは、よく言っても手探りの段階でした。

一方、開発者はクラウドプラットフォーム、DevOps手法、CI/CDパイプラインによる自動化を積極的に採用しました。アプリケーションの迅速なデプロイとデリバリーが当時の最優先事項であり、現在も変わりません。

エッジは両者が融合する場所であり、アプリケーションとネットワーク機能が調和しながら共存できます。

分散型であることに加え、段階的に進む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は、命令型APIとはまったく異なります。システムに望む状態を伝えると、その実現方法はシステム自身が判断します。たとえば、1つの宣言（JSONまたはYAML形式）ですべてのADCおよびセキュリティサービスのパラメーターを定義し、1回のREST API呼び出しでシステムに渡すことができます。この場合、結果は成功（サービスがデプロイされた）か失敗のいずれかですが、失敗してもシステム全体には影響しません。自動化システム側にインテリジェンスを持たせる必要はありません。インテリジェンスは構成対象のシステム内に維持されるため、自動化コストを大幅に削減できます。

NFV環境で仮想ネットワーク機能をプロビジョニングする場合も、まったく同じ手順を実行できます。宣言型APIにより、エンドツーエンドのNFVオーケストレーションツールとの統合が大幅に簡素化されます。オーケストレーターは、サービスやネットワーク機能を構成する個々の手順を把握する必要はありません。サービスのセットアップに必要なパラメーターを含む単一のJSON宣言をシステムに送信するだけです。ここでも、サービスを「どのように」構成するかというインテリジェンスは、構成対象のシステム内に保持されます。

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

業界全体では、アプリケーションとそのサービス、さらにネットワーク機能の展開を可能にする共通の自動化フレームワークが、今後数年で標準になると予想されます。特に、5Gの導入が世界各地で進むにつれ、その傾向は強まるでしょう。サービスプロバイダーには、サイロを統合し、俊敏性を高め、エッジをより積極的に活用することがますます求められています。

最近開催されたSDN NFV World Congressでの、エッジコンピューティングに関するBart Salaetsの基調講演は、こちらからもご覧いただけます。

著者について

Bart Salaetsフィールド最高技術責任者 | F5

Bart Salaetsのその他のブログ記事