LASSIC Media らしくメディア

「アクセスが集中する時間帯になるとシステムの反応が鈍くなる。ベンダーからは『サーバを増やして負荷を分散しましょう』と提案されたが、台数を足せば本当に速くなるのか、判断の勘所がつかめない」——IT事業部でインフラ構成の提案を受ける立場にいると、こうした場面に出会うことがあるのではないでしょうか。提案書や構成図に「ロードバランサ」「LB」「ALB」といった言葉が並んでいても、それが何を担い、どんな効果をもたらすのかがあいまいなまま、費用の承認だけを求められることも少なくないはずです。ロードバランサは、アプリケーションのように画面として目に見えるわけではなく、ネットワーク機器やミドルウェアの境界に位置するため、発注者やPMにとって理解しづらい領域になりがちでしょう。しかし、この仕組みの理解は、システムがアクセス増にどこまで耐えられるか、障害時にサービスを続けられるかといった、事業に直結する論点とつながっています。本記事では、特定製品の導入手順ではなく、ロードバランサ（負荷分散）とはそもそも何を指すのか、どのような方式があり、選定や運用でどこを見ておくとよいのかを、発注者の視点から順に整理していきます。個々の製品名を覚える前に、負荷分散という考え方の輪郭をつかんでおくと、ベンダーからの説明を聞くときの解像度が変わってくるはずです。

ロードバランサとは何か

ロードバランサとは、利用者からのリクエストを複数のサーバに振り分け、処理の負荷を分散させる仕組みです。「ロード（負荷）」を「バランス（均す）」するという名前のとおり、1台のサーバに処理が集中しないよう、あらかじめ用意した複数台へ交通整理を行う役割を担います。窓口が1つしかない受付に来客が殺到すると長い行列ができてしまいますが、複数の窓口を開けて案内係が空いている窓口へ順に誘導すれば、待ち時間は短くなるでしょう。ロードバランサが担っているのは、まさにこの案内係のような働きだと考えると、イメージをつかみやすくなります。

なぜこの仕組みが必要になるのかというと、1台のサーバで処理できる量には上限があるためです。利用者が増えてリクエストが集中すると、1台では処理が追いつかず、応答が遅くなったり、混雑時には停止したりします。しかも、サーバが1台構成では、その1台が故障した時点でサービス全体が止まってしまう、いわゆる単一障害点（Single Point of Failure）を抱えることにもなりかねない点は見落とせないでしょう。ロードバランサを挟んで複数台に処理を分けておけば、1台が停止しても残りのサーバで処理を続けられ、台数を増やすことで処理できる総量も引き上げられます。

整理すると、ロードバランサがもたらす効用は大きく2つに分けられるでしょう。1つは、複数台に処理を分けることで、より多くのアクセスを捌けるようにする「拡張性（スケール）」の面です。もう1つは、一部のサーバが停止してもサービスを継続できるようにする「可用性」の面といえます。この2つは別々の話に見えて、実際には同じ「複数台構成にして振り分ける」という発想から生まれる、表裏一体の効果です。次の図は、クライアントからのリクエストがロードバランサを経て複数のサーバへ分配される様子を、単純化して示したものです。

負荷分散の主な方式

ロードバランサが「どのサーバに振り分けるか」を決める判断基準を、振り分けアルゴリズムと呼びます。方式によって、負荷の均し方や向いている用途が変わってくるため、提案された構成がどの方式を前提にしているかを把握しておくと、判断の助けになるでしょう。代表的な方式を表に整理しました。

どの方式が適しているかは、サーバ構成やアプリケーションの性質によって変わります。台ごとの性能が揃っていればラウンドロビンで十分なことも多く、処理の重さにばらつきがあるなら最小接続数のほうが偏りを抑えられるでしょう。発注の段階で細かなアルゴリズムまで指定する必要はありませんが、「どういう考え方で振り分けるのか」をベンダーに一度確認しておくと、後から挙動を把握するときに戸惑いにくくなります。

L4とL7 — 振り分けの階層による違い

ロードバランサは、リクエストの「どこを見て」振り分けるかによって、大きく2つのタイプに分けられます。ネットワークの階層になぞらえて、L4（レイヤ4）型とL7（レイヤ7）型と呼ばれるものです。この違いは、提案される製品の性格を左右するため、押さえておく価値があります。

L4型は、トランスポート層の情報、つまりIPアドレスとポート番号を手がかりに振り分けます。通信の中身までは解釈せず、宛先だけを見て素早く受け渡すため、処理が軽く高速に捌ける点が持ち味です。一方でL7型は、アプリケーション層の情報まで踏み込んで判断します。HTTPのURLやホスト名、Cookieの内容などを見て振り分けられるため、「このパスへのアクセスはこのサーバ群へ」「この種類のリクエストは別系統へ」といった、きめ細かなルーティングが可能になります。近年よく見かけるクラウドのアプリケーション向けロードバランサは、このL7型に該当するものが多いでしょう。

両者は優劣で選ぶものではなく、用途で使い分ける関係にあります。単純に負荷を分けたいだけならL4型で軽快に捌けますし、URLやドメインごとに振り分け先を変えたい、暗号化通信の処理をまとめて引き受けたいといった要件があればL7型が候補になります。提案書に登場するロードバランサがどちらの層で動くのかを知っておくと、実現できることの範囲を見積もりやすくなるはずです。

ロードバランサの導入形態

ロードバランサをどのような形で用意するかも、構成やコストを左右する論点です。導入形態は、大きく次の3つに整理できます。

クラウド上でシステムを構築する場合は、マネージド型を選ぶ場面が増えています。機器の調達や冗長化をクラウド事業者側に任せられるため、自社で抱える運用の負担を軽くしやすいのが理由でしょう。一方、オンプレミス環境や特殊な要件があるケースでは、ハードウェア型やソフトウェア型が引き続き選ばれることもあります。どの形態が適するかは、既存の環境や運用体制、想定するアクセス規模によって変わるため、提案の背景にある前提をベンダーに確認しておくと納得感が高まります。

選定・運用で意識したい観点

ロードバランサは一度組み込むと長く使い続ける構成要素であり、導入時に押さえておきたい観点がいくつかあります。発注や運用の意思決定に関わる立場からは、次の5つを確認しておくと判断がしやすくなるでしょう。

ヘルスチェック（死活監視）

ロードバランサは、振り分け先のサーバが正常に応答できているかを定期的に確認しています。この仕組みがヘルスチェックです。応答が返らないサーバを検知すると、そのサーバへの振り分けを一時的に止め、健全なサーバだけにリクエストを送るよう切り替えます。この働きがあるからこそ、1台が停止しても利用者が異常に気づかないまま処理を続けられるわけです。導入時には、何をもって「正常」と判断するのか、チェックの間隔をどう設定するのかが論点になります。単に接続できるかどうかだけを見るのか、特定のページが正しく表示されるところまで確認するのかで、障害の検知精度は変わってきます。

セッション維持（スティッキーセッション）

ログイン状態やカート情報のように、利用者ごとの状態を扱うシステムでは、注意が要る点があります。リクエストのたびに違うサーバへ振り分けられると、前の操作で保持していた状態が引き継がれず、ログインが外れるといった不具合につながりやすくなるのです。これを避けるため、同じ利用者を同じサーバへ誘導し続けるスティッキーセッションという設定を使うことがあります。ただし、特定のサーバに利用者が張り付くと負荷の偏りが生じやすくなるため、状態をサーバの外側（共有のデータベースやキャッシュ）に持たせる設計と、どちらを採るかを検討する必要があるでしょう。この判断は後から変更しにくいため、設計の初期に方針を固めておきたいところです。

TLS終端（暗号化通信の扱い）

暗号化された通信（HTTPS）を、どこで復号するかも設計上の論点です。ロードバランサでまとめて復号し、その先のサーバへは平文で渡す方式を、TLS終端と呼びます。各サーバが個別に暗号処理を担う負担を減らせる一方、ロードバランサから先の区間の通信をどう守るかという別の検討が生まれます。証明書の更新をどこで管理するのかも含め、運用の手順に関わってくるため、体制とあわせて確認しておくとよいでしょう。

ロードバランサ自体の冗長化

見落とされがちなのが、ロードバランサそのものが新たな単一障害点になり得るという点です。すべてのリクエストがロードバランサを経由する以上、これが停止すればサービス全体が止まってしまいます。そのため、ロードバランサ自体も複数台で構成し、一方が停止しても他方が処理を引き継ぐ冗長構成を組むのが一般的です。クラウドのマネージド型では、この冗長化が最初から組み込まれていることが多いものの、オンプレミスで構築する場合は明示的に設計へ含める必要があります。提案された構成で、この点がどう担保されているかは確認しておきたいポイントです。

監視とオートスケール連携

ロードバランサは、通過するリクエスト数や各サーバの状態を把握できる位置にあるため、監視の要としても機能します。アクセス数や応答時間、エラーの発生状況を継続的に把握しておくと、負荷の傾向をつかみ、増強の判断材料にできます。クラウド環境では、負荷に応じてサーバの台数を自動で増減させるオートスケールの仕組みと連携させ、混雑時に台数を増やし、落ち着いたら減らすといった運用も可能です。こうした連携まで視野に入れると、初期構築だけでなく運用フェーズでの拡張のしやすさも見えてきます。

ここまでの5つの観点は、それぞれ独立した話ではなく、互いに結びついています。たとえばセッション維持の方針は、オートスケールで台数を増減させる運用と相性を確認しておく必要がありますし、ヘルスチェックの精度は冗長化の効果を左右します。発注側としては、この5つをチェックリストのように持っておき、提案を受けるたびに照らし合わせる進め方が現実的でしょう。

導入時の注意点

ロードバランサの導入で陥りやすいのが、「台数を増やしさえすれば速くなる」という単純な期待だけで進めてしまう考え方です。振り分けの前提として、各サーバが同じ処理をこなせる状態に揃っていることや、利用者の状態をどこで保持するかといった設計が整っていなければ、台数を足しても期待どおりには機能しません。また、小規模で当面アクセス増の見込みが小さいシステムに、過剰に手厚い冗長構成を組むと、初期投資と運用の手間だけがふくらんでしまう場合もあります。想定される利用規模に見合った構成を選ぶ、というバランス感覚が求められるところです。なお本記事は、特定のロードバランサ製品の設定手順を解説するものではなく、負荷分散という仕組みの考え方と、選定・運用で押さえたい観点に焦点を当てています。個別製品の細かな設定を詰める段階では、公式ドキュメントや導入実績のあるベンダーへの確認が別途必要になるでしょう。

リクエストの流れで見る具体イメージ

ロードバランサの働きは、リクエストの流れに沿って追うとつかみやすくなります。利用者がブラウザでシステムにアクセスしたときの一例を、簡略化して挙げてみましょう。

利用者のブラウザ
  → ロードバランサが リクエストを受け付ける
  → 各サーバの稼働状態（ヘルスチェック）を確認する
  → 振り分け方式に従って 空いている健全なサーバを選ぶ
  → 選ばれたサーバが 処理を実行して結果を返す
  → ロードバランサを経由して ブラウザに応答が届く
      （1台が停止していれば その台は選ばれず残りの台で処理を継続）

この流れの中で、ロードバランサは「受付」と「交通整理」と「稼働監視」を同時に担っていることが読み取れます。利用者からは1つの入り口に見えていても、その裏側では複数のサーバが分担して処理を支えている、という構図です。障害が起きたときに「特定の操作だけが遅い」「一部の利用者だけ挙動が違う」といった症状が出た場合、振り分けやセッション維持の設定に目を向けると、原因の切り分けが進みやすくなることもあります。

まとめ

• ロードバランサとは、リクエストを複数のサーバに振り分けて負荷を分散する仕組みで、より多くのアクセスを捌く拡張性と、一部停止時もサービスを続ける可用性の両面を支えます。
• 振り分けにはラウンドロビン、重み付け、最小接続数、IPハッシュなどの方式があり、サーバ構成やアプリの性質に応じて選ばれます。
• IP・ポートで捌くL4型と、URLやCookieまで見て振り分けるL7型があり、用途によって使い分けます。
• 導入形態はハードウェア型・ソフトウェア型・クラウドのマネージド型に大別され、環境や運用体制に応じて選択します。
• 選定・運用では、ヘルスチェック、セッション維持、TLS終端、ロードバランサ自体の冗長化、監視とオートスケール連携といった観点が要点になります。
• 本記事は特定製品の設定手順ではなく、負荷分散という仕組みの考え方と、発注・運用で押さえたい観点の整理を狙いとしています。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• AWS「ロードバランシングとは」
• Google Cloud「Cloud Load Balancing overview」
• nginx「Using nginx as HTTP load balancer」

Tweet