BCPを踏まえた インシデント対応演習 SUZURI・minne事業部 minneグループ / tossy 2026.03.15@AWS入門のためのAWS体験話。だから私はAWS。 

2 自己紹介 & 今日話すこと tossy / GMOペパボ SUZURI・ minne事業部 minneグループ ハンドメイドマーケット「minne」 のWebアプリケーションエンジニア BCPを踏まえたAmazon RDS for MySQLのインシデント対応演習を実 施した話をします 

インシデント対応演習とは 

4 インシデント対応演習の目的 事業継続計画（BCP） の観点から、DBに影響があった場合の復旧を迅速にしたい BCPとは、企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合にお いて（中略）事業継続のための方法、手段などを取り決めておく計画 特にDB障害が起きたとき、復旧のための手順書はあるが、実際に対応したことが ないという状況が想定される 「知っている」と「やったことがある」は行動が変わってくる → ギャップを演習 で埋めたい [1] [1] 中小企業庁ホームページ https://www.chusho.meti.go.jp/bcp/contents/level_c/bcpgl_01_1.html 

5 なぜ、DB障害の演習をやるのか AWSのAZ障害により、DBへ影響を受けた時の対応に備える ランサムウェアによるDB暗号化の被害が増加（2024年上半期で 114件） IPA「情報セキュリティ10大脅威 2025 」で組織向け脅威 第1位 に選出 実際に過去、AZ障害でEC2インスタンスに影響が出たことがある 2025/4/15 AWS東京リージョンのAZで障害 [2] [3] 15日午後4:40～5:43 (日本時間)の間、AP-NORTHEAST-1 リージョンの単一のアベイラビリティーゾ ーン (apne1-az4) において、一部のEC2インスタンスへの接続の問題が発生した [2] IPA 情報セキュリティ10大脅威 2025 https://www.ipa.go.jp/security/10threats/10threats2025.html [3] Amazon Elastic Compute Cloud (Tokyo) - April 15, 2025 | AWS Health Dashboard https://health.aws.amazon.com/health/status?eventID=arn:aws:health:ap-northeast- 1::event/EC2/AWS_EC2_OPERATIONAL_ISSUE/AWS_EC2_OPERATIONAL_ISSUE_F82D3_02AD2D67316 

インシデント対応演習概要 

7 インシデント対応演習の全体像 実際の障害を想定した机上訓練と手を動かす実機演習に分け、対応を実施 時間 内容 70分 説明・机上訓練（インシデント対応のシミュレーション） 10分 休憩 15分 実機演習1 スナップショット作成/復元/削除 20分 実機演習2 マルチAZフェイルオーバ検証 25分 実機演習3 クロスリージョンリードレプリカ検証 20分 チームでの振り返り（KPT） 

机上訓練 

9 机上訓練 狙い：実際の障害を想定したシミュレーションにより対応力を強化 事務局が 発生事象のみ を共有 演習者がチームで 3つのチェックポイント に答えていく 設定変更を行うオペレーションは実施せず、状態確認のみ実施 事前に役割分担を指定: ハンドラ / 影響調査 / マネージャ連絡・書記 → 本番で想定されるフロー(例：Slackチャンネル作成)で対応をシミュレーション 

10 全体シナリオ：AZ障害が発生 事務局からの第一報： 「AWSのあるリージョンのとある AZ にて障害が発生しているようで、RDSで影響が出ているようで す、原因調査をお願いします！」 ここから演習者の対応が開始 以下の各チェックポイントを演習者から事務局へ報告してもらう形式とした チェックポイント1：サービス影響範囲の特定 チェックポイント2：自動フェイルオーバ後の状態 チェックポイント3：異常箇所の報告 

11 チェックポイント1：サービス影響範囲の特定 事務局「チェックポイント① AWSのリージョンXXXに障害が発生しているようです。 データベースへの影響を報告してください」 DBが マルチAZ構成 であることを確認 AZ障害でプライマリが利用不可となる → 狙い：自動フェイルオーバにより サービス全体への影響は限定的 というこ とを答えてもらいたい [4] [4] Multi-AZ 配備のレプリケーションは、完全に管理されています。Amazon RDS では DB インスタンスの障害条件やアベ イラビリティーゾーンの障害が自動的に監視され、機能停止が発生すると、スタンバイ (Amazon Aurora の場合はリードレ プリカ) への自動フェイルオーバーが開始されます。https://aws.amazon.com/jp/rds/faqs/ 

12 チェックポイント2: 自動フェイルオーバ後の状態 事務局「チェックポイント② 現状のプライマリのDBのAZを想定し、報告願います」 セカンダリが プライマリに昇格していることがわかる。エンドポイント変わらず 狙い：AZが自動フェイルオーバで切り替わること=普段と異なるAZで提供されるこ とがわかる 実際の様子 

