クラウド対応ADC

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

クラウド対応のアプリケーションデリバリコントローラー（ADC）は、従来型のADCとは異なります。カスタムハードウェアまたはCOTSハードウェアに導入でき、アプリケーションの高速かつセキュアで可用性の高い配信とデプロイの両方のニーズに対応する、拡張性に優れたソフトウェアソリューションです。クラウド対応ADCにより、従来の安定性、セキュリティ、拡張性と、柔軟でクラウドおよびDevOpsに適した最新のプログラマブル機能を組み合わせた、データセンターアーキテクチャへの最新の2層型アプローチが可能になります。

分かりやすい説明ですが、具体的には何を意味するのでしょうか？

以前、モダンアプリプロキシと見なされるための要件について書きました。これは確かにクラウド対応ADCに必要な要素の1つですが、今日の要求の厳しい環境では、技術的な機能だけでは不十分です。運用面およびエコシステムとの統合に加え、最新および新たに登場するアプリケーションアーキテクチャをサポートする能力も必要です。

実際のところ、クラウド対応や従来型と新しいアプリケーションアーキテクチャの両方への対応など、同様の特長をうたうADCは数多くあります。そこで今回は、今日のアプリケーション環境においてクラウド対応ADCがなぜそれほど重要なのかを掘り下げる前に、クラウド対応ADCと従来型ADCの違いを詳しく見ていきます。

5つの差別化ポイント

クラウド対応ADCが従来型ADCと異なる点は、基本的に5つ（厳密に言えば6つ）あります。F5は、私が入社するよりずっと前にADCのあるべき姿をほぼ定義した企業です。そのため、ADCに求められてきた役割と、ビジネスに必要なスピード、セキュリティ、安定性を備えたアプリケーション配信を今後も継続するためにADCがどう進化すべきかを、誰よりも深く理解しています。

パフォーマンス

これは当然のことですよね。アプリの前段に配置してプロキシとして機能させるなら、配信対象のアプリと同等以上、できればそれを上回る速度が必要です。従来のADCは、シャーシやハードウェアなどのアプライアンスとして提供されてきました。しかし、従来のADCの性能は、使用する専用ハードウェアのCPUによって制限されていました。ADCはプラットフォームであるため、汎用CPUが汎用的な処理を重視するのと同様に、全般的な速度を重視する傾向があります。ただし、ほぼ必ずさまざまなハードウェアアクセラレーションのオプションが用意されており、どれを使用するかは導入前に決める必要があります。突飛な考えかもしれませんが、クラウド対応ADCなら、この制約を超えられるはずです。あるアプリでは特定のサービスの必要性が高く、別のアプリでは別のサービスの必要性が高いことを把握し、それぞれに対応できることが求められます。クラウドコンピューティングという概念全体の基盤には、必要に応じてコンピューティングリソースの用途を変更するという考え方があります。同様に、何らかのハードウェアに投資する組織も、その用途を変更できるべきです。

ネットワーク上に階層化されたサービスでこれが重要なのは、一般的なタスクを専用ハードウェア（FPGA）にオフロードすることで、CPUをリクエスト／レスポンスの検査、変更、スクラビングなど、ほかの処理に振り向けられるためです。これにより、プロキシでの処理全体が高速化し、レイテンシーが低減して、ユーザー満足度の向上につながります。

だからこそ、クラウド対応ADCは従来の制約を打破できます。ソフトウェア定義のパフォーマンスを活用し、セキュリティなど特定の処理に対するADCのパフォーマンスを、組織がプログラムによって向上できるようにします。つまり、組織のニーズが変化した場合、そのハードウェアのパフォーマンスプロファイルもオンデマンドで変更できます。これがハードウェアのアジリティです。矛盾しているように聞こえるかもしれません。しかし、これもクラウド対応ADCの特長です。専用ハードウェアを別の用途に転用できるため、投資を保護し、高額な全面刷新を不要にできます。

プログラマビリティ

スクリプト機能をめぐるNetOpsとDevOpsの対立は、以前からお客さまより繰り返し伺ってきた悩みの種です。従来のADCが提供していたのは、ごく基本的なスクリプト機能に限られ、使用する言語もDevOpsよりNetOpsになじみのあるものでした。一方、DevOpsは、データパスでスクリプトを活用すれば、よりアジャイルなさまざまなリクエスト／レスポンスのルーティングやスケーリング戦略、さらにはセキュリティサービスまで実現できるため、その習得に前向きでした。しかし、従来のADCは上流のコアネットワークに配置されていたため、NetOpsが、トラフィックフローに影響を及ぼしかねないスクリプトをDevOpsに自由にデプロイさせることはありませんでした。

仮想エディションの登場により、DevOpsは仮想マシンとして自分専用のプライベートADCを利用できるようになりました。しかし、それでもネットワーク寄りのスクリプト言語を習得せざるを得ませんでした。これは望ましいことではありません。クラウド対応ADCは、コアネットワークのNetOpsと、クラウドなどのアプリケーションネットワークのDevOpsの両方をサポートすべきです。特にDevOpsや開発者は、node.jsのような開発者にとって使いやすい言語を好みます。単にその言語に習熟しているからではなく、開発者向けインフラストラクチャとの統合を迅速化するための豊富なライブラリリポジトリ（NPMなど）やサービスがすでに存在するためです。だからこそ、クラウド対応ADCは両方をサポートすべきなのです。

アプリセキュリティ

