🧩 概要

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設計が実現します。

📚 参考資料

🌐 運営ブログのご紹介

📘 MyWay Going（マイウェイ・ゴーイング）

データ連携基盤・ETL・DB設計を専門とするフリーランスエンジニアのポートフォリオサイトです。
Qiitaでの技術発信を軸に、活動実績まとめ・案件進行で得た学び・キャリア構築ノウハウを掲載しています。
気になる方はぜひご覧ください🙌
▶️ 技術発信のハイライト・活動実績・フリーランスとしての取り組みを整理
👉 MyWay Going｜データエンジニア活動実績とキャリア戦略