深夜にWebサーバーが「突然死」する恐怖
よくあるシナリオ：深夜2時、システムダウンの通知でスマートフォンが鳴り止みません。メモリの不具合やNginxの予期せぬクラッシュにより、サーバーが突然停止してしまいます。単一障害点（Single Point of Failure）を持つサーバー構成では、すべてのトラフィックが遮断され、顧客は離れ、眠い目をこすりながら手動復旧に追われることになります。
統計によると、ダウンタイムは1分ごとに数百から数千ドルの損失を企業にもたらすと言われています。CentOS Stream 9にシステムを移行する際、必須となるのが自動フェイルオーバー（failover）の仕組みです。1台のサーバーがダウンしても、もう1台が2秒以内に即座に引き継ぎ、ユーザーに気づかれることなくサービスを継続させる必要があります。
なぜWebサーバーは脆弱なのか？
問題は、ドメイン名を単一の静的IPアドレスに紐付けていることにあります。このIPアドレスが応答しなくなると、すべてが停止します。
- パケットのドロップ：OSが応答せず、ユーザーのブラウザにタイムアウトエラーが表示される。
- サービスのハングアップ：サーバー自体は生きていても（pingは通る）、NginxやApacheがクラッシュしており、リクエストが拒否される。
- DNSの反映遅延：DNS側で手動でIPを変更しても、反映（TTL）までに5分から数時間かかることがあり、現代のシステムには遅すぎます。
Keepalived：システム管理者の救世主
この課題を解決するために、軽量で安定性の高いKeepalivedが有力な選択肢となります。これはVRRP（Virtual Router Redundancy Protocol）というプロトコルに基づいています。物理IPの代わりに、サーバー群に仮想IP（VIP）を割り当てます。メインノードに障害が発生すると、このVIPは自動的に稼働中のノードへ「移動」します。
CentOS Stream 9において、KeepalivedはLinuxカーネルと非常によく統合されています。IPの管理だけでなく、継続的なヘルスチェックも行います。Webサービスにエラーが発生すると、Keepalivedがそれを検知し、予備のサーバーに制御権を譲ります。
CentOS Stream 9での実践的なデプロイ
今回は、2つのノードと1つの共有仮想IPを使用する構成を構築します。
- Node Master: 192.168.1.10
- Node Backup: 192.168.1.11
- Virtual IP (VIP):
