Azure データ プラットフォームの DR - 推奨事項

得られた教訓

1. 高可用性 (HA) とディザスター リカバリー (DR) の違いを関係者全員が理解していることを確認します。一般的な落とし穴は、2 つの概念を混同し、関連するソリューションを一致させることです。
2. 目標復旧時点 (RPO) と目標復旧時間 (RTO) を定義するために、次の側面に関する期待値についてビジネス利害関係者と話し合います。
   1. 通常、復旧が速いほどコストが高いことを念頭に置いて、許容できるダウンタイムの量。
   2. 保護対象のインシデントの種類。そのような事態に関連する確率にも言及します。 たとえば、サーバーがダウンする確率は、リージョン全体のすべてのデータセンターに影響を与える自然災害よりも高くなります。
   3. 使用できないシステムがビジネスに与える影響
   4. 今後のソリューションの OPEX 予算。
3. エンド ユーザーに受け入れられるサービスの低下オプションを検討します。 これには、次のものが含まれます。
   1. 最新のデータがなくても、視覚化ダッシュボードに引き続きアクセスできます。つまり、インジェスト パイプラインが機能しない場合でも、エンド ユーザーはデータにアクセスできます。
   2. 読み取りアクセス権はありますが、書き込みアクセス権がありません。
4. 目標とする RTO と RPO のメトリックにより、実装するディザスター リカバリー方法の選択が決まることがあります。
   1. アクティブ/アクティブ。
   2. アクティブ/パッシブ。
   3. 障害発生時のアクティブ/再デプロイ。
   4. 許容できるダウンタイムを考慮するには、独自の複合 SLO を検討してください。
5. 次のような、システムの可用性に影響を与える可能性があるすべてのコンポーネントを理解していることを確認します。
   1. ID 管理。
   2. ネットワーク トポロジ。
   3. シークレット/キー管理。
   4. データ ソース:
   5. オートメーション/ジョブ スケジューラ。
   6. ソース リポジトリとデプロイ パイプライン (GitHub、Azure DevOps)。
6. 停止の早期検出も、RTO と RPO の値を大幅に減少させる方法です。 対象にする必要があるいくつかの側面を次に示します。
   1. 停止とは何か、および Microsoft の停止の定義にどのようにマップされるかを定義します。 Microsoft の定義は、製品またはサービス レベルの Azure サービス レベル アグリーメント (SLA) ページで確認できます。
   2. これらのメトリックとアラートをタイムリーにレビューするための、責任あるチームを備えた効率的な監視とアラートのシステムは、目標を達成するのに役立ちます。
7. サブスクリプションの設計に関しては、ディザスター リカバリー用の追加のインフラストラクチャを元のサブスクリプションに格納できます。 ADLS Gen2 や Azure Data Factory などのサービスとしてのプラットフォーム (PaaS) サービスには、通常、元のサブスクリプションに含まれたままで、他のリージョンのセカンダリ インスタンスにフェールオーバーできるネイティブ機能があります。 一部のお客様は、コスト目的で DR シナリオでのみ使用されるリソース用の専用リソース グループを用意することを検討することをお勧めします。
   1. サブスクリプションの制限は、このアプローチの制約になる可能性があることに注意する必要があります。
   2. その他の制約には、DR リソース グループが BAU ワークフローに使用されないようにするための設計の複雑さと管理コントロールが含まれる場合があります。
8. ソリューションの重要度と依存関係に基づいて DR ワークフローを設計します。 たとえば、データ ウェアハウスが起動して実行される前に、Azure Analysis Services インスタンスを再構築しようとしないでください。エラーが発生するためです。 プロセスの後半で開発ラボを終了し、最初にコア エンタープライズ ソリューションを回復します。
9. ソリューション間で並列化できる復旧タスクを特定して、RTO の合計を減らしてみてください。
10. Azure Data Factory がソリューション内で使用されている場合は、セルフホステッド統合ランタイムを範囲に含めるのを忘れないでください。 Azure Site Recovery はこれらのマシンに最適です。
11. 人為的なミスを避けるため、特に負荷が大きい場合、手動操作を可能な限り自動化する必要があります。 次のことをお勧めします。
    1. Bicep、ARM テンプレート、または PowerShell スクリプトを使用してリソース プロビジョニングを採用する。
    2. ソース コードとリソース構成のバージョン管理を採用する。
    3. クリック操作ではなく、CI/CD リリース パイプラインを使用します。
