インターン生が5日間で新システムをデプロイ！AWS Lambda+DynamoDBで広告の最適化にチャレンジ
5 月中旬から、pixiv のインターンシップに参加していた @iw_tatsu です。 5日間 (5/16 ~ 5/19, 5/30) のインターンでは、 @edvakf さんにメンターになっていただき、 ピクシブ百科事典におけるpixivコミック広告の最適化に取り組みました。 作成したコードは GitHub に置いてます。
課題: ピクシブ百科事典での pixiv コミック広告最適化
スマートフォンで見ると、 ピクシブ百科事典 の記事の最初のアコーディオンメニューには、 3 つの人気pixivコミック広告 (すべての記事で同じもの) が表示されています。
現在、この 3 つは直近で最も「いいね」を押された pixivコミックが表示されていますが、 これらを 記事ごと に最適化するのが今回の課題でした。
特に、今回はクリックをコンバージョンとして、 表示回数に対してのコンバージョン率 (CVR) が高くなるように広告の選択を最適化しています。
また、重要な制約として、 他のサービスでも利用できる汎用的なものにする というのがあり、 今回は記事のカテゴリなどのサービス特化の情報は考慮していません。 「記事ごとにクリックされる広告は異なる」というのが今回の仮説です。
取り組んだことの概要
詳しくは SlideShare にまとめていますが、 取り組んだことの概要をまとめると以下のようになります。
- 課題を CVR の高い広告を選択するバンディット問題として捉える
- システムは AWS を用いて構築
- Amazon API Gateway にリクエストを受け取る
- リクエストを AWS Lambda で処理する
ということを行っています。 データベースには、Amazon DynamoDB を用いました。
スライドの補足
Serverless Framework
スライドでは詳しく述べていませんが、 API Gateway や AWS Lambda のデプロイには、 Serverless Framework を利用しています。 作成したコードの README にも、 デプロイ方法のメモを記述しています。 これがないとコンソール上でプログラム書かないといけなくて、 バージョン管理が辛いです…。
料金体系関連
スライドではかなり省いていますが、 DynamoDB などの料金計算はやや複雑です。
特に、DynamoDB の各行の容量を直接知る方法は現状ないようで、 自分で見積もる必要があります。 今回のインターンでは、 この料金体系を考慮したテーブル設計が必要 (例: Map は Key の文字列長がサイズに影響する。 行をたくさん取る操作はお金がたくさんかかるため、 行の容量とのバランスを考えながら各行に情報を詰め込むなど) で、 結構時間をかけてしまいました (が、それも含めてとても勉強になりました)。
後、API Gateway の料金をスライドには記述し忘れていますが、 実は一番お金かかってました… ($50 程度)。
やり残したこと
基本的には、スライドや README に書いていますが、 特に考慮すべきことは、 サービスによって広告の数が違う事が考えられるので、 テーブルの設計は見直す必要があるかもということです (広告が多いとテーブルの各行の容量が大きくなって課金額が跳ね上がる)。
感想
5 日間という短い期間でしたが、 初めてのことにたくさん触れられるエンジニアとして最高の体験ができました！٩( ’ω’ )و
ほとんど書いてこなかった JavaScript を学んだり、 バンディットアルゴリズムを実際のサービスに適用してみたり、 運用費などのサービス全体を考慮した開発ができたのは 貴重な体験でした。
edvakfさん、ピクシブのみなさま、 本当にありがとうございました！
edvakfからのコメント
今回Lambdaを選んだことで、インターンの5日間という限られた時間で、ゼロから作った成果物を本番デプロイして運用するという経験ができたのは貴重でした。
料金も1週間程度で$100で済みましたし、その後のお片づけも一瞬でした。今後もインターン生などに何かを作ってもらうときに使っていけそうです。
また、コードを書くのは慣れているので比較的すぐにできても、実際に本番で使うためには価格や負荷の見積もりをしたり、見積もった上で設計段階から見なおしたり、社内の各所にかけあったりと、プログラミング以外のことが必要になってくるということを見られたのも良かったです。まさに実際の仕事を体験できたのではないでしょうか。
iw_tatsuさん、インターンお疲れ様でした！
