Findy Team+のシステムアーキテクチャ

Findy Team+は以前までAWSのElastic Beanstalkを使用し、APIサーバやWorkerサーバをEC2上に構築するアーキテクチャとなっていました。
Findy Team+は外部ツールと連携し、データを収集して分析するプロダクトの特性上、データ収集のBatch処理が長時間実行されることがあります。WorkerサーバでBatch処理を実行中にデプロイを行うとBatch処理のプロセスが中断されてしまうため、処理が動いていないタイミングを見計らってデプロイする必要があり、スピーディなデプロイを行うことが出来なかった点が当時の課題でした。

現在のアーキテクチャでは、EventBridge スケジューラによってスケジュールでStep Functionsを実行し、そこからBatch処理のECSタスクを起動しています。WorkerサーバとBatch処理を別個のECSタスクで管理することが可能となり、それぞれの処理を独立して稼働させることに成功しました。
これにより実行中のBatch処理をリリースの際に気にする必要がなくなりデプロイ頻度の向上へと繋がったのです。

現在のアーキテクチャの課題と今後の改善予定

今後の展望として、トラフィックやデータ量が数十倍に増加しても問題なく処理できるアーキテクチャを目指しています。
現在のアーキテクチャでは、アクセスが集中したり、Batch処理などで一時的に高負荷がかかる場合に自動でスケールする仕組みが整っていません。
そのため、高負荷を想定し、事前に高スペックのECSタスクやDBインスタンスを稼働させていますが、スケールアップだけではパフォーマンスの頭打ちがきたり、高負荷に合わせたスペックにしていることによるコスト増加などの課題が発生しています。
これらの課題を解決するため、今後は負荷に応じて自動でスケールアウト・スケールダウンできる仕組みを構築するなど、コストの最適化や、トラフィックやデータ量の増加にも対応できるアーキテクチャを実現していきたいと思ってます。

◆執筆：
古田 龍 プロダクト開発部 @ryu-f
後藤 知貴 プロダクト開発部 @_gotchin