独立サイトの災害復旧：RTO/RPOの定義、復旧手順、年次訓練

独立サイトの災害復旧：RTO/RPOの定義、復旧手順、年次訓練

一、RTOとRPO：まず許容できるデータ損失と停止時間を把握する

RTO（Recovery Time Objective、目標復旧時間）は、サイトが障害発生から対外サービスを復旧するまでの最大許容時間です。RPO（Recovery Point Objective、目標復旧時点）は、復旧後に許容できるデータ損失の時間幅です。この2つの数値を決めれば、バックアップ頻度と災害対策投資が決まります。つまりコストと可用性のトレードオフです。

直感に反する判断：B2B独立サイトでは、99.99%の可用性追求は過剰投資です。B2Bサイトは訪問者数が少なく、問い合わせはメールとフォームが中心で、4時間停止と1時間停止で業務への実影響に大差はありません。しかし災害対策コストの差は甚大です。RTO 15分を実現するには、デュアルアクティブ拠点とリアルタイムデータベース同期が必要で、月額コストは単一拠点方案の5〜10倍になります。

シナリオ例：産業機械の海外展開サイトで、月間問い合わせ数が約30件、客単価50万元。4時間停止すると、問い合わせ密度から計算して1〜2件の問い合わせを失う程度で、損失は限定的です。このようなサイトは単一拠点と日次バックアップで、RTO 4時間、RPO 4時間で十分で、月間の災害対策コストは200元未満です。無理にデュアルアクティブにすると、月2000元多く払って得る可用性は、業務に測定可能なリターンをもたらしません。

自分のサイトがどの分類か判断するには、まず月間問い合わせ数と客単価を見ます。月間問い合わせが100件超、客単価1万元未満ならEC寄りで、RTOは1時間に抑える必要があります。月間問い合わせが30件未満、客単価10万元超ならプロジェクト型寄りで、RTO 4時間で十分許容できます。

二、復旧手順：4ステップ、事前に紙に書いておく

災害復旧の手順を頭の中だけに置いてはいけません。障害は深夜に起こるかもしれませんし、担当者が出張中だったり、システムに詳しくない人だったりすることもあります。手順は文書化し、コマンドライン単位で誰がいつ何をするのかを明確にします。

標準的な復旧手順は4ステップです。まずトラフィックを切り替え、DNSまたはCDNを待機サーバーのIPに変更します。次にデータを復元し、遠隔のオブジェクトストレージから最新のバックアップを取得してファイルとデータベースを戻します。続いて検証し、トップページ、商品一覧、問い合わせフォームの送信、メール到達を一通り確認します。最後に関係者へ通知し、営業、カスタマーサポート、経営層にサイト復旧時刻を共有します。攻撃を受けた後の特別な復旧手順は次を参照してください。サイトが攻撃を受けた後。

事例: ある越境ECサイトで午前3時にアラートが鳴り、本番サイトが502を返しました。当番の運用担当は手順に沿って対応します。まずMySQLのクラッシュと確認し、再起動しても復旧せず。次にDNSを待機サーバーへ切り替え、TTLは事前に60秒に設定していたため10分で世界に反映。続いてS3から前夜のバックアップを取得してデータベースを復元し、40分で完了。その後、スマートフォンからテストの問い合わせを送信し、30秒後にメールを受信。最後にグループチャットで営業に通知し、朝8時の始業時にはサイトは正常に戻っていました。RTOは約1時間、RPOは約6時間で、目標を満たしています。

DNS切り替えとCDN連携の詳細は次を参照してください。CDNグローバル高速化のノード障害時の切り替えをご覧ください。ドメイン変更と301リダイレクトの引き継ぎも考え方は同じです。次を参照してください。サイトリニューアルとドメイン変更。

三、待機サーバーとコールドスタンバイ: 常に二重化が必要とは限らない

