Ad Network ＆ Performance室
樋村隆弘氏：「LINE広告ネットワークのSRE」と題して、私たちのチームで開発しているLINE広告ネットワークの簡単な紹介と、そこでSREが果たす役割についてお話いたします。
最初に自己紹介をしておくと、私は樋村隆弘と申しまして、開発4センター Ad Network ＆ Performance室の下のAd Network Devチームのマネージャーをしています。もともと大学では物理学を専攻していまして、2012年に新卒でインターネットイニシアティブに入社しまして、クラウド基盤の開発や運用に従事していました。
その後2017年に、FIVE株式会社というベンチャーに入社したのですが、こちらはモバイル動画広告ネットワークの開発をしていたベンチャーで、同年の12月にLINEに買収されてLINEの傘下に入りまして、引き続き広告ネットワークの開発・運用に従事しています。
趣味は音ゲーで、最近はちょっとあまり外に出れないこともあって、自宅に筐体を買ってしまい、ちょっと寝る場所がなくなってしまっています。よろしくお願いします。
本日のアジェンダですが、最初に、私たちのAd Network & Performance室について簡単に紹介した後に、LINE広告ネットワークとその中身について簡単に紹介します。その後は技術スタック、働くおもしろさ・求めるマインドについて簡単に紹介したいと思います。よろしくお願いします。
LINE広告ネットワーク
それでは、まず私たちの部署について簡単に紹介します。私たちは、開発4センターの下に所属するAd Network ＆ Performance室に所属しています。私は、Ad Network & Performance 室配下の Ad Network Dev チームのマネージャーをしています。こちらのチームは、私を含めて8名のチームです。
このAd Network ＆ Performance室ですが、こちらはLINE広告ネットワークの開発と運用を担当する部署となっています。
次に、私たちが担当しているLINE広告ネットワークの紹介したいのですが、その前にLINE広告について簡単にご紹介します。LINE広告は、LINEに広告を配信するためのプラットフォームでして、こちらは今日の説明会に来ているみなさんは、おそらくLINEを使っていると思いますので、LINEに配信されている広告については、見たことがあるかと思います。
簡単に紹介しておくと、LINEのトークリスト最上部に掲載するTalk Head Viewをはじめ、LINE NEWS面やタイムラインなど、さまざまなLINEの面に流れています。こちらのLINE広告の規模ですが、LINE自体が現在、国内の月間アクティブユーザーが8,900万人（2021年6月時点）を突破していまして、そのため、やはりLINE広告自体についても、国内最大級の運用型広告プラットフォームと言えるかなと思っています。
以前はLINEに広告を配信するためだけのプラットフォームでしたが、現在は、これから紹介するLINE広告ネットワークを通じて、LINEの外のアプリに対しても広告配信が可能となっています。LINE広告ネットワークですが、こちらは先ほど申し上げたとおり、こちらはLINE広告のプラットフォームを用いて、LINE以外のアプリについても広告配信するためのネットワークとなっています。
LINEマンガやLINE BLOGといったLINEファミリーのアプリを始めとして、ニュースサイトやレシピサイト、漫画系アプリ、ライフスタイル系など、国内のさまざまな幅広いジャンルのアプリに対して、広告の配信が可能となっています。LINE広告ネットワークの配信先アプリの総MAU（Monthly Active Users）は、2020年の9月の時点で1.1億ユーザーを突破しています。（LINE広告ネットワーク内の重複を除く） LINE広告ネットワークは広範なアプリ広告枠に対して、LINE広告のターゲティング機能を活用して配信可能となっています。
こちらのLINE広告ネットワークですが、もともとはモバイル動画広告配信プラットフォームであるFIVE Ad Networkが前身となったサービスです。FIVE Ad Networkは、2014年に創立されたファイブ株式会社というベンチャーが開発・運用していたサービスでして、こちらの社名のファイブは「5秒動画」が由来となっています。
こちらはスマートフォン時代に合わせて、CMなどと比べて、より短い秒数でもユーザーに興味・関心を持ってもらえるような動画の作成、コンサルティングまで含めてやるといったところで、創業したベンチャーです。このファイブが順調に成長しまして、2017年にLINEに買収され、LINEの傘下となりました。
LINE広告のシステムと連携したことによって、LINE Ads Platform for Publishersとして2019年にリリースされています。こちらが名前を変えて、今はLINE広告ネットワークと呼ばれています。こちらのファイブ株式会社自体も2020年の5月末にLINEに吸収合併されて、現在は私たちもLINEの1チームとして、開発4センターのもと、LINE広告ネットワークの開発・運用に引き続き携わっています。
LINE広告のSRE
事業の紹介はこれぐらいにして、LINE広告ネットワークの中身を紹介しながら、本日の主題であるLINE広告のSREは実際に何をしているかについて触れたいと思います。だいたいの広告プラットフォームは、ご存知の方もいると思いますが、広告枠を提供する側のSupply Side Platform(SSP) と、広告を出したい側のDemand Side Platform（DSP）に分かれています。
LINE広告もLINE SSPとLINE DSPに分かれています。広告配信においては、広告枠が表示されたタイミングにおいて、リアルタイムに問い合わせをして配信する「Real-Time Bidding」が主流になっていますが、LINEも同様に、LINEで広告枠が表示されるとSSPに問い合わせが行って、DSPに問い合わせが行って、広告が返ってくるというようなフローになっています。
LINE広告ネットワークは、LINEの外部のアプリに広告を配信する広告ネットワークについても同様に、アプリに組み込まれたSDKに広告表示の命令が来ると、LINE広告ネットワークのサーバーにリアルタイムでアクセスして、LINEのDSPとOpenRTBで接続して広告を取ってくるような仕組みになっています。
DSPによって得意分野が違ったりするので、LINE広告ネットワークはLINEのDSPだけではなく、LINE以外の他社のDSPともOpenRTBで接続していまして、いろいろなDSPからの入札をもとに、オークションして広告を配信する仕組みになっています。
先ほどの簡略化した図からちょっとブレイクダウンしますと、このようになります。赤色が付いている部分ですが、こちらが私どものチームが管理しているところです。ほぼ広告配信に必要なものすべてが揃っているかなという感じです。もともとLINE広告ネットワークも独立したものでしたので、広告配信に必要なものが一通り揃っています。
広告を表示するためにアプリに組み込むSDKについても、私たちのチームで開発をしています。また、そちらの広告を配信するAdサーバーについても私たちで管理していて、こちらについても、やはりSSPとDSPという感じで分かれています。
また、広告の表示やクリックといったビーコンを受信するビーコンサーバーもありまして、こちらもAdサーバーと比べるると、より、レイテンシーに厳しい制約があるので、別のサーバー群として管理されています。この辺りは、広告配信プラットフォームではよくある構成かなと思います。そして、このビーコンサーバーに届いたデータですが、Fluentdを利用してBigQueryにアップロードされています。
配信のレポートなど、各種ETLジョブについてはBigQueryを活用して作られています。LINEではBigQueryではなく自社で運用しているHadoopクラスタを利用して分析や集計を行っているケースがほとんどなのですが、私たちはもともと別の会社だったということもありまして、従来から引き続きBigQueryを使い続けている感じになっています。
あとは、画像や動画の配信については、CDNを経由して行っています。LINEの他のチームだと、この四角で書いたコンポーネントごとにチームが分かれているケースも珍しくないのですが、私どものチームではこのあたりを全部面倒見る感じになりますので、けっこうやることが多いかなと思います。
配信サーバーですが、買収以前はGCP、さらにそれ以前はAWSで動いていました。しかし買収を機に、LINEが管理する Verda というプライベートクラウドに引っ越しています。
今まで見てきたように、私たちのチームではアプリ広告に必要なSDKから配信サーバー、集計パイプラインや管理画面といった、（広告配信に）必要なものすべてが担当範囲となります。
LINE広告SREの技術スタック
次に、技術スタックについて紹介します。LINE のサーバーサイドではJavaやKotlinの利用が中心ですが、私たちのチームではScalaという言語を使っています。
フレームワークとしては、Twitterが開発しているfinagleを利用しています。こちらはマイクロサービス用のフレームワークで、Futureによる非同期処理が非常に簡単にできるということと、Twitterが開発しているというところからもわかるとおり、トラフィックが非常に多い場所で使いやすいフレームワークであるということで採用をしています。
Scalaも、finagleがScalaで書かれていたというところから採用しています。基本的にScalaはBetter Javaとして使い、Java経験しかない方でもちゃんと読めるようなコードの書き方をしようということで開発をしています。
サーバー間のRPCはThrift RPCを使っていて、こちらもfinagleに組み込まれているので利用しています。
データストアについてはだいたい他のチームと一緒で、Redis、MySQLを使っています。広告配信などに必要なデータはRedisに入っています。このRedisやMySQL自体の運用についてはDBAのチームに依頼しているので、こちらの構築については、特に私たちのチームでやる必要はありません。
とはいえ、モニタリングなどについてはちゃんと私たちのチームでやる必要があります。よりアプリケーションレイヤーに近いところの部分のモニタリングについては、やはりソフトウェア側で対応する必要がありますので、そういった部分については運用のカンや経験が必要になり、力の見せどころかなと思います。
あとは先ほど触れたとおりですが、集計は全部BigQueryの上でやっています。最近では BigQuery に加えて LINEのHadoopクラスタにもデータを入れていまして、LINEのデータとも合わせて分析可能になっています。なのでBigQuery、Spark、Hiveといった、けっこういろいろな方面を触る機会があるかなという感じです。BigQuery や Hadoop に取り込むログは Fluentdを利用して収集しています。
あとは、モニタリングとかの監視系についてはPrometheus、Grafanaが利用されています。finagleにもStatsReceiverというメトリクスを出す仕組みがあるので、こちらをPrometheusのメトリクスに翻訳して利用しています。
finagle自体もデフォルトで豊富なメトリクスを出してはくれますが、よりサービス寄りのメトリクスについては自分たちで計測する必要があり、どこでメトリクスを取るかという部分は開発者の力量やセンスに寄るところがあります。やはり、作る人によってまちまちなメトリクスになってしまっている部分がありますので、そういったところの整理はやはり課題の1つかなと思っています。
あとはNagiosも使っています。こちらはファイブができた頃から使っているもので、さすがにちょっと最近規模が大きくなってきて運用が難しくなってきたところもあり、このあたりも見直ししていきたいなと思っています。あとはElasticsearch、Kibanaといったものについては、SDKから起きたような表示系のエラーについては、Elasticsearchに入れてKibanaでもモニタリングできるようになっています。
デプロイ関連は他のチームと同様、Jenkinsを使ってCIを回してデプロイまでしています。あとはDroneCIについても、一部のコンポーネントで使っているという感じです。サーバー自体のプロビジョニングはAnsible、AWXを使っていますが、ちょっと古いコンポーネントについてはfabricを使っています。このあたりもAnsibleに移行している段階で、まだまだやることがあるかなという感じです。
あと画面系はTypeScript、React＋Reduxという感じです。本日はSREの説明会ですが、我々のチームで SDKも開発しているのでそちらにも触れておきますと、SDKは基本的にAndroidはJava、iOSはObjective-Cで作っています。KotlinとかSwiftについては、テストコードのみでの利用となっています。
SREだからといってSDK開発と完全に無縁というわけではなく、例えば、使われ方によってはトラフィックスパイクを起こしそうなものについて、クライアントサイドエンジニアからすると、そのあたりのインフラ寄りの勘所や知識については明るくない、知識が豊富でないというところがあります。
なので、SDK の設計段階からスパイク的なトラフィックが来てもちゃんと逃がせるよう、ちゃんと設計をする必要があります。そういったところでもやはりリードしてもらえると非常に助かるかなと思っています。
現状と今後の課題
現状と今後の課題ですね。やはり私たちもモニタリング、ログの強化や整備といったところについては、重要視しています。また私たちのチームは別の会社だった時代も長かったので、インフラについては集計パイプラインをBigQueryからIU、LINEのHadoopクラスタに移していくといったところで、運用コストを下げていく部分についても必要かなと思っています。
あとバッチについても、可用性向上のためにVMからKubernetesなどに移行する試みもしようと考えています。
最後に、おもしろさとかについてですが、やはり1.1億のMAUだから生み出せる膨大なトラフィックがありますので、こちらのトラフィックを高速に処理するのは大変ですが、半分やりがいもあるかなと思っています。また開発したものは、ダイレクトに売上に影響しますが、その一方でやはりサービス障害を起こすと大きな金額の損失にもつながりますので、やはり信頼性の高いシステムが求められるかなと思っています。
みなさんと一緒に働くことを楽しみにしています。ご清聴ありがとうございました。
