影響を与えずに行う DR テスト

一度もテストされていない災害復旧計画は、仮説にすぎません。実際の経験から、DR計画では、構成のドリフト、自動化の欠落、古いrunbook、想定を超える起動時間など、テスト環境でしか明らかにならない問題が頻繁に見つかることが分かっています。最も必要なときに計画が機能するという確信を持つには、定期的なDRテストしか方法がありません。

Test FailoverはAzure Site Recoveryに組み込まれた機能で、本番環境を中断せずにセカンダリリージョンへのフェールオーバーをシミュレートできます。テストフェールオーバー中、ASRはセカンダリリージョンの分離された仮想ネットワークに、レプリケートされたVMのコピーを作成します。プライマリリージョンの本番VMは通常どおり稼働し続けるため、実際のユーザーに影響するリスクはありません。

分離されたテストVNetは、本番システムに接続できないようにする必要があります。これにより、テストVMが本番データベースに誤って書き込んだり、実際の顧客にメールを送信したり、決済トランザクションを実行したりすることを防げます。本番VNetとのピアリングやインターネットアクセスを持たない専用のテストフェールオーバーVNetを作成し、DR訓練専用に使用してください。

DRテストでは、次の基準を検証します。

• 起動時間 — すべてのVMが想定時間内に起動するか
• アプリケーションの起動 — 復旧したデータベースに接続したとき、アプリケーションが正しく初期化されるか
• データの整合性 — 復旧ポイントのデータに一貫性があり、完全であるか
• 実際のRTO — フェールオーバーのトリガーからアプリケーションがリクエストの処理を開始するまでの経過時間を測定する
• Runbookの実行 — すべての自動化スクリプトが正常に完了したか

テスト中は、テストフェールオーバーをトリガーした瞬間にタイマーを開始します。アプリケーションが正常であることを確認できた時点（ロードバランサーの正常性プローブが200 OKを返した時点）でタイマーを停止します。これが実際のRTOです。目標RTOと比較してください。実際のRTOが目標を超えている場合は、VMの起動の遅さ、データベースの初期化時間の長さ、DNS伝播の遅延などのボトルネックを特定し、対処します。

テストフェールオーバーが完了したら、復旧したデータベースに接続してデータを検証します。レプリケーションのカットオフ前にコミットされたトランザクションが存在すること、また部分的にコミットされたトランザクションが正しく処理されていること（ロールバックまたは完了）を確認してください。ポイントインタイムリストア（PITR）に対応したデータベースでは、特定のタイムスタンプへの復元をテストし、期待どおりのデータ状態になっていることを確認します。

テストが完了したら、セカンダリリージョンにあるテストVM、そのディスク、ネットワークインターフェイスなどのテストフェールオーバーのリソースをクリーンアップする必要があります。Azure Site Recoveryでは、ポータルの'Cleanup test failover'アクションを使用して、すべてのテストリソースを自動的に削除できます。クリーンアップを忘れると、不要なコストが発生し、セカンダリリージョンに古いリソースが残ってしまいます。

各DRテストの後に、テスト日と範囲、達成した実際のRTOとRPO、合否を記載した検証項目のチェックリスト、確認された問題や失敗、予定している是正措置を含むテストレポートを作成します。このレポートは、コンプライアンス監査（ISO 27001、SOC 2、HIPAA）や、長期的なDR成熟度の改善状況を追跡するうえで役立ちます。

業界のベストプラクティスやコンプライアンスフレームワークでは、通常、DRテストを最低でも年1回実施することが求められます。ただし、Tier 1ワークロードの多くの組織では、四半期ごと、あるいは毎月テストを実施しています。テスト頻度を高めると、構成のドリフトを早期に発見でき、チームの自信と対応の習熟度も高まります。頻繁なテストの負担を減らすため、テストのセットアップと検証はできる限り自動化してください。

Azure Chaos Studioは、Azureリソースに制御された障害を注入して、アプリケーションの回復性をテストできるマネージドカオスエンジニアリングサービスです。VMの停止、ゾーン障害の発生、CPUのスロットリング、ネットワーク遅延の注入などを行い、アプリケーションの動作を観察できます。標準的なDR訓練とは異なり、カオスエンジニアリングでは、部分的な障害状態でアプリケーションが適切に縮退するかどうかをテストします。

DRテストは、継続的改善サイクルの一部として実施すると最も効果的です。計画 → 実行 → 測定 → 是正 → 繰り返し、というサイクルです。各テストの後に見つかった問題に対処し、runbookとドキュメントを更新して、再度テストします。時間の経過とともに、設定したRTO/RPOの目標値と実際の達成値との差を縮め、許容範囲内で毎回テストに合格できる状態を目指します。

このレッスンで学んだMicrosoft Azure Fundamentals（AZ-900）の概念について理解度を確認します。

このレッスンでは、テストフェールオーバーによって、分離されたVNetにVMのコピーを作成し、本番環境を中断せずにDRイベントをシミュレートできること、テスト中に実際のRTOを測定してデータの整合性を検証する必要があること、そして各訓練の後にテストリソースをクリーンアップして結果を文書化すべきことを学びました。次は、Azure SQL DatabaseのようなPaaSサービスに特化した災害復旧について説明します。