負荷分散の基礎: ナットとボルト

今日のダイナミックでアプリケーション中心の市場において、組織は顧客が期待する情報、サービス、エクスペリエンスを迅速かつ確実に安全に提供することへのプレッシャーにさらされています。 負荷分散、暗号化、アクセラレーション、セキュリティなどの主要なネットワークおよびアプリケーション機能は、物理サーバーのプロキシとして機能する物理または仮想アプライアンスであるアプリケーション配信コントローラ (ADC) を介して提供できます。 アプリケーションの爆発的な増加と、継続的インテグレーションと継続的デプロイメント (CI/CD) の厳格なサイクルによって組織に課せられる要求により、ADC の市場が 2020 年までに年間 29 億ドルに達すると予測されているのも不思議ではありません。¹

しかし、未来に向かう前に、私たちがここに至った経緯を見てみましょう。 ネットワークベースの負荷分散は、ADC が動作するための重要な基盤です。 1990 年代半ばに、最初の負荷分散ハードウェア アプライアンスが登場し、サーバーやネットワーク全体にワークロードを分散することで、組織がアプリケーションを拡張できるように支援し始めました。 これらの最初のデバイスはアプリケーションに中立であり、アプリケーション サーバー自体の外部に存在していたため、簡単なネットワーク技術を使用して負荷分散を行うことができました。 本質的には、これらのデバイスは外部に「仮想 IP アドレス」を提示し、ユーザーが接続を試みると、双方向ネットワーク アドレス変換 (NAT) を実行する最も適切な実サーバーに接続を転送します。

しかし、仮想化とクラウド コンピューティングの登場により、ハイパーバイザー上で実行することを目的としたソフトウェア配信の仮想エディションとして、負荷分散 ADC の新しいイテレーションが登場しました。 現在、仮想アプライアンスは、専用ハードウェア上で実行されるものと同じ幅広い機能を備えたアプリケーション サービスを提供できます。 さらに、これらの仮想エディションにより、仮想、クラウド、ハイブリッド環境間でアプリケーション サービスを移動する際に発生する複雑さが大幅に軽減され、組織はプライベート クラウド環境またはパブリック クラウド環境でアプリケーション サービスを迅速かつ簡単に開始できるようになります。

データ センターを襲った最新のトレンドはコンテナ化です。コンテナ化は、分散アプリケーションの導入と実行に役立つアプリケーション仮想化の手法です。 このプロセスでは、アプリケーションを分離し、共有 OS 上の明確に区切られたメモリ領域に格納します。これにより、仮想アプライアンスを構築するよりもアプリケーションの開発と展開が容易になるだけでなく、開発期間も短縮されます。 移植性とパフォーマンスが劇的に向上するため、コンテナ化により、企業はより優れたスケーラビリティと俊敏性を実現できます。 将来的には、コンテナ アーキテクチャにより、組織はさまざまなクラウド環境をより有効に活用できるようになります。

今日の ADC は、最初のロード バランサーからサービス仮想化プロセスを経て進化しました。 そして現在、ソフトウェアのみの仮想エディションにより、ADC は可用性を向上させるだけでなく、組織がビジネスに必要なスケーラブルで高性能かつ安全なアプリケーションを提供できるようにもなります。 しかし、結局のところ、これらすべての仮想化アプリケーション サービス、共有インフラストラクチャの展開、インテリジェント ルーティング機能は、負荷分散テクノロジの強固な基盤がなければ実現できません。

企業がダイナミックに進化する市場の複雑な課題にどう対処できるかを理解するために、アプリケーション配信の基礎を探ってみましょう。 負荷分散の基礎。

始める前に、負荷分散の基本的な用語を確認しましょう。 誰もが同じ用語を使用すれば、これは簡単になりますが、残念ながら、負荷分散デバイス (および ADC) の各ベンダーはそれぞれ異なる用語を使用しているようです。 しかし、少し説明すれば、混乱を解消することができます。

ほとんどの負荷分散 ADC は、ノード、ホスト、メンバー、またはサーバーの概念を利用します。4 つすべてを備えているものもありますが、意味は異なります。 これらの用語はすべて、2 つの基本的な概念を表現しようとしています。 1 つの概念 (通常はノードまたはサーバーと呼ばれます) は、ADC からトラフィックを受信する物理サーバーまたは仮想サーバー自体の概念です。これは物理サーバーの IP アドレスと同義であり、ロード バランサーがない場合、サーバー名 (たとえば、www.example.com) が解決される IP アドレスになります。 このホワイト ペーパーの残りの部分では、この概念をホストと呼びます。

