F5 Blog

 
アーカイブ 記事を検索

クラウドレディADC

クラウドレディADCと従来型ADCとの違いは、基本的に5つの観点から説明できます(もし杓子定規にやりたいのであれば、6つということも可能ですが)。F5は事実上「ADCとはどうあるべきか」を定義した企業なので、ADCについては他の誰よりも理解しているつもりです。ビジネスが要求するスピードとセキュリティ、安定性を確保しながらアプリケーションを配信するには、ADCにはどのような要件が突きつけられており、今後どのように進化すべきなのか、いずれについても私達は理解しています。

 

パフォーマンス

これは考えるまでもなく、重要な観点です。ADCはアプリケーションやプロキシの前段で動作するため、配信するアプリケーション以上のスピードが求められるからです。そのため従来型ADCは、シャーシとハードウェアで構成されたアプライアンスの形で提供されています。しかしADC全体の処理能力は、カスタム ハードウェア内で稼働するCPUによって制約されてしまいます。ADCのパフォーマンスを評価する場合、汎用CPUのパフォーマンス評価で一般的な処理に焦点を当てるのと同様に、一般的な処理における速度が注目される傾向がありますが、これは正しい評価方法だとは言えません。ADCには様々なハードウェア アクセラレータのオプションが用意されており、どれを選択するかを導入前に決定する必要があるからです。つまりどのハードウェア アクセラレータを選択するかによって、実際の処理能力は大きく左右されることになるわけです。これは実に悩ましい問題であり、クラウドレディADCはこの問題を解決できなければならないと私達は考えています。ここで理解しなければならないことは、「どの処理機能の高速化が求められるかはアプリケーションによって異なる」ということです。クラウド コンピューティングのコンセプト全体を支えているのは「目的に応じてオンデマンドの計算機能を再利用する」という考え方ですが、ハードウェアでも同様のこと(目的に応じて処理できる内容を変化させることが可能)を実現しなければなりません。

なぜこのような取り組みが重要なのでしょうか。ADCでは特定の処理を、専用ハードウェア(FPGA)にオフロードすることが可能だからです。これによってCPUは、リクエスト/レスポンスの検査や加工、スクラビングといった、他の処理を行えるようになります。プロキシでより高速に処理を終了できれば、レイテンシはより小さくなり、ユーザーにもメリットがもたらされます。

だからこそクラウドレディADCは、従来のハードウェア アクセラレータが持つ制約を解消しなければなりません。プログラミングによって目的に応じてハードウェア アクセラレータの処理内容を変更し、セキュリティのような特定処理のパフォーマンスを高められるようにする必要があるのです。これが可能になれば、ニーズが変化した場合にも対応しやすくなります。ハードウェアのパフォーマンス プロファイルを、必要に応じて変更すればいいからです。これは「ハードウェアの俊敏性」を実現することに他なりません。パラドックスのように聞こえることは、重々承知しています。しかしこれは、クラウドレディADCであるために欠かせない要素なのです。専用ハードウェアの処理内容を目的に応じて変更できるようにすることで、投資保護が可能になり、ハードウェアをまるごとアップグレードするという、高額な追加投資も不要になります。

 

プログラマビリティ

「スクリプティング機能に関して、NetOpsとDevOpsとの間にはなぜこれほどの断絶が存在するのか」。このような不満を、私はこれまで何度も顧客から聞かされてきました。問題はADCがほぼ基本的なスクリプティング機能しか実装しておらず、それがDevOpsではなくNetOpsと親和性がある言語で提供されている点にあります。現在のDevOpsでは、データパスのスクリプティングがもたらすメリットを享受しようという機運が高くなっています。これによってリクエスト/レスポンスルーティングの迅速化やスケーリング戦略の実現が容易になる上、セキュリティサービスにも大きな貢献を果たすからです。しかし従来型のADCがコア ネットワークの中に鎮座した状態のままでは、トラフィックを処理するためのスクリプトをDevOpsから展開することは困難です。

現在では仮想マシンの形で提供されているADC、いわゆるバーチャル エディションのADCを、DevOpsから立ち上げて利用することも可能になっています。しかしこれらのADCは現在も、ネットワーク向けのスクリプティング言語しか受け付けません。これは困ったことです。クラウドレディADCは、コア ネットワークで使われるNetOps用のスクリプティング言語だけではなく、クラウドのようなアプリケーション ネットワークで使われるDevOps用のスクリプト言語もサポートすべきです。そして例えば、DevOpsチームや開発者が、node.jsのような開発環境と親和性の高い言語を選択できるようにする必要があります。これは単に「彼らがこの言語を知っているから」ということが理由ではありません。高度な機能を持つライブラリ リポジトリ(例えばNPM)やリポジトリ サービスは、開発環境との親和性が高いインフラとより迅速に統合できるようになっているからです。クラウドレディADCがNetOpsとDevOpsの両方をサポートすべき理由は、まさにここにあります。

 

アプリケーション セキュリティ

従来型ADCは長い間、基本的なアプリケーション セキュリティを提供し続けてきました。アプリケーション、特にWebアプリケーションの前段に配置されることで、データセンタの中で最初に攻撃を識別し、これへの対応を行う役割を果たし続けてきたのです。しかし従来型ADCが実装するセキュリティ機能のほとんどは、当然ながらプロトコル レベルのセキュリティを中心としたものでした。SYNフラッド攻撃の防御やDDoS攻撃の検出、その他のTCPや基本的なHTTP関連のセキュリティ オプションなどが、ADCの機能の一部として、これまで長い間提供され続けてきたのです。

