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