Azure Data Factory（ADF）入門｜オンプレETLをクラウドへ移行するパイプライン設計とAWS Glueとの比較ガイド

オンプレミスのETL基盤（Informatica、SSIS、独自シェルスクリプト）をAzureに移行しようと調べ始めると、「Azure Data Factory」と「Azure Synapse Analytics」が同時に出てきて、どちらを使えばいいのか迷うことがある。さらにAWSのGlueと比べてどう違うのかも気になる。

この記事では、Azure Data Factory（以下ADF）について、オンプレのETL経験者にもわかりやすく解説する。基本概念・料金・パイプライン設計のポイント・AWS Glueとの違いまでを実務目線で整理する。

なぜAzure Data Factoryなのか？（オンプレETLとの違い）

オンプレのETL基盤が抱える典型的な課題を振り返ってみよう。

・実行環境の管理コスト: ETLサーバーのOS管理・パッチ当て・スケールアップ対応が常に必要
・スケジューラーの属人化: cronやタスクスケジューラーに複雑な依存関係が積み上がり、障害時の影響範囲が読めない
・接続先の多様化への対応: クラウドストレージ・SaaS・オンプレDBと接続先が増えるたびに個別実装が必要になる
・モニタリングの貧弱さ: ログはファイルに出力されるだけで、実行状況の可視化・アラート設定が手間

ADFはこれらをすべてマネージドで解決するサービスだ。ETLパイプラインの定義・スケジューリング・実行・モニタリングをAzureポータル上で一元管理できる。サーバーを1台も立てずに、ストレージ間のデータ移動・変換・ロードが実現する。

重要なのは、ADFは「実行エンジン」ではなく「オーケストレーター」だという点だ。変換処理の重い計算をADF自体がこなすわけではなく、Azure Databricks・Azure SQL Database・HDInsight等の実行エンジンを呼び出してパイプラインを組む設計思想になっている。

Azure Data Factoryの基本概念

ADFを使いこなすには、4つのコアコンセプトを押さえる必要がある。

1. Pipeline（パイプライン）

一連の処理フローをまとめたワークフローの単位。「毎朝5時にS3互換ストレージからAzure SQL Databaseへデータを転送する」といった一連の処理を、Activityの組み合わせで定義する。

# パイプラインのJSON定義例（概念的な構造）
{
  "name": "CopyFromBlobToSQL",
  "activities": [
    {
      "name": "CopyActivity",
      "type": "Copy",
      "inputs": [{ "referenceName": "BlobDataset" }],
      "outputs": [{ "referenceName": "SQLDataset" }]
    }
  ]
}

2. Activity（アクティビティ）

パイプライン内の個々の処理ステップ。代表的なActivityは次のとおりだ。

・Copy Activity: データ移動の主役。100種類以上のコネクタ経由でデータをコピーする
・Data Flow Activity: Sparkベースのコードレスデータ変換。GUIでマッピングを定義できる
・Lookup Activity: データソースからレコードを取得して後続Activityに渡す
・Execute Pipeline Activity: 別パイプラインを子として呼び出す
・Web Activity: 外部HTTP APIを呼び出す
・Databricks Notebook Activity: Azure Databricks上のノートブックを実行する

3. Dataset（データセット）

データの「形」の定義。BlobストレージのCSVファイル、Azure SQLのテーブル、REST APIのエンドポイントなど、入出力データの構造情報をもつ。Linked Serviceと紐づけて、どこにある何の形のデータかを表現する。

4. Linked Service（リンクされたサービス）

外部システムへの接続情報（いわゆる接続文字列）をまとめた設定。Azure Blob Storage、Azure SQL Database、オンプレのSQL Server、AWSのS3、Salesforce等への認証・接続情報を一か所に管理する。認証情報はAzure Key Vaultと連携して安全に保管できる。

Integration Runtime（IR）の選び方

ADFのもう一つの重要概念が Integration Runtime（IR） だ。これはパイプラインを実際に動かす「実行エンジンの場所」を決める設定で、3種類ある。

・Azure IR: Azure側のマネージド環境で実行。パブリックに公開されているデータソースへのアクセスが前提。最も手間がかからない
・Self-hosted IR: オンプレのサーバー上にエージェントを配置し、社内ネットワーク内のDBや共有ファイルサーバーへアクセスする。VPNやExpressRoute不要でオンプレDB連携が可能になる点が大きなメリット
・Azure-SSIS IR: Azure上でSSISパッケージをそのまま動かすための環境。既存のSSIS資産を移行する際に使う

オンプレのOracleやSQL Serverと連携するケースでは Self-hosted IR が必須になる。1台のWindowsサーバーに4コア・8GBメモリ程度あれば動作するが、エージェントのバージョン管理や可用性設計（アクティブ/スタンバイ構成）が運用上のポイントになる。

料金の仕組み（コスト感覚）

ADFの料金は「何をどれだけ動かしたか」で課金される。主な課金軸は3つだ（2026年8月時点・東日本リージョン）。

1. Orchestration（オーケストレーション）

パイプラインの実行回数・アクティビティ実行数に対する課金。1,000アクティビティ実行あたり約$1（Azure IRの場合）。

2. Data Movement（データ移動）

