この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第34回です。
第4章では、クラウド環境でネットワークを設計するときに必要となる、 仮想ネットワーク、ルーティング、セキュリティ、負荷分散、外部接続などを学びます。
ロードバランサーとは？仕組み・L4/L7・ヘルスチェック・設計ポイントを解説
Webサービスへアクセスが集中したとき、1台のサーバーですべての通信を処理すると、 性能不足やサーバー障害がそのままサービス停止につながります。 ロードバランサーは、複数のサーバーへ通信を振り分け、 性能と可用性を高めるための重要な仕組みです。 この記事では、クラウドネットワークを設計するうえで必要なロードバランサーの基本を整理します。
ロードバランサーを理解するとき、 「アクセスを複数サーバーへ均等に振り分ける機器」 とだけ覚えるのは不十分です。
実務では、 どのレイヤーで振り分けるのか、障害サーバーをどう除外するのか、 セッションを維持する必要があるのか、TLSをどこで終端するのか まで考えて設計します。
この記事を読み終えるとできること
- ロードバランサーの役割を説明できる
- L4とL7ロードバランサーの違いを説明できる
- ヘルスチェックの必要性を説明できる
- 代表的な負荷分散方式を比較できる
- パブリックと内部ロードバランサーを使い分けられる
- 可用性を考慮した負荷分散構成を検討できる
ロードバランサーとは何か
ロードバランサーとは、利用者から受け取った通信を 複数のサーバーやサービスへ振り分ける仕組みです。
英語では Load Balancer、 処理そのものは Load Balancing と呼ばれます。
たとえば、Webサイトを3台のWebサーバーで提供しているとします。 利用者が3台それぞれのIPアドレスを意識してアクセスする構成では、 利用者側で接続先を選ばなければなりません。
ロードバランサーを配置すると、利用者は ロードバランサーの1つの接続先 へアクセスするだけで済みます。
LOAD BALANCING｜ロードバランサーの基本イメージ
ポイント
利用者から見ると接続先は1つでも、 その後ろでは複数のサーバーが処理を担当できます。
なぜロードバランサーが必要なのか
ロードバランサーには、大きく 性能・可用性・運用性 の3つの目的があります。
負荷を分散する
1台へアクセスが集中するのを防ぎ、 複数のサーバーで処理を分担できます。
障害に強くする
1台のサーバーが故障した場合、 正常なサーバーへ通信を振り分けられます。
拡張しやすくする
利用者や通信量が増えたとき、 バックエンドサーバーを追加して処理能力を増やせます。
ロードバランサーがない場合
サーバー1台でサービスを提供する構成
この構成では、サーバーのCPUやメモリ、ネットワーク、 アプリケーション処理能力が限界に達すると、 レスポンスが遅くなる可能性があります。
また、その1台が停止すれば、 サービス全体が利用できなくなる可能性があります。
ロードバランサーを使った場合
複数サーバーへアクセスを分散する構成
サーバーを複数台にすることで、 1台あたりの負荷を減らし、 障害時にも残りのサーバーで処理を継続しやすくなります。
サーバーを複数台並べるだけでは十分ではありません。
「どのサーバーが正常なのか」 「次の通信をどこへ送るのか」 を判断する役割が必要です。 その役割をロードバランサーが担当します。
ロードバランサーの基本構成
クラウドでWebサービスを公開するときの 一般的な構成を簡略化すると、次のようになります。
CLOUD LOAD BALANCING｜基本構成
主な構成要素
| 構成要素 | 役割 |
|---|---|
| フロントエンド | 利用者から通信を受け付けるIPアドレスやポート |
| リスナー | どのプロトコル・ポートで通信を受けるかを定義する |
| バックエンド | 実際に処理を行うサーバー、コンテナ、サービスなど |
| 振り分けルール | どの通信をどのバックエンドへ送るかを決める |
| ヘルスチェック | バックエンドが正常に処理できる状態かを確認する |
設計では「ロードバランサー1台」を見るのではなく、
フロントエンド、リスナー、バックエンド、 ヘルスチェック、セキュリティ制御までを 一つの通信経路として考えます。
通信が振り分けられる流れ
利用者がWebサービスへアクセスする場合を例に、 ロードバランサーの動きを確認します。
- 利用者がサービスへアクセスする DNSで名前解決した後、利用者はロードバランサー側の接続先へ通信します。
- ロードバランサーが通信を受信する HTTPSであればTCP 443など、設定されたリスナーで通信を受け付けます。
- 振り分け対象を確認する 通信内容や設定されたルールから、対象となるバックエンドグループを判断します。
- 正常なバックエンドを選択する ヘルスチェックで正常と判断されているサーバーなどから接続先を選びます。
- バックエンドへ通信を転送する 選択したサーバーへ通信を送り、サーバーがアプリケーション処理を行います。
- 応答を利用者へ返す サーバーの応答がロードバランサーを経由して利用者へ返されます。
実際の通信経路や送信元IPアドレスの見え方、 コネクションの扱いは、 ロードバランサーの種類やクラウドサービスによって異なります。
設計時は利用するサービスの仕様を確認してください。
L4とL7ロードバランサーの違い
ロードバランサーを理解するうえで重要なのが、 L4とL7 の違いです。
| 項目 | L4ロードバランサー | L7ロードバランサー |
|---|---|---|
| 主に見る情報 | IPアドレス、TCP/UDP、ポートなど | HTTP/HTTPSのURL、Host、ヘッダーなど |
| OSI参照モデル | 第4層付近 | 第7層付近 |
| 得意な用途 | TCP/UDP通信の高速な分散 | Webアプリケーションの柔軟な振り分け |
| HTTP内容を使った制御 | 基本的に行わない | 可能 |
| 例 | 接続先ポートによる分散 | URLパスやホスト名による分散 |
L4ロードバランサー
L4ロードバランサーは主に、 IPアドレス、TCPやUDP、ポート番号などの情報を使って 通信を処理します。
L4 LOAD BALANCING
L7ロードバランサー
L7ロードバランサーでは、 HTTPやHTTPSの内容を利用して、 より細かく振り分けることができます。
たとえば、次のようなルールを作れます。
| 条件 | 転送先 |
|---|---|
| example.com/shop/* | ECサイト用サーバー群 |
| example.com/api/* | APIサーバー群 |
| admin.example.com | 管理画面用サーバー群 |
L7 LOAD BALANCING｜URLによる振り分け例
「L7の方が上位だから常に優れている」わけではありません。
必要なプロトコル、性能、振り分け条件、 TLS処理、アプリケーション要件などを踏まえて選びます。
代表的な負荷分散方式
正常なバックエンドが複数存在するとき、 次に決めるのが どのサーバーへ通信を送るか です。
Round Robin
Server A → B → C → Aのように、 順番に振り分ける考え方です。
Least Connections
現在の接続数が少ないサーバーへ 新しい接続を振り分ける考え方です。
Weighted
サーバーごとに重みを設定し、 高性能なサーバーへ多く振り分ける考え方です。
Weightedの例
| サーバー | 性能 | 重みの例 |
|---|---|---|
| Server A | 高性能 | 50 |
| Server B | 標準 | 30 |
| Server C | 低性能 | 20 |
ただし、実際に利用できるアルゴリズムや動作は 製品・クラウドサービスごとに異なります。
クラウドではロードバランサーの内部アルゴリズムを 利用者が細かく指定できないサービスもあります。
「一般的なロードバランサーの知識」と 「利用するクラウドサービスの具体的な仕様」を分けて確認しましょう。
ヘルスチェックの仕組み
ロードバランサーの可用性を考えるうえで 特に重要なのが ヘルスチェック です。
ヘルスチェックとは、バックエンドが正常にサービスを提供できる状態かを ロードバランサーなどが定期的に確認する仕組みです。
HEALTH CHECK｜異常サーバーを振り分け対象から外す
Server Bが異常と判断された場合、 新しい通信をServer Bへ送らず、 Server AとServer Cへ振り分けます。
何を確認するかが重要
たとえばWebアプリケーションの場合、 TCPポートが開いているだけでは、 アプリケーションが正常とは限りません。
| 確認方法 | 分かること | 注意点 |
|---|---|---|
| TCP接続 | 指定ポートで接続できるか | アプリケーション内部の異常までは判断できない場合がある |
| HTTP GET / | WebサーバーからHTTP応答が返るか | トップページだけ正常でも内部処理が異常な可能性がある |
| HTTP GET /health | アプリケーション用の正常性確認 | 何をもってHealthyとするかをアプリ側と決める必要がある |
ヘルスチェックで決める主な項目
- 使用するプロトコル
- 接続先ポート
- HTTPの場合の確認パス
- 実行間隔
- タイムアウト時間
- 何回失敗したら異常と判断するか
- 何回成功したら正常へ戻すか
ヘルスチェックを厳しくしすぎることにも注意が必要です。
一時的な遅延だけで大量のサーバーを異常判定すると、 残ったサーバーへ通信が集中し、 障害を拡大させる可能性があります。
外部向けと内部向けロードバランサー
ロードバランサーは、 インターネット公開サービスだけに使うものではありません。
企業システムでは、 外部向けと内部向け を使い分けることがあります。
外部向け
インターネットなど外部ネットワークから アクセスを受け付けるロードバランサーです。
- 公開Webサイト
- 公開API
- インターネット向けサービス
内部向け
社内やクラウド内部など、 限定されたネットワークからのみ利用する構成です。
- 社内業務システム
- 内部API
- アプリケーション層間通信
PUBLIC / INTERNAL LOAD BALANCER
すべてのシステムをインターネットへ公開する必要はありません。
アプリケーションの役割と通信元を整理し、 外部公開が必要な入口だけを公開することが基本です。
セッション維持とは
ロードバランサーでは、 同じ利用者の通信が毎回異なるサーバーへ 振り分けられる場合があります。
アプリケーションによっては、 同じ利用者を一定時間同じバックエンドへ振り分けたいことがあります。
この考え方は Session Persistence、Session Affinity、Sticky Session などと呼ばれます。
SESSION PERSISTENCE
なぜ必要になるのか
たとえば、ログイン状態などの情報を 各Webサーバーのローカルメモリだけに保存している場合、 別サーバーへ振り分けられると、 利用者の状態を引き継げない可能性があります。
ただし、セッション維持に依存しすぎない
クラウドでは、 Webサーバーを追加・削除しやすい構成が重要です。
そのため、可能であればセッション情報を 外部の共有ストレージやデータストアへ持たせ、 どのサーバーへ振り分けられても処理できる ステートレスな構成 を検討します。
セッション維持は便利ですが、 特定サーバーへアクセスが偏る原因になる場合があります。
「設定できるから使う」のではなく、 アプリケーション側のセッション管理方式を確認して判断します。
TLS終端をどこで行うか
HTTPSを利用する場合、 TLS通信をどこで復号するかも重要な設計項目です。
ロードバランサーでTLS終端する構成
TLS TERMINATION AT LOAD BALANCER
ロードバランサー側でTLSを終端すると、 証明書管理をロードバランサー側へ集約しやすくなります。
一方で、 ロードバランサーからバックエンドまでの通信も 暗号化する必要がある環境では、 バックエンド側までHTTPSを使用する構成を検討します。
| 区間 | 構成例 |
|---|---|
| Client → Load Balancer | HTTPS |
| Load Balancer → Backend | HTTPまたはHTTPS |
TLSをどこで終端するかは、 セキュリティ要件、運用、証明書管理、性能 などを考慮して決定します。
ロードバランサー設計で確認するポイント
実務では「ロードバランサーを置く」と決めただけでは 設計は完成しません。
1．どの通信を負荷分散するのか
- HTTPかHTTPSか
- TCPかUDPか
- 待ち受けポートは何番か
- 利用者はインターネットか社内か
- IPv4・IPv6の要件はあるか
2．L4とL7のどちらが必要か
- URLによる振り分けが必要か
- ホスト名による振り分けが必要か
- HTTPヘッダーなどを使った制御が必要か
- HTTP以外のTCP/UDP通信か
3．バックエンドをどこへ配置するか
高可用性を求める場合、 すべてのサーバーを同じ障害領域へ配置するのではなく、 複数の障害領域へ分散することを検討します。
AVAILABILITY DESIGN｜複数障害領域へ分散
4．ヘルスチェックを何にするか
- TCPだけで十分か
- HTTPの特定パスまで確認するか
- チェック間隔は何秒か
- 異常判定まで何回失敗を許容するか
- 正常復帰を何回の成功で判断するか
5．セッションをどう扱うか
- バックエンドに状態を持っているか
- Sticky Sessionが必要か
- ステートレス化できないか
- セッション情報を共有ストアへ移せないか
6．TLSをどこで終端するか
- 証明書はどこで管理するか
- バックエンドまで暗号化するか
- 証明書更新を誰が行うか
- 使用するTLS設定に要件があるか
7．セキュリティ制御
ロードバランサー単体だけでなく、 前の記事で学んだルートテーブルや セキュリティ制御との組み合わせも確認します。
- 利用者からロードバランサーまで許可されているか
- ロードバランサーからバックエンドまで許可されているか
- ヘルスチェック通信が許可されているか
- バックエンドを直接インターネット公開する必要があるか
- 管理アクセスをどこから許可するか
8．タイムアウト
長時間処理するアプリケーションでは、 ロードバランサー側のタイムアウト値と アプリケーション処理時間の関係を確認します。
ネットワーク障害に見えても、 実際にはロードバランサーのタイムアウト設定が原因ということがあります。
9．ログと監視
- リクエスト数
- 接続数
- レスポンスタイム
- エラー数
- Healthy / Unhealthyバックエンド数
- ロードバランサーのアクセスログ
- バックエンド側のアプリケーションログ
10．スケーリングとの連携
クラウドでは、アクセス増加時にバックエンドを追加し、 負荷が減ったら削除する オートスケーリング とロードバランサーを組み合わせることがあります。
LOAD BALANCER + AUTO SCALING
ロードバランサー設計でよくある失敗
1．サーバーを複数台にしただけで安心する
ヘルスチェックや障害領域まで考えていないと、 サーバーを増やしても期待した可用性を得られません。
2．ヘルスチェックが浅すぎる
TCPポートだけ確認していると、 Webプロセスは動いていてもアプリケーションが利用できない状態を 正常と判断する場合があります。
3．ヘルスチェックが厳しすぎる
一時的な処理遅延だけでサーバーを切り離すと、 残ったサーバーへ負荷が集中する可能性があります。
4．バックエンドを直接公開する
ロードバランサー経由だけを想定しているにもかかわらず、 バックエンドへインターネットから直接アクセスできると、 セキュリティ設計の意図が崩れる場合があります。
5．セッションを考慮していない
アプリケーションがサーバー内に状態を保持している場合、 振り分け先の変更で利用者の状態が失われる可能性があります。
6．ロードバランサーだけ監視する
入口が正常でも、バックエンドがすべて異常なら サービスは提供できません。 経路全体を監視する必要があります。
「ロードバランサーを導入した＝サービスが冗長化された」 とは限りません。
DNS、ロードバランサー、バックエンド、 データベース、ネットワーク経路など、 サービス全体の単一障害点を確認することが重要です。
顧客・上司へロードバランサーをどう説明するか
技術に詳しくない相手へ 「L4」「L7」「ターゲットグループ」などから説明すると、 本来の目的が伝わりにくくなります。
「利用者からのアクセスを1台のサーバーだけで処理すると、 アクセス集中時の性能低下や、サーバー故障によるサービス停止のリスクがあります。 そこでロードバランサーを入口に配置し、 複数のサーバーへアクセスを振り分けます。 1台に障害が発生した場合は正常なサーバーへ通信を送ることで、 性能と可用性を高めます。」
技術を業務効果へ変換する
| 技術的な説明 | 顧客へ伝える意味 |
|---|---|
| 複数バックエンドへ負荷分散する | アクセス増加時にも処理能力を確保しやすい |
| ヘルスチェックを行う | 故障したサーバーへ利用者を接続させにくくする |
| 複数障害領域へ配置する | 一つの設備障害でサービス全体が停止するリスクを下げる |
| オートスケーリングと連携する | 利用量の増減に応じて処理能力を調整しやすい |
上級編では、 「何を設定するか」だけでなく「なぜ必要か」まで説明する ことを意識してください。
ロードバランサーで使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Load Balancer | ロードバランサー |
| Load Balancing | 負荷分散 |
| Backend | 振り分け先のバックエンド |
| Target | 通信の転送対象 |
| Listener | 通信を受け付ける設定 |
| Health Check | 正常性確認 |
| Healthy | 正常 |
| Unhealthy | 異常 |
| Session Persistence | セッション維持 |
| TLS Termination | TLS終端 |
| Traffic Distribution | トラフィック分散 |
公式ドキュメントや障害調査で使える表現
The load balancer distributes incoming traffic across multiple backend servers.
ロードバランサーは、受信したトラフィックを複数のバックエンドサーバーへ分散します。
The backend server is failing the health check.
バックエンドサーバーがヘルスチェックに失敗しています。
Traffic is routed only to healthy backend instances.
通信は正常なバックエンドインスタンスへ転送されます。
Please verify the health check protocol, port, and path.
ヘルスチェックのプロトコル、ポート、パスを確認してください。
理解度チェック
用語の暗記ではなく、 ロードバランサーをどのように設計するか考えながら答えてください。
問題1．ロードバランサーの主な役割として最も適切なものはどれですか。
- サーバーのIPアドレスを自動配布する
- 複数のバックエンドへ通信を振り分ける
- ドメイン名をIPアドレスへ変換する
- ルーティングテーブルを自動作成する
解答を見る
ロードバランサーは利用者から受け取った通信を 複数のバックエンドへ振り分けます。
問題2．URLのパスによって 「/shop/はECサーバー群」「/api/はAPIサーバー群」 のように振り分けたい場合、L4とL7のどちらが適していますか。
解答を見る
HTTPのHostやURLパスなど、 アプリケーション層の情報を利用した振り分けでは L7ロードバランサーが利用されます。
問題3．Web Server Bでアプリケーション障害が発生しています。 ロードバランサーからServer Bへ新しいアクセスを送らないために 特に重要な機能は何ですか。
- NAT
- DNS
- ヘルスチェック
- DHCP
解答を見る
ヘルスチェックによってバックエンドの正常性を確認し、 異常と判断した宛先を振り分け対象から外します。
問題4．TCP 443への接続だけをヘルスチェックしているサーバーについて、 「TCP接続が成功しているのでWebアプリケーションも必ず正常である」 と判断してよいでしょうか。
解答を見る
TCPポートが開いていても、 アプリケーション内部で障害が発生している可能性があります。 必要に応じてHTTPの専用ヘルスチェックパスなどを利用します。
問題5．ロードバランサーを導入するときに確認すべき設計項目を 5つ挙げてください。
解答例を見る
- L4・L7のどちらを利用するか
- リスナーのプロトコルとポート
- バックエンドの配置
- ヘルスチェック方式
- セッション維持の要否
- TLS終端方式
- タイムアウト
- セキュリティ制御
- ログ・監視
この中から5つ説明できれば問題ありません。
実践演習：Webサービスのロードバランサーを設計する
あなたはクラウド上で新しいWebサービスを設計する ネットワークエンジニアです。
顧客要件
- インターネットから利用するWebサービスである
- 通信はHTTPSを使用する
- アクセス増加を想定してWebサーバーを複数台構成にしたい
- 1台のWebサーバーが故障してもサービスを継続したい
- /api/へのアクセスはAPI用サーバーへ振り分けたい
- Webサーバーは複数の障害領域へ配置する
- 故障したWebサーバーへ新しいアクセスを送らないこと
課題1．L4とL7を選択する
この要件ではL4とL7のどちらを選択しますか。 理由も書いてください。
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
選択：L7ロードバランサー
/api/というURLパスを確認して APIサーバー群へ振り分ける必要があるため、 HTTPの内容を利用できるL7ロードバランサーが適しています。
課題2．基本構成を考える
次の空欄を埋めてください。
↓ HTTPS
＿＿＿＿＿＿＿＿＿＿＿＿
↓
├─ Web Server A（Zone A）
├─ Web Server B（Zone B）
└─ Web Server C（Zone C）
解答を見る
空欄には 外部向けL7ロードバランサー が入ります。
課題3．ヘルスチェックを設計する
Webサーバーが正常にサービスを提供できるか確認するため、 次の項目を考えてください。
| 項目 | あなたの設計 |
|---|---|
| プロトコル | ＿＿＿＿＿＿＿＿ |
| ポート | ＿＿＿＿＿＿＿＿ |
| 確認パス | ＿＿＿＿＿＿＿＿ |
| 異常時の動作 | ＿＿＿＿＿＿＿＿＿＿＿＿＿＿ |
解答例を見る
- プロトコル：HTTPまたはHTTPS
- ポート：アプリケーションが待ち受けるポート
- 確認パス：/health など
- 異常時：該当サーバーを新規通信の振り分け対象から外す
実際の値はアプリケーション構成によって決定します。
課題4．障害発生時の動きを説明する
Server Bがヘルスチェックに失敗した場合、 どのような動作を期待しますか。
解答例を見る
ロードバランサーがServer Bを異常と判断し、 Server Bへの新しい通信の振り分けを停止します。 その後は正常なServer AやServer Cへ通信を振り分け、 サービスを継続します。 Server Bが再び正常と判断された場合は、 設定された条件に従って振り分け対象へ戻します。
課題5．設計確認表を作る
最後に、実際の設計レビューを想定して整理してください。
| 確認項目 | 設計内容 | 理由 |
|---|---|---|
| LB種別 | ＿＿＿＿＿＿ | ＿＿＿＿＿＿＿＿＿＿ |
| 公開範囲 | ＿＿＿＿＿＿ | ＿＿＿＿＿＿＿＿＿＿ |
| リスナー | ＿＿＿＿＿＿ | ＿＿＿＿＿＿＿＿＿＿ |
| バックエンド | ＿＿＿＿＿＿ | ＿＿＿＿＿＿＿＿＿＿ |
| ヘルスチェック | ＿＿＿＿＿＿ | ＿＿＿＿＿＿＿＿＿＿ |
| TLS | ＿＿＿＿＿＿ | ＿＿＿＿＿＿＿＿＿＿ |
自分の言葉で説明する課題
後輩エンジニアから、 「Webサーバーを3台にするだけではダメなんですか？ なぜロードバランサーが必要なんですか？」 と質問されました。
1分程度で説明してください。
説明例を見る
Webサーバーを3台用意するだけでは、 利用者から来た通信をどのサーバーへ送るのかを決める仕組みがありません。 ロードバランサーを入口に配置すると、 複数のサーバーへ通信を振り分けられます。
また、ヘルスチェックによって故障しているサーバーを検出し、 正常なサーバーだけへ通信を送ることで、 1台のサーバー障害時にもサービスを継続しやすくなります。
そのため、ロードバランサーは 負荷分散だけでなく、サービスの可用性を高めるためにも利用されます。
まとめ
- ロードバランサーは、 利用者から受け取った通信を複数のバックエンドへ振り分ける仕組み
- 負荷分散だけでなく、 サーバー障害時の可用性向上にも重要
- L4は主にIPアドレス・TCP/UDP・ポートなど、 L7はHTTPのHost・URLなどを利用して振り分ける
- ヘルスチェックによって 異常なバックエンドを振り分け対象から除外する
- 外部向けだけでなく、 クラウド内部のサービス間通信にもロードバランサーを利用できる
- アプリケーションによっては セッション維持の要否を検討する
- HTTPSではTLSをどこで終端するかを設計する
- 複数障害領域への配置、 セキュリティ、タイムアウト、ログ、監視も含めて設計する
ロードバランサー設計で重要なのは、 「通信を分散できること」だけではありません。 障害時にも正常なバックエンドへ通信を届け、 サービス全体として継続できる構成にすることです。
上級編では、要件定義から基本設計、BGP、クラウド、 セキュリティ、自動化、設計レビュー・顧客提案までを順番に学びます。
コメント