Azure Data Factoryに入門する

Azureクラウド。データと特にAIの世界で頭ひとつ抜け出しそうだ。
有限な時間を有効に使うには、”ベストソリューション”に全振りすることが適切だと信じているが、
一方で、それだと認知の奥行きのようなものが少ない気がしている。
考え方を広げるには色々知るべきだとも思う。

知識を糧にするために必要なことは要約と文書化だと信じている。
データ・パイプラインを構築する数多の技術の1つとして、Azure Data Factoryがある。
今回、Azure Data Factoryに入門してみようと思う。

Azureクラウドは公式の説明に癖がある。
分かるまでとっつきづらい印象がある。知識を糧にするため要約と文書化を続けてみたい。

パイプライン、アクティビティ、データセット、リンクされたサービス

データが物理的に格納されている場所をデータセットとリンクする。「リンクサービス」などと言う。
対応するサービスは後述する。
アクティビティには入力データセットと出力データセットを設定できる。
アクティビティは入力データセットのデータを消費し、出力データセットにデータを生成する。
アクティビティは大きく「データのコピー」と「データの変換」と「制御」の責務を持たせられる。
複数のアクティビティを束ねてパイプラインを構成する。これらの関係は下図の通り。

このうち「制御」アクティビティは、変数の追加、別のパイプラインの実行、Assert、ForEach、
If Condition、ルックアップ、変数の設定、Until、検証、Wait、Web、Webhookなどができる。

ユーザは、UI上でポチポチしてパイプラインを組み上げられる。
下図のように、アクティビティの出力を別のアクティビティの入力とすることで機能を作り込んでいく。
前のアクティビティが正常終了しなかった場合、次のアクティビティは実行されない。
もちろん並列実行させることもできる。

サポートするデータストア・コネクタ

移動アクティビティは、ソースからシンクへデータをコピーする。
サポートされているデータストアは公式に記述があるが、一部記述に矛盾があり信用できない。
Azure Data Factory と Azure Synapse Analytics のコネクタの概要

さすがに仕様上は凄まじいサポート具合だと思う。[汎用]により事実上無限に繋げられる。

[Azure]
Blob, Cognitive Search Index, CosmosDB, Data Explore, ADSL Gen1/Gen2,
Azure Database (MariaDB/PostgreSQL/MySQL), Databricks Delta Lake,
Files, SQL Database, SQL Managed Instance, Synapse Analytics, Table Storage
[Database]
AWS RDS(Oracle, SQL Server), AWS Redshift, DB2, Drill, GCP BigQuery,
GreenPlum, HBase, Apache Impala, Informix, MariaDB, Microsoft Access,
MySQL, Netezza, Phenix, PostgreSQL, SAP Business Warehouse,
SAP HANA, Snowflake, Spark, SQL Server, Sybase, Terradata, Vertica
[NoSQL]
Cassandra, MongoDB
[Files]
S3, FileSystem, FTP, GCP Cloud Storage, HDFs, Oracle Storage, SFTP
[サービスとアプリ]
Amazon Marketplace WebService, Appfingures, Asana, Concur,data world,
Dataverse, Dynamics365, Dynamics AX, Dynamics CRM, GitHub,
Google AdWords, Google Spredsheet, HubSpot, Jira, Magento,
Microsoft365, Oracle Eloqua, Oracle Responsys, Oracle Service Cloud,
Paypal, Quickbase,Quick Books,Salesforce, Salesforce Service Cloud,
Sales Marketing Cloud, C4C, SAP ECC, Service Now, SharePoint Online,
Shopify, SmartSheet, Square, TeamDesk, Twillo, Web(HTML), Xero,
Zen Desk, Zoho
[汎用]
HTTP, OData, ODBC, RESTfulAPI

ファイル形式は以下。
Arvo,バイナリ,Common Data Model形式,区切りテキスト, 差分形式, Excel, JSON,
ORC, Parquet, XML

スケジュール設定と実行

「スケジュール」と名前が付くものがパイプライン、アクティビティ、データセットに存在するが、
パイプラインの実行時刻・タイミングを定義するのは「出力データセット」であるようだ。
アクティビティの実行タイミングは、入力ではなく出力のデータセットのスケジュールで決まる。
このため、入力データセットは省略できるが、出力データセットは必ず1個作る必要がある。

アクティビティと入出力データセットの関係が下図に示されている。
出力データセットが、「8-9AM」、「9-10AM」、「10-11AM」の3回の枠でスケジュールされている。
それに合わせてアクティビティと入力データセットのスケジュールが決まる。
下図はさらに、入力が準備され、アクティビティと出力がこれから実行される様を表している。

アクティビティにスケジュールをオプションで設定できるが、
その場合は出力データセットのものと合わせる必要がある。(何の意味があるのか…)

パイプラインにパイプラインがアクティブな期間を設定できる。
非アクティブな時間に出力データセットが発火しても無視される。

統合ランタイム(IR)

Azure内のフルマネージドなサーバーレスコンピューティング。

仮想化されたコンピューティングリソースをData Factoryでは統合ランタイムと呼ぶ。
悪いセンスの極みみたいな名前だが、Windowsで開発した経験があるとピンと来ると思う。

アクティビティや入出力データセットで定義された内容を処理する際に消費される計算資源。

