編集

次の方法で共有

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 ディザスター リカバリーによって提供される自動復旧、継続的インテグレーションと継続的デリバリー (CI/CD) を使ってユーザーが管理する復旧が含まれます。

Architecture

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

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

ワークフロー

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

    • 各 Azure リージョンには、待ち時間で定義された境界内にデプロイされた一連のデータセンターがあります。
    • Azure 可用性ゾーンは、局所的な障害にトレラントな各 Azure リージョン内の物理的に分離された場所です。
    • すべての Azure リージョンと可用性ゾーンは、リージョンごとの専用の低遅延ネットワークとハイ パフォーマンス ネットワークを介して接続されます。
    • 回復性を確保するため、すべての可用性ゾーン対応リージョンには、少なくとも 3 つの個別の可用性ゾーンあります。

  2. リージョン内のデータセンター、データセンターの一部、または可用性ゾーンがダウンすると、ゾーン回復性の Data Factory と Azure Synapse のパイプラインで、ダウンタイムのないフェールオーバーが発生します。

Components

シナリオの詳細

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

メタデータ

  • パイプライン
  • データセット
  • リンクされたサービス
  • 統合ランタイム
  • トリガー

データの監視

  • パイプライン
  • トリガー
  • アクティビティの実行

障害は、ハードウェア障害、自然災害、人的エラーやサイバー攻撃によるソフトウェア障害など、さまざまな方法で発生する可能性があります。 障害の種類により、地理的な影響は地域的なものから世界的なものにまでなる可能性があります。 ディザスター リカバリー戦略を計画するときは、災害の性質とその地理的影響の両方を考慮してください。

Azure の BCDR は、共有責任モデルで動作します。 多くの Azure サービスでは、お客様が DR 戦略を明示的に設定する必要があります。一方、Azure は必要に応じてベースライン インフラストラクチャとプラットフォーム サービスを提供します。

次の推奨されるプラクティスを使って、さまざまな障害シナリオにおける Data Factory と Azure Synapse のパイプラインの BCDR を実現できます。 実装については、「このシナリオのデプロイ」をご覧ください。

Azure ディザスター リカバリーによる自動復旧

自動復旧によって提供される Azure のバックアップとディザスター リカバリーでは、ペアになっているリージョンを持つ Azure リージョンに対して完全なリージョン停止が発生した場合、Data Factory または Azure Synapse パイプラインは、自動復旧を設定すると、ペアになっているリージョンに自動的にフェールオーバーされます。 例外は東南アジアとブラジルのリージョンで、データ所在地の要件のため、それらのリージョンにデータを留めておく必要があります。

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

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

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

リージョン全体で障害が発生した場合に BCDR を実現するには、セカンダリ リージョンにデータ ファクトリまたは Azure Synapse ワークスペースが必要です。 Data Factory または Azure Synapse のパイプラインの削除、停止、または内部メンテナンス イベントが誤って発生した場合は、Git と CI/CD を使ってパイプラインを手動で復旧できます。

必要に応じて、アクティブ/パッシブ実装を使用できます。 プライマリ リージョンは通常の操作を処理し、アクティブな状態を維持します。一方、セカンダリ DR リージョンでは、特定の実装に応じて事前に計画された、プライマリに昇格するための手順が必要です。 この場合、インフラストラクチャに必要なすべての構成がセカンダリ リージョンで使用できますが、プロビジョニングされていません。

考えられるユース ケース

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

  • 人的エラーによるパイプライン成果物の誤った削除。
  • 障害が報告されないために BCDR がトリガーされない長期間の停止またはメンテナンス イベント。

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

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

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

ユーザーが管理する復旧方法を使用すると、プライマリ リージョンでメンテナンス イベント、停止、または人的エラーが発生しても、運用を続けることができます。 CI/CD を使うことで、Data Factory と Azure Synapse のパイプラインを Git リポジトリに統合し、即時復旧のためにセカンダリ リージョンにデプロイできます。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

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

Data Factory と Azure Synapse Analytics の価格の例については、次をご覧ください。

オペレーショナル エクセレンス

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

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

このシナリオのデプロイ

Data Factory と Azure Synapse のパイプライン用に自動またはユーザー管理の DR を設定するには、次のようにします。

自動復旧を設定する

Data Factory では、[Integration runtime setup] (統合ランタイムのセットアップ) で、アクティビティの実行またはディスパッチ用に Azure 統合ランタイム (IR) リージョンを設定できます。 完全なリージョン停止の際の自動フェールオーバーを有効にするには、[リージョン] を [自動解決] に設定します。

[Integration runtime setup] (統合ランタイムのセットアップ) での自動フェールオーバーを有効にするための [自動解決] の選択を示すスクリーンショット。

統合ランタイムのコンテキストでは、IR リージョンとして [自動解決] を選ぶと、IR はペアになっているリージョンに自動的にフェールオーバーします。 他の特定の場所のリージョンでは、別のリージョンにセカンダリ データ ファクトリを作成し、CI/CD を使って Git リポジトリからデータ ファクトリをプロビジョニングできます。

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

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

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

CI/CD を使ってユーザーが管理する冗長性をデプロイするときは、次のようにします。

トリガーを無効にします

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

Azure PowerShell を使って Data Factory のトリガーをオフまたはオンにする方法については、「サンプルのデプロイ前とデプロイ後スクリプト」と「パイプライン トリガーのデプロイに関連する CI/CD の機能強化」をご覧ください。

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

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

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

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

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

  1. データ ファクトリにグローバル パラメーターを追加して、リージョンを示します (たとえば、プライマリが region='EastUS' でセカンダリ データ ファクトリが region='CentralUS')。

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

  3. 障害が発生したら、新しいプライマリ リージョンを返すように監視の仕組みを手動で更新します (例: 'CentralUS')。

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

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

注意

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

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Krishnakumar Rukmangathan | シニア プログラム マネージャー - Azure Data Factory チーム

  • Sunil Sabat | プリンシパル プログラム マネージャー - Azure Data Factory チーム

その他の共同作成者:

  • Mario Zimmermann | プリンシパル ソフトウェア エンジニアリング マネージャー - Azure Data Factory チーム

  • Wee Hyong Tok | PM のプリンシパル ディレクター - Azure Data Factory チーム

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順