前回の記事では、Active-Active 構成のアーキテクチャ全体像を解説しました。
本記事では、「東京リージョン全損」を想定したフェイルオーバー試験を実際に行い、各レイヤー（App / DB / Storage）がどのように切り替わるかを、実際の手順と挙動の記録とともにレポートします。

1. 試験シナリオと疑似障害の発生

試験の概要

本試験では、東京リージョンの完全停止（リージョン障害）を想定し、システムを以下の3段階のレイヤーに分けて段階的に切り替えを行いました。

試験の前提として、対象システムには下記のリソースが正常稼働していることを確認しています。

• 東京・大阪の両リージョンで WordPress が正常にサービス提供中
• Aurora Global Database で東京が Writer（Primary）、大阪が Reader（Secondary）として同期中
• EFS Replication が東京 → 大阪方向で有効な状態

疑似障害の発生（試験操作）

「障害」の模擬として、東京リージョンの Auto Scaling Group（ASG）のキャパシティを 0 に設定し、東京側のすべての EC2 インスタンスを意図的に停止させます。

この操作が、本試験における「障害発生」のトリガーです。以降に述べるフェイルオーバー処理は、この操作を起点として発生します。

2. App層の自動フェイルオーバー（システムの挙動）

Route 53 ヘルスチェックによる自動検知と切り替え

EC2 インスタンスが全停止すると、ALB がバックエンドなしでエラーを返し始めます。これを Route 53 のヘルスチェックが検知します。

Route 53 では、東京・大阪それぞれの ALB エンドポイントに対してヘルスチェックを関連付けており、東京側のヘルスチェックが「Failure」に遷移すると、レイテンシーベースのルーティングから東京の ALB が自動的に除外されます。

その結果、それまで東京に誘導されていたユーザーのトラフィックは、大阪リージョンの ALB へ自動的に切り替わります。

実際の障害時における「書き込み」の縮退

本試験の操作（東京の EC2 停止のみ）では、東京の Aurora クラスターはまだ稼働しているため、Write Forwarding を経由して大阪からの書き込みを継続することが実のところ可能です。
しかし、本件が想定している「東京リージョン全損」のような大規模障害のケースでは、東京のデータベース自体もダウンします。

そのような状況下では、大阪の EC2 が稼働していても、転送先の Writer が不在となるため、サイトの閲覧（読み取り）は可能ですが、投稿や更新などの書き込みはエラーになります。

つまり、DNSの自動切り替えによってシステムの「閲覧」機能は迅速に自律復旧しますが、システム全体としては「縮退運転」の状態となります。完全なサービス復旧（書き込みの再開）のためには、次のフェーズである「DB層の昇格」が必要です。

Active-Active 構成の強みがここに現れます。 Pilot Light 構成であれば、EC2 インスタンスの起動とスケールアウトが完了するまでサイト自体が閲覧できません。Active-Active 構成では、大阪側のサーバーが常時稼働しているため、DNS の切り替わりが完了した時点から閲覧は即時に復旧します。

3. DB層の昇格処理（手動フェイルオーバー操作）

フェイルオーバーの前に: 現況確認

DB 層の昇格操作は、EFS の昇格と並んで「不可逆な操作」の筆頭です。いったん Global Database のフェイルオーバーを実行すると、Aurora のレプリケーショントポロジーが変更され、元に戻すには改めてフェイルオーバーを実行する必要があります。

試験環境であれば「とにかく昇格させる」だけで完了しますが、本番環境での実施は、いくつかの現況確認をセットにして行うことが重要です。

確認すべき主要なポイントは以下の通りです。

• 東京リージョンの状態：
  ヘルスチェックの失敗が一時的な瞬断なのか、本格的なリージョン障害なのかを判断する。過去のアラート履歴や AWS の Service Health Dashboard も参照する。
