はじめに

こんにちは、 IT 本部 IT 基盤部 第三グループの横野です。

DeNA では、全社的な業務を支える基盤サービスが多数存在します。その中には、リージョン障害が発生した場合でも 目標復旧時間（RTO）が 10 分のサービスなど、特に高い可用性が求められるサービスもあります。こうした要件を満たすため、私たちは Disaster Recovery（DR）の自動化に取り組みました。

本稿では、そのような厳しい要件を持つサービスに対して、どのように障害を正確に検知し、高可用性な自動切り替えメカニズムを実現したのか、そのアーキテクチャと具体的な仕組みについてご紹介します。読者の皆さんが、高い可用性を要求されるサービスにおける DR 自動化の一例について理解を深めていただければ幸いです。

なお、本稿でいう DR、あるいは「切り替え」とは、リージョン障害などによってデータベースのライターインスタンスを使い続けられなくなったときに、リクエスト処理を生き残っているリージョンだけで完結できる状態へ移すことを指します。

サービス要件と DR 自動化の背景

私たちが運用する基盤サービスは、多くの社員が日々の業務で利用する重要なシステムです。リージョン障害が発生した場合、多くの社員の業務が停止してしまうため、このサービスには以下の要件が求められています。

• 高可用性: 社内業務の根幹を支えるため、長時間のサービス停止は許容されません。
• 迅速な復旧: 重大な障害であっても、RTO は 10 分です。

これらの要件を満たす手段の一つとして、Disaster Recovery（DR）の自動化に取り組みました。

なお、DR 設計の前提として、このサービスは更新処理の頻度が高くなく、仮に一定範囲のデータロストが発生しても再実行で吸収できます。そのため、RPO（目標復旧時点）として一定のデータロストを許容しており、DR の設計において復旧速度を優先できます。

まずはサービスのインフラ構成を整理します。

サービスのインフラ構成

本サービスは、東京リージョンと大阪リージョンに同等のアプリケーション実行基盤を持ち、リージョン分散した形で 1 つのサービスとして提供しています。構成は次の通りです。

1. エントリポイント（グローバル）: クライアントからのトラフィックは AWS Global Accelerator (GA) に到達し、東京・大阪のアプリケーション基盤へ分散されます。
2. アプリケーション層（リージョン単位）: 各リージョンでは ALB の背後で ECS Fargate がアプリケーションを実行し、受け取ったリクエストを処理します。
3. データ層（リージョン横断）: データベースは Amazon Aurora Global Database で構成され、平時は東京リージョンをプライマリ、大阪リージョンをセカンダリとして運用します。書き込みは東京側のライターインスタンスが担い、リーダーインスタンスは両リージョンに配置しています。

上記の構成を図で示すと、次のようになります。

このような構成において、特定のリージョン全体で障害が発生した際に、サービスを停止させることなく処理を健全な別リージョンへ寄せられるかが最大の課題になります。

DR 自動化アーキテクチャの全体像

前節ではサービス構成を整理しました。この節では、その構成に対して監視・切り替えの仕組みをどのように導入したか、DR 自動化アーキテクチャ全体の流れを示します。

DR の対象範囲の整理

まず対象を整理すると、リージョン障害が発生した際には、クライアントからのリクエスト、Web アプリケーションを実行する ECS タスク、書き込み先である Aurora Global Database のライターを健全なリージョン側へ寄せます。

ただし、これら 3 つがすべて同じ仕組みで切り替わるわけではありません。リクエスト自体は、アプリケーションレベルの障害であれば GA のヘルスチェックに基づくトラフィック制御によって健全なリージョンへ自動で迂回できます。一方で、Aurora ライターインスタンスの異常は GA では解消できません。また、リクエストが健全なリージョンへ寄ったとしても、そのリージョン側の ECS タスク数が平時のままでは全リクエストを受けきれない可能性があります。

そのため今回の DR 自動化の主対象は、「GA だけでは解決できないデータベースライターの切り替え」 と 「切り替え先リージョンで処理を完結させるための ECS の増強・旧リージョン側の縮退」 です。

DR 設計上の課題

RTO 10 分を実現するうえで、2 つの課題があります。1 つ目は障害判定の課題で、判定を早めると誤検知が増え、慎重にしすぎると復旧が遅れるというトレードオフがあります。2 つ目は切り替え実行の課題で、適切に障害を判定できたとしても、切り替え作業を人手で行うと着手の遅れや手順ミスによって実際の復旧時間が悪化し、RTO を満たせなくなりえます。

特にリージョン切り替えは、Aurora ライターインスタンスの昇格や ECS の再配置を伴う重い操作であり、誤って発動するとそれ自体がユーザ影響につながります。つまり、正しく切り替えるべき障害を見極めることと、その切り替えを素早く確実に実行することをどう両立するかが、本稿で解く問題です。なお、監視欠損や複数リージョンを跨ぐ非常に広範囲な障害など、自動復旧の前提を満たしにくい事象は手動対応としています。

検知・実行の 2 段構成

