ロードバランサとは ― 負荷分散の仕組みと方式

ロードバランサとは、利用者から届いた通信を、同じ役割を持つ複数のサーバに振り分ける装置です。負荷を分けて1台に処理が集中しないようにし、故障したサーバを避けて送ることで、サービスを止まりにくくします。

日本語では負荷分散装置とも呼び、LBと略すこともあります。専用の機器のほかに、サーバ上で動くソフトウェアや、クラウド事業者のサービスもあります。どの形でも、振り分けの仕組みは同じです。

負荷分散が必要な理由から始めて、振り分け方式、故障を見つけるヘルスチェック、L4とL7の違い、DNSラウンドロビンとの違いを順に説明します。

Webサイトへのアクセスが増えると、1台のサーバでは処理が追いつかなくなります。サーバを高性能なものに替える方法もありますが、1台の性能を上げられる幅には限りがあります。そこで、同じ内容を返すサーバを複数台並べ、届いた要求を分け合います。

サーバの台数を増やして処理能力を上げることをスケールアウトと呼び、1台の性能を上げることをスケールアップと呼びます。スケールアウトなら、台数を足すだけで処理できる量を増やせます。

複数台にすると、故障にも強くなります。1台が止まっても、残りのサーバで処理を続けられるからです。ただしそのためには、止まったサーバを見つけて要求を送らないようにする仕組みが必要です。この仕組みは、ヘルスチェックの節で説明します。

例として、example.com のWebサーバを3台に増やした構成を考えます。3台のサーバA・B・Cには、172.16.0.11から172.16.0.13までのプライベートIPアドレスを付けます。利用者に公開するのは、ロードバランサが持つ 203.0.113.50 だけです。

1. 利用者のPCは、DNSで example.com のアドレスを調べ、203.0.113.50 を受け取ります。
2. PCが 203.0.113.50 に要求を送ると、ロードバランサがこれを受け取ります。
3. ロードバランサは、決めておいた振り分け方式で3台から1台を選びます。
4. ロードバランサは、選んだサーバへ要求を転送します。
5. 多くの構成では、サーバの応答もロードバランサを通って利用者に戻ります。

利用者からは、裏に何台のサーバがあるかは見えません。サーバを足したり外したりしても、公開するアドレスは変わりません。サーバの手前で要求を受けるこの位置は、リバースプロキシと同じです。実際、負荷分散はリバースプロキシの代表的な用途の1つです。

どのサーバに送るかを決める規則を、振り分け方式と呼びます。方式は、サーバの今の状態を見るかどうかで2つに分かれます。決めておいた規則どおりに配るのが静的な方式で、サーバの接続数や応答の速さを測って選ぶのが動的な方式です。

ラウンドロビンは、どの要求も同じくらいの重さなら、ほぼ均等に分けられます。ただし、時間のかかる要求が1台に重なると、そのサーバだけが混み合います。最小コネクションは処理中の接続数を見て選ぶので、こうした偏りを避けやすい方式です。

最小コネクションが向くのは、1本の接続が長く続く通信です。HAProxyというソフトウェアの設定マニュアルも、HTTPのように接続がすぐ終わる通信にはあまり向かないと説明しています。

次の図では、同じ6件の要求を方式を変えて振り分けます。要求は、利用者1・2・3・1・4・2の順に届きます。サーバBを止めたときに行き先がどう変わるかも確かめられます。

ラウンドロビンは、要求の送り主を見ません。利用者1の要求1と要求4がどちらもAに届くのは、順番がちょうど一巡したためです。一方、送信元IPハッシュでは、サーバの台数が変わらない限り、同じ利用者は毎回同じサーバに届きます。この性質は、セッション維持の節で再び登場します。

ロードバランサは、背後のサーバが正常に動いているかを定期的に確かめます。この確認をヘルスチェックと呼びます。応答のないサーバは振り分け先から外し、新しい要求を送らないようにします。確かめ方は、どの層まで見るかで分かれます。

