Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
AWS RDS自動フェイルオーバーは、プライマリデータベースインスタンスが利用不可になった際に起動する標準搭載の高可用性機能です。AWSは手動操作なしで、別のアベイラビリティゾーン（AZ）に配置されたスタンバイレプリカを自動的にプライマリに昇格させます。
自動フェイルオーバーとマルチAZの関係性
自動フェイルオーバーはマルチAZを有効化した場合のみ動作します。マルチAZ構成では、AWSは別のAZに同期型スタンバイレプリカを用意し、常にプライマリとデータを同期させます。
AWS RDS自動フェイルオーバーが発生する要因
RDSは軽微な障害では切り替えを実施しません。AWSがプライマリインスタンスの重大な異常を検知した場合のみフェイルオーバーが実行されます。
RDSのフェイルオーバーは単なるバックアップからの復元ではなく、2つの独立した基盤環境間で連携して切り替えを行う仕組みで、アプリケーションに対し高速かつ透過的に動作するよう設計されています。
マルチAZを有効にすると、AWSは2つの異なるアベイラビリティゾーンにプライマリDBインスタンスとスタンバイインスタンスを起動します。データ損失ゼロを実現する鍵は同期レプリケーションです。
プライマリへの全ての書き込み処理は同時にスタンバイにも反映されます。トランザクションは両方のインスタンスに記録されて初めて確定されるため、スタンバイは常にプライマリと完全に一致した最新のミラー状態となります。
切り替え全体は通常60～120秒で完了します。実行される処理は以下の通りです。
マルチAZスタンバイとリードレプリカはどちらもデータレプリケーションを利用しますが、解決する課題が異なります。2つを混同するとコストのかかる障害につながるため注意が必要です。
詳細に入る前に簡単な比較表を記載します。
| 機能 | マルチAZスタンバイ | リードレプリカ |
|---|---|---|
| 主な用途 | 高可用性・フェイルオーバー対応 | 読み取り負荷分散・パフォーマンス向上 |
| レプリケーション方式 | 同期型（データ損失ゼロ） | 非同期型（遅延が発生する可能性あり） |
| クエリ実行可否 | 不可 | 可（読み取り専用） |
| フェイルオーバー | DNS更新による自動切り替え | 手動での昇格（標準RDSの場合） |
| アベイラビリティゾーン | 必ず別のAZ | 同一AZ、別AZ、または別リージョン |
スタンバイインスタンスはパッシブノードであり、直接クエリを実行したり接続したりすることはできません。役割はプライマリとデータを同期させ、異常発生時に自動的に引き継ぐことのみです。可用性を最優先する場合、マルチAZが適切な選択肢となります。
リードレプリカはアクティブノードで、読み取り専用のトラフィックを処理しプライマリの負荷を軽減します。スケーリングに有効ですが非同期レプリケーションのため、障害発生時に最新のトランザクションがレプリカに反映されていないリスクがわずかに存在します。
MySQL、PostgreSQL、Oracleといった標準RDSエンジンでは、リードレプリカの自動昇格機能は存在しません。プライマリに障害が発生した場合、昇格とDNS変更を手動で実施する必要があり、マルチAZ構成と比較して停止時間が長くなります。
AWS RDSの自動フェイルオーバーはAWS環境内では優れた動作をします。しかし多くの企業システムはクラウドのみで構成されておらず、オンプレミスサーバー、VMware基盤、パブリッククラウドが混在する場合、単一クラウドのフェイルオーバーソリューションでは保護に漏れが生じます。
この課題に対応するのがi2Availabilityです。複雑な異種混在環境向けに開発されたアプリケーションレベルの高可用性ソリューションで、クラウド標準ツールを超えた災害復旧機能を提供します。
AWS RDSは自身のエコシステム内のフェイルオーバーを効率的に処理します。しかし複数環境にデータベースを運用し、コンプライアンスや復旧要件が厳格な企業にとって、クラウド標準ツールのみでは実現できない制御性と柔軟性をi2Availabilityが補完します。
マルチAZを有効にするだけでは不十分です。アプリケーションと基盤の設定が適切でない場合、データベースが復旧してもアプリが停止したままとなる可能性があります。
RDSフェイルオーバー発生時、プライマリインスタンスへの既存接続はすべて切断されます。アプリ側で「接続が相手側からリセットされました」「通信リンク障害」といったエラーが発生します。
実装すべき2つの施策は以下の通りです。
PgBouncerやHikariCPといったコネクションプールツールはパフォーマンスを改善しますが、設定を誤るとフェイルオーバー時に不具合を引き起こします。
ユーザーからの問い合わせで障害発生を把握するのではなく、事前アラートを設定しましょう。
実際の障害発生時に設定の不備に気づくのは手遅れです。定期的にフェイルオーバー訓練を実施しましょう。
Q1：RDSに自動フェイルオーバー機能はありますか？
はい、マルチAZを有効化した場合に限り利用可能です。AWSがプライマリインスタンスを監視し、障害を検知すると別のアベイラビリティゾーンのスタンバイレプリカに自動的に切り替えます。
Q2：手動フェイルオーバーと自動フェイルオーバーの違いは何ですか？
自動フェイルオーバーはAWSがハードウェアまたはネットワーク障害を検知した際に起動され、人手による操作は不要です。手動フェイルオーバーはユーザーがAWSコンソールの「フェイルオーバー付き再起動」から実行するもので、試験や計画メンテナンス用途に使用されます。
Q3：RDSフェイルオーバーが発生する要因は？
代表的な要因はアベイラビリティゾーンの停止、ネットワーク接続断、ホストハードウェア故障です。OSパッチ適用やインスタンススケーリングといった計画メンテナンス期間中にも計画的な切り替えが実施される場合があり、こちらは障害によるものではない点に注意してください。
Q4：RDSに自動バックアップ機能はありますか？
はい。Amazon RDSは毎日自動的にスナップショットを作成し、トランザクションログを取得します。これらにより任意の時点までデータベースを復元するポイントインタイムリカバリ（PITR）が利用可能で、設定した保存期間内の任意の秒に復旧できます。
Q5：マルチAZ構成のAmazon RDSに自動フェイルオーバー機能は備わっていますか？
はい。マルチAZを有効化すると、RDSは手動操作なしで通常60～120秒以内にスタンバイを昇格させDNSエンドポイントを更新します。
AWS RDS自動フェイルオーバーの仕組みを理解することで、軽微な一時停止と大規模なシステム障害を分けることができます。マルチAZによる同期レプリケーションと自動DNS切り替えは対策の半分に過ぎません。
真に耐障害性の高いシステムを構築するためには、アプリ側にリトライロジックを実装し、DNS TTLを低く設定し、定期的にフェイルオーバー試験を実施する必要があります。基盤の切り替えはAWSが処理し、ユーザーが復旧するまでの速度は自身のアーキテクチャに依存します。
ハイブリッドまたは複数プラットフォームにデータベースを運用する企業の場合、AWS標準のフェイルオーバー機能だけでは対応しきれないケースが存在します。i2Availabilityといったツールを活用することで、クラウドを超えた保護範囲を拡大し、RDSのみではカバーできないオンプレミスサーバー、仮想化基盤、データセンター間の災害復旧に対応できます。
