■ この記事はこんな人におすすめ
- 外部APIを使った非同期処理の設計に悩んでいる人
- タイムアウトや障害に強いワーカー構成を構築したい人
- AWSのECS・Lambda・SQS・EventBridgeを組み合わせて使いたい人
- ピーク時間帯のパフォーマンス劣化問題を解決したい人
- インフラをコストを抑えながらスケールさせたい人
■ この記事で得られること
- 外部API呼び出しをキュー経由で安全に非同期処理できるようになります
- SQSを用いた障害耐性の高いアーキテクチャの考え方が身につきます
- EventBridge + ECS Schedulerによるピーク回避の予約実行パターンを実装できます
- ECSワーカーからLambdaへの切り替えによるコスト最適化の判断軸がわかります
- 今後のユーザー指定スケジュール実行の設計パターンを比較できます
1. はじめに
本記事では、画像生成API「Nano Banana」を使って100〜300件の画像を一括生成するシステムを、実際の課題を乗り越えながら段階的に改善してきた設計の変遷を紹介します。
最終的な構成は ECS（アプリ）+ Lambda（ワーカー）+ SQS（キュー）+ EventBridge（スケジューラー起動）+ ECS（スケジューラー） の組み合わせです。
設計の2大テーマは次の通りです：
- 「事前にセットした画像 + 共通プロンプト」で一括生成したい
- ピーク時間帯（PM13:00〜18:00）の処理遅延・エラーを回避したい
2. 現在のインフラ構成になるまでの課題と変遷
■ ① 初期構成の問題点を把握する
まず最初はシンプルに、アプリ（ECS）から直接APIを呼び出す構成でした。
NG（初期構成）
ユーザーリクエスト → アプリ（ECS） → Nano Banana API
問題点：
- APIのタイムアウトエラーが頻発する
- ユーザーが処理完了を待ち続けなければならない
■ ② ECSワーカーを追加してみる
次に、処理を分離するためにECSワーカーを追加しました。
構成：
ユーザーリクエスト → アプリ（ECS） → ワーカー（ECS）
残った問題点：
- ワーカー障害時にリクエストが消える（メッセージが保持されない）
- ワーカーが混雑すると、アプリ側もブロックされる
- リクエスト数に応じたスケールが難しい
■ ③ SQSを導入してキューイングする
ワーカーへの橋渡しにSQSを導入し、疎結合なアーキテクチャへ移行します。
構成：
アプリ（ECS） → SQS → ワーカー（ECS）
SQS導入のメリット：
- ワーカーが落ちてもメッセージはSQSに残り再処理が可能
- アプリはSQSにメッセージを積むだけでブロックされない
- ワーカーをリクエスト量に応じて独立してスケール可能
残った問題点：
- ピーク時間帯（PM13:00〜18:00）に1件あたり3〜5分かかる
- 外部APIのサーバーエラーも多発する
■ ④ EventBridge + ECSスケジューラーで予約実行する
AM06:00に予約実行することでピーク時間帯を回避します。
構成：
EventBridge（AM06:00起動）
→ スケジューラー（ECS）
→ DBのステータス・予約日時を確認
→ SQSにメッセージを作成
→ ECSを停止
→ SQS → ワーカー（ECS）
ポイント：
- 起動はEventBridgeが行い、処理が終わったらスケジューラーを停止
- DBの予約ステータスを確認してから、該当分のみSQSにエンキュー
残った問題点：
- ワーカーが常時起動しているためコストがかかる
- ワーカーが1台のため処理が直列になり、時間がかかる
■ ⑤ LambdaでワーカーをFaaS化し、並列処理とコスト削減を実現
ECSワーカーをLambdaに切り替えることで、SQSトリガーによる並列実行と従量課金を実現します。
最終構成：
EventBridge（AM06:00起動）
→ スケジューラー（ECS）
→ DBのステータス・予約日時を確認
→ SQSにメッセージを作成
→ ECSを停止
→ SQS → ワーカー（Lambda × n件並列）
Lambdaの利点：
- SQSトリガーにより、メッセージ数に応じて自動的に並列起動
- 使った分だけの料金（常時起動コストがゼロ）
- ECSの管理オーバーヘッドが不要
3. 今後の展望（ユーザー指定スケジュール実行）
現在の課題は「AM06:00固定」であること。ユーザーが実行タイミングを指定できるようにするには、以下の2パターンが考えられます。
■ パターン1：動的にEventBridgeルールを作成する
ユーザーが日時を指定した際に、その時刻に合わせたEventBridgeルールをAPIから動的に作成します。
メリット： ルールが1件1件明確で管理しやすい
デメリット： ルール数が増えると管理が煩雑になる
■ パターン2：1時間ごとに定期実行して対象を絞る
EventBridgeで毎時起動するスケジューラーを常設し、DBの予約日時と現在時刻を比較して対象ジョブだけSQSに積みます。
メリット： 構成がシンプル、ルール数が増えない
デメリット： 実行タイミングが最大1時間ズレる可能性がある
■ コストの違いは？
コスト差は1ヶ月で数十円〜数百円程度であり、精度と運用コストのバランスでパターンを検討するのが良さそうです。
まとめ
- 直接API呼び出し → タイムアウト・障害に弱い
- ECSワーカー追加 → 疎結合化できるが、障害時にリクエストが消える
- SQS導入 → 信頼性・スケール性が大幅に向上
- EventBridge + ECSスケジューラー → AM06:00予約実行でピーク回避
- Lambdaへの切り替え → 並列処理 + コスト最適化の両立
- 今後：動的EventBridgeルール or 1時間ポーリングでユーザー指定スケジュールへ
今回の実装から得た学びとは？
- インフラの実装方法やサービスの候補はAIとの壁打ちでそこまで苦労しない。
- 大事なことは、要件やコスト、セキュリティなどの観点から適切なサービスを判断できることである。
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。