Azure Data Factory（ADF）で「ソースは Azure IR からしか届かない File Share」「シンクは Self-hosted IR からしか届かない SFTP」という構成は、現場でよく遭遇します。本記事では、このような“IR が分断された”環境で、どこまで直接コピーができるのか、そして公式に推奨される中継ストレージ経由のベストプラクティスを、設計と運用の両面から詳しく解説します。
シナリオ整理：Azure IR と Self-hosted IR が分かれているケース
まずは今回の前提条件を整理します。
| 項目 | 内容 |
|---|---|
| ソース | File Share（オンプレ／IaaS／Azure Files など） Azure 統合ランタイム（Azure IR）からのみ到達可能 |
| シンク | SFTP サーバー 自己ホスト型統合ランタイム（Self-hosted IR／SHIR）からのみ到達可能 |
| 現在の運用 | Azure IR で中継ストレージへコピー → SHIR で中継ストレージから SFTP へコピー（2 段構成） |
| 確認したい点 | より良い・新しい「公式に推奨される」方法があるか？ |
結論から言うと、このシナリオでは現在実施している「中継ストレージ＋二段階コピー」が、そのまま正攻法であり、最新ドキュメントとも整合する構成です。後ほど代替案も紹介しますが、「単一コピーアクティビティで Azure IR と Self-hosted IR をブリッジするような新機能」は、現時点では提供されていません。
Azure Data Factory の統合ランタイムの基本と制約
統合ランタイム（Integration Runtime）の種類
ADF には主に次の 3 種類の統合ランタイム（IR）が存在します。
| 種類 | 用途 | 代表的なシナリオ |
|---|---|---|
| Azure IR | Microsoft 管理のクラウド IR。パブリックなクラウドサービス間のコピーや Data Flow など。 | Blob ⇔ ADLS Gen2、SQL DB ⇔ Blob などインターネット到達可能なデータストア。 |
| Self-hosted IR（SHIR） | ユーザー管理の Windows マシン上にインストール。オンプレ／閉域網リソースへのゲートウェイ。 | オンプレ DB ⇔ Azure、VNet 内の SFTP ⇔ Azure など。 |
| Azure-SSIS IR | SSIS パッケージ実行専用 IR。 | 既存 SSIS 資産をそのままクラウド実行。 |
コピーアクティビティはどの IR で実行されるのか
コピーアクティビティでは、ソース／シンクの Linked Service ごとに IR を設定できますが、実際にデータ移動を行うのは 1 つの IR だけです。
Microsoft のドキュメントでは、どの IR が実行に使われるかを次のように定義しています。
| ソース / シンクの組み合わせ | 実行に使われる IR | ポイント |
|---|---|---|
| 両方とも Azure IR | Azure IR | クラウドデータストア同士のコピーは Azure IR で完結。 |
| 片側が Self-hosted IR | Self-hosted IR | ソースかシンクのどちらか一方でも Self-hosted IR なら、コピーは Self-hosted IR 上で実行される。 |
| 両方とも閉域網（オンプレ/VNet） | 同一の Self-hosted IR インスタンス | 同じ Self-hosted IR から両方へ到達できる必要がある。 |
つまり、Self-hosted IR を利用するコピーの場合、その IR が「データムーバー」としてソース・シンク双方へアクセスする、というのが根本ルールになります。
片側だけ Self-hosted IR では直接コピーできない理由
今回のケースでは、Linked Service の IR は次のようになります。
| Linked Service | IR | ネットワーク到達性 |
|---|---|---|
| LS_FileShare | Azure IR | Azure IR から File Share へアクセス可能。Self-hosted IR からは不可。 |
| LS_SFTP | Self-hosted IR | Self-hosted IR から SFTP へアクセス可能。Azure IR からは不可（ファイアウォール/VNet 制約など）。 |
この状態で、Copy Activity の Source に LS_FileShare、Sink に LS_SFTP を指定するとどうなるでしょうか。
- ソース側：Azure IR を使うように見える
- シンク側：Self-hosted IR を使うように見える
しかし前述の仕様により、実際にデータを動かすのは Self-hosted IR 側のみです。
結果として、Self-hosted IR ホストから File Share と SFTP の両方に到達できない限り、単一のコピーアクティビティで File Share → SFTP を実現することはできません。Linked Service に別々の IR を指定できても、「2 つの IR が協調して動く」わけではなく、片方だけが実行役に選ばれるためです。
結論：中継ストレージ＋二段階コピーが公式の推奨パターン
Microsoft のドキュメントでは、異なる Self-hosted IR にぶら下がるデータストア間のコピーは、2 回のコピーアクティビティ＋中継ストレージで対応するよう、明示的に案内されています。
今回のケースは「Azure IR と Self-hosted IR の組み合わせ」ですが、根本ルールは同じで、
- 実際に動く IR は 1 つだけ
- その IR からソース・シンク両方へ到達できなければ単一コピーは不可
となるため、やはり中継ストレージを経由した 2 段コピーが現時点での正攻法です。
メリットも多くあります。
- コピー処理を「前半（File Share → 中継）」と「後半（中継 → SFTP）」に分離できるため、再実行や切り戻しがしやすい
- 中継ストレージにファイルが残るため、監査・検証・再送に利用できる
- 前半・後半それぞれでリトライや並列度を細かくチューニングできる
推奨構成：Blob / ADLS Gen2 を中継ストレージにする
中継ストレージ候補と選定の視点
中継ストレージには、基本的に以下のいずれかを選びます。
| 候補 | メリット | 向いているケース |
|---|---|---|
| Azure Blob Storage | 低コスト・高スループット。SFTP 機能も有効化可能。 | シンプルなファイル転送、中継専用のオブジェクトストアとして使いたい場合。 |
| Azure Data Lake Storage Gen2（ADLS Gen2） | 階層ネームスペースと POSIX 風 ACL。分析基盤と兼用しやすい。 | 中継データをそのまま分析やデータレイクに活用したい場合。 |
どちらも Azure IR から問題なくアクセスできますし、Self-hosted IR からも HTTPS でアクセス可能なため、両 IR から到達できる「ハブ」的な位置づけになります。
典型的なネットワーク・権限設計
- ストレージアカウントは Private Endpoint + VNet 統合を前提に設計し、必要なサブネットからのみ到達可能にする
- Azure IR からのアクセスには、IP 限定ルールや VNet 統合機能（Managed VNet IR）を組み合わせてセキュアにする
- Self-hosted IR ホストからは 443/TCP のインターネット／Private Endpoint へ outbound を許可する
パイプライン実装ステップ（実践例）
準備するリソース
- Azure Data Factory（または Synapse Pipeline）
- 中継用 Azure Storage（Blob or ADLS Gen2）
- Self-hosted IR ノード（1 台以上。後述のスケールアウトも検討）
Linked Service の設計例
| Linked Service 名 | 接続先 | IR | 補足 |
|---|---|---|---|
| LS_FileShare | File Share（オンプレ or Azure Files） | Azure IR | 必要に応じて Managed VNet IR を利用。 |
| LS_Staging_Cloud | 中継 Blob / ADLS Gen2 | Azure IR | 前半コピー用。 |
| LS_Staging_SHIR | 中継 Blob / ADLS Gen2 | Self-hosted IR | 後半コピー用。同じストレージだが IR だけ変えて Linked Service を分ける。 |
| LS_SFTP | 最終 SFTP サーバー | Self-hosted IR | 鍵認証を推奨。 |
パイプライン構成（ロジック）
パイプラインはシンプルに 2 段構成にします。
- Copy_FileShare_to_Staging（Azure IR）
File Share → 中継ストレージ - Copy_Staging_to_SFTP（Self-hosted IR）
中継ストレージ → SFTP
複数ファイルを扱う場合は、例えば次のような構成にできます。
- GetMetadata（File Share のディレクトリを列挙）
- ForEach（childItems）
- └ Copy_FileShare_to_Staging
- └ Copy_Staging_to_SFTP
さらに、ファイル単位でのリトライやエラー通知を細かく制御したい場合は、
- パイプライン A：File Share → 中継
- パイプライン B：中継 → SFTP
とパイプライン自体を分け、Trigger やパラメータで連携させる設計も有効です。
Copy アクティビティ JSON のイメージ
イメージがしやすいように、前半コピーの JSON（概略）を示します。
{
"name": "Copy_FileShare_to_Staging",
"type": "Copy",
"typeProperties": {
"source": {
"type": "FileSystemSource",
"recursive": true
},
"sink": {
"type": "DelimitedTextSink",
"copyBehavior": "FlattenHierarchy"
}
},
"inputs": [
{ "referenceName": "DS_FileShare", "type": "DatasetReference" }
],
"outputs": [
{ "referenceName": "DS_Staging", "type": "DatasetReference" }
]
}
Dataset の Linked Service 側で、
- DS_FileShare → LS_FileShare（Azure IR）
- DS_Staging（前半） → LS_Staging_Cloud（Azure IR）
- DS_Staging（後半） → LS_Staging_SHIR（Self-hosted IR）
というように IR を切り替えるのがポイントです。
可用性・再実行性を高める工夫
一時拡張子（.partial など）＋リネーム
大容量ファイルを SFTP へ転送する場合、転送中のファイルを別システムに読まれると不整合の原因になります。そこで、次のような運用がよく採用されます。
- 中継ストレージから SFTP へコピーするときのファイル名を「<元ファイル名>.partial」としてアップロードする
- Copy アクティビティ完了後、SFTP 上で「.partial → 本来のファイル名」にリネームする
リネームは、
- 2 本目のパイプラインで SFTP 用 Script / REST API を叩く
- Logic Apps などを併用して実行する
などで実装できます。SFTP 側から見ると「一瞬でファイルが現れる」状態にできるため、整合性の担保に役立ちます。
サイズ・ハッシュによる整合性チェック
コピーの正しさを検証するには、次のようなパターンがあります。
- 中継ストレージ上のファイルサイズと、SFTP 上のファイルサイズを GetMetadata で取得して比較
- 必要なら Azure Functions 等でハッシュ値（MD5 など）を計算して比較
- チェック結果を Log Analytics や SQL DB に記録し、後から監査できるようにしておく
「サイズ一致のみ」でも多くの運用では十分ですが、法規制や SLA が厳しいシステムではハッシュチェックも検討すると安心です。
マニフェストファイルによる差分転送
毎回 File Share 全体をスキャンしてコピーすると、
- リストアップ処理に時間がかかる
- 不要な再転送が多くなる
といった問題が出ます。そこで、次のような「マニフェスト方式」が有効です。
| 項目 | 内容 |
|---|---|
| マニフェスト格納場所 | 中継ストレージの専用コンテナ、もしくは Azure SQL / Cosmos DB |
| マニフェスト項目 | ファイルパス、サイズ、更新日時、ハッシュ、転送ステータス（未転送／転送済み／エラー）など |
| 差分判定 | File Share 側のリストとマニフェストを付き合わせ、「新規または更新されたファイルだけ」を対象に ForEach でコピー |
こうしておくと、再実行時にも「どこまで終わっていたか」を容易に再構築でき、冪等性が高まります。
中継データのクリーンアップ戦略
中継ストレージにファイルを残し続けると、容量やコストが気になります。この点は、Azure Blob Storage のライフサイクル管理ポリシーを使うことで自動化できます。
例えば、次のようなルールを設定します。
- 更新日から 30 日経過した中継ファイルを自動削除
- あるいは「タグ: Role = Staging」の付いた Blob だけを 14 日後に削除
ルールは JSON で記述でき、コンテナ単位やプレフィックス単位で細かく制御可能です。これにより、
- 直近数日分はオンラインで残す（障害時の再送・検証用）
- それより古いものは自動削除してストレージコストを抑制
といった運用が簡単に実現できます。
代替案・アーキテクチャオプション
ネットワークを再設計して「単一 Self-hosted IR」で直接コピーする
「どうしても 1 本の Copy Activity で File Share → SFTP を実現したい」場合は、Self-hosted IR ホストから File Share と SFTP の両方へ到達できるようにネットワークを組み替えるのが唯一の道です。
具体的には：
- Self-hosted IR を Azure VM に配置し、その VM から
- Azure Files / File Share へは SMB（TCP 445）または Private Endpoint 経由でアクセス
- SFTP へは VNet Peering / VPN / ExpressRoute などでアクセス
- ファイアウォール／NSG で必要なポートのみ許可する
この条件を満たせば、
- ソース：File Share（Self-hosted IR）
- シンク：SFTP（Self-hosted IR）
という構成にできるため、単一の Self-hosted IR 上で直接コピーが可能になります。ただし、ネットワーク／セキュリティ設計が複雑になりやすい点には注意が必要です。
Managed VNet IR でオンプレ側に寄せる
Azure Data Factory には、Azure IR を VNet に閉じ込めて使える Managed Virtual Network Integration Runtime があり、これを使うと「Self-hosted IR をインストールせずに閉域網へアクセス」できるケースがあります。
条件が揃えば、
- File Share・SFTP いずれも VNet 内／Private Endpoint 経由で到達可能にする
- 両方の Linked Service を Managed VNet IR にぶら下げる
ことで、「Self-hosted IR なしで単一 Azure IR で完結」させる設計も検討できます。ただし、既にオンプレ SFTP を Self-hosted IR で運用している場合は、ネットワーク構成の大きな見直しが必要になる点を考慮してください。
宛先を Azure Storage SFTP（Blob SFTP）に寄せて Self-hosted IR を排除する
もし「外部システムから SFTP でファイルを受け取りたいだけ」であれば、Azure Blob Storage のネイティブ SFTP 機能が非常に有力な選択肢になります。
構成イメージ：
- ADF：File Share → Blob（Azure IR）にコピー
- 外部システム：Blob SFTP エンドポイントに SFTP で接続してファイルを取得
この場合、ADF の観点では「Blob へのコピー」だけになり、Self-hosted IR 自体が不要になります。SFTP サーバーのパッチ適用や OS 管理からも解放されるため、運用コスト削減の効果は大きくなります。
避けたい誤解とアンチパターン
統合ランタイム周りでは、次のような勘違いがよくあります。
- 「ソース側は Azure IR、シンク側は Self-hosted IR なので、自動的に 2 つの IR が協調してコピーしてくれる」
→ 実際には Self-hosted IR だけが実行役として選ばれるため、Self-hosted IR から双方に到達できなければ失敗します。 - 「Self-hosted IR を 2 台（別インスタンス）用意して、片側ずつ接続させれば 1 回でコピーできる」
→ ADF の仕様上、1 つの Copy Activity の中で 2 つの Self-hosted IR を同時に使うことはできません。 - 「Staged Copy（ステージング機能）を ON にすれば IR 制約を回避できる」
→ ステージングの有無にかかわらず、その Copy Activity を実行している IR がすべてのデータ転送を担当します。異なる Self-hosted IR をまたいだコピーはステージングでもサポートされていません。
このあたりを誤解して構成してしまうと、「テスト接続は通るのに本番コピーが失敗する」「Queued のまま進まない」といったトラブルの原因になります。
運用ベストプラクティス
セキュリティ：Key Vault で資格情報を一元管理
資格情報（SFTP の鍵、パスワード、接続文字列など）は、Azure Key Vault に格納し、ADF から参照する方式が推奨です。
- Linked Service の「パスワード」などを Key Vault Secret 参照にする
- Data Factory のマネージド ID に、Key Vault への Get / List 権限のみ付与する
- パイプライン内で Web Activity 経由で Secret を取得してヘッダに流用する、といった高度な利用も可能
こうしておけば、秘密情報はコードにもパイプライン定義にも残らず、ローテーションも Key Vault 側だけで完結します。
スケール：Self-hosted IR ノードのスケールアウト
大量のファイルや大容量データを扱う場合、Self-hosted IR ノードの CPU / メモリ／ネットワーク帯域がボトルネックになりがちです。Self-hosted IR は、複数ノード構成でのスケールアウトがサポートされているため、負荷に応じてノードを増やすことができます。
- Copy Activity の並列度（parallelCopies）やデータ分割設定と合わせてチューニング
- 中継ストレージを使う構成だと、「前半は Azure IR のスケール」「後半は Self-hosted IR のスケール」と役割を分けやすい
監査性：Azure Monitor / Log Analytics 連携
ADF は標準でパイプライン／アクティビティの実行履歴を持ちますが、既定保存期間は 45 日程度です。長期の監査や高度な分析を行うなら、Azure Monitor の診断ログを Log Analytics に流す構成がおすすめです。
- Diagnostic settings で ADF のログを Log Analytics Workspace に送信
- ADFActivityRun / ADFPipelineRun テーブルを KQL で検索し、
- エラー率の推移
- パイプラインごとの処理時間
- 転送量とコスト見積もり
- 特定のエラーコードやファイル名でアラートを飛ばすことで、運用オペレーションを自動化
中継ストレージ経由の 2 段コピーでは、「前半だけ失敗」「後半だけ失敗」といったケースも起きるため、パイプライン単位・アクティビティ単位のログを横断的に監視できる仕組みは非常に有用です。
まとめ
- Self-hosted IR を片側に使うコピーでは、その Self-hosted IR がソースとシンクの両方に到達できる必要があるという仕様があるため、今回のような「File Share は Azure IR からしか見えない／SFTP は Self-hosted IR からしか見えない」構成では、単一の Copy Activity による直接コピーは不可能です。
- Microsoft の公式ドキュメントでも、異なる Self-hosted IR 間のコピーは 中継ストレージ＋二段階コピーが推奨されており、今回の運用はまさにその正攻法に沿ったものです。
- 中継ストレージには Blob / ADLS Gen2 を用い、ライフサイクル管理ポリシーでクリーンアップすることで、コストを抑えつつ監査性を確保できます。
- 「どうしても直接コピーしたい」場合は、Self-hosted IR から両方のエンドポイントへ到達できるようネットワークを再設計するか、Managed VNet IR や Azure Storage SFTP などを活用して、そもそもの宛先やネットワーク構成を Azure 側に寄せるアーキテクチャ変更を検討する必要があります。
- いずれの構成でも、Key Vault による資格情報管理、Self-hosted IR のスケールアウト、Log Analytics によるモニタリングを組み合わせることで、セキュアかつ再実行性・監査性に優れたデータ連携基盤を構築できます。
したがって、現状の「中継ストレージ経由の二段階コピー」は、単なる妥協策ではなく、仕様・運用・拡張性の観点から見ても十分に「推奨構成」と言えるものです。今後の要件変化（転送量増加、外部接続先の追加など）に備えつつ、本記事の内容をベースに設計・運用をブラッシュアップしていくとよいでしょう。
コメント