編集

次の方法で共有

Azure データ プラットフォームの DR - アーキテクチャ

Azure Synapse Analytics
Azure Machine Learning
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs

ユース ケースの定義

この事例では、Microsoft のリファレンス アーキテクチャに基づいて、架空の企業 "Contoso" を Azure データ プラットフォームで使用します。

データ サービス - コンポーネント ビュー

Contoso は、以下の基本的な Azure 構造を導入しています。これはエンタープライズ ランディング ゾーンのサブセットです。 エンタープライズ Azure ランディング ゾーンの例を示す図。

以下の説明の数値は、上の図の数値に対応しています。

Contoso の Azure Foundations - ワークフロー

  1. マイクロソフトエンタープライズ加入契約 – Azure における Contoso の最上位の親エンタープライズ加入契約。Microsoft との商業契約、組織アカウント構造、使用可能な Azure サブスクリプションが反映されています。 サブスクリプションの課金基盤と、デジタル資産の管理方法は、ここから提供されます
  2. ID およびアクセス管理 – Contoso の Azure フットプリント全体の ID、認証、リソース アクセス、認可サービスを提供するために必要なコンポーネント
  3. 管理グループとサブスクリプションの編成 - データ プラットフォームのコア機能に合わせたスケーラブルなグループ階層。ワークロードが明確に分離されている一元管理されたセキュリティとガバナンスを使用することで、大規模な運用化が可能となります。 管理グループはサブスクリプションの上のガバナンス スコープを提供します
  4. 管理サブスクリプション - データ プラットフォームをサポートするために必要なさまざまな管理レベル機能のための専用サブスクリプション
  5. 接続サブスクリプション - データ プラットフォームの接続機能のための専用サブスクリプションで、データ プラットフォームが指定されたサービスを識別し、内部と外部のサービス全体にわたる、あるいは内部と外部サービス間の安全なルーティングおよび通信を決定することを可能にします
  6. ランディング ゾーン サブスクリプション – Azure ネイティブ、オンライン アプリケーション、内部および外部に接するワークロードとリソースのための一対多サブスクリプション
  7. DevOps プラットフォーム – Azure の基盤とデータ プラットフォームをサポートする DevOps プラットフォーム。 このプラットフォームには、コードとしてのインフラストラクチャ (IaC) の自動デプロイを可能にするコード ベースソース管理リポジトリと CI/CD パイプラインが含まれています。

Note

多くのお客様は、依然として大規模なサービスとしてのインフラストラクチャ (IaaS) フットプリントを保持しています。 IaaS 全体の復旧機能を実現するために追加すべき重要なコンポーネントは Azure Site Recovery です。 Site Recovery は、Azure VM のリージョン間レプリケーション、オンプレミスの仮想マシンと物理サーバーの Azure へのレプリケーション、セカンダリ データセンターへのオンプレミス マシンのレプリケーションを調整および自動化します。

この基本構造の中で、Contoso はそのエンタープライズ ビジネス インテリジェンスのニーズをサポートするために、「Azure Synapse を使用した分析のエンド ツー エンド」のガイダンスに沿って、次の要素を実装しました。

Azure Data Services を使用した最新のデータ プラットフォームを示すアーキテクチャ図。Contoso のデータ プラットフォーム

Contoso のデータ プラットフォーム - ワークフロー

ワークフローは、データの流れに従って左から右に進みます。

  • データ ソース - データ プラットフォームに取り込むことができるデータのソースまたは種類
  • 取り込み - 構造と速度が異なる各種ソースからデータを取り込むことができるプラットフォームの機能。 この設計にはラムダ アーキテクチャが反映されています
  • ストア - プラットフォームに取り込まれた大規模なデータを安全に格納する機能。
  • プロセス - クレンジング、標準化、モデリングなど、ダウンストリームのプロセスの "用途に合う" ようにデータを処理するプラットフォームの機能。 データが "使用可能な位置と状態にあること" は、通常、データの前処理によって保証されます。
  • エンリッチ - プラットフォーム上で処理されたデータを、統計や機械学習などのモデリング手法、または既製の Azure AI サービスを用いて補う機能。
  • 提供 - ダウンストリームで利用できるようプラットフォームがデータを整形して提示する機能。
  • データ コンシューマー - プラットフォームのさまざまな接点から提供されたデータを利用する人やアプリケーション、またはダウンストリーム プロセス。
  • 検出とガバナンス - プラットフォームがそこに格納されているデータを管理し、インデックスが作成済みであることや、検出可能/検索可能であること、説明が適切で完全な系列を含んでいること、データを利用するプロセスやエンド ユーザーに対して透明性があることを保証する機能。
  • プラットフォーム - プラットフォームの基盤、つまり Contoso の Azure Foundations (前述の説明を参照)。

