次の方法で共有

Azure Data Factory と Azure Synapse Analytics のパイプラインでの BCDR

Azure Data Factory
Azure Repos
Azure Synapse Analytics
GitHub

障害には、ハードウェア障害、自然災害、またはソフトウェア障害があります。 障害に備え、障害から復旧するプロセスのことを、ディザスター リカバリー (DR) と呼びます。 この記事では、Azure Data Factory と Azure Synapse Analytics パイプラインのビジネス継続性とディザスター リカバリー (BCDR) を実現するための推奨されるプラクティスについて説明します。

BCDR 戦略には、可用性ゾーンの冗長性、Azure DR が提供する自動復旧、継続的インテグレーションと継続的デリバリー (CI/CD) を使用したユーザー管理の復旧が含まれます。

Architecture

Azure Synapse Analytics および Azure Data Factory パイプライン BCDR の可用性ゾーンとリージョンを示す図。

このアーキテクチャの Visio ファイル をダウンロードします。

Workflow

  • Azure Data Factory と Azure Synapse Analytics パイプラインは、Azure リージョンと Azure 可用性ゾーンを使用して回復性を実現します。

    • 各 Azure リージョンには、待ち時間で定義された境界内にデプロイされた一連のデータセンターがあります。

    • Azure 可用性ゾーンは、Azure リージョン内の物理的に分離された場所です。 ゾーンは、ローカル障害を許容できます。

    • すべての Azure リージョンと可用性ゾーンは、専用のリージョンの低待機時間ネットワークと高パフォーマンス ネットワークを介して接続されます。

    • 回復性を確保するため、すべての可用性ゾーン対応リージョンには、少なくとも 3 つの個別の可用性ゾーンあります。

  • データセンター、データセンターの一部、またはリージョン内の可用性ゾーンで障害が発生した場合、ゾーン回復性の高い Azure Data Factory パイプラインと Azure Synapse Analytics パイプラインは、ダウンタイムをゼロにしてフェールオーバーします。

Components

  • Azure Data Factory は、大規模なデータ ワークフローの管理と自動化を支援するように設計されたクラウドベースのデータ統合サービスです。 このアーキテクチャでは、データ移動と変換のワークフローを調整し、リージョンペアの自動フェールオーバーと CI/CD ベースのユーザー管理復旧による回復性をサポートします。

  • Azure Synapse Analytics は、大量のデータを迅速かつ効率的に分析できるように設計された、ビッグ データとデータ ウェアハウス用の統合プラットフォームです。

    • Azure Synapse Analytics パイプライン は、Azure Synapse Analytics 内のデータ統合とオーケストレーション機能であり、データの移動と変換のためのワークフローの構築、管理、自動化に使用できます。 このアーキテクチャでは、Azure Synapse Analytics パイプラインがデータ ワークフローを管理し、ゾーン冗長性、Git リポジトリとの統合、自動またはユーザー管理の回復アプローチを有効にすることで BCDR をサポートします。

  • GitHub は、開発者が Git を使用してソフトウェア プロジェクトの共同作業、コードの管理、変更の追跡を行うのに役立つクラウドベースのプラットフォームです。 このアーキテクチャでは、GitHub はパイプライン成果物を格納し、ユーザーが管理する復旧戦略の一環としてセカンダリ リージョンへの自動デプロイを可能にします。

  • Azure Repos は、コードの管理に使用できる一連のバージョン管理ツールです。 このアーキテクチャでは、手動の DR とフェールオーバーの準備をサポートするために、Azure Data Factory と Azure Synapse Analytics パイプラインのソース管理と CI/CD 統合を提供することで、GitHub と同様に機能します。

Scenario details

Azure Data Factory と Azure Synapse Analytics パイプラインには、次の種類のデータを含む成果物が格納されます。

  • パイプライン、データセット、リンクされたサービス、統合ランタイム (XR)、トリガーなどのメタデータ

  • パイプラインの実行、トリガーの実行、アクティビティの実行などの監視データ

障害は、ハードウェア障害、自然事象、人為的ミスやサイバー攻撃によって引き起こされるソフトウェア障害など、さまざまな形で発生する可能性があります。 障害の種類によっては、地理的な影響がリージョンまたはグローバルである可能性があります。 DR 戦略を計画するときは、災害の性質と潜在的な地理的範囲の両方を考慮してください。

Azure の BCDR は、共同責任モデルの下で動作します。 Azure には基本的なインフラストラクチャとプラットフォーム サービスが用意されていますが、多くの Azure オファリングでは DR 戦略を積極的に構成する必要があります。

