初心者向けロードバランサーの設定完全入門ガイド【2026年版】

※本記事にはプロモーション（広告）を含みます。

ロードバランサーの設定は、まずヘルスチェックの間隔・しきい値・タイムアウト値の3点から着手してください。分散アルゴリズムの選定だけを済ませて満足すると、バックエンドサーバーが停止した後も古いノードへ通信が流れ続け、ユーザーにエラー画面を返し続ける事態につながります。本記事では、AWSやNginxなど実際に広く使われている選択肢を例に、初心者がつまずきやすい設定項目を手順ごとに整理し、運用フェーズで見落としがちな監視・セキュリティ設定まで解説します。技術情報はいずれもバージョンによって挙動が変わるため、実際の設定時は各サービスの公式ドキュメントを必ず確認してください。

ロードバランサーの基本仕組み

ロードバランサーは、クライアントからのリクエストを複数のサーバーに振り分ける中継役です。単純に「トラフィックを分ける装置」と捉えると設定作業でつまずきます。実際には通信をどの階層で処理するか、どのアルゴリズムで振り分けるかによって、扱うパラメータも障害時の挙動も大きく異なります。設定を始める前に、この2軸を押さえておく必要があります。

L4とL7の違い

L4(トランスポート層)ロードバランサーは、IPアドレスとポート番号を見てTCP/UDP単位で振り分けます。パケットの中身を解釈しないため処理は高速ですが、URLパスやHTTPヘッダーに基づく振り分けはできません。一方、L7(アプリケーション層)ロードバランサーはHTTPリクエストの内容まで読み取り、パス単位・ホスト名単位でルーティング先を変えられます。マイクロサービス構成でAPIごとに異なるバックエンドへ振り分けたい場合はL7が前提になります。逆に、単純なDBプロキシやゲームサーバーのようにレイテンシを最優先する構成では、L4のほうが適した場面が多くあります。まず自分のシステムがどちらの要件に該当するかを整理してから、設定に進んでください。

主な分散方式の種類

分散アルゴリズムには複数の方式があり、代表的なものは以下のとおりです。

方式名	振り分けの考え方	向いている用途
ラウンドロビン	順番に均等割り当て	サーバー性能が均一な構成
最小コネクション数	接続数が少ないサーバーへ優先割り当て	処理時間にばらつきがある構成
IPハッシュ	送信元IPで固定的に割り当て	セッション維持が必要な構成
重み付きラウンドロビン	サーバーの性能比率に応じて配分	スペックが異なるサーバー混在構成

セッション情報をサーバー側で保持するアプリケーションでは、IPハッシュやCookieベースのセッション永続化を選ばないと、同じユーザーのリクエストが毎回別サーバーに飛び、ログイン状態が切れる不具合が起きます。設定画面で「Sticky Session」や「セッションアフィニティ」といった項目があれば、この問題への対応機能です。

設定前に確認すべき準備

ロードバランサーの管理画面を開く前に、システム構成図とネットワーク要件を整理しておくと、設定作業の手戻りが大幅に減ります。ここでは特に見落とされやすい2点を取り上げます。

ヘルスチェックの設計

ヘルスチェックは、バックエンドサーバーが正常に応答しているかを定期的に確認し、異常があれば振り分け対象から自動的に除外する仕組みです。設定項目は主に4つあります。

チェック間隔:何秒ごとに確認するか
タイムアウト:応答をどれだけ待つか
異常判定回数:何回連続で失敗したら切り離すか
復帰判定回数:何回連続で成功したら戻すか

間隔を短くしすぎるとバックエンドへの負荷が増え、長くしすぎると障害検知が遅れます。目安として、チェック間隔5〜10秒、異常判定2〜3回連続失敗という設定から始め、実際のトラフィックパターンを見ながら調整する運用が現実的です。ヘルスチェック用のエンドポイントは、DB接続確認まで含めた専用パス(例:/healthz)を用意し、単なる200応答だけを返すページとは切り分けることをおすすめします。単純なpingだけでは、アプリケーションが起動していてもDB接続が切れている状態を検知できません。

ネットワーク要件の確認

クラウド環境でロードバランサーを構築する場合、サブネット構成とセキュリティグループ(またはファイアウォールルール)の設計が前提になります。パブリック向けロードバランサーはインターネットゲートウェイに到達可能なサブネットに配置し、バックエンドサーバーは直接インターネットからアクセスできないプライベートサブネットに置く構成が基本形です。この構成にしておくと、バックエンドへの不正アクセスをロードバランサー層で一元的にブロックできます。加えて、複数のアベイラビリティゾーンにまたがってロードバランサーとバックエンドを配置しておくと、1つのゾーンで障害が発生してもサービス全体は継続できます。単一ゾーン構成のまま本番稼働させると、そのゾーン障害がそのままサービス停止に直結する点は事前に理解しておく必要があります。

主要サービスの設定手順

ロードバランサーの実装方法は、クラウドが提供するマネージドサービスを使う方法と、OSS製品をサーバー上に構築する方法の大きく2つに分かれます。それぞれの代表的な選択肢と特徴を整理します。

サービス比較表

サービス	提供形態	対応層	特徴
AWS Elastic Load Balancing	クラウドマネージド	L4/L7	Application Load Balancer(L7)とNetwork Load Balancer(L4)を用途別に選択可能
Google Cloud Load Balancing	クラウドマネージド	L4/L7	グローバル単一IPで複数リージョンに振り分け可能
Azure Load Balancer	クラウドマネージド	L4	Azure Application Gatewayと組み合わせてL7機能を追加
NGINX	OSS・ミドルウェア	L7中心	Webサーバー機能と兼用でき、設定ファイルベースで柔軟に制御
HAProxy	OSS・ミドルウェア	L4/L7	高負荷環境での実績が長く、詳細なルーティング制御が可能

クラウドマネージド型はスケーリングや冗長化を運用側が意識せずに済む利点がある一方、細かい挙動のカスタマイズには制約があります。OSS製品はサーバーへのインストールと設定ファイル管理が必要になりますが、ルーティングロジックを細部まで制御できます。小規模な自社サービスであればマネージド型から始め、要件が複雑化した段階でOSS製品への移行を検討する流れが無理のない進め方です。

AWSでの設定手順

AWSでApplication Load Balancer(ALB)を構築する場合の大まかな流れは次のとおりです。

VPC内に最低2つのアベイラビリティゾーンをまたぐパブリックサブネットを用意する
ターゲットグループを作成し、バックエンドのEC2インスタンスやコンテナを登録する
ターゲットグループに対してヘルスチェックパスと間隔を設定する
ALB本体を作成し、リスナー(80番・443番など)とターゲットグループを紐付ける
HTTPSを使う場合はACM(AWS Certificate Manager)で証明書を発行し、リスナーに割り当てる

ALBはパスベースルーティングやホストベースルーティングに対応しているため、1つのALBで複数のマイクロサービスへの振り分けをまとめて管理できます。設定内容や画面構成はAWSのアップデートで変更されることがあるため、実際の操作手順はAWS公式ドキュメントの最新版で確認してください。

Nginxでの構築手順

NginxをL7ロードバランサーとして使う場合、upstreamブロックでバックエンドサーバー群を定義し、serverブロックのproxy_passでそこへ振り分けます。基本的な設定例は次のとおりです。

upstream backend_servers {
    least_conn;
    server 10.0.1.11:8080 weight=3;
    server 10.0.1.12:8080 weight=1;
    server 10.0.1.13:8080 backup;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

この例ではleast_connで最小コネクション数方式を指定し、weightでサーバーごとの処理比率を調整、backupで通常時は使わない予備サーバーを指定しています。proxy_set_headerでクライアントの元IPをバックエンドに伝えておかないと、アクセスログがすべてロードバランサーのIPになり、アクセス解析や不正アクセス検知が機能しなくなる点に注意してください。設定変更後はnginx -tで構文チェックを行ってからリロードする手順を徹底すると、設定ミスによる全断を防げます。バージョンによってディレクティブの挙動が変わることがあるため、詳細はNginx公式ドキュメントを参照してください。

運用でつまずきやすい点

初期設定が完了した後も、運用フェーズ特有のトラブルが発生します。ここでは特に問い合わせが多い2つのテーマを扱います。

SSL証明書の更新管理

HTTPS通信を扱うロードバランサーでは、証明書の有効期限切れがサービス全断の直接原因になります。クラウドマネージド型であればACMのような証明書管理サービスと連携し、自動更新を有効にしておくのが基本の対策です。自前でLet’s Encryptなどを利用する構成では、更新処理をcronやsystemdタイマーで自動化し、更新失敗時にはアラートが飛ぶ仕組みまで組んでおく必要があります。証明書の有効期限だけを見るのではなく、更新ジョブ自体が正常に動いているかを別途監視することが、実際の障害を防ぐうえで欠かせません。

閾値チューニングの勘所

本番稼働直後は、ヘルスチェックの異常判定回数を厳しく設定しすぎて、一時的な高負荷でも正常なサーバーが切り離されてしまうケースがよく起こります。逆に緩すぎる設定では、実際に障害が起きたサーバーへの振り分けが止まらず、ユーザーにエラーが返り続けます。目安として、アクセスログとヘルスチェックの失敗ログを突き合わせ、実際の障害発生タイミングと切り離しタイミングにどれだけのずれがあるかを最初の数週間は継続的に確認してください。切り離しまでに数分かかっているようであれば、チェック間隔と異常判定回数を見直す余地があります。

セキュリティと監視のコツ

ロードバランサーはシステムの入り口にあたるため、セキュリティ設定と監視体制の不備がそのまま全体のリスクに直結します。

アクセス制御の設定

ロードバランサーに割り当てるセキュリティグループやファイアウォールルールは、必要なポートと送信元だけに絞り込んでください。管理用ポートを不特定多数に開放したまま運用すると、外部からのスキャンや攻撃対象になりやすくなります。WAF(Web Application Firewall)を併用できるサービスでは、SQLインジェクションやクロスサイトスクリプティングといった既知の攻撃パターンをロードバランサー層でブロックできるため、バックエンド側の実装ミスをカバーする層としても機能します。ただし、WAFのルール設定自体を誤ると正常なリクエストまで遮断してしまうため、本番適用前にログモードで動作確認する手順を挟んでください。セキュリティ設定の最終的な妥当性は、各社の環境やコンプライアンス要件によって異なるため、自己責任のもとで検証したうえで本番反映することが前提になります。

ログ監視体制の構築

ロードバランサーのアクセスログには、レスポンスタイム・ステータスコード・振り分け先サーバーといった情報が記録されます。これらを継続的に収集し、5xx系エラー率やレスポンスタイムの急上昇を検知できるダッシュボードを用意しておくと、障害の予兆を早期につかめます。特定のバックエンドサーバーだけエラー率が高い状態が続く場合、ヘルスチェックの閾値設定が緩すぎて切り離しが機能していない可能性を疑ってください。監視ツールはクラウド標準のもの(CloudWatchなど)でも、OSSの監視スタックでも構いませんが、アラートが実際に担当者へ届く経路まで含めてテストしておくことが、監視体制を形だけで終わらせないための最低条件です。

よくある質問

Q1. ロードバランサーは何台から必要ですか

バックエンドサーバーが2台以上になった時点で導入を検討する価値があります。1台構成でも、将来的なスケールアウトを見据えて先にロードバランサーを挟んでおくと、後からの構成変更を避けられます。

Q2. L4とL7はどちらを選べばよいですか

URLパスやドメイン名で振り分け先を変える必要があるならL7、単純なTCP/UDP通信をとにかく高速に中継したいならL4が基本の選び方です。両方の要件がある場合は、L4とL7を多段構成にする方法もあります。

Q3. ヘルスチェックの間隔はどれくらいが適切ですか

目安として5〜10秒間隔から始め、実際の障害検知にかかった時間とサーバー負荷を見ながら調整してください。頻度を上げすぎるとヘルスチェック自体がバックエンドの負荷要因になります。

Q4. 無料で使えるロードバランサーはありますか

NginxやHAProxyはOSSとして無料で利用でき、自前のサーバーにインストールして構築できます。クラウドのマネージド型ロードバランサーは従量課金制のサービスが一般的で、料金体系は各社の公式サイトで最新情報を確認してください。

Q5. 設定変更はサービス無停止で反映できますか

多くのクラウドマネージド型サービスは設定変更を無停止で反映できます。Nginxのような自前構築の場合も、設定ファイルの構文チェック後にリロードコマンドを使えば、接続中のセッションを維持したまま新しい設定を適用できます。

Q6. セッションが切れる不具合はどう直せばよいですか

セッション情報をサーバー側のメモリに保持している構成が原因のことが多く、まずはIPハッシュやCookieベースのセッション永続化を有効にしてください。根本対応としては、セッション情報をRedisなどの外部ストアに切り出し、どのサーバーが応答してもセッションを共有できる構成に変更する方法があります。

まとめ

ロードバランサーの設定は、分散アルゴリズムの選択だけで完結する作業ではありません。ヘルスチェックの間隔・タイムアウト・異常判定回数といった細かなパラメータが、実際の障害検知速度を左右します。導入初期はAWSやGoogle Cloudのようなマネージド型サービスで基本構成を固め、要件が複雑化した段階でNginxやHAProxyといったOSS製品によるきめ細かな制御を検討する流れが現実的な進め方です。設定を反映した後も、アクセスログとヘルスチェックの結果を突き合わせて閾値を継続的に見直し、証明書更新やアラート経路まで含めた監視体制を維持することが、安定稼働を支える土台になります。バージョンや仕様は各サービスのアップデートで変わるため、実際の設定作業では必ず公式ドキュメントの最新情報を確認し、セキュリティ設定は自己責任のもとで検証したうえで本番環境へ反映してください。

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク