Webサイトの仕組みを調べていると、「ロードバランサー」という言葉が出てくることがあります。
この「ロードバランサー」ですが、どんな役割や機能があるか知っていますか？
この記事では、「ロードバランサー」について、以下の内容を図を用いてわかりやすく説明します。
- ロードバランサーとは？
- ロードバランサーの振り分け方式
- ロードバランサーの主な機能
- ロードバランサーのメリットとデメリット
ロードバランサーとは？
ロードバランサーとは、WebサイトやWebアプリケーションへのアクセスを受け取り、複数のサーバーに振り分ける仕組み（または装置・ソフトウェア）です。アクセスを振り分けることにより、複数のサーバーで処理を分担でき、1台のサーバーに負荷が集中しにくくなります。このように処理の負担を分けることを「負荷分散」といいます。
ロードバランサーは英語で「Load Balancer」と書きます。Load（ロード）はサーバーにかかる負荷、Balancer（バランサー）はバランスを取るものという意味です。
スーパーのお客さんをアクセス、スーパーの案内係をロードバランサー、スーパーのレジをWebサーバーと考えるとわかりやすいです。レジ（Webサーバー）が3台あっても、お客さん（アクセス）が1台に集中すると、そこだけに長い列ができます。そこで案内係（ロードバランサー）が空いているレジ（Webサーバー）にもお客さん（アクセス）を振り分けると、3台で手分けして会計できます。
実際のWebサイトでは、例えばネットショップの商品ページを開くと、ブラウザはページのデータをリクエストします。ロードバランサーはサイトの入口でそのリクエストを受け取り、同じ商品ページを返せるサーバーA・B・Cの中から1台を選びます。
ロードバランサーの振り分け方式
ロードバランサーの代表的な振り分け方式には、以下の3種類があります。
- ラウンドロビン
- 重み付きラウンドロビン
- 最小接続数方式
ここでは、サーバーA・B・Cの3台がリクエストを受け付けられる場合を例に、各方式を説明します。
順番に選ぶ（ラウンドロビン）
ラウンドロビンとは、サーバーを順番に選ぶ方式です。A・B・Cの順で選ぶ場合、Cの次はAに戻ります。
例えば、6件のリクエストが順に届くと、A → B → C → A → B → Cの順に送り、3台が2件ずつ担当します。
レジで同じ人数を担当しても、かごの商品が多いお客さんの会計には時間がかかります。同じようにサーバーでも、リクエストの件数が同じでも、すぐに終わる処理と時間のかかる処理が混ざると、各サーバーの負担には差が出ます。
送り先ごとの割合を変える（重み付きラウンドロビン）
重み付きラウンドロビンとは、サーバーごとにリクエストを割り当てる割合を設定できる方式です。この割合を決めるために、各サーバーに設定する数値を「重み」と呼びます。
例えば、Aの処理能力がBやCより高い場合は、A・B・Cの重みを2：1：1に設定できます。この場合、全体の約半分がAへ、約4分の1ずつがBとCへ送られます。Aには、BやCの約2倍のリクエストが割り当てられます。
接続が少ないサーバーを選ぶ（最小接続数方式）
最小接続数方式とは、ロードバランサーと各サーバーの間で、通信に使われている接続が少ないサーバーを優先する方式です。ここで数えるのは、各サーバーとの間で現在使われている接続です。
例えば、3台を同じ条件で扱い、Aに5本、Bに1本、Cに3本の接続があるなら、次の送り先はBです。その後、次のリクエストが届いたときに、Aの接続数が0本になり、BとCには接続が残っていれば、今度はAが選ばれます。
ラウンドロビンでは順番が決まっていますが、最小接続数方式では、リクエストが届いた時点の接続数によって送り先が変わります。
ロードバランサーの主な機能
ロードバランサーには、負荷分散に加えて、次のような機能があります。
- ヘルスチェック
- パスによる振り分け
- セッション固定
利用できる機能は、製品や設定によって異なります。各機能についてこれから説明します。
サーバーの状態を確認する（ヘルスチェック）
ヘルスチェックとは、サーバーがリクエストを受け付けられる状態かを確かめる機能です。
例えば、ロードバランサーが各サーバーに定期的に確認用のリクエストを送り、決められた時間内に正常な応答が返るかを調べます。確認が続けて失敗したときに異常と判定するよう設定することもできます。
サーバーBが応答せず、異常と判定されたとします。AとCが正常なら、Bを送り先から外し、その後のリクエストをAとCに振り分けられます。スーパーでレジBが故障したときに、案内係がレジAとCへお客さんを案内するのと同じです。
URLのパスで送り先を分ける
対応するロードバランサーでは、URLの「パス」と呼ばれる部分を見て、送り先のグループを選べます。例えば、https://example.com/products/123 では、/products/123 がパスです。
同じネットショップでも、商品一覧と注文処理を別々のサーバーグループで担当しているなら、次のように送り先を設定できます。
- パスが
/products/で始まるリクエスト → 商品一覧を担当するサーバーグループ - パスが
/orders/で始まるリクエスト → 注文を担当するサーバーグループ
ロードバランサーは、まずどのグループに送るかを決めます。そのグループに複数のサーバーがあれば、次にラウンドロビンなどの方式に従ってどの1台に送るかを決めます。
同じ利用者を同じサーバーへ送る（セッション固定）
セッション固定とは、同じ利用者の一連のリクエストを、できるだけ同じサーバーに送る機能です。例えば、ロードバランサーがブラウザにクッキーという目印を渡し、次のリクエストでその目印を見て送り先を選ぶ方法があります。
ネットショップで、サーバーAだけに買い物かごの情報を保存しているとします。利用者が商品を追加したあと、買い物かごを開くリクエストもAに届けば、Aに保存した商品を表示できます。
ロードバランサーのメリットとデメリット
ロードバランサーのメリットとデメリットを以下に示します。
メリット
- アクセスが集中しても対応しやすい。
- ネットショップのセールでリクエストが一気に増えても、複数のサーバーで手分けして処理できるため、1台に負担が集中しにくくなります。
- 1台が止まってもサービスを続けやすい。
- 例えば、Bが異常と判定されたあとも、AとCでその時点のアクセスを処理できれば、サイトを提供し続けられます。異常の検知までにBへ送られたリクエストは、失敗することがあります。
- サーバーを1台ずつメンテナンスできる。
- 例えば、Bを更新するときは、まず新しいリクエストをAとCに振り分けます。Bがすでに受け取ったリクエストの処理が終わってから更新し、動作を確認したら、Bを送り先に戻します。
デメリット
- 導入や運用に費用がかかる。
- ロードバランサーの機器やクラウドサービスの利用料金がかかります。振り分け先のサーバーを増やす場合は、その分の費用も加わります。
- 設定や管理の手間が増える。
- どのサーバーに送るか、どんな応答なら正常と判断するかなどを設定します。例えば、存在しないページをヘルスチェックの確認先にすると、サーバーが稼働していても異常と判定され、送り先から外れることがあります。
- 入口にも障害対策が必要になる。
- ロードバランサーを1台だけで運用している場合、その1台が止まると、裏側のサーバーが動いていてもリクエストが届かなくなります。サイトを止まりにくくするには、ロードバランサー自体の障害にも備える必要があります。
本記事のまとめ
この記事では「ロードバランサー」について、以下の内容を説明しました。
- ロードバランサーは、サイトの入口でアクセスを受け取り、複数のサーバーに振り分ける。
- 振り分け方式によって、順番、設定した割合、その時点の接続数など、送り先を選ぶ基準が変わる。
- ヘルスチェックで異常と判定されたサーバーは、新しいリクエストの送り先から外せる。
- 複数のサーバーで処理を分担すると障害やメンテナンスに対応しやすくなる一方、費用や設定の手間が増える。
お読みいただきありがとうございました。