各処理がどこで実行されるのか、というのはパイプラインの実行で気になるポイント。
可能な限りデータの移動やコピーは省略して欲しいし、各サービスが得意な機能を使って欲しい。
この辺りを最大限考慮して必要な場所で処理するよ、と公式には書かれている。

3種類の統合ランタイムが存在する。

Azure統合ランタイム

Azureでデータフローを実行する。クラウドストア間でコピーアクティビティを実行する。
コピーは負荷が高い操作であるので、オートスケールが考慮されている。
他に、アクティビティの負荷をコンピューティングに割り当てる(ディスパッチ)機能を有する。

Self-Hosted統合ランタイム

オンプレミスかAzure上のプライベートネットワークにインストールするコンピューティングリソース。
Windowsマシンを自前で用意(Self-Host)して、Azureサービスに提供するというもの。
まさにMicrosoftのWindowsをAzureと繋ぐコンピューティング仮想化の姿とも言える。
オンプレミスに大量のコンピュータを用意してAzureに提供したりすることができる。

Azure-SSIS統合ランタイム

SSIS(SQL Server Integration Service)パッケージを実行する専用のAzure上の
フルマネージドクラスタ。
SSISプロジェクト用に独自のAzureSQL Database、SQL Managed Instanceを持ち込める。
ノードサイズのスケールアップ、クラスターのスケールアウトを実行できる。
SSIS統合ランタイムを手動で停止することでコストを節約することもできる。
SSDTやSSMS等、SQLServer用クライアントツールをSSIS統合ランタイムに繋ぐことができる。

統合ランタイムの場所

仮想マシンがAzureクラウド上のどこに物理的に配置されるのかは気になるところ。
一般に性能観点だけであればデータに近いところに仮想マシンを配置しておくと良い結果となる。
が、データコンプライアンスの観点で、仮想マシンを配置する場所を固定しないといけない場合がある。

Azure IR

Azure IRについて、デフォルトでは自動的に配置場所が決まる。
つまり、シンクデータストアと”同じリージョン”または”同じ地理的な場所”に配置される。
クラウドサービスを使っていると、そのサービスのリージョン、地理的な場所が不定となる場合がある。
シンクデータストアの場所がわからず、世界中の好き勝手なところにAzure IRが作られてしまう。
そんな時は、自動的なコンフィグレーションを無視して配置場所を固定することができる。

また、データが特定のリージョンから離れないように、明示的にVMの場所を固定できる。

Self-hosted IR

Self-hostするものなので、そもそも場所は自分で決めるもの。

Azure-SSIS IR

箱としてのデータベースと、そのデータベースを駆動するコンピューティングリソースが分離している。
普通に考えて、箱の場所とVMの場所は同じにしないとパフォーマンスが悪いだろう。(公式に記載あり)
ただし、Data FactoryとSSIS IRの場所は必ずしも同じでなくても良いようだ。

データ統合単位(DIU)

なんか説明なくいきなり出てくるワード。Data Integration Unitの略だろうか。
Azure Data Factoryにおいて、1つの単位の能力を表す尺度。
CPU、メモリ、ネットワークリソース割り当てを組み合わせたもの。
DIUはAzure IRランタイムにのみ適用される。Self-hostedランタイムには適用されない。
要はAzure IRランタイムの戦闘力を数値化したもの。課金に影響する。
データ統合単位

シナリオにあった統合ランタイムの選択

Azure統合ランタイムからパブリックにアクセスできないデータストアにアクセスする場合、
データストアのファイアウォールなどにAzure統合ランタイムのパブリックIPを設定して抜け穴を作る。
しかし、Azureを含むクラウドアーキテクチャの設計においてあまり望ましくない。
よりベターなのは、PrivateLinkや、Load Balancerの追加セットアップを行う。
また、オンプレミスにある場合、Express Route、S2S VPN経由でアクセスを行う。
この追加セットアップは必要以上に面倒を増やすし、最初からSelf-Hostedにした方が良い。

Enterpriseの現場において、データ転送の経路に対するセキュリティ要件は厳しい。
転送経路が全てプライベートになっている状態を保証できることが理想となる。
つまり、プライベートエンドポイント間のPrivateLinkを設定することが理想である。
Azure統合ランタイムは、デフォでプライベートエンドポイントとPrivateLinkはサポートされない。
マネージド仮想ネットワークを使用すると、データストアに対してプライベートエンドポイントを設定し、
統合ランタイムをPrivateLinkを設定できる。
また、Self-hosted統合ランタイムにおいて、仮想ネットワークにプライベートエンドポイントと
PrivateLinkを設定できる。

クラウドインフラストラクチャの責任共有モデルについての議論もある。
Azure統合ランタイムのパッチ、バージョン更新等のメンテナンスはAzure側が自動的に行う。
対して、Self-hosted統合ランタイムは、ユーザが責任を持つ必要がある。
より楽をしたいならAzure統合ランタイムがより良い選択肢となる。

まとめ

ドキュメントを調べてAzure Data Factoryの用語をまとめてみた。
Azureクラウドの公式ドキュメントは癖があり、ドキュメントを読むだけで一苦労だなという印象。
やはり、AWSと比較してEnterpriseを全面的に推している印象がある。
後続の記事でガンガン知識を文書化していく。