概要
このシリーズでは、組織が Azure エンタープライズ データ プラットフォームのディザスター リカバリー (DR) 戦略を設計する方法の例を示します。
- この一連の記事は、Microsoft のクラウド導入フレームワーク、Azure Well-Architected Framework および Business Continuity Management によって提供されるガイダンスを補完します。
Azure には、障害発生時にサービス継続性を提供できるための広い範囲の回復性オプションが用意されています。 ただし、サービス レベルが高いほど、複雑さとコスト プレミアムが発生する可能性があります。 コスト、回復性、複雑さのトレードオフは、ほとんどのお客様にとって DR に関する重要な意思決定要因です。
Azure プラットフォーム全体で障害が発生することがありますが、Microsoft の Azure データセンターと Azure サービスには複数の冗長性レイヤーが組み込まれています。 障害は通常、スコープ内で制限され、通常は数時間以内に修復されます。 これまでは、ID 管理などの主要なサービスで、Azure リージョン全体がオフラインになるのではなく、サービスの問題が発生する可能性がはるかに高くなります。
また、サイバー攻撃 (特にランサムウェア) は、現代のあらゆるデータ エコシステムにとって具体的な脅威であり、データ プラットフォームの停止につながる恐れがあることを認識する必要があります。 これは本シリーズの対象外ですが、お客様には、どのようなデータ プラットフォームでも必要なセキュリティと回復性のための設計の一環として、このような攻撃に対する制御を実装することをお勧めします。
- ランサムウェア対策に関する Microsoft のガイダンスは、Azure の Cloud の基礎に関する記事でご覧いただけます
範囲
本連載の対象範囲は次のとおりです。
- お客様のペルソナを想定した、物理的な災害からの Azure データ プラットフォームのサービス復旧。 一例となるお客様は次のとおりです。
- ITIL (Information Technology Infrastructure Library) ベースのサービス管理手法に従って、運用サポート機能を定義した中規模の組織。
- クラウドネイティブではなく、コア エンタープライズでは、アクセスや認証管理、インシデント管理などの共有サービスがオンプレミスに残っています。
- Azure へのクラウド移行の過程で、自動化によって有効になります。
- Azure データ プラットフォームでは、顧客の Azure テナント内に次の設計が実装されています。
- エンタープライズ ランディング ゾーン – ネットワーク、監視、セキュリティなどのプラットフォーム基盤を提供します。
- Azure Analytics プラットフォーム - サービスによって提供されるさまざまなソリューションとデータ製品をサポートするデータ コンポーネントを提供します。
- この記事で説明するプロセスは、Azure の専門家 (SME) ではなく、Azure 技術リソースによって実行されます。 そのため、リソースには次のレベルの知識/スキルが必要です。
- Azure の基礎 – Azure、そのコア サービス、データ コンポーネントに関する実用的な知識。
- Azure DevOps に関する実用的な知識。 ソース管理内を移動し、パイプラインデプロイを実行できます。
- この記事で説明するこのプロセスでは、プライマリリージョンからセカンダリ リージョンへのサービス フェールオーバー操作について説明します。
対象範囲外
次の項目は、この記事シリーズの範囲外と見なされます。
- セカンダリ リージョンからプライマリ リージョンへのフォールバック プロセス。
- Azure 以外のアプリケーション、コンポーネント、またはシステム - これには、オンプレミス、他のクラウド ベンダー、サードパーティの Web サービスなどが含まれますが、これらに限定されません。
- これらのサービスへの依存関係に関係なく、オンプレミス ネットワーク、ゲートウェイ、エンタープライズ共有サービスなどのアップストリーム サービスの復旧。
- オンプレミスの運用システム、サード パーティのレポート システム、データ モデリングまたはデータ サイエンス アプリケーションなどのダウンストリーム サービスの復旧。これらのサービスへの依存関係に関係なく。
- ransomware または同様のデータ セキュリティ インシデントからの復旧を含む、データ損失のシナリオ
- データ バックアップ戦略とデータ復元計画
- DR イベントの根本原因の確立。
- Azure サービスまたはコンポーネントのインシデントに対して、Microsoft は [状態 - 履歴] Web ページ内で "根本原因分析" を発行します
主要な前提条件
この DR で動作する例の主な前提条件は次のとおりです。
- 組織は、Azure データ プラットフォームの運用サポートのための ITIL ベースのサービス管理手法に従います。
- 組織には、IT 資産のサービス復元フレームワークの一部として、既存のディザスター リカバリー プロセスがあります。
- コードとしてのインフラストラクチャ (IaC) は、Azure DevOps などの自動化サービスによって有効になっている Azure データ プラットフォームをデプロイするために使用されています。
- Azure データ プラットフォームによってホストされる各ソリューションは、ビジネス影響評価などを完了しており、復旧ポイント目標 (RPO)、目標復旧時間 (RTO)、平均復旧時間 (MTTR) メトリックに対する明確なサービス要件を提供します。
次のステップ
シナリオの概要を把握したので、ユース ケース用に設計されたアーキテクチャに関する学習に進むことができます。