とことこロゴス
ロードバランサ
クライアントからの要求を複数のサーバへ振り分ける装置やソフトウェア。処理の集中を抑え、正常な処理先を選ぶためにヘルスチェックを行う構成がある。
イマシルちゃんの解説
Webサイトにアクセスが集中すると、サーバが一台では処理しきれなくなることがあるよ。
ロードバランサは、利用者から届く要求を複数のサーバへ分担させる装置やソフトウェアなんだ。
順番に担当を決めたり、接続数の少ないサーバを選んだりして、特定の一台に負荷が偏るのを抑えるよ。
サーバが応答できるか定期的に確かめるヘルスチェックを組み合わせることもあるんだ。
異常を検知したサーバへ新しい要求を送らないようにすれば、残りのサーバでサービスを続けやすくなるよ。
この解説はわかりやすかったですか？
より深い解説
振分けに使う情報
接続の行き先は、順番、重み付け、接続数などの負荷分散アルゴリズムで決める。単純に順番に配る方法では、要求ごとの処理量の違いまで均等化できない。
処理先の選び方
| 方式 | 新しい接続や要求を渡す先 | 適用するときの考え方 |
|---|---|---|
| ラウンドロビン | 対象サーバへ順番に振り分ける | 各サーバの性能や要求ごとの処理量が近い場合に使いやすい |
| 最少接続数方式 | その時点で接続数が最も少ないサーバへ振り分ける | 接続が続く時間にばらつきがある場合、同時接続数の偏りを抑えやすい |
| 重み付きの方式 | 処理能力などに応じて比率を変える | 性能が異なるサーバを同じグループで使う場合に調整する |
最少接続数方式はLeast Connections、リーストコネクションとも呼ばれる。例えば同じ性能の配信サーバでも、小さな画像と大きな動画では接続が続く時間が異なる。順番に同じ件数を割り当てても、大きな動画の配信が集中したサーバには接続が多く残る。現在の接続数を見て次の処理先を選ぶことで、この偏りを抑える。
ただし接続数はCPU使用率や転送バイト数そのものではない。一つの接続に複数の要求が載る場合もあるため、何を一件として数える方式なのかを確認する。
公開する宛先とサーバ群
クライアントが接続する負荷分散用の仮想IPアドレスをVIPと呼ぶ。実際に処理するサーバをまとめた集合がサーバプールであり、製品によってクラスタグループなどの名称を使う。
一台のロードバランサでも、複数のVIPやプールを設定できる。例えばWeb用とファイル配信用のサーバ群を分け、各グループに公開宛先、負荷分散アルゴリズム、ヘルスチェックの条件を対応付ける。VIPを設けただけで、異なるサービスの状態や振分け規則まで共通になるわけではない。
送信元の変換と応答の戻り道
宛先をVIPから実サーバへ変換する方式では、送信元IPアドレスを残すか、ロードバランサ側のアドレスへ変えるかを選ぶ構成がある。送信元を変える処理がソースNAT（SNAT）である。
| 方式 | サーバが見る送信元 | 応答経路の考え方 |
|---|---|---|
| 送信元を変換する | ロードバランサ側のIPアドレス | 変換後の送信元へ応答するので、ロードバランサへ戻しやすい |
| 送信元を変換しない | 元のクライアントのIPアドレス | サーバの経路設定で応答がどこへ向かうか確認する |
往復の通信を追跡してアドレス変換を戻す構成では、応答も同じロードバランサを通る必要がある。サーバのデフォルトゲートウェイが別のルータを向くと、応答がロードバランサを迂回して通信できない場合がある。一方、DSRのように応答を直接返すことを前提とした方式もあるため、必要な経路は採用方式に合わせて決める。
送信元を変換すると、サーバのIPアドレスだけによるログでは元の利用者を区別できなくなる。HTTPの転送ヘッダーなどで利用者情報を引き継ぐ場合も、信頼できるロードバランサが付与した値だけを扱う。
稼働状態の確認
ヘルスチェックでは、TCP接続の成功やHTTP応答などを確認する。ポートが開いていても、データベースに接続できず業務が使えない場合があるため、確認対象を目的に合わせる。
故障を検出した処理先を新しい要求の対象から除外し、回復を確認して戻す。確認が頻繁すぎると負荷が増え、まれすぎると検知が遅れる。回数や間隔、判定条件を設計する。
続きの要求をどう扱うか
買い物かごなどの状態を一台だけで持つ場合、次の要求が別のサーバへ届くと状態を参照できない。このため同じ利用者を同じ処理先へ寄せるセッション維持を用いることがある。
Cookieを使う接続先の固定をCookieパーシステンスという。ロードバランサが専用Cookieを付ける方式では、最初の応答のSet-Cookieヘッダーで接続先に対応する識別情報をブラウザへ渡す。次の要求で返されたCookieヘッダーを読み、同じサーバへ振り分ける。アプリケーションが発行したCookieと接続先の対応を学習する方式もある。
HTTPのCookieを読むにはレイヤー7の情報を扱う必要がある。HTTPSをそのまま通すだけではヘッダーが暗号化されているため、ロードバランサでTLSを終端するなど、内容を扱える構成にする。
接続先を固定することと、サーバ間でセッションのデータを共有することは別である。固定先のサーバが停止したとき、買い物かごなどを別サーバでも引き継ぎたいなら、状態を共有する保存先や再取得の方法も必要になる。
他の機能との区別
TLSを終端してサーバの暗号処理を肩代わりする機能はTLSオフロードである。搭載されることはあるが、振分けそのものとは違う。リンクアグリゲーションが束ねるのは物理回線であり、複数サーバへの要求配分ではない。
DNSラウンドロビンでは名前解決の応答で行き先を分散する。キャッシュがあるため、レコードを変更しても接続先が直ちに切り替わるとは限らない。負荷分散装置自身が単一障害点にならない構成も検討する。
参考資料
実際の試験ではここに出る！全6問
ネットワークスペシャリスト
テクニカルエンジニア（ネットワーク）
- 午前