企画から分析まで、ほぼ毎日デプロイ　LINEのAd Network & Performance 開発室では1から100まですべて担当できる

LINE広告ネットワークについて紹介

樋村隆弘氏：では、Ad Network & Performance開発室の樋村から、私たちの部署について紹介いたします。よろしくお願いします。

最初に私の自己紹介からさせてください。私は、LINE株式会社Ad Network & Performance開発室の樋村と申します。もともとは大学時代に理論物理をやっていまして、その後、新卒でISPに入りまして、クラウドサービスの開発をしていました。

2017年3月に、ファイブ株式会社という、広告システムの開発を行っているベンチャー企業に転職しまして、同じ年にファイブがLINEに買収され子会社化したので、そこでLINEに入社しました。現在は主にLINE広告ネットワークの開発に従事しています。

最近の趣味は音ゲーで、今自粛期間中なので、自宅に筐体を買いました（笑）。よろしくお願いします。

本日のアジェンダです。まず簡単に我々で開発しているLINE広告ネットワークについて紹介したのちに、その中身と技術スタックについて紹介いたします。最後に、簡単に開発体制やチームについて紹介しようと思います。

前身はFIVE Ad Network

LINE広告ネットワークですが、前身はFIVE Ad Networkという広告ネットワークでした。なので、ちょっとファイブについても簡単に説明いたします。こちらがファイブですが、2014年10月に開発したモバイルを中心とした動画広告配信プラットフォームでした。

動画広告は、このときはまだあまりメジャーではなかったので、広告プラットフォームの配信については、全部イチから設計して開発していました。ファイブという社名の由来は5秒動画です。動画広告というと、どうしてもテレビCMを思い浮かべると思うのですが、それだと15秒や30秒といった尺になるので、あまりモバイル環境には適さないよねっということで、自社で短尺の動画作成もしたりしながらスタートしました。

その後どんどん成長して、2017年12月にLINEの傘下に入りまして、完全子会社化しました。しばらくの間は別のビルでやっていたのですが、2019年6月に新宿のミライナに移転しまして、1つのチームでやっていくことになりました。この写真がちょうど移転時の写真ですね。僕のiPhoneからもってきました。このFIVE Ad Networkが、今はLINE広告ネットワークというかたちで動いています。

このLINE広告ネットワークですが、LINE広告という大きなプラットフォームの下に位置するものです。みなさん、LINEはインストールしていると思うので、おそらくLINEで広告を見たことはあるかと思います。当然LINEにも、LINE広告という広告プラットフォームがあります。

LINEに広告を流したい、出稿したい広告主は、LINE広告に対して広告を入れるわけですが、LINEは非常に大きいアプリで、国内のリーチ数は非常に大きい。でも、スマートフォンって使っている時間をすべてLINEに使うわけではないと思うので、やはり広告主さんとしては、LINE以外にも広告を出稿したいと考えるわけです。

ただそうなってくると、また別の広告プラットフォームに広告を出稿する必要があって、管理も大変だし、レポートも別々に上がってくるし、すごく大変ですよね。

こういうこともあって、我々のLINE広告ネットワークが増えたことで、実はLINE広告に広告を流して、あとはちょっとチェックボックスをオンにするだけで、LINE以外のアプリにも広告を流せるものが揃っているのです。

現在LINEの国内月間アクティブユーザーは8400万人程度（2020年6月時点）。それに加えてLINE広告ネットワークでの配信先アプリの月間アクティブユーザーが5400万人（2019年9月時点、LINE広告ネットワーク内の重複を除く）。そこそこの規模ですね。

広告主さんは少ない手間でいろいろなアプリに広告を流せてハッピーですし、ほかのアプリ側についても、LINEに流れるような……審査を経た質のいい広告と言えばいいのかな、が流れてくるので、お互いハッピーになる関係になっています。

こんな感じで、LINE広告ネットワークに流した場合は、LINE以外のアプリ、例えばコミック系アプリやレシピサイトなどに広告が流れます。最近だと自粛期間中なので、けっこうみなさんコミック媒体を見てたり、自炊のためにレシピサイトを見たりしているので、おそらく我々の広告に当たっているのかなと思っています。

この図は媒体資料からもってきたので、もし興味のある方は、媒体資料を見るのもいいのかもしれません。

LINE広告ネットワークの中身

今まで駆け足でLINE広告ネットワークの概要を説明しましたが、中身について簡単に紹介します。やっていることは図にするとシンプルで、LINEもやはり広告プラットフォームをもっていると。

だいたいの広告プラットフォームは、広告枠を提供する側のSupply Side Platformと、広告を出したい側のDemand Side Platformに分かれていて、LINEもその例に漏れず、LINE SSPと、LINE DSPに分かれています。

なので、LINEで広告枠が出たときに、リアルタイムでLINE SSPに取得しにいって、LINE SSPはDSPにリクエストを投げて、DSP上で管理画面から入ってきたデータをもとにランキングして、いいものから返ってきます。