2 番目の概念は、「メンバー」という用語で表現されます (残念ながら、一部のメーカーではノードとも呼ばれます)。 メンバーは通常、トラフィックを受信する実際のアプリケーションの TCP ポートを含むという点で、ホストよりも少し定義が明確です。 たとえば、www.example.com という名前のホストは、ホストを表すアドレス 172.16.1.10 に解決され、TCP ポート 80 でアプリケーション (Web サーバー) が実行されている場合、メンバー アドレスは 172.16.1.10:80 になります。 簡単に言えば、メンバーには、アプリケーション ポートの定義と物理/仮想サーバーの IP アドレスが含まれます。 このホワイト ペーパーの残りの部分では、これをサービスと呼びます。

なぜこんなに複雑なのでしょうか? サーバーとその上で実行されるアプリケーション サービスを区別することで、ロード バランサーは、データセンターまたはクラウド内の基盤となるハードウェアやハイパーバイザーではなく、アプリケーションと個別に対話できるようになります。 ホスト (172.16.1.10) では、複数のサービス (HTTP、FTP、DNS など) が利用可能である場合があります。 各アプリケーションを一意に定義することにより (たとえば、172.16.1.10:80、172.16.1.10:21、および 172.16.1.10:53)、ADC はホストではなくサービスに基づいて、一意の負荷分散とヘルス モニタリング (後で説明する概念) を適用できます。

覚えておいていただきたいのは、ほとんどの負荷分散ベースのテクノロジーでは、ホストまたは物理サーバーを表すために 1 つの用語が使用され、その上で利用可能なサービスを表すために別の用語が使用されるということです (この場合は、単にホストとサービス)。

負荷分散により、組織はパブリック クラウドまたはプライベート クラウドでの展開を含む複数のバックエンドの宛先に受信アプリケーション トラフィックを分散できます。 したがって、バックエンドの宛先のコレクションという概念が必要になります。 クラスター (プールまたはファームとも呼ばれます) は、任意の数のホストで利用可能な同様のサービスの集合です。 たとえば、会社の Web ページを提供するすべてのサービスは、「会社の Web ページ」というクラスターに集められ、電子商取引サービスを提供するすべてのサービスは、「電子商取引」というクラスターに集められます。

仮想サーバーは、実際のサーバー (物理サーバー、仮想サーバー、またはコンテナ) のプロキシです。 仮想 IP アドレスと組み合わせると、これが外部に公開されるアプリケーション エンドポイントになります。

これらの用語を理解することで、負荷分散の基礎を理解できます。 負荷分散 ADC は仮想サーバーを外部に公開します。 各仮想サーバーは、1 つ以上の物理ホスト上に存在するサービスのクラスターを指します。

図 2 は実際の展開を代表するものではないかもしれませんが、負荷分散とアプリケーション配信のプロセスについての説明を続けるための基本的な構造を提供します。

この共通語彙が確立されたので、アプリケーションが顧客に配信される簡単なトランザクションを調べてみましょう。 図に示すように、負荷分散 ADC は通常、クライアントと、クライアントが使用したいサービスを提供するホストの間にインラインで配置されます。 アプリケーション配信におけるほとんどのことと同様に、この配置はルールではなく、あらゆる種類の展開におけるベスト プラクティスです。 また、ADC には、2 つのサービス ポイントで構成されるクラスターを指す仮想サーバーがすでに構成されていると仮定します。 この展開シナリオでは、戻りトラフィックがクライアントに戻る途中でロード バランサを介して処理されるように、ホストにロード バランサに戻る戻りルートがあるのが一般的です。

基本的なアプリケーション配信トランザクションは次のとおりです。

• クライアントはサービスに接続しようとします。
• ADC は接続を受け入れ、どのホストが接続を受信するかを決定した後、選択したホストのサービスに合わせて宛先 IP (および場合によってはポート) を変更します (クライアントの送信元 IP は変更されないことに注意してください)。
• ホストは接続を受け入れ、デフォルト ルートである ADC を介して元のソースであるクライアントに応答を返します。
• ADC はホストからの戻りパケットを傍受し、送信元 IP (および可能なポート) を仮想サーバーの IP とポートに一致するように変更し、パケットをクライアントに転送します。
• クライアントは、返信パケットが仮想サーバーから送信されたものであると信じて受信し、プロセスを続行します。

