DeNAがARC Region Switchで実現した10分以内の自動DR切り替え

編集: グリットアーツ編集部

公開日：2026年10月12日

3行解説

ニュースの概要

DeNAのエンジニアが、2026年8月6日付の技術記事で、リージョン障害時に自動で切り替えるDR（災害復旧）設計を紹介しました。対象は、東京リージョンと大阪リージョンにまたがる基盤サービスです。記事では、AWS Global Accelerator、ECS Fargate、Aurora Global Database、CloudWatch、Amazon Application Recovery Controller（ARC）のRegion Switchを組み合わせ、RTO 10分を目標にした自動復旧の流れを説明しています。

このサービスでは、平時は東京をプライマリ、大阪をセカンダリとして運用し、障害時にはリクエスト処理、アプリケーション実行、データベース書き込み先を健全なリージョンへ寄せます。なお、東京リージョンが復旧した後の戻し作業は手動運用としています。

何が新しいのか

新しい点は、障害の検知と切り替えの実行を分けて設計していることです。監視は、東京と大阪の2つのLambdaから東京のライターに書き込みを試し、両方が3分連続で失敗したときだけ切り替えを起動します。これにより、単一の監視経路の不具合で誤って切り替えるリスクを下げています。

実行面では、ARC Region SwitchのPlanに、Aurora Global Databaseのフェイルオーバー、ECSサービスの200%キャパシティへの増強、旧東京側ECSのDesired Countを0にする縮退を組み込んでいます。切り替え先の大阪リージョンは、最初に読み込み確認を行い、問題があれば自動切り替えを止めて手動対応に戻します。

グリットアーツ編集部の分析

この事例で重要なのは、RTO 10分という目標に対して、Auroraの切り替えとECSの増強を並列化している点です。人手で順番に作業すると、切り替え先の準備とDB昇格が直列になり、復旧時間が伸びやすくなります。逆に並列化できれば、復旧時間の短縮に効きますが、その分だけ事前検証は重くなります。

また、監視欠損を失敗として扱い、広範囲障害は自動化の対象外にしている点も実務的です。自動化を広げすぎると誤切り替えの影響が大きくなるため、自動でやる範囲と手動に残す範囲を分ける設計は、現場で再現しやすい考え方だといえます。

日本の現場で考えると

この設計は、社内業務基盤や更新頻度が高くない業務システムのように、多少のデータロストを許容しつつ復旧速度を優先したい場面に向いています。逆に、厳密なRPOが必要な基幹系や、広域障害でも完全自動復旧を求める用途では、そのまま当てはめにくいです。

日本の現場では、東京・大阪のように地理的に分けた2リージョン運用でも、切り替え先のキャパシティ確保、監視の欠損判定、戻し作業の手順が運用負荷になります。特に、切り替え後に旧リージョンへ戻す作業を手動にするなら、夜間・休日のオンコール体制まで含めて設計しておく必要があります。

導入・検討時に確認したいこと

• 監視が3分連続で失敗したときの誤検知率と、検知までの実測時間
• AuroraフェイルオーバーとECS増強を並列に実行した場合の所要時間
• 切り替え先リージョンの健全性確認で、どの条件なら自動停止するか
• 旧リージョンをDesired Count 0にする際の影響範囲と復旧手順
• 東京へ戻すフォールバックを手動にした場合の責任分界と運用手順

現時点で分かっていないこと

記事からは、実際の切り替え成功率や訓練回数、切り替え時の詳細な所要時間分布は分かりません。また、200%キャパシティ増強がどの程度の余裕を前提にしているかも、公開情報だけでは確認できません。

マルチリージョンの自動復旧は、監視の作り方と切り替え手順の分け方で難易度が大きく変わります。自社のRTOや手動復旧の残し方を整理したい場合は、運用設計の観点から検討する価値があります。

出典: DeNA Engineering