こんにちは、アスクルのつっきーです。
現在は自社配送システムであるとらっくるの開発を担当しています。
本記事では配送チームが抱えていた課題を、処理形式を変更することで解決した取り組みについて紹介します。
この記事で伝えたいこと
- バッチ処理の長時間化と多重起動による問題を、キューイング方式への変更で解決したこと
- システム改善による、運用負荷の軽減と処理時間を短縮することでユーザの待機時間を削減し、操作ストレス軽減や業務効率向上に貢献したこと
課題
配送チームでは、Amazon EventBridgeを使用して、ECS Fargateを1分間隔で起動するバッチ処理を運用していました。
リリース当初大きな問題は発生していませんでしたが、処理件数の増加に伴い、次の課題が顕在化しました。
- バッチ処理が1分以内に完了せず、長時間化して重複起動が発生する
- 時間の限られた業務の中で利用されるため、処理の長時間化は業務上ボトルネックとなる
- Amazon EventBridgeの仕様上、同時刻に複数の起動が発生する
- バッチ処理内で多重起動制御をしていたものの、異常終了によるシステムアラートが発生し、運用担当者の都度対応が必要になる
解決策
これらの課題を根本的に解決するため、構成自体の見直しを行い、キューイング方式に変更しました。
変更内容は次のとおりです。
変更前
Amazon EventBridge → ECS Fargateによる1分間隔でのバッチ処理。
変更後
Amazon SQS → AWS Lambdaによるキューイング方式。
結果
今回の対応により、次の効果を得られました。
- 多重起動の防止：キューイング形式に変更し、多重起動が発生しない仕組みを構築しました。
- 処理時間の短縮：以前は最大1分かかっていた処理が、約30秒に短縮しました。
- 運用負荷の削減：リリース後2ヶ月が経過しましたが、対象のアラートは0件となり、運用担当者の負荷も削減しました。
今後の取り組み
今回の改善をきっかけに、今後も以下を目指して取り組みを続けます。
- システムと業務の現場両方をより良くする
- 問題の本質に向き合い、継続的に改善する
- 利用者にとって価値のあるシステムを提供し続ける
最後までお読みいただきありがとうございました。
今後もとらっくるの進化にご期待ください！
