LinuCレベル4 システムアーキテクト 可用性の設計 問28
可用性の設計／データレプリケーションと災害対策PostgreSQLを2台（プライマリ＋スタンバイ）で冗長化している。プライマリ障害発生から5分以内の自動復旧（RTO ≤ 5分）が必要な業務における切り替え方式の設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- A手動切り替えとし、担当者が障害を確認してからスタンバイを昇格させる。誤検知による切り替えが起きない点を優先してRTO要件を達成する
- B手動切り替えとし、監視ツールのアラートを受けたオペレーターがスタンバイを昇格させる。人手の判断が入るため確実だが、認知・対応時間でRTO 5分の達成は困難なことが多い
- CPacemaker/Corosyncによる自動フェイルオーバーを導入し、ハートビートで障害を検知してスタンバイへの昇格とVIPの移動を自動的に行い、人手の介在を省いてRTO要件を達成する
- D手動切り替えと自動フェイルオーバーの両方を並行して有効にし、どちらか早い方が切り替えを実行する構成にする
正解：C
解説
RTO 5分以内という厳しい要件に対しては、障害検知から昇格・接続先切り替えまでを人手なしに完結させる自動フェイルオーバーを基本方針とするのが最も適切です。手動切り替えは人の認知・判断・操作の時間が加わるため、5分以内の復旧は困難なことが多いです。Pacemaker/Corosync はハートビートで障害を検知し、リソースエージェントを通じて PostgreSQL のスタンバイ昇格と VIP の移動を自動化できます。ただし自動化を導入しただけで 5分が保証されるわけではなく、実際の RTO は『検知→フェンシング（旧プライマリの隔離）→昇格→接続先切り替え→アプリの再接続』の各段階の所要時間の合計で決まります。各段階に時間上限を設け、障害試験で実測して 5分以内に収まることを検証する必要があります。また、Corosync のノード間通信の監視と DB サービス自体の健全性監視は別物である点にも注意します。手動と自動を無秩序に併用すると二重昇格や競合のリスクがありますが、クラスタ管理下での計画的な手動切り替えまで否定するものではありません。
選択肢ごとの解説
- A誤り。5分以内のRTO要件のある業務において、担当者の確認・対応を経る手動切り替えでは時間的に要件を満たせない可能性が高いです。
- B誤り。オペレーターによる手動切り替えは誤検知を防げる利点がありますが、認知・対応の時間が積み重なりRTO 5分の達成が困難です。
- C正しい。RTO 5分以内の要件には、障害検知から昇格・切り替えまでを自動化する Pacemaker/Corosync による自動フェイルオーバーを基本方針とするのが最も適切です。ただし達成には、検知・フェンシング・昇格・再接続の各段階の時間を抑え、障害試験で実測検証することが前提になります。
- D誤り。手動と自動の両方を有効にすると、どちらが先に動作するかによって制御が競合したり二重昇格が起きたりするリスクがあり、適切な設計ではありません。