災害復旧のファイル転送：事業継続性の確保

災害復旧ファイル転送は、プライマリサイトが障害を起こしても業務を継続させます。クロスリージョンレプリケーション（S3 CRR・Azure GRS）・ウォームスタンバイインフラ・文書化されたフェイルオーバー手順書を組み合わせます。DR対応のファイルシステムは変更を継続的にセカンダリ拠点にコピーし（RPO数秒〜数時間）、RTO目標内でのフェイルオーバーをサポートし、現実に近い条件でテストされています。有用なDRへの最短経路：1つのワークロードを選んで第2リージョンにレプリケートし、土曜日にリージョン障害をシミュレートして、実際に何が起こるかを測定することです。

ビジネスインパクトによるワークロードの分類

すべてのファイルシステムがホット-ホットレプリケーションを必要とするわけではありません。ビジネスインパクト分析により、ダウンタイムとデータ損失に対する許容度でシステムを分類します。

Tier 0（ミッションクリティカル）：決済処理・医療システム。RPO 1分未満、RTO 15分未満。
Tier 1（クリティカル）：注文管理・顧客向けアプリ。RPO 15分未満、RTO 1時間未満。
Tier 2（重要）：社内ツール・レポーティング。RPO 24時間未満、RTO 8時間未満。
Tier 3（標準）：研修資料・アーカイブ。RPO 1週間未満、RTO 3日未満。

Tier 0のレプリケーションコストはTier 3の3〜10倍かかります。正直にシステムをマッピングしてください。ほとんどの企業ではシステムの5〜10%がTier 0〜1に相当し、すべてを同じレベルに持ち上げるのではなく、そこに費用を集中させるべきです。

レプリケーショントポロジー

ファイルストレージには3つのレプリケーションモデルが主流です。

アクティブ-パッシブ：プライマリが書き込みを受け付け、セカンダリがレプリカを受信。フェイルオーバーにはプロモーションが必要。ほとんどのリージョナルDR設定で使用される。
アクティブ-アクティブ：両方のリージョンが書き込みを受け付け、競合解決を行う。複雑だがRTOがほぼゼロ。グローバルシステムで使用される。
バックアップベース：セカンダリへの定期的なバックアップ。RPOは最大だが最もシンプル。Tier 3で使用される。

S3クロスリージョンレプリケーション（CRR）はアクティブ-パッシブをサブミニッテのRPOで実装します。S3マルチリージョンアクセスポイントがフェイルオーバールーティングを追加します。アクティブ-アクティブには、データベースにDynamoDB Global TablesとCockroachDB、ファイルには競合解決タグ付きの双方向rcloneがDIYアプローチの1つです。

セカンダリリージョンの選択

プライマリとセカンダリは独立して障害を起こすべきです。目安：

異なる地理的リージョン（us-east-1 → us-west-2、us-east-1 → us-east-2ではなく）
異なる電力グリッド（米国では西海岸対東海岸、欧州では異なる国の電力網）
関連する場合は異なるプレートテクトニクスゾーン（両方が環太平洋火山帯上にあるのを避ける）

コンプライアンスワークロードでは、両方のリージョンが規制を満たす必要があります。GDPRのデータはEU内に留まるべきです。パリからフランクフルトまたはダブリンにレプリケートし、バージニアへは行かない。HIPAAはセカンダリリージョンでもBAAが必要です。リージョンの選択とその理由を文書化してください。監査人は必ず質問します。

クロスリージョンレプリケーションのコスト

レプリケーションには3つのコスト要素があります。

ストレージ：プライマリの2倍（両リージョンがコピーを保持）
データ転送：AWSはリージョン間CRRに0.02ドル/GBを課金
リクエスト料金：転送先のPUT操作

毎月10TBをレプリケートする場合、バージニアからオレゴンへのAWSコストは月700ドル程度です。軽減策：転送先で安価なストレージクラスにレプリケート（StandardではなくS3 Glacier Instant Retrieval）、重要でないデータを除外するためにプレフィックスまたはタグでレプリケーションをフィルタリング、バケットレプリケーションメトリクスで暴走したレプリケーションを検出。

フェイルオーバー手順書

考えとして存在するだけの手順書は、失敗する手順書です。本番対応の手順書が網羅すべき内容：

トリガー基準：フェイルオーバーを開始する条件（リージョンのステータスページ・アプリケーションのヘルスチェック・P99レイテンシが閾値超過）
決定権限：誰が判断を下すか（通常はVP Engineering + SREリード、自動トリガーの事前承認済み閾値付き）
手順：正確なコマンドを順番に、期待される出力付き
検証：各ステップが機能したことを確認する方法
ロールバック：フェイルオーバー自体が問題を引き起こした場合の元に戻す方法
コミュニケーション：ステータスページ更新・顧客通知・社内のLINE/Slackへの連絡

