大規模広告配信システムからデータプラットフォームまで　マイクロアドのインフラの舞台裏

インターネット広告の仕組み

中野翔太氏（以下、中野）：それでは、マイクロアドの発表を始めさせていただきます。よろしくお願いします。

（会場拍手）

中野：ありがとうございます。マイクロアドに中途で入社して3年目の中野翔太と申します。経歴としましては、新卒でSIerに入社したんですけれども1年ほどで辞めて、その後マイクロアドに転職をしました。現在社会人5年目の28歳です。最近はScalaを書くことが多くなっています。では、本日はよろしくお願いします。

まず、マイクロアドの会社の概要です。事業内容としてはデータプラットフォームとかアドプラットフォームということをやっている会社で、本社が渋谷にあり、設立が2007年7月、今月でちょうど11年になりました。

社員数は200人いて、そのうち約30名ぐらいがエンジニアです。東京と京都に開発拠点がありまして、京都はだいたいエンジニア5人ぐらいで、エンジニアだけのすごく静かな環境でやっております。

ということで、本日は最初に、マイクロアドの事業や技術を説明した後に、実際にどんな開発案件があるのかを紹介します。そして最後に会社のイベントや制度などを、紹介していこうかなと思っています。

では、最初はマイクロアドの事業、技術について説明していきます。マイクロアドは、インターネット広告とデータの会社と覚えていただければと思います。

広告の分野でさまざまな商品持ってるんですけれども、本日はアドプラットフォームを中心に説明をさせていただきます。

ところでみなさん、インターネット広告の仕組みはご存知ですか？　例えばサイトのAというところに訪れて、最初は転職系の広告が出ました。そして、2回目に同じサイトAに訪れた時には車の広告が出てくるみたいな、同じサイトを訪れても違う広告が表示される、ということを経験したことがあると思います。

これは何が起きてるかというと、広告枠が設置されたサイトが表示された瞬間に、その都度オークションが行われていて、表示される広告が選定される、ということが行われています。この仕組みのことをReal Time Bidding、RTBと言います。

RTBにおいては、この図の真ん中にあるSSPだとか、DSPというプレイヤーが存在しています。SSPやDSPというのは特定の製品の名前ではなくて、こういう広告配信を行うプラットフォームの総称だと思っていただければ問題ありません。

ちなみに、SSPというのがメディア側の収益最大化を行うプラットフォームで、DSPというものは広告主側の広告効果を最大化するためのプラットフォームです。

RTBの仕組み

では、ちょっとこの図を説明していくと、サイトAが表示された時に、まずSSPにリクエストが飛びます。

そしてSSPから接続されているDSPに対して、「こんなリクエストが来ましたよ」というリクエストを送って、DSP側でそれぞれどんな広告を出すかなど、その広告に対して値付けをし、その結果をSSPに返します。

この図の例でいうと、3つのDSPの中で一番転職の広告の50円が高いために、サイトAには最終的に転職広告が表示される、ということが行われています。

この広告枠、サイトAが表示されて実際に広告が出るまでという時間なんですけれども、たった0.1秒で行われています。このあたり、けっこうアドテクのおもしろさかなというふうに思っています。あと、ちょっと注意してもらいたいのが、ここでは1回のリクエストで10円とか50円とか出してるんですけれども、実際には0.何円とかそれぐらいの値段になっています。

先ほどの図のSSPやDSPという製品を、マイクロアドでは両方持っています。SSPは「COMPASS」という製品で、DSPは「BLADE」という製品です。

ここからちょっとシステム的な紹介をします。BLADEに特化した紹介なんですけれども、まず一番上のBidリクエスト150億、インプレッション30億というところなんですけれども、先ほどのSSPからのリクエストというものが、マイクロアドのBLADEでは1日に150億件ほど来ております。で、月間で4,000億を超えるぐらいの数字です。

インプレッションというのは表示ですね。約1億ぐらいの広告表示が、マイクロアドのBLADEから毎日行われていて、月間で30億ぐらいの規模になっております。これらのデータを全部ログに記録しておいて、分析に活用しています。

ピーク時は20万のQPSがあり、レスポンスは5～10ミリ秒ほどなんですけれども、0.1秒を過ぎてしまうと、まったく広告の配信対象にならないので、MicroAd BLADEではできるだけ早いタイミングでSSPに対してレスポンスできるようにしています。広告は数千から数万あるんですが、その選定をたったこれだけの時間で行っている、というシステムです。

それらの高トラフィックでハイパフォーマンスな広告配信アプリケーションには、ScalaやJavaを使っております。また、そのデータの分析だとかバッチ処理にはPythonを利用しております。

他には広告の配信を行ううえで、どんなデータを使うことによって適切なユーザーに広告を配信できるか、というのが重要になっています。うちではCCCさんのデータとか、ソフトバンクさんのデータとか、会社では出さないんですけれども、位置情報のデータだとか、EC購買データを使って、ユーザーに対して適切な広告を配信できるようにしています。

