ディザスター リカバリー戦略を設計するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:09 復旧ターゲットに合わせて、構造化、テスト、文書化されたビジネス継続性とディザスター リカバリー (BCDR) 計画を実装します。 プランは、すべてのコンポーネントとシステム全体をカバーする必要があります。

このガイドでは、ワークロードの信頼性の高いディザスター リカバリー戦略を設計するための推奨事項について説明します。 顧客に対して保証されている内部サービス レベル目標 (SLO) またはサービス レベル アグリーメント (SLA) を満たすには、堅牢で信頼性の高いディザスター リカバリー戦略が必要です。 障害やその他の大きな問題が予想されます。 これらのインシデントに対処するための準備によって、顧客がビジネスを信頼して確実に提供できる量が決まります。 ディザスター リカバリー戦略は、大規模なインシデントの準備のバックボーンです。

定義

期間 定義
[フェールオーバー] 運用ワークロード トラフィックを使用できないリージョンから影響を受けない地理的リージョンに自動または手動でシフトする。
フェールバック 運用ワークロード トラフィックをフェールオーバー リージョンからプライマリ リージョンに自動または手動でシフトします。

主要な設計戦略

このガイドでは、信頼性計画の一環として次のタスクを既に実行していることを前提としています。

信頼性の高いディザスター リカバリー (DR) 戦略は、信頼性の高いワークロード アーキテクチャの基盤に基づいています。 DR 戦略の設計を開始する前に、ワークロードを構築するすべての段階で信頼性に対処し、最適化された復旧に必要な部分が確実に配置されるようにします。 この基盤により、目標復旧時間 (RTO) や目標復旧ポイント (RPO) など、ワークロードの信頼性目標が現実的で達成可能になります。

ディザスター リカバリー計画を維持する

ワークロードに対する信頼性の高い DR 戦略の基礎は、 DR 計画です。 計画は、環境の進化に合わせて定期的にレビューおよび更新される生きたドキュメントである必要があります。 適切なチーム (運用、テクノロジリーダー、ビジネス利害関係者) に定期的に計画を提示します (たとえば、6 か月ごと)。 OneDrive for Businessなどの高可用性でセキュリティで保護されたデータ ストアに格納します。