12. フェールオーバーの計画がある場合は、プライマリ インスタンスにフォールバックする手順を検討する必要があります。
13. 明確なインジケーターとメトリックを定義して、フェールオーバーが成功し、ソリューションが稼働しているか、状況が正常 (プライマリ機能とも呼ばれます) に戻っていることを検証します。
14. フェールオーバー後もサービス レベル アグリーメント (SLA) を同じままにするか、サービスの機能低下を許可するかを決定します。
    1. この決定は、サポートされているビジネス サービス プロセスに大きく依存します。 たとえば、部屋予約システムのフェールオーバーは、コア運用システムとは大きく異なります。
15. RTO/RPO 定義は、インフラストラクチャ レベルではなく、特定のユーザー シナリオに基づいている必要があります。 これにより、障害や障害が発生した場合に最初に復旧する必要があるプロセスとコンポーネントの粒度が高くなります。
16. フェールオーバーを進める前に、ターゲット リージョンに容量チェックを含める必要があります。大きな障害が発生した場合は、多くのお客様が同じペアリージョンに同時にフェールオーバーしようとするため、リソースのプロビジョニングに遅延や競合が発生する可能性があることに注意してください。
    1. これらのリスクが許容できない場合は、アクティブ/アクティブ/パッシブ DR 戦略を検討する必要があります。
17. ディザスター リカバリー計画を作成して保守し、復旧プロセスとアクションを行う人を文書化する必要があります。 担当者が休暇中の可能性もあるため、セカンダリ連絡先を含めるようにしてください。
18. DR 計画ワークフローを検証し、必要な RTO/RPO を満たし、責任あるチームをトレーニングするために、定期的なディザスター リカバリー訓練を実行する必要があります。
    1. データと構成の予備も定期的に検査して、復旧アクティビティをサポートする "目的に適合している" ことを確認する必要があります。
19. ネットワーク、ID、リソースのプロビジョニングを担当するチームとの早期コラボレーションにより、次に関する最も最適なソリューションに関する合意が可能になります。
    1. プライマリからセカンダリのサイトにユーザーとトラフィックをリダイレクトする方法。 DNS リダイレクトや、 Azure Traffic Manager などの特定のツールの使用などの概念 評価できます。
    2. セカンダリ サイトへのアクセス権と権限を、タイムリーかつ安全な方法で提供する方法。
20. 災害発生時には、関係する多くの当事者間の効果的なコミュニケーションが、計画を効率的かつ迅速に実行するための鍵となります。 Teams には次のものが含まれる場合があります。
    1. 意思 決定。
    2. インシデント対応チーム。
    3. 影響を受ける内部ユーザーとチーム。
    4. 外部チーム。
21. 適切なタイミングでさまざまなリソースをオーケストレーションすることで、ディザスター リカバリー 計画の実行効率が確保されます。

考慮事項

アンチパターン

• この記事シリーズをコピーして貼り付けます この記事シリーズは、Azure 固有の DR プロセスの次のレベルの詳細を探しているお客様にガイダンスを提供することを目的としています。 このため、単一の顧客固有の Azure 実装ではなく、一般的な Microsoft IP と参照アーキテクチャに基づいています。

提供される詳細は、強固な基礎知識をサポートするのに役立ちますが、"目的に適合している" DR 方法とプロセスを取得するには、お客様独自のコンテキスト、実装、および要件をあてはめる必要があります。

• DR を技術専用プロセスとして扱うこと ビジネス利害関係者は、DR の要件を定義し、サービスの復旧を確認するために必要なビジネス検証手順を実行する上で重要な役割を果たします。 ビジネス利害関係者がすべての DR アクティビティに関与するようにすると、"目的に適合していて"、ビジネス価値を表し、実行可能な DR プロセスがもたらされます。