下の層の確認ほど処理は軽くなりますが、分かることは少なくなります。たとえばpingに応答していても、Webのソフトウェアが止まっていればページは返せません。L7の確認で決めたURLを実際に取得すれば、こうした故障も見つけられます。

一度の失敗ですぐ外すと、たまたま応答が遅れただけのサーバまで外れてしまいます。そこで、何回続けて失敗したら外し、何回続けて成功したら戻すかを決めておきます。たとえばHAProxyというソフトウェアでは、ヘルスチェックを有効にすると、既定値で2秒ごとに確認します。3回続けて失敗すると外し、2回続けて成功すると戻します。

確認と確認の間にサーバが止まると、失敗が続いて外されるまでは、そのサーバに要求が届くことがあります。ヘルスチェックは故障を見つけてから外す仕組みなので、止まった瞬間の要求までは救えません。そうした要求に返る502や504の読み方は、HTTPステータスコードの記事で説明しています。

ソフトウェアの新しい版を出すときに振り分け先を変えるのも、ロードバランサの仕事です。振り分け先を一度に変えるか少しずつ変えるかは、ブルーグリーンデプロイとカナリアリリースの記事で比べています。

ネットショップには、カートの中身をサーバが記憶する作りのものがあります。この場合、次の要求が別のサーバに振り分けられると、そのサーバはカートの中身を知りません。利用者から見ると、入れたはずの商品が消えてしまいます。

そこで、同じ利用者からの一連の要求を、同じサーバに送り続ける機能を使います。この機能をセッション維持と呼びます。パーシステンスやスティッキーセッションと呼ぶこともあります。同じ利用者かどうかを見分ける手がかりは、主に2つです。

送信元IPアドレスを使う方法は、前の節の送信元IPハッシュと同じ考え方です。ただし会社や家庭の利用者は、NATによって外からは同じアドレスに見えます。その全員が1台に送られるので、負荷が偏ります。

Cookieを使う方法では、ロードバランサが最初の応答に、どのサーバかを示す値をCookieとして付けます。ブラウザは、次の要求からそのCookieを付けて送ります。ロードバランサはその値を読み、要求を同じサーバに送ります。Cookieの仕組みは、RFC 6265で定められています。Set-CookieとCookieヘッダのやり取りは、Cookieの記事に図があります。

セッション維持にも弱点があります。送り続けていたサーバが止まると、そのサーバだけが記憶していた情報は失われます。そこで、セッションの情報をサーバの外の共有の保存場所に置き、どのサーバに届いても続きを処理できるようにする設計もあります。

ロードバランサは、振り分け先を決めるときにどの層の情報まで見るかで2種類に分かれます。L4やL7のLは層（Layer）を表し、数字はOSI参照モデルの第4層と第7層を指します。

L4のロードバランサは、IPアドレスとポート番号で振り分けます。TCPの接続ごとに行き先を決め、同じ接続のパケットは同じサーバに送り続けます。通信の中身を読まないので処理が軽く、HTTP以外の通信にも使えます。

L7のロードバランサは、HTTPのリクエストを読んで振り分けます。たとえば、URLが /images/ で始まる要求だけを、画像を返すサーバのグループに送れます。前の節で説明したCookieによるセッション維持も、L7で行います。

L7のロードバランサは、利用者からのTCP接続をいったん自分で受けたうえで、選んだサーバへ別の接続を張り直します。この動きはリバースプロキシそのものです。

HTTPSの場合は、ロードバランサがTLSの暗号を解いてから中身を読みます。暗号の処理をロードバランサで引き受けることを、TLS終端と呼びます。TLSの仕組みは、HTTPとHTTPSの記事で説明しています。

接続を張り直すため、サーバから見える送信元はロードバランサの内側のアドレスになります。そこでロードバランサは、利用者の元のアドレスをHTTPのヘッダに書いてサーバに伝えます。広く使われているのはX-Forwarded-Forヘッダで、標準の形としてはRFC 7239のForwardedヘッダがあります。

AWSでは、L7にあたるロードバランサをALB、L4にあたるロードバランサをNLBと呼びます。仮想サーバのEC2インスタンスやAuto Scalingと組み合わせる方法は、ELBとAuto Scalingの記事にまとめています。