次の推奨プラクティスを使用して、さまざまな障害シナリオで Azure Data Factory と Azure Synapse Analytics パイプラインの BCDR を実現できます。 実装については、 このシナリオのデプロイを参照してください。

Azure DR を使用した自動復旧

バックアップと DR を使用 して自動復旧を構成 すると、リージョンがペアになっている Azure リージョンで完全な停止が発生すると、Azure Data Factory または Azure Synapse Analytics パイプラインがトリガーされ、ペアになっているリージョンに自動的にフェールオーバーされます。 例外には、東南アジアとブラジルのリージョンが含まれます。データ所在地の要件では、これらのリージョンにデータを残す必要があります。

DR フェールオーバーでは、Azure Data Factory によって運用パイプラインが復旧されます。 復旧したパイプラインを検証する必要がある場合は、運用パイプラインの Azure Resource Manager テンプレートをシークレット ストレージにバックアップし、復旧したパイプラインとバックアップを比較できます。

Azure Global チームは定期的に BCDR の訓練を実施しており、これらの訓練には Azure Data Factory と Azure Synapse Analytics が含まれます。 BCDR の訓練では、リージョンの障害がシミュレートされ、お客様の関与なしに Azure サービスがペアになったリージョンにフェールオーバーされます。 BCDR 訓練の詳細については、 サービスのテストを参照してください。

CI/CD を使用したユーザー管理の冗長性

完全なリージョン障害が発生した場合に BCDR を実現するには、セカンダリ リージョンに Azure Data Factory または Azure Synapse ワークスペースがプロビジョニングされている必要があります。 Azure Data Factory または Azure Synapse Analytics パイプラインに影響を与える誤った削除、サービスの停止、または内部メンテナンス イベントが発生した場合は、Git 統合と CI/CD ワークフローを使用してパイプラインを手動で復旧できます。

必要に応じて、アクティブ/パッシブ実装を使用できます。 プライマリ リージョンは通常の操作を処理し、アクティブなままです。 セカンダリ DR リージョンをプライマリ リージョンに昇格するには、特定の実装によって異なる事前に計画された手順が必要です。 これらの手順により、リージョンの障害が発生した場合にスムーズに移行し、中断を最小限に抑えることができます。 この場合、インフラストラクチャに必要なすべての構成がセカンダリ リージョンで使用できますが、プロビジョニングされていません。

考えられるユース ケース

ユーザー管理の冗長性は、次のシナリオで役立ちます。

  • 人為的エラーが原因でパイプライン成果物が誤って削除された
  • 障害が報告されていないため BCDR をトリガーしない拡張停止またはメンテナンス イベント

運用ワークロードを他のリージョンにすばやく移動して、影響を受けないようにすることができます。

Considerations

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 Well-Architected Framework」を参照してください。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の 設計レビュー チェックリスト」を参照してください。

Azure Data Factory と Azure Synapse Analytics パイプラインは、可用性ゾーンをサポートするメインストリームの Azure サービスです。 これらは、適切なレベルの回復性と柔軟性と超低待機時間を提供するように設計されています。

ユーザーが管理する復旧アプローチを使用すると、プライマリ リージョンにメンテナンス イベント、停止、または人的エラーがある場合に操作を続行できます。 CI/CD を使用すると、Azure Data Factory と Azure Synapse Analytics パイプラインを Git リポジトリに統合し、セカンダリ リージョンにデプロイしてすぐに復旧できます。

Cost Optimization

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「 コストの最適化」のデザイン レビュー チェックリストを参照してください。

ユーザー管理の復旧では、CI/CD を使用して Azure Data Factory と Git を統合します。 必要に応じて、必要なすべてのインフラストラクチャ構成をバックアップとして持つセカンダリ DR リージョンを使用します。 このシナリオでは、追加コストが発生する可能性があります。 コストを見積もる場合は、 Azure 料金計算ツールを使用します。

Azure Data Factory と Azure Synapse Analytics の価格の例については、次の記事を参照してください。

Operational Excellence

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「 オペレーショナル エクセレンスの設計レビュー チェックリスト」を参照してください。

ユーザーが管理する CI/CD 復旧アプローチを使うと、Azure Repos または GitHub に統合できます。 詳細については、「 CI/CD のベスト プラクティス」を参照してください。

このシナリオのデプロイ

次のアクションを実行して、Azure Data Factory および Azure Synapse Analytics パイプライン用に自動またはユーザー管理の DR を設定します。

自動復旧を設定する

Azure Data Factory では、 IR セットアップでアクティビティの実行またはディスパッチの Azure IR リージョンを設定できます。 リージョン全体の停止が発生した場合に自動フェールオーバーを有効にするには、 リージョン を [自動解決] に設定します。