DR プランを開発するには、次の推奨事項に従います。

  • 災害を構成するものを明確に定義するため、DR 計画のアクティブ化が必要です。

    • 災害は大規模な問題です。 これらは、リージョンの停止、Microsoft Entra ID や Azure DNS などのサービスの停止、ランサムウェア攻撃や DDoS 攻撃などの重大な悪意のある攻撃である可能性があります。

    • オペレーターが誤って DR エスカレーションを呼び出さないように、1 つのリソースの障害など、災害とは見なされない障害モードを特定します。

  • FMA ドキュメントで DR 計画を作成します。 DR 計画で、障害として定義されている障害の障害モードと軽減戦略がキャプチャされていることを確認します。 DR 計画と FMA ドキュメントの両方を並行して更新して、環境が変更されたときやテストで予期しない動作が明らかになったときに正確になるようにします。

    • 非運用環境の DR 計画を開発するかどうかは、ビジネス要件とコストへの影響によって異なります。 たとえば、プレリリース テストのために特定の顧客に品質保証 (QA) 環境を提供する場合、それらの環境を DR 計画に含めることができます。

  • ワークロード チーム内のロールと責任を明確に定義し、organization内の関連する外部ロールを理解します。 ロールには、次のものが含まれている必要があります。

    • 災害の宣言を担当する当事者。

    • インシデントの閉鎖を宣言する責任を負う当事者。

    • 操作ロール。

    • テストと検証の役割。

    • 内部および外部の通信ロール。

    • 振り返りと根本原因分析 (RCA) のリード ロール。

  • ワークロード チームが従う必要があるエスカレーション パスを定義して、回復状態が利害関係者に確実に伝達されるようにします。

  • コンポーネント レベルの回復手順、データ資産レベルの回復、ワークロード全体の復旧プロセスをキャプチャします。 コンポーネントが最も影響の少ない方法で確実に復旧されるように、所定の操作順序を含めます。 たとえば、アプリケーションを回復する前に、データベースを復旧してチェックします。

    • 各コンポーネント レベルの回復手順について、ステップ バイ ステップ ガイドとして詳しく説明します。 可能であれば、スクリーンショットを含めます。

    • チームの責任とクラウド ホスティング プロバイダーの責任を定義します。 たとえば、Microsoft は PaaS (サービスとしてのプラットフォーム) の復元を担当しますが、データのリハイドレートと構成をサービスに適用する責任があります。

    • プロシージャを実行するための前提条件を含めます。 たとえば、収集する必要がある必要なスクリプトまたは資格情報を一覧表示します。

    • インシデントの根本原因をキャプチャし、復旧を開始する前に軽減策を実行します。 たとえば、インシデントの原因がセキュリティの問題である場合は、フェールオーバー環境で影響を受けるシステムを復旧する前に、その問題を軽減してください。

  • ワークロードの 冗長性設計 によっては、ワークロードを顧客が再び使用できるようにする前に、フェールオーバー後に大幅な作業を行う必要がある場合があります。 フェールオーバー後の作業には、DNS 更新プログラム、データベース 接続文字列更新プログラム、トラフィック ルーティングの変更が含まれる場合があります。 復旧手順でフェールオーバー後のすべての作業をキャプチャします。

    注意

    冗長設計では、大規模なインシデントから完全または部分的に自動的に復旧できる場合があるため、これらのシナリオに関するプロセスと手順が計画に含まれていることを確認してください。 たとえば、可用性ゾーンまたはリージョンにまたがる完全にアクティブ/アクティブな設計がある場合は、 可用性ゾーンまたはリージョンの停止後に透過的に自動的にフェールオーバーし、実行する必要がある DR プランの手順を最小限に抑えることができます。 同様に、 デプロイ スタンプを使用してワークロードを設計した場合、スタンプがゾーン単位でデプロイされている場合、部分的な停止のみが発生する可能性があります。 この場合、DR 計画では、影響を受けないゾーンまたはリージョンのスタンプを回復する方法について説明する必要があります。

  • フェールオーバー環境でアプリを再デプロイする必要がある場合は、ツールを使用して、デプロイ プロセスを可能な限り自動化します。 アプリのデプロイをすぐに開始できるように、DevOps パイプラインが事前デプロイされ、フェールオーバー環境で構成されていることを確認します。 必要に応じて手動承認ゲートを使用して、自動化されたエンドツーエンドのデプロイを使用して、一貫した効率的なデプロイ プロセスを確保します。 完全なデプロイ期間は、復旧ターゲットに合わせる必要があります。

    • デプロイ プロセスのステージで手動による介入が必要な場合は、手動の手順を文書化します。 役割と責任を明確に定義します。

  • できるだけ多くの手順を自動化します。 スクリプトでは、べき等性が可能になるため、宣言型プログラミングを使用します。 宣言型プログラミングを使用できない場合は、カスタム コードの開発と実行に注意してください。 再試行ロジックとサーキット ブレーカー ロジックを使用して、壊れたタスクでスタックしているスクリプトの時間を無駄にしないようにします。 これらのスクリプトは緊急時にのみ実行するため、誤って開発されたスクリプトを使用して、より多くの損害を引き起こしたり、回復プロセスを遅くしたりしないようにします。

    注意

    自動化によってリスクが発生します。 トレーニング済みのオペレーターは、自動化されたプロセスを慎重に監視し、プロセスで問題が発生した場合は介入する必要があります。 自動化が誤検知に反応するリスクを最小限に抑えるには、DR 訓練を徹底してください。 プランのすべてのフェーズをテストします。 検出をシミュレートしてアラートを生成し、復旧手順全体を進みます。

    DR ドリルでは、復旧ターゲット メトリックの更新を検証または通知する必要があります。 自動化が誤検知の影響を受けやすい場合は、フェールオーバーのしきい値を増やす必要がある場合があります。

  • DR 手順との混乱を避けるために、フェールバック 計画を DR 計画から分離します。 フェールバック 計画は、DR プランのすべての開発とメンテナンスに関する推奨事項に従う必要があり、同じ方法で構成する必要があります。 フェールオーバーに必要な手動の手順は、フェールバック 計画でミラーリングする必要があります。 フェールオーバー後にフェールバックがすぐに発生する場合や、数日または数週間かかる場合があります。 フェールバックはフェールオーバーとは別と考えてください。

    • フェールバックの必要性は状況的です。 パフォーマンス上の理由からリージョン間でトラフィックをルーティングする場合は、フェールオーバーされたリージョンで最初に負荷をフェールバックすることが重要です。 その他の場合は、ワークロードが配置されている運用環境に関係なく、いつでも完全に機能するようにワークロードを設計している可能性があります。