• レプリケーション遅延（RPO の把握）：
  フェイルオーバー実行時点でのレプリケーション遅延量を把握しておく。Aurora のモニタリングメトリクス (AuroraGlobalDBReplicationLag) を確認し、同期ラグが大きい場合は、昇格後にどの程度の最新データが失われるかを事前に評価する。
• スプリットブレインの回避：
  東京の Writer がまだ部分的に稼働している可能性がある場合は、両リージョンが独立して Writer として動作する「スプリットブレイン状態」を防ぐため、東京側のクラスターへの書き込みアクセスを遮断してから昇格を行う。

フェイルオーバーは技術的な「作業」であると同時に、ビジネス上の「決断」でもあります。上記の確認を経た上で、昇格に踏み切るか否かを判断することが重要です。

Aurora Global Database のフェイルオーバー実行

現況確認が完了したら、Aurora Global Database のフェイルオーバーを実行し、大阪リージョンのクラスターを Primary（Writer）へ昇格させます。

マネジメントコンソールからも実行可能ですが、運用自動化の観点から AWS CLI を用いて以下のコマンドで実行しました。

フェイルオーバー後の PHZ 更新

Aurora の昇格が完了すると、大阪クラスターが新しい Primary Writer となります。ここで一つ手動操作（DNSレコードの更新）が必要になります。

前回の記事で解説した Private Hosted Zone（PHZ）スプリットビューの設定では、大阪 VPC の PHZ レコードは「大阪クラスターの Reader Endpoint」を指していました。昇格後は大阪クラスターが Writer になるため、このレコードを Writer Endpoint へ更新する必要があります。

本来、この更新を行わないと大阪の EC2 からの接続先が依然として Reader Endpoint を向いており、書き込みエラーが継続します。

【シングル構成における注意点】
もしコスト最適化などの目的で Aurora クラスターを「シングル構成（インスタンス1台）」で構築している場合、この PHZ 更新操作を行わなくても、フェイルオーバー直後から記事の書き込みが成功してしまうことがあります。

これは Aurora の仕様上、クラスター内にインスタンスが1台しかない場合、Writer Endpoint と Reader Endpoint が全く同じインスタンスの IPアドレス を解決するためです。結果として、PHZ が Reader Endpoint を指したままでも昇格した唯一のインスタンス（Writer）に接続され、書き込みが成功してしまいます。

しかし、マルチAZ（Readerインスタンスが複数存在する状態）で構成している場合、Reader Endpoint への書き込みは失敗します。そのため、試験環境（シングルAZ構成）でテストが成功したが、本番環境（マルチAZ構成）のフェイルオーバーで書き込みが復旧しないという大きなトラブルの原因になります。
構成にかかわらず、フェイルオーバー時には必ず PHZ のレコードを Writer Endpoint へ更新する手順を組み込んでおいたほうが安全です。

管理用サブドメインの切り替えと動作確認

本環境では、ユーザーがアクセスする「閲覧用ドメイン（www）」と、管理者が記事の投稿などを行う「管理用サブドメイン（admin）」を役割として分けて設計しています。
閲覧用の www ドメインはレイテンシーベース・ルーティングによって障害時に自動的に切り替わりますが、管理用の admin サブドメインは「常に Primary（書き込み可能な）リージョンの ALB」を固定で指すようにしています。これにより、管理者は確実に書き込み可能な環境へアクセスし、ログインセッションの意図しない分散を防ぐことができます。

そのため、DB昇格などのフェイルオーバー処理に伴い、Route 53 において admin サブドメインのエイリアスレコードを東京の ALB から 大阪の ALB へと手動で更新します。

レコードの更新が完了したら、ブラウザから admin サブドメインの WordPress 管理画面にアクセスします。
本試験では、管理画面から記事の新規投稿を行い、エラーにならずデータベースへの永続化が成功することを確認しました。

これにより、閲覧（自動切り替え）と管理・書き込み（手動切り替え）の両方が大阪リージョンで正常に動作する状態が実現します。

4. Storage層の昇格処理（手動フェイルオーバー操作）