Note

多くのお客様にとって、使用するデータ プラットフォームのリファレンス アーキテクチャが概念レベルで一致していても、物理的な実装は異なる場合があります。 たとえば、ELT (抽出、読み込み、変換) プロセスは Azure Data Factory を通して、データ モデリングは Azure SQL サーバーによって実行される場合があります。 ステートレスとステートフルの違いについて述べた後続のセクションで、この問題に対処するためのガイダンスを提供します。

データ プラットフォームに関して、Contoso では、すべてのコンポーネントで推奨される運用サービス レベルを選択しています。また、ディザスター リカバリー (DR) 戦略としては、運用コストが最小となるアプローチに基づき、"災害発生時の再デプロイ" を採用することにしました。

以降の各セクションでは、この体制をアップリフトしたいと考えるお客様のために、DR プロセスの基礎的な知識と力の入れどころについて取り上げます。

Azure サービスとコンポーネント ビュー

以下の表は、Contoso 全体で使用される個々の Azure サービスとコンポーネント (データ プラットフォーム) の内訳を、DR アップリフトのための選択肢と併せて示したものです。

Note

以降の各セクションは、ステートフル サービスとステートレス サービス別に整理されています

ステートフルの基本コンポーネント

  • ロールのエンタイトルメントを含む Microsoft Entra ID

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: Premium P1
    • DR アップリフト オプション: Microsoft Entra の回復性は、サービスとしてのソフトウェア (SaaS) オファリングの一部です
    • 注

  • Azure Key Vault

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • Recovery Services コンテナー

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso SKU の選択: 既定 (geo 冗長ストレージ (GRS))
    • DR アップリフト オプション: リージョンをまたがる復元を有効にすると、セカンダリ (ペア リージョン) に復元データが作成されます
    • 注
      • ローカル冗長ストレージ (LRS) とゾーン冗長ストレージ (ZRS) を使用できますが、既定の設定からの構成アクティビティが必要です

  • Azure DevOps

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: DevOps サービス
    • DR アップリフト オプション: DevOps サービスとデータの回復性は、その SaaS オファリングに含まれます
    • 注
      • オンプレミス オファリングとしての DevOps Server は、ディザスター リカバリーをお客様の責任で行う必要があります
      • サード パーティ サービス (SonarCloud、Jfrog Artifactory、Jenkins ビルド サーバーなど) が使用されている場合、ディザスター リカバリーはお客様の責任で行う必要があります
      • DevOps ツールチェーン内で IaaS VM が使用されている場合、ディザスター リカバリーはお客様の責任で行う必要があります

ステートレスの基本コンポーネント

  • サブスクリプション

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • 管理グループ

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • Azure Monitor

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • Cost Management

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • Microsoft Defender for Cloud

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • Azure DNS

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: 単一ゾーン - パブリック
    • DR アップリフト オプション: N/A (DNS は高可用性が確保されるように設計されています)

  • Network Watcher

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • サブネット、ユーザー定義ルート (UDR) およびネットワーク セキュリティ グループ (NSG) を含む仮想ネットワーク

  • Azure Firewall

    • コンポーネントの復旧責任: Contoso
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: Standard
    • DR アップリフト オプション: Azure Firewall は高可用性が確保されるように設計されていますが、可用性ゾーンを使って作成することで可用性をさらに高めることができます

  • Azure DDoS

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: DDoS ネットワーク保護
    • DR アップリフト オプション: N/A (Azure サービスに含まれます)

  • ExpressRoute 回線

    • コンポーネントの復旧責任: Contoso、接続パートナー、Microsoft
    • ワークロード/構成の復旧責任: 接続パートナーと Microsoft
    • Contoso の SKU の選択: Standard
    • DR アップリフト オプション:
    • 注
      • ExpressRoute 回線には冗長性が組み込まれていて、各回線は、接続プロバイダーまたはクライアントのネットワーク エッジから、ExpressRoute の場所にある 2 つの Microsoft Enterprise エッジ ルーター (MSEE) への 2 つの接続で構成されます。
      • ExpressRoute Premium 回線を使用すると、すべての Azure リージョンにグローバルにアクセスできるようになります

  • VPN Gateway

    • コンポーネントの復旧責任: Contoso
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: 単一ゾーン - VpnGw1
    • DR アップリフト オプション: VpnGw#AZ SKU を使用して可用性ゾーンに VPN ゲートウェイをデプロイして、ゾーン冗長サービスを提供できます

  • Azure Load Balancer

    • コンポーネントの復旧責任: Contoso
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: Standard
    • DR アップリフト オプション:
    • 注
      • Azure Traffic Manager は、DNS ベースのトラフィック ロード バランサーです。 このサービスでは、パブリックに公開されているアプリケーションのトラフィックをグローバル Azure リージョン全体に分散することがサポートされます。 このソリューションは、高可用性の設計範囲内におけるリージョンの停止からの保護を提供します

