ロードバランシング入門：基本の仕組み
はじめに
今日の変化が激しいアプリケーション中心の市場では、顧客が期待する情報、サービス、エクスペリエンスを迅速かつ確実、安全に提供するよう、組織にかかるプレッシャーがますます高まっています。ロードバランシング、暗号化、高速化、セキュリティなど、ネットワークとアプリケーションの主要な機能は、物理サーバーのプロキシとして機能する物理または仮想アプライアンスであるApplication Delivery Controller（ADC）を通じて提供できます。アプリケーションが急増し、継続的インテグレーションと継続的デプロイメント（CI/CD）の厳格なサイクルへの対応も組織に求められる中、ADC市場が2020年までに年間29億ドル規模に達すると予測されているのも不思議ではありません。1
しかし、未来に目を向ける前に、ここに至るまでの経緯を振り返ってみましょう。ネットワークベースの負荷分散は、ADCの動作を支える不可欠な基盤です。1990年代半ば、初の負荷分散ハードウェアアプライアンスが登場し、サーバーやネットワーク全体にワークロードを分散することで、組織によるアプリケーションのスケーリングを支援するようになりました。これらの初期のデバイスはアプリケーションに依存せず、アプリケーションサーバー自体の外部に配置されていたため、シンプルなネットワーク技術を使用して負荷を分散できました。基本的には、外部に「仮想IPアドレス」を提示し、ユーザーが接続を試みると、双方向ネットワークアドレス変換（NAT）を行いながら、最適な実サーバーに接続を転送していました。
しかし、仮想化とクラウドコンピューティングの登場に伴い、ハイパーバイザー上での実行を想定したソフトウェアベースの仮想版として、次世代の負荷分散ADCが登場しました。現在では、仮想アプライアンスでも、専用ハードウェア上で稼働するアプライアンスと同等の幅広い機能を備えたアプリケーションサービスを提供できます。さらに、こうした仮想版により、仮想、クラウド、ハイブリッドの各環境間でアプリケーションサービスを移行する際の複雑さが大幅に軽減され、プライベートクラウド環境やパブリッククラウド環境でアプリケーションサービスを迅速かつ容易に立ち上げられます。
データセンターにおける最新のトレンドは、分散アプリケーションのデプロイと実行を支援するアプリケーション仮想化手法であるコンテナ化です。このプロセスでは、共有OS上でアプリケーションを分離し、明確に区切られたメモリ空間に格納します。これにより、仮想アプライアンスを構築する場合よりも、アプリケーションの開発とデプロイが容易かつ迅速になります。可搬性とパフォーマンスが大幅に向上するため、コンテナ化によって企業のスケーラビリティと俊敏性が高まる可能性があります。将来的には、コンテナアーキテクチャにより、さまざまなクラウド環境を組織がさらに有効活用できるようになる可能性もあります。
今日のADCは、初期のロードバランサーからサービス仮想化のプロセスを経て進化してきました。そして現在では、ソフトウェアのみで構成される仮想エディションにより、ADCは可用性を向上させるだけでなく、ビジネスに必要な拡張性、パフォーマンス、セキュリティを備えたアプリケーションの提供にも役立ちます。しかし、こうした仮想化アプリケーションサービス、共有インフラストラクチャの導入、インテリジェントルーティング機能は、いずれもロードバランシング技術という強固な基盤がなければ実現できません。
動的に変化する市場の複雑な課題に企業がより適切に対処する方法を理解するために、アプリケーションデリバリーの基盤であるロードバランシングの基礎を見ていきましょう。
基礎知識：用語
本題に入る前に、ロードバランシングの基本用語を確認しましょう。用語が統一されていれば簡単なのですが、残念ながら、ロードバランシングデバイス（ひいてはADC）のベンダーごとに異なる用語が使われているようです。しかし、少し説明を加えれば、こうした混乱を解消できます。
ノード、ホスト、メンバー、サーバー
ほとんどの負荷分散ADCでは、ノード、ホスト、メンバー、サーバーという概念が使用されています。4つすべてを使用するADCもありますが、それぞれ意味が異なります。これらの用語が表す基本的な概念は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アドレスに加えて、アプリケーションポートの定義も含まれます。本書では以降、これをサービスと呼びます。
なぜこれほど複雑なのでしょうか。サーバーと、その上で稼働するアプリケーションサービスを区別することで、データセンターでもクラウドでも、ロードバランサーは基盤となるハードウェアやハイパーバイザーではなく、各アプリケーションと個別に連携できるためです。1つのホスト（172.16.1.10）で複数のサービス（HTTP、FTP、DNSなど）を提供している場合があります。各アプリケーションを個別に定義することで（例：172.16.1.10:80、172.16.1.10:21、172.16.1.10:53）、ADCはホスト単位ではなくサービス単位で、それぞれに応じた負荷分散とヘルスモニタリング（後述）を適用できます。
ほとんどのロードバランシング技術では、ホスト（物理サーバー）を表す用語と、そのホストで利用可能なサービスを表す用語を使い分けます。ここでは、単に「ホスト」と「サービス」と呼びます。
プール、クラスター、ファーム
ロードバランシングにより、組織は受信するアプリケーショントラフィックを、パブリッククラウドやプライベートクラウドへのデプロイを含む複数のバックエンド宛先に分散できます。そのため、バックエンド宛先をまとめた集合という概念が必要です。ここでは、この集合をクラスターと呼びます（プールまたはファームとも呼ばれます）。クラスターとは、任意の数のホスト上で利用可能な同種のサービスをまとめたものです。たとえば、企業のWebページを提供するすべてのサービスは「company web page」というクラスターにまとめ、eコマースサービスを提供するすべてのサービスは「e-commerce」というクラスターにまとめます。
仮想サーバー
仮想サーバーは、実際のサーバー（物理、仮想、またはコンテナ）のプロキシです。仮想IPアドレスと組み合わせることで、外部に公開されるアプリケーションのエンドポイントとなります。
すべてを組み合わせる
これらの用語を理解すれば、ロードバランシングの基本を把握できます。ロードバランシングADCは、外部に仮想サーバーを公開します。各仮想サーバーは、1台以上の物理ホスト上にあるサービスのクラスターを参照します。
図2は実際の導入環境を表したものではない可能性がありますが、ロードバランシングとアプリケーションデリバリのプロセスについて引き続き説明するうえで、その基本構造を示しています。
ロードバランシングの仕組み
共通の用語を確認したところで、アプリケーションがお客さまに配信される際の基本的なトランザクションを見ていきましょう。図に示すように、通常、負荷分散ADCは、クライアントと、クライアントが利用するサービスを提供するホストとの間にインラインで配置されます。アプリケーションデリバリの多くの要素と同様に、この配置は必須ではありませんが、どのような導入形態でもベストプラクティスとされています。また、ADCには、2つのサービスポイントで構成されるクラスタを参照する仮想サーバーがすでに設定されているものとします。この導入シナリオでは、クライアントに戻るトラフィックがロードバランサーを経由して処理されるように、ホストの戻り経路をロードバランサーに向けるのが一般的です。
基本的なアプリケーションデリバリーのトランザクションは、次のとおりです。
- クライアントがサービスへの接続を試みます。
- ADCは接続を受け入れ、接続先のホストを決定した後、選択したホストのサービスに合わせて宛先IP（および必要に応じてポート）を変更します（クライアントの送信元IPは変更されません）。
- ホストは接続を受け入れ、デフォルトルートであるADCを経由して、元の送信元であるクライアントに応答を返します。
- ADCはホストからの戻りパケットをインターセプトし、送信元IP（および該当する場合はポート）を仮想サーバーのIPとポートに一致するよう変更して、パケットをクライアントに転送します。
- クライアントは、仮想サーバーから送信されたものとして戻りパケットを受信し、処理を続行します。
この非常に単純な例は比較的わかりやすいものですが、注意すべき重要な点がいくつかあります。第1に、クライアントから見ると、仮想サーバーにパケットを送信し、仮想サーバーから応答を受信するだけです。第2に、NATが実行されます。ここでADCは、クライアントが送信した宛先IP（仮想サーバーのIP）を、リクエストの負荷分散先として選択したホストの宛先IPに置き換えます。第3に、この処理によってNATが「双方向」になります。ホストから返されるパケットの送信元IPは、そのホストのIPです。このアドレスを変更せずにパケットをそのままクライアントへ転送すると、クライアントはリクエストを送信していない相手からパケットを受信することになるため、そのパケットを破棄します。そこでロードバランサーは、記憶している接続情報に基づいてパケットを書き換え、送信元IPを仮想サーバーのIPにすることで、この問題を解決します。
アプリケーション配信の判断
通常、この時点で2つの疑問が生じます。負荷分散ADCは、接続をどのホストに送信するかをどのように決定するのでしょうか。また、選択したホストが稼働していない場合はどうなるのでしょうか。
まず、2つ目の質問について説明します。選択されたホストが稼働していない場合はどうなるのでしょうか。簡単に言えば、ホストはクライアントのリクエストに応答せず、最終的に接続試行がタイムアウトして失敗します。これでは高可用性を確保できないため、望ましい状況ではありません。そのため、ほとんどの負荷分散テクノロジーには、ホストへの接続送信を試みる前に、そのホストが実際に利用可能かどうかを判断するための何らかのヘルスモニタリング機能が組み込まれています。
ヘルスモニタリングには複数のレベルがあり、レベルが上がるにつれて粒度が細かくなり、監視対象もより具体的になります。基本的なモニターでは、ホスト自体にpingを送信するだけです。ホストがpingに応答しない場合、そのホスト上に定義されているサービスも停止している可能性が高いため、利用可能なサービスのクラスターから除外するのが妥当です。ただし、ホストがpingに応答しても、サービス自体が稼働しているとは限りません。そのため、ほとんどのデバイスでは、単純なTCP接続から、スクリプト化された処理やインテリジェントな処理によるアプリケーションとのやり取りまで、何らかの「サービスping」を実行できます。このような上位レベルのヘルスモニターを使用すると、ホストではなく実際のサービスが利用可能であることをより確実に確認できるだけでなく、ロードバランサーが単一ホスト上の複数のサービスを区別できるようになります。ロードバランサーは、あるサービスが利用できない場合でも、同じホスト上のほかのサービスは正常に稼働している可能性があり、引き続きユーザートラフィックの有効な送信先として扱うべきであると判断します。
ここで最初の疑問に戻ります。ADCは、接続要求の送信先となるホストをどのように決定するのでしょうか。各仮想サーバーには、そのサービスを提供するホストの一覧で構成される、特定の専用サービスクラスターがあり、これが選択肢のリストになります。さらに、ヘルスモニタリングによってこのリストが更新され、対象のサービスを提供する「現在利用可能な」ホストのリストが作成されます。ADCは、この更新後のリストから新しい接続の送信先となるホストを選択します。具体的なホストの決定方法は、そのクラスターに関連付けられた負荷分散アルゴリズムによって異なります。こうしたアルゴリズムには、最小接続数、動的比率、単純なラウンドロビンなどがあります。ラウンドロビンでは、ロードバランサーがリストの先頭から順に、新しい接続を次のホストへ割り当てます。リストの末尾に達すると、再び先頭から割り当てを開始します。この方法は単純で予測しやすい一方、すべての接続がバックエンドホストに同程度の負荷をかけ、同程度の時間継続することを前提としていますが、実際には必ずしもそうとは限りません。より高度なアルゴリズムでは、現在の接続数、ホストの使用率、さらにはホストへの既存トラフィックに対する実際の応答時間などを使用し、利用可能なクラスターサービスの中から最適なホストを選択します。
十分に高度なアプリケーションデリバリシステムでは、ヘルスモニタリング情報と負荷分散アルゴリズムを組み合わせ、サービス間の依存関係も考慮できます。これは、1台のホストで複数のサービスが稼働し、ユーザーのリクエストを完了するためにそのすべてが必要となる場合に特に有用です。このような場合、一方のサービスだけが稼働し、もう一方が停止しているホストにユーザーを振り分けることは望ましくありません。つまり、ホスト上の1つのサービスに障害が発生した場合、そのホスト上の別のサービスも、利用可能なサービスのクラスタリストから除外する必要があります。HTMLやスクリプトによってサービスの細分化が進むにつれ、この機能の重要性はますます高まっています。
負荷分散すべきか、しないべきか？
クライアントがトランザクション要求を開始した際に、利用可能なサービスを選択することは、ロードバランシングによる解決策の半分にすぎません。接続が確立された後、ADCは、そのユーザーからの後続トラフィックをロードバランシングの対象とすべきかどうかを追跡する必要があります。ロードバランシング後の後続トラフィックの処理には、一般に「接続の維持」と「パーシステンス」という2つの課題があります。
接続の維持
ユーザーがすぐには切断されない長時間持続するTCP接続（ポート21：FTP、ポート23：Telnetなど）を利用する場合、ロードバランサーは、その接続で伝送される複数のデータパケットが、利用可能な別のサービスホストに負荷分散されないようにする必要があります。これが接続維持であり、2つの主要な機能が必要です。1つ目は、開いている接続と、その接続が属するホストサービスを追跡する機能です。2つ目は、接続が切断されたときに接続テーブルを更新できるよう、その接続を継続的に監視する機能です。これは、ほとんどのADCにとってごく標準的な機能です。
パーシステンス
一方、近年では、クライアントが1つのタスクを実行するために、複数の短時間TCP接続（例：ポート80のHTTP）を使用するケースが増えています。通常のWebブラウジングなどでは問題にならず、新しいリクエストを任意のバックエンドサービスホストに送信できます。しかし、XMLやeコマースなど、同じユーザーからの複数の接続を負荷分散せず、同じバックエンドサービスホストに送信することが極めて重要なケースも数多くあります。この概念をパーシステンス（サーバーアフィニティ）と呼びます。
この問題への対処方法は、プロトコルや求める結果に応じて複数あります。たとえば、最新のHTTPトランザクションでは、サーバーが「keep-alive」接続を指定することで、複数の短時間接続を1つの長時間接続にまとめ、ほかの長時間接続と同様に処理できます。ただし、これによる負荷軽減は限定的です。主な理由は、Webサービスやモバイルサービスの利用が増える中、すべての接続を必要以上に長く開いたままにすると、システム全体のリソースに負担がかかるためです。そのため現在、多くの組織がスケーラビリティとポータビリティを確保するため、APIを利用するステートレスアプリケーションの構築へと移行しています。これは基本的に、リソースの負荷を軽減するためにサーバーがすべてのセッション情報を保持しないことを意味します。この場合、セッションIDの受け渡しとパーシステンスの仕組みによって状態が維持されます。
最も基本的なパーシステンス方式の1つが送信元アドレスアフィニティです。受信リクエストの送信元IPアドレスと、そのリクエストの負荷分散先となったサービスホストを記録し、それ以降のすべてのトランザクションを同じホストに転送します。これを実現する方法として、SSLセッションIDとCookieの使用があります。SSLパーシステンスでは、SSLセッションIDを使用してSSLセッションを追跡します。そのため、クライアントのIPアドレスが変わっても、ロードバランサーはセッションIDに基づいて同じセッションであることを認識できます。Cookieベースのパーシステンスでは、セッションを一意に識別するCookieをクライアントのコンピューターに挿入し、以降のリクエストでそのCookieを参照することで、接続を適切なサーバーに転送できます。
現在では、ADCの高度なインテリジェンスにより、組織はデータパケットを開き、その中に含まれるほぼあらゆる情報を基にパーシステンステーブルを作成できます。これにより、ユーザー名などの一意の情報を使用してパーシステンスを維持できます。ただし、この識別可能なクライアント情報がすべてのリクエストに含まれていることを確認する必要があります。この情報が含まれていないパケットにはパーシステンスが適用されず、再度負荷分散されるため、アプリケーションが機能しなくなる可能性が高くなります。
まとめ
当初、負荷分散は、ネットワーク全体にワークロードを分散し、アプリケーションとサービスの可用性を確保することに重点を置いていました。しかし、テクノロジーの進化に伴い、ロードバランサーはアプリケーションデリバリーのためのプラットフォームへと発展し、組織の重要なアプリケーションに高い可用性とセキュリティを提供するようになりました。基本的な負荷分散は今もアプリケーションデリバリーの基盤ですが、最新のADCは、さらに高度で多彩な機能を提供します。
企業は、アプリケーションにアクセスできるだけでは、実際に利用できるとは限らないことを認識しています。利用できないアプリケーションは、それを導入する組織にとって時間とコストの無駄になります。そこで役立つのが最新のADCです。SSL/TLSオフロード、キャッシュ、圧縮、レートシェーピング、侵入検知、アプリケーションファイアウォール、さらにはリモートアクセスといったネットワークベースのサービスを、すべてのアプリケーションサービスとホストで共有・再利用できる単一の戦略的ポイントに統合し、仮想化されたApplication Delivery Networkを構築できます。これにより、セキュリティ要件を損なうことなく、ネットワーク、アプリケーション、運用の各チームが、提供期間の短縮や拡張性の向上を求めるビジネスニーズに、より適切に対応できるようになります。
高度なアプリケーションデリバリの仕組みとADCの将来について詳しくは、アプリケーションデリバリコントローラーの進化および従来のロードバランシングを超えてをご覧ください。
1 http://www.strategyr.com/MarketResearch/Application_Delivery_Controllers_ADC_Market_Trends.asp
2017年5月10日公開