L7で振り分けるメリットは、HTTPの中身に応じて行き先を変えられることです。デメリットは、中身を読む分だけ処理が重くなることです。

メリット1：URL・ヘッダ・Cookieで振り分け先を変えられる

URLのパスを見て、/images/ は画像用のサーバ、/api/ はAPI用のサーバに送れます。Hostヘッダを見れば、1つのアドレスで受けた複数のサイトを、サイトごとのサーバに分けられます。Cookieを使えば、セッション維持もできます。

メリット2：リクエストごとに振り分けられる

L4はTCPの接続ごとに行き先を決めるので、1本の接続に多くのリクエストが流れると、その分が1台に集まります。L7はリクエストを1つずつ読むので、同じ接続の中のリクエストも別々のサーバに送れます。

メリット3：TLS終端で暗号の処理を1か所にまとめられる

HTTPSの暗号を解く処理をロードバランサが引き受けるので、サーバ側は暗号の処理を減らせます。証明書も、ロードバランサで一括して管理できます。

デメリット1：処理が重い

L7のロードバランサは、TCPの接続を受けてHTTPを読み、HTTPSなら暗号も解きます。L4より処理が多いので、同じ性能の機器なら扱える通信の量は少なくなります。

デメリット2：読めるプロトコルでしか使えない

L7の振り分けが使えるのは、ロードバランサが中身を理解できるプロトコルに限られます。多くの製品では、HTTPとHTTPSが中心です。ほかのプロトコルを負荷分散するなら、L4のロードバランサを使います。

デメリット3：鍵の管理と送信元アドレスに手当てが要る

TLS終端をするには、サーバ証明書と秘密鍵をロードバランサに置く必要があります。また、サーバからは利用者のアドレスが直接見えないので、X-Forwarded-Forなどのヘッダで伝える必要があります。

専用の装置を使わずに負荷を分ける方法に、DNSラウンドロビンがあります。これは、1つの名前に複数のサーバのアドレスをAレコード（名前とIPv4アドレスの対応）として登録しておく方法です。DNSサーバは、問い合わせのたびに答えの並び順を入れ替えて返します。

たとえば example.com に 203.0.113.50 と 203.0.113.60 を登録します。並び順が変わるので、利用者ごとにつなぐ先が分かれます。この使い方は、RFC 1794にも記録されています。

いちばんの違いは、止まったサーバを避けられるかどうかです。DNSサーバは登録したサーバが動いているかを確かめないので、止まったサーバのアドレスもほかと同じように答えます。

もう1つの違いは、答えがキャッシュされることです。答えは、DNSの記事で説明した有効期間（TTL）の間、キャッシュDNSサーバやPCに残ります。止まったサーバのレコードを消しても、TTLが切れるまでは古い答えが使われ続けます。

DNSで振り分ける方法にも、サーバの状態を確かめて答えを変える仕組みがあります。この仕組みをGSLB（Global Server Load Balancing）と呼び、地域の離れたデータセンターに利用者を振り分けるときに使います。

すべての要求はロードバランサを通ります。ロードバランサが1台だけだと、それが止まったときに要求がどのサーバにも届かなくなります。このように、1か所が止まると全体が止まる箇所を、単一障害点と呼びます。

そこで、ロードバランサを2台用意し、片方を待機させておく構成がよく使われます。動いている側が止まると、待機していた側が公開アドレスの 203.0.113.50 を引き継ぎます。利用者は、これまでと同じアドレスに送り続けるだけで済みます。

アドレスの引き継ぎには、VRRPのような仕組みを使います。VRRPは、複数のルータで1つのアドレスを共有するために作られた規格で、今の版はRFC 9568で定められています。VRRPの仕組みそのものと、同じ役割のHSRPとの違いは、FHRPの記事で比べています。

処理を複数のサーバに分けておくと、大量の通信を送りつけてサービスを使えなくするDoS攻撃にも備えやすくなります。攻撃の手口は、DoS攻撃・DDoS攻撃の記事で説明しています。