この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:09 | 復旧ターゲットに合わせて、構造化、テスト、文書化されたビジネス継続性とディザスター リカバリー (BCDR) 計画を実装します。 プランは、すべてのコンポーネントとシステム全体をカバーする必要があります。 |
|---|
このガイドでは、ワークロードの信頼性の高いディザスター リカバリー戦略を設計するための推奨事項について説明します。 内部サービス レベル目標 (SLO) または顧客に対して保証したサービス レベル アグリーメント (SLA) を満たすには、堅牢で信頼性の高いディザスター リカバリー戦略が必要です。 エラーやその他の主要な問題が予想されます。 これらのインシデントに対処するための準備によって、顧客がビジネスを信頼して確実に提供できる量が決まります。 ディザスター リカバリー戦略は、主要なインシデントの準備のバックボーンです。
定義
| 任期 | 定義 |
|---|---|
| フェールオーバー | 使用できないリージョンから影響を受けない地理的リージョンへの運用ワークロード トラフィックの自動または手動シフト。 |
| フェールバック | 運用ワークロード トラフィックをフェールオーバー リージョンからプライマリ リージョンに自動または手動でシフトします。 |
主要な設計戦略
このガイドでは、信頼性計画の一環として、既に次のタスクを実行していることを前提としています。
重要なフローと重要でないフローを特定します。
フローに故障モード解析 (FMA) を実行します。
信頼性の目標を特定します。
堅牢なテスト戦略を設計します。
信頼性の高いディザスター リカバリー (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 計画に含めることができます。
ワークロード チーム内の役割と責任を明確に定義し、組織内の関連する外部ロールを理解します。 ロールには、次のものが含まれている必要があります。
災害の宣言を担当する当事者。
インシデントの閉鎖の宣言を担当する当事者。
オペレーション役割。
テストと検証のロール。
内部および外部の通信ロール。
振り返りと根本原因分析を主導する役割。
復旧状態が関係者に確実に伝達されるように、ワークロード チームが従う必要があるエスカレーション パスを定義します。
コンポーネント レベルの復旧手順、データ資産レベルの復旧、ワークロード全体の復旧プロセスをキャプチャします。 コンポーネントが最も影響の少ない方法で確実に復旧されるように、所定の操作順序を含めます。 たとえば、アプリケーションを回復する前にデータベースを回復して確認します。
各コンポーネント レベルの回復手順について詳しく説明します。詳細については、ステップ バイ ステップ ガイドを参照してください。 可能であれば、スクリーンショットを含めます。
チームの責任とクラウド ホスティング プロバイダーの責任を定義します。 たとえば、Microsoft は PaaS (サービスとしてのプラットフォーム) の復元を担当しますが、データのリハイドレートとサービスへの構成の適用は、お客様の責任で行います。
プロシージャを実行するための前提条件を含めます。 たとえば、収集する必要がある必要なスクリプトまたは資格情報を一覧表示します。
復旧を開始する前に、インシデントの根本原因を把握し、軽減策を実行します。 たとえば、インシデントの原因がセキュリティの問題である場合は、フェールオーバー環境で影響を受けるシステムを復旧する前に、その問題を軽減してください。
ワークロードの 冗長性の設計 によっては、ワークロードを顧客が再び使用できるようにする前に、フェールオーバー後に重要な作業を行う必要がある場合があります。 フェールオーバー後の作業には、DNS の更新、データベース接続文字列の更新、トラフィック ルーティングの変更が含まれる場合があります。 復旧手順でフェールオーバー後のすべての作業をキャプチャします。
注
冗長性設計では、大規模なインシデントを完全または部分的に自動的に復旧できる場合があるため、これらのシナリオに関するプロセスと手順が計画に含まれていることを確認してください。 たとえば、可用性ゾーンまたはリージョンにまたがる完全にアクティブ/アクティブな設計がある場合、 可用性ゾーンまたはリージョンの停止後に透過的に自動的にフェールオーバーし、実行する必要がある DR プランの手順を最小限に抑えることができます。 同様に、 デプロイ スタンプを使用してワークロードを設計した場合、スタンプがゾーン単位でデプロイされている場合、部分的な停止のみが発生する可能性があります。 この場合、DR プランでは、影響を受けないゾーンまたはリージョンのスタンプを回復する方法について説明する必要があります。
フェールオーバー環境でアプリを再デプロイする必要がある場合は、ツールを使用して、デプロイ プロセスを可能な限り自動化します。 アプリのデプロイをすぐに開始できるように、DevOps パイプラインがフェールオーバー環境で事前デプロイおよび構成されていることを確認します。 必要に応じて手動承認ゲートを使用して、自動化されたエンドツーエンドのデプロイを使用して、一貫性のある効率的なデプロイ プロセスを確保します。 完全なデプロイ期間は、復旧ターゲットに合わせる必要があります。
- デプロイ プロセスのステージで手動による介入が必要な場合は、手動の手順を文書化します。 ロールと責任を明確に定義します。
できるだけ多くの手順を自動化します。 スクリプトでは、べき等性が可能になるため、宣言型プログラミングを使用します。 宣言型プログラミングを使用できない場合は、カスタム コードの開発と実行に注意してください。 再試行ロジックとサーキット ブレーカー ロジックを使用して、破損したタスクでスタックしているスクリプトの時間を無駄にしないようにします。 これらのスクリプトは緊急時にのみ実行されるため、誤って開発されたスクリプトを使用して、より多くの損害を引き起こしたり、回復プロセスを遅くしたりしないようにします。
注
自動化はリスクを伴います。 トレーニング済みのオペレーターは、自動化されたプロセスを注意深く監視し、プロセスで問題が発生した場合は介入する必要があります。 自動化が誤検知に反応するリスクを最小限に抑えるには、DR 訓練を徹底してください。 計画のすべてのフェーズをテストします。 検出をシミュレートしてアラートを生成し、復旧手順全体を進みます。
DR ドリルでは、復旧ターゲット メトリックの更新を検証または通知する必要があります。 自動化が誤検知の影響を受けやすい場合は、フェールオーバーのしきい値を増やす必要がある場合があります。
DR プロシージャとの潜在的な混乱を避けるために、フェールバック 計画を DR 計画から分離します。 フェールバック 計画は、DR 計画のすべての開発とメンテナンスに関する推奨事項に従う必要があり、同じ方法で構成する必要があります。 フェールオーバーに必要な手動の手順は、フェールバックプランに取り入れる必要があります。 フェールバックは、フェールオーバー後にすぐに発生する場合や、数日または数週間かかる場合があります。 フェールバックはフェールオーバーとは別のものとして検討してください。
- フェールバックの必要性は状況によって異なります。 パフォーマンス上の理由からリージョン間でトラフィックをルーティングする場合は、フェールオーバーされたリージョンで最初に負荷をフェールバックすることが重要です。 その他の場合は、ワークロードが配置されている運用環境に関係なく、いつでも完全に機能するようにワークロードを設計している可能性があります。
ディザスター リカバリー訓練を実施する
DR テストプラクティスは、よく開発された DR 計画と同じくらい重要です。 多くの業界には、指定された数の DR 訓練を定期的に実行する必要があるコンプライアンス フレームワークがあります。 業界に関係なく、定期的な DR 訓練は成功に最も重要です。
DR ドリルを成功させるには、次の推奨事項に従ってください。
年に 1 回以上は実稼働環境で DR 訓練を実施してください。 テーブルトップ(ドライラン)訓練または非運用環境訓練は、関係者が自分の役割と責任に精通していることを確認するのに役立ちます。 これらの訓練は、オペレーターが回復プロセスに従って知識 ("筋肉メモリ") を構築するのにも役立ちます。 ただし、実稼働訓練のみが、DR 計画と RTO および RPO メトリックの有効性を真にテストします。 ワークロードに対して定義されている RTO ターゲットと RPO ターゲットが達成可能であることを確認するには、本稼働環境訓練を使用してコンポーネントとフローの復旧プロセスを時間を計測します。 DNS 伝達など、制御できない関数の場合は、それらの関数を含むフローの RTO と RPO のターゲットが、制御を超える可能性のある遅延を考慮していることを確認します。
卓上ドリルを使用して、熟練したオペレーターの知識を深めるだけでなく、DR プロセスと手順について新しいオペレーターを教育します。 上級オペレーターは、新しいオペレーターが自分の役割を果たすのに時間がかかり、改善の機会を見守る必要があります。 新しいオペレーターがプロシージャのステップに迷ったり混乱したりする場合は、その手順を確認して、明確に記述されていることを確認します。
考慮事項
運用環境で DR ドリルを実行すると、予期しない致命的なエラーが発生する可能性があります。 最初のデプロイ中に、非運用環境で復旧手順をテストしてください。
訓練中にチームにできるだけ多くのメンテナンス時間を与えます。 メンテナンス時間を計画する場合は、 テスト 中にキャプチャした復旧メトリックを 、必要な最小限の時間 として使用します。
DR ドリルのプラクティスが成熟したら、並列で実行できる手順と、順番に実行する必要がある手順を学習します。 ドリル プラクティスの初期段階では、すべてのプロシージャを順番に実行する必要があり、予期しない問題を処理するために各手順で余分な時間が必要であると想定します。
重要なフロー内のリソースのバックアップ 計画を定義および管理する
バックアップは、全体的な復旧プロセスの重要な部分です。 多くの場合、これは復旧が必要な環境の一部にすぎません。 DR プランは通常、アプリケーションまたはリージョン全体です。 データ、ファイルの破損、マルウェア、および標的型ランサムウェア攻撃の偶発的または悪意のある削除はすべて、ワークロードの可用性に影響を与える可能性があります。 環境の各部分に対して確実なバックアップ 計画を作成することは、効果的な DR プランを用意するのと同じくらい重要です。DR プランは、効果的な確実なバックアップ計画に依存するためです。 DR プランと同様に、バックアップ計画も適切なレベルの管理によって合意し、可能な更新のために定期的に再検討し、高可用性で安全なデータ ストアに文書化する必要があります。
ワークロード内の重要なパスの一部であるさまざまな Azure サービスに適したバックアップ ソリューションを決定します。
サービスごとに必要な保持期間を定義します。
1 つのツールがすべてでは機能しない可能性があることを理解してください。 Azure Backup ツールは、多くのリソースの種類をカバーできますが、すべてではありません。
特定の種類のオブジェクトを復元するための最適なオプションは、あるレベルの種類の高可用性リポジトリからの再デプロイである場合があります。 (Azure DevOps、GitHub など)
データ サービスには、アプリケーション関連のオブジェクトとは異なる要件があります。
リージョン間の回復可能性を作成するには、バックアップ データの複数リージョンストレージ戦略を検討してください。
バックアップ データの定期的なスケジュールされたテスト 復元を実行して、サービスが期待どおりに動作していることを確認します。
Azure ファシリテーション
多くの Azure 製品には、フェールオーバー機能が組み込まれています。 これらの機能を理解し、復旧手順に含めます。 DR 用のエンタープライズ データ資産の準備に関するガイダンスについては、 Azure データ プラットフォームシリーズ の DR を参照してください。
IaaS (サービスとしてのインフラストラクチャ) システムの場合は、 Azure Site Recovery を使用してフェールオーバーと復旧を自動化します。 一般的な PaaS 製品については、次の記事を参照してください。
多くの Azure 製品には、組み込みのバックアップ機能があります。 これらの機能を理解し、復旧手順に含めます。
IaaS (サービスとしてのインフラストラクチャ) システムの場合は、 Azure Backup を使用して、VM および VM 関連サービスと一部のデータ サービスのバックアップを容易にします。 一般的な製品については、次の記事を参照してください。
関連リンク
信頼性チェックリスト
完全なレコメンデーションのセットを参照してください。