バックエンドエンジニアチームがビッグデータ集計のAWSコストを50％削減、集計時間を1/5に短縮した方法
フルカイテン株式会社にてプロダクト開発部バックエンドデータ基盤チーム(社内名称：monetチーム)のリーダーに就いている齊藤と申します。
本日は、AWSのコスト削減と日々のデータ集計の時間の短縮（パフォーマンスチューニング）について共有できればと思います。
以下のような方向けに弊社が直面した課題や現在の取組みをご紹介いたします。何か一つでも参考になれば幸いです。
・大規模データ基盤の運用をしている方
・その中でも集計時間に課題を抱えている方
実施結果
・データの流通総額について：
累計：1兆5,010億円
6月：564億円
7月：558億円
8月：484億円
3ヶ月平均：535億円
・コスト削減の推移
2023年12月の最高額から約50%カット
・集計時間
15時間→3時間に短縮できた
縦軸：処理時間（分）
横軸：日付（週）
開発の概要について
弊社の顧客は中・大手小売業になります。弊社プロダクトのFULL KAITENは1兆5,000億円規模の流通総額を蓄積しています。これはデータ件数に換算すると、何百億件ものレコード数になります。
そのようなレコード数のデータを、我々データ基盤チームではSKU×店舗などの様々な切り口で集計しています。企業の売上や在庫の数、店舗数などで計算量は変わってきますが、一番規模の大きなお客様では一社で毎日1億件以上のレコードを生成しています。
プロダクトの成長に比例してAWSのコストも高くなっていました。
こういった状況から、この約2年間で私達が行った改善や施策についてご紹介します。
チームの概要
正社員：2名 齊藤（筆者）・田畑
業務委託：4名
エンジニアとしてプロフェッショナルなメンバーで、業務委託2人は機械学習の知識もあり。※チームメンバーのコメントを最後に載せています。
推進前（〜2022年下期）
2022年10月、私がジョインした当時は、横田がmonetチームのリーダーでした。入社当時、monetデータの流れが複雑で追い付くのに必死すぎて記憶がない…自分以外のメンバーは変わっていないので体制は今と同じです。
↓ 私の入社エントリ―はこちらです。
当時の対応を振り返ると、チューニングの速度改善は定期的に行っていました。現状で妥協することなく、常に改善活動をしていました。
自分が入社した時はデータの集計をRedshiftベースからGlueベースへリプレイスを実施していて、その時の話は横田がQiita記事にまとめています。
これにより速度改善はできましたが、Glueは利用単価が高いため全体のAWSコストは増加傾向にありました。
推進時（2023年7月〜）
RedshiftからGlueへのリプレイスを終えてからも、開発の合間合間で地道にコツコツとパフォーマンスチューニングを続けました。
具体的には
利用しているデータソース（Athena/Redshift）のパーティションキーを利用実績から調整
Pyspark内で作成しているパーティションキーをデータの偏りを分析して最適化
同じくPyspark内で利用しているキャッシュ方式変更や利用廃止などの見直し
効果は大小あるものの、チューニングを積み重ねることで集計するのに一日あたり最大15時間程度かかっていた顧客が3時間程度にまで短縮することができました。
2023年4月に私がmonetチームのリーダーになり、横田はバックエンドチームのマネージャに。ようやく外に目を向ける余裕が出始めた頃でした。
ある時、ふとAWSの月々の費用を画面で見たら高額になっていて驚きました。推進前に切り替えたGlueと、アカウントの増加に伴い増えていAurora(RDS)が費用の大きな割合を占めていました。
これだけ高額なら、処理方式を変えれば絶対に減らせると思い、マネージャーとなった横田と議論を重ね、以下の2つのコスト削減施策を進めることになりました。
AuroraからAthenaへのリプレイス
RDSに掛かる費用の中でも特に高額だったのが、書き込みに掛かるものでした。これまではパフォーマンスの観点からFULL KAITENで集計した結果のほとんどをAuroraに書き出し、画面表示もAuroraからデータ参照をしていました。
しかし検証した結果、Auroraには応答速度で劣るものの、Athenaでも実用に耐え得る速度で画面表示できることが分かりました。
費用面で非常に優位だったこともあり、リプレイスを決意。Glue処理構成の変更
Redshiftからのリプレイスを行った時点では、Glueジョブはモノリシックな構成となっていました。
そのため、Glueで設定するワーカー数も10と設定したら最初から最後まで10台のクラスタが起動し続けます。（図中：左）
ただ、集計によってはもっと少ないワーカー数で十分な処理もあるはずだという見当を付けていました。（図中：集計B～集計E）
そのためGlueで実行していた200を超える集計を見直し、FULL KAITENの機能ごとにGlueジョブを分割することでworkerの最適化が実行出来る形に進めていくことに。（図中：右）
洗練期（2024年2月）
これは偶然ですが、2つのコスト削減施策のリリース時期が重なり、どちらも2024年の2月前半になりました。
AthenaへのリプレイスによりAuroraの書き込み費用が、Glue処理構成変更によりGlueのDPU費用が、それぞれ見込み通り削減できました。
他にも細々とS3ファイルの整理やライフサイクルの設定なども行っていた影響で、ピークとなっていた2023年12月と比較すると最大50%まで月額費用を抑えることができました！
今後について
今回の対応で全社ではピークとなっていた2023年12月と比較して最大50%のコスト削減が実現できました。 しかし、個社にフォーカスするとまだまだ削減の余地がありそうなところも散見されるため、改善の余地があると考えています。
また先ほどのグラフで、2024年4月以降、費用が微増傾向にあることが分かります。これは契約社数の増加や機能追加によるものです。
プロダクトの成長とランニング費用の増加は基本的には比例していくもの。
今後も、様々な手段で処理の効率化を図り、ランニング費用の増加を抑えていきたいと思います。
これを読んで下さっている方で、特に
・Glueを用いた効率的なビッグデータ処理
・クエリのパフォーマンスチューニング
が得意だという方がいたら、是非一緒に働きませんか？
世界の大量廃棄問題を解決するという壮大なミッションの実現を一緒に目指しましょう！
補足：メンバーに聞いたチームと仕事の魅力
久保：
テクニカルな知識量はもちろんですが、最新のテクノロジーを取り入れることへのフットワークがとても軽く臨機応変に感じていて、とても勉強になります。
方：
・技術面
- 先進のデータ基盤を使っている: Redshift、Spark、ECS Farget, Sagemakerなど
- 開発効率が高い: 一貫性を持つCICD、DEBUG実行環境、移行ツールなど
- 比較的に低い学習コスト: Pythonベースのソースコードが簡潔、構造化されるスクリプト、定期的にソースをリファクタリングしている
- メンバーがハイスキル（みんなプロフェッショナル）
・環境面
- 大きい仕様変更が少ない
- 正確なプロダクト仕様がある
- スケジュール管理がうまい: Jiraなどのツールで進捗を正確に把握して、開発を進めながら調整できる
- チーム内のナレッジ共有が上手くできている
- 助け合う社風（雰囲気？）
長谷川：新しい技術を取り入れるスピードが速く、メンバーの適応能力も高いところ。
蔡：
マネジメント力、設計スキル、テクニカルな実装、タスク遂行スピード等、各メンバーが持っているスキルがすごいなと感じます。
フルカイテンバックエンドチームの紹介はこちら！
フルカイテンの採用情報はこちらからどうぞ。
この記事が気に入ったらサポートをしてみませんか？