これらの課題に対応するため、全体像は大きく「障害を検知するレイヤー」と「切り替えを実行するレイヤー」の 2 段で構成されます。前者は誤検知を抑えながら切り替えるべき障害を見極めること、後者は判定後の切り替えを人手に依存せず迅速かつ再現性高く実行することを担います。

1. 障害の検知
   • 各リージョンに配置した監視 Lambda が Aurora ライターインスタンスへの書き込み可否を定期的に確認し、結果を CloudWatch アラームとして集約します。
   • すべての監視が失敗を示したときだけ切り替えをトリガーすることで、誤検知による誤切り替えを防ぎます。
2. フェイルオーバーの実行
   • 切り替えがトリガーされると Amazon Application Recovery Controller (ARC) の Region Switch が起動し、事前定義したワークフローを実行します。
     • ARC は、マルチ AZ / マルチリージョン構成の復旧を支援する AWS のマネージドサービスです。今回利用している Region Switch はその中でもマルチリージョン DR の実行オーケストレーションを担う比較的新しい機能で、切り替え手順を Region Switch Plan として定義できます。概要は Amazon Application Recovery Controller (ARC) 、機能の詳細は About Region switch をご覧ください。
     • Region Switch Plan では、Aurora Global Database のフェイルオーバー、ECS のスケール調整、必要に応じた Lambda によるカスタムアクションなどを、並列・直列のステップとして AWS マネージドで実行できます。
   • ワークフローの最初のステップでは切り替え先リージョンの健全性を確認し、問題がある場合は自動切り替えを中断してオンコール担当者へ通知します。
   • 確認を通過した後、Aurora Global Database のフェイルオーバーと ECS のスケール調整を連携させて、リクエスト処理・アプリケーション実行・データベース書き込みを健全なリージョンで完結できる状態へ移行します。
   • なお、切り替え後に東京リージョンが復旧した後は、ライターを東京へ戻すフォールバックを手動で実施する運用です。

このように、DR 自動化アーキテクチャ全体としては、「監視 Lambda + CloudWatch」が検知系を担い、「ARC Region Switch + Aurora + ECS 制御」が実行系を担う構成です。

以降の節では、まず障害検知の仕組みを説明し、その後に自動切り替えワークフローを見ていきます。

リージョン障害の検知

リージョン障害の検知には、1 分間隔で定期的に実行される 2 種類の監視 Lambda を利用しています。いずれも東京のライターインスタンスへテストデータの書き込みを試みるもので、実行元のリージョンだけが異なります。

• セカンダリリージョン（大阪）からの書き込み監視: 監視元が切り替え先の大阪側にあるため、東京リージョンに障害が起きても観測を継続しやすく、切り替え判断の主信号として利用します。
• プライマリリージョン（東京）からの書き込み監視: ライターインスタンスの障害かリージョン間ネットワーク障害かを切り分ける補助信号です。東京リージョン障害時には監視結果自体が欠損する可能性があるため、欠損も失敗として扱います。

この 2 つの監視が 3 分間にわたってともに失敗した場合、単一の監視経路の問題ではなく、ライターインスタンスもしくは東京リージョン側の障害である可能性が高いと判断し、自動フェイルオーバーをトリガーします。逆に、片方でも成功している間は切り替えを実行せず、誤検知による誤切り替えを防ぎます。

なお、切り替え先である大阪側リーダーインスタンスの健全性は、この判定条件には含めず、Region Switch ワークフローの最初のステップで確認します。リーダーインスタンスへの読み込み監視を定期実行して判定条件に加える構成も検討しましたが、その場合、リーダーインスタンス側の失敗判定がライターインスタンス側のアラーム成立に必ず先行するとは保証できず、セカンダリ側も不健全な広範囲障害、つまり本来オンコール対応すべき状況でもフェイルオーバーが実行されてしまうおそれがあります。切り替え直前に確認する方式であれば、健全性チェックが必ずフェイルオーバーに先行します。

RTO 10 分を実現する自動切り替えワークフロー

障害検知によって切り替え対象と判断されると、Amazon Application Recovery Controller (ARC) の Region Switch が起動し、東京リージョンから大阪リージョンへ、Aurora ライターと ECS の実行基盤を寄せるフェイルオーバー処理を、定義されたワークフローにしたがって自動で実行します。

1. 切り替え先リージョンの健全性確認: 最初のステップとして、セカンダリリージョン（大阪）のリーダーインスタンスに Lambda 関数から読み込みを実行し、切り替え先のリーダーインスタンスが読み取りを受け付けられる状態にあることを確認します。この確認に失敗した場合はワークフローをその時点で停止し、手動対応へ切り替えます。
2. ECS サービスのスケールアップと Aurora フェイルオーバーの並列実行: 切り替え先のセカンダリリージョン（大阪）にある Web アプリケーション（ECS サービス）を通常の 200% キャパシティに増強する処理と、Aurora Global Database のライターの切り替えを並列で実行します。これにより、アプリケーション受け入れ体制の準備とデータベース切り替えを同時進行させ、復旧時間を短縮します。
3. プライマリリージョン ECS のスケールダウン: 障害が発生した旧プライマリリージョン（東京）の Web アプリケーション（ECS サービス）を Lambda 関数経由で縮退し、ECS サービスの Desired Count を「0」に設定します。これは、フェイルオーバー後の旧プライマリリージョン側ではアプリケーションが正常に動作しない可能性があることから、継続稼働を防ぐためです。