この非常に単純な例は比較的わかりやすいですが、注目すべき重要な要素がいくつかあります。 まず、クライアントが認識している限り、仮想サーバーにパケットを送信し、仮想サーバーが応答します。これは簡単です。 次に、NAT が実行されます。 ここで、ADC は、(仮想サーバーの) クライアントから送信された宛先 IP を、要求の負荷分散先として選択したホストの宛先 IP に置き換えます。 3 番目は、このプロセスの中で NAT を「双方向」にする部分です。 ホストからの返信パケットの送信元 IP はホストの IP になります。このアドレスが変更されず、パケットが単にクライアントに転送された場合、クライアントは要求していない相手からパケットを受信することになり、そのパケットを単にドロップします。 代わりに、ロード バランサは接続を記憶し、送信元 IP が仮想サーバーの IP になるようにパケットを書き換えることで、この問題を解決します。

通常、この時点で、次の 2 つの疑問が生じます。 負荷分散 ADC は、接続を送信するホストをどのように決定しますか? 選択したホストが動作していない場合はどうなりますか?

まず2番目の質問について議論しましょう。 選択したホストが動作していない場合はどうなりますか? 簡単な答えは、クライアントの要求に応答せず、接続の試行が最終的にタイムアウトして失敗するということです。 これは明らかに、高可用性が保証されないため、好ましい状況ではありません。 そのため、ほとんどの負荷分散テクノロジには、ホストへの接続の送信を試みる前に、ホストが実際に利用可能かどうかを判断するための、ある程度のヘルス モニタリングが含まれています。

ヘルスモニタリングには複数のレベルがあり、それぞれ粒度と焦点が高まっていきます。 基本的なモニターは、ホスト自体に ping を実行するだけです。 ホストが ping に応答しない場合は、ホスト上で定義されているすべてのサービスがダウンしている可能性があり、利用可能なサービスのクラスターから削除する必要があると考えられます。 残念ながら、ホストが ping に応答したとしても、必ずしもサービス自体が動作していることを意味するわけではありません。 したがって、ほとんどのデバイスは、単純な TCP 接続からスクリプトまたはインテリジェントな対話によるアプリケーションとの対話に至るまで、何らかの「サービス ping」を実行できます。 これらの高レベルのヘルスモニターは、ホストではなく実際のサービスの可用性に対する信頼性を高めるだけでなく、ロードバランサーが単一のホスト上の複数のサービスを区別することも可能にします。 ロード バランサは、1 つのサービスが利用できない可能性がある一方で、同じホスト上の他のサービスは正常に動作している可能性があり、ユーザー トラフィックの有効な宛先として引き続き考慮される必要があることを認識します。

これで最初の質問に戻ります。 ADC は接続要求を送信するホストをどのように決定するのでしょうか? 各仮想サーバーには、可能性のあるリストを構成する特定の専用サービス クラスター (そのサービスを提供するホストをリストします) があります。 さらに、ヘルス モニタリングでは、そのリストを変更して、指定されたサービスを提供する「現在利用可能な」ホストのリストを作成します。 ADC は、この変更されたリストから新しい接続を受信するホストを選択します。 正確なホストの決定は、その特定のクラスターに関連付けられた負荷分散アルゴリズムによって異なります。 これらのアルゴリズムには、最小接続数、動的比率、単純なラウンドロビンなどがあり、ロード バランサはリストの上から順に下っていき、新しい接続を次のホストに割り当てます。リストの一番下に到達すると、上から再び開始します。 これは単純で非常に予測可能ですが、バックエンド ホスト上のすべての接続の負荷と期間が同様であると想定していますが、これは必ずしも当てはまりません。 より高度なアルゴリズムでは、現在の接続数、ホストの使用率、さらにはホストへの既存のトラフィックの実際の応答時間などを使用して、利用可能なクラスター サービスから最も適切なホストを選択します。

十分に高度なアプリケーション配信システムでは、ヘルス監視情報と負荷分散アルゴリズムを統合して、サービスの依存関係を把握することもできます。 これは主に、単一のホストに複数のサービスがあり、そのすべてがユーザーのリクエストを完了するために必要な場合に便利です。 このような場合、1 つのサービスが稼働しているが、他のサービスが稼働していないホストにユーザーがアクセスすることは望ましくありません。 つまり、ホスト上の 1 つのサービスに障害が発生した場合、ホストの他のサービスも利用可能なサービスのクラスター リストから削除する必要があります。 HTML とスクリプトによってサービスが差別化されるにつれて、この機能はますます重要になります。

クライアントがトランザクション要求を開始したときに利用可能なサービスを選択する負荷分散の部分は、ソリューションの半分にすぎません。 接続が確立されると、ADC はそのユーザーからの後続のトラフィックを負荷分散する必要があるかどうかを追跡する必要があります。 一般に、負荷分散された後続のトラフィックを処理する際には、接続の維持と永続性という 2 つの特定の問題があります。