[自動解決] を選択して IR セットアップで自動フェールオーバーを有効にする方法を示すスクリーンショット。

IR リージョンとして [自動解決 ] を選択すると、IR はペアのリージョンに自動的にフェールオーバーされます。 他の特定の場所のリージョンでは、別のリージョンにセカンダリ データ ファクトリを作成し、CI/CD を使用して Git リポジトリからデータ ファクトリをプロビジョニングできます。

  • マネージド仮想ネットワークの場合は、セカンダリ リージョンに手動で切り替える必要があります。

  • Azure マネージド自動フェールオーバーは、インフラストラクチャがカスタマー マネージドであるため、セルフホステッド統合ランタイム (SHIR) には適用されません。 SHIR を使用して高可用性を実現するために複数のノードを設定する方法については、「 SHIR の作成と構成」を参照してください。

  • Azure SQL Server Integration Services (Azure-SSIS) IR 用に BCDR を構成するには、「 BCDR の Azure-SSIS IR を構成する」を参照してください。

リージョンの新しいネットワークで保留中のプライベート エンドポイントがあるため、フェールオーバー後にリンクされたサービスが完全に有効になりません。 復旧されたリージョンでプライベート エンドポイントを構成する必要があります。 承認 API を使用して、プライベート エンドポイントの作成を自動化できます。

CI/CD を使用してユーザー管理の復旧を設定する

Azure Data Factory または Azure Synapse パイプラインの削除または停止が発生した場合は、Git と CI/CD を使用してパイプラインを手動で復旧できます。

CI/CD を使用してユーザー管理の冗長性をデプロイする場合は、次のアクションを実行します。

Disable triggers

元のプライマリ データ ファクトリがオンラインに戻った後、トリガーを無効にします。 トリガーを手動で無効にするか、自動化を実装して、元のプライマリ データ ファクトリの可用性を定期的に確認できます。 ファクトリが復旧したら直ちに、元のプライマリ データ ファクトリのすべてのトリガーを無効にします。

Azure PowerShell を使用して Azure Data Factory トリガーをオフまたはオンにするには、 デプロイ前とデプロイ後のサンプル スクリプト と、 パイプライン トリガーのデプロイに関連する CI/CD の機能強化に関するページを参照してください。

重複する書き込みを処理する

ほとんどの抽出、変換、および読み込みパイプラインは、バックフィルおよび再調整プロセスで必要になるため、重複する書き込みを処理するように設計されています。 透過的フェールオーバーをサポートするデータ シンクでは、レコードをマージするか、特定の時間範囲内のすべてのレコードを削除して挿入することで、重複する書き込みを処理できます。

フェールオーバー後にエンドポイントを変更するデータ シンクの場合、プライマリとセカンダリ ストレージに重複するデータまたは部分的なデータが存在する可能性があります。 データを手動でマージする必要があります。

監視の仕組みを調べてパイプラインのフローを制御する (省略可能)

一般に、目的の時点から失敗したパイプラインを再開するために、失敗アクティビティやルックアップ アクティビティなどのアクティビティを含むようにパイプラインを設計する必要があります。

  1. プライマリ データ ファクトリの region='EastUS' やセカンダリ データ ファクトリの region='CentralUS' など、リージョンを示すグローバル パラメーターをデータ ファクトリに追加します。

  2. 3 番目のリージョンに監視の仕組みを作ります。 監視の仕組みには、REST 呼び出しまたは任意の種類のストレージを使用できます。 ミラーリング監視サーバーは、既定で現在のプライマリ リージョン ( 'EastUS' など) を返します。

  3. 障害が発生した場合は、ミラーリング監視サーバーを手動で更新して、 'CentralUS'などの新しいプライマリ リージョンを返します。

  4. 監視の仕組みを調べて現在のプライマリ値をグローバル パラメーターと比較するアクティビティを、パイプラインに追加します。

    • パラメーターが一致する場合、このパイプラインはプライマリ リージョンで実行されます。 主な処理タスクに進みます。

    • パラメーターが一致しない場合、このパイプラインはセカンダリ リージョンで実行されます。 結果のみを返します。

Note

この方法では、監視の仕組みへの依存関係がパイプラインに組み込まれます。 監視の仕組みの読み取りに失敗すると、すべてのパイプラインの実行が停止します。

Contributors

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

Principal authors:

Other contributors:

  • Wee Hyong Tok |PM のプリンシパル ディレクター - Azure Data Factory チーム
  • マリオ・ツィマーマン |プリンシパル ソフトウェア エンジニアリング マネージャー - Azure Data Factory チーム

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

Next steps