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

得られた教訓

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

考慮事項

アンチ パターン

• この記事シリーズをコピーして貼り付けること この記事シリーズは、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 - まとめ