ロード バランシング101：基本

今日のダイナミックでアプリケーション中心の市場で、組織は顧客が期待する情報、サービス、エクスペリエンスを迅速かつ安全に、高い信頼性で提供しなければならないというプレッシャーにさらされ、それはますます強まっています。ロード バランシング、暗号化、アクセラレーション、セキュリティなど、ネットワークとアプリケーションの重要な機能は、物理サーバーの代わりに機能する物理または仮想アプライアンスであるアプリケーション デリバリ コントローラ（ADC）を介して提供することができます。アプリケーションの爆発的な増加と、継続的インテグレーションと継続的デリバリ（CI/CD）の厳格なサイクルが組織に求める対応を考えると、ADCの市場が2020年までに年間29億ドルに達すると予測されているのも頷けます。¹

ここで、未来を考える前に、私たちがここにどのようにして到達したかを見てみましょう。ネットワークベースのロード バランシングは、ADCが動作する上で不可欠な基盤です。1990年代半ばに、最初のロード バランシング ハードウェア アプライアンスが使われ始め、ワークロードをサーバーとネットワークに分散させることで、組織がアプリケーションを拡張できるようになりました。これらの最初のデバイスはアプリケーションに依存せず、アプリケーション サーバーの外部に存在していたため、簡単なネットワーク技術を使用してロード バランシングを行うことができました。要するに、これらのデバイスは「仮想IPアドレス」を外部に提示し、ユーザーが接続しようとすると、双方向のネットワークアドレス変換（NAT）を行って、最も適切な実際のサーバーに接続を転送していました。

しかし、仮想化とクラウド コンピューティングの出現とともに、ハイパーバイザー上で実行することを意図したソフトウェア提供型の仮想エディションである新しい形のロード バランシングADCが登場しました。今日では、仮想アプライアンスは、専用のハードウェア上で実行するのと同じように、幅広い機能を持つアプリケーション サービスを提供することができます。さらに、これらの仮想エディションでは、仮想、クラウド、およびハイブリッド環境間でのアプリケーション サービスの移動に伴う複雑さの多くが排除され、企業はプライベート クラウドまたはパブリック クラウド環境でアプリケーション サービスを迅速かつ容易に立ち上げることができます。

データ センタを直撃している最新のトレンドはコンテナ化であり、これは分散アプリケーションの展開や運用に役立つアプリケーションの仮想化の手法です。このプロセスでは、アプリケーションを分離し、共有OS上の明確に区切られたメモリ空間にアプリケーションを格納するため、仮想アプライアンスを構築するよりもアプリケーションの開発や展開が容易になるだけでなく、より迅速に行うことができます。移植性とパフォーマンスが飛躍的に向上するため、コンテナ化によりビジネスの拡張性と俊敏性が向上する可能性があります。また、将来的には、コンテナ アーキテクチャにより、組織がさまざまなクラウド環境をより有効に活用できるようになるでしょう。

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

ダイナミックに進化する市場の複雑な課題に企業がどのようにうまく対処できるかを理解するために、アプリケーション デリバリの基礎をロードバランシング101で探ってみましょう。

始める前に、ロード バランシングの基本的な用語を確認しましょう。誰もが同じ言葉を使っているなら簡単なのですが、残念ながら、ロード バランシング デバイス（そして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はホストの代わりにサービスに基づいて独自のロード バランシングと稼働状況の監視（後半で説明する概念）を調整することができます。

ほとんどのロード バランシング ベースの技術は、ホストまたは物理サーバーを表すためにある用語を使用し、その上で利用可能なサービスを表すために別の用語を使用していることを覚えておいてください。ここでいう、ホストとサービスです。

ロード バランシングにより、組織は、パブリック クラウドやプライベート クラウドの導入を含め、複数のバック エンドの宛先にインバウンド アプリケーション トラフィックを分散させることができます。そのため、バックエンドの宛先の集合体という概念が必要になります。ここでその概念を指す用語がクラスタ（プールやファームとも呼ばれます）であり、任意の数のホスト上で利用可能な類似のサービスの集合体です。例えば、会社のWebページを提供するすべてのサービスは「会社のWebページ」というクラスタに集められ、eコマース サービスを提供するすべてのサービスは「eコマース」というクラスタに集められます。

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

これらの用語を理解できれば、ロード バランシングの基本を理解できます。ロード バランシングADCは仮想サーバーを外部に提示します。各仮想サーバーは、1つ以上の物理ホスト上に存在するサービスのクラスタを指します。

