次の方法で共有

ディザスター リカバリーのためのアーキテクチャ戦略

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

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

災害は、ワークロードと運用チームによる慎重な計画と予防的な準備を必要とする重大なインシデントです。

この記事では、ディザスター リカバリーの主な戦略について説明し、回復力のあるワークロードの設計、データの整合性、およびフェールオーバーと復旧の明確に定義された目標を強調します。 ここでは、段階的な手順ではなく、DR の目的と指針の原則に焦点を当てています。 段階的なプロセスやプレイブックを含む詳細な実装ガイダンスについては、コンパニオン記事「 複数リージョンデプロイのディザスター リカバリー計画を作成する」を参照してください。

定義

任期 定義
アクティブ/パッシブ コールド スタンバイモード 障害が発生するまでセカンダリ リージョンにインフラストラクチャが最小限またはまったく実行されていない DR デプロイ パターン。フェールオーバー中に完全なデプロイが必要です。
アクティブ/パッシブ ウォーム スタンバイ セカンダリ リージョンに一部のインフラストラクチャが事前にデプロイされ、容量が減って実行されている DR デプロイ パターンにより、コールド スタンバイよりも高速なフェールオーバーが可能になります。
Backup 損失、破損、または障害が発生した場合にデータの回復を可能にするために、プライマリ システムとは別に格納されたデータのコピー
ビジネスの重要度 ワークロードまたはコンポーネントのビジネス運用の重要性に基づく分類。復旧の優先順位と投資レベルに影響を与えます。
DR アクティブ化基準 ディザスター リカバリー プロシージャを宣言してトリガーするタイミングを決定する定義済みのしきい値と条件。
DR ドリル ディザスター リカバリー手順をテストし、制御された条件下で復旧機能を検証するための計画された演習。
フェールバック 運用ワークロード トラフィックをフェールオーバー リージョンからプライマリ リージョンに自動または手動でシフトします。
フェールオーバー 使用できないリージョンから影響を受けない地理的リージョンへの運用ワークロード トラフィックの自動または手動シフト。
ポイントインタイム リストア 特定の時点にデータを復元する機能。通常は、データの破損や偶発的な変更から回復するために使用されます。
復旧時点目標 (RPO) 災害発生時に企業が許容できるデータ損失量を、時間で測定した最大許容範囲として定義します。
目標復旧時間 (RTO) 障害が発生した後にビジネス操作を復元できる最大許容時間。
同期レプリケーション 変更が複数の場所に同時に書き込まれるデータ レプリケーション。データ損失はゼロですが、待機時間が長くなる可能性があります。
非同期レプリケーション 変更が最初にプライマリの場所に書き込まれ、次にセカンダリの場所にコピーされるデータ レプリケーションにより、一部のデータ損失が可能になりますが、待機時間は短くなります。
作戦室 ディザスター リカバリー操作中に主要な担当者が調整する集中型の場所または通信チャネル。

ビジネスへの影響による優先順位付け

ミッション クリティカル、ビジネス クリティカル、ビジネス運用など、組織で定義された重要度レベルでワークロードを分類します。 各レベルが個別のレベルの投資、回復性、回復シーケンスを保証することを認識します。 ワークロードに重要度が異なる複数のフローまたはコンポーネントが含まれている場合は、イベント中のあいまいさを回避するために、それぞれの復旧アプローチを文書化します。

これらの重要度レベルは、適切な回復目標に影響します。 重要度の高いコンポーネントでは、より高速な回復とより頻繁なデータ保護が必要ですが、重要度の低いコンポーネントでは、復元の速度が低下する可能性があります。 これらの要件から、復旧の期待をビジネス価値と直接整合させる 明確な RTO および RPO ターゲットを導き出します。

災害のしきい値を定義する

チームとビジネスの利害関係者が、災害としてカウントされる内容とそうでないものを正確に理解していることを確認します。 戦略では、完全な災害、大規模な中断、迅速に修正できる小さな問題を区別する必要があります。 コンポーネントが失敗している場合にのみ、これを基にしないでください。 代わりに、問題がユーザーとビジネス全体に与える影響を考慮します。

小規模なインシデントと実際の DR 状況を分離するしきい値を定義したら、 それらを正常性モデルに組み込みます。 これにより、監視によって早期の警告の兆候を見つけることができ、適切な復旧プロセスがトリガーされます。

通信プロトコルを確立する

明確なコミュニケーションがないと、最適に設計されたディザスターリカバリープランでも機能しない可能性があります。 意思決定を行うユーザー、情報を得るユーザー、DR イベント中に情報がどのように流れるかを定義する明確なコミュニケーション戦略を構築します。

まず、ワークロード チーム内の役割と責任、および関係するすべての外部グループを概説します。 これには、災害の宣言、インシデントのクローズ、操作タスクの実行、テストと検証の実行、内部および外部の通信の管理、主要な振り返りまたは根本原因分析を行うための所有者が含まれている必要があります。

