SPRING FEST 2018 での登壇資料です

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

2. About me
@hackmylife
● 通称「白米」
● 開発３センター
● 開発Aチーム
● Senior server side engineer
● Livedoor news, LINEギフト, LINE Blog
● 2017年よりLINE Ads Platformの開発
● Java, Perl, Python, Ruby

3. • About LINE Ads Platform
• Spring in LAP
• Technical topic
Agenda

4. Timeline LINE NEWS LINEマンガ LINE BLOG
LINE Ads Platform

5. LINEに広告配信できる唯一のPlatform
MAU 7800万
国内最大規模の運用型広告プラットフォーム
LINE Ads Platform

6. ● リアルタイムに広告主が予算や配信ターゲットを変更できる
● Pay per click
● 表示する広告をオークションで選ぶ
運用型広告

7. SSP DSP
Auction process
リクエスト来てるけど
広告ある？
¥25で買うわ
¥5¥25¥10
Supply Side Platform Demand Side Platform

8. Only 50ms

9. Real Time Bidding

10. MediaAdvertiser Audience
三者三様のニーズ
利益ROI UX

11. 何らかの指標が必要

12. CTR (Click Through Rate)
𝐶𝑇𝑅 𝑎𝑑 =
𝑐𝑙𝑖𝑐𝑘𝑠 𝑎𝑑
𝑖𝑚𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛𝑠 𝑎𝑑
𝑝𝐶𝑇𝑅 𝑎𝑑 = 𝑃(𝐶𝑙𝑖𝑐𝑘|𝐴𝐷, 𝑅𝑒𝑞𝑢𝑒𝑠𝑡)

13. ● 色々な特徴量から推定値を出す
● 難しい数式が沢山出てくる
● 話が長くなる
● この辺りの話はLINE DEVELOPER DAY 2018で話します
機械学習

14. やめておきましょう

15. 今日はSpring festだし

16. 広告をReal timeでオークションしてる
50msという強烈な制約
CTRを予測するのが大事でMLの活発な分野
覚えておいて欲しいこと

17. Spring in LAP

18. 50msを維持する工夫

19. Analytics ClusterDataPipeline
SDK
Architecture
SSP
EventReceiver
DMP BI
DSP

20. ● Real Time Bidding
● 複数のDSPにパラレルにrequest投げて結果をオークションする
● メディア側を管理するプラットフォーム
● Java + Spring boot2
● Tomcat
● Caffeine
● CMS側はKotlin + Nuxt.js
Supply Side Platform
SSP

21. ● Real Time Bidding
● 50msでresponseを返す必要がある
● 広告主のROIを最大化するように最適な広告を選択する
● Go
● Redis
● Online Machine Learning
● CMS側はjava + spring boot + React.js
Demand Side Platform
DSP

22. ● 50msでresponse返す必要がある
● G1GCでも数十ms使う時がある
● GoのGCは高速 -> GO採用
Why not use Java?
https://engineering.linecorp.com/ja/blog/detail/342

23. 広告データの持ち方
DSP
広告を登録
MySQL
ファイル配信

24. ● メモリに乗る量なら全部メモリにのせる
● 乗らないものはredisに
様々データの持ち方

25. Analytics ClusterDataPipeline
AppSDK
Architecture
SSP
EventReceiver
DMP BI
DSP

26. ● 推定オーディエンス情報(性別、年齢、興味)
● LINE Tag
● Look-a-like
● 広告配信を最適化するために特徴となるデータを提供する
● Java + Spring boot 1.5 -> 2.0
● Kafka
● HBase
● Redis
Data Management Platform
DMP

27. ● Armeria(非同期RPC/API)
● 50msでresponse返す必要がる
● G1GCでも数十ms使う時がある
● 99.9%tileでは問題ない
推定オーディエンス情報配信
https://engineering.linecorp.com/ja/blog/detail/70

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. 良さそう！

30. Result
maxGCPauseMillis = 20

31. 悪化してる！

32. Why?
一時停止時間目標: ガベージ・コレクションの評価やチュー
ニングを行うときは、遅延時間とスループットのトレードオ
フが常に生じます。(中略)
あまり積極的な目標を設定すると、ガベージ・コレクション
のオーバーヘッドが増加しても構わないという意味に解釈さ
れ、 スループットに直接影響します。

33. ● Heapsize 4g -> 8g
● g1HeapRegionSize 2M -> 4M
● maxGCPauseMillis 30 -> 50
結局どうしたか？

34. Heapを増やそう

35. Java 11にはZGCが！

36. DMPの話に戻ります

37. LINE Tag Event
Nginx Kafka
fluent-plugin-kafka
https://github.com/fluent/fluent-plugin-kafka
Kafka Streams
Redis
HBase

38. Analytics ClusterDataPipeline
AppSDK
Architecture
SSP
EventReceiver
DMP BI
DSP

39. ● 数万rpsなど
● Logは全て保存される
● 広告のimpやclickなどのイベントを集計する
● Java + Spring boot 1.5
● Kafka
Event Receiver

40. Analytics ClusterDataPipeline
AppSDK
Architecture
SSP
EventReceiver
DMP BI
DSP

41. ● 各サービスのrequest/response logなど
● データ分析基盤
● 広告配信に関わるあらゆるデータを収集し格納するプラットフォーム
● Hadoop, Hive, Presto
● Kafka, Spark
● ES, Druid
● Airflow, Mesos, Aurora
● Filebeat, Logstash
Data Pipeline/Analytics Cluster

42. ● それそれのArchitectureはDevelopment Leadが決定する
● 揃えられるとことは揃える
● トラフィックが膨大なので、高速であることが必須
● 突拍子もないものはダメ
各プロジェクトでバラバラ

43. Technical topic

44. ● 高速で安定したStreaming Platform
● 各サービス間でのデータの受け渡し
● QueueやJob schedulerとしても利用
● Write at once, consume anywhere
Kafka

45. ● Spring Bootと相性良い
● コードあまり書かなくても良い
● spring-kafkaもあるけど、公式のkafka_clientがおすすめ
● Kafka streamsはシンプルに使える
Kafka難しくない？
https://kafka.apache.org/documentation/streams/

46. We Love Kafka

47. ● Spring boot 2
● Reactor
● Kafka
● actuator + micrometer
最近の開発について

48. ● Reactive streams
● Non-blocking + Back pressure
● WebFlux, Lettuce5
● Flux, Mono
Reactor

49. ● Reactive API
● RedisAdvancedClusterReactiveCommands
● 戻り値が Mono / Flux
● 個人的にはすごくスッキリする
Lettuce5

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. ● あまり使ってない
● なぜならkafkaがあるから
● 個人的には使いたくて予定はあるんだけどまだ使えてない
Back pressure?

52. ● まだ使ってない
● 今やっているプロジェクトで使う予定だったか、もともと処理
が高速で使い所がなかった
● 使いたいところあるんだけど別プロジェクト
● PR送るは簡単だけどパフォーマンステストもしたい
How about WebFlux?

53. Development Team

54. 開発体制
2 60 100

55. ● MTGは通訳を挟んでTV会議
● 普段は翻訳botを入れたLINEで
● Face to Faceも大事なので気軽に出張行きます
コミュニケーション

56. ● まだまだ開発することはたくさんある
● 機械学習とかARとか新しいことも頑張りたい
● エンジニアも企画もまだまだ足りません
これから

57. We Are Hiring!

58. https://linedevday.linecorp.com/jp/2018/