S3バックのアプリケーションのフェイルオーバーステップの例：Route 53のfiles.example.comをプライマリバケットのCloudFrontからセカンダリバケットのCloudFrontに更新する。digとカナリアアップロードで確認する。目標時間：10分未満。

DNSとルーティング戦略

DNSが通常フェイルオーバーを制御します。選択肢：

Route 53 Failoverルーティング：ヘルスチェックに基づく自動切り替えのアクティブ-パッシブ
Route 53 Latencyルーティング：最寄りの正常なリージョンへのトラフィック
CloudFrontとオリジンフェイルオーバー：クライアントに透過的
マルチリージョンバックエンド付きロードバランサー：機能するが複雑さが増す

TTLが重要です。300秒のTTLのDNSレコードは5分でフェイルオーバーし、3,600秒のTTLは1時間かかります。DR上重要なレコードはTTL 60〜300秒に設定し、より高速な収束のためにわずかに多いDNSトラフィックを受け入れてください。

フェイルオーバー中のデータ整合性

レプリケーションラグはセカンダリがわずかに遅れていることを意味します。フェイルオーバーにより最近の書き込みが失われる可能性があります。RPOを最悪ケースの想定損失として文書化し、照合計画を持ってください。

アプリケーション層でコミットされていない書き込みをログに記録して再生できるようにする
処理中のトランザクションをキャプチャしてイベントログから再生する
損失を明示的に受け入れる（重要でないデータには、シンプルが最善）

ファイルのアップロードについて特に言えば、フェイルオーバーで中断されたマルチパートアップロードはセカンダリに不完全なアップロードを残す可能性があります。両方のリージョンにAbortIncompleteMultipartUploadライフサイクルルールを設定してクリーンアップしてください。

DRの真剣なテスト

テスト済みのDR計画とテストされていないDR計画は別物です。テストの段階：

卓上演習：手順書を口頭で確認する。四半期ごとに。
部分的なフェイルオーバー：1つのサブシステム（例：ファイルサービスのみ）をフェイルオーバーする。半年ごとに。
完全なリージョナルフェイルオーバー：スケジュールされたメンテナンスウィンドウですべてをフェイルオーバーする。年次で。
カオスエンジニアリング：スケジュールなし、シミュレート、業務時間中に。Tier 0システムには四半期ごとに。

すべてを記録してください。何が壊れたか。各ステップが実際にかかった時間。必要なときにドキュメントにアクセスできなかった人。各テスト後に手順書を改善してください。これを実践するチームのフェイルオーバーは機能し、実践しないチームは実際のインシデント中に問題を発見します。

コミュニケーションチャンネルが重要

インシデント中、クラウド内のコミュニケーションが利用不可になることがあります。障害が起きているのと同じAWSリージョンでホストされているSlackは役に立ちません。帯域外のチャンネルを事前に取り決めてください。

別のリージョンでホストされるセカンダリSlackワークスペース
TwilioまたはTelnyxによるSMSブリッジ
最終手段としての個人の電話網
プライマリインフラ外でホストされる公開ステータスページ（Atlassian Statuspage・StatusGator）
LINEのグループチャット（モバイルで機能し、インフラとは独立している）

チャンネルを物理バインダーに文書化してください。それらへの切り替えを練習してください。

担当者間での復旧ファイルの転送

リージョン障害により通常のコラボレーションツールにアクセスできなくなった場合、特定のファイル（最新のデータベースダンプ・設定エクスポート・インシデントレスポンスプレイブック）の転送には、インフラから独立して動作するチャンネルが必要です。個人デバイスで使えるツールが役立ちます。

HexaTransferはアカウント設定なしにどのブラウザでも動作します。SSOプロバイダーもダウンしているとき、または対応するコンサルタントがテナントにプロビジョニングされずにファイルを受け取る必要があるときに役立ちます。エンドツーエンドのAES-256-GCM暗号化により、ストレス下のインシデント対応中でも秘密が漏洩しません。

事後レビュー

すべてのDRテストとすべての実際のインシデントには、責任追及しないポストモーテムが必要です。文書化すべき内容：

イベントのタイムライン
うまくいったこと
うまくいかなかったこと
根本原因（技術的・プロセス的）
担当者と期限付きのアクションアイテム

アクションアイテムを完了まで追跡してください。20のアクションがあって完了がゼロのポストモーテムは、ポストモーテムなしより悪い状態です。改善が重要ではないというシグナルをチームに送ることになります。ループを閉じれば、次のインシデントは前回より改善されます。

災害復旧はほとんどが規律です。RPO/RTOを設定し、継続的にレプリケートし、手順書を文書化し、四半期ごとにテストし、帯域外でコミュニケートする。技術は簡単な部分です。

hexatransfer.com で今すぐ試せます — 無料、アカウント不要、最大10GB。