アプリケーションデリバリコントローラーの進化
はじめに
変化の激しい今日の世界では、世界中の数百万人のユーザーに重要なアプリケーションを提供することが、組織にとって常に課題となっています。アプリケーションの拡張性、セキュリティ、可用性を確保するには、ネットワークサービスとアプリケーションサービスの導入が極めて重要です。これが、Application Delivery Controller（ADC）が進化してきた主な理由の1つです。しかし、こうした機能はいずれも、基本的な負荷分散技術という確固たる基盤なしには実現できません。まずは、負荷分散の重要性、それが効率的なアプリケーションデリバリにどのようにつながるのか、そしてADCが現在も進化を続け、クラウドファーストの世界にどのように対応しているのかを見ていきましょう。
ロードバランシングの需要を促進する要因
ロードバランシングの目的は、受信するネットワークトラフィックやアプリケーショントラフィックを複数の物理サーバーに分散し、それらのサーバーを外部からは1台のサーバーとして見せることです。これを行う理由は数多くありますが、主な要因は「スケーラビリティ」「高可用性」「予測可能性」の必要性です。
スケーラビリティとは、既存のパフォーマンスに影響を与えることなく、負荷の増加に動的または容易に対応できる能力です。一方、高可用性（HA）とは、1つ以上のシステムに障害が発生しても、サイトの可用性とアクセス可能な状態を維持できる能力です。サービス仮想化（ソフトウェアコンポーネントの動作を模倣し、アプリケーション開発の迅速化とテストを支援する技術）は、スケーラビリティと可用性の両方を向上させる可能性をもたらします。サービスまたはユーザーとの接点を実際のサーバーから分離すれば、サーバーを追加してアプリケーションを拡張できます。また、個々のサーバーに障害が発生しても、アプリケーション全体が利用できなくなることはありません。予測可能性は、HAの要素に加え、これまでに得られた知見も含むため、やや明確に定義しにくい概念です。可用性とパフォーマンスの観点から、サービスを提供する方法とタイミングを制御できること、と表現するのが最も適切です。
ロードバランシングの歴史
商用インターネットの黎明期、ドットコム長者を夢見る多くの人々は、その計画に深刻な問題があることに気付きました。当時のメインフレームにはWebサーバーソフトウェアがなく（少なくともAS/400eが登場するまでは）、仮にあったとしても、スタートアップの予算では導入できませんでした。手が届いたのは、数多くのPCメーカーが販売する標準的な市販のサーバーハードウェアでした。しかし、その多くには大きな問題がありました。PCベースのサーバー1台だけでは、事業で発生するトラフィック量を到底処理できなかったのです。しかも、そのサーバーが停止すれば、サービスも事業も止まってしまいます。幸い、この問題を解決して一財産を築こうと考えた人々もいました。こうして、ロードバランシングが誕生しました。
はじめにDNSありき
専用設計の負荷分散デバイスが市販される以前は、既存のテクノロジーを活用してスケーラビリティと可用性を実現するために、さまざまな試みが行われていました。その中で最も広く普及し、現在も使用されているのがDNSラウンドロビンです。
この方式では、DNSは同じDNS名に対して、異なるサーバーに複数の一意のIPアドレスを割り当てます。つまり、ユーザーが初めて「www.example.com」の名前解決を要求すると、DNSサーバーは新しい接続を順番に各サーバーへ振り分け、最後のサーバーに達すると再び最初のサーバーに戻ります。このシンプルなソリューションにより、複数のマシンに接続を均等に分散できました。
スケーラビリティの観点では、このソリューションにより、1つのDNS名にほぼ無制限にサーバーを追加できたため、非常に効果的でした。しかし、可用性の面では課題がありました。DNSには、登録されているサーバーが稼働しているかどうかを把握する機能がなかったためです。サーバーが利用できなくなった状態でユーザーがアクセスを試みると、停止中のサーバーにリクエストが送信される可能性がありました。
DNSラウンドロビンが採用されたもう1つの理由は、ユーザーが特定のサーバーに送られることを高い確度で見込めるという予測可能性でした。その中心となるのがパーシステンスです。これは、セッションの開始後や、ユーザーが一時中断していたセッションを再開した際に、別のサーバーへ負荷分散されないようにするという考え方です。これは非常に重要な課題でしたが、DNSラウンドロビンでは解決できませんでした。
ソフトウェアによる独自の負荷分散
この問題に対処するため、初期に登場した専用ソリューションの1つが、アプリケーションソフトウェアまたはアプリケーションサーバーのオペレーティングシステム（OS）に直接組み込まれたロードバランシングでした。実装方法は開発企業ごとに異なっていましたが、ほとんどのソリューションは基本的なネットワーク上の仕組みを利用していました。たとえば、あるソリューションでは、プール（クラスターとも呼ばれます）内のすべてのサーバーに、それぞれ固有の物理IPアドレスに加えて、別のIPアドレスを割り当てていました。
ユーザーがサービスへの接続を試みると、サーバーの物理IPではなくプールIPに接続されました。プール内で最初に接続要求に応答したサーバーが、ユーザーを物理IPアドレス（そのサーバー自体、またはプール内の別のシステムのアドレス）にリダイレクトし、サービスセッションが開始されました。このソリューションの主な利点の1つは、アプリケーション開発者がさまざまな情報を利用して、クライアントの接続先となる物理IPアドレスを決定できることでした。たとえば、プール内の各サーバーで、各プールメンバーが処理中のセッション数を管理し、新しい要求を最も使用率の低いサーバーに転送することができました。
当初、このソリューションのスケーラビリティは明らかでした。新しいサーバーを構築してプールに追加するだけで、アプリケーションの処理能力を拡張できました。しかし、時間が経つにつれ、アプリケーションベースの負荷分散のスケーラビリティに疑問が生じました。次の接続をどのサーバーに割り当てるかについて、プールメンバー同士が常に連絡を取り合う必要があったため、プールに新しいサーバーを追加するたびに、メンバー間のネットワークトラフィックが指数関数的に増加しました。プールが一定の規模（通常は5～10ホスト）に達すると、このトラフィックはエンドユーザーのトラフィックだけでなく、サーバー自体のプロセッサ使用率にも影響を及ぼし始めました。つまり、必要なサーバーが少数にとどまる限り、スケーラビリティは優れていました（ちなみに、対応できるサーバー数はDNSラウンドロビンよりも少ないものでした）。
DNSラウンドロビンとソフトウェアロードバランシングにより、HAは大幅に向上しました。プールメンバー同士が常時通信していたことに加え、アプリケーション開発者が豊富なアプリケーション知識を活用してサーバーの正常稼働を判断できたため、これらのソリューションでは、ユーザーがリクエストを処理できないサーバーに到達する可能性がほぼなくなりました。ただし、HA機能を高度化するたびにサーバーとネットワークの使用率が増加し、スケーラビリティがさらに制限された点には注意が必要です。HAに関するもう1つの悪影響は、信頼性の低下でした。これらのシステムでトラフィックの分散に使用されていたネットワーク上のさまざまな仕組みは複雑で、ネットワークレベルでの相当な監視が必要でした。そのため、こうした分散方式では、アプリケーション全体とアプリケーションネットワーク上のすべてのトラフィックに影響する問題が頻繁に発生していました。
これらのソリューションは、予測可能性も向上させました。アプリケーション設計者は、ユーザーを負荷分散せずに同じサーバーへ戻す必要があるタイミングと理由を把握していたため、必要に応じてユーザーのセッション維持を支援するロジックを組み込むことができました。また、同じ「プーリング」技術を使用してサーバー間でユーザー状態情報を複製し、そもそもセッション維持を必要とするケースの多くを解消しました。さらに、アプリケーションに関する深い知識を活用し、必ずしもサーバー負荷を正確に示すとは限らない接続数などではなく、アプリケーションの実際の健全性に基づく負荷分散アルゴリズムを、より適切に開発できました。
真のスケーラビリティに関する潜在的な制約や信頼性の問題に加え、独自仕様のアプリケーションベースの負荷分散には、開発と保守をアプリケーションベンダーに依存するという欠点もありました。最大の問題は、すべてのアプリケーションが負荷分散（またはプーリング）テクノロジーを提供していたわけではなく、提供していた場合でも、他のアプリケーションベンダーのテクノロジーとは連携できないことが多かった点です。ベンダーに依存しないOSレベルの負荷分散ソフトウェアを開発する組織もいくつかありましたが、残念ながら同じスケーラビリティの問題を抱えていました。また、アプリケーションとの緊密な統合がなかったため、こうしたソフトウェア「ソリューション」には、HAに関するさらなる課題もありました。
ネットワークベースの負荷分散ハードウェア
専用ロードバランシングの第2世代として登場したのが、ネットワークベースのアプライアンスです。これらは、今日のApplication Delivery Controllerの礎を築いた存在です。アプリケーション自体の外部に物理的に配置され、当初はロードバランサーとして登場しましたが、NATなど、よりシンプルなネットワーク技術を使用して負荷分散を実現していました。これらのデバイスは外部に仮想サーバーアドレスを公開し、ユーザーが接続を試みると、その接続を最適な実サーバーに転送していました。
ロードバランサーは、どの接続をどのサーバーに割り当てるかを正確に制御できました。また、高度化する「ヘルスモニター」を使用して、アプリケーションサーバー（実在する物理サーバー）が必要に応じて応答していることを確認していました。サーバーが正常に応答しない場合、ロードバランサーは、期待される応答が得られるまで、そのサーバーへのトラフィック送信を自動的に停止しました。ヘルスモニターは、アプリケーション開発者自身が構築したものほど包括的であることはほとんどありませんでしたが、ネットワークベースのハードウェア方式により、ほぼすべてのアプリケーションに基本的な負荷分散サービスを統一された一貫性のある方法で提供できました。これにより、アプリケーションサーバー専用の、真に仮想化されたサービスエントリーポイントがついに実現しました。
スケーラビリティの観点では、ソフトウェアベースの負荷分散をハードウェアベースのソリューションに置き換え始めた組織で、サーバー使用率が大幅に低下しました。その結果、短期的にはサーバーを追加購入する必要がなくなり、長期的にはROIの向上につながりました。
同様に、HAはソリューションの複雑さを軽減し、アプリケーションに依存しない負荷分散を実現することで、信頼性を高め、ソリューションとしての対応範囲を広げるのに役立ちました。ネットワークベースの負荷分散ハードウェアにより、事業者は、負荷分散機能を内蔵した一部のアプリケーションだけでなく、すべてのアプリケーションに高可用性を提供できるようになりました。
ネットワークベースの負荷分散ハードウェアによって追加された中核的な要素が、予測可能性です。新しい接続の転送先を予測し、制御することがはるかに容易になりました。これらのデバイスによって処理がインテリジェント化され、動的DNSによる制御不能な分散とは異なり、制御された負荷分散が可能になりました。これにより、事業者は各サーバーの負荷処理能力に応じて負荷を分散できるようになりました。
ネットワークベースのロードバランサーと仮想化の登場により、アプリケーションサーバーの情報をインターネットから隠蔽したり、ユーザーに影響を与えることなく保守のためにサーバーをオフラインにできるよう、接続を徐々に別のサーバーへ移行したりするなど、セキュリティと管理に新たなメリットがもたらされました。これがADCの起源となりました。
アプリケーションデリバリーコントローラー
フルプロキシでもある中核的な負荷分散機能は、新しいサービスや新たに登場するサービスを追加し、統合するための優れた基盤としてIT部門に認識されました。その結果、負荷分散デバイスは拡張可能なADCプラットフォームへと進化しました。端的に言えば、プロキシは負荷分散の基盤であり、ADCを実現する基礎技術です。
ADCのセキュリティを考えるうえで、基盤技術であるプロキシによって実現される仮想化は極めて重要です。SSL/TLS暗号化のオフロード、認証の一元化、さらにはアプリケーションを認識するファイアウォールのいずれにおいても、これらのソリューションの強みは、ロードバランサー（ハードウェア版または仮想版）がすべてのアプリケーションにわたる仮想化の集約ポイントとなる点にあります。認証の一元化は、その典型例です。従来の認証および認可メカニズムは、常にアプリケーション自体に直接組み込まれていました。アプリケーションベースの負荷分散と同様に、各実装はそれぞれのアプリケーションの実装に依存し、固有のものだったため、多種多様な方式が生じていました。これに対し、すべてのアプリケーションに共通する仮想化されたエントリーポイントで認証を適用すれば、単一の統一された認証方式を使用できます。これにより、認証システムの設計と管理が大幅に簡素化されるだけでなく、アプリケーションサーバー側で認証機能を実行する必要がなくなるため、サーバー自体のパフォーマンスも向上します。さらに、特に自社開発のアプリケーションでは、個々のアプリケーションごとに認証プロセスを開発するための時間と費用も不要になります。
可用性は、拡張性、高可用性、予測可能性というロードバランサーの基本的な属性すべてに関係するため、ADCの属性の中でも、元来のロードバランサーとの関連が最も分かりやすいものです。しかし、ADCはロードバランサーよりもさらに高度な可用性を実現します。ADCにおける可用性には、アプリケーションの依存関係や動的プロビジョニングといった高度な概念も含まれます。現在のアプリケーションが単独で動作することはまれであり、多くの場合、その設計上の機能を実現するために他のアプリケーションに依存していることをADCは把握できます。こうした他のプロセスも考慮することで、ADCはアプリケーションの可用性をより効果的に確保できます。市場で最もインテリジェントなADCは、外部入力に基づいてサービスの提供方法を動的に変更できるプログラマティックインターフェースも備えています。これらのインターフェースにより、クラウドやコンテナ化されたデプロイメントなどの最新環境で必要となる、動的プロビジョニングと自動スケールアップ／スケールダウンが可能になります。
パフォーマンスの向上も、負荷分散という概念から自然に発展した機能の1つです。ロードバランサーは、利用可能で許容範囲内の時間で応答するサービスに接続を振り分けるだけでなく、接続数やプロセッサ使用率が最も低いサービスにも振り分けることで、アプリケーションのパフォーマンスを向上させました。これにより、新しい接続はそれぞれ、その処理に最も適したシステムによって処理されるようになりました。その後、専用ハードウェアを使用するSSL/TLSオフロードが負荷分散製品の一般的な機能になると、暗号化トラフィックの処理に伴う計算負荷とバックエンドサーバーの負荷が軽減され、サーバーのパフォーマンスも向上しました。
現在のADCは、さらに進化しています。多くの場合、キャッシュ、圧縮、さらにはレートシェーピングのテクノロジーも搭載し、アプリケーション全体のパフォーマンスと配信を一層向上させます。また、これらのサービスを提供する従来のスタンドアロン型アプライアンスのように静的に実装するのではなく、ADCに備わるアプリケーションインテリジェンスを活用し、パフォーマンス上の効果が得られる場合にのみサービスを適用することで、その利用を最適化できます。
たとえば、一般的な認識とは異なり、圧縮技術がアプリケーションのすべてのユーザーに必ずしもメリットをもたらすとは限りません。帯域幅が狭いユーザーの場合、実際のスループットがボトルネックとなるため、パケットを小さくすることで大きなメリットを得られます。長距離を経由する必要がある接続でも、パケットが小さければデータ転送に必要な往復回数が減り、ネットワーク遅延の影響を軽減できます。一方、帯域幅が広い短距離接続（同じ大陸内など）では、圧縮を適用するとパフォーマンスが低下する可能性があります。スループットが必ずしもボトルネックではないため、圧縮と展開による追加のオーバーヘッドで遅延が生じ、スループットの向上だけではパフォーマンス面でその遅延を補えないからです。つまり、適切に管理しなければ、解決策として導入した圧縮技術が元の問題を悪化させる可能性があります。しかし、全体的なパフォーマンスの向上につながる場合にのみ圧縮をインテリジェントに適用することで、ADCは圧縮技術の利用とコストを最適化し、より有効に活用できる機能に多くのプロセッサーサイクルを割り当てられます。
世界が向かう先
デジタルトランスフォーメーションは戦略上極めて重要であるため、多くの企業がクラウドへの移行に着手しています。アプリケーションが増加し、私たちを取り巻く世界を変えていく中、クラウドへ移行する組織は、俊敏性の向上、事業に即した運用コスト、オンデマンドの拡張性、コアビジネスへの一層の注力など、多くのメリットを得られると考えられています。
「クラウド」は、コンピューティング、ストレージ、ネットワークの共有リソースが一体となった、形のない単一の存在ではありません。実際には、プロバイダー、インフラストラクチャ、テクノロジー、環境が複雑に組み合わされ、多くの場合、世界各地の複数の拠点に展開されています。そのため、多くの企業が、パブリッククラウド、プライベートクラウド、さらにはそれらを組み合わせた複数のクラウドにアプリケーションを展開しています。これが、新たな現実であるマルチクラウドです。
このように状況が急速に変化する中でも、クラウドの導入を遅らせる要因がいくつかあります。最初の課題はマルチクラウドの無秩序な拡大です。既存のアプリケーションが「リフト＆シフト」され、「クラウドネイティブ」なアプリケーションが計画も管理もされないまま導入されています。さらに、組織は短期的なニーズに対応するため、互いに異なるクラウドプラットフォームやアーキテクチャ、さまざまなアプリケーションサービス、複数のツールセットを使用する傾向があります。その結果、企業全体のアーキテクチャが複雑化し、アプリケーションをある環境から別の環境へ移行することがはるかに難しくなるだけでなく、コストも増大します。
こうした課題があるにもかかわらず、今後数年間で、パブリッククラウドとプライベートクラウドへの新規導入や両者をまたぐ導入は確実に増加します。マルチクラウド時代が目前に迫る今、企業には、限られたアプリケーションのサポートや、ハードウェアおよび単一クラウドのみでの運用にとどまらない、インテリジェントなアプリケーションサービスとADCの導入が求められています。
まとめ
ADCは、かつてロードバランサーが占めていたネットワーク上の重要な位置付けを自然な形で受け継ぎ、進化したものです。従来のデバイスから多くを継承しながらも、可用性だけでなく、パフォーマンスとセキュリティも提供する、明確に異なる新しい種類の製品です。その名が示すとおり、アプリケーションを可能な限り最適な方法で配信するためのあらゆる側面を担います。
アプリケーションインテリジェンス、SSLオフロード、プログラマティックインターフェースなどの高度な機能を備えた最新のADCは、組織のビジネス拡大を支援し、いつでもどこでもユーザーにリーチできるようにします。技術分野のニーズが絶えず変化する中、ADCはマルチクラウド環境やコンテナ環境の最新テクノロジーにも、より柔軟に適応できます。
最終的に、ADCは、アプリケーションをより高速かつスマートでセキュアに配信するための主要な経路および統合ポイントとなるだけでなく、進化を続け、クラウドファーストの世界に対応していくといえるでしょう。
2017年9月10日公開