あと、一番下の1,500台というのは、これはBLADEだけの数ではないんですけれども、弊社で持っているサーバは1,500台ほどありまして、すべてオンプレミスで持っています。「なんでオンプレミスなの？」と気になる人もいると思います。本日は弊社のインフラエンジニアも来ていますので、ぜひ興味ある人は懇親会に来ていただければと思います。

データプラットフォーム「UNIVERSE」

というわけで、アドテクのほうの説明はこれで終わりで、もう1個のデータプラットフォームを説明していきます。マイクロアドはこれまでアドテクの領域でやってきた会社なんですけれども、アドテクでやっていくうえでデータの収集をしたりだとか、データの蓄積をしたり、それを分析したりというノウハウがたまってきています。それを活用して、データプラットフォームをつくっています。それが「UNIVERSE」というものです。

データプラットフォームと言われても、おそらく「何だそれ」と思うと思うので、具体的な例を説明していきたいと思います。例えば、あるユーザーに対してオンライン上の行動履歴というものがあって、「世田谷区在住」「30代男性」「旅行サイトで申し込みあり」「ポルシェに興味あり」みたいなデータがあるとします。

こういうものを見た時、みなさんだったらどんな人だと思いますか？　僕はおそらくこのデータだけ見ると、ちょっとお金に余裕のある人かなと思います。このオンライン上の行動履歴だけだと、これぐらいのことしかわからないんですが、このユーザーに対していろんなデータを使う。例えば位置情報データであったり、EC購買データであったり。

そして位置情報で平日は渋谷にいることがわかれば、「おそらくこの人は渋谷の会社に勤める人だな」ということがわかったり。EC購買データを見て、トーマスのおもちゃとかNintendo Switchを買っているのを見ると、「あ、この人はもしかしたら子供がいるかもしれない」ということが予測できるようになります。

UNIVERSEでやりたいことというのはこういうことで、いろんなデータをつなげることによって、人物像が詳細に浮かび上がってくる。こういったデータを使うことで、広告配信をより正確にしたり、広告配信だけではなくて、実際にこのデータを使ってオフラインでの購買、つまりマーケティングに利用することも考えています。

UNIVERSEシリーズの紹介

そのUNIVERSEという製品の1個の機能としてリリースされたものがこのFFMです。FFMはFull Funnel Managementの略なんですが、マーケティングの用語でこういったファネル分析というものがあるみたいです。

そして、それを適用したようなシステムなんですけれども、やりたいことはKPIを設定したうえで、ユーザーごとのオンラインの行動履歴をリアルタイムで分析して、スコアリングします。その数値によって、上から潜在層、見込層、直近層みたいなもの、ユーザーがどれだけいるかということを可視化できるシステムです。

ファーストリリースとして、こういう画面つくっています。これはVue.jsでつくっています。

FFMでは、オンライン上のデータだけではなく、実際にオフラインの行動をKPI設定したりしていて、これからさらに精度を上げていくというようなフェーズになっております。

また、そのUNIVERSEというものの関連で、「UNIVERSE Bidder」というものを、「仮」と書いているんですけど、開発しています。

アーキテクチャの刷新だったりとか、UNIVERSEのデータを使って、より詳細というか、正確な広告配信を行うための広告配信プラットフォームをつくろうとしています。現在以下のような技術を採用予定です。もし新規に広告配信のプラットフォームをつくることに興味ある方いれば、ぜひこの後足を運んでいただければと思います。

まとめです。マイクロアドはこれまでアドテクな会社だったんですけれども、これからはデータビジネスに注力するというところです。こちらでマイクロアドの事業についての説明は終わりです。

サイトのアクセスログをリアルタイムに処理

続いて、実際にどんな開発をしているのかを説明していきたいと思います。事例2つ紹介します。

1つ目は、「サイトアクセスログ」という案件です。

先ほど説明したUNIVERSEのFFMというもので、ユーザーのオンライン上の行動をリアルタイムに分析したデータを利用していたんですけれども、そのデータをつくっているのがこの案件になります。

例えば、トップページにアクセスをして、次に商品ページに行って、購入ページに行った。そういった人は実際に購入しやすい。こういった事実があるとすれば、こういう人に対して広告をどんどん出していこう、みたいなことができます。

つまりここで言いたいことは、断片的なページのアクセスではなくて、連続的な行動を把握することで、より正確な広告配信を行うということです。

システム的な要件としては、2～5万QPSとか、これも比較的ハイパフォーマンスなものが要求されますが、アクセスのデータを全部そのまま使うんではなくて、マイクロアドが持ってるデータと紐付けて、より分析しやすいものだとか、意味のあるデータをつくるだとか。

あと、トップページ、商品ページ、購入ページといった順序がけっこう大事になってくるので、ログの順序は正確に保持する、みたいな要件があります。

この問題を解決するために、以下のような構成を取って開発をしています。

ストリーム処理にはSpark Streamingを用いて、メッセージのキューイングにKafkaを使用してます。そしていったんサイトにアクセスした情報というものを全部Kafkaに集約して、Spark Streamingで全部リアルタイムに購読してログを変換する、みたいなことをやっております。