同様に、LINE広告ネットワーク側も、LINE広告ネットワークのSDKを各メディア、アプリのところに導入してもらって、そのSDKを呼ぶだけでLINE広告ネットワークにリクエストがいき、LINE DSPにリクエストを飛ばして、広告を取ってくるようになっています。ここのLINE DSPが共通なので、基本的にレポーティングや広告素材の管理も全部同じところでできます。

また、LINE広告ネットワークはLINE DSPだけではなくLINE以外のDSPとも接続していまして、お互いにOpenRTBでつながっており、そこでいいものをオークションして返すようになっています。お互いのいいとこ取りをする感じですね。

さっきの簡略化した図からもうちょっとだけブレイクダウンすると、このようになります。もともとLINE広告ネットワークも独立した広告ネットワークだったので、なんだかんだいって、SSPとDSPはやっぱりやっています。当然、管理者用のコンソールや、メディアパートナー広告主が見るような管理画面があって、もろもろJobWorkerがある構成ですね。

広告のスコア付けをするAdServerがあり、それの表示やクリックの情報を受けるBeaconServerが別途立っています。このあたりはやはりリクエストも多いし、このAdランカーとBeaconとでは、処理に要求されるレイテンシーが違うので、別のサーバーに分かれています。よくある構成ですね。

画像や動画の配信は、CDNを経由して行っています。あとこのBeaconに届いたデータは、もともとLINEとは別だったので、我々はGoogleのBigQueryを使っていまして、そこにfluentdでAdServerやBeaconServerからのログをBigQueryにもっていって、ここで集計やレポーティングをしています。

この色が付いている部分が、我々の管理しているところですね。オレンジ色になっているところが面倒を見ている部分です。ほぼ広告システムが全部という感じです。

技術スタックはScalaがメイン

我々の採用している技術スタックについて簡単に紹介します。サーバーサイドで、LINEの国内側ではわりかしJavaで書かれていることが多いのですが、我々はScalaを使っています。

フレームワークとしてはfinagleを使っていまして、これはTwitterが開発しているマイクロフレームワークで、Futureによる非同期処理が非常に簡単にできるフレームワークです。トラフィックが非常に多い場所で使いやすいフレームワークなので採用しています。

Scalaはfinagleが、Scalaで書かれているから採用しました。基本的にはBetter Javaとして使っているので、わりかしJavaしかわからない人でも、ちゃんと読めるようなコードの書き方にしようということになっています。

サーバー間の通信は、基本的にThrift RPCを使っていまして、こちらはgRPCなど、みなさんご存知だとは思いますが、gRPCでのProtocol Buffersにあたる部分がThriftになったものです。これも、finagleが使っているのでそれを使っています。

データストアはRedis / MySQLを使っています。広告配信のためのデータはRedisに入っています。

あとは先ほどお話したとおりですが、集計は全部BigQueryでやってます。このBigQueryのLog importスキーマも全部Thriftから自動生成して取り込まれるようになっているので、ちゃんと安定して使えるようになっています。

あと、LINEのHadoopクラスタにもデータが入っていて、そこでLINEのデータと合わせて分析してます。なので、SparkもHiveも、いろいろなんでも使います。

ログはfluentdで全部収集していて、モニタリング・監視系はPrometheusとGrafanaを使っています。あとNagiosも使っていますね。あとは、エラービーコンみたいなものは、SDKから飛んできたものについてはElasticsearchに入れて、Kibanaなどでモニタリングしています。

デプロイもJavaなので、基本的にFat JARに固めてもっていくようになっていて、CIは全部Jenkinsで。まあよくある構成ですね。

サーバーサイドはこんな感じなのですが。本日はサーバーサイドエンジニア説明会ではありますが、ちょっと我々はSDKも開発しているので、そこについても簡単に触れると、基本的にAndroidもiOSも、JavaとObjective-Cでそれぞれ作られています。

あとKotlinとSwift、これはテストコードのためだけに使っています。とくにKotlinは、バージョンとかの問題でお客さんのアプリに組み込むには問題があるので、Javaを使っています。

フロントはTypeScriptとReact、Reduxという構成です。

ほぼ毎日がデプロイ

最後に開発体制やチーム構成について簡単にお話しします。エンジニア、この室長の小西さんを含めて10名です。うち5名くらいがHaskellが書けるHaskellerだったりするので、ちょっと偏ったチームなんですが（笑）。和気あいあいとやっています。

基本的にはGitHub Enterpriseで、Git-flowを使ってPeer-Reviewして、デプロイしてます。ほぼ毎日、なにかしらのデプロイが走っています。

エンジニアの役割ですが、企画から要件定義、設計、開発をして、テストして、リリースして、ABテストなどをして分析して、という感じになっています。なので、本当に毎日デプロイしているので、フィードバックが非常に早いです。

あとSDKからサーバーサイドまで、広告システムに必要なものすべてに触れる状況になっていますので、広告をやったことがないという方でもやったことがあるという方でも、もちろん1から100まですべて担当できて、おもしろいかなと思います。

ということで、私からはAd Network & Performance開発室について簡単に紹介しました。絶賛採用中なので、ぜひよろしくお願いします。