しかしクラウドレディADCは、その先に進まなければなりません。アプリケーション アーキテクチャに含まれる「数少ないデバイス」の1つとして、現在のアプリケーションが必然的に要求するスケーラビリティを保証しながら、フルスタックのセキュリティをカバーする必要があるのです。少なくとも私達はそう考えています。これによってパフォーマンスを改善できるからです。例えばセキュリティ機能を複数のアプライアンスで実行しており、他のアプライアンスの処理が完了するのを待つ必要があると考えてみましょう。もし1台のアプライアンスで同時により多くの処理ができれば、このような待ち時間を解消できます。アプライアンスからアプライアンスへとパケットが移動することで発生するレイテンシもなくなり、より高い効率が実現できるのです。これは子供と一緒に長距離を旅行するのに似ています。ガソリンスタンドにトイレがあれば、給油とトイレを一緒に済ましたほうが効率的です。給油した後、また5分後にトイレ休憩したいとは思わないはずです。ネットワークにおけるセキュリティ機能もこれと同じです。一度により多くの処理を行いオーバーヘッドを最小化することで、顧客やビジネスにもたらされるフラストレーションも減らせるのです。パフォーマンスは非常に重要です。クラウドレディADCは、よりスピーディなアプリケーション体験を可能にする全てのことを、実現すべきなのです。

モバイルデバイスとアプリケーションとの安全な通信への高まり続ける需要(場合によっては要求)に対応できる、新たなモデルも提供しなければなりません。そのために求められるのが、フォワードセキュリティ(FS:前方秘匿性)と、これを可能にする暗号のサポートです。つまり、マイクロサービスや新たなアプリケーションをサポートするために必要なアーキテクチャを壊すことなく、暗号化や復号といった高い計算負荷を伴う処理を専用ハードウェアにオフロードする、新たなモデルを実現するのです。クラウドレディADCはこの両方を、スピーディかつセキュアな通信を実現しながら、サポートすべきです。これによって現在の最新アーキテクチャとクラウド環境へと、シームレスに移行することが可能になります。

 

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

プライベート クラウドを成功させ、自動化やオーケストレーションによってビジネスの競争力を高めていくには、外部のAPIエコノミーを活用することが極めて重要です。しかしそうは言っても、複数のベンダー製品で構成され、異なるシステム構築手法やオブジェクト モデルを採用したデータセンタのサービスは、常に多様化する傾向があります。そのためAPIをベースにした自動化は、関連する全てのコンポーネントに関する専門知識が必要となり、非常に難しいものになってしまいます。現実に求められるのは、2レベルのインテグレーションです。1つはオーケストレーション、もう1つはオートメーションです(これらは同じものではありません)。プラットフォームには、APIやテンプレートを介してアクセスできる固有の自動化機能があり、これらをパートナー エコシステムの中へネイティブな形で統合し、その上にオーケストレーションを位置づけるのです。このいずれもクラウドレディADCには必要となります。前者は、自社製品やカスタム スクリプト、あるいはPuppetやChefのようなフレームワーク経由での自動化を可能にし、後者はOpenStackやVMware、Ciscoのような、重要性が高まっているコントローラ経由でのオーケストレーションを可能にします。

クラウドレディADCは、ネイティブなインテグレーションを実現すると共に、包括的なオーケストレーション ソリューションを提供するために使用されるフレームワークやシステムによるオーケストレーションも、可能にすべきなのです。

クラウドレディADCが、クラウドテンプレートをサポートすべきだということは、言うまでもありません。これについて言いたいことは、それだけです。

 

アプリケーション モデル

従来型ADCは、従来型アプリケーションが必要とする各種サービスを、堅牢な形で提供するために誕生しました。それはモノリス(一枚板のような存在)と言ってもいいでしょう。しかし現在のアプリケーションは分散化と多様化が進み、従来型アプリケーションから大きな変化を遂げました。多様なアーキテクチャ、多様なプラットフォーム、そして多様な展開モデルを活用するようになっているのです。しかし、コンテナなのか仮想マシンなのか、あるいはクラウドそのものなのかクラウドライクな環境なのかにかかわらず、アプリケーションは現在も様々なアプリケーション サービスを必要としています。同時に複数のサービスが求められることも珍しくありません(例えばロードバランサとアプリケーション セキュリティのように)。つまりADCへのニーズは依然として高いのです。従来型ADCはマイクロサービスに対する要求を満たすことができませんが、クラウドレディADCなら可能です。クラウドレディADCが提供すべきなのは、ロードバランサや各種セキュリティ機能がもたらす幅広いサービスだけではありません。memcachedのように、NetOpsではなくDevOpsの領域に直結したサービスも含まれています。

クラウドレディADCはあらゆる環境において、従来型のアプリケーションと新しいアプリケーションの両方が必要とするプログラマビリティやインテグレーション、フォームファクタをサポートする、プラットフォームであり続けなければならないのです。

従来型ADCとクラウドレディADCとの間には、類似性も数多く存在します。いずれもプラットフォームであり、一般的な運用モデルに対応した複数のサービスを実現しています。またいずれもプログラマブルであり、他のデータセンタやクラウド システムとインテグレートされ、性能に関する高い柔軟性を提供しています。しかしクラウドレディADCは従来型ADCよりもさらに先を行くものです。アプリケーションのニーズは多様化しており、幅広いシステムインフラ/環境とのインテグレーションや相互運用性が求められています。クラウドレディADCはこのニーズを満たすことで、ビジネスの未来を切り拓くことを可能にするのです。

Tags:
お問い合わせ