Airship から配信されるファイルを Azure 上で安全かつ確実に受け取り、Databricks で Delta テーブルとして利活用できるようにするには、単に SFTP を開けるだけでは足りません。本記事では、ADLS Gen2・Azure SFTP・Managed File Transfer・Databricks Auto Loader / ADF を組み合わせた、ネットワークとセキュリティまで含めた実践的な設計と手順を詳しく解説します。
Airship → Azure Databricks 連携の全体像
まずは、Airship から Azure Databricks までのエンドツーエンドの流れを整理します。
Airship（SFTP クライアント / MFT）
└─[SFTP / 22]→ Azure Storage（ADLS Gen2・SFTP 有効化）
└─ コンテナー（raw）内の受信フォルダにファイル到着
└─ Databricks Auto Loader または Azure Data Factory で検知・取り込み
↓
Delta Lake（Bronze → Silver → Gold）
＋ Unity Catalog によるデータカタログ・権限管理
この構成では、Airship はあくまで「SFTP クライアント」として動作し、Azure 側に用意した SFTP 対応の ADLS Gen2 が「SFTP サーバー」の役割を担います。そこから先は Azure 内の処理だけで完結させることで、ネットワークやセキュリティの制御をシンプルに保つことができます。
コンポーネント別の役割
| コンポーネント | 主な役割 | 設計のポイント |
|---|---|---|
| Airship（MFT） | ファイル生成・SFTP 転送 | 鍵管理、一時拡張子運用、分割サイズの取り決め |
| Azure Storage（ADLS Gen2） | ファイル受信・保存（SFTP サーバー） | SFTP 有効化、コンテナー設計、ファイアウォール・Private Endpoint |
| Databricks Auto Loader | 新規ファイル自動検知・取り込み | イベント通知 or ポーリング、チェックポイント、スキーマ管理 |
| Azure Data Factory（ADF） | パイプライン制御・バッチ取り込み | イベントトリガー／スケジュール、再実行制御、Databricks ノートブック連携 |
| Delta Lake / Unity Catalog | データ保存・権限管理・監査 | Bronze / Silver / Gold 分離、テーブル・列レベル権限、アクセスログ |
インバウンド（受信）処理の設計と手順
ここからは、Airship から ADLS Gen2 までの「インバウンド部分」を、実際の作業手順ベースで整理します。
ADLS Gen2 と SFTP の準備
- ストレージアカウントの作成
- 種類：汎用 v2（Standard）
- 階層型名前空間（Hierarchical Namespace）を有効化し、ADLS Gen2 として利用
- 暗号化は既定のまま（必要に応じて顧客管理キーを検討）
- SFTP を有効化
ストレージアカウントの SFTP 機能を有効化し、SFTP エンドポイントを払い出します。
セキュリティ観点から、SFTP を有効化するストレージアカウントは用途を限定しておくと運用が楽になります。 - コンテナーとディレクトリの作成
例として、以下のようなコンテナーとディレクトリを用意します。コンテナー：raw パス ：/airship/_dropbox /airship/_quarantine /airship/customer_consents /airship/tracking
SFTP ローカルユーザーと鍵認証の設定
Azure SFTP では、ストレージアカウントに紐づく スコープド ローカルユーザー を設定し、そのユーザーに SSH 公開鍵を関連付けて認証します。
- スコープド ローカルユーザーの作成
- ユーザー名は
airship-ingestなど用途が分かる名前にする - ホームディレクトリ：
/airship/_dropboxを指定 - 権限：書き込み・読み取りのみ（削除は原則禁止）
- ユーザー名は
- 公開鍵認証のベストプラクティス
- Airship 側（クライアント）が鍵ペアを生成
- 公開鍵のみ を Azure 側に共有し、ローカルユーザーに紐づける
- 秘密鍵は Airship 側で厳重に管理し、Azure 側には絶対に渡さない
- 鍵ローテーション（有効期限・切替手順）を Airship 側と事前に合意しておく
| 項目 | 推奨設定 | コメント |
|---|---|---|
| ホームディレクトリ | /airship/_dropbox | 他のパスを見せないためにスコープを限定 |
| アクセス許可 | 読み取り・書き込み | 削除は原則禁止、運用上どうしても必要なら別ユーザーで運用 |
| 認証方式 | SSH 公開鍵認証 | パスワード認証は避ける |
ネットワークとセキュリティの基本設計
インターネット越しに SFTP を公開する以上、ネットワークとセキュリティは慎重に設計する必要があります。
- ストレージファイアウォール：
Airship の送信元 IP（もしくは CIDR）を 許可リスト に登録し、それ以外からのアクセスは拒否します。 - Private Endpoint：
Airship 側が閉域網（ExpressRoute / VPN）から Azure に接続できる場合は、Private Endpoint を利用しパブリックエンドポイントを使わない構成がベストです。 - 診断ログの有効化：
ストレージアクセスログ・SFTP の接続ログを Log Analytics などに送信し、監査・アラートの基盤を整備します。 - 暗号化とキー管理：
保存時暗号化は標準で有効です。コンプライアンス要件が厳しければ、顧客管理キー（CMK）や専用のキーコンテナーを検討します。
部分書き込みを避けるための到着確定方式
SFTP 転送中の「半端なファイル」を取り込んでしまうと、行欠けや集計誤差の原因になります。Airship 側との取り決めで、ファイルが完全に転送完了したことが分かるルールを決めておきましょう。
| 方式 | 概要 | 特徴 |
|---|---|---|
| 一時拡張子方式 | .part などの拡張子でアップロードし、転送完了後に最終ファイル名へリネーム | 最もシンプルで分かりやすい。Auto Loader / ADF 側は最終拡張子だけを対象にする。 |
| 一時フォルダ方式 | _tmp フォルダへアップロードし、完了後に _dropbox へ移動 | フォルダ単位で「完了ファイル」のみを監視できる。フォルダ数が増えやすい点に注意。 |
| マーカーファイル方式 | 本体ファイル + .done ファイルをセットで出力し、.done を到着確定のトリガーにする | バッチ処理単位の完了検知にも使える。ADF のパイプラインと相性が良い。 |
どの方式を選ぶ場合も、「取り込み側は未完了ファイルには一切触れない」を徹底することが重要です。
ファイル命名規則の例
運用や再処理を意識して、意味のある命名規則を定義しておきましょう。
{データ種別}_{YYYYMMDDHHmm}_{ソース}_{バージョン}.csv.gz
例：
customer_consents_20250910_airship_v1.csv.gz
tracking_events_20250910_airship_v1.csv.gz
- データ種別：customer_consents / tracking など
- タイムスタンプ：原則 UTC、もしくはタイムゾーンを ISO8601 のような形で別カラムに持つ
- バージョン：仕様変更や再送時の識別に利用
新規ファイルの検知と取り込み方式
ADLS Gen2 の受信フォルダに到着したファイルを、どのように Delta テーブルへ取り込むかを設計します。代表的な選択肢は以下の 2 つです。
Databricks Auto Loader を用いた取り込み（推奨）
Databricks Auto Loader は、クラウドストレージ上の新規ファイルを自動検知してストリーミング／バッチ取り込みができる機能です。
- ADLS Gen2 のパスを監視し、新規ファイルのみ を取り込む
- イベント通知モード（Blob 作成イベント利用）とディレクトリ ポーリングの 2 モード
- チェックポイントにより、同じファイルの重複取り込みを防止
- スキーマドリフト（列追加・型変更）への耐性が高い
サンプルイメージ（構文イメージのみ）：
df = (spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "csv")
.option("cloudFiles.inferColumnTypes", "true")
.load("abfss://raw@<account>.dfs.core.windows.net/airship/customer_consents"))
(df.writeStream
.format("delta")
.option("checkpointLocation",
"abfss://raw@<account>.dfs.core.windows.net/_checkpoint/airship/customer_consents")
.option("mergeSchema", "true")
.table("catalog.schema.bronze_customer_consents"))
Auto Loader は「新規ファイルを見つけたら即座に取り込む」ことが得意なので、Airship 側の転送がスケジュールバッチであっても問題なく動作します。
Azure Data Factory を用いた取り込み
Azure Data Factory（ADF） は、GUI ベースでパイプラインを定義できる ETL / データオーケストレーションサービスです。以下のようなケースで有利です。
- Airship 以外にも多くのシステムと連携しており、中央集権的にパイプライン管理をしたい
- 外部システムへの API コール・メール通知なども同じパイプラインで制御したい
- 業務バッチ単位の再実行や依存関係の管理を GUI で行いたい
典型的なパターンは次の通りです。
- トリガー（Blob 作成イベント or スケジュール）でパイプライン起動
Get Metadataアクティビティで対象フォルダ内のファイル一覧を取得ForEachでファイルごとにループし、Databricks Notebook を呼び出して処理- 処理結果に応じて正常系フォルダ / 隔離フォルダへ移動、ログを記録
Auto Loader と ADF の比較
| 観点 | Databricks Auto Loader | Azure Data Factory |
|---|---|---|
| 新規ファイル検知 | イベント通知またはポーリングで自動検知 | イベントトリガー、またはスケジュールでフォルダをスキャン |
| リアルタイム性 | 高い（ストリーミング常駐も可能） | トリガー頻度次第（分単位のスケジュールなど） |
| スキーマドリフト対応 | 標準機能で強力 | 予めスキーマを固定するのが基本 |
| 運用管理 | Databricks 側でジョブ管理 | ADF ポータルからグラフィカルに管理 |
| 外部連携の豊富さ | Databricks ベースの処理が中心 | 各種 SaaS / DB / API との連携が豊富 |
| おすすめ用途 | Airship 連携データのストリーミング／日次バッチ処理 | 全社的なバッチオーケストレーション、Airship 含む複数システム連携 |
Airship 連携のように「ファイル到着 → Delta 取り込み」が主目的であれば、まずは Auto Loader を第一候補とし、既存で ADF 基盤がある場合は ADF + Databricks という組み合わせも有力な選択肢となります。
フォルダ構成とパーティション設計
「同意情報（Customer Consents）」と「トラッキング情報」のように性質の異なるデータを扱う場合、フォルダ構成とパーティション設計が性能・運用性に大きく影響します。
ADLS Gen2 のフォルダ構成例
abfss://raw@<account>.dfs.core.windows.net/
└─ airship/
├─ _dropbox/ # SFTP の受信箱（Airship が書き込む場所）
├─ _quarantine/ # 取り込み失敗・ウイルス検査隔離用
├─ customer_consents/
│ └─ ingest_date=YYYY/MM/DD/HH/
└─ tracking/
└─ ingest_date=YYYY/MM/DD/HH/
abfss://bronze@<account>.dfs.core.windows.net/
└─ airship/
├─ customer_consents/
│ └─ p_event_date=YYYY-MM-DD/
└─ tracking/
└─ p_event_date=YYYY-MM-DD/
| フォルダ / コンテナー | 役割 | ポイント |
|---|---|---|
| raw/airship/_dropbox | Airship からの受信箱 | SFTP ローカルユーザーのホーム。取り込みジョブは原則ここを直接読まない。 |
| raw/airship/_quarantine | 異常系の隔離 | スキーマ不一致やウイルス検知で退避させる場所。 |
| raw/airship/customer_consents | 同意情報の着信確定済みエリア | ingest_date 単位でパーティション分割し、到着順を管理。 |
| raw/airship/tracking | トラッキングイベントの着信確定済みエリア | 処理量が増えやすいので、粒度の細かいパーティションを推奨。 |
| bronze/airship/* | Delta の生データ層 | 追記のみ。p_event_date など業務日付でパーティション分割。 |
ここで重要なのは、受信箱（_dropbox）と取り込み済み領域を物理的に分けることです。取り込み処理は customer_consents/ingest_date=... や tracking/ingest_date=... のみを対象とし、_dropbox には一切手を触れないようにしておくと、誤取り込みや削除ミスを防ぎやすくなります。
パーティションキー設計のポイント
- ingest_date：システムに取り込まれた日時（技術日付）での分割。SLA 管理や再処理の単位に向いています。
- event_date：実際のイベント発生日時（業務日付）。クエリや分析のフィルター条件に使うカラムとして Delta テーブルでパーティション化します。
- 「ingest」と「event」を別に持つことで、遅延到着・再送でも整合性を保ちやすくなります。
Landing ゾーンと Bronze レイヤーの関係
「Landing」と「Bronze」を分けるべきかどうかは、組織の規模とガバナンスの厳しさに依存します。
エンタープライズ規模の場合
- Landing（受信・原本保存）
Airship から届いたファイルを、そのままの形で保存する層。WORM（Write Once Read Many）やバージョン管理を組み合わせて、「原本は絶対に書き換えない」ルールにします。 - Bronze（生データだが最小限整形済み）
文字コード統一、改行コード調整、フォーマットの揺れを吸収した Delta テーブル。ここから先はテーブル志向の世界になります。 - Silver / Gold
業務で使いやすいように join や集約を行う整形・提供レイヤー。
この構成では、問題が発生した場合に「Landing の原本を再読み込みして Bronze からやり直す」といったリカバリパスが明確になります。
小規模・アジャイル重視の場合
データ量や関係者が少ないうちは、Bronze を Landing 兼用とするシンプルな構成も現実的です。ただし、以下のルールを徹底する必要があります。
- Bronze は 追記のみ。上書き・削除は原則禁止。
- Airship から届いたファイルそのものを再現できるよう、ファイル名・ハッシュ値・行数などをメタデータとして保持。
- 閲覧権限は厳しめにし、更新権限を持つロールを明確に分離。
迷った場合は、最低限 _dropbox（受信箱）と Bronze の物理分離 だけでも行っておくと、後から Landing を拡張しやすくなります。
ネットワーク / セキュリティの詳細ポイント
Airship からのファイル連携を安全に運用するために、押さえておきたいセキュリティ観点を整理します。
- 最小権限
SFTP ローカルユーザーは対象コンテナー・ディレクトリのみにスコープし、不要なパスを見せないようにする。 - 鍵管理
公開鍵のみ Azure 側に登録し、鍵のローテーション方法（古い鍵と新しい鍵を一定期間併用 → 古い鍵削除）を手順化。 - IP 制御
Airship の送信元 IP をファイアウォールの許可リストに登録。可能な限り範囲は狭く、明示的に管理。 - PII へのアクセス制御
Unity Catalog を活用し、テーブル・カラム単位でアクセス権を設計。顧客 ID やメールアドレスなど、個人情報に該当する項目へのアクセスを制限。 - マルウェア対策
受信直後にアンチウイルススキャンを実行し、疑わしいファイルは_quarantineに隔離。スキャン結果はログとして残す。
運用・監視の設計
一度構成して終わりではなく、長期運用を見据えてモニタリングやメタデータ管理を設計しておくことが重要です。
到着 SLA 監視
- 「毎日 09:00 までに前日のデータが到着する」といった SLA を定義し、遅延時にアラートを出す。
- Databricks ジョブや ADF パイプラインの実行結果と組み合わせて、「ファイルは来たが取り込みに失敗している」ケースも検知できるようにする。
スキーマ逸脱の検知
- Auto Loader のレスキュー列（_rescued_data など）を活用し、「想定外の列」や「型不一致」の発生を検知する。
- ADF を利用する場合は、事前にスキーマ検証用のステップを挟み、NG なら
_quarantineに移動するだけに留め、本番テーブルには書き込まない。
冪等性（べき等性）の確保
ネットワーク障害などにより、Airship 側が同じファイルを複数回送信する可能性も考慮します。
- ファイル名＋サイズ＋ハッシュ値（MD5 など）を組み合わせた一意キーを管理テーブルに保存。
- 取り込み前に管理テーブルを参照し、すでに処理済みのファイルはスキップまたは別領域に移動。
- Auto Loader のチェックポイントを適切に管理し、処理済みファイルを再読込しない。
メタデータ台帳の整備
取り込み単位で、以下のような情報を Delta テーブルとして管理しておくと、トラブルシュートや監査に役立ちます。
- ファイル名
- 取込日時（ingest_date）
- 件数（レコード数）
- ファイルサイズ
- ハッシュ値
- 処理ステータス（成功 / 失敗 / 隔離など）
よくある落とし穴と対処策
- 部分書き込みを取り込んでしまう
→ 一時拡張子（.part）→リネーム、または.doneマーカーファイル方式を Airship 側と合意し、未完了ファイルには一切触れない運用にする。 - 巨大ファイルによる遅延・障害
→ Airship 側と「1 ファイルあたり 100～500MB 程度を目安に分割する」などのルールを決めておく。Auto Loader や Databricks のクラスターサイズもそれに合わせてチューニング。 - 時刻のずれで分析結果が合わない
→ ingest_date（取り込み日時）と event_date（イベント発生日）を別々に持ち、パーティションも業務日付を優先する。タイムゾーンは UTC に統一し、ローカル時刻はビューで変換。 - 権限設計が複雑になりすぎる
→ 受信箱、Bronze、Silver 以上でロールを分け、「閲覧のみ」「取り込みのみ」「設計変更可」など責任範囲ごとにロールを定義する。Unity Catalog のカタログ / スキーマ単位で整理すると分かりやすい。
まとめ：Airship 連携を堅牢かつ拡張しやすくするポイント
Airship からのファイルを Azure Databricks で活用する際、単に SFTP を開けて CSV を読み込むだけでは、運用していく中でさまざまな課題が浮かび上がります。本記事で紹介したように、
- 「MFT × Azure SFTP」前提で ADLS Gen2 に受ける
- Databricks Auto Loader または ADF で新規ファイルを検知・取り込み
- Landing / _dropbox と Bronze（Delta）を分離し、原本を守る
- 公開鍵・IP 制御・Private Endpoint などでネットワークとセキュリティを固める
- 到着確定方式（リネーム / マーカー）とメタデータ台帳で、再処理しやすい基盤を用意する
といったポイントを押さえておくことで、長期的に安定して運用できるデータ基盤を構築できます。これから Airship との連携設計を進める場合は、本記事の構成例や命名規則、運用・監視の考え方をベースに、自社の要件に合わせてカスタマイズしていくとスムーズです。
コメント