【製品解説】高可用性Postgres基盤の要：EDB Failover Manager（EFM）5.4 徹底解説
企業のコア業務を支えるデータベースシステムにおいて、ダウンタイムの削減とデータの保護は最優先事項です。PostgreSQLやEDB Postgres Advanced Server（EPAS）をミッションクリティカルな環境で運用する際、万が一のノード障害時にいかに素早く、かつ安全にリカバリ（フェイルオーバー）を行うかがビジネスの継続性を左右します。
本記事では、EDBが提供する高可用性（HA）ソリューションの中核を担うソフトウェア「EDB Failover Manager（EFM）」の製品概要、主要機能、導入メリット、そして最新バージョン 5.4 の新機能・変更点について、詳しく解説します。
1. EFM（EDB Failover Manager）とは何か
高可用性を実現する障害監視・自動昇格ソリューション
EDB Failover Manager（EFM）は、PostgreSQLおよび EDB Postgres Advanced Server（EPAS）のプライマリ／スタンバイ構成（レプリケーションクラスタ）において、高可用性（High Availability）を実現するための障害監視・フェイルオーバー自動化管理ソフトウェアです。
通常、PostgreSQLのストリーミングレプリケーション機能を使用することでデータの冗長化は可能ですが、プライマリデータベースに障害が発生した場合、どのスタンバイを新しいプライマリに昇格させるか、あるいはアプリケーションの接続先をどう切り替えるかといった判断と実行は手動で行うか、外部ツールに依存する必要があります。
EFMは、クラスタ内の各データベースノードに軽量なエージェント（プロセスマネージャー）を配置し、データベースの健全性を24時間体制で監視します。プライマリノードの停止やネットワーク断絶などの致命的な障害を検知すると、事前定義されたポリシーに従って人間が介在することなく数秒〜数十秒でスタンバイデータベースを新しいプライマリへと自動昇格させます。
EFMのアーキテクチャと基本コンポーネント
EFMクラスタは、主に以下のコンポーネントで構成されます。
- EFM Agent（エージェント）
各データベースサーバー（プライマリおよびスタンバイ）上でバックグラウンドプロセスとして動作します。自身のホスト上のPostgreSQL/EPASプロセスの状態をローカルで監視すると同時に、他のノードのエージェントと後述するJGroupsプロトコルを介して相互通信を行います。 - Witness Node（ウィットネスノード：目撃者ノード）
データベースインスタンスを持たず、EFMエージェントのみが動作する専用ノードです。クラスタノード数が偶数の場合や、2ノード（プライマリ1・スタンバイ1）構成において、ネットワーク分断（スプリットブレイン）発生時に「過半数（クォーラム）」の合意形成を正しく行うための「第三者視点」として機能します。 - JGroupsベースのメッシュネットワーク
EFMエージェント間は、オープンソースのグループ通信ライブラリである「JGroups」を使用して通信を行い、ノード同士の状態確認や障害検知を行います。SSL/TLSによる通信の暗号化も設定可能です。これにより、中央集権型の監視サーバーを必要とせず、分散型のアーキテクチャによって安定したクラスタ管理を実現します。
2. EFMの主な機能
EFMは、単なる「障害検知・昇格ツール」にとどまらず、エンタープライズの運用現場で求められる多様な高可用性制御・運用自動化機能を備えています。
① 高度なヘルスメインテナンスと障害検知
EFMエージェントは、以下の複数レイヤーでデータベースの稼働状態を定期的にチェック（ヘルスチェック）します。
- プロセス監視: PostgreSQL/EPASの親プロセスおよび関連ワーカーが動作しているかを監視。
- クエリ監視: 実際にデータベースへの接続テストクエリを発行し、応答性やトランザクションの書き込み可能性を確認。
- ディスク容量監視: WAL領域やデータディレクトリ（PGDATA）のストレージ空き容量を監視し、枯渇による突発停止を防止。
② スプリットブレイン（Split-Brain）防止メカニズム
マルチノード環境で最も恐ろしい現象が、ネットワーク分断によって旧プライマリと新プライマリが同時に書き込みを受け付けてしまう「スプリットブレイン」によるデータの破損・不整合です。EFMは以下の多重防御によりこれを確実に防ぎます。
- クォーラム（過半数）判定: クラスタの過半数のエージェントと通信が取れないノードは、自身を孤立状態と判断し昇格処理を行いません。
- Fencing（フェンシング）スクリプトの実行: 昇格処理の直前に、旧プライマリの電源を強制シャットダウン（IPMI/iLO経由など）したり、ネットワークスイッチで隔離するスクリプトを実行可能です。
- STONITH（Shoot The Other Node In The Head）的アプローチ: 旧プライマリが生存している可能性がある場合、物理的に隔離されるまで新プライマリへの昇格を安全にブロックします。
③ Virtual IP（VIP）管理および通知機能
フェイルオーバーが発生した際、アプリケーション側の接続設定を変更せずに即座に新しいプライマリへ接続を誘導するため、EFMは仮想IP（Virtual IP: VIP）の自動割り当て・付け替え（VIPフェイルオーバー）をサポートしています。 また、Pingによるネットワーク疎通確認や、ロードバランサー（pgBouncerやHAProxy等）との連携用フックスクリプト機能も搭載されています。
④ 運用を止めない手動切り替え（Switchover）機能
計画メンテナンス（OSパッチ適用やデータベースのマイナーバージョンアップ等）の際、efm promote コマンドにスイッチオーバーのオプション（-switchover）を指定して実行することで、サービスダウンタイムをほぼゼロに抑えた状態で安全にプライマリの役割を別のスタンバイノードへ委譲（スイッチオーバー）できます。
⑤ 柔軟な通知・アラートシステム
クラスタの状態変化（ノードの離脱、警告レベルの遅延、フェイルオーバーの完了など）が発生すると、設定されたメールアドレスへの即時通知（SMTP）や、SNMPトラップの発行、あるいは指定したカスタムアラートスクリプトを実行してSyslogや各種運用監視ツール（Datadog、Zabbix、PagerDuty等）へイベントを連携できます。
3. EFMのメリット
高可用性構成を組むアプローチはいくつか存在しますが、EFMを選択することで企業は以下のような技術的・運用上のメリットを享受できます。
メリット1：軽量かつ中央単一障害点（SPOF）のないアーキテクチャ
多くのクラスタ管理システムは「監視専用の中央マネージャーサーバー」を必要とし、そのマネージャー自体の障害対策が新たな課題となります。EFMは各DBノード同士がピアツーピア（P2P）で相互監視を行う分散アーキテクチャを採用しているため、単一障害点（SPOF）が存在しません。構成も非常にシンプルで、既存のインフラに与えるオーバーヘッドは最小限に抑えられます。
メリット2：PostgreSQL/EPASネイティブな親和性
EFMはEDB社によって開発・保守されているため、PostgreSQLの内部仕様（ストリーミングレプリケーション、pg_controlファイルの状態、WALログの同期状況、pg_rewindなど）を完全に理解した上で動作します。そのため、外部の汎用クラスタソフトウェア（Pacemaker/Corosync等）に比べて設定が極めてシンプルで、PostgreSQLのバージョンアップ時にも互換性のトラブルが発生しにくい特徴があります。
メリット3：データ消失を極限まで抑える昇格ロジック
フェイルオーバー時、EFMは単に「生き残っているスタンバイ」を無条件に昇格させるわけではありません。クラスタ内に複数のスタンバイが存在する場合、「最もプライマリからのレプリケーション遅延（WALの適用遅延）が少ないスタンバイ」を自動的に選択して昇格させます。これにより、RPO（目標復旧時点）を最小化し、データ消失のリスクを極限まで削減します。
メリット4：エンタープライズレベルのセキュリティ対応
EFMエージェント間の通信は、TLS/SSLによって完全に暗号化可能です。また、エージェントの実行権限分離や、データベース接続時のパスワード非保持（SSL証明書認証やSecure Passwordファイルの使用）に対応しており、金融機関や医療機関などの厳格なセキュリティ・コンプライアンス基準に適合します。
4. バージョン 5.4 の新機能・変更点
最新の EFM 5.4（2026年8月24日リリース）では、パスワード管理やレプリケーション監視の強化、周辺ライブラリの更新、そして複数のエッジケースに対する安定性向上が図られています。
① パスワード管理の強化
EFM 5.4では、データベース接続に使用するパスワードの管理方法が強化されました。
- 外部スクリプトによるパスワード取得: 設定ファイルにパスワードをそのまま平文で記述する代わりに、外部スクリプトを介してパスワードを動的に取得できるようになりました。環境変数や外部シークレットマネージャーと連携した、より安全な運用が可能です。
② レプリケーション監視とロードバランサー連携の強化
運用管理者がクラスタの状態をより正確に把握し、周辺システムと連携しやすくするための機能が追加されました。
- ストリーミングレプリケーション情報の取得: レプリケーションの状況を取得するための
efmコマンドが新たに追加され、遅延状況などをより簡単に確認できるようになりました。 - ロードバランサー向けHTTPエンドポイント: ロードバランサーがクラスタ内のプライマリノードを検出するための、専用のHTTPエンドポイントが新設されました。
③ 主要ライブラリのアップグレード
EFM 5.4では、以下の内部ライブラリがそれぞれ最新版に更新されました。
- Log4j 2.25.5への更新
- Jakarta Mail 2.0.2への更新
- PostgreSQL JDBCドライバ 42.7.12への更新
これらの更新により、既知の脆弱性への対応や周辺コンポーネントとの互換性向上が図られています。
④ 運用面の細かな改善
日常運用やサービス管理の観点から、複数の改善が加えられました。
- 起動・停止処理の確実性向上: エージェント停止時にロックファイルの削除を確認してから完了を報告するようになり、状態管理がより確実になりました。
- systemd連携の改善:
efm stop-clusterコマンドで停止したエージェントについて、systemdが誤って失敗状態と報告しないよう修正されました。 - 実行ディレクトリの変更: 従来の
/var/run・/var/lockのシンボリックリンクディレクトリではなく、/run・/run/lockディレクトリを使用するようになりました。
⑤ 複数のエッジケースに関するバグ修正
クラスタの安定性を高めるため、以下のようなエッジケースのバグが修正されました。
- 偶数ノード構成において、段階的なネットワーク分断時に誤ったプライマリ昇格が発生することがあった不具合
minimum.standbysプロパティ使用時、スタンバイ数が不足している場合に手動スイッチオーバーがブロックされてしまう不具合priority.standbys使用時、一部スタンバイのpromotableがfalseの場合にスタンバイの優先順位が失われることがあった不具合- 複数のエージェントが同時に起動した際、単一クラスタへの参加に失敗することがあった不具合
efm reset-members実行後の再参加時、一部のエージェントが不完全なメンバーリストを使用してしまうことがあった不具合
まとめ：高可用性Postgres運用のベストプラクティスとして
データベースの移行やモダン化（クラウド移行、マルチリージョン展開など）が進む中でも、「いかにシステムを止めないか」という高可用性の課題は普遍です。
EDB Failover Manager（EFM）5.4 は、オープンソースの柔軟性とエンタープライズの要求に応える堅牢性を兼ね備えた、もっとも信頼できるPostgres高可用性ソリューションのひとつです。今回のバージョンでは、パスワード管理やレプリケーション監視の強化、周辺ライブラリの更新、そして複数のエッジケースに対する安定性向上といった、地道な改善が積み重ねられており、新規導入はもちろん、既存バージョンからのアップグレードにおいても運用面でのメリットをもたらします。
データベースの無停止運用や自動リカバリ環境の構築をご検討の際は、ぜひEFM 5.4の導入をご検討ください。