従来型のADCは、長年にわたり基本的なアプリケーションセキュリティを提供してきました。アプリケーション、特にWebアプリケーションの前段に配置されるため、通常、データセンター内で攻撃を最初に認識し、対処できる存在でした（現在も同様です）。当然ながら、そのセキュリティの大部分はプロトコルレベルのセキュリティを中心としていました。SYNフラッド対策、DDoS検知、その他のTCPおよび基本的なHTTP関連のセキュリティオプションは、以前から従来型ADCに不可欠な要素となっています。

しかし、クラウド対応ADCには、さらに多くの役割が求められます。今日のアプリケーションに不可欠なスケーラビリティを確保するため、ADCはアプリケーションアーキテクチャ自体に組み込まれる数少ない「デバイス」の1つになる可能性が高く、フルスタックセキュリティにも同様に注力するのが合理的です。特に、それがパフォーマンスの向上にもつながることを考えれば、少なくともF5はそう考えます。何らかの処理のために一度立ち止まる必要があるなら、その機会にできるだけ多くの処理を行う方が合理的です。その方が効率的であり、複数の機器を次々に経由することで生じる遅延も解消できます。子どもを連れて長距離を移動した経験があれば、お分かりでしょう。ガソリンスタンドにトイレがあるのに、5分後にまた休憩所へ立ち寄りたくはないはずです。ネットワークセキュリティも同じです。できるだけ多くの処理を一度に行うことで、お客さまと企業の双方にとって不満の原因となりがちなオーバーヘッドを削減できます。パフォーマンスは極めて重要であり、クラウド対応ADCは、より高速なアプリケーション体験を実現するために、可能な限りの機能を果たす必要があります。

そのためには、モバイルデバイスとアプリ間のセキュアな通信をサポートする需要の高まり（一部では要件）に対応するための新たなモデルが必要になる場合があります。これには、Forward Secrecy（FS）と、それを実現する暗号技術のサポートが含まれます。また、マイクロサービスや新しいアプリケーションをサポートするために必要なアーキテクチャを損なうことなく、計算負荷の高い暗号化と復号の処理を、その処理向けに設計されたハードウェアにオフロードする新たなモデルを実現することも意味します。クラウド対応ADCはその両方をサポートし、高速かつセキュアな通信を実現しながら、現在のアーキテクチャやクラウド環境にシームレスに統合できる必要があります。

パートナーエコシステムと自動化

もう1つのAPIエコノミーは、プライベートクラウドの成功に加え、自動化とオーケストレーションの進展によって企業が得られる競争優位性にとって極めて重要です。しかし、そうでないことが望ましくても、データセンターにはさまざまなベンダーの多様なサービスが存在し、それぞれ統合モデルやオブジェクトモデルが異なります。そのため、必要なすべてのコンポーネントに関する専門知識を要する、負担の大きいAPI駆動型の自動化になりがちです。実際には、オーケストレーション向けと自動化向けという2つのレベルの統合が必要です （この2つは同じものではありません）。1つはAPIやテンプレートを介したプラットフォーム固有の自動化機能で、もう1つはオーケストレーションが中心となるパートナーエコシステムとのネイティブ統合です。クラウド対応ADCには、どちらも必要です。前者は、独自製品、カスタムスクリプト、PuppetやChefなどのフレームワークを介した自動化を実現し、後者は、重要性が高まっているOpenStack、VMware、Ciscoなどのコントローラーを介したオーケストレーションを可能にします。

クラウド対応ADCには、包括的なオーケストレーションソリューションの提供に使用されるフレームワークやシステムとのネイティブ統合と、それらを通じたオーケストレーション機能が求められます。

クラウド対応ADCがクラウドテンプレートをサポートすべきであることは、何度も言うまでもありません。

ですから、この点についてはこれ以上申し上げません。

アプリモデル

従来型ADCは、従来型アプリケーションに堅牢な一連のサービスを提供する必要性から生まれました。いわゆるモノリス向けです。今日のアプリケーションは、さまざまなアーキテクチャ、プラットフォーム、導入モデルを活用し、従来のアプリケーションよりも分散化、多様化、異質化が進んでいます。コンテナか仮想マシンか、クラウドかクラウドに類似した環境かを問わず、アプリケーションには今もそうしたサービスの一部が必要です。また、複数のサービスを同時に必要とする場合（たとえば、負荷分散とアプリケーションセキュリティ）には、ADCが必要になります。従来型ADCはマイクロサービスには適さない場合がありますが、クラウド対応ADCなら対応できます。その対象には、負荷分散とセキュリティのメリットを得られる可能性がある、より幅広いサービスも含まれます。たとえば、netopsではなくdevopsの領域に明確に属するmemcachedなどです。

クラウド対応ADCは、プラットフォームでありながら、従来型アプリと新しいアプリの双方が必要とするサービスを、それぞれに適した環境で提供するために必要なプログラマビリティ、統合、フォームファクターの要件に対応します。

従来型ADCとクラウド対応ADCには、多くの共通点があります。どちらもプラットフォームであり、共通の運用モデルで複数のサービスを実現できます。また、どちらもプログラム可能で、他のデータセンターやクラウドシステムと統合でき、パフォーマンス機能を柔軟に選択できます。しかし、クラウド対応ADCは従来型の枠を超え、従来型アプリケーションと新しいアプリケーションの両方をサポートします。さらに、多種多様なインフラストラクチャや環境との統合および相互運用に対するニーズが高まる中、ビジネスとアプリケーションの未来を支えます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事