図2は実際の導入環境と異なるかもしれませんが、ロード バランシングとアプリケーション デリバリのプロセスについての説明を進めるための基本的な構造を示しています。

共通の用語を確立できたところで、アプリケーションがどのように顧客に提供されるかという単純なトランザクションを見てみましょう。図が示すように、ロード バランシングADCは通常、クライアントと、クライアントが使用したいサービスを提供するホストの間に配置されます。アプリケーション デリバリのほとんどのことと同様に、この配置はルールではなく、どのような導入でもあくまでベスト プラクティスです。また、ADCが、2つのサービス ポイントで構成されるクラスタを指す仮想サーバーで既に構成されていると仮定します。この導入シナリオでは一般的に、リターン トラフィックがクライアントに戻る途中でロード バランサを経由して処理されるように、ホストにロード バランサへのリターン ルートが設定されています。

基本的なアプリケーション デリバリ トランザクションは、以下のように進みます。

• クライアントがサービスへの接続を試みます。
• ADCは接続を受け入れ、どのホストがその接続を受信すべきかを決定した後、選択されたホストのサービスに一致するように宛先IP（そして可能であればポート）を変更します（クライアントの送信元IPには関与しないことに注意してください）。
• ホストは接続を受け入れ、そのデフォルトのルートであるADCを経由して元の送信元であるクライアントに応答します。
• ADCはホストからの戻りパケットを傍受し、送信元IP（そして可能であればポート）を仮想サーバーのIPとポートに一致するように変更し、パケットをクライアントに転送します。
• クライアントは戻りパケットを受信し、それが仮想サーバーから受け取ったものだと想定して処理を続けます。

この単純な例は比較的わかりやすいですが、注意すべき重要な要素がいくつかあります。まず、クライアントから見ると、クライアントが仮想サーバーにパケットを送信し、仮想サーバーが応答するという単純な構図です。2番目にNATが行われます。ここでは、ADCが（仮想サーバーの）クライアントから送られた宛先IPを、要求のロード バランシング先として選択したホストの宛先IPに置き換えます。3番目は、このプロセスでNATを「双方向」にする部分です。ホストからの戻りパケットの送信元IPは、ホストのIPになります。もしこのアドレスが変更されず、パケットが単にクライアントに転送された場合、クライアントは要求していない相手からのパケットを受け取ることになり、排除されてしまいます。そうならないために、ロード バランサが接続を覚えていて、送信元IPが仮想サーバーのIPになるようにパケットを書き換え、この問題を解決します。

通常、この時点で、「ロード バランシングADCはどのホストに接続を送信するかをどのように決定するのか」、そして「選択したホストが動作していない場合はどうなるのか」という2つの疑問が生まれます。

まず、「選択したホストが動作していない場合はどうなるのか」という2番目の疑問を見ていきましょう。答えは簡単で、ホストはクライアントの要求に応答せず、接続の試行が最終的にタイムアウトして失敗します。これでは高可用性を保証できないので、これは明らかに好ましい状況ではありません。そのため、ほとんどのロード バランシング技術では、接続を送信しようとする前にホストが実際に利用可能かどうかを判断するために、何らかのレベルで稼働状況の監視が行われています。

稼働状況の監視にはいくつかのレベルがあり、レベルが上がると詳細度が上がり、注目点が増します。基本的な監視は単にホストにpingを実行するだけです。ホストがpingに応答しない場合、おそらくホスト上で定義されているサービスが停止しており、利用可能なサービスのクラスタから削除すべきだと判断されます。残念ながら、ホストがpingに応答したとしても、サービス自体が動作しているとは限りません。したがって、ほとんどのデバイスは、単純なTCP接続からスクリプトやインテリジェントなやり取りを介したアプリケーションとのやり取りに至るまで、何らかの「サービスping」を実行することができます。これらの高レベルの稼働状況モニターにより、（ホストではなく）実際のサービスの可用性に対する信頼が増すだけでなく、ロード バランサが1つのホスト上の複数のサービスを区別できるようになります。ロード バランサは、あるサービスが利用できなくても、同じホスト上の他のサービスは正常に動作しているかもしれず、それらのサービスはユーザー トラフィックの有効な宛先と見なされることを理解しています。