ステートフル データ プラットフォーム固有のサービス

  • ストレージ アカウント: Azure Data Lake Gen2

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: LRS
    • DR アップリフト オプション: ストレージ アカウントには、プライマリ リージョンの冗長性からセカンダリ リージョンの冗長性まで、幅広いデータ冗長性オプションがあります
    • 注
      • ペア リージョンにデータをコピーすることによって冗長性を高めるには、GRS が推奨されます

  • Azure Event Hubs

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: Standard
    • DR アップリフト オプション: 可用性ゾーンを有効にしてイベント ハブの名前空間を作成できます。 この回復性を拡張し、geo ディザスター リカバリーでリージョン全体の障害をカバーできます
    • 注
      • 設計上、Event Hubs の geo ディザスター リカバリーではデータがレプリケートされないため、フェールオーバーとフォールバックに関して留意すべき考慮事項がいくつかあります

  • Azure IoT Hub

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: Standard
    • DR アップリフト オプション:
    • 注
      • IoT Hub は、データを各 IoT ハブのペア リージョンにレプリケートすることで、Microsoft が開始するフェールオーバーと手動フェールオーバーを提供します
      • IoT Hub にはリージョン内 HA が用意されており、定義済みの一連の Azure リージョン内に可用性ゾーンが作成されていれば、自動的にそれが使用されます

  • Azure Stream Analytics

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: Standard
    • DR アップリフト オプション: Azure Stream Analytics はフル マネージドのサービスとしてのプラットフォーム (PaaS) オファリングですが、自動 geo フェールオーバーは提供されません。 geo 冗長性は、複数の Azure リージョンに同じ Stream Analytics ジョブをデプロイすることで実現できます

  • Azure Machine Learning

  • Power BI

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: Power BI Pro
    • DR アップリフト オプション: N/A (Power BI の回復性は、その SaaS オファリングに含まれます)
    • 注

  • Azure Cosmos DB

  • Azure Data Share

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: N/A
    • DR アップリフト オプション: Azure Data Share の回復性は、セカンダリ リージョンへの HA デプロイによって高めることができます

  • Microsoft Purview

