Azure Data Factory に DataOps を適用する
適用対象:
Azure Data Factory Azure Synapse Analytics
ヒント
企業向けのオールインワン分析ソリューション、Microsoft Fabric の Data Factory をお試しください。 Microsoft Fabric は、データ移動からデータ サイエンス、リアルタイム分析、ビジネス インテリジェンス、レポートまで、あらゆるものをカバーしています。 無料で新しい試用版を開始する方法について説明します。
Azure Data Factory は、Microsoft が提供するクラウドでのデータ統合と ETL のサービスです。 このペーパーでは、データ ファクトリの DataOps に関するガイダンスを示します。 これは、CI/CD、Git、DevOps に関する完全なチュートリアルを意図したものではありません。 このペーパーでは、データ ファクトリのデプロイのベスト プラクティス、ファクトリの管理、ガバナンスに関する詳細な実装リンクを参照しながら、サービスで DataOps を実現するのに必要なデータ ファクトリ チームのガイダンスを確認できます。 このペーパーの末尾には、チュートリアルへのリンクを含むリソース セクションも用意されています。
DataOps とは
DataOps は、意思決定者により迅速に価値を提供する目的で、データ組織が共同データ管理のために実践するプロセスです。
Gartner では、次のように明快に DataOps を定義しています。
DataOps は、組織全体のデータ マネージャーとデータ コンシューマーとの間のデータ フローのコミュニケーション、統合、自動化を改善することに重点を置いた協調的なデータ管理プラクティスです。 DataOps の目的は、データ、データ モデル、および関連する成果物の予測可能なデリバリーと変更管理を作成することで、より迅速に価値を提供することです。 DataOps では、テクノロジを使用して、適切なレベルでガバナンスを行いながら、データ デリバリーの設計、デプロイ、管理を自動化します。また、メタデータを使用して、動的環境でのデータの使いやすさと価値を向上させます。
Azure Data Factory で DataOps を実現する方法
Azure Data Factory は、クラウド規模のデータ統合と ETL プロジェクトを簡単に構築するための視覚的なデータ パイプライン パラダイムをデータ エンジニアに提供します。 データ ファクトリは、GitHub や Azure DevOps などの成熟したバージョン コントロール ツールとのネイティブ統合、およびより広範な Azure エコシステムに依存して、多くの組み込み機能を提供し、豊富なコラボレーション、ガバナンス、成果物のリレーションシップを含む DataOps を支援します。
具体的には、ユーザーが独自の GitHub または Azure DevOps リポジトリをデータ ファクトリに取り込むと、コミット、成果物の保存、バージョン コントロールなどの一般的なコマンド用の直感的な組み込み UI オプションが提供されます。 また、このサービスには、CI/CD とコード チェックインのベスト プラクティスを提供して、運用環境のサニティと正常性を保護するオプションも用意されています。
Azure Data Factory の "コード"
パイプライン、リンク サービス、トリガーなど、Azure Data Factory 内のすべての成果物には、ビジュアル UI 統合の背後にある JSON に対応する "コード" 表現があります。 これらの成果物は、Azure Resource Manager テンプレート 標準に準拠して作用します。 コードを見つけるには、キャンバスの右上にあるブラケット アイコンをクリックします。 サンプルの JSON "コード" は次のようになります。
ライブ モードと Git バージョン コントロール
すべてのファクトリには、信頼できる 1 つの情報源があります。そのような情報源としては、パイプライン、リンク サービス、サービス内に格納されているトリガー定義があります。 この信頼できる情報源は、パイプライン実行が実行するものであり、トリガーの動作を決定するものになります。 ライブ モードの場合、発行のたびに、単一の信頼できる情報源が直接変更されます。 次の図は、ライブ モードの [すべて発行] (Publish All) ボタンの外観を示しています。
ライブ モードは、開発者がコード変更の即時の影響を確認できるため、サイド プロジェクトの作業を 1 人で行っている場合には便利です。 ただし、開発者がチームで運用レベルの作業プロジェクトに取り組んでいる場合には推奨されません。 タイプ ミス、重要なリソースの誤削除、テストされていないコードの発行など、数多くの危険があります。 ミッション クリティカルなプロジェクトやプラットフォームで作業している場合は、Git リポジトリの導入を検討し、データ ファクトリで Git モードを使用して、開発プロセスを効率化します。 Git モードのバージョン コントロール機能とゲート チェックイン機能は、ライブ モードに直接触れることに関連する事故のほとんど (すべてではないにしても) を防ぐのに役立ちます。
Note
Git モードでは、[発行] (Publish) または [すべて発行] (Publish All) ボタンが [保存] または [すべて保存] に置き換えられ、変更は独自のブランチにコミットされます (ライブ コード ベースは直接変更されません)。
GitHub と Azure DevOps 統合の設定
Azure Data Factory では、GitHub または Azure DevOps にリポジトリを格納することを強くお勧めします。 このサービスではどちらの方法も完全にサポートされています。どちらのリポジトリを選択して使用するかは、個々の組織の標準によって決まります。 新しいリポジトリを設定する方法と、既存のリポジトリに接続する方法があります。Azure portal を使用するか、Azure Data Factory Studio UI から作成します。
Azure portal ファクトリの作成
Azure portal から新しいデータ ファクトリを作成すると、既定の Git リポジトリは Azure DevOps になります。 リポジトリとして GitHub を選択し、リポジトリ設定を構成することもできます。
Azure portal から、リポジトリの種類を選択し、リポジトリとブランチの名前を入力して、Git とネイティブに統合された新しいファクトリを作成します。
組織内の Azure Policy で Git の使用を強制する
Azure Data Factory プロジェクトでは、ベスト プラクティスとして Git を使用することが強く推奨されます。 完全な CI/CD プロセスを実装していない場合でも、Git と ADF の統合により、独自のサンドボックス環境 (Git ブランチ) にリソース成果物を保存できるようになります。この環境で、他のファクトリ ブランチとは独立して変更をテストできます。 Azure Policy を使用すると、組織のファクトリで Git の使用を強制できます。
Azure Data Factory Studio
データ ファクトリを作成してから、Azure Data Factory Studio を使用してリポジトリに接続することもできます。 [管理] タブには、リポジトリとリポジトリの設定を構成するオプションが表示されます。
ガイド付きのプロセスで一連の手順が実行されるので、選択したリポジトリの構成と接続を簡単に行えます。 設定が完了したら、共同作業を開始し、リソースをリポジトリに保存できます。
継続的インテグレーションと継続的デリバリー (CI/CD)
CI/CD はコード開発のパラダイムであり、変更の検査とテストは、開発、テスト、ステージングなど、さまざまなステージの進捗に応じて行われます。変更は、各ステージでレビューとテストが行われた後で、最終的に運用環境のライブ コード ベースに発行されます。
継続的インテグレーション (CI) は、開発者がコードベースに変更を行うたびにテストと検証を自動的に行う手法です。 継続的デリバリー (CD) は、継続的インテグレーション テストが成功すると、その変更が次のステージに継続的に導入されることを意味します。
前に簡単に説明したように、Azure Data Factory の "コード" は Azure Resource Manager テンプレート JSON の形式になります。 そのため、継続的インテグレーションとデリバリー (CI/CD) プロセスを経る変更は、JSON BLOB への追加、削除、編集で構成されます。
Azure Data Factory でのパイプライン実行
Azure Data Factory の CI/CD について説明する前に、まず、サービスでパイプラインがどのように実行されるかについて説明する必要があります。 データ ファクトリは、パイプラインを実行する前に、次のことを行います。
- パイプラインの最新の発行済み定義とその関連資産 (データセットやリンク サービスなど) をプルします。
- パイプラインをアクションにコンパイルします。データ ファクトリでそのパイプラインが最近実行された場合は、キャッシュされたコンパイルからアクションを取得します。
- パイプラインを実行します。
パイプラインの実行では、次の手順のようになります。
- サービスによって、パイプライン定義のポイントインタイム スナップショットが作成されます。
- パイプラインの実行中に、定義は変更されません。
- パイプライン実行が長時間にわたる場合でも、パイプラインはその開始後に行われた後続の変更の影響を受けません。 実行中に変更をリンク サービスやパイプラインなどに発行しても、進行中の実行には影響しません。
- 変更を発行すると、発行後に開始された後続の実行では、更新された定義が使用されます。
Azure Data Factory での発行
発行を自動化するために Azure Release Pipeline でパイプラインをデプロイする場合でも、Resource Manager テンプレートの手動デプロイでパイプラインをデプロイする場合でも、バックエンドでは、発行は各成果物のデータセット、リンク サービス、パイプライン、トリガーに対する一連の作成/更新操作です。 この効果は、基になる Rest API 呼び出しを直接行うのと同じです。
このアクションにより、次のようになります。
- これらの API 呼び出しはすべて同期的です。つまり、呼び出しは、発行が成功または失敗した場合にのみ返されます。 成果物の部分デプロイという状態は存在しません。
- API 呼び出しは、ほぼ順次処理されます。 成果物の参照依存関係を維持しながら、呼び出しを並列化するようにしています。 デプロイの順序は、リンク サービス -> データセット/統合ランタイム -> パイプライン -> トリガーです。 この順序により、依存成果物がその依存関係を正しく参照できるようになります。 たとえば、パイプラインはデータセットに依存するため、データ ファクトリはデータセットの後にそれらをデプロイします。
- リンク サービス、データセットなどのデプロイはパイプラインから独立しています。 パイプラインが更新される前に、データ ファクトリがリンク サービスを更新する場合があります。 この状況については、「トリガーを停止するタイミング」セクションで説明します。
- デプロイしても、ファクトリから成果物は削除されません。 ファクトリをクリーンアップするには、成果物の種類 (パイプライン、データセット、リンク サービスなど) ごとに DELETE API を明示的に呼び出す必要があります。 例については、Azure Data Factory のデプロイ後スクリプトのサンプルを参照してください。
- ユーザーがパイプライン、データセット、リンク サービスに触れていない場合でも、ファクトリへのクイック更新 API 呼び出しが呼び出されます。
トリガーの発行
- トリガーには、開始または停止の状態があります。
- 開始モードのトリガーを変更することはできません。 変更を発行する前にトリガーを停止する必要があります。
- 開始モードのトリガーで、トリガー API の作成または更新を呼び出すことができます。
- ペイロードが変更されると、API は失敗します。
- ペイロードが変更されていない場合、API は成功します。
- この動作は、トリガーを停止するタイミングに大きな影響を与えます。
トリガーを停止するタイミング
ライブ トリガーによってパイプライン実行が常に開始される運用データ ファクトリへのデプロイについて、問題は "トリガーを停止する必要があるか" ということです。
簡単に答えるなら、次のいくつかのシナリオでのみ、トリガーの停止を検討する必要があります。
- トリガー定義 (終了日、頻度、パイプラインの関連付けなどのフィールドを含む) を更新する場合は、トリガーを停止する必要があります。
- ライブ パイプラインで参照されているデータセットまたはリンク サービスを更新する場合は、トリガーを停止することをお勧めします。 たとえば、SQL Server の資格情報をローテーションする場合です。
- 関連付けられているパイプラインでエラーがスローされ、サーバーの障害や負荷の原因になっている場合は、トリガーを停止できます。
トリガーの停止に関して考慮すべきいくつかの点を次に示します。
- 「Azure Data Factory でのパイプライン実行」セクションで説明されているように、トリガーがパイプライン実行を開始すると、パイプライン、データセット、統合ランタイム、リンク サービスの定義のスナップショットが作成されます。 変更前のパイプライン実行がバックエンドに設定されていると、トリガーは古いバージョンで実行を開始します。 ほとんどの場合、これで問題ありません。
- 「トリガーの発行」セクションで説明されているように、 開始状態のトリガーは更新できません。 そのため、トリガー定義の詳細を変更する必要がある場合は、変更を発行する前にトリガーを停止します。
- 「Azure Data Factory での発行」セクションで説明されているように、データセットやリンク サービスに対する変更は、パイプライン変更の前に発行されます。 パイプライン実行で正しい資格情報が使用され、適切なサーバーと通信が行われるようにするため、関連付けられているトリガーも停止することをお勧めします。
"コード" 変更の準備
pull request に関しては、以下のベスト プラクティスに従うようお勧めします。
- 各開発者は、それぞれ自分のブランチで作業し、1 日の終わりにリポジトリのメイン ブランチへの pull request を作成する必要があります。 GitHub と DevOps の pull request に関するチュートリアルを参照してください。
- ゲート キーパーが pull request を承認し、変更をメイン ブランチにマージすると、CI/CD プロセスを開始できます。 環境全体で変更を促進するための推奨される手法として、自動 と 手動の 2 つがあります。
- CI/CD パイプラインを開始する準備ができたら、一般的には Azure Pipeline Release を使用してこれを行いますが、Azure Player からこのオープンソース ユーティリティを使用して特定の個々のパイプラインのデプロイを行うこともできます。
変更の自動デプロイ
自動デプロイの助けとして、Azure Data Factory ユーティリティ npm パッケージを使用することをお勧めします。 npm パッケージを使用することは、パイプライン内のすべてのリソースを検証し、ユーザーの ARM テンプレートを生成するのに役立ちます。
Azure Data Factory ユーティリティ npm パッケージの使用を開始するには、「継続的インテグレーションおよびデリバリーの自動発行」を参照してください。
変更の手動デプロイ
Git リポジトリのメイン コラボレーション ブランチにブランチをマージし直したら、ライブ Azure Data Factory サービスに変更を手動で発行できます。 このサービスでは、開発以外のファクトリからの発行を、[発行を無効にする (ADF Studio から)] (Disable publish (from ADF Studio)) オプションを使用して UI で制御できます。
選択的デプロイ
選択的デプロイは、チェリー ピックと呼ばれる GitHub と Azure DevOps の機能に依存します。 この機能を使用すると、特定の変更のみがデプロイされ、他の変更はデプロイされないようにすることができます。 たとえば、1 人の開発者が複数のパイプラインに変更を加えはしたものの、今日のデプロイでは、変更を 1 つだけにデプロイしたい場合があります。
Azure DevOps と GitHub のチュートリアルに従って、必要なパイプラインに関連するコミットを選択します。 トリガー、リンク サービス、およびパイプラインに関連付けられている依存関係に対して行われた関連する変更など、すべての変更が選択されていることを確認します。
変更をチェリー ピックし、メイン コラボレーション パイプラインにマージしたら、提案された変更の CI/CD プロセスを開始できます。 選択的デプロイのための外部フレームワークを修正、チェリー ピック、または利用する方法に関する追加情報は、この記事の「自動テスト」セクションで説明されています。
単体テスト
単体テストは、新しいパイプラインの開発プロセスや既存のデータ ファクトリ成果物の編集プロセスの重要な部分で、コードのコンポーネントをテストすることに重点が置かれています。 Data Factory では、パイプライン デバッグ機能を使用することにより、パイプライン レベルとデータ フロー成果物レベルの両方で個別に単体テストを行うことができます。
データ フローを開発するときは、データ プレビュー機能を使用して、変更を運用環境にデプロイする前に単体テストを実行することにより、個々の変換とコード変更に関する分析情報を得ることができます。
このサービスでは、Azure Data Factory でデバッグや単体テストを行う際に、パイプライン アクティビティのライブ フィードバックと対話型フィードバックが UI で提供されます。
自動テスト
自動テストには、Azure Data Factory で使用できるツールがいくつかあります。 このサービスではサービス内のオブジェクトが JSON エンティティとして格納されるため、Visual Studio でオープンソースの .NET 単体テスト フレームワーク NUnit を使用すると便利です。 ファクトリの自動単体テスト環境を設定する方法の詳細については、「Setup automated testing for Azure Data Factory」(Azure Data Factory の自動テストを設定する) という投稿を参照してください。 (このブログの使用許可に関して、Richard Swinbank 氏に感謝します。)
デプロイ前とデプロイ後の手順の CI/CD プロセスの一環として、PowerShell または AZ CLI で、TEST パイプラインを実行することもできます。
データ ファクトリの主な強みは、データ セットのパラメーター化にあります。 この機能を使用することで、異なるデータ セットで同じパイプラインを実行して、新しい開発がすべてのソースとターゲットの要件を満たしていることを確認できます。
Azure Data Factory のその他の CI/CD フレームワーク
前に説明したように、組み込みの Git 統合は、マージ、分岐、比較、パブリケーションなど、Azure Data Factory UI を介してネイティブに使用できます。 ただし、Azure コミュニティで一般的に使用され、同様の機能を実現する別のメカニズムを提供する便利な CI/CD フレームワークが他にもあります。 Azure Data Factory Git の手法は ARM テンプレートに基づいていますが、Kamil Nowinski が開発した ADFTools のようなフレームワークは、代わりにファクトリからの個々の JSON 成果物に依存することで、異なるアプローチを採用しています。 Azure DevOps に精通しており、その環境 (サービスですぐに利用できる ARM ベースの UI アプローチではなく) で作業することを好むデータ エンジニアは、このフレームワークが自分に合っていて、部分的なデプロイなどの一般的なシナリオに適していると感じる場合があります。 このフレームワークでは、実行中のトリガー状態を持つ環境にデプロイするときのトリガーの処理を簡略化することもできます。
Azure Data Factory でのデータ ガバナンス
効果的な DataOps の重要な側面は、データ ガバナンスです。 データ統合 ETL ツールでは、データ系列と成果物のリレーションシップを提供することで、ダウンストリームの変更の影響をデータ エンジニアが理解するための重要な情報を提供できます。 データ ファクトリには、ファクトリの実装を構成する組み込みの関連成果物ビューが用意されています。
Microsoft Purview とのネイティブ統合により、系列、影響分析、データ カタログ作成がさらに提供されます。
Microsoft Purview は、オンプレミス、マルチクラウド、サービスとしてのソフトウェア (SaaS) のデータを管理・統制するための統合データ ガバナンス ソリューションを提供します。 これにより、自動化されたデータ検出、機密データ分類、エンドツーエンドのデータ系列を使用して、データ環境全体の最新のマップを簡単に作成できるようになります。 これらの機能により、データ コンシューマーは貴重で信頼できるデータ管理を利用できるようになります。
Purview データ カタログへのネイティブ統合により、データ統合パイプラインで使用するデータ資産を、組織のデータ資産全体からデータ ファクトリで簡単に検索および検出できます。
Azure Data Factory Studio のメイン検索バーを使用して、Purview カタログ内のデータ資産を検索できます。
