【技術公開】「デプロイと実行の干渉」をどう防ぐか。サーバーレスなバッチ基盤で実現する安定運用の裏側

Webサービスの運用において、バッチ処理（スケジュール実行）の安定性はプロダクトの信頼性に直結します。

私たちのプロダクト 不特法クラウド でも、ローンチ初期はEC2上のcronというシンプルな構成を採用していました。しかし、サービス規模の拡大に伴い、ブルー/グリーンデプロイによるインスタンス入れ替え時の「バッチ中断リスク」や、管理の二重化といった課題が顕在化してきました。

そこで、デプロイとバッチ実行を完全に切り離し、かつ開発者がインフラを意識しなくて済む環境を目指して構築したのが、現在のサーバーレスな実行基盤です。

🛠 今回公開したアーキテクチャのポイント

スケジュール同期の自動化: アプリケーション上の定義を正（SSOT）としてAWSへ反映。
サーバーレス実行: AWS Batch on Fargate により、実行時のみリソースを確保し干渉を防ぐ。
運用負荷の最小化: サーバーの個別管理から解放され、開発者が本質的な課題に集中できる環境へ。

テーマは「単に動く」から「運用の手離れが良い」への移行でした。自律的なエンジニアリングを支える、不特法クラウドのインフラ設計の試行錯誤を解説しています。

▼ 記事の全編はこちら（note）

スケジュール定義をAWSへ自動同期。ECS/EventBridgeで構築する堅牢なサーバーレスバッチ基盤｜レプス公式note

こんにちは！レプスのシニアEM、石坂です。 Webアプリケーションを運用する上で避けて通れないのが「バッチ処理」の管理です。今回は、私たちレプスが提供するプロダクト、不特法クラウドで採用しているAWSバッチ実行基盤の技術的な舞台裏を公開します。 1. 過去の課題：EC2 + cron 実行の限界実はローンチ初期、私たちのバッチ処理は EC2インスタンス上のcron で動かしていました。開発初期においてはこの構成が最もシンプルでスピード感もありましたが、サービスが成長し、扱うデータ量やバッチの種類が増え

https://note.com/lepusinc/n/n4d879f8bfcef

▼過去のこんな記事もよく読まれています（note）