Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

5,044 views

Published on

SPRING FEST 2018 での登壇資料です

Published in: Technology
  • Be the first to comment

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/

×