こちらは、Direct Streamという方式を取っていて、これはKafkaとSpark間の並行処理を容易に実装できたり、At least onceを保証できます。

まあ、購読の処理で重複排除をしているので、At least onceでOKですね。

あと、QPSのところなんですが、DBに入ってるデータを、アプリケーション起動時に全部メモリーに保持させて、高速化をしています。

ただ、そのアプリケーション起動時に持っているデータは、DBが更新されたら古くなっていくので、定期的にそのデータも更新しており、それにはAkkaのSchedulerなどを使っています。

また、エグゼキュータ間でデータの不整合が生じてはいけないので、マスタのデータからブロードキャストすることで、不整合が発生しないようにしています。

ということで、このデータを使ってリアルタイムにスコア算出が可能になりました。また、これによって、その瞬間に実際に購入をしたりする、コンバージョンというんですけど、その確率の高いユーザーに対しての配信が可能になりました。

入札額の算出フローを刷新する

2つ目の案件として紹介させていただくのが、「入札額算出フロー刷新」です。

入札額というのは、おさらいになるんですけれども、先ほどのRTBという、リアルタイムなオークションにおいて、広告に対して値段を付けるという処理です。

弊社では今、この広告に値段を付けるというのをバッチ処理でやってまして、それを算出した値をリアルタイムに取ってくるという処理を行っています。

ただ、この入札額の算出フロー、DSPにとってはめちゃくちゃ大切な処理なんですが、基盤に問題があって。ゾウさんがいっぱいいるんですが、必要なデータがいろんなHadoopクラスタに散らばっていたりだとか、DWHがそもそもスケールがめっちゃしづらい製品だったりだとか。

あと、分析ツールもコードで管理できないもので、データサイエンティストしか仕様を知らない、エンジニアがまったく何が行われてるかわからない、みたいな状況でした。という、いろいろひどい状況があったんですけが、今回、サーバサイドエンジニアとして担当したところが、下の「ジョブ管理」というところです。

さきほどのアーキテクチャというのは、今、実はけっこうシンプルな構成になってまして、DWHもすべてHadoopに変えて、1つのクラスタでデータを管理する、みたいなかたちになってます。こちらもエンジニアブログ書いてますので、ぜひチェックしていただければと思います。

カオスなワークフローをシンプルに

ということで、ワークフローもカオスになっていたんですが、そこを解消するためにDigdagという、Treasure Dataさんがメインで開発をしている、オープンソースのワークフロー管理ツールを導入することになりました。

なぜこれを導入したかといいますと、yamlに似たDSLでワークフローを記述できるということで、学習コストがかなり低いこと。あとは誰でも読めるので、データサイエンティストの人とかとも、あまり勉強しなくても、「このワークフローは違うんじゃない」みたいな話ができたりします。

あと、Dockerコンテナでの実行を標準サポートしてるので、実行環境に依存しない処理がガンガン書けたり、ワークフロー管理で最低限必要な要件、どこまでジョブが実行されたかを記録する機能も標準で備えていたため、Digdagを採用しています。

具体的にはこういうかたちの処理になってます。

例えば、Jenkinsやcronでやっていた時は、1のデータが1時に終わる、で、2のデータ作成が2時に終わるみたいな、そういう時間をだいたいで予測して、その時間を指定して実行してたので、もし前のデータ作成処理が長引いた時に、その前のデータ作成が終わってないのに次のデータがつくられ始めて、エラーが起きてしまうということがありました。

ただ、Digdagを採用することで、それぞれの処理のスケジュールや依存関係を、ちゃんと依存をしたかたちで実行できるようになり、解決しました。実際のDigdagのコードはこんな感じですね。

最終的にこんな感じのシンプルなフローになりました。

技術選定における裁量について

まとめとしては、2つの事例の紹介をしました。ここで、どんな開発をしたのかというイメージを持っていただきたかったんですけれども、メインで言いたかったこととしては、マイクロアドでは技術選定とか、問題があってそれを解決するための技術の選定は、トップダウン式で決まりません。

この案件を担当するエンジニアが、その技術を選んで検証を行い、「この技術を使う」という裁量権を与えられています。なので、けっこういろんな技術試したい人とかは楽しめる環境にあるかな、というふうに思います。

これで案件の紹介を終わりにします。最後に、軽く社内のイベントとか制度について、紹介をさせていただきたいと思います。

マイクロアドでは、毎週金曜日に勉強会を開催しています。主に業務に関する内容で実施していまして、この社内ライブラリの話だとか、DDDを新しく導入したチームが他のチームに共有をしたりする勉強会を行ったりしています。

あとは、LT会を、だいたい3ヶ月のうち2回ぐらい開催していて、寿司やピザやビールを一緒に、ゆるい雰囲気で実施をしております。

また、自己研鑽補助の制度として、半期7万円ぐらい、書籍を買ったり、勉強会の参加費が補助されるという制度があります。

以上で発表は終わりになるんですけれども、マイクロアドは絶賛採用強化中です。データでビジネス、アドテクに興味ある方は、ぜひこの後マイクロアドの懇親会にお越しください。以上、ありがとうございました。

（会場拍手）