次の方法で共有

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) を使ってユーザーが管理する復旧が含まれます。

アーキテクチャ

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

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

ワークフロー

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

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

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

コンポーネント

シナリオの詳細

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

メタデータ

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

監視データ

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

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

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

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

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

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

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

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

[信頼性]

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

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

ユーザーが管理する復旧方法を使用すると、プライマリ リージョンでメンテナンス イベント、停止、または人的エラーが発生しても、運用を続けることができます。 CI/CD を使うことで、データ ファクトリと 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 では、統合ランタイムのセットアップで、アクティビティの実行またはディスパッチ用に Azure 統合ランタイム (IR) リージョンを 設定できます。 リージョンが完全に停止した場合に自動フェールオーバーを有効にするには、 リージョン を [自動解決] に設定します。

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

統合ランタイムのコンテキストでは、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 によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

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

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

次の手順