アドテクスタジオのDynalystの黒崎です。
約2ヶ月間のサイバーエージェントの新卒エンジニア全体の研修を終えて今年はアドテクスタジオに新卒エンジニアが15人配属されました✨?

アドテクスタジオでは独自の「ひとりDSP」という研修を開催したので、その紹介をしたいと思います?

ひとりDSPとは

その名の通り、新卒に5日間でひとりでDSPを作ってもらいます。2年前から始まり、今年で3回目の開催です?
アドテクと言っても様々な領域がありますが、まずはインターネット広告の取引方法の一つであるRTB(Real Time Bidding)というプロトコルを理解してもらう事、そこでなぜデータ分析や負荷分散、非同期処理といった技術が必要とされるのかを体感してもらう事が狙いです?

RTBはよく以下の図のように説明される事が多いです。

広告を配信したい広告主(DSP, Demand Side Platform)、広告枠を提供したいメディア(Supply Side Platform)の間で広告を取引するためのプロトコルです。
一般的に取引にはOpenRTBというプロトコルが用いられます。
仕様書もGitHubで公開されています。 ( https://openrtb.github.io/OpenRTB/ ) PDFファイルで65ページにも及びます?
これらを読んで理解するのも良いですが、簡略化した仕様でも一度DSPを作ってみて覚える方が早いですよね??
DSPは1リクエストごとにお金が絡むシステムなので、自分たちがこれから開発する広告配信プロダクトの業界内での立ち位置、どのようにして利益を上げているのか、ビジネス面から技術面の仕組みまで知ることができます?

ひとりDSPの仕様

• 2000リクエスト/秒?
• レスポンスは100ミリ秒以内, それ以上はオークションに参加できない?
• 20 広告主 / CPCは広告主ごとに異なる?
• 事前にCTR(クリック率)予測用の学習データが渡される?
• インフラのプラットフォームにはGCPを利用。予算は一人1万円まで?

一番目を引くのは2000リクエスト/秒という数字ですね?どれくらいの流量かぱっと想像つかないかもしれませんが、1日で換算すると約1.7億リクエストにもなります！?多いですね。ちなみに一般的なDSPは数万とか数十万リクエスト/秒といった規模感なのでさらに多いですね…?
100ミリ秒というレスポンスタイムの制約もアドテク業界では一般的な制約ですが、一般的なウェブアプリケーションのレスポンス速度の事を考えると、短さに驚かれるかと思います。

研修スタート！

最初に新卒2年目の先輩社員からひとりDSP研修の説明がありました?

運営/メンターは2年目の社員が中心で、3年目の社員も助っ人として少し参加しました。
去年ひとりDSP研修を受けた社員が今年は運営側に回っています?
近い代の社員がメンターをすることで新卒社員との繋がりも生まれていいですね?

開発の様子

開発作業はアドテクスタジオのオフィスで行いました。
オフィス紹介はこちら? ( アドテクスタジオ、「Hack」がテーマの新オフィスをOPEN★ )?

黙々と作業したり、新卒同士で相談したり、わいわいと開発していました。
リクエストをさばくシステムの開発も大事ですが、オークションなのでオークションで効率よく勝つロジックも作らなければならないので、事前に渡された学習用データの分析にも余念がありません?

新卒が開発したDSPの発表スライドをいくつかピックアップしてみました(クリックで拡大できます)。

C++でDSPを実装した人が二人も居たり、Apache Solrを使ってリクエストを受ける度にリクエストログをスキャンしているのに高速なクリック率予測を実装した人がいたり、今年の新卒は尖っていますね…！?

本番！

5日目が本番なので、開発に使える時間は4日間で、あっという間に5日目を迎えました。運営が用意したSSPと新卒のDSPを接続し、4時間ひたすらオークションが行われます?
スタートしたら見守るだけ…と思いきや、入札ロジックに外部からパラメータを渡して調整できるようにしている人はオークションの状況を見てパラメータを変更するのに忙しそうでした?

オークションの状況はこんな感じでした。

これは各DSP(新卒)ごとのオークションに勝って落札した数の推移です。一気に買って予算を使い切って最後は何も買わなくなった人、最初から最後までペースよく買い続けた人など、人によって買い方が違うことがわかりますね。
高い値段でたくさん買っても、広告がクリックされなければ買い付けコストだけが膨らんで赤字になってしまうので、クリック率を予測した上で適切な価格で落札する必要があります。

こちらはDSPが配信した広告がクリックされた数の推移です。クリックされる数が多ければ多いほど、売上も上がっているということになります。1クリックあたりの単価は広告主によって違うので、単価が高い広告主かつ期待されるクリック率が高いユーザやメディアほど入札額も高くすることができます。

結果発表

5日間の成果についてひとりずつプレゼンし、審査員の社員からの質問を受けます。
現場社員ならではの鋭い質問が多く、議論も活発でした?

気になる結果ですが…以下になります！

アーキテクチャ賞 & ロジック賞: Rathoreくん

サーバはKubernetesを使ってGCPのContainer Engineにディプロイしていました。Kubernetsというのは便利なcontainerized application managerのことです。Kubernetesを使うとディプロイやスケーリングなどが簡単にできます。データベースはRedisを使用しました。一台のCompute Engineインスタンスにインストールして5000 req/sぐらいの速度が得られました。今回のデータにはUserとSiteのフィーチャーがあって、両方に対してのCTRを計算しました。CTRのデータをRedisに保存して、Bid Requestが来たら両方のCTRの重み付き平均をとってCTRを予測しました。重みはデータにあるそのUserの件の数とSiteの件の数にしました。

Rathoreくんはダブル受賞です！?

利益賞 1位: 押切くん

仕様と開発期間を考慮した上で，インフラ構成は GCE インスタンス1台のみ，各広告主の残予算などの情報はシングルトンで管理 (+ JSON でバックアップ) する，という非常に雑な構成で挑みました．CTR 予測部分の調整が不十分だったのが原因で競技開始直後はほぼすべての枠が赤字になったりもしましたが，Go で実装していたおかげで修正版を競技中に素早くデプロイすることができ，競技途中からは安定して利益を出せるようになりました．

利益賞 2位: 諸澤くん

全体の構成は、4台立てたGCEにLBを用いて負荷分散をし、CTR予測の情報と予算管理には、各々Redisを用いた構成としました。工夫した点は、競技中に自分のDSPのWin Noticeから他のDSPの状況を考え、他のロジックのサーバをインスタンスグループに追加して検証した点です。検証の結果、別のロジックのサーバの方が利益を出すことができたため、全てのサーバを別のロジックのインスタンスに置き換えました。今回の研修では、興味のあったScalaやPlay、Redisを初めて触りとても不安でしたが、二位という結果を残すことができ、かつ技術的挑戦することができました。メンターの方々や色々教えてくれた同期にとても感謝しています。

利益賞 3位: 神場くん

ひとまず最低限戦えるものを作りたかったので、予算管理とインスタンスの台数を簡単に変えられる仕組みを先に作りました。CTR予測は事前の学習データから計算したもの(ユーザーごとに集計して出したCTR)をメモリ上に置いてそのまま使うことにし、予算だけをRedisに保存していました。3位入賞出来て良かったです。

5日間と短期間なのに集中して作り上げたのはさすがですね。
この研修の翌週から新卒はアドテクスタジオ内の各チームに配属されていきました。
新卒の皆さん、社員一同活躍を期待していますので、存分に暴れてくださいね！?