Step Functionsで実現するロングランニングジョブのイベント駆動化: SQS×Pipes×Fargate構成

ツール導入前の課題

当時のアーキテクチャは、ECS上のコンテナが常時起動してSQSをポーリングする「ワーカー型」でした。 しかし、これには以下のような構造的な限界がありました。

• 同時実行数が固定のため、ジョブが集中すると処理待ちが発生
  • 配車業務の根幹に関わる計算結果を想定時間内に返せず、遅延リスクが高まっていた
• 処理待ちを防ぐための手動スケール
  • ユーザー増を見越したECSタスク数の調整など、運用でカバーしていたが、限界に近づいていた
• 最適化エンジンのバージョン（v1/v2）使い分け
  • 旧構成ではバージョンごとに専用ワーカー群の常時起動が必要で、バージョン増加に比例して管理対象リソースとコストが増える構造だった

これらを解決するために、SQSの滞留数に応じたオートスケーリングも検討しました。 ただ、最大約1時間かかる計算処理中にスケールインが走ると、実行中ジョブが強制終了されてしまうリスクがあります。 安全側に倒してタスク数を多めに維持すれば、アイドルリソースの無駄なコストが発生する、というジレンマもありました。

どのような状態を目指していたか

常時リソースを確保し続ける方式から、必要な時に必要なだけリソースを利用する「イベント駆動型」のアーキテクチャへ移行する必要がありました。

この方針で、次の状態を実現したいと考えました。

• スケーラビリティ：ジョブごとにオンデマンドでFargateタスクを起動し、待ち時間なく処理を開始できる
• 安全なロングランニング処理：スケールインに依存せずジョブ単位で完了まで稼働し、長時間ジョブでも安定運用できるようにする
• 従量課金に近い運用：常時起動リソースを持たず、処理がない時間の待機コストをほぼゼロにできる

• 常時起動ECS（旧構成のスケールアウト案）：単純にタスク数を増やす案。根本的な課題解決にならずコスト増になりやすい
• AWS Lambda：イベント駆動だが、計算処理が最大1時間近くかかるため15分のタイムアウト制限を受ける
• AWS Batch：バッチ処理基盤として強力だが、ジョブごとの細かい条件分岐（バージョンの動的振り分け）をやろうとすると別のオーケストレーターが必要になり、構成が複雑化しやすい

• スケーラビリティ：ジョブ数に応じて、待ち時間なく即座にリソースを確保できること
• フロー制御の柔軟性：ジョブに含まれるメタデータに基づいて、実行するコンテナを動的に切り替えられること
• 保守性：分岐ロジックやリトライ処理をコードではなく、視認性の高いワークフローとして管理できること
• コスト効率：計算していない時間の待機コストが小さい（= 常時起動リソースを持たない）こと

• SQS→EventBridge Pipes→Step Functionsの連携により、ポーリングやグルーコードを書くことなくイベント駆動のフローを組める
• Choice ステートで、バージョンに応じたFargateタスクをオンデマンドで起動できる
• ECS統合（RunTask）を使うと、.sync を利用して「起動」だけでなく「完了」まで含めてワークフローに落とし込みやすい
• Retry / Catch で指数バックオフなど高度なエラーハンドリングをワークフロー側で定義できる

改善したかった課題はどれくらい解決されたか

課題だった「ジョブの待ち時間」は解消されました。 ジョブごとにFargateタスクをオンデマンドで起動できるため、（各サービスのクォータの範囲で）必要な分だけ並列実行ができるようになりました。

どのような成果が得られたか

• 安全なデプロイ：旧構成では長時間実行中のジョブがデプロイ時のタスク停止に巻き込まれるリスクがあったが、新構成では影響を受けにくくなった
• 可視化による運用改善：どのバージョンがどれくらい動いたか、エラー原因は何かなどがStep Functionsのコンソールで視覚的に把握できるようになり、運用負荷が下がった
• コスト約80%削減：常時起動リソースを廃止し、必要な時だけ動く構成にしたことでコストを大きく削減できた。また、旧構成でワーカーが常時キューをポーリングしていたことで発生していたSQSへのAPIリクエストコストも、Pipesが効率的にメッセージを取得するようになったことで合わせて削減できた

• ASL（Amazon States Language）の学習コスト：定義ファイルが独特で、最初は少し取っつきにくい（現在はWorkflow StudioやCDKのサポートでかなり改善されている）
• デバッグ：分散システム特有の難しさがあり、処理がどこで詰まっているかの追跡にはX-Rayなどを活用する必要がある
• ローカルテスト：Step Functions Localはあるものの、サービス統合まで含めた“完全な再現・テスト”は難しく、最終的にはデプロイして確認というサイクルになりがち
  • 補足：StandardワークフローはASYNC呼び出しのため、Pipes側で「ステートマシン内部ロジックの失敗」を検知してリトライすることができない（失敗時の扱いはステートマシン側で設計が必要）

「複数のAWSサービスを組み合わせる処理」や「条件分岐が必要なバッチ処理」があるなら、自前でコードを書く前にStep Functionsを検討すべきです。 特にエラーハンドリングやリトライ処理をアプリケーションコードから追い出せるだけで、システム全体の見通しが良くなります。

最初はWorkflow Studioを使ってGUIでフローを描いてみると、イメージが湧きやすいのでおすすめです。

今回の刷新により、「SQS → EventBridge Pipes → Step Functions → Fargate」という構成が、長時間実行されるジョブにおいて有効であるという成功事例を作ることができました。 この知見を活かし、今後新たなバッチ処理や非同期処理が必要になった際には、このアーキテクチャを第一候補として積極的に採用していきたいと考えています。