詳細な手順を提供し、すべての前提条件 (スクリプト、資格情報、構成など) を一覧表示し、チームとクラウド プロバイダーの間の責任を定義します。 繰り返し発生する障害を防ぐために、復旧を開始する前に根本原因の問題に対処してください。

部門間の戦争ルームを確立して、適切な人々が迅速に調整できるようにし、コミュニケーション チャネルとメッセージ テンプレートを事前に準備して、チームがプレッシャーを受けないようにします。

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

復旧対応アーキテクチャを設計する

ディザスター リカバリー プロセスは、ワークロードの設計方法を反映する必要があり、逆に、復旧要件が最初からアーキテクチャの決定に影響を与える必要があります。 システムを設計するときは、障害発生時に復旧する方法を検討し、復旧要件をサポートするパターン ( アクティブ/パッシブ コールド スタンバイ や アクティブ/パッシブ ウォーム スタンバイなど) を選択します。

データ復旧の場合は、RPO ターゲットに基づくレプリケーション戦略を使用します。 たとえば、優先度の高いデータの場合は可用性ゾーン間で同期し、優先順位が低いリージョン間では非同期です。 整合性モデルで復旧がサポートされていることを確認し、頻繁な完全バックアップとポイントインタイム リカバリーを実装し、データ ストア間の依存関係を考慮して、復旧中の整合性チェックを自動化します。

注

個々のコンポーネントの部分的なフェールオーバーを可能にするために、包含と分離を使用してワークロードを設計します。 これにより、複雑さ、コスト、RTO が削減され、完全な障害を宣言することなく部分的な可用性が維持される場合があります。 部分フェールオーバーを個別にテストし、トリガーするタイミングを文書化します。

インフラストラクチャと復旧の手順を準備する

セカンダリ リージョンを事前に準備します。 次のように、インシデントが発生したときにチームが準備できるようにチェックリストを作成します。

  • コンピューティング レイヤー: ウォーム アクティブ/パッシブ ワークロードの場合は、最小限のコンピューティング リソースを事前デプロイして迅速なフェールオーバーをサポートします。
  • ネットワーク インフラストラクチャ: VNet、サブネット、ルート、ファイアウォール、セキュリティ グループなどのトポロジをレプリケートし、すべての構成を確認します。
  • ID とアクセスの管理: アカウントのセットアップ、RBAC のアクセス許可、ポリシーを重複させ、運用環境と同じセキュリティ ベースラインを確保します。
  • 監視: 可視性用に構成されたアラートとダッシュボードを使用して監視インフラストラクチャをデプロイします。

復旧プロセスを階層化します。 コンポーネント レベル、データ資産レベル、およびワークロード レベルでの構造手順。 影響を最小限に抑えるための適切なシーケンスを定義します。 たとえば、データベースに依存するアプリケーションの前にデータベースを復元します。 ビジネスへの影響に基づいてスコープを定義します。 お客様の影響とコストを考慮して、運用環境と、必要に応じて非運用環境で DR カバレッジを必要とするかを決定します。

フェールバック戦略はフェールオーバーとは別に維持します。

リスク： フェールバックの必要性は状況によって異なります。たとえば、パフォーマンスのためにトラフィックがリージョン間で再ルーティングされた場合、元のリージョンに復元することが重要です。 それ以外の場合は、アクティブな環境に関係なく、ワークロードが完全に機能する場合があります。 フェールバックがフェールオーバーとは別の明確に定義されたプロセスとして扱われなければ、チームが混乱を経験し、不完全な復元や長時間のダウンタイムにつながる可能性があります。

そのリスクを軽減するには、フェールバック 計画を作成し、フェールオーバーからの手動の手順のミラーリングなど、DR 計画と同じ原則を使用してフェールバック計画を構築して維持します。 フェールバックはすぐに、または数日または数週間にわたって発生する可能性がありますが、別のプロセスとして扱います。

フェールオーバー後の作業を計画します。 フェールオーバー後に必要なすべてのタスク (DNS の更新、トラフィック ルーティング、接続文字列の調整など) をキャプチャして、ワークロードを完全にオンラインに戻します。

堅牢なバックアップ戦略を実装する

各 Azure サービスに合わせて調整されたバックアップ ソリューションを選択し、保有期間を定義し、すべてをカバーするツールが 1 つないことを認識します。 リージョン間の回復可能性を確保するためにマルチリージョン ストレージを検討し、一部のリソースでは高可用性リポジトリからの再デプロイを使用します。 定期的に復元をテストしてバックアップを検証し、計画を定期的に確認および更新し、安全に保存し、関連するチームがアクセスできるようにします。

定期的にドリルを行う

DR 計画は、現実的な条件下で検証された場合にのみ意味があります。 エッジ ケースを含む複数のシナリオをテストし、スケジュールされたドリルと驚きのゲーム日を組み合わせて、システムとチームがプレッシャーの下でどのように対応するかを確認します。