EFS 昇格の必要性

DB層の昇格が完了した状態でも、EFS に関してはまだ対処が必要です。

通常運用では、大阪の EFS は東京からのレプリケーションを受信している「読み取り専用」のファイルシステムです。この状態のまま大阪を Primary として運用すると、WordPress がアップロードファイルを EFS に書き込もうとしてもエラーになります。

フェイルオーバー時のフォールバックとして EFS を書き込み可能にする「昇格」操作が必要な理由がここにあります。

EFS Replication の解除（昇格操作）

EFS の昇格は、大阪側の EFS に設定されているレプリケーション設定を削除することで行います。これも AWS CLI を用いて以下のコマンドで実行しました。

注意点として、この操作はEFS 内部の同期状態が解消されてから完了するまでに時間を要します。完了は非同期であり、ステータスが「Enabled」→「Deleting」→「（設定が消える）」という遷移をたどります。完了するまでの時間はシステムの状態に依存しており、ユーザー側でコントロールすることはできません。

昇格後の動作確認

レプリケーション削除の完了を確認した後、大阪の WordPress から画像をアップロードし、EFS に書き込みが行えることを確認します。本試験では画像のアップロードとブラウザ表示が正常に完了することで、EFS の昇格を確認しました。

5. フェイルバックと環境復元

試験終了後は、東京リージョンを再び Primary に戻す「フェイルバック」を行い、通常運用状態への環境復元を確認しました。主な作業は以下の通りです。

1. 東京 ASG の復元：
   aws autoscaling update-auto-scaling-group コマンドで min-size / desired-capacity を試験前の値（1台）に戻し、東京の EC2 を起動。
2. Aurora のフェイルバック：
   再度 aws rds failover-global-cluster コマンドを実行し、東京を Writer に戻す。合わせて大阪 PHZ のレコードを Reader Endpoint に戻す。
3. EFS レプリケーションの再設定：
   aws efs create-replication-configuration コマンドを用いて、東京 EFS からのレプリケーションを大阪 EFS へ向けて再設定する。試験中に大阪で追加・変更されたファイルのハンドリングが必要な場合は、DataSync 等で別途同期を行う。

これら3つのレイヤーの復元がすべて完了し、東京・大阪ともに正常なリクエストを処理できる状態に戻ったことを確認して、フェイルバックは完了です。

6. 構成パターン別のフェイルオーバー特性比較

最後に、本件の知見を踏まえ、第1章で整理した Pilot Light パターンと今回の Active-Active パターンとのフェイルオーバー特性の違いを整理します。

Active-Active 構成の最大の優位性は「App 層の閲覧復旧が自動かつ迅速」である点です。DB や Storage の完全復旧には、どちらの構成パターンでも引き続き手動操作が必要であり、この部分の特性に本質的な差はありません。

また、本件を通じて明確になった点として、「Active-Active だからといってフェイルオーバーが完全無人化できるわけではない」という点があります。DB・Storage の昇格は、現況確認と管理者の判断を伴う手動操作として設計することが、スプリットブレインやデータ消失といったリスクを避けるための現実的なアプローチです。

7. まとめと次回予告

本記事では、以下のフェイルオーバー試験の手順と、各レイヤーの挙動の特性をレポートしました。

• 疑似障害（ASG 停止）を起点とした段階的フェイルオーバー試験の実施
• App層: Route 53 ヘルスチェックによる自動切り替えで「閲覧」が迅速に復旧
• DB層: Aurora Global DB フェイルオーバーと PHZ 更新により「書き込み」が復旧
• Storage層: EFS レプリケーション解除により「ファイル書き込み」が復旧
• フェイルオーバーにおける「現況確認」の重要性と、手動操作のリスクとのバランス

次回の記事では、この構成を実際に構築する上で遭遇した「ハマりどころ」を紹介します。他の環境でも踏みやすい落とし穴を厳選してレポートします。