ここで、「ADCはどのホストに接続要求を送信するかをどのように決定するのか」という最初の疑問に戻ります。各仮想サーバーは、候補のリストに含まれているサービスの特定の専用クラスタ（そのサービスを提供するホストのリスト）を持っています。さらに、稼働状況を監視することでそのリストが修正され、指定されたサービスを提供する「現在利用可能な」ホストのリストが作成されます。ADCは、この修正されたリストを使用して、新しい接続を受け取るホストを選択します。実際にどのホストにするかは、そのクラスタに関連付けられているロード バランシング アルゴリズムによって決まります。これらのアルゴリズムの一部として、最小接続、動的比率、単純なラウンド ロビンなどがあり、これらではロード バランサが新しい接続をリストの一番上のホストから順番に割り当て、リストの最後に達したら、再びリストの一番上から始めます。これは単純で予測も簡単ですが、すべての接続がバックエンド ホストで同程度の負荷を生じ、時間も同じであることを前提としていて、これは必ずしも正しくありません。より高度なアルゴリズムでは、現在の接続数、ホストの利用率、ホストへの既存のトラフィックについての実際の応答時間などに基づいて、利用可能なクラスタ サービスの中から最も適切なホストを選択します。

非常に高度なアプリケーション デリバリ システムでは、ロード バランシング アルゴリズムと稼働状況監視情報を統合してサービス間の依存関係を把握することもできるでしょう。これは主に、1台のホストに、ユーザーの要求を実行するために必要なすべてのサービスがある場合に便利です。このような場合、あるサービスが動作していても他のサービスは動作していないホストにユーザーを送りたくはありません。言い換えれば、ホスト上の1つのサービスで障害が発生したら、そのホストの他のサービスも、利用可能なサービスのクラスタ リストから削除することが望まれます。この機能は、HTMLやスクリプトの使用によりサービスの分化が進むにつれ、ますます重要になっています。

クライアントがトランザクション要求を開始したときに利用可能なサービスを選択することは、ロード バランシング全体から見ると解決策の半分に過ぎません。接続が確立されると、ADCはそのユーザーからの後続のトラフィックのロード バランシングをすべきかどうかを把握する必要があります。ロード バランシングをした後の後続トラフィックの処理には、一般的に、接続のメンテナンスとパーシステンスという2つの問題があります。

ユーザーがすぐに閉じない長命のTCP接続（ポート21：FTP、ポート23：Telnetなど）を利用しようとしている場合、ロード バランサは、その接続を介して運ばれる複数のデータ パケットのロード バランシング先が利用可能な別のサービス ホストにならないようにする必要があります。これが接続のメンテナンスであり、これには2つの重要な機能が必要です。1つ目は、開いている接続とそれが属するホスト サービスを把握する機能です。2つ目は、接続が閉じたときにロード バランサが接続テーブルを更新できるように、その接続の監視を継続できる機能です。これは、ほとんどのADCで標準の機能です。

しかし、より一般的になってきているのは、クライアントが1つのタスクを達成するために複数の短命のTCP接続（例えば、ポート80：HTTP）を使用する場合です。標準的なWebブラウジングのように、新しい要求をどのバックエンド サービス ホストに送信してもよい場合もありますが、同じユーザーからの複数の接続は同じバックエンド サービス ホストに送信し、ロード バランシングを行わないことが非常に重要な場合も多くあります（XML、eコマースなど）。この概念をパーシステンスまたはサーバー アフィニティと呼びます。

これに対処する方法は、プロトコルと目的とする結果に応じていくつかあります。例えば、最新の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オフロード、キャッシング、圧縮、レート シェーピング、侵入検知、アプリケーション ファイアウォール、さらにはリモート アクセスなど、ネットワークベースのさまざまなサービスを1つの戦略的ポイントに統合し、すべてのアプリケーション サービスとすべてのホストで共有し、再利用できるようにして、仮想化されたアプリケーション デリバリ ネットワークを構築することが可能になりました。これにより、ネットワーク、アプリケーション、運用チームは、セキュリティに関するニーズを犠牲にすることなく、デリバリ スケジュールの短縮と拡張性の向上を求めるビジネス ニーズにより的確に対応することができます。

高度なアプリケーション デリバリがどのように機能するのか、そしてADCの将来について詳しく知りたい方は、「アプリケーション デリバリ コントローラの進化」と「従来の単純なロード バランシングを超えてその先へ」をお読みください。