バイセル Tech Blog

バイセル Tech Blogは株式会社BuySell Technologiesのエンジニア達が知見・発見を共有する技術ブログです。

バイセル Tech Blog

データ拡大に伴う長期運用プロダクトの改善事例紹介

はじめに

こちらは バイセルテクノロジーズ Advent Calendar 2023 の14日目の記事です。
昨日は岩下さんによる資格支援制度を使って、アプリケーションエンジニアがGCPのキャッチアップをした話でした。

こんにちは、開発1部でエンジニアリングマネージャーをしている加藤です。

現在、私はAXISという在庫・販売管理システムのマネジメントを担当しています。
運用も5年ほど経過し、長期運用プロダクトとして様々な課題が生じています。

今年1年間で、AXISチームでは様々な改善を行なってきました。

そこで今回、いくつかの課題に関して、どのように解決したかをピックアップして紹介いたします。

長期運用しているプロダクトでは、どのような課題があり、それらを解決するためにはどのような改善を行ったか、事例として参考にして頂ければ幸いです。

AXISとは

以前、何度か別のブログ記事で紹介しておりますが、AXISは2018年10月にリリースされた、バイセルのリユース事業の柱である「在庫・販売管理」を支えるシステムです。
別の買取システムと連携して、買取した商品の在庫情報を保持しています。 それらをECサイトや催事などのチャネルで、販売するまでのフローをAXISでは管理しています。

改善した取り組みの紹介

では早速、この1年で改善した取り組みに関して、いくつか紹介させて頂ければと思います。

その1: 棚卸明細作成バッチのチューニング

バイセルでは、半年に1回、商品在庫の棚卸を実施しています。
上記の棚卸を実施する日の前日に、商品の在庫数などの情報をまとめて、CSVファイルとして書き出す為のデータをバッチ処理で作成しています。

AXISの運用を始めた当初は、数万規模だった在庫が、運用開始5年で数十万件単位まで増え、このバッチ処理にも非常に時間が掛かるようになっていました。

昨年の12月に実施した時点で、バッチ処理が終わるまで約5時間近くの時間が掛かっていました。

そこで、処理を見直し、コードのチューニングを実施しました。

  • 愚直にN+1が発生していた箇所の解消

  • 関連データでpreloadできていなかった箇所の修正

元々、Sidekiqなどの非同期処理ツールの導入も検討していましたが、まず大きく処理は変えず、基本的なチューニングを実施しました。

結果、バッチ処理の実行時間を1時間以内まで短縮することに成功しました!

対象データが数十万件と多い為、少しのコード改善でも、全体的な実行時間を大きく削減することができました。

特に、長期運用しているプロダクトだと、このようにチューニングの効果が色濃く出る結果だと感じました。

その2: ブランチ運用/デプロイフローの見直し

AXISチームでは元々、下記のような git-flow でブランチ運用を行なっていました。

上記のフローだと、下記のような課題がありました。

  • テスト実行の待ち時間が多く発生していた

現状、developブランチにマージすると、staging環境へのデプロイが実行されるように設定されていました。
また、GitHub Actions でのテストコード実行のタイミングが

  • featureブランチへのコードpush時
  • Pull Request マージ時

と、複数回テストコード実行の処理が走っていました。

長期運用によりテストコードが肥大化しており、GitHub Actions 上で並列実行化は行なっていましたが、それでも全てのテストを完了するまでに15~20分程の所要時間がかかっていました。

例えば、developブランチへの Pull Request が複数存在する場合1つのリクエスト毎にマージする必要があり、コードが反映されるまで、マージの待ちが発生してしまい、開発効率が低下していました。

上記の課題の解決の為、下記のような対応を行いました。

  • ブランチ運用の見直し

git-feature-flow を参考に、下記のようなブランチ運用フローに変更しました。

変更内容的には

  • push時に走っていたテスト実行を廃止
  • Pull Request マージ時に走っていた一部のテスト実行を、Pull Request 作成時に変更

この変更によって

  • バラバラにstaging環境へ反映していた修正をまとめて反映できるようになり、反映の待ち時間も削減することができました。
  • テスト実行回数が減り、staging環境への1回のコードデプロイ時間も15~20分程(テスト実行1回分)削減することができました。
  • リリースしたい変更を集約できるので、staging環境での動作検証も行いやすくなりました。

長期運用していると、運用を始めた当初のフローそのままで運用されていることが多いですが 運用フローに関しては、定期的に見直し、最適化していくことが重要だと感じました。

その3: 在庫一括登録機能を導入し、在庫登録処理を改善

在庫の登録を行う場合、1点1点バーコードをAXISで読み込み、在庫登録を行なっています。
現在、事業成長と共に商品在庫の件数も増加していて、直近でも法人買取などの件数も増えてきています。

数百点単位で買取を行う場合、これらの在庫登録を行うのにとても時間が掛かっていました。

そこで、登録する上で必要なデータをCSVデータとして作成してもらい、そのデータを一括で在庫登録する機能を開発しました!

結果、下記の通り、在庫登録の作業時間を大きく削減することができました。

今年1年で改修した内容の中で、一番効果があった改修でした。

現場で手間の掛かっている作業をシステム的に改善できないか、検討することがやはり大切だと感じました。

まとめ

今回、長期運用プロダクトで発生しうる課題と、その解決方法の一例を紹介させて頂きました。
長期運用していると、運用を始めた当初だと想定していなかった様々な課題が発生します。
その課題をいかに解決するか、それが難しくもあり、またやりがいのあるタスクだとも感じています。

長期運用プロダクトを運用している方に、ぜひお役立ちできれば幸いです。

また、バイセルではエンジニアを随時募集しております。興味のある方はぜひ以下の採用サイトをご覧ください。
herp.careers

最後まで読んでいただきありがとうございました。明日の記事は甲田さんのモバイルデバイス2300台のMDMが、Jamf Proに移行するまでです。
ぜひご覧ください!