ディザスター リカバリー訓練を実施する

DR テストプラクティスは、よく開発された DR 計画と同じくらい重要です。 多くの業界では、指定された数の DR ドリルを定期的に実行する必要があるコンプライアンス フレームワークがあります。 業界に関係なく、定期的な DR ドリルは成功に最も重要です。

DR 訓練を成功させるには、次の推奨事項に従ってください。

  • 1 年に少なくとも 1 つの運用 DR ドリルを実行します。 テーブルトップ(ドライラン)訓練または非運用環境訓練は、関係者が自分の役割と責任に精通していることを確認するのに役立ちます。 これらの訓練は、オペレーターが回復プロセスに従うことで、知識 ("筋肉の記憶") を構築するのにも役立ちます。 ただし、運用訓練のみが、DR 計画と RTO および RPO メトリックの有効性を真にテストします。 運用ドリルを使用して、コンポーネントとフローの復旧プロセスを時間を計り、ワークロードに対して定義されている RTO ターゲットと RPO ターゲットが達成可能であることを確認します。 DNS 伝達など、制御できない関数の場合は、これらの関数を含むフローの RTO と RPO ターゲットが、制御を超える可能性のある遅延を考慮していることを確認します。

  • 卓上ドリルを使用して、経験豊富なオペレーターの知識を深めるだけでなく、DR のプロセスと手順について新しいオペレーターを教育することもできます。 上級オペレーターは、新しいオペレーターが自分の役割を果たすのに時間がかかり、改善の機会をwatchする必要があります。 新しい演算子がプロシージャのステップによってためらっているか混乱している場合は、そのプロシージャを確認して、明確に記述されていることを確認します。

考慮事項

  • 運用環境で DR ドリルを実行すると、予期しない致命的なエラーが発生する可能性があります。 最初のデプロイ中に、運用環境以外の環境で復旧手順をテストしてください。

  • 訓練中にチームにできるだけ多くのメンテナンス時間を与えます。 メンテナンス時間を計画する場合は、 テスト 中にキャプチャした復旧メトリックを 、必要な最小時間 の割り当てとして使用します。

  • DR ドリルプラクティスが成熟するにつれて、並列で実行できるプロシージャと、順番に実行する必要がある手順を学習します。 ドリル プラクティスの早い段階では、すべてのプロシージャを順番に実行する必要があり、予期しない問題を処理するために各ステップで余分な時間が必要であると想定します。

Azure ファシリテーション

多くの Azure 製品には、組み込みのフェールオーバー機能があります。 これらの機能を理解し、回復手順に含めます。

IaaS (サービスとしてのインフラストラクチャ) システムの場合は、Azure Site Recoveryを使用してフェールオーバーと復旧を自動化します。 一般的な PaaS 製品については、次の記事を参照してください。

例

DR 用のエンタープライズ データ資産の準備に関するガイダンスについては、Azure データ プラットフォームの DR シリーズを参照してください。

信頼性チェックリスト

推奨事項の完全なセットを参照してください。

信頼性チェックリスト