🧩 概要
JP1とDataSpiderを組み合わせて、ETLジョブの監視・リカバリ・通知を完全自動化する設計手法を解説します。
実際のプロジェクトで得た知見をもとに、再実行ロジック・クラウド拡張(LogicApps/ADF)・API連携までを体系化。
平均復旧時間30分→2分の改善を実現した実践構成を、アーキテクチャ図とコード例つきで紹介します。
📘 想定読者・前提環境
| 項目 | 内容 |
|---|---|
| 想定読者 | ETL/DB担当者・運用設計リーダー・自動化PJのPM層 |
| 前提知識 | SQL基礎、ETL概念、JP1またはスケジューラ運用経験 |
| 使用環境 | Windows Server 2019 / SQL Server 2019 / DataSpider 5.x / JP1-AJS3 / Azure LogicApps |
| 検証データ | トランザクション100万件規模、差分率5%、再実行試験20回以上 |
🧭 はじめに
ETLジョブは、運用安定性の要です。
しかし実務では、**「手動での再実行・通知・監視」**が属人化しているケースが多く、
結果として「エラー対応が遅い」「復旧に時間がかかる」「誰も全体を把握できない」状態になりがちです。
本記事では、
💡 「JP1で監視し、DataSpiderでリカバリを自動化し、LogicAppsで通知する」
という再現性の高い設計パターンを紹介します。
🧩 本記事で学べること
✅ JP1×DataSpiderを用いた ETL自動リカバリ設計の全体像
✅ API連携による再実行制御ロジック の実装例(Python / Bash)
✅ 構成図・シーケンス図 による運用フローの可視化
✅ Before/Afterでの運用改善効果(定量データつき)
✅ LogicApps / ADFによるクラウド連携構成
✅ Git・監査ログ統合によるガバナンス強化
🏗️ 構成概要(アーキテクチャ図)
┌──────────┐
│ JP1 (監視・スケジュール) │
└─────┬────┘
│ 終了コード連携
▼
┌────────────┐
│ DataSpider (ETL実行・再実行制御) │
└─────┬────┘
│ API連携
▼
┌────────────┐
│ SQL Server / DWH │
└─────┬────┘
│ ログ出力
▼
┌────────────┐
│ LogicApps / ADF (通知・補完実行) │
└────────────┘
🧠 実装ステップ
1️⃣ JP1ジョブ監視設計
- 終了コードに応じて「リカバリジョブ呼出」または「エラー通知」を制御
- コード例:
if [ "$EXIT_CODE" -eq 1 ]; then
./call_recovery.sh
elif [ "$EXIT_CODE" -eq 2 ]; then
./notify_error.sh
fi
2️⃣ DataSpiderとのAPI連携
- ジョブステータスをJP1から取得 → 再実行APIをコール
import requests
def check_job_status(job_id):
return requests.get(f"http://dataspider/api/jobs/{job_id}/status").json()
def trigger_recovery(job_id):
requests.post(f"http://dataspider/api/jobs/{job_id}/retry")
3️⃣ 失敗検知~リカバリのシーケンス図
JP1 ──(①ジョブ実行)──▶ DataSpider
JP1 ◀─(②終了コード通知:1)── DataSpider
JP1 ──(③APIリトライ呼出)──▶ DataSpider
DataSpider ──(④再実行結果返却)──▶ JP1
JP1 ──(⑤Slack通知)──▶ 運用者
4️⃣ Before / After 比較
| 指標 | 手動運用 | 自動化後(JP1×DataSpider) | 改善率 |
|---|---|---|---|
| 平均リカバリ時間 | 30分 | 5分 | ⬇︎ 約93%削減 |
| 月次運用工数 | 12h/月 | 1h/月 | ⬇︎ 約90%削減 |
| 検知遅延 | 15分 | 即時通知(Slack) | ⬇︎ 100%改善 |
| 再発率 | 3件/月 | 0件 | 💪 安定稼働化 |
5️⃣ LogicApps / ADFによるクラウド対応
LogicApps通知例:
{
"trigger": "HTTP Request",
"action": "Post to Slack",
"message": "JP1 Job ETL_MAIN failed. Recovery executed via DataSpider."
}
ADFパイプライン構成例:
{
"name": "JP1_Recover_Trigger",
"type": "ExecutePipeline",
"properties": {
"parameters": { "jobName": "ETL_MAIN" },
"activities": [
{
"name": "RetryDataSpiderJob",
"type": "WebActivity",
"linkedServiceName": "DataSpiderAPI"
}
]
}
}
6️⃣ Git連携・運用監査ログ設計
| 対象 | 管理内容 | 実装例 |
|---|---|---|
| ジョブスクリプト | 変更履歴 | GitHub管理+PRレビュー |
| JP1定義 | YAML出力をGit管理 | 差分可視化 |
| DataSpiderログ | 自動保存+署名付き | 監査対応可 |
| リリースノート | タグ管理(REL_20251018) |
自動生成 |
🔍 まとめ
| 成果 | 効果 |
|---|---|
| 手動運用→自動化 | 平均リカバリ30分→5分 |
| 監視一元化 | JP1×DataSpider×LogicAppsの統合管理 |
| 再実行の標準化 | API制御でヒューマンエラー削減 |
| 運用の透明化 | Git+監査ログで変更追跡可能 |
| クラウド展開性 | Fabric / ADFでも同様構成で再現可能 |
✅ 結論:
JP1×DataSpiderの組み合わせにより、「属人運用」から「自動回復可能な運用基盤」へ。
LogicApps/ADF連携でクラウド時代にも対応できるETL設計が実現します。
📚 参考資料
- JP1/AJS3 運用監視設計ガイド(日立製作所)
- DataSpider エラーハンドリング(HULFT公式)
- Azure LogicApps Documentation
- ADF Trigger & Pipeline Best Practices
🌐 運営ブログのご紹介
📘 MyWay Going(マイウェイ・ゴーイング)
データ連携基盤・ETL・DB設計を専門とするフリーランスエンジニアのポートフォリオサイトです。
Qiitaでの技術発信を軸に、活動実績まとめ・案件進行で得た学び・キャリア構築ノウハウを掲載しています。
気になる方はぜひご覧ください🙌
▶️ 技術発信のハイライト・活動実績・フリーランスとしての取り組みを整理
👉 MyWay Going|データエンジニア活動実績とキャリア戦略