こんにちは、Webアプリ開発を3年行っています。
また、オンプレのサーバー管理も行っています。
本記事では「サーバーロードバランス」と「フェイルオーバークラスタ」の代表的な構成を、メリット／デメリットとあわせてまとめます。試験対策のメモや現場ノウハウを整理したものなので、インフラ初学者～中級者の復習に使ってください
1. なぜロードバランシングが必要か
アクセス集中への対策
1 台構成では CPU・メモリ・I/O がボトルネックになりがち
可用性（サービス停止リスク）の低減
障害発生時に “もう 1 台” へ逃がす仕組みがあると MTTR¹ を縮小できる
拡張性・柔軟性
キャパシティ計画が立てやすく、段階的なスケールアウトが可能
¹ Mean Time To Recovery：平均復旧時間
- 代表的なロードバランス方式
| 方式 | 概要 | 主要メリット | 主なデメリット |
|---|---|---|---|
| DNS ラウンドロビン | 1 つの FQDN に複数の A/AAAA レコードを設定し、DNS で応答 IP をランダム返却 | ・低コスト（DNS のみ） ・導入が簡単 |
・死活監視不可 → 障害サーバーへもトラフィック ・負荷ベースの振り分け不可 ・キャッシュ TTL により切替にラグ |
| ハード／ソフトロードバランサ | L4/L7 スイッチや LVS・nginx などがフロントに立ち、バックエンドを監視して振り分け | ・充実したヘルスチェック ・多彩なアルゴリズム（RR・LeastConn 等） ・SSL 終端や HTTP/2, gRPC などの付加機能 |
・機器／ソフトの導入・設定コスト ・LB 自体が SPOF ⇒ 冗長化必須 |
| Virtual IP (VIP) 方式 | 各ノードが同じ仮想 IP を共有し、自律的に ARP を制御（Keepalived など） | ・専用機器不要でコスパ◎ ・双方向監視で障害ノードを自動切離し |
・全ノードに監視デーモン導入が必要 ・心拍／負荷情報交換でネットワーク負荷増 |
- 導入が簡単 - 死活監視不可 → 障害サーバーへもトラフィック
- 負荷ベースの振り分け不可
- キャッシュの TTL で切替にラグ
ハード／ソフトロードバランサ L4/L7 スイッチや LVS・nginx などがフロントに立ち、バックエンドを監視して振り分け - 充実したヘルスチェック - 多彩なアルゴリズム（RR・LeastConn 等）
- SSL 終端や HTTP/2, gRPC 等の付加機能 - 機器／ソフトの導入・設定コスト
- LB 自体が SPOF² → 冗長化必須
Virtual IP (VIP) 方式 各ノードが同じ仮想 IP を共有し、自律的に ARP を制御（Keepalived 等） - 専用機器不要でコスパ◎ - 双方向監視で障害ノードを自動切離し - すべてのノードに監視デーモン導入が必要
- 心拍／負荷情報の交換でネットワーク負荷増
² Single Point of Failure：単一障害点
2.1 DNS ラウンドロビン実装例
txt
example.com. 300 IN A 203.0.113.10
example.com. 300 IN A 203.0.113.11
TTL を短めにしておくと切替ラグを多少緩和できますが、完全なフェイルオーバはできません。
2.2 Keepalived（VIP 方式）のイメージ
conf
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
virtual_ipaddress {
192.0.2.100/24
}
track_script {
chk_nginx
}
}
track_script でアプリのヘルスチェックを行い、失敗時に優先度を下げてフェイルオーバします。
3. フェイルオーバークラスタ（高可用性）
ロードバランサは リクエスト分散、クラスタは サービス継続 が目的という違いがあります。ここでは 2 ノード構成を想定します。
3.1 ディスク配置モデル
以下を Qiita の Markdown テーブル形式 に変換しました。前回と同じスタイルで改行に <br> を使用しています。
| モデル | データ保持 | 利用例 | 注意点 |
|---|---|---|---|
| 共有ディスク方式 | 両ノードが同一 SAN/LUN をマウント | ・DB クラスタ ・ファイルサーバ |
・SAN コスト ・ファイバ配線 |
| ディスクミラー方式 | 各ノードがローカルディスクを相互同期 | ・Hyper-V Replica ・DRBD |
・ネットワーク帯域を圧迫 |
3.2 ノード構成
Active/Passive
通常は 1 台のみ稼働 → 障害時に待機系へ フェイルオーバ
Active/Active
双方が現役稼働 → 片系障害時は残りへトラフィック集中
どちらもクラスタリングソフト（Pacemaker, WSFC など）が心拍監視を行います。
4. 仮想化環境でのネットワークモード（おまけ）
| モード | 特徴 | 典型ユース |
|---|---|---|
| ブリッジ | 仮想 NIC と物理 NIC が同一セグメント | 本番 Web＋DB |
| NAT | ホスト OS がアドレス変換 | 社内検証環境 |
| ホストオンリー | ホストとゲストのみで閉じたネット | ローカル実験 |
5. まとめ
スモールスタートなら DNS ラウンドロビン → 障害検知は別途考慮
可用性重視なら VIP or LB でヘルスチェック付き分散
性能＋機能拡張が必要なら専用ロードバランサを冗長構成で導入
DB などステートフル領域は フェイルオーバークラスタで瞬断に備える
自分の案件や予算、障害許容度に応じて組み合わせることで、堅牢かつスケーラブルなインフラを実現できます。