「カンリー店舗集客」のサーバレスインフラアーキテクチャ

「店舗経営を支える、世界的なインフラを創る」をミッションに、店舗事業者向けの集客支援サービスを提供しています。
本稿では、集客支援の主力プロダクト「カンリー店舗集客」で採用している、サーバレスバッチ処理のアーキテクチャをご紹介します。

サーバレスのインフラアーキテクチャについて

背景

「カンリー店舗集客」は2020年にサービスをリリースし、現在では導入店舗数が11万店を超えるプロダクトへと急成長しています。
急成長の裏側では、スピード優先の開発によって技術的負債が蓄積され、運用保守が難しくなっていました。インフラ面でも課題が多く、当時はEC2を採用していたため、1つのバッチに突発的な負荷がかかると、同一ホスト上で稼働していた他のバッチ処理もすべて停止してしまうことがありました。

また、バッチの成功／失敗の把握が難しく、並列処理がアプリケーションコードに依存していたことや、インスタンスの常時稼働によるコストの高さも課題でした。

解決策

これらの課題を解決するため、EventBridge、Step Functions、AWS Batch を組み合わせたサーバレスなバッチ処理アーキテクチャへと移行しました。
従来はEC2上のcronでバッチをスケジューリングし、実行タイミングを環境変数で制御していましたが、EventBridgeを用いることでサーバレス化し、他のAWSサービスとの連携も容易になりました。

EventBridgeからはStep Functionsが呼び出されます。Step Functionsはサーバレスなワークフローサービスで、GUI上で各ステップの実行状況が可視化されるため、どこで失敗したかを直感的に把握でき、トラブル対応がしやすくなっています。また、処理対象のデータをCSVに出力して全く同じ条件で再実行できる工夫や、Mapステートによる並列処理で拡張性も確保しています。

実際のバッチ処理は、Step FunctionsからAWS Batchを通じて実行され、Fargateをコンピューティングリソースとして利用しています。これにより、EC2のように常時インスタンスを起動しておく必要がなくなり、コスト削減が実現しました。OSやミドルウェアの管理も不要となり、運用負荷も大幅に軽減されています。さらに、ジョブごとにCPUやメモリのリソースを柔軟に調整できるため、1つのバッチ処理が他の処理へ与える影響も限定的になりました。

CI/CD

StepFunctionsやAWS Batchの枠組みのみTerraformで管理しています。一方で、Step FunctionsのASL（Amazon States Language）、ジョブ定義、EventBridgeのスケジュールなど、アプリケーションに密接に関わるリソースについては、Terraformの管理外としています。これらはアプリケーション側で管理し、CI/CDのワークフローでアプリの変更と連動して自動更新しています。

監視

Step Functionsの失敗イベントはEventBridgeバスを通じてDatadogに送信され、Datadogではイベントモニターにより監視されています。

課題

移行後の課題としては、Step FunctionsのASLに慣れるまで時間がかかる点が挙げられます。この対策として、社内で勉強会を実施し、その様子を録画して新規メンバーがキャッチアップできるようにしています。

また、1分間隔で実行するようなショートポーリング系のバッチは、このアーキテクチャが適していないという課題もあります。こうしたケースはLambdaの活用など、今後の改善が必要だと考えています。

今後の展望や取り組み予定について

拡張性と可用性を確保した構成は実現できたものの、バッチの実行状況を一覧で把握したり、失敗ジョブのリトライや一括停止を誰でも容易に行える運用環境の整備が今後の課題です。現時点ではバッチの数や依存関係は比較的シンプルですが、将来的な増加を見据え、運用性とオブザーバビリティの向上に取り組んでいく予定です。Datadogにはすでにバッチのログを送信しており、今後はAPMを導入し、より深い可視化を目指しています。

サービスがグロースしていく過程で複雑さが増していくことは避けられません。そうした中で、機能開発を優先しながらも運用の手間を抑えるには、今回のバッチに限らず、やはりサーバレス構成が有力な選択肢になると考えています

◆執筆：株式会社カンリー プラットフォーム部 SRE 本間 雄基
@paya02_ictdev