こんにちは！SUZURI・minne事業部 minneグループのtossy（@tossy）です。
2026年3月15日に開催された 「AWS入門のためのAWS体験話。だから私はAWS。」 で「BCPを踏まえたインシデント対応演習」というタイトルで登壇しました。 本記事では、発表内容の概要についてお伝えします。
発表資料
発表の概要
GMOペパボでは年に一度、インシデントの対応力向上を目的とし、インシデント対応演習を実施しています。 過去に実施したインシデント対応演習の内容は以下をご覧ください。
今回の発表では、事業継続計画（BCP）の観点から、DB障害が発生した場合の復旧を迅速にするためのインシデント対応演習についてお話ししました。
BCPとは、企業が自然災害などの緊急事態に遭遇した場合において、事業継続のための方法、手段などを取り決めておく計画のことです。 特にDB障害については、復旧のための手順書はあるが実際に対応したことがないという状況が想定されます。
そこで、「知っている」と「やったことがある」では実際に対応するときの行動が大きく変わってくるため、そのギャップを演習で埋めることを目的としました。
演習の背景
AWSのAZ障害によるDB影響へ備える理由として、以下のような背景があります。
- ランサムウェアによるDB暗号化の被害が増加しており、IPAの「情報セキュリティ10大脅威 2025」でも組織向け脅威第1位に選出
- 2025年4月に実際にAWS東京リージョンのAZでEC2インスタンスへの接続に影響が出る障害が発生
このことから、AWSのAZ障害が発生したときに備えておく必要があると考えました。
演習の構成
実際の障害を想定した机上訓練と手を動かす実機演習の2部構成で実施しました。
机上訓練では、事務局が「AWSのあるリージョンのとあるAZにて障害が発生している」という第一報を共有し、演習者がチームで3つのチェックポイントに答えていく形式で対応をシミュレーションしました。事前にハンドラ・影響調査・マネージャ連絡/書記の役割分担を行い、Slackチャンネルを作成するなど本番に近いフローで実施しました。
机上訓練の振り返りとしては、本番に近い状態でのAWSのAZ障害のシミュレーションができた一方で、用意したシナリオに対してサービス影響ありと報告を受けた想定外の展開もありました。
実機演習では、Staging環境のDBを使って以下の3つの演習を実施しました。
- 手動スナップショット作成・復元・削除 — スナップショットからの復元は新しいインスタンスとして作成されること等を体験
- マルチAZフェイルオーバ — 数分で切り替わること、エンドポイントが変わらないことを確認
- クロスリージョンリードレプリカ — 東京から大阪リージョンへのリードレプリカ作成と昇格を実施
DB障害への備えの比較
発表では、マルチAZとクロスリージョンリードレプリカの違いを以下のように整理しました。
| マルチAZ | クロスリージョンリードレプリカ | |
|---|---|---|
| レプリケーション | 同期的 | 非同期的 |
| 切り替え | 自動 | 手動（昇格操作） |
| エンドポイント | 変わらない | 変わる（アプリ側変更必要） |
| 対応範囲 | AZ障害 | リージョン障害 |
| 復旧時間目安 | 数分 | 〜数時間程度 |
マルチAZフェイルオーバは自動で復旧できるメリットがあります。クロスリージョンリードレプリカでは、リージョン単位の障害に対して別リージョンでサービス継続ができる一方、昇格後はアプリケーションのDB接続先変更や差分データの復旧など手動オペレーションが多くなる点があります。
まとめ
今回の演習を通じて、「知っている」と「やったことがある」のギャップを埋めることができました。机上訓練では、「AWSのあるリージョンのとあるAZにて障害が発生している」というシミュレーションを行い、本番に近い訓練を行うことができました。実機演習では各復旧手段の特性と運用上の注意点を手を動かしながら体感することができました。
イベントを運営してくださったみなさま、聴講してくださったみなさま、ありがとうございました。 この記事が、同じようにインシデントの対応演習をされる方の参考となれば幸いです。
