オンプレバッチのAWS移行、4つのパターン — どのジョブをどこへ運ぶか

オンプレからの移行で、サーバ本体より難物なのがバッチ群です。数百本のジョブ、複雑な先行後続、誰も全容を知らないシェルの山。この記事はETL・バッチ移行シリーズの総論として、4つの移行パターンと使い分けの軸を示します。結論を先に言うと、全部を1つのパターンに揃えようとした移行は失敗します。

014つのパターン

• ①そのままEC2 — OS・ジョブスケジューラごと持ち込む（リホスト）。改修ゼロ、クラウドの恩恵は少なめ
• ②コンテナ化（ECS＋EventBridge） — 処理をコンテナにし、スケジュール起動。実行環境の管理が消え、並列化しやすい
• ③サーバーレス（Lambda＋Step Functions） — 軽い処理の連鎖に。サーバ管理ゼロ、ただしLambdaは1回15分まで
• ④マネージドETL（Glue／AWS Batch） — 大量データの変換・集計。分散処理で夜間枠を短縮できる可能性

02使い分けの3軸

パターン選定は「改修をどれだけ許容できるか」「1ジョブの実行時間」「依存関係の複雑さ」の3軸でほぼ決まります。

• 改修許容度が低い・期限が近い → ①EC2続投が正解。動いている資産の尊重は立派な設計判断です
• 15分以内で終わる軽い処理 → ③サーバーレスの好適地
• 数時間かかる重い集計 → ②コンテナか④マネージドETL（Lambdaの15分制限に注意）
• 先行後続が複雑なジョブネット → どのパターンでもStep Functionsでの編成を検討

03現実解は「混在」

実際の移行では、基幹の夜間バッチは①で続投し、周辺の軽いジョブから③④へ段階的に移す混在構成がほとんどです。「全部サーバーレス化します」という宣言は勇ましいですが、数百本の書き換えとテストの工数を見積もった瞬間に破綻します。パターンの混在は妥協ではなく、リスクとコストの最適化です。

04どこから手をつけるか

最初に移すのは「依存が少なく、失敗しても業務影響が小さいジョブ」です。ログ集計・レポート生成・ファイル整理あたりが定番で、ここでAWS側の実行・監視・リランの型を確立してから、基幹に近いジョブへ進みます。最初に一番重要なバッチへ挑むのは、練習なしで本番に出るのと同じです。

05シリーズ各論へ

このシリーズでは、パターン別・論点別に各論を用意しています：ジョブスケジューラ（JP1等）の移行／HULFT・ファイル連携／シェルバッチをEC2で正しく動かす／ジョブネットのStep Functions化／ETLツールからGlueへの判断／夜間バッチは速くなるのか／監視とリラン設計。自社の状況に近いものからどうぞ。