ユース ケースの定義
この事例では、Microsoft のリファレンス アーキテクチャに基づいて、架空の企業 "Contoso" を Azure データ プラットフォームで使用します。
データ サービス - コンポーネント ビュー
Contoso は、 Enterprise ランディング ゾーン 設計のサブセットである、次の基本的な Azure アーキテクチャを実装しました。
以下の説明の数値は、上の図の数値に対応しています。
Contoso の Azure Foundations - ワークフロー
- エンタープライズ登録 - Microsoft との商用契約、組織のアカウント構造、使用可能な Azure サブスクリプションを反映した、Azure 内での Contoso の上位の親エンタープライズ登録。 サブスクリプションの課金基盤と、デジタル資産の管理方法は、ここから提供されます。
- ID とアクセスの管理 – Contoso の Azure 資産全体で ID、認証、リソース アクセス、承認サービスを提供するために必要なコンポーネント。
- 管理グループとサブスクリプションの組織 - データ プラットフォームのコア機能に合わせたスケーラブルなグループ階層であり、ワークロードが明確に分離されている一元的に管理されたセキュリティとガバナンスを使用して大規模な運用化を可能にします。 管理グループのガバナンス範囲は、サブスクリプションを上回ります。
- 管理サブスクリプション - データ プラットフォームをサポートするために必要なさまざまな管理レベル機能の専用サブスクリプション。
- 接続サブスクリプション - データ プラットフォームの接続機能の専用サブスクリプション。これにより、名前付きサービスを識別し、内部サービスと外部サービス間の安全なルーティングと通信を決定できます。
- ランディング ゾーン サブスクリプション – Azure ネイティブ、オンライン アプリケーション、内部および外部向けのワークロードとリソース用の 1 対多サブスクリプション
- DevOps プラットフォーム - Azure 資産全体をサポートする DevOps プラットフォーム。 このプラットフォームには、コードベースのソース管理リポジトリと CI/CD パイプラインが含まれており、コードとしてのインフラストラクチャ (IaC) の自動デプロイが可能です。
Note
多くのお客様は、依然として大規模なサービスとしてのインフラストラクチャ (IaaS) フットプリントを保持しています。 IaaS 全体の復旧機能を実現するために追加すべき重要なコンポーネントは Azure Site Recovery です。 Site Recovery は、Azure VM のリージョン間レプリケーション、オンプレミスの仮想マシンと物理サーバーの Azure へのレプリケーション、セカンダリ データセンターへのオンプレミス マシンのレプリケーションを調整および自動化します。
この基本構造の中で、Contoso はそのエンタープライズ ビジネス インテリジェンスのニーズをサポートするために、「Azure Synapse を使用した分析のエンド ツー エンド」のガイダンスに沿って、次の要素を実装しました。
Contoso のデータ プラットフォーム - ワークフロー
ワークフローは、データの流れに従って左から右に進みます。
- データ ソース - データ プラットフォームが使用できるデータのソースまたは種類。
- 取り込み - 構造と速度が異なる各種ソースからデータを取り込むことができるプラットフォームの機能。 この設計は、 Lambda アーキテクチャを反映しています。
- ストア - プラットフォームに取り込まれた大規模なデータを安全に格納する機能。
- プロセス - クレンジング、標準化、モデリングなど、ダウンストリームのプロセスの "用途に合う" ようにデータを処理するプラットフォームの機能。 通常、データの事前処理により、"位置と条件、 使用できる状態" になります。
- エンリッチ - 統計、機械学習、またはその他のモデリング手法または事前構築済みの Azure AI サービスを使用して、プラットフォームで処理されるデータを強化する機能。
- Serve - ダウンストリームで使用するためにデータを整形および提示するプラットフォームの機能。
- データ コンシューマー - プラットフォームのさまざまなサービス のタッチポイントからデータを使用する個人、アプリケーション、またはダウンストリーム プロセス。
- 検出と管理 - 含まれるデータを管理し、インデックスが作成され、検出可能/検索可能で、完全な系列で適切に記述され、エンド ユーザーと消費プロセスに対して透過的であることを保証するプラットフォームの機能。
- プラットフォーム - プラットフォームが構築される基盤、つまり前述の Contoso の Azure 基盤。
Note
多くのお客様にとって、使用するデータ プラットフォームのリファレンス アーキテクチャが概念レベルで一致していても、物理的な実装は異なる場合があります。 たとえば、ELT (抽出、読み込み、変換) プロセスは Azure Data Factory を通して、データ モデリングは Azure SQL サーバーによって実行される場合があります。 この問題に対処するために、以下の Stateful コンポーネントとステートレス コンポーネント セクションでガイダンスを提供します。
データ プラットフォームの場合、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 アップリフト オプション: Azure サービスの一部として対象となる N/A。
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 ビルド サーバーなど) を使用する場合、障害からの復旧に関するお客様の責任は維持されます。
- IaaS VM が DevOps ツールチェーン内で使用されている場合、障害からの復旧に対するお客様の責任は維持されます。
ステートレスの基本コンポーネント
サブスクリプション
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
管理グループ
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
Azure Monitor
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
Cost Management
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
Microsoft Defender for Cloud
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
Azure DNS
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: 単一ゾーン - パブリック
- DR アップリフト オプション: N/A、DNS は設計上高可用性です。
Network Watcher
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
サブネット、ユーザー定義ルート (UDR) およびネットワーク セキュリティ グループ (NSG) を含む仮想ネットワーク
- コンポーネントの回復責任: Contoso
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: N/A
- DR アップリフト オプション: VNET は セカンダリのペアリージョンにレプリケートできます。
Azure Firewall
- コンポーネントの回復責任: Contoso
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: Standard
- DR アップリフト オプション: Azure Firewall は設計上高く利用できAvailability Zones を使用して作成して可用性を向上させることができます。
Azure DDoS
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: DDoS ネットワーク保護
- DR アップリフト オプション: Azure サービスの一部として対象となる N/A。
ExpressRoute 回線
- コンポーネントの回復責任: Contoso、接続パートナー、および Microsoft
- ワークロード/構成の復旧責任: 接続パートナーと Microsoft
- Contoso の SKU の選択: Standard
- DR 上昇オプション:
- ExpressRoute は、 private ピアリングを使用して geo 冗長サービスを提供するように高揚できます。
- ExpressRoute には、高可用性 (HA) 設計も用意されています。
- サイト間 VPN 接続 ExpressRoute のバックアップとして使用できます。
- 注
- ExpressRoute には 組み込みの冗長性があり各回線は、接続プロバイダー/クライアントのネットワーク エッジから ExpressRoute の場所にある 2 つの Microsoft Enterprise エッジ ルーター (MSE) への 2 つの接続で構成されます。
- ExpressRoute Premium 回線を使用すると、すべての Azure リージョンにグローバルにアクセスできます。
VPN Gateway
- コンポーネントの回復責任: Contoso
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: 単一ゾーン - VpnGw1
- DR アップリフト オプション: VPN ゲートウェイは、vpnGw#AZ SKU を使用して Availability Zone にデプロイして、 ゾーン冗長サービスを提供できます。
Azure Load Balancer
- コンポーネントの回復責任: Contoso
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: Standard
- DR 上昇オプション:
- ロード バランサーを構成することで、可用性ゾーンを含んだリージョン内でゾーン冗長を実現できます。 その場合、リージョン内の 1 つのゾーンが正常なままである限り、データ パスは存続します。
- プライマリ リージョンに応じて、 リージョン間のロード バランサー を高可用性のリージョン間デプロイ用にデプロイできます。
- 注
- 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 の回復性は、 クロスリージョン HA 実装によって高めることができます。
- Microsoft では、HA/DR オプションに関する次の ガイドを提供しています。
- 注
- IoT Hub は、データを各 IoT ハブのペア リージョンにレプリケートすることで、Microsoft が開始するフェールオーバーと手動フェールオーバーを提供します。
- IoT Hub には Intra-Region HA が用意されており 定義済みの Azure リージョン のセットで作成された場合、可用性ゾーンが自動的に使用されます。
Azure Stream Analytics
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: Standard
- DR の高揚オプション: Azure Stream Analytics はサービスとしてのフル マネージド プラットフォーム (PaaS) オファリングですが、自動 geo フェールオーバーは提供されません。 geo 冗長性 は、複数の Azure リージョンに同じ Stream Analytics ジョブをデプロイすることで実現できます。
Azure Machine Learning
- コンポーネントの回復責任: Contoso と Microsoft
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: General Purpose、D Series インスタンス
- DR 上昇オプション:
- Azure Machine Learning は複数の Azure サービスに依存しており、それらのサービスのいくつかはお客様のサブスクリプションにプロビジョニングされます。 そのため、お客様は引き続きこれらのサービスの高可用性構成に責任を負います。
- 回復性は、 複数リージョンのデプロイによって高めることができます。
- 注:
- Azure Machine Learning 自体は、自動フェールオーバーやディザスター リカバリーを しません。
Power BI
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: Power BI Pro
- DR アップリフト オプション: Power BI の回復性は、SaaS オファリングの一部です。
- 注
- Power BI は、Azure ではなく Office365 テナントに存在します。
- Power BI では、Azure Availability Zones を使用して、データセンターの障害から Power BI レポート、アプリケーション、データを保護します。
- リージョンの障害が発生した場合、Power BI は新しいリージョンに します通常は、 Microsoft セキュリティ センターで説明したように、同じ地理的な場所にあります。
Azure Cosmos DB
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: 単一リージョン書き込みと定期的なバックアップ
- DR 上昇オプション:
- 単一リージョンのアカウントは、リージョンの障害の後で可用性を失う場合があります。 回復性は、 single 書き込みリージョンと少なくとも 2 つ目の (読み取り) リージョンに高く引き上げることができ、サービスマネージド フェールオーバーを有効にすることができます。
- 運用環境のワークロードに使用される Azure Cosmos DB アカウントで、自動フェールオーバーを有効にすることをお勧めします。 この構成がない場合、リージョンに接続されていないため手動フェールオーバーは成功せず、書き込みリージョンの停止中は、アカウントで書き込みを利用できなくなる可能性があります。
- 注
- リージョン内のデータ損失から保護するために、Azure Cosmos DB には、2 つの の異なるバックアップ モード - Periodic と Continuous が用意されています。
- リージョン間フェールオーバーは、Azure Cosmos DB クライアントで検出され、処理されます。 アプリケーションの変更は不要です。
- 次のガイダンスでは、Cosmos DB の構成に基づくリージョンの停止のについて説明します。
Azure Data Share
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Microsoft
- Contoso の SKU の選択: N/A
- DR の上昇オプション: Azure Data Share の回復性は、セカンダリ リージョンへの HA デプロイによって高めることができます。
Microsoft Purview
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: N/A
- DR 上昇オプション: N/A
- 注
- 2024 年 10 月の時点で、 Microsoft Purview では、自動化されたビジネス継続性とディザスター リカバリー (BCDR) はサポートされていません。 そのサポートが追加されるまで、バックアップと復元の作業はすべてお客様の責任で行う必要があります。
ステートレス データ プラットフォーム固有のサービス
Azure Synapse: パイプライン
- コンポーネントの回復責任: Microsoft
- ワークロード/構成の復旧責任: Contoso
- Contoso の SKU の選択: コンピューティング最適化 Gen2
- DR アップリフト オプション: N/A、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 Analytics では、dedicated SQL プールのディザスター リカバリーのみがサポートされており Apache Spark プールではサポートされていません。
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 は、可用性ゾーンリージョン間でレプリカを使用することでHA 設計にまで引き上げることができます。
- 異なるリージョン内の複数のサービス 回復性をさらに拡張できます。
- 注
- AI Search では、ビジネス継続性 (およびディザスター リカバリー) が複数の AI Search サービスによって実現されます。
- ディザスター リカバリーのための組み込みのメカニズムはありません。 致命的な障害発生時に継続的なサービスが必要な場合は、別のリージョンに 2 つ目のサービスを配置し、すべてのサービスでインデックスが完全に冗長になるように geo レプリケーション戦略を実装することをお勧めします。
ステートフル コンポーネントとステートレス コンポーネント
特に Microsoft 製品スイートと Azure は頻繁にイノベーションが起こるので、この事例に使用したコンポーネント セットも急速に進化することが考えられます。 将来的に古くなったガイダンスを提供しないため、またこの文書で明示的にカバーされていない領域にも対応するために、以下のセクションに記載したいくつかの手引きは、大まかな状態の分類に基づいています。
コンポーネント/サービスは、前のイベントまたはユーザーの操作を記憶するように設計されている場合、ステートフルとして記述できます。 "ステートレス" とは、以前のインタラクションの記録が存在せず、個々のインタラクション要求は、それに付随する情報のみに基づいて処理されなければならないことを意味します。
再デプロイが必要な DR シナリオの場合:
- Azure Functions や Azure Data Factory パイプラインなどの "ステートレス" なコンポーネント/サービスは、少なくともスモーク テストを使用してソース管理から再デプロイして、より広範なシステムに導入される前に可用性を検証できます。
- Azure SQL Database やストレージ アカウントなど、"ステートフル" なコンポーネント/サービスには、さらに注意が必要です。
- コンポーネントを調達する際の重要な決定はデータ冗長機能の選択です。 この決定は、通常、運用コストによる可用性と持続性のトレードオフに焦点を当てています。
- データストアには、データ バックアップ戦略も必要です。 基になるストレージのデータ冗長性機能により、一部の設計ではこのリスクが軽減されますが、他の設計、たとえば SQL データベースでは、別のバックアップ プロセスが必要になります。
- 必要に応じて、スモーク テストを使用して検証済みの構成を使用して、ソース管理からコンポーネントを再デプロイできます。
- 再デプロイされたデータストアは、そのデータセットをリハイドレートする必要があります。 リハイドレートは、データ冗長 (使用可能な場合) またはバックアップ データセットを使用して実現できます。 リハイドレートが完了したら、精度と完全性を検証する必要があります。
- バックアップ プロセスの性質によっては、バックアップ データセットを適用する前に検証が必要になる場合があります。 バックアップ プロセスの破損またはエラーにより、使用可能な最新バージョンの代わりに以前のバックアップが使用される可能性があります。
- コンポーネントの日付/タイムスタンプと現在の日付の間の差分は、その時点からデータ インジェスト プロセスを再実行または再生することによって対処する必要があります。
- コンポーネントのデータセットが最新の状態になったら、より広範なシステムに導入できます。
その他の主要サービス
このセクションでは、他の主要な Azure データ コンポーネントとサービスの高可用性 (HA) と DR のガイダンスについて説明します。
- Azure Databricks - DR ガイダンスは、 product ドキュメントで確認できます。
- Azure Analysis Services - HA ガイダンスは、 製品のドキュメントで確認できます。
- Azure Database for MySQL
- SQL
- Azure VM 上の SQL ガイダンスは、 product ドキュメントで確認できます。
- Azure SQL と Azure SQL Managed Instance ガイダンスは、 product ドキュメントで確認できます。
次のステップ
これで、シナリオのアーキテクチャについて学習したので、 scenario の詳細について学習できます。