こんにちは，Gunosy Tech Lab の tmotegi です．
Gunosy が提供している広告商品の Gunosy Ads では， Gunosy が開発したアプリのユーザ一人一人に対して興味を持つであろう広告を推定してユーザに提示しています． 今回はユーザが興味を持つ広告(=CTR が高い広告)を学習する部分をリプレイスした話について紹介しようと思います．
はじめに
従来のシステムと変更するに至った経緯について紹介します．
従来のシステム
従来のシステムでは Spark(Scala) on EMR を用いて，広告に対するユーザの興味を学習していました．
広告に対するユーザの興味を学習する処理を簡単にまとめると，
- ユーザ・広告・配信面の特徴量の整形(ベクトル化)
- 機械学習でモデルを作成
- モデル・ベクトルを保存
という流れになっています．
従来のシステムの課題
今まで開発・運用されてきたシステムですが，運用していく中で次のような課題が見えてきました．
- EMR を構成するスポットインスタンスが確保しづらいタイミングがある
- 1つのモデルを学習する際に強めのインスタンスを複数台確保するため，複数の AB テストするときにコストがかさむ
- 開発当初のチームのスキルセットと現在のチームのスキルセットが異なってきている
このような背景があり，下記の2点を重視して新システムを開発しました．
- EMR に依存せず学習を行う
- 現在のチームのスキルセットにあった技術を採用する
新システム
次に実際に開発した新システムについて紹介します．
変更点は学習データ作成・学習・保存を行っていた Spark のジョブを
- Athena による学習データ作成
- Fargate 上でユーザの興味の学習
- Fargate によるベクトルデータの import
の3つに分解しました． これらのジョブのスケジューリングはワークフローエンジンの digdag を利用しています．
Gunosy Ads の開発を行う広告技術部では ETL ジョブを行う digdag が存在しているため， 今回の新システムでもそれを利用しています． 広告技術部の digdag 環境については下記のエントリで触れられています．
digdag には豊富なプラグインがあり，Athena や ECS を操作する処理は次の2つのプラグインを用いて実行しています．
結果
学習部分を Spark から Python に置き換えたため，豊富な機械学習ライブラリを使うことができるようになり， 開発速度の向上やロジスティック回帰以外の複雑なモデルを採用することが容易となりました．
秘伝のタレのように継ぎ足し継ぎ足し開発されていた， ロジスティック回帰のモデルを Gradient Boosting Decision Tree ベースのモデルに置き換えることで， 広告の主要 KPI が安定して5%程度改善しています．
また，EMR から Fargate + Athena に置き換えたため，90%のコスト削減を達成しました．
今後の課題
今回のシステムではスピードを優先するために AWS Batch ではなく AWS Fargate を利用して実現しました． 複雑な機械学習のモデルでは膨大な学習データが必要となることもあり，Fargate でサポートされている 30GB を使っていても， メモリ不足に時々悩まされています．
現状はデータの範囲やサブサンプリングレートを調整することで対処しているケースが多いのですが， ゆくゆくは Batch に置き換えるかもしれません．(Batch をうまく使える digdag プラグインがほしいです 🙏)
おわりに
今回は Spark で構築された従来の CTR 予測のシステムを Python + SQL で構築した新システムに置き換える話を紹介しました． チームのスキルセットにあった技術を採用することで，試行のスピードや回数が増したような気がします．
Gunosy では各種プロダクトの広告配信ロジックの改善を日々進めています． 興味がありましたら，ランチなど気軽にお声がけください．