ARC Region Switch では、Aurora Global Database のフェイルオーバーや ECS のスケール調整を Plan として定義できるため、切り替え手順を再現可能なワークフローとして表現できます。また、シンプルな定義で扱える一方、その切り替え自体の可用性を確保できる点も利点でした。加えて、IAM 権限が不足している場合に警告されるため、事前の設定不備に気づきやすい点も有用でした。

自動化が失敗したときの安全網

自動化されたワークフローがいつでも成功するとは限りません。そこで、Region Switch の実行失敗を検知する EventBridge ルールを設定しています。ワークフロー全体の実行失敗や、ステップの失敗・エラーによる一時停止のイベントを捕捉し、SNS 経由でオンコール担当者へ通知します。前述の切り替え先健全性確認で停止した場合もこの通知の対象であり、自動復旧できないケースは速やかに手動対応へ引き継がれます。

本番 DR 訓練と検証結果

この DR 自動化は、まず開発環境で事前に検証し、その後に本番環境でも DR 訓練を実施しました。本番での DR 訓練では、東京リージョン側サブネットの Network Access Control List（NACL）を全拒否に変更して障害発生を模擬しました。

訓練手段として NACL を採用したのは、ECS、Aurora、ALB といった主要コンポーネントが機能しない状態を、ネットワークレイヤで明示的かつ確実に再現しやすいためです。今回の訓練では、個別コンポーネントの異常ではなく、東京リージョン側でサービス処理を継続できない状況を一貫して作ることが重要でした。また、NACL の変更は切り戻し手順が明確であり、万が一想定外の事態に至った場合でも比較的容易に復旧できます。障害を確実に発生させられることと、安全に切り戻ししやすいことの両方を満たせる点を重視して、この方法を選択しました。

なお、訓練時はユーザ影響を最小限に抑えるため、ECS のヘルスチェックでは通過条件を緩め、障害検知についても通常時より検知しやすい条件に変更した簡略化構成で実施しました。これは訓練を安全に実施するための暫定的な調整であり、実際の障害発生時の復旧時間そのものが短縮されたことを意味するものではありません。

切り替え先健全性確認ステップは訓練時点ではまだ組み込まれていませんでしたが、別途の検証でこのステップ単体の所要時間が数秒程度であることを確認しています。

通常時の想定所要時間と、訓練時に適用した簡略化構成での想定所要時間は、以下の通りです。 ECS のスケールアップと Aurora フェイルオーバーは並行して進みますが、ユーザからのリクエストを正常に受け付けるには ECS がヘルスチェックを通過している必要があります。そして、そのヘルスチェック通過には Aurora フェイルオーバーの完了が前提となります。

本番 DR 訓練での実測値は 4 分 17 秒 でした。訓練時の想定所要時間（5 分）を下回る結果となり、各ステップの所要時間の見積もりが妥当であることを確認できました。以上より、RTO 10 分以内での復旧は十分に実現可能と言えます。

おわりに

本稿では、高い可用性が求められる基盤サービスにおいて、自動的な Disaster Recovery を実現するためのアーキテクチャについてご紹介しました。

主要なポイントは、RTO 10 分を満たすうえで存在する 2 つの課題に対して、それぞれ別の仕組みで対処した点です。

• 障害判定の課題への対処:
  • 異なるリージョンから実行する 2 種類の書き込み監視がともに失敗した場合のみ切り替えを実行し、誤検知による誤切り替えを抑えます。
• 切り替え実行の課題への対処:
  • Amazon Application Recovery Controller (ARC) Region Switch が、障害検知後に定義された手順にしたがって自動でフェイルオーバーを実行します。
  • ワークフローの最初に切り替え先リージョンの健全性を確認し、自動復旧できないケースは実行を停止して EventBridge 経由でオンコール担当者へ通知し、手動対応へ引き継ぎます。
  • ECS サービスのスケールアップと Aurora Global Database のフェイルオーバーを並列実行し、人手による遅れや手順ばらつきを抑えながら復旧時間を短縮します。

この DR 自動化アーキテクチャの導入により、障害判定の精度を高めつつ、判定後の切り替えを迅速かつ再現性高く実行できるようになり、目標としていた RTO（10 分以内）での復旧を実現しました。障害の発生頻度自体は高くないとしても、発生時に高い可用性を維持し、求められる復旧水準を確実に満たせる基盤を整えられた点に大きな価値があります。

今後は、定期的な DR 訓練を通じてこの自動化された仕組みをさらに改善・最適化し、予期せぬ広範囲な障害にも対応できる、より堅牢なサービス運用を目指します。この取り組みが、高い可用性を求める SRE エンジニアの皆さんの参考になれば幸いです。