ココナラ、経理会計システムをEC2からECS on Fargateへ移行。単一障害点だったAPI/バッチを分離し1ヶ月のBlue/Green並行運用で切り替え

ココナラのインフラ・SREチームは、経理会計システム(APIサーバとバッチ処理で構成)をEC2上で運用していた。この2つの機能が単一のEC2に同居していたため、単一障害点になっているという課題があった。ちょうどアプリケーション側でRubyアップデート計画が進んでおり、基盤運用側からも「EC2サーバ管理の運用コストを削減したい」という要望が出ていたことから、この2つのニーズが合致するタイミングでECS on Fargateへの移行を検討した。また経理会計システムは全体のシステム群から見ると比較的小さな構成で影響度が低かったため、社内でFargateへの移行を推進していく上での初段階の対象として適切だと判断された。

移行にあたっては、まずインフラ設計としてAPIサーバとバッチ処理を分離し、用途別にAPIサーバ・CPU集約型バッチ・軽量バッチの3種類のタスク定義を作成してコスト最適化を図った。

• CI/CDはCircleCIでECS用のデプロイラインを新規構築し、タスク定義の変更がデプロイ時に反映されるよう工夫した
• 開発環境はTerraformの共通moduleを活用して統一管理
• アプリ開発チームからの接続要望に応えるためECS Execを有効化
• 責任分界として、タスク定義はアプリケーション側、サービス定義はインフラ側が管理する形に整理
• エラー検知とバッチの周期的実行を担保する監視体制を整備

本番適用後は1ヶ月間、新旧環境をBlue/Green構成で並行運用してから問題ないことを確認し、旧EC2環境を削除した。移行途中ではEventBridgeからECSタスクを起動する際に「Capacity is unavailable at this time.」というエラーに直面したが、監視のおかげで30分で検知でき、EventBridgeから直接ECSを呼び出す方式をやめてStepFunctionsを経由させ、再試行機能を使う構成に変更することで対処した。

APIサーバとバッチ処理の分離・冗長化が実現し、単一障害点だった構成を解消した。Ansibleによる構成管理が不要になるなど、インフラ管理ツールの統一も進んだ。タスク定義とサービス定義でアプリ側・インフラ側の責務が明確になり、これらの改善を通じて運用コストの削減につなげた。記事中に具体的なコスト削減率などの定量的な数値は明記されていない。