DR プランには、テーブルトップ演習の手順と周期、非運用環境でのドライ ラン、および生産レベルのドリルを含めます。 Tabletop ドリルは、チームの役割の練習、知識の構築、新しいメンバーのトレーニングに役立ちますが、運用環境の訓練は、実際の条件で計画が RTO と RPO の目標を満たしていることを確認する唯一の方法です。 DNS 伝達など、制御外のプロセスの場合は、復旧時間を評価するときに潜在的な遅延を検証します。

リスク： 運用環境で DR ドリルを直接実行すると、予期しない重大な障害が発生する可能性があります。 運用環境で訓練を実行する前に、まず非運用環境で復旧手順をテストして安全性を検証し、問題を明らかにします。

全体的な DR ポスチャを改善するために、テスト結果を入力として扱うプロセスを配置します。 たとえば、新しい演算子がためらっている場合は、その手順を確認して、明確に記述されていることを確認します。

完全な DR ドリルとは別に、全体的な RTO レベルとコンポーネント レベルの RTO と RPO の両方をテストおよび検証します。 ターゲットを確実に達成できるように、リージョン間でのデータの移動やコールド ストレージからの復元などのシナリオを含めます。

プランを最新の状態に保ち、実行可能にする

DR 計画を生きたドキュメントとして扱います。 環境の変化に合わせて計画を進化させ、関連するすべてのチーム、運用、テクノロジ リーダーシップ、ビジネス利害関係者と定期的にレビューする必要があります。理想的には 6 か月ごとです。

障害発生時のシステムの動作と対応方法を把握し、DR 計画を FMA ドキュメントに合わせて維持します。 新しい障害ケースを検出したら、テスト、監視、または実際のインシデントを通じて、それらを含むように計画を更新します。 環境が変更またはテストによって予期しない動作が明らかになった場合は常に、DR プランと FMA ドキュメントの両方が更新されていることを確認します。

時間の経過に伴ってプロシージャを絞り込みます。 DR プラクティスの初期段階では、各プロシージャを順番に実行し、予期しない問題に対して余分な時間を割く必要があると仮定します。 DR プラクティスが成熟したら、どのステップを安全に並列実行できるかを特定します。 アーキテクチャの変更を反映するように改良する必要があります。 ワークロード アーキテクチャが変更されるたびに、DR プランを更新して、アクティブ化基準または復旧プロセスに対する調整を明確に定義します。

現実的な復旧時間を計画します。 訓練をスケジュールする際の復旧手順に必要な最小時間として、テストからのメトリックを使用します。

障害発生時のアクセシビリティを確保する

ディザスター リカバリーは、計画と実行に必要なツールの両方が、すべての障害条件下で使用可能なままである場合にのみ成功します。

ディザスター リカバリーのドキュメント、スクリプト、および復旧コンポーネントを高可用性で安全な場所に保存し、リージョンの障害時でもアクセスできるようにします。 プラン、資格情報、証明書、スクリプトなど、すべての DR 資産を保護し、リージョン間でレプリケートします。 最悪のシナリオでは、オフラインまたは印刷されたコピーを維持します。 必要に応じてすぐに実行できるように、すべてのリージョンに CI/CD パイプラインを事前デプロイします。

復旧手順を安全に自動化する

可能な限りフェールオーバー環境でのデプロイと復旧の手順を自動化し、RTO ターゲットを確実に満たします。 信頼性を確保するために宣言型のべき等スクリプトを使用し、カスタムコードには再試行ロジックやサーキットブレーカーロジックといったセーフガードを構築します。 DevOps パイプラインを事前デプロイして構成し、必要な場合にのみ手動承認ゲートで自動化されたエンド ツー エンド プロセスを使用して、デプロイをすぐに開始できるようにします。 デプロイタイムラインが復旧ターゲットと一致していることを確認します。

必要に応じて手動承認を適用し、速度と制御のバランスを取ります。 手動の手順が必要な場合は、それらを明確に文書化し、ロールと責任を定義します。

リスク： 自動化はリスクを伴います。 自動化を使用する場合でも、トレーニング済みのオペレーターは復旧プロセスを監視し、問題が発生した場合は介入する必要があります。 完全な DR ドリルを使用して、すべてのフェーズをテストし、復旧ターゲットを検証し、フェールオーバーのしきい値を調整して誤検知のリスクを軽減します。

Azure ファシリテーション

多くの Azure 製品には、フェールオーバー機能が組み込まれています。 これらの機能を理解し、復旧手順に含めます。 DR 用のエンタープライズ データ資産の準備に関するガイダンスについては、 Azure データ プラットフォームシリーズ の DR を参照してください。

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

多くの Azure 製品には、組み込みのバックアップ機能があります。 これらの機能を理解し、復旧手順に含めます。

IaaS (サービスとしてのインフラストラクチャ) システムの場合は、 Azure Backup を使用して、VM および VM 関連サービスと一部のデータ サービスのバックアップを容易にします。 一般的な製品については、次の記事を参照してください。

信頼性チェックリスト

完全なレコメンデーションのセットを参照してください。

信頼性チェックリスト

  • Last updated on