13 チェックポイント3：異常箇所の報告 事務局「チェックポイント3 異常が起きていた部分を報告してください」 フェイルオーバに伴う影響を洗い出し エンドポイント → 変わらないため影響なし ログ転送（CloudWatch） → 変わらないため影響なし アラーム → 切り替え時に一時的に発報する可能性あり レプリケーション遅延 → 一時的に発生する可能性あり 狙い：「何が影響を受けるか」だけでなく「何が影響を受けないか」の状況把握も 重要 

14 机上訓練での振り返り 良かった点 各演習者が協力することでスムーズな対応ができた → 事前の役割分担 が大事 本番に近い状態でのAWSのAZ障害のシミュレーションができた （事務局）用意したシナリオに対して想定外の展開 チェックポイント1にて、サービス影響ありとの報告 → 演習者へ気づきを与えることができた 反省点 チェックポイントを通過できない場面 → 次回以降、AZ障害への備え ができた （事務局）どの役割でメンションされているかの対応が難しかった 

実機演習 

16 実機演習の進め方 狙い：実際のオペレーションを手を動かし、体験する Staging環境のDBを使って AWSコンソールで実操作 手順書を参照しながら、チームで実施 役割（2チーム構成） 画面操作者：1名 ダブルチェック者：1名 書記（何を実施したかを記録）：1名 → 各メンバに役割を持たせ、 3役体制 で安全に実施 

17 実機演習1: 手動スナップショット作成、削除 やったこと Staging DBの 手動スナップショット作成 スナップショットから インスタンス復元（シングルAZ） スナップショットの 削除 学び スナップショット作成は 数分で完了 復元は 新しいインスタンスとして作成 される → DB障害時にスナップショットを用いたDB復旧を行うための確認ができた 

18 実機演習2: マルチAZフェイルオーバ やったこと インスタンスを手動でシングルAZ → マルチAZに変更 フェイルオーバの手動実行 と AZ切り替わりの確認 学び マルチAZフェイルオーバは 自動で数分で切り替わる エンドポイントは変わらず、瞬断のみ マルチAZは 同期レプリケーション しているため → データ差分復旧不要 [5] [5] Multi-AZ 配備が使うレプリケーションは同期しています。つまり、すべてのデータベース書込みはプライマリとスタンバ イで同時に行われます。このように最新のデータベース更新を保護することで、イベントのフェイルオーバー発生時にスタン バイ状態にすることができます。 https://aws.amazon.com/jp/rds/faqs/ 

19 実機演習3: クロスリージョンリードレプリカ やったこと 東京 → 大阪リージョン へクロスリージョンリードレプリカ作成 大阪リージョンのリードレプリカの 昇格 昇格後のインスタンス間の関係性を確認 学び 事前に VPC / サブネット / VPCピアリング の準備が必要 昇格後はレプリケーション関係が 切断 される リージョンに障害が発生しても、別リージョンでサービス継続できる ただし、別リージョンにもリードレプリカが必要となりコスト増 

20 クロスリージョンリードレプリカ昇格後に必要なこと 昇格すると東京-大阪の関係が切れ、それぞれが独立したインスタンスになる そのため、以下の対応が必要： アプリケーションのDB接続先を変更（エンドポイントが変わる） 設定ファイル（database.yml等）の書き換え アプリケーションの再起動 非同期レプリケーション であるため、障害以降の 差分データの復旧が必要 [6] → マルチAZのフェイルオーバと違い、復旧までの手動オペレーションが多くなる [6] Amazon RDS リードレプリカは同期レプリケーションをサポートしますか?→いいえ。 https://aws.amazon.com/jp/rds/faqs/ 

21 データベース障害への備えまとめ マルチAZ クロスリージョンリードレプリカ レプリケーション 同期的 非同期的 切り替え 自動 手動（昇格操作） ダウンタイム 数分 数分〜数十分 エンドポイント 変わらない 変わる（アプリ側変更必要） 対応範囲 AZ障害 リージョン障害 事前準備 少ない VPC/サブネット/VPCピアリング等が必要 コスト 中 高 復旧時間目安 数分 〜数時間程度 [7] [8] [7] スタンバイ分が追加となる [8] スタンバイ + リージョン間転送量がかかってくる 

まとめ 

23 まとめ BCPを踏まえ、DB障害時の復旧を迅速にするため、インシデント対応演習を実施 実際の障害を想定した机上訓練、および、手を動かす実機演習を実施 机上訓練：マルチAZ構成のプライマリ障害時を想定 実機演習：手動スナップショット作成・削除、マルチAZフェイルオーバ、クロス リージョンリードレプリカ 「知っている」と「やったことがある」の違いは大きいため、今回の演習でギャッ プを埋めることができて良かった 

Thank you! ご質問・フィードバックお待ちしています