Copy Activityによるデータ転送量と実行時間に課金。Azure IR使用時は1 DIU（Data Integration Unit）時間あたり約$0.25。DIUはコピー処理の並列度を表す単位で、デフォルトはAutoだが上限設定が可能だ。

3. Data Flow（データフロー）

GUI上でSparkクラスターを動かす変換処理。vコア時間単位で課金。General Purposeで1 vコア時間あたり約$0.272。小さいSparkクラスターを短時間動かすだけでも積み上がるため、不要な変換処理はSQL側に任せるほうがコスト効率がよいことが多い。

コスト概算の例

注意点: Data Flowのクラスターはパイプライン実行ごとに起動・停止するため、起動オーバーヘッドが1～2分発生する。高頻度バッチでは「クラスター再利用」（TTL設定）を使うと起動コストを抑えられる。

AWS Glueとの比較

AWSのGlueと比較されることが多いため、主な違いを整理しておく。

インフラエンジニアの感覚で言うと、ADFは「GUIで直感的にパイプラインを組みたい」「Pythonは書けるがSparkには詳しくない」「SalesforceやServiceNowとの接続も必要」というケースに向いている。GlueはS3上の大量データをSparkで本格変換したいという重めのETLに強い印象だ。

どちらを選ぶかはAzureメインかAWSメインかの環境要因が大きく、マルチクラウド環境ではADFのほうがコネクタの多様性が有利に働く場面がある。

パイプライン設計の実践Tips

1. 失敗時の再実行を考慮したべき等設計

ADFのCopy Activityは途中失敗すると再実行が必要になる。SQLへの書き込みはUPSERT（MERGE文）かStaging Tableを経由した洗い替えで設計しておくと、再実行しても重複レコードが生じない。

2. パラメーターの活用

テーブル名・ファイルパス・日付をパイプラインのパラメーターとして外出しすることで、同じパイプライン定義を複数ソースに再利用できる。「ForEachアクティビティ + Lookup」の組み合わせでメタデータ駆動型のパイプライン（処理対象テーブル一覧をDB管理する方式）が組める。

3. トリガーの種類と使い分け

・スケジュールトリガー: 定時実行。cronライクな設定でUTC/ローカル時刻指定が可能
・タンブリングウィンドウトリガー: 時間ウィンドウ単位で連続実行。過去分の再処理（バックフィル）が前後の依存関係を保ちながら自動実行できる
・イベントトリガー: Blob StorageへのファイルアップロードやAzure Event Gridのイベントで起動

4. モニタリングとアラート

ADFには専用のMonitor画面があり、パイプラインの実行履歴・失敗原因・所要時間がGUIで確認できる。Azure Monitorと連携することで、失敗時にメール通知やTeams通知を飛ばす設定も数分で完了する。

よくあるトラブルと対処法

Self-hosted IRが突然切断される

社内の電源管理ポリシーや動的IP変更、Windowsの自動更新でエージェントが停止するケースが多い。対処は2点：IRエージェントの自動起動設定を確認すること、本番環境では2台以上のスタンバイ構成にすること。ADFコンソールの「IR状態」が「オフライン」になればすぐに気づける。

Copy Activityのパフォーマンスが遅い

DIU数のデフォルト（Auto）が低く設定された状態で大量データをコピーしようとすると数時間かかることがある。DIU上限を明示的に設定（最大256）するか、Parallelコピーの設定でファイル単位の並列度を上げると改善する。ソース側のネットワーク帯域も確認すること。

Data Flowが高コストになる

GUIでデータ変換を追加するほどSpark処理が増え、vコア時間が積み上がる。単純な列選択・フィルタ・型変換のみならCopy ActivityのMapping機能（コードレス）で完結させ、Data Flowは使わないほうがコスト効率がよい。複雑な集約・Joinがある場合のみData Flowを使う判断基準が妥当だ。

Azure Blob Storageへの書き込み権限エラー

Linked Serviceのマネージドアイデンティティ認証を使っている場合、Azure Blob Storage側のIAMロール（Storage Blob Data Contributor）が割り当たっていないと失敗する。アクセスキー認証に比べてセキュリティ的に優れているため、マネージドアイデンティティ推奨だが、ロールの割り当て漏れが典型的なハマりポイントだ。

本記事のまとめ

Azure Data Factoryは、オンプレのETL基盤をサーバーレスで置き換える際の選択肢として十分に実用的なサービスだ。特に次のようなケースでは導入効果が高い。

・GUIベースで素早くパイプラインを構築したい
・SaaSやオンプレDBを含む100種類以上のコネクタを使いたい
・既存のSSIS資産をそのままAzure上で動かしたい
・Azure Databricksとの連携で本格的なデータ基盤を構築したい

一方でSparkによる大規模変換が主目的であればAWS Glueの検討も合理的だ。AzureエコシステムでのデータパイプラインならADF、ETL変換の深さを重視するならAWS Glue（AWSメイン環境の場合）という使い分けが現場では多い。

料金面は使い方次第で大きく変わるため、まずはAzure Cost Managementで実際の利用コストを週次で確認する習慣をつけることを勧める。データ移動量とData Flow実行時間が主要な課金ドライバーになるため、最初の1か月は予算アラートを設定して監視しながら運用することが望ましい。

ETLとELTのどちらの設計パターンが自社の要件に合っているかについては、ETLとELTの違いの記事もあわせて参照してほしい。