ユーザーが長時間TCP接続（ポート21）を利用しようとしている場合： FTP、ポート 23: すぐに閉じない接続 (Telnet など) の場合、ロード バランサは、その接続を介して伝送される複数のデータ パケットが他の利用可能なサービス ホストに負荷分散されないようにする必要があります。 これは接続の維持であり、2 つの主要な機能が必要です。 1 つ目は、開いている接続とそれらが属するホスト サービスを追跡する機能です。 次に、ロード バランサーは接続が閉じられたときに接続テーブルを更新できるように、その接続を継続的に監視できる必要があります。 これはほとんどの ADC にとって標準的なものです。

しかし、クライアントが複数の短命 TCP 接続 (たとえば、ポート 80) を使用する場合がますます一般的になっています。 単一のタスクを実行するために HTTP を使用します。 標準的な Web ブラウジングなど、場合によっては問題にならず、新しいリクエストはバックエンド サービス ホストのいずれかに送信できます。ただし、同じユーザーからの複数の接続が同じバックエンド サービス ホストに送信され、負荷分散されないことが非常に重要であるインスタンス (XML、電子商取引など) も多数あります。 この概念は永続性またはサーバー アフィニティと呼ばれます。

プロトコルと望ましい結果に応じて、これに対処する方法は複数あります。 たとえば、最新の HTTP トランザクションでは、サーバーは「キープアライブ」接続を指定できます。これにより、複数の短命接続が 1 つの長命接続に変換され、他の長命接続と同様に処理できるようになります。 しかし、これはほんのわずかな救済策にしかすぎません。主な理由は、Web サービスやモバイル サービスの使用が増えるにつれて、すべての接続を必要以上に長く開いたままにしておくと、システム全体のリソースに負担がかかるためです。 そのため、今日では、スケーラビリティと移植性のために、多くの組織が API に依存するステートレス アプリケーションの構築に移行しています。 これは基本的に、リソースの負荷を軽減するためにサーバーがすべてのセッション情報を忘れることを意味し、このような場合、状態はセッション ID を渡すことによって、また永続性の概念を通じて維持されます。

最も基本的な永続性の形式の 1 つは、ソース アドレス アフィニティです。これは、着信要求のソース IP アドレスと、それらの要求が負荷分散されたサービス ホストを単純に記録し、今後のすべてのトランザクションが同じホストに送信されるようにします。 これを実現するには、SSL セッション ID と Cookie を使用する 2 つの方法があります。 SSL 永続性は、SSL セッション ID を使用して SSL セッションを追跡します。つまり、クライアントの IP アドレスが変更された場合でも、ロード バランサはセッション ID に基づいてセッションが永続的であることを認識します。Cookie ベースの永続性では、クライアントのコンピュータに Cookie を挿入してセッションを一意に識別し、リクエストでその Cookie を参照して正しいサーバーに接続するオプションが提供されます。

現在、ADC のインテリジェンスにより、組織はデータ パケットを開いて、その中のほぼすべてのものの永続テーブルを作成できます。 これにより、ユーザー名などの固有の情報を使用して永続性を維持できるようになります。 ただし、組織は、この識別可能なクライアント情報がすべてのリクエストに存在することを確認する必要があります。この情報のないパケットは保持されず、再度負荷分散され、アプリケーションが破損する可能性が高くなります。

当初、負荷分散はネットワーク全体にワークロードを分散し、アプリケーションとサービスの可用性を確保することに重点を置いていました。 しかし、テクノロジーが進化するにつれて、ロード バランサはアプリケーション配信のプラットフォームとなり、組織の重要なアプリケーションの可用性とセキュリティが確保されるようになりました。 基本的な負荷分散はアプリケーション配信の基盤であり続けますが、最新の ADC ははるかに強化された機能を提供します。

企業は、アプリケーションにアクセスできるだけでは、それが使用可能になるわけではないことを認識しています。また、使用できないアプリケーションは、それを導入する組織にとって時間とコストの無駄を意味します。 ここで、最新の ADC が登場します。これにより、組織は SSL/TLS オフロード、キャッシュ、圧縮、レート シェーピング、侵入検知、アプリケーション ファイアウォール、さらにはリモート アクセスなどのネットワーク ベースのサービスを、すべてのアプリケーション サービスとすべてのホストで共有および再利用できる単一の戦略ポイントに統合し、仮想化されたアプリケーション配信ネットワークを作成できます。 これにより、ネットワーク、アプリケーション、運用の各チームは、セキュリティの必要性を犠牲にすることなく、より短い配信期間とより優れたスケーラビリティを求めるビジネス要求に適切に対応できるようになります。

高度なアプリケーション配信の仕組みと ADC の将来について詳しく知りたい場合は、 「アプリケーション配信コントローラーの進化」と「従来の負荷分散を超えて」をお読みください。