AWS Batch・EventBridgeと疎結合化 — バッチ近代化の設計と「やりすぎない」線引き

ホストやオンプレのバッチを移した後、次に来るのが近代化です。AWS Batch・EventBridge・SQS/SNSを使えば、密結合だったジョブ網を疎結合でしなやかにできます。ただし——全部を疎結合にすると、今度は「順序が保証されない地獄」が待っています。効くところに効かせ、守るべき順序は守る。その線引きを設計します。

01道具を3つ揃える

• AWS Batch — 重いバッチ計算のためのマネージド実行基盤。ジョブキュー、Fargate/EC2/スポットの実行環境、配列ジョブ、ジョブ間依存。夜間バッチの重い集計を並列で捌く
• EventBridge — イベントバス＋スケジューラ。「ファイル到着で起動」「定時起動」「イベントで振り分け」を担う
• SQS / SNS — SQSはキュー（順番待ち・負荷平準化・リトライ）、SNSはファンアウト（1つの出来事を複数へ通知）。疎結合の接着剤

02疎結合化とは「直接呼ばない」こと

オンプレのバッチ網は密結合です。ジョブAが終わったらジョブBを直接起動し、Bが失敗すると後続が全部倒れる。疎結合化は、この直接のつながりをイベントやキューを介した間接のつながりに置き換えることです。ジョブAは「終わった」というイベントを出すだけ。誰がそれを受けて何をするかは、受け手側が決める。

• 回復力 — 失敗したらキューに残り、リトライやDLQ（リラン設計）で拾える
• スケール — キューが溜まれば受け手を増やせる。負荷の波を吸収できる
• 独立進化 — 送り手と受け手が疎なので、片方だけ改修・入れ替えできる

03効くパターン4つ

• ファイル到着駆動 — S3にファイルが置かれる → イベント → EventBridge → Batch/Lambda起動。ポーリング常駐が消える（ファイル連携のS3化と好相性）
• 定時起動 — EventBridge Scheduler → Step Functions でジョブネット実行（ジョブネット化）。EventBridge SchedulerならScheduleExpressionTimezoneにAsia/Tokyoを指定すればcron/rateをJSTのまま評価でき、夏時間も自動処理される（UTC固定なのはレガシーのEventBridgeスケジュールルールの方）
• 負荷平準化 — 大量リクエストをSQSで受け、後段が自分のペースで処理。ピークの突き上げを平す
• ファンアウト — 1つの完了イベントを、集計・通知・連携の複数処理へSNSで同時配信

04正直な線引き — 疎結合にしすぎない

ここが本記事の肝です。疎結合は万能ではありません。厳密な順序と一貫性が要る処理を無理に疎結合にすると、順序保証・重複排除・整合性のために、かえって複雑な作り込みが必要になります。

• 月次の締め処理のように「AのあとBのあとC」が絶対の順序 → 素直にStep Functionsで順序制御する。イベントでばら撒かない
• 厳密一度きり（exactly-once）が要る会計処理 → キューの「最低一度（at-least-once）」配信とべき等性設計を正しく理解して使う。安易な疎結合は二重計上を生む
• 疎結合にすると、処理の流れが「どこで何が起きたか」見えにくくなる → 分散した処理を追う監視・トレースの設計が別途要る

05移行の順番 — 密結合のまま移して、効くところから疎に

近代化の進め方も、バッチ移行の総論と同じです。まず密結合のまま（EC2続投やStep Functionsでの素直な順序制御で）移行を完遂し、そのうえで「並列化で夜間枠を縮めたい」「ファイル連携をイベント駆動にしたい」という効果の見えるところから疎結合を入れる。全面的な作り替えを移行と同時にやると、問題の切り分けができなくなります。

—まとめ

AWS Batch・EventBridge・SQS/SNSは、バッチをしなやかにする強力な道具です。ファイル到着駆動・定時・負荷平準化・ファンアウトで、密結合の弱さを解消できる。ただし、順序と一貫性が命の処理まで疎結合にすると、別種の複雑さを招きます。効くところに効かせ、守るべき順序は素直に守る——この線引きこそが、バッチ近代化の設計力です。