災害対策はコールドスタンバイ、ウォームスタンバイ、アクティブ-アクティブの3段階です。コールドスタンバイはバックアップファイルのみで、障害時に一時的にサーバーを立てて復旧します。ウォームスタンバイは待機サーバーを常時起動したままにし、データを非同期で同期します。アクティブ-アクティブは2つの拠点で同時にトラフィックを処理し、リアルタイムで同期します。コストは低い順から高くなるほど、RTOは短くなります。

多くのB2B直販サイトはコールドスタンバイとウォームスタンバイの併用で十分です。待機サーバーは常時起動しますがトラフィックは受けず、毎日1回データを同期します。障害時はDNSを切り替えるだけで、RTOは1〜2時間に抑えられます。アクティブ-アクティブは1人か少人数のチームには過剰投資で、運用の複雑さに耐えられません。

直感に反する注意点：DNSの切り替えは即時ではありません。TTLを60秒に設定しても、世界中でDNSが反映されるまで5〜15分かかり、一部のユーザーはローカルDNSキャッシュに数時間古いアドレスを保持し続けます。つまり、トラフィックを切り替えても全員がすぐに待機サーバーへアクセスするわけではなく、移行期間が発生します。事前計画には「DNS切り替え後、15分待ってから全世界からのアクセスを検証する」と明記しておきましょう。

4. 年次訓練：計画を実際に走らせ、紙の上の問題を見つける

災害復旧計画で最大のリスクは「書いただけでやったつもり」になることです。文書には立派に書いてあっても、実際に障害が起きてみると待機サーバーのパスワードが分からない、バックアップファイルが取得できない、SMTP設定が古いサーバーに直書きされている、といった問題が発覚します。こうした問題は実際に訓練して初めて表面化します。

年次訓練は業務が落ち着く日曜日の未明に実施し、全工程の時間を計測します。訓練では本番サイトを実際に切り替えるのではなく、テスト環境でバックアップの取得からフォームの検証まで復旧手順を一通り実行し、各ステップの実測所要時間を記録します。実測RTOと計画の目標を比較し、目標を超えていれば対策を強化します。訓練後は振り返りをまとめ、計画を更新します。

シナリオ例：あるチームが初めて年次訓練を行い、計画に沿ってバックアップを取得し、データベースを復旧し、サイトにアクセスしました。最初の40分は順調でしたが、問い合わせフォームの検証の段階で、送信してもメールがなかなか届きません。原因はSMTPパスワードがwp-config.phpに書かれており、旧サーバーのメールサービスがすでに停止していたことでした。これが実際の障害時に発覚していれば、さらに1時間の調査が必要になっていたでしょう。訓練の価値は、こうした紙の上の問題を事前に見つけることにあります。

バックアップ戦略の詳細設定はサイトのバックアップと復元演習、監視アラートのしきい値はサイト監視とアラート、日常メンテナンスのチェックリストは公式サイト保守で毎月やる6つのこと。

FAQ よくある質問

最後に

災害復旧で最も危険な心構えは「バックアップがあれば十分」というものです。バックアップが解決するのはデータを失わないことで、災害復旧が解決するのは、障害発生後にどれだけ早くサービスを戻せるか、誰がやるか、どうやるかです。この2つは、まる一揃いの計画と訓練の分だけ違います。計画のないバックアップは、いざという時にあたふたするだけです。訓練のない計画も、実際に使う時には同じように詰まります。

実行は3ステップです。第一に、月間の問い合わせ数と客単価からRTO/RPOを決めます。多くのB2Bサイトは4時間で十分なので、むやみに高い目標を追わないこと。第二に、コマンドライン単位の復旧計画を書き、パスワードマネージャーとクラウドストレージの2か所に保存します。第三に、毎年テスト環境で完全な訓練を1回行い、実際のRTO/RPOを記録し、目標を超えたら計画を強化します。この3ステップを終えて初めて、自分のサイトが障害後にどれだけ早く戻るかが分かります。

覚えておきたい一言。RTOは高ければ高いほど良いわけではなく、4時間と15分では災害対策コストが10倍違います。まずサイト停止4時間でどれだけ損失が出るかを計算し、それからどの程度の災害対策が必要かを決めましょう。