ステートレス データ プラットフォーム固有のサービス

  • Azure Synapse: パイプライン

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: コンピューティング最適化 Gen2
    • DR アップリフト オプション: 該当なし。Synapse 回復性は、自動フェールオーバー機能を使用する SaaS オファリングの一部です
    • 注
      • セルフホステッド データ パイプラインが使用されている場合、ディザスター リカバリーはお客様の責任で行う必要があります

  • Azure Synapse: Data Explorer プール

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: コンピューティング最適化、Small (4 コア)
    • DR アップリフト オプション: N/A (Synapse の回復性は、その SaaS オファリングに含まれます)
    • 注
      • Availability Zones は、Synapse Data Explorer に対して使用可能な場合には既定で有効になっています。

  • Azure Synapse: Spark プール

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: コンピューティング最適化、Small (4 コア)
    • DR アップリフト オプション: N/A (Synapse の回復性は、その SaaS オファリングに含まれます)
    • 注

  • Azure Synapse: サーバーレスおよび専用 SQL プール

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Contoso
    • Contoso の SKU の選択: コンピューティング最適化 Gen2
    • DR アップリフト オプション: N/A (Synapse の回復性は、その SaaS オファリングに含まれます)
    • 注
      • Azure Synapse Analytics では、終日スナップショットが自動的に取得され、7 日間利用できる復元ポイントが作成されます
      • Azure Synapse Analytics によって、1 日に 1 回、ペアになっているデータセンターに対して標準の geo バックアップが実行されます。 geo リストアの目標復旧時点 (RPO) は 24 時間です
      • セルフホステッド データ パイプラインが使用されている場合、ディザスター リカバリーはお客様の責任で行う必要があります

  • Azure AI サービス (旧称 Cognitive Services)

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: プリペイド
    • DR アップリフト オプション: N/A (AI サービス の API は、Microsoft が管理するデータ センターによってホストされます)
    • 注
      • お客様がデプロイした Docker コンテナーを使用して AI サービス がデプロイされている場合、復旧はお客様の責任で行う必要があります

  • Azure AI Search (旧称 Azure Cognitive Search)

    • コンポーネントの復旧責任: Microsoft
    • ワークロードと構成の復旧責任: Microsoft
    • Contoso の SKU の選択: Standard S1
    • DR アップリフト オプション:
    • 注
      • AI Search では、ビジネス継続性 (およびディザスター リカバリー) が複数の AI Search サービスによって実現されます。
      • ディザスター リカバリーのための組み込みのメカニズムはありません。 壊滅的災害の際にサービスを継続する必要がある場合は、別のリージョンに 2 番目のサービスを用意し、geo レプリケーション戦略を導入して、インデックスがすべてのサービスで完全に冗長になるようにすることをお勧めします。

ステートフル コンポーネントとステートレス コンポーネント

特に Microsoft 製品スイートと Azure は頻繁にイノベーションが起こるので、この事例に使用したコンポーネント セットも急速に進化することが考えられます。 将来的に古くなったガイダンスを提供しないため、またこの文書で明示的にカバーされていない領域にも対応するために、以下のセクションに記載したいくつかの手引きは、大まかな状態の分類に基づいています。

過去のイベントやユーザー インタラクションを記憶する設計になっているコンポーネントやサービスは、"ステートフル" と表現される場合があります。 "ステートレス" とは、以前のインタラクションの記録が存在せず、個々のインタラクション要求は、それに付随する情報のみに基づいて処理されなければならないことを意味します。

再デプロイが必要な DR シナリオの場合:

  • Azure Functions や Azure Data Factory のパイプラインのように "ステートレス" なコンポーネントやサービスは、広範なシステムに導入する前に、少なくとも可用性を検証するためのスモーク テストを行い、ソース管理から再デプロイできます
  • Azure SQL データベースやストレージ アカウントなどの "ステートフル" なコンポーネントやサービスには、さらに注意が必要です
    • コンポーネントを調達する際の重要な決定はデータ冗長機能の選択です。 この決定で最も重要となるのは、通常、運用コストを伴う可用性と持続性のトレードオフです
  • データストアには、データ バックアップ戦略も必要です。 基になるストレージのデータ冗長性機能により、一部の設計ではこのリスクが軽減されますが、他の設計、たとえば SQL データベースでは、別のバックアップ プロセスが必要になります。
    • 必要に応じて、コンポーネントはスモーク テストを通して検証済みの構成を使用して、ソース管理から再デプロイできます
    • 再デプロイされたデータストアは、そのデータセットをリハイドレートする必要があります。 リハイドレートは、データ冗長 (使用可能な場合) またはバックアップ データセットを使用して実現できます。 リハイドレートが完了したら、正確性と完全性を検証する必要があります
      • バックアップ プロセスの性質によっては、バックアップ データセットを適用する前に検証が必要になる場合があります。 バックアップ プロセスの破損またはエラーにより、利用可能な最新のバージョンではなく、以前のバックアップが使用される可能性があります
    • コンポーネントの日付/タイムスタンプと現在の日付との間に差がある場合は、その時点からデータ インジェスト プロセスを再実行または再生することによって対処する必要があります
    • コンポーネントのデータセットが最新の状態になったら、広域システムに導入できます

その他の主要サービス

このセクションには、他の主要な Azure データ コンポーネントとサービスに関する HA/DR ガイダンスが含まれています。

次のステップ

シナリオのアーキテクチャについて説明しました。次は、シナリオの詳細について確認しましょう