この記事では、 Azure Data Factory での信頼性のサポートについて説明します。 可用性ゾーンと複数リージョンのデプロイによるリージョン内の回復性について説明します。
信頼性は、お客様と Microsoft の間で共有される責任です。 このガイドを使用して、特定のビジネス目標とアップタイム目標を満たす信頼性オプションを決定できます。
Data Factory を使用して、サーバーレス データ統合とデータ変換のための柔軟で強力なデータ パイプラインを作成できます。 その結果、信頼性の ビジネス継続性計画 を定義するときは、次の信頼性要件とガイダンスを考慮する必要があります。
データファクトリーパイプライン。
統合ランタイム (XR) 。データ ストアに接続し、パイプラインで定義されたアクティビティを実行します。
データ ファクトリに接続するデータ ストア。 データ ストアがビジネス継続性の要件を満たしていることを確認するには、製品の信頼性に関するドキュメントとガイダンスを参照してください。
信頼性アーキテクチャの概要
Data Factory は、複数のインフラストラクチャ コンポーネントで構成されています。 各コンポーネントは、さまざまな方法でインフラストラクチャの信頼性をサポートします。
Data Factory のコンポーネントは次のとおりです。
パイプライン トリガーを管理し、パイプライン アクティビティの調整を監視するコア Data Factory サービス。 コア サービスは、データ ファクトリ内の各コンポーネントのメタデータも管理します。 Microsoft はコア サービスを管理します。
パイプライン内で特定のアクティビティを実行する統合ランタイム (XR)。 さまざまな種類の AR があります。
Azure IR と Azure-SQL Server Integration Services (Azure-SSIS) IR を含む、Microsoft が管理する IR。 Microsoft は、これらのランタイムを構成するコンポーネントを管理します。 シナリオによっては、AR の回復性に影響する設定を構成します。
セルフホステッド統合ランタイム (SHIRs)。 Microsoft では、Data Factory パイプラインの一部を実行するために、独自のコンピューティング インフラストラクチャで実行できるソフトウェアを提供しています。 コンピューティング リソースのデプロイと管理、およびそれらのコンピューティング リソースの回復性については、お客様が責任を負います。
一時的な障害
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Data Factory を使用する場合は、特にパイプラインとアクティビティを設計する場合に、一時的な障害に備えて準備することが重要です。
べき等
パイプライン アクティビティはべき等である必要があります。つまり、悪影響を及ぼすことなく複数回再実行できる必要があります。 ネットワーク障害や可用性ゾーンの停止などの一時的な障害が発生した場合、Data Factory はパイプライン アクティビティを再実行する可能性があります。 この再実行では、重複するレコードを作成できます。
一時的な障害が原因でレコードが重複して挿入されないようにするには、次のベスト プラクティスを実装します。
データベースに書き込む前に、レコードごとに一意の識別子を使用します。 この方法は、重複するレコードを見つけて排除するのに役立ちます。
upsert をサポートするコネクタにはアップサート戦略を使用 します。 重複レコードの挿入が発生する前に、この方法を使用して、レコードが既に存在するかどうかを確認します。 存在する場合は、更新します。 存在しない場合は、挿入します。 たとえば、
MERGEやON DUPLICATE KEY UPDATEなどの SQL コマンドでは、このアップサート アプローチが使用されます。コピー アクション戦略を使用します。 詳細については、「 コピー アクティビティでのデータ整合性の検証」を参照してください。
再試行ポリシー
再試行ポリシーを使用すると、接続されているリソースの一時的な障害など、問題が発生した場合に再試行するようにパイプラインの一部を構成できます。 Data Factory では、次のパイプライン オブジェクトの種類に対して再試行ポリシーを構成できます。
データ ファクトリのトリガーとアクティビティの再試行ポリシーを変更または無効にする方法の詳細については、「 パイプラインの実行とトリガー」を参照してください。
可用性ゾーンのサポート
可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Data Factory ではゾーンの冗長性がサポートされており、 可用性ゾーンの障害に対する回復性が提供されます。 このセクションでは、Data Factory サービスの各部分がゾーン冗長をサポートする方法について説明します。
サポートされているリージョン
ゾーン冗長 Data Factory リソースは、 可用性ゾーンをサポートする任意のリージョンにデプロイできます。
考慮事項
コア サービス: Microsoft は、コア Data Factory サービスのコンポーネントを管理し、それらを可用性ゾーンに分散します。
AR: ゾーン冗長のサポートは、使用する IR の種類によって異なります。
Azure IR では ゾーンの冗長性がサポートされており、Microsoft はこの機能を管理します。
Azure-SSIS IR では、少なくとも 2 つのノードをデプロイする必要があります。 これらのノードは、異なる可用性ゾーンに自動的に割り当てられます。
SHIR を使用すると、ランタイムをホストするコンピューティング インフラストラクチャをデプロイする必要があります。 個々の仮想マシン (VM) などの複数のノードをデプロイし、高可用性のために構成できます。 その後、これらのノードを複数の可用性ゾーンに分散できます。 詳細については、「 高可用性とスケーラビリティ」を参照してください。
費用
コア サービス: ゾーンの冗長性には追加コストは適用されません。
AR: ゾーン冗長のコストは、使用する IR の種類によって異なります。
Azure IR には、追加料金なしでゾーン冗長性が含まれます。
Azure-SSIS IR では、ゾーンの冗長性を実現するために、少なくとも 2 つのノードをデプロイする必要があります。 各ノードの課金方法の詳細については、「 価格の例: Azure-SSIS IR で SSIS パッケージを実行する」を参照してください。
SHIR では、コンピューティング インフラストラクチャをデプロイして管理する必要があります。 ゾーンの回復性を実現するには、コンピューティング リソースを複数のゾーンに分散させる必要があります。 デプロイするノードの数と構成方法によっては、基になるコンピューティング サービスやその他のサポート サービスから追加のコストが発生する可能性があります。 複数のノードで SHIR を実行するための追加料金は発生しません。
可用性ゾーン構成のサポート
コア サービス: 構成は必要ありません。 Data Factory コア サービスでは、ゾーンの冗長性が自動的にサポートされます。
IR:
Azure IR: 構成は必要ありません。 Azure IR により、ゾーンの冗長性が自動的に有効になります。
Azure-SSIS IR: 構成は必要ありません。 Azure-SSIS IR は、2 つ以上のノードを使用してデプロイされるときに、ゾーンの冗長性を自動的に有効にします。
SHIR では、複数の可用性ゾーンにノードを分散させるなど、独自の回復性を構成する必要があります。
容量の計画と管理
コア サービス: Data Factory コア サービスは、需要に基づいて自動的にスケーリングされ、容量を計画または管理する必要はありません。
IR:
Azure IR は 需要に基づいて自動的にスケーリングされ、容量を計画または管理する必要はありません。
Azure-SSIS IR では、使用するノードの数を具体的に構成する必要があります。 可用性ゾーンの障害に備えて、IR の容量を過剰にプロビジョニングすることを検討してください。 オーバープロビジョニングにより、ソリューションは、ある程度の容量損失を許容でき、パフォーマンスが低下することなく引き続き機能できます。 詳細については、「 過剰プロビジョニングによる容量の管理」を参照してください。
SHIR では、独自の容量とスケーリングを構成する必要があります。 SHIR をデプロイするときは、リソースの余裕を持たせることを配慮してください。
通常の運用
ゾーン間のトラフィック ルーティング: 通常の操作中、Data Factory は、各可用性ゾーン内の正常なインスタンス間でパイプライン アクティビティ、トリガー、およびその他の作業を自動的に分散します。
ゾーンダウン エクスペリエンス
検出と応答: Data Factory プラットフォームは、可用性ゾーンでの障害の検出と応答を担当します。 パイプラインやその他のコンポーネントでゾーン フェールオーバーを開始するために何もする必要はありません。
アクティブな要求: 進行中のパイプラインとトリガーは引き続き実行され、ゾーン障害による即時の中断は発生しません。 ただし、ゾーン障害時に進行中のアクティビティは失敗し、再起動される可能性があります。 アクティビティを一貫性のあるように設計することが重要です。これにより、ゾーン障害やその他の不具合からの復旧が容易になります。 詳細については、「 一時的な障害」を参照してください。
フェールバック
可用性ゾーンが復旧すると、Data Factory は自動的に元のゾーンにフェールバックします。 パイプラインやその他のコンポーネントでゾーン のフェールバックを開始するために何もする必要はありません。
ただし、SHIR を使用する場合は、コンピューティング リソースが停止している場合は再起動が必要になる場合があります。
ゾーン障害のテスト
コア サービスの場合、および Azure および Azure-SSIS の場合、Data Factory はゾーン冗長リソースのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
SHIR の場合、 Azure Chaos Studio を使用して、Azure VM 上の可用性ゾーンの障害をシミュレートできます。
マルチリージョン サポート
Data Factory リソースは、単一の Azure リージョンにデプロイされます。 リージョンが使用できなくなった場合、データ ファクトリも使用できなくなります。 ただし、リージョンの停止に対する回復性を確保するために使用できる方法があります。 これらの方法は、データ ファクトリがペアになっているリージョンかペアになっていないか、特定の要件と構成によって異なります。
Microsoft が管理するペア リージョンへのフェールオーバー
Data Factory では、ブラジル南部と東南アジアを除く、ペアになっているリージョンのデータ ファクトリに対して Microsoft が管理するフェールオーバーがサポートされています。 万一、リージョンの障害が長引いた場合、Microsoft は Data Factory インスタンスのリージョンフェールオーバーを開始する可能性があります。
ブラジル南部と東南アジアではデータ所在地の要件があるため、Data Factory データは 、Azure Storage ゾーン冗長ストレージを使用してローカル リージョンにのみ格納されます。 東南アジアの場合、すべてのデータはシンガポールに格納されます。 ブラジル南部の場合、すべてのデータはブラジルに格納されます。
ペアリングされていないリージョンのデータ ファクトリ、またはブラジル南部または東南アジアのデータ ファクトリの場合、Microsoft はユーザーに代わってリージョンフェールオーバーを実行しません。
重要
Microsoft は、Microsoft が管理するフェールオーバーをトリガーします。 これは、大幅な遅延の後に発生する可能性が高く、ベスト エフォートベースで実行されます。 このプロセスにはいくつかの例外もあります。 データ ファクトリのメタデータが失われる可能性があります。 Data Factory リソースのフェールオーバーは、他の Azure サービスのフェールオーバー時刻とは異なる時点で発生する可能性があります。
リージョンの停止に対する回復性が必要な場合は、代替の マルチリージョン アプローチの 1 つを使用することを検討してください。
IR のフェールオーバー
フェールオーバーに備えるために、使用する IR によっては、追加の考慮事項が存在する場合があります。
使用するリージョンを自動的に解決するように Azure IR を構成できます。 リージョンが 自動解決 に設定されていて、プライマリ リージョンで障害が発生した場合、Azure IR はペアになっているリージョンに自動的にフェールオーバーします。 このフェールオーバーには 制限があります。 アクティビティの実装または IR セットアップでのディスパッチ用に Azure IR リージョンを構成するには、 リージョンを自動解決に設定します。
Azure-SSIS IR フェールオーバーは、データ ファクトリの Microsoft が管理するフェールオーバーとは別に管理されます。 詳細については、 代替の複数リージョンアプローチを参照してください。
SHIR は 自分が担当するインフラストラクチャで実行されるため、Microsoft が管理するフェールオーバーは SHIR には適用されません。 詳細については、 代替の複数リージョンアプローチを参照してください。
フェールオーバー後の再構成
Microsoft が管理するフェールオーバーが完了したら、ペアになっているリージョンの Data Factory パイプラインにアクセスできます。 ただし、フェールオーバーが完了した後は、PR またはその他のコンポーネントに対していくつかの再構成を実行することが必要になる場合があります。 このプロセスには、ネットワーク構成の再確立が含まれます。
代替のマルチリージョン アプローチ
リージョンの障害に対する回復性を備えるパイプラインが必要で、フェールオーバー プロセスを制御する必要がある場合は、メタデータ駆動型パイプラインの使用を検討してください。
Data Factory のソース管理を設定 して、メタデータに対する変更を追跡および監査します。 このアプローチを使用して、パイプライン、データセット、リンクされたサービス、トリガーのメタデータ JSON ファイルにアクセスできます。 Data Factory では、Azure DevOps や GitHub など、さまざまな Git リポジトリの種類がサポートされています。 詳細については、「 Data Factory のソース管理」を参照してください。
Azure DevOps などの継続的インテグレーションと継続的デリバリー (CI/CD) システムを使用して、パイプラインのメタデータとデプロイを管理します。 CI/CD を使用すると、操作を別のリージョンのインスタンスにすばやく復元できます。 リージョンが使用できない場合は、新しいデータ ファクトリを手動で、または自動化を使用してプロビジョニングできます。 新しいデータ ファクトリが作成されたら、既存の Git リポジトリからパイプライン、データセット、およびリンクされたサービス JSON を復元できます。 詳細については、 Data Factory および Azure Synapse Analytics パイプラインのビジネス継続性とディザスター リカバリー (BCDR) に関するページを参照してください。
使用する IR によっては、他の考慮事項が存在する場合があります。
Azure-SSIS IR は、Azure SQL Database または Azure SQL Managed Instance に格納されているデータベースを使用します。 このデータベースの geo レプリケーションまたはフェールオーバー グループを構成できます。 Azure-SSIS データベースは、読み取り/書き込みアクセス権を持つプライマリ Azure リージョンにあります。 データベースは、読み取り専用アクセス権を持つセカンダリ リージョンに継続的にレプリケートされます。 プライマリ リージョンが使用できない場合、フェールオーバーがトリガーされ、プライマリ データベースとセカンダリ データベースがロールをスワップします。
また、Azure SQL Database または SQL Managed Instance フェールオーバー グループと同期して動作するデュアル スタンバイ Azure SSIS IR ペアを構成することもできます。
詳細については、「 BCDR の Azure-SSIS IR を構成する」を参照してください。
SHIR は 、管理するインフラストラクチャで実行されます。 SHIR が Azure VM にデプロイされている場合は、 Azure Site Recovery を使用して、別のリージョンへの VM フェールオーバー をトリガーできます。
バックアップと復元
Data Factory では、ソース管理統合によって CI/CD がサポートされるため、データ ファクトリ インスタンスのメタデータをバックアップできます。 CI/CD パイプラインは、このメタデータを新しい環境にシームレスにデプロイします。 詳細については、 Data Factory の CI/CD を参照してください。
サービス水準合意書
Azure Data Factory のサービス レベル アグリーメント (SLA) では、サービスの予想される可用性について説明します。 この契約では、この期待を達成するために満たす必要がある条件についても説明しています。 これらの条件を理解するために、「Online Services のサービス レベル アグリーメント (SLA)」を必ず確認してください。