• DR プランを "設定して忘れること" Azure は、個々のお客様によるさまざまなコンポーネントとサービスの使用状況と同様、絶えず進化しています。 "目的に適合している" DR プロセスは、それらとともに進化する必要があります。 SDLC プロセスまたは定期的なレビューにより、お客様が DR プランを定期的に見直す必要があります。 目標は、サービス復旧プランの有効性と、コンポーネント、サービス、またはソリューション間の差分が把握されていることを確認することです。

• 紙ベースの評価 DR 時のエンドツーエンドのシミュレーションは最新のデータ エコシステムでは困難ですが、影響を受けるコンポーネント全体での完全なシミュレーションに可能な限り近づける努力をする必要があります。 定期的にスケジュールされている訓練により、組織が自信を持って DR 計画を実行することができるために要求される "身体で覚える" ことが実現されます。

• すべての実行を Microsoft に依存すること Microsoft Azure サービス内には、使用されるクラウド サービス レベルによって固定された明確な責任の分担があります。フル SaaS スタックが使用されている場合でも、Azure サービスとの対話に使用されるデバイスとともに、アカウント、ID、およびデータが正しい/最新であることを確認する作業は、引き続きお客様が担当します。

イベントの範囲と方法

災害イベントの範囲

イベントによって影響範囲が異なるため、応答が異なります。 次の図は、災害イベントについてこのことを示しています。

災害への対処方法のオプション

ディザスター リカバリー方法には、次の 4 つのおおまかなオプションがあります。

• Microsoft を待機する - 名前が示すように、Microsoft によって影響を受けたリージョンのサービスの復旧が完了するまで、ソリューションがオフラインになります。 復旧されると、ソリューションは顧客によって検証され、サービスの復旧のために最新の状態に更新されます。
• 障害発生時に再デプロイする - ソリューションは、障害発生後のイベントを最初から使用可能なリージョンに手動で再デプロイします。
• ウォーム スペア (アクティブ/パッシブ): セカンダリ ホステッド ソリューションが代替リージョンに作成され、最小のキャパシティを保証するためにコンポーネントが配置されます。ただし、このコンポーネントは運用環境のトラフィックを受信しません。 代替リージョンのセカンダリ サービスは、DR イベントが発生するまで、"オフ" であるか、パフォーマンス レベルが低い状態で実行される場合があります。
• ホット スペア (アクティブ/アクティブ) - ソリューションは、複数のリージョンにわたるアクティブ/アクティブ セットアップでホストされます。 セカンダリ ホステッド ソリューションは、大規模なシステムの一部としてデータを受信、処理、および処理します。

DR 方法の影響

多くの場合、サービスの回復性を高いレベルにすることによる運用コストが、DR 方法の主要な設計上の決定 (KDD) を主導しますが、 他にも重要な考慮事項があります。

この作業例の DR シナリオは、Contoso のデータ プラットフォームをホストするプライマリ リージョンに直接影響を与える Azure リージョンの完全な停止です。 この停止シナリオでは、4 つのおおまかな DR 方法への相対的な影響は次のとおりです。

"分類キー"

• 目標復旧時間 (RTO): ディザスター イベントからプラットフォーム サービスの復旧までの予想経過時間。
• 実行の複雑さ: 組織が復旧アクティビティを実行する複雑さ。
• 実装の複雑さ: DR 戦略を実装する組織の複雑さ。
• 顧客への影響: DR 戦略からのデータ プラットフォーム サービスの顧客への直接的な影響。
• 上記の OPEX コスト: 追加のコンポーネントやサポートに必要な追加リソースに対する Azure の毎月の課金の増加など、この戦略を実装することで予想される追加コスト。

次のステップ

シナリオに関連する推奨事項について学習したので、このシナリオを配置する方法について学習できます

関連リソース

• Azure データ プラットフォームの DR - 概要
• Azure データ プラットフォームの DR - アーキテクチャ
• Azure データ プラットフォームの DR - シナリオの詳細
• Azure データ プラットフォームの DR - まとめ