高可用性(HA)構成の最小コスト実装:2台のVPSでフェイルオーバーを組む

VPS・サーバー選定上級
VPS高可用性Keepalived冗長化中小企業

結論: 1台構成のVPSは、いつか必ず単一障害点(SPOF)として牙を剥きます。最小コストで冗長化する現実的な選択肢は、Keepalived(VRRP)による2台のアクティブ・スタンバイ構成か、ヘルスチェック付きDNSフェイルオーバーのどちらかです。この記事では両者の違いと、Keepalivedの実装で踏みがちな落とし穴、コスト試算を具体的に示します。

本番サーバーが落ちたとき、最初に頭をよぎるのは復旧手順そのものよりも、「今この瞬間、気づかずにアクセスしているユーザーがどれだけいるか」という焦りではないでしょうか。1台構成で運用している限り、この焦りは仕組みの問題として残り続けます。ハードウェア障害、OSアップデート後の起動失敗、想定外の高負荷──理由が何であれ、単一のサーバーはいつか止まります。

かといって、いきなりロードバランサーとマルチAZ構成を組むにはコストも学習コストも高すぎる。この記事は、その間にある現実的な選択肢──2台のVPSで組む最小コストのHA(高可用性)構成──を扱います。

TL;DR

  • HA(高可用性)構成とは、1台が壊れても自動的にもう1台が引き継ぎ、サービスを止めない構成のこと。SPOF(単一障害点)を消すのが目的。
  • 最小コストの選択肢は主に2つ。Keepalived(VRRP)による2台構成(数秒で切り替わるが同一セグメント前提)と、DNSフェイルオーバー(切替はやや遅いがネットワーク構成に自由度がある)。
  • Keepalivedの標準設定は「keepalivedプロセスが生きているか」しか見ていません。実サービスの死活監視にはvrrp_scriptの追加が必須です。
  • VPS/クラウド環境ではマルチキャストが使えないケースがあり、unicast_src_ip/unicast_peerでの代替が必要になることがあります(提供元の仕様は要確認)。
  • 2台構成の追加コストは基本的に「VPSもう1台分の月額」だけです。ダウンタイムの機会損失と比べて判断します。

高可用性(HA)とは何か、なぜ1台構成には限界があるか

高可用性(High Availability、以下HA)とは、構成要素の一部が故障してもサービス全体が止まらないように設計されたシステムのことです。対になる概念がSPOF(Single Point of Failure、単一障害点)で、これは「そこが壊れると全体が止まる箇所」を指します。

1台構成のVPSは、まさにそれ自体がSPOFです。OSレベルの障害、ディスク故障、メンテナンス作業中の人為ミス、DDoSやリソース枯渇による高負荷──原因を問わず、そのサーバーが応答しなくなった瞬間にサービス全体が止まります。

しかも復旧には人の対応が必要です。夜間や休日にアラートで気づき、SSHでログインし、原因を特定し、再起動なりロールバックなりを行う。この間、サービスは止まったままです。HA構成の狙いは、この「人が気づいて対応するまでの時間」を、機械的な自動フェイルオーバーに置き換えることにあります。

とはいえ、いきなり本格的なクラウドのマルチAZ構成やマネージドロードバランサーを導入するのは、中小企業の予算感には合わないことが多いはずです。ここで検討したいのが、VPS2台で組む最小構成です。

最小構成の選択肢: Keepalived(VRRP) vs DNSフェイルオーバー

2台構成でHAを実現する方法は、大きく分けて2系統あります。

  1. Keepalived(VRRP)による仮想IP方式 — 2台のサーバーが1つの仮想IP(VIP)を共有し、片方が死ぬと自動的にもう片方がそのIPを引き継ぐ。
  2. DNSフェイルオーバー — ヘルスチェックの結果に応じて、DNSが指すサーバーのIPアドレスを自動的に切り替える。Cloudflare Load Balancingのように、ヘルスチェックとDNS切替をセットで提供するサービスを使うのが一般的です(料金体系・提供条件は各社公式サイトで要確認)。

比較すると、以下のようになります。

項目Keepalived(VRRP)2台構成DNSフェイルオーバー
切替の仕組みVRRPで仮想IPを引き継ぐ(Gratuitous ARPで通知)ヘルスチェックの結果でDNSレコードを書き換える
切替速度数秒程度(advert_intとヘルスチェック間隔次第)数十秒〜数分(DNS TTL・リゾルバのキャッシュに依存)
ネットワーク前提基本的に同一L2セグメント(同一データセンター内)。VPS/クラウドではマルチキャストが使えずunicast設定が必要になることがあるサーバー同士が別リージョン・別ネットワークでも構成可能
追加コストVPSもう1台分の月額のみサーバー費用に加え、ヘルスチェック付きDNS/ロードバランサーサービスの利用料(要公式確認)
実装の複雑さVRRPと仮想IPの理解、スプリットブレイン対策が必要DNSとヘルスチェックの設定が中心で比較的シンプル
弱点同一セグメント前提なのでリージョン単位の障害には弱いクライアント側のDNSキャッシュがTTLを無視する場合、切替が体感的に遅れることがある

同一データセンター内の2台で完結させたいならKeepalived、リージョンをまたいで冗長化したい・自前でVRRPを管理したくないならDNSフェイルオーバー、という住み分けになります。

Keepalivedを使った基本構成の実装

VRRP(Virtual Router Redundancy Protocol)は、複数のサーバーで1つの仮想IPアドレス(VIP)を共有し、優先度(priority)が最も高いノードだけがそのVIP宛の通信を受け取る、というプロトコルです。Keepalivedは、このVRRPをLinux上で実装するデーモンです。

基本構成は次のようになります(数値・パス名は環境に合わせて調整してください)。

# /etc/keepalived/keepalived.conf (Node A: 通常時はMASTER)

vrrp_script chk_web {
    script "/usr/local/bin/check_web.sh"   # 実サービスの死活確認スクリプト
    interval 2                              # 2秒ごとにチェック
    fall 2                                  # 2回連続失敗でFAULT扱い
    rise 2                                  # 2回連続成功で復帰
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass <2台で共通のパスワード>
    }

    # マルチキャストが使えない環境ではunicastで代替(提供元VPSの仕様は要確認)
    unicast_src_ip 203.0.113.10
    unicast_peer {
        203.0.113.11
    }

    virtual_ipaddress {
        203.0.113.100
    }

    track_script {
        chk_web
    }
}

Node B側はstate BACKUP、priorityを低め(例: 100)にし、unicast_src_ip/unicast_peerを自分と相手のIPに入れ替えるだけで、他の値(virtual_router_id・auth_pass・virtual_ipaddress)は揃えます。

仕組みは次の通りです。

  • 平常時はpriorityが高いNode AがMASTERとなり、VIP(203.0.113.100)を保持する。
  • track_scriptに登録したchk_webが2回連続で失敗すると、Node Aのpriorityが自動的に引き下げられる。
  • Node Bのpriorityの方が相対的に高くなった時点で、Node BがMASTERに昇格し、VIPを引き継ぐ(Gratuitous ARPで周囲に通知)。
  • クライアント側はVIP宛にアクセスし続けるだけでよく、どちらの実サーバーが応答しているかを意識する必要はない。

ここで重要なのは、標準設定のままでは「keepalivedプロセスが生きているか」しか監視していないという点です。Webサーバー(nginx/Apache等)がクラッシュしていても、keepalivedプロセス自体が動いていればVIPはそのまま残り、フェイルオーバーは起きません。実サービスの死活監視は、上記のchk_webのようなvrrp_scriptを自前で用意して初めて機能します。

また、多くのVPS/クラウド環境ではネットワークがマルチキャストに対応しておらず、標準のVRRP(マルチキャスト方式)では通信できないことがあります。この場合は上記のunicast_src_ip/unicast_peerで1対1通信に切り替える必要があります。VIPの付け替え自体をVPS側のネットワーク機能が受け付けるかどうかは提供元によって異なるため、契約前に公式ドキュメントで確認することをおすすめします。

よくある落とし穴

1. スプリットブレイン(両系同時MASTER化)

2台の間のVRRP通信(advertisement)が何らかの理由で届かなくなると、双方が「自分がMASTERだ」と判断し、同じVIPを同時に名乗ってしまうことがあります。これがスプリットブレインです。IPアドレスの競合が起き、どちらのサーバーに通信が届くかが不安定になります。

対策としては、VRRP通信の経路をできるだけ安定させること(専用のプライベートネットワークを使う、unicast_peerの到達性を監視対象に含める)、両ノードが同時にMASTER状態になっていないかを外部から監視・アラートすることが挙げられます。2台構成はコストが最小である代わりに、この状態を仲裁する第三者(クォーラム)を置きにくいという弱点も理解しておく必要があります。

2. ヘルスチェックの設計が甘い

「keepalivedプロセスの生死」ではなく「実際にサービスがリクエストに正しく応答しているか」を確認するスクリプトをvrrp_scriptに登録することが前提です。単にプロセス名の存在チェックだけでなく、実際にlocalhostのヘルスチェックエンドポイントへHTTPリクエストを送り、期待するレスポンスが返るかまで確認する設計が望ましいところです。

3. フェイルオーバーを試したことがない

設定を書いただけで、実際に片方を止めてVIPが引き継がれるかを検証していないケースは珍しくありません。想定通りに動くかどうかは、設定を書いた時点では「仮説」でしかなく、意図的に片系を落とすテストを一度は行っておく必要があります。

コスト試算: VPS2台分の増加コスト vs ダウンタイムの損失

Keepalived方式の追加コストは、基本的に同等スペックのVPSをもう1台契約する月額分だけです。国内VPSの小〜中規模プラン(2コア/4GB前後)は月額千円台〜数千円台の価格帯で提供されていることが多いですが、料金体系は提供元によって異なるため、契約前に各社公式サイトで確認してください。

この追加コストを、ダウンタイムが発生した場合の機会損失と比較してみます。ダウンタイムコストの大まかな考え方は次の式です。

  • 時間あたりの売上・機会損失 × 停止時間
  • 対応にあたる従業員の人件費 × 停止時間
  • 顧客からの信用低下・問い合わせ対応コスト(定量化しにくいが実在する)

仮に追加コストが月額数千円だとしても、年間では数万円程度に収まります。一方で、ECサイトや予約システムなど収益に直結するシステムが数時間止まった場合の機会損失は、業種・規模によってはこれを容易に上回ります。逆に、社内向けの参照系システムなど、止まっても業務に致命的な影響がないものであれば、無理にHA構成にせず、DNSフェイルオーバーや手動復旧の運用手順(ランブック)で十分というケースもあります。すべてのシステムを同じ基準で冗長化する必要はありません。

まとめ

1台構成のVPSは、いつかは必ず単一障害点として顕在化します。最小コストでこれを解消する現実的な選択肢は、Keepalived(VRRP)による2台構成か、ヘルスチェック付きDNSフェイルオーバーです。前者は数秒単位の高速な切替が可能な代わりに同一セグメント前提でスプリットブレイン対策が必要になり、後者はネットワーク構成の自由度が高い代わりに切替に時間がかかります。

Keepalivedを選ぶ場合は、標準設定が「プロセスの生死」しか見ていないことを理解した上で、実サービスを監視するvrrp_scriptを必ず追加すること、VPS/クラウド環境ではunicast設定が必要になり得ることを事前に提供元へ確認すること、そして構成を組んだら一度は実際にフェイルオーバーを試しておくことが欠かせません。

HA構成の設計・実装支援を行っています

Keepalivedによる2台構成の設計から、DNSフェイルオーバーとの比較検討、既存構成のスプリットブレインリスクの診断まで、InfraDBでは個別相談を受け付けています。

HA構成の相談をする

関連記事

関連記事

VPS・サーバー選定PostgreSQLパフォーマンスチューニング: 中小企業DBの遅延を解消する手順VPS・サーバー選定マネージドVPSとアンマネージドVPS：社内に専任エンジニアがいない場合の選び方VPS・サーバー選定ConoHa VPS vs さくらのVPS 2026年版：法人ユースで選ぶならどっちか
記事一覧に戻る