この記事はCyberAgent Developers Advent Calendar 2017 12日目の記事です。
現在、サイバーエージェントのアドテクスタジオという部署で、ある新規プロダクトの開発チームの責任者している、新田智啓といいます。開発しているプロダクトはアドテクのDSPプロダクトで、今回はこのアドテク配信プロダクトについて話をしようと思います。
私はSIer出身で、アドテクスタジオに入るまでアドテクというものを全く知りませんでした。私はアドテクがサーバーサイドエンジニアとしてチャレンジングで面白い環境と感じていて、アドテクというシステムがどのようなものかを伝えたいと考えて、今回の機会に紹介したいと思いました。
意識せずに触れているアドテク
普段、意識せずに触れているアドテクというものがどのようなシステムか、どのような技術を使っているか、DSPのプロダクトがどのような規模感で、どのような技術が使われているか、アドテク業界では普通の話かもしれませんが世間に出てきづらい情報かと思いますので、あらためてこの流れを紹介したいと思います。
まずはアドテクとはどういうものか？
凄くシンプルに説明すると、普段何かのネットページを見ていると何気なく表示される広告バナー。これらの広告を配信しているのがアドテク(Ad Technology)です。
アドテク業界の用語や業務的な部分はこちらも参考にしてみてください。
日本一優しいアドテク教室
https://adtech.cyberagent.io/pr/archives/3601
RTB – アドテクのオークションシステム
アドテクの広告を表示するためのシステムの１つとして、RTBがあります。
RTB(Real Time Bidding)は広告が表示される瞬間に毎回開催されるオークションです。
このオークションを開く側のプロダクトを作っている会社や入札する側のプロダクトを作っている会社など、複数の会社のシステムが繋がり、絡み合いながらアドテクノロジーの生態系を作っています。
広告が表示される時に何が起こってるのでしょうか？
ユーザがメディアでページを表示したときにメディアはSSPに広告を表示したい意図のリクエストを送ります。メディアにはブログサイトやポータルサイト、日記やまとめサイトなど色々なメディアがあります。
そして、その広告表示リクエストを誰が買うかを決めるため、SSPはオークションを開き、その入札のリクエストをDSPへ送信します。
DSPはそのオークションに対して入札のレスポンスを返します。入札金額が一番高い金額を付けたDSPの広告がやっと表示されます。ユーザが１回ウェブページを表示される度にリクエストを送られることになり、広告が表示出来る可能性があるならばリクエストが来ることになるため、DSPは実際に広告を表示できなくても大量のリクエストを受けることになります。大量のリクエストを受けることになるため、一つのSSPで1万QPS(Query Per Second)以上ある接続も当たり前です。
そして、オークションなので時間制限があります。
広告を表示するまでの時間が長いと広告を見ずに立ち去ってしまうユーザが大量に出てしまうため、オークションは時間は100ms(ミリ秒)とされています。SSPがリクエストを送信して、DSPがSSPにレスポンスが返るまでの時間で100msのため、実際はネットワーク部分に掛かる時間として50ms程度の利用を見積もり、アプリケーションサーバでは残り50ms以内に処理を完了し、データを返さなければなりません。
その50msの中でDSPはどのようなことをするのかによって、広告の効果に数字として出てきます。また、色々なサイトに広告を出せるようにするためにDSPは複数のSSPに接続する開発を行います。
そうすると、秒間で10万を超えるリクエストを受けるのは珍しくありません。その全てのリクエストに対してアプリケーションサーバは50ms以内に全てレスポンスを返します。そして、毎秒10万のリクエストを受けていれば、それに対するログは１日で数十億レコードになります。それらの大量データを集計しなければ、入札の最適化が出来ないことはもちろん、自分たちが広告によって得た売上すら計算が出来ません。
このような高スループット、低レイテンシー、大量データの課題を解決するために常に新しい技術を日常的に使っています。
私の所属している新規プロダクトであっても最低ラインが1万QPS程度は受けられるように作らなければなりませんし、将来に秒間10万や20万のリクエストを処理できるアーキテクチャで作っていかなければなりません。
今回はそれらの技術について、どのように使われているかをさわりだけでも伝えられればと思っています。
アドテクのRTBと接続しているDSPのシステム
前置きが長くなりました。ここからDSPのシステムアーキテクチャなどの紹介をしたいと思います。
このような業務要件の中で重要になるのは技術の選定とアーキテクチャの設計になります。アドテクスタジオはアドテクに関わる複数のプロダクトがあり、それぞれのチームが自由に技術を選定しています。技術要求が高いため、課題に合わせた技術を選択する必要があるからです。
アドテクスタジオで使われている技術
インフラのプラットフォームはAWS、GCP、プライベートクラウドのOpenStack環境がよく利用されています。オークションへ入札処理を行う入札サーバ(bidサーバ)は通常のHTTPを使うWebサーバで、アドテクスタジオではScalaを採用しているプロダクトが多いです。最近ではGoを使っているプロダクトも増えています。重要なのはハイトラフィックなデータを高速に低コストで処理できる必要があることです。最近ではGCP環境でKubernetersを利用して、GKEでの管理を行っているプロダクトも増えています。AWSでCloudFormationなどを利用しているプロダクトもあります。
この入札サーバは50msで処理を完了しなければならないため、計算のロジックも気にしますが、時間的コストが掛かるIOのデータストレージが一番の気になるポイントです。
よく使われるRDBでは大量のレプリカなどが必要になるため、bidサーバを実装する際に直接RDBをReadするように設計することは稀です。bidサーバから参照されるデータは広告主が登録した広告xメディアxユーザ情報により最適化しています。ユーザだけでも数千万データがあるのは当然ですし、それに対して広告やメディアが掛け算で増えたデータが最適な広告を選択するためには必要です。それらのデータを1msなどで取り出したいわけです。想像するだけでRDBでは厳しい部分があります。
そこで選択するミドルウェアとして、基本的に高速なオンメモリキャッシュかRedisやAeroSpike等の1ms以内で処理を返せるようなKVSを利用します。DynamoDBやBigTable、Spannerなども低レイテンシーを謳っていますが、アドテクのbidサーバを支えるには4-8ms掛かると、50msという時間範囲では出来る処理の回数が少なくなってしまうため、かなり厳しいです。もし、それらのストレージを使う場合には１リクエストに対するアクセス回数を1-2回に限定するか、キャッシュ機構を作る必要があります。
大量のデータの保存
次に受けたリクエストの情報はレポートや最適化に利用するために保存する必要があります。データはfluentdなどを使って転送しています。転送先はS3、GCS、BigQuery、Redshift、Kafka、Kinesis、PubSubなど、プラットフォームやアーキテクチャによって違います。
ちなみにRedshiftへの転送はしてる場合にはデータ容量を気をつける必要があります。スピード(SSD化)と容量を同時に実現するためにはコストが掛かり過ぎてしまうためです。コストバランスを見た場合に、限界容量が低く、配信の全てのデータを入れる容量を確保するためにはコストが高すぎるため実際には難しいからです。Redshiftに入り切らないデータを扱うのもアドテクならではかもしれません。全データの検索が必要なDMP(Data Management Platform)などは必要な全てのデータをRedshift等に入れることもあります。
月次のレポートを作成したいと考えると10万qps x 60秒 x 60分 x 24時間 x 30日 = 259,200,000,000 ≒ 2600億レコードのデータの集計が必要になります。これらも単純なcountやsumだけでよければ、それほど難しくありませんが、最適化などを前提にした計算処理の場合、しっかりとした足場で実装する必要があります。もはや10億が誤差にしか見えません・・・。大きなメディアであっても月間PV等が億単位のものは多くはないので、アドテクの中で普通に経験出来る環境が、他の環境では多くないことが分かります。
そしてアドテクで扱うデータはとても大きいため、コストバランスも技術選択の要素の１つになります。選択を失敗すると毎月のコストのインパクトとなって返ってきます。
次に受信したデータの処理になります。
極力リアルタイム性を要求されるプロダクトでは高スループットなキューシステムに入れたデータはサブスクライバによってデータを処理します。ここは普通にデーモン化したアプリケーションでデータを取得しながら処理を行うものもあれば、Streaming処理基盤を利用したシステムのものもあります。
KCL(Kinesis Client)やSpark Streaming、Cloud Dataflow(Apache Beam)などです。
もし、S3やGCSなどを転送先のシステムでは１時間や１日単位でのバッチ処理でも可能です。ただ、最近はfluentdのプラグインでS3やGCSに保存することが出来るので、バッチ処理を選択するケースは少ないと思われます。
レポート集計処理
レポート集計単位(1時間分/1日分)のデータが入りきる場合にはRedshiftなどを利用したり、それ以上のデータを利用したい場合にはBigQueryに入れている場合はそのまま集計などをしています。最近ではRedshift SpectrumやAthena等の選択肢も増えたためAWS上でも大きなデータを集計しやすい基盤が出来てきました。
データの活用方法では前記の通りレポートだけではなく入札最適化の計算処理も行われます。AIなどが流行していますが、アドテクでも積極的に使われている技術になります。データの統計的な情報を計算や機械学習を行い、次の入札の効率化をするデータを作ります。前記のRedshift、Sparkの他にHiveやSparkなどを利用しているプロダクトが多いです。
AIなどを使った技術でアドテクスタジオで、どのようなことを行っているかはAI Labの発表などの記事を参照してみてください。
https://www.cyberagent.co.jp/techinfo/labo/ai/
入札状況、システム状況のビジュアル化
次に入札状況やシステム情報のビジュアル化です。
ユーザ毎に値を変えながら入札処理を行い、日々の状況によってシステムが自動的に入札額や入札頻度を調整するため、システム的に正しくても、業務的におかしな入札額になっていたり、入札件数が極端に減っていたりすることをシステム的に発見することは、かなりの作り込みをしなければ困難です。また、エンジニアだけではなくビジネスメンバーもデータを使って次のアクションを考えるようにしなければなりません。
これらはTableauやDataStudio、re:dash、supersetなどでビジネスメンバーが見やすいツールを導入したり、ElasticsearchやGraphite、druidなどのストレージとKibanaやGrafanaのビジュアルツールを使ったリアルタイムなビジュアル化を行っています。
そして、システム的な監視もCloudWatchやStackDriver、Datadogなどで行っていて、他の通知サービスと組み合わせてシステムの監視を行い、問題の際にはチャット、メール、電話などで通知がされるようになっています。
アドテクのシステムのまとめ
規模感、レイテンシ、データサイクル、最適化などが組み合わさって初めてユーザに価値ある情報として広告を届けることが出来ます。
これが不十分であれば、ユーザにはノイズにしかならない広告を表示してしまいます。広告主にとっても、ユーザにとっても価値があるプロダクトを作るために、システムと向き合っています。
今回はRTBのオークションのDSP部分だけを紹介しましたが、実際にはこれ以外にもさまざまなシステム連携、集計機能の実装、入札予測ロジックの作成など、多くの機能が必要であり、技術的なチャレンジが必要なシステムになっています。
WebのCRUDを中心としたシステムとは少し違ったアーキテクチャが求められるアドテクについて少しでも興味を持ってもらえたら幸いです。
今回はエンジニアとしてこのような環境があることを知ってもらい、興味を持ってもらいたいと思い、この記事を書きました。
１つ注意なのですが、広告を扱っているシステムといっても２つの種類があります。アドテクは広告の配信プロダクトを持っている会社と、広告配信のために入稿のオペレーションのプロダクトを持っている会社があります。今回のようなアーキテクチャは広告配信のプロダクトを作っている会社になります。ぜひ、広告配信に関連するアドテクのシステムに触れてみて下さい。
アドテクスタジオで利用されている技術についてはこちらにも記事があります。
AdTech Studio Tech Blog
https://adtech.cyberagent.io/techblog/
アドテクのシステムや技術に興味がある人が居ましたら、定期的に勉強会を開いていたり、常に募集をしていますので、ぜひ話を聞きに来て下さい。
(上記のページのCONTACTから個別でメッセージを送って頂けます)