Successfully reported this slideshow.
Your SlideShare is downloading. ×

500+のサーバーで動く LINE Ads PlatformをささえるSpring

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
The new LINE Ads Platform
The new LINE Ads Platform
Loading in …3
×

Check these out next

1 of 58 Ad
Advertisement

More Related Content

Slideshows for you (19)

Similar to 500+のサーバーで動く LINE Ads PlatformをささえるSpring (20)

Advertisement

More from LINE Corporation (20)

Recently uploaded (20)

Advertisement

500+のサーバーで動く LINE Ads PlatformをささえるSpring

  1. 1. 500+のサーバーで動く LINE Ads PlatformをささえるSpring Naoki Watanabe
  2. 2. About me @hackmylife ● 通称「白米」 ● 開発3センター ● 開発Aチーム ● Senior server side engineer ● Livedoor news, LINEギフト, LINE Blog ● 2017年よりLINE Ads Platformの開発 ● Java, Perl, Python, Ruby
  3. 3. • About LINE Ads Platform • Spring in LAP • Technical topic Agenda
  4. 4. Timeline LINE NEWS LINEマンガ LINE BLOG LINE Ads Platform
  5. 5. LINEに広告配信できる唯一のPlatform MAU 7800万 国内最大規模の運用型広告プラットフォーム LINE Ads Platform
  6. 6. ● リアルタイムに広告主が予算や配信ターゲットを変更できる ● Pay per click ● 表示する広告をオークションで選ぶ 運用型広告
  7. 7. SSP DSP Auction process リクエスト来てるけど 広告ある? ¥25で買うわ ¥5¥25¥10 Supply Side Platform Demand Side Platform
  8. 8. Only 50ms
  9. 9. Real Time Bidding
  10. 10. MediaAdvertiser Audience 三者三様のニーズ 利益ROI UX
  11. 11. 何らかの指標が必要
  12. 12. CTR (Click Through Rate) 𝐶𝑇𝑅 𝑎𝑑 = 𝑐𝑙𝑖𝑐𝑘𝑠 𝑎𝑑 𝑖𝑚𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛𝑠 𝑎𝑑 𝑝𝐶𝑇𝑅 𝑎𝑑 = 𝑃(𝐶𝑙𝑖𝑐𝑘|𝐴𝐷, 𝑅𝑒𝑞𝑢𝑒𝑠𝑡)
  13. 13. ● 色々な特徴量から推定値を出す ● 難しい数式が沢山出てくる ● 話が長くなる ● この辺りの話はLINE DEVELOPER DAY 2018で話します 機械学習
  14. 14. やめておきましょう
  15. 15. 今日はSpring festだし
  16. 16. 広告をReal timeでオークションしてる 50msという強烈な制約 CTRを予測するのが大事でMLの活発な分野 覚えておいて欲しいこと
  17. 17. Spring in LAP
  18. 18. 50msを維持する工夫
  19. 19. Analytics ClusterDataPipeline SDK Architecture SSP EventReceiver DMP BI DSP
  20. 20. ● Real Time Bidding ● 複数のDSPにパラレルにrequest投げて結果をオークションする ● メディア側を管理するプラットフォーム ● Java + Spring boot2 ● Tomcat ● Caffeine ● CMS側はKotlin + Nuxt.js Supply Side Platform SSP
  21. 21. ● Real Time Bidding ● 50msでresponseを返す必要がある ● 広告主のROIを最大化するように最適な広告を選択する ● Go ● Redis ● Online Machine Learning ● CMS側はjava + spring boot + React.js Demand Side Platform DSP
  22. 22. ● 50msでresponse返す必要がある ● G1GCでも数十ms使う時がある ● GoのGCは高速 -> GO採用 Why not use Java? https://engineering.linecorp.com/ja/blog/detail/342
  23. 23. 広告データの持ち方 DSP 広告を登録 MySQL ファイル配信
  24. 24. ● メモリに乗る量なら全部メモリにのせる ● 乗らないものはredisに 様々データの持ち方
  25. 25. Analytics ClusterDataPipeline AppSDK Architecture SSP EventReceiver DMP BI DSP
  26. 26. ● 推定オーディエンス情報(性別、年齢、興味) ● LINE Tag ● Look-a-like ● 広告配信を最適化するために特徴となるデータを提供する ● Java + Spring boot 1.5 -> 2.0 ● Kafka ● HBase ● Redis Data Management Platform DMP
  27. 27. ● Armeria(非同期RPC/API) ● 50msでresponse返す必要がる ● G1GCでも数十ms使う時がある ● 99.9%tileでは問題ない 推定オーディエンス情報配信 https://engineering.linecorp.com/ja/blog/detail/70
  28. 28. 一時停止時間目標: ガベージ・コレクションの評価やチューニングを行うときは、遅延時間とスループッ トのトレードオフが常に生じます。 G1 GCは、均一な一時停止を伴うインクリメンタル・ガベージ・コ レクタですが、アプリケーション・スレッドのオーバーヘッドも大きくなります。 G1 GCのスループッ ト目標は、アプリケーション時間が90%、ガベージ・コレクション時間が10%です。これをJava HotSpot VMのパラレル・コレクタと比較してみましょう。 パラレル・コレクタのスループット目標は、 アプリケーション時間が99%、ガベージ・コレクション時間が1%です。 したがって、G1 GCのスルー プットを評価するときは、一時停止時間目標を緩くしてください。あまり積極的な目標を設定すると、 ガベージ・コレクションのオーバーヘッドが増加しても構わないという意味に解釈され、 スループット に直接影響します。G1 GCの遅延時間を評価するときは、望ましい(ソフト)リアルタイム目標を設定す ると、G1 GCはその目標を満たそうと努力します。 その影響として、スループットが犠牲になります。 詳細は、「ガベージファースト・ガベージ・コレクタ」の「一時停止時間目標」を参照してください。 maxGCPauseMillis https://docs.oracle.com/javase/jp/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html
  29. 29. 良さそう!
  30. 30. Result maxGCPauseMillis = 20
  31. 31. 悪化してる!
  32. 32. Why? 一時停止時間目標: ガベージ・コレクションの評価やチュー ニングを行うときは、遅延時間とスループットのトレードオ フが常に生じます。(中略) あまり積極的な目標を設定すると、ガベージ・コレクション のオーバーヘッドが増加しても構わないという意味に解釈さ れ、 スループットに直接影響します。
  33. 33. ● Heapsize 4g -> 8g ● g1HeapRegionSize 2M -> 4M ● maxGCPauseMillis 30 -> 50 結局どうしたか?
  34. 34. Heapを増やそう
  35. 35. Java 11にはZGCが!
  36. 36. DMPの話に戻ります
  37. 37. LINE Tag Event Nginx Kafka fluent-plugin-kafka https://github.com/fluent/fluent-plugin-kafka Kafka Streams Redis HBase
  38. 38. Analytics ClusterDataPipeline AppSDK Architecture SSP EventReceiver DMP BI DSP
  39. 39. ● 数万rpsなど ● Logは全て保存される ● 広告のimpやclickなどのイベントを集計する ● Java + Spring boot 1.5 ● Kafka Event Receiver
  40. 40. Analytics ClusterDataPipeline AppSDK Architecture SSP EventReceiver DMP BI DSP
  41. 41. ● 各サービスのrequest/response logなど ● データ分析基盤 ● 広告配信に関わるあらゆるデータを収集し格納するプラットフォーム ● Hadoop, Hive, Presto ● Kafka, Spark ● ES, Druid ● Airflow, Mesos, Aurora ● Filebeat, Logstash Data Pipeline/Analytics Cluster
  42. 42. ● それそれのArchitectureはDevelopment Leadが決定する ● 揃えられるとことは揃える ● トラフィックが膨大なので、高速であることが必須 ● 突拍子もないものはダメ 各プロジェクトでバラバラ
  43. 43. Technical topic
  44. 44. ● 高速で安定したStreaming Platform ● 各サービス間でのデータの受け渡し ● QueueやJob schedulerとしても利用 ● Write at once, consume anywhere Kafka
  45. 45. ● Spring Bootと相性良い ● コードあまり書かなくても良い ● spring-kafkaもあるけど、公式のkafka_clientがおすすめ ● Kafka streamsはシンプルに使える Kafka難しくない? https://kafka.apache.org/documentation/streams/
  46. 46. We Love Kafka
  47. 47. ● Spring boot 2 ● Reactor ● Kafka ● actuator + micrometer 最近の開発について
  48. 48. ● Reactive streams ● Non-blocking + Back pressure ● WebFlux, Lettuce5 ● Flux, Mono Reactor
  49. 49. ● Reactive API ● RedisAdvancedClusterReactiveCommands ● 戻り値が Mono / Flux ● 個人的にはすごくスッキリする Lettuce5
  50. 50. Mono / Flux // before public CompletableFuture<String> getItem(String key){} public CompletableFuture<List<String>> getItemList(String[] keys){} // after public Mono<String> getItem(String key){} public Flux<String> getItemList(String[] keys){}
  51. 51. ● あまり使ってない ● なぜならkafkaがあるから ● 個人的には使いたくて予定はあるんだけどまだ使えてない Back pressure?
  52. 52. ● まだ使ってない ● 今やっているプロジェクトで使う予定だったか、もともと処理 が高速で使い所がなかった ● 使いたいところあるんだけど別プロジェクト ● PR送るは簡単だけどパフォーマンステストもしたい How about WebFlux?
  53. 53. Development Team
  54. 54. 開発体制 2 60 100
  55. 55. ● MTGは通訳を挟んでTV会議 ● 普段は翻訳botを入れたLINEで ● Face to Faceも大事なので気軽に出張行きます コミュニケーション
  56. 56. ● まだまだ開発することはたくさんある ● 機械学習とかARとか新しいことも頑張りたい ● エンジニアも企画もまだまだ足りません これから
  57. 57. We Are Hiring!
  58. 58. https://linedevday.linecorp.com/jp/2018/

Editor's Notes

  • LINEの渡邉直樹が「500+のサーバーで動くLINE Ads PlatformをささえるSpring」というタイトルでお話させていただきます。よろしくお願いします。
  • twtterは hackmylife というIDで活動していますが、社内の人はめんどくさがって省略して白米と読んでます。
    割と気に入っています。

    Linvedoorni入社したら、会社のほうがコロコロ変わって気がついたらLINEいました。
    ずっと広告やっていたわけではなくて、B2Cの開発を主にやっていたんですが、2017年からLINE Ads Platformの開発をしています。
  • まずは広告プラットフォームとはなんぞや?という話を軽くして、
    LAP、あ、これLINE Ads Platformの略です。弊社サービス名を三文字に略すのがとても好きです。
    社内でも賛否両論あるんですが・・・。 LINE Ads Platfromの中でspringどう使われているか解説して、
    最後にLINE全般的な技術的な話題を少しする予定です。
  • LINE Ads Platformではこのような形で広告を表示しています。
    LINEアプリのタイムライン、newsタブをはじめ、LINEマンガなどのファミリーアプリ、一番右側のLINE BlogはWeb pageなんですが、こういった場所に広告が表示されています。
  • LINE Ads Platformの特徴は、LINEに広告を出稿できる唯一のプラットフォームで、月間で7000万人もののオーディエンスにリーチできる、国内最大規模のプラットフォームになっています。プラットフォームの特徴としてはProgrammatic Advertising をサポートしていることです。
  • というのは日本では運用型広告と言った言い方が主流だからです。
    この方式には、いくつか特徴があります。
    1つ目の特徴は、リアルタイムに広告主が予算や配信対象を変更することができることです。運用型という名前がしっくりきますね。
    2つ目の特徴は、成果型報酬です。つまりclickや動画の視聴など、成果が上がって初めて課金される形式です。
    3つ目が一番特徴的なところで、リクエストを受けるたびに、内部でオークションを開催し、広告を選ぶことです。

    まず、このオークションの部分を簡単にですが、ご説明したいと思います。
  • オークションプロセスには2つのプラットフォームが登場します。SSPとDSPです。
    SSPはsupply side platformの略で、広告が表示されるメディア側の管理をしています。みなさんが広告枠があるページにアクセスしたときに、一番初めにメディアから、SSPにリクエストが飛びます。SSPはリクエストを受けると、表示できる広告の形式の条件と一緒に、DSPに広告リクエストを送ります。

    DSPはdemand side platformの略で、広告を管理しています。
    SSPからリクエストを受けると、DSPは内部的にオークションを行い、オークションに勝った広告を返します。
    このオークションに勝利した広告、この場合25円の広告がみなさんに表示されるわけです。
  • 広告プラットフォームでは3タイプのプレイヤーが存在して、それぞれ違ったニーズを持っています。
    1つ目は広告主です。広告主は費用に対する効果を最大化したいと考えいます。
    2つ目はメディア。メディアは表示した広告の売り上げを最大化したいと考えています。ちなみにここに書いてあるeCPMというのは、広告を1000回表示した時に利益を表します。
    最後にオーディエンスつまり、ユーザーです。オーディエンスはサイトの使い勝手を損なわないことや、広告が出るならば、自分にとって興味があるような広告が出たほうが良いと考えるのではないでしょうか?

    このようなニーズを最大限に満たす必要があります。
  • こう言った三者三様のニーズを満たしているか判断するための、なんらかの指標が必要です。
  • そこで指標の一つとして使うのがCTRです。CTRはとある広告がクリックされた回数を、表示した回数で割ったものです。
    広告主にとっては、目的を達成を図る数値してコンバージョン率(CVR)がありますが、コンバージョンの為には、まずは広告をクリックしてもらうことが目標となります。
    メディアにとっては、先ほど申し上げたように、最近はクリックなどの成果報酬型が主流ですから、クリックが売り上げに繋がります。
    最後にオーディエンスにとっては、興味を持ったかどうかのバロメータとして使えます。

    他にも様々な指標を使っていいるのですが、一番横断的に使えるものとして今日はCTRが特に重要で、かつこれを事前に予測する必要があります



    10min
  • CTRを予測するには、色々な特徴量から推定値を出して行きます

    が、このあたりの話はしだすときりがないのと、11/21のdeveloper dayで話す予定なので、
  • 今日は別の話をします
  • せっかくのSpring festなのでSpringの話をしましょう
  • Real timeでオークションしてるってことと、それを50ms以内に行う必要があるということ、3つ目は今日はあまり関係ないのですが、広告プラットフォームとって大事なのはCTRを予測することで、MLがたくさん使われています
  • 12分
  • 50msを維持する工夫なんかも入れて話して行きましょう
  • 全体のざっくりしたarchitectureです。

    まずはさっき見ていたSSPとDSPのあたりから構成を見て行きましょう。
  • CMSで設定された情報は、数分おきにsync apiというのが実行されて、データをjsonでもらってcaffeineでメモリに持っている。


    Auction -> AsyncTaskExecutor -> 帰ってきたのを待ってまたオークション
    Waterfall -> 順次投げて帰ってきたところで終了

    15分
  • 広告主が登録した広告は一旦MySQLへ。これ読むと遅いので、ファイルとして配信して、全部メモリにロードしている。
  • 18分
  • 20min
  • LINEがOSSと試打しているArmeria。netty baseの非同期RPC/API。早い。
  • 他はデフォでも基本的にはいい感じに動く
    maxGCPauseMillisは200デフォルトだったと思うのでそこだけ調整
  • 10ms以内に治るって聞いた!
    24min
  • 24min
  • LINE tagはjsタグ。色々なサイトに貼れる。appのイベントは別の経路だけどくる。
    めっちゃくる。なので、Nginxで受けてログに落とし、Fluentdでkafkaへ。
    反対側ではkafka consumer(strems)が受け取って、即使えるようにredisに、永続化するのにHbaseに書いてる。

    26min
  • 27min
  • リクエストを受け取ったらkafkaに書く。大量のトラフィックあってもkafkaは高速で安定しているので心理的に安心。
  • 色々ありすぎて把握できないw 250台以上は実はここが持っている。
    Hadoopが実は100台ぐらいある prestoは最近使ってなさそう
    Sparkはよく使ってるっぽい。
    ES -> kibanaにアクセスログ流れるのがとても便利
    担当のdev leadと先日チャットで話たら、 MesosとAuroraで監視とauto-scalingしてる!って猛プッシュされたので一応書きました。
  • 30min
  • 35min
  • 38min
  • 40min

×