application配信コントローラの進化

今日のダイナミックな世界では、組織は常に世界中の何百万ものユーザーに重要なapplicationsを提供するという課題に直面しています。 アプリをスケーラブルかつ安全で、利用可能なものにするために、ネットワーク サービスとapplicationサービスを展開することが非常に重要です。 これが、application配信コントローラー (ADC) の進化の背後にある主な理由の 1 つです。 ただし、基本的なロードバランシングテクノロジの確固たる基盤がなければ、これらの機能はいずれも実装できません。 それでは、まず、ロードバランシングの重要性、それが効率的なapplication配信にどのようにつながるか、そして ADC がどのように進化し、クラウドファーストの世界を取り入れているかを理解することから始めましょう。

負荷分散の目的は、多数の物理サーバー間で着信ネットワークまたはapplicationトラフィックのバランスを取り、それらのサーバーを外部から 1 つのサーバーのように見せることです。 これを行う理由はたくさんありますが、主な推進力は「スケーラビリティ」、「高可用性」、および「予測可能性」の必要性です。

スケーラビリティとは、既存のパフォーマンスに影響を与えることなく、増加した負荷に動的に、または簡単に適応する能力です。 一方、高可用性 (HA) とは、1 つ以上のシステムに障害が発生した場合でも、サイトが利用可能かつアクセス可能な状態を維持する機能です。 サービス仮想化 (ソフトウェア コンポーネントの動作を模倣してapplication開発を加速およびテストする) は、スケーラビリティと可用性の両方にとって興味深い機会を提供します。 サービスまたはユーザー接点が実際のサーバーから分離されている場合は、サーバーを追加することでapplicationを拡張できます。 さらに、個々のサーバーに障害が発生しても、application全体が使用できなくなることはありません。 予測可能性は、HA の一部と、その過程で学んだいくつかの教訓を表すため、やや明確ではありません。 可用性とパフォーマンスに関して、サービスがいつどのように提供されるかを制御することと表現するのが最も適切です。

商業インターネットの初期の頃、多くのドットコム億万長者志望者たちは、自分たちの計画に重大な問題があることに気付きました。 メインフレームには Web サーバー ソフトウェアがありませんでした (少なくとも AS/400e までは)。また、あったとしても、スタートアップの予算では購入できませんでした。 彼らが購入できたのは、広く普及している PC メーカーの標準的な既成のサーバー ハードウェアでした。 それらのほとんどの企業の主な問題は、ビジネスで発生するトラフィックの量を単一の PC ベースのサーバーで処理することは不可能だということでした。 そして、それがダウンすると、オフラインになり、ビジネスができなくなります。 幸いなことに、その人たちの中には、その特定の問題を解決することで何百万ドルも稼ごうと計画している人もいました。 これにより、負荷分散が誕生しました。

市販の専用ロードバランシングデバイスが登場する以前は、既存のテクノロジーを利用してスケーラビリティと可用性の目標を達成する試みが数多くありました。 最も普及していた（そして現在でも使用されている）テクノロジーは DNS ラウンドロビンでした。

この方法では、DNS は同じ DNS 名で、異なるサーバーに多数の一意の IP アドレスを割り当てます。 つまり、ユーザーが初めて「 www.example.com 」の解決を要求したときに、DNS サーバーは、各新しい接続を行の一番下の行に到達するまで最初のサーバーに渡し、その後、再び最初のサーバーに戻ります。 このソリューションはシンプルで、一連のマシン間で接続を均等に分散できるようになりました。

スケーラビリティの観点から見ると、このソリューションは DNS 名にほぼ無制限の数のサーバーを追加する機会を提供したため、非常にうまく機能しました。 しかし、可用性に関しては、DNS にはリストされているサーバーが動作しているかどうかを知る機能がないため、このソリューションは障害を生み出しました。 サーバーが利用できなくなり、ユーザーがアクセスしようとした場合、そのリクエストはダウンしているサーバーに送信される可能性があります。

DNS ラウンドロビンのもう 1 つの推進力は予測可能性です。これは、ユーザーが特定のサーバーに送信されるという高いレベルの信頼性です。 これは、永続性というアイデアを中心に据えています。永続性とは、セッションが開始された後、またはユーザーが以前に中断したセッションを再開したときに、ユーザーが新しいサーバーに負荷分散されないようにするという概念です。 これは DNS ラウンドロビンでは解決できなかった非常に重要な問題です。

この問題に対処するために、最初に専用に構築されたソリューションの 1 つは、applicationソフトウェアまたはapplicationサーバーのオペレーティング システム (OS) に直接組み込まれた負荷分散でした。 開発した企業の数だけさまざまな実装がありましたが、ほとんどのソリューションは基本的なネットワークのトリックを中心に展開されていました。 たとえば、このようなソリューションの 1 つでは、すべてのサーバーがプール (クラスターとも呼ばれます) 内にあり、それぞれのサーバーに独自の物理 IP アドレスが割り当てられていました。

ユーザーがサービスに接続しようとすると、サーバーの物理 IP ではなくプール IP に接続されました。 プール内のどのサーバーが最初に接続要求に応答したかによって、ユーザーは物理 IP アドレス (自分の IP アドレスまたはプール内の別のシステム) にリダイレクトされ、サービス セッションが開始されます。 このソリューションの主な利点の 1 つは、application開発者がさまざまな情報を使用して、クライアントが接続する物理 IP アドレスを決定できることです。 たとえば、プール内の各サーバーに、各プール メンバーがすでに処理しているセッションの数を記録しておき、新しいリクエストを最も使用率の低いサーバーに送信することができます。

当初、このソリューションのスケーラビリティは明らかでした。 新しいサーバーを構築し、それをプールに追加するだけで、applicationの容量を増やすことができました。 しかし、時間が経つにつれて、アプリケーションベースのロードバランシングプール メンバーは、次の接続を誰に送るべきかについて互いに常に連絡を取り合う必要があったため、プールに新しいサーバーが追加されるたびに、プール メンバー間のネットワーク トラフィックが急激に増加しました。 プールが一定のサイズ (通常は 5 ～ 10 台のホスト) に拡大すると、このトラフィックはエンド ユーザーのトラフィックだけでなく、サーバー自体のプロセッサ使用率にも影響を与え始めます。 したがって、少数のサーバー (ちなみに、DNS ラウンドロビンよりも少ない) を超える必要がない限り、スケーラビリティは優れています。

DNS ラウンドロビンとソフトウェア負荷分散により HA が大幅に向上しました。 プール メンバーは互いに常に通信しており、application開発者は豊富なapplication知識を使用してサーバーが正常に動作しているかどうかを知ることができたため、これらのソリューションにより、ユーザーが要求を処理できないサーバーにアクセスする可能性が事実上排除されました。 ただし、インテリジェンスを有効にする HA 特性の各反復は、対応するサーバーおよびネットワークの使用率に影響を与え、スケーラビリティをさらに制限することを指摘する必要があります。 HA によるもう 1 つのマイナスの影響は、信頼性の領域にありました。 これらのシステムでトラフィックを分散するために使用されるネットワーク トリックの多くは複雑であり、かなりのネットワーク レベルの監視が必要でした。 したがって、これらの配布方法では、application全体とapplicationネットワーク上のすべてのトラフィックに影響を及ぼす問題が頻繁に発生しました。

これらのソリューションにより予測可能性も向上しました。 application設計者は、ユーザーを負荷分散するのではなく、いつ、なぜ同じサーバーに戻す必要があるかを知っていたため、必要に応じてユーザーが永続的に存在し続けるようにするロジックを埋め込むことができました。 また、同じ「プーリング」テクノロジを使用して、サーバー間でユーザー状態情報を複製し、そもそも永続性を必要とするインスタンスの多くを排除しました。 最後に、applicationに関する深い知識のおかげで、サーバー負荷の適切な指標とは限らない接続などの情報ではなく、applicationの実際の健全性に基づいた負荷分散アルゴリズムをより適切に開発できるようになりました。

真のスケーラビリティに対する潜在的な制限と信頼性の問題に加えて、独自のアプリケーション ベースの負荷分散にはさらに 1 つの欠点がありました。 開発と保守はapplicationベンダーに依存していました。 ここでの主な問題は、すべてのapplicationsが負荷分散 (またはプーリング) テクノロジを提供しているわけではなく、提供しているアプリケーションでも他のapplicationベンダーが提供するテクノロジと連携しないことが多かったことです。 ベンダー中立の OS レベルの負荷分散ソフトウェアを作成した組織はいくつかありましたが、残念ながら、同じスケーラビリティの問題に悩まされていました。 また、applicationsとの緊密な統合がなければ、これらのソフトウェア「ソリューション」は追加の HA 課題も経験します。

専用の負荷分散の 2 番目の反復は、ネットワーク ベースのアプライアンスとして登場しました。 これらは、今日のapplication配信コントローラーの真の創始者です。 これらのアプライアンスは物理的にはapplications自体の外部に存在し、ロード バランサーとして開始されましたが、NAT などのより単純なネットワーク技術を使用してロード バランシングを実現しました。 これらのデバイスは外部に仮想サーバアドレスを提示し、ユーザーが接続を試みると、デバイスは最も適切な実サーバーに接続を転送します。

ロード バランサは、どのサーバーがどの接続を受信するかを正確に制御し、ますます複雑になる「ヘルス モニター」を使用して、applicationサーバー (実際の物理サーバー) が必要に応じて応答していることを確認しました。 サーバーが正しく応答しなかった場合、ロード バランサーは、目的の応答が生成されるまでそのサーバーへのトラフィックの送信を自動的に停止します。 ヘルス モニターは、application開発者自身が構築したものほど包括的であることはほとんどありませんでしたが、ネットワーク ベースのハードウェア アプローチにより、ほぼすべてのapplicationに一貫した方法で基本的な負荷分散サービスを提供できるようになりました。これにより、最終的に、applicationサーバーに固有の、真に仮想化されたサービス エントリ ポイントが作成されました。

スケーラビリティの観点から見ると、ソフトウェア ベースの負荷分散をハードウェア ベースのソリューションに置き換え始めた組織では、サーバーの使用率が劇的に低下しました。 これにより、短期的には追加のサーバーを購入する必要がなくなり、長期的には ROI の向上につながりました。

同様に、HA はソリューションの複雑さを軽減し、アプリケーションに偏らないロードバランシングを実現し、ソリューションとしての信頼性と深みを高めます。 ネットワークベースの負荷分散ハードウェアにより、ビジネス オーナーは、組み込みのロードバランシング機能を使用して、一部のアプリケーションではなく、すべてのapplicationsに高いレベルの可用性を提供できるようになりました。

予測可能性は、ネットワークベースの負荷分散ハードウェアによって追加されたコア コンポーネントでした。 新しい接続がどこに向けられるかを予測し、操作することがはるかに簡単になりました。 これらのデバイスはプロセスにインテリジェンスを追加し、制御された負荷分散 (動的 DNS の制御されていない分散とは対照的) の作成に役立ちました。 これにより、ビジネスオーナーはサーバーの負荷処理能力に基づいてサーバーに負荷を分散できるようになりました。

ネットワークベースのロード バランサと仮想化の登場により、applicationサーバーの ID をインターネット コミュニティから隠したり、サーバーから接続を「遮断」してユーザーに影響を与えずにメンテナンスのためにサーバーをオフラインにしたりする機能など、セキュリティと管理に新たな利点がもたらされました。 これが ADC の起源となった基礎です。

フルプロキシでもある中央負荷分散機能により、IT 部門は新しいサービスや新興サービスを重ねて統合するのに最適な場所を見つけました。 これにより、負荷分散デバイスは拡張可能な ADC プラットフォームへと進化しました。 簡単に言えば、プロキシは負荷分散の基礎であり、ADC を可能にする基盤となるテクノロジーです。  

ADC セキュリティについて議論する場合、プロキシ (基本テクノロジ) によって作成される仮想化が重要です。 SSL/TLS 暗号化オフロード、集中認証、さらにはアプリケーション対応ファイアウォールについて議論する場合でも、これらのソリューションの威力は、ロード バランサ (ハードウェアまたは仮想エディション) がすべてのapplicationsにわたる仮想化の集約ポイントであるという事実にあります。 集中認証は典型的な例です。 従来の認証および承認メカニズムは、常にapplication自体に直接組み込まれてきました。 アプリケーション ベースの負荷分散と同様に、各実装は各アプリケーションの実装に依存し、それぞれに固有のものであったため、多数の異なる方法が存在しました。 代わりに、すべてのapplicationsに対して仮想化されたエントリ ポイントで認証を適用することで、単一の統一された認証方法を適用できます。 これにより、認証システムの設計と管理が大幅に簡素化されるだけでなく、その機能を実行する必要がなくなるため、applicationサーバー自体のパフォーマンスも向上します。 さらに、特に自社開発のapplicationsでは、個別のapplicationごとに認証プロセスを開発するために時間と費用を費やす必要がなくなります。

可用性は、スケーラビリティ、高可用性、予測可能性など、すべての基本的なロード バランサ属性に関連しているため、元のロード バランサに結び付ける最も簡単な ADC 属性です。 ただし、ADC はロード バランサよりもさらに高度な機能を備えています。 ADC の可用性は、applicationの依存関係や動的プロビジョニングなどの高度な概念も表します。 ADC は、applicationsが自己完結型で動作することはほとんどないことを理解できます。 多くの場合、設計を実現するために他のapplicationsに依存します。 この知識により、他のプロセスも考慮してapplicationの可用性を提供する ADC の能力が向上します。 市場で最もインテリジェントな ADC は、外部入力に基づいてサービスを提供する方法を動的に変更できるプログラム インターフェイスも提供します。 これらのインターフェースにより、クラウドやコンテナ化されたデプロイメントなどの最新の環境に必要な動的なプロビジョニングと自動スケールアップ/ダウンが可能になります。

パフォーマンスの向上は、ロードバランシングの概念に対するもう 1 つの明らかな拡張でした。 ロード バランサは、接続が利用可能なサービス (および許容可能な時間枠内で応答するサービス) に送信されるだけでなく、接続数やプロセッサ使用率が最も少ないサービスにも送信されるようにすることで、本質的にアプリケーションのパフォーマンスを向上させます。 これにより、新しい接続ごとに、それを最も適切に処理できるシステムによってサービスが提供されるようになりました。 その後、SSL/TLS オフロード (専用ハードウェアを使用) がロードバランシングサービスの一般的な定番となり、暗号化されたトラフィックの計算オーバーヘッドとバックエンド サーバーの負荷が削減され、パフォーマンスも向上しました。

今日の ADC はさらに進化しています。 これらのデバイスには、applicationsの全体的なパフォーマンスと配信をさらに向上させるためのキャッシュ、圧縮、さらにはレート シェーピング テクノロジが組み込まれていることがよくあります。 さらに、ADC は、これらのサービスを提供する従来のスタンドアロン アプライアンスの静的な実装ではなく、固有のアプリケーション インテリジェンスを使用して、パフォーマンス上の利点が得られる場合にのみこれらのサービスを適用し、その使用を最適化できます。

例えば、圧縮技術一般に信じられていることにもかかわらず、必ずしもapplicationのすべてのユーザーにとって有益であるとは限りません。 確かに、ボトルネックとなるのは実際のスループットなので、帯域幅が狭いユーザーはパケットが小さいほど大きなメリットが得られます。 長距離を移動する必要がある接続でも、パケットが小さくなるとデータを転送するための往復回数が減り、ネットワーク遅延の影響が軽減されるため、メリットが得られます。 ただし、帯域幅が大きい短距離接続（同じ大陸内など）では、圧縮を適用するとパフォーマンスが低下する可能性があります。 スループットは必ずしもボトルネックではないため、圧縮と解凍の追加オーバーヘッドによってレイテンシが増加し、パフォーマンスの観点からはスループットの増加では補えないことになります。 つまり、適切に管理されなければ、解決策としての圧縮技術は、元の問題よりも悪化する可能性があります。 しかし、全体的なパフォーマンスにメリットがある場合にのみ圧縮をインテリジェントに適用することで、ADC は圧縮テクノロジの使用とコストを最適化し、最も活用される機能にプロセッサ サイクルをより多く割り当てることができます。

デジタル トランスフォーメーションは非常に重要な戦略的課題であるため、多くの企業がクラウドへの移行を開始しています。 applicationsの数が増え、私たちを取り巻く世界が変化する中、クラウドに移行する組織は、俊敏性の向上、運用コストの適正化、オンデマンドのスケーラビリティ、コアビジネスへの集中など、多くのメリットを享受できると考えられています。  

「クラウド」は、共有コンピューティング、ストレージ、ネットワーク リソースの漠然とした単一のエンティティではなく、複数のグローバル ノードに展開されることが多いプロバイダー、インフラストラクチャ、テクノロジ、環境の複雑な組み合わせで構成されています。 これが、多くの企業が実際にapplicationsをパブリック クラウド、プライベート クラウド、さらにはそれらの組み合わせなど、さまざまなクラウドに導入している理由です。 これがマルチクラウド、新たな現実です。

このように急速に進化する環境にもかかわらず、クラウドの導入を遅らせる要因がいくつかあります。 最初の課題は、既存のapplicationsが「リフト アンド シフト」され、「クラウド生まれ」のapplicationsが計画も管理も​​されていない方法で導入される、マルチクラウドの無秩序な拡大です。 さらに、組織は短期的なニーズを満たすために、異なるクラウド プラットフォーム、異なるアーキテクチャ、さまざまなapplicationサービス、複数のツールセットを使用する傾向があります。 その結果、企業全体のアーキテクチャが複雑になり、applicationsをある環境から別の環境に移行することが非常に困難になり、コストも高くなります。

ADC は、過去のロード バランサが担っていた重要なネットワーク領域への自然な進化です。 ADC は昔のデバイスに大きく依存していますが、可用性だけでなくパフォーマンスとセキュリティも提供する、明らかに新しい種類のデバイスです。 名前が示すように、彼らはapplicationを可能な限り最良の方法で提供するためのあらゆる側面に関心を持っています。

アプリケーション インテリジェンス、SSL オフロード、プログラム インターフェイスなどの高度な機能を備えた最新の ADC は、組織がビジネスを拡大し、いつでもどこでもユーザーにリーチするのに役立ちます。 技術の世界ではニーズが絶えず変化しており、ADC はマルチクラウドやコンテナ環境の最新テクノロジーに適応する能力も向上しています。

結局のところ、ADC は、applicationsをより高速、スマート、安全に配信するための主要な導管および統合ポイントになるだけでなく、クラウド ファーストの世界を進化させ、取り入れ続けると言っても過言ではありません。