ロードバランサーの基礎 ― 中小企業の自社サービス公開・冗長化の選択肢を整理
「自社Webサービスを冗長化したい」「サーバ1台では捌ききれない」「アクセス急増で落ちた」――業務でWebサービスを運営する中小企業が必ず通る課題が**ロードバランサー（負荷分散装置）**の導入です。
ロードバランサーは「複数のサーバに負荷を振り分ける」だけでなく、冗長化・SSL終端・セキュリティ機能まで担う重要なインフラ機器です。本記事では、中小企業の情シスが自社サービス公開・冗長化を検討する際に押さえるべきロードバランサーの基礎を整理します。
ロードバランサーとは
ロードバランサー（Load Balancer, LB）は、複数のサーバに通信を分散して送るための機器・ソフトウェアです。クライアントから見れば1つのアドレス（VIP: Virtual IP）に接続しているだけですが、内部では複数のサーバに振り分けられています。
[クライアント]
│
▼
[ロードバランサー（VIP）]
│ 振り分け
┌──┴──┬──────┐
▼ ▼ ▼
[Web1][Web2][Web3]主な役割：
① 負荷分散。 複数サーバへトラフィックを分散し、1台あたりの負荷を抑制。
② 冗長化（高可用性）。 1台のサーバが故障しても、他のサーバで継続稼働。
③ ヘルスチェック。 各サーバの応答を定期確認し、異常時は自動的に振り分け対象から除外。
④ SSL/TLS終端。 クライアント⇔LB間を暗号化、LB⇔サーバ間は平文として、サーバ側のCPU負荷を軽減。
⑤ セキュリティ。 WAF（Webアプリケーションファイアウォール）連携、DDoS緩和、レート制限。
L4ロードバランサー と L7ロードバランサー
ロードバランサーは、動作するOSI参照モデルの階層で2種類に分かれます。
| 種別 | 動作層 | 振り分け基準 | 用途 |
|---|---|---|---|
| L4 LB | トランスポート層 | IP・TCPポート | 高速・低レイテンシ。汎用通信 |
| L7 LB | アプリケーション層 | HTTPヘッダ・URL・Cookie | Webアプリケーション特化 |
L4ロードバランサー
IPアドレスとポート番号だけを見て振り分けるため、処理が高速でWeb以外の通信（メール、FTP、独自プロトコル等）にも使えます。複雑なルーティングは苦手。
例：AWS NLB（Network Load Balancer）、Azure Load Balancer、HAProxy（L4モード）、Linux Virtual Server（LVS）
L7ロードバランサー
HTTPヘッダの中身まで見て振り分けるため、URL別、ホスト名別、Cookie別などの細かい制御が可能。Webアプリケーション特化で、SSL終端・WAF・キャッシュ等の機能が豊富。
例：AWS ALB（Application Load Balancer）、Azure Application Gateway、Nginx、HAProxy（L7モード）、Apache mod_proxy
中小企業のWebサービス公開では、L7ロードバランサーが標準です。
振り分けアルゴリズム
ロードバランサーがリクエストをどのサーバに振るかの方式：
| アルゴリズム | 概要 |
|---|---|
| ラウンドロビン | 順番に振る。最も単純 |
| 重み付きラウンドロビン | サーバの性能差を反映して比率配分 |
| 最小コネクション | 接続数が最も少ないサーバへ |
| IPハッシュ | クライアントIPで固定的に振る（セッション維持） |
| URLハッシュ | URLで固定的に振る（キャッシュ効率向上） |
セッションを維持したいWebアプリ（ログイン状態を保ちたいなど）では、IPハッシュまたは**Cookie維持（Sticky Session）**を使うのが定番です。
中小企業向けロードバランサーの選択肢
① ハードウェアロードバランサー（高価格帯）
| 製品 | 概要 |
|---|---|
| F5 BIG-IP | 業界標準。エンタープライズ向け |
| Citrix NetScaler | 大規模Webサービス向け |
| A10 Thunder | 国内導入実績あり |
1台あたり数百万〜数千万円規模で、中小企業ではほぼ採用されません。エンタープライズ要件の場合のみ選択肢に入ります。
② ソフトウェアロードバランサー（オープンソース）
| 製品 | 概要 |
|---|---|
| Nginx | Webサーバ兼用L7 LB。中小企業の定番 |
| HAProxy | L4/L7両対応。高性能 |
| Apache mod_proxy_balancer | Apacheベース |
| Traefik | コンテナ環境向け |
| Envoy | サービスメッシュ系 |
Linux VM上にNginxまたはHAProxyを構築する構成は、中小企業のWebサービス基盤として最もコスト効率の良い選択肢です。
③ クラウドロードバランサー（SaaS／マネージド）
| サービス | 提供元 | 種別 |
|---|---|---|
| AWS ALB | AWS | L7 |
| AWS NLB | AWS | L4 |
| Azure Application Gateway | Microsoft | L7 + WAF |
| Azure Load Balancer | Microsoft | L4 |
| Google Cloud Load Balancing | L4/L7 | |
| Cloudflare Load Balancer | Cloudflare | L7 + CDN |
クラウドのマネージドLBは、冗長化・スケーリング・監視が組み込みで、中小企業のWebサービス公開で最も推奨される選択肢です。月額1〜3万円程度から利用可能。
④ CDN兼用ロードバランサー
| サービス | 概要 |
|---|---|
| Cloudflare | DDoS防御 + CDN + LB |
| Akamai | エンタープライズCDN + LB |
| Fastly | エッジコンピューティング |
自社サービスを公開していて、攻撃対策・速度改善も重要な場合、CloudflareやFastlyが第一選択肢になります。月額数千円から始められ、無償プランもあります。
中小企業の構成例
構成例1：シンプルなWeb冗長化（オンプレ）
[インターネット]
│
[FortiGate/UTM]
│
[Linux VM: Nginx LB]
│
┌──┴──┐
[Web1] [Web2]
│ │
└──┬──┘
│
[NAS / DB]社内Web基盤、小規模ECサイト、社内ポータル等。Nginx 1台 + Web 2台で構成。月額追加コスト：数万円（VM運用費）。
構成例2：クラウド完全マネージド
[インターネット]
│
[Cloudflare / CDN+WAF]
│
[AWS ALB / Azure App Gateway]
│
[EC2 × 2台 または Container Apps]
│
[Aurora / Azure SQL]自社開発のSaaSサービス、顧客向けWebアプリ、ECサイト等。冗長化・スケーリング・WAFがセットで運用できる。月額：5〜30万円規模。
構成例3：オンプレ・クラウドハイブリッド
オンプレのWebサーバを、Cloudflare Load Balancer経由で公開し、障害時はクラウド側のフェイルオーバー先に切り替え。BCP対策として有効。
ロードバランサー導入で押さえるべきポイント
① セッション維持（Sticky Session）
ログイン状態を保つWebアプリの場合、同じクライアントを同じサーバに振り続ける必要があります。Cookie維持が一般的で、ALBやNginxで簡単に設定できます。
セッション情報をRedisやデータベースに集約する外部セッションストア方式を取れば、Sticky不要で純粋に負荷分散できます。
② SSL/TLS終端
ロードバランサーでSSL終端する設計が一般的。クライアント⇔LB間がHTTPS、LB⇔サーバ間がHTTPで、サーバ側のCPU負荷を軽減できます。
ただし、社内ネットワーク内でも暗号化が必要な業界（金融、医療等）では、LB⇔サーバ間もHTTPSにする「SSLパススルー」または「SSLブリッジ」を検討してください。
③ ヘルスチェックの設定
ヘルスチェック設定が甘いと、故障サーバに振り分け続けて全リクエスト失敗という事態が起きます。
- ヘルスチェックエンドポイントを専用に作る（
/health等） - 応答が200以外なら除外
- 連続N回失敗で除外、連続M回成功で復帰
- 正常系のレスポンス内容まで検証する（HTTP 200を返すが中身が異常な場合あり）
④ ログ集約
ロードバランサーのアクセスログは、全Webリクエストの入り口にあたります。SIEM・Datadog・CloudWatch等に集約して、攻撃検知・性能分析に使ってください。
⑤ WAF併用
公開Webサービスでは、WAF（Web Application Firewall）併用が事実上必須です。
- AWS WAF（ALB併用）
- Azure WAF（Application Gateway内蔵）
- Cloudflare WAF
- Akamai Kona Site Defender
SQLインジェクション、XSS、ボットアクセス、DDoS攻撃の緩和に大きく寄与します。
ロードバランサー導入で陥りやすい失敗
① 冗長化と称してロードバランサー1台で構成。 LB自体が単一障害点になります。クラウドLBはマネージドで自動冗長化されているが、自前構築のNginx/HAProxyは**Active/Standby構成（Keepalived等）**にする必要があります。
② SSL終端でTLS 1.0/1.1のサポートを残す。 監査・PCI DSS等で指摘されます。TLS 1.2以上のみを有効化。
③ ヘルスチェック先がトップページ。 トップページは複雑な処理を行うため重い。専用の軽量エンドポイントを用意してください。
④ DBサーバへの負荷集中を見落とす。 Webサーバを5台に増やしても、DBが1台のままなら結局DBがボトルネック。DB側の冗長化・スケールもセットで考えてください。
⑤ クラウドLBの料金を見誤る。 「データ転送量に応じた課金」「リクエスト数課金」等で、想定外の月額になるケース。事前に料金シミュレーションを実施してください。
まとめ
ロードバランサーは「負荷分散＋冗長化＋SSL終端＋セキュリティ」の基盤機能を担う重要なインフラ要素です。中小企業の選択肢は「Nginx/HAProxy（オンプレ）」「クラウドマネージドLB（AWS ALB / Azure App Gateway）」「Cloudflare等のCDN兼用LB」の3パターンが現実的で、用途・予算・運用体制で選び分けます。SSL終端・ヘルスチェック・WAF併用・DBの並行スケーリングは、設計段階から織り込んでください。
情シス365のProject365では、自社サービス公開・冗長化のためのロードバランサー設計・構築を支援しています。無料ヒアリングからお気軽にどうぞ。