SpringFest2018の「500+のサーバーで動くLINE Ads PlatformをささえるSpring」聴講メモ

プレゼンター

渡邉 直樹 LINE株式会社 開発3センター 開発Aチーム

複数のLINEファミリーサービスの開発を経て、2017年から広告配信Platformの開発に携わっています。最近はBoot2の新しい機能を使ってみることにハマっています。

概略

LINEではSpringが多く使われています。最近ではSpring Boot 2への移行も進んできました。 本セッションでは、最近のLINEでのSpring活用事例として、500台以上のサーバーで運営される広告配信PlatformのLINE Ads Platformを例にあげて、多量のトラフィックを処理するためのArchitectureと、その中でSpringがどの様に使われているかをご紹介したいと思います。広告配信に特化した話はしない予定です。 #sf_a4 #アンケート

聴講メモ

LINEの広告プラットフォーム

  • SSPとDSPのやり取りと50ms以内に行う必要がある
  • RTB ( Real Time Bidding )
  • 三者三様のニーズ
    • 広告主はROIの最大化
    • メディアは利益を最大化したい
    • ユーザはUXが最高であることがが望ましい
  • CTR ( Click Through Rate ) は事後の数値
    • 事前の数値はpCTR ( 予測されたCTR )
      • 機械学習で様々な特徴量から推定値を出す
      • LINE DEVELOPER DAY 2018で話すので詳細は割愛

Spring in LINE Platform

  • 50msを維持する工夫
  • SSP
    • メディア側を管理するプラットフォーム
      • JavaとSprintBoot2
      • Tomcat
      • Caffeineでキャッシュ
      • CMS側はKotlinとNuxt.js
  • DSP
    • 広告を管理しているプラットフォーム
      • Javaを使わない理由はGCがきついから
      • GoのGCは高速なのでGoを採用
  • メモリに乗る量なら全てメモリに乗せる
    • 乗らないのもはRedisで扱う
  • DMP
    • 広告配信を最適化するために特徴となるデータを提供
    • 推定オーディエンス情報 ( 性別、年齢、興味 )
      • LINE Tag
      • Look-a-like
    • 実装
      • JavaとSpringBoot1.5->2 ( 今年から2 )
      • Kafka
      • HBase
      • Redis
  • 推定オーディエンス情報配信
    • Armeria ( 非同期PRC/API )
    • 50msでresponseを返す必要がある
    • G1GCでも数十ms使うときがある
    • 99.9%では問題ない
  • G1GCの時間を短縮しようとして、あまり積極的な目標を設定するとGCのオーバーヘッドが増加して逆効果
    • G1GCはもともと最適化されているっぽい？
    • 対策としてヒープのサイズを大きくした
  • Java11にはZGCがあるから、GCの時間が短くなると期待
  • LINE Tag Event
    • 広告主埋め込むJSタグ
      • 広告主のサイトに貼られているので、どらくらい来るのかわからない
      • そこでスケール可能なKafkaで受け取り、過ぎに使うものはRedis、永続的に利用するものはHBand
  • Data Pipeline / Analytics Cluster
    • 広告配信に関わるあらゆるデータを集計し格納、分析するプラットフォーム
    • Hadoop, Hive, Presto
    • Kafka, Spark
    • ES, Druid
    • Airflow, Mesos, Aurora
    • Filebeat, Logstash
  • LINEでは、各プロジェクトでArchitectureやミドルウェアがバラバラ
    • ドラフィックが膨大なので、高速であることが必須

Technical topic

  • Kafka
    • 高速で安定したstreaming platform
    • 各サービス間でのデータの受け渡しで、責任分界点として利用
      • Kafkaに書き込めば送ったことにする
      • なので必ずKafkaに書き込む
    • QueueやJob Schedulerとして利用
    • write at once, consume anywhere
      • とりあえずKafkaに置いとけば、データは消えないので、いろんなサービスで利用可能
    • Spring Bootと相性が良い
      • ほとんどコードを書かなくて良い
      • spring-kafkaもあるけど、公式のkafka_clientがおすすめ
      • spring-kafkaを利用すると、springのバージョンが固定化されるから、自由にバージョンを上げ下げできない
      • Kafka streamはシンプルに利用できる
  • 最近の開発
    • Spring Boot 2
    • Reactor
      • reactive streams
      • non-blocking + back pressure
      • WebFlux
      • Lettuce5
        • ReactiveAPI
        • 戻り値がMono/Fluxになるから、個人的にはスッキリする
      • CompletableFutureとかCompletableFuture<List>とかくよりもスッキリする
    • Kafka
    • actuator + micrometer ( プロメテウスはやめた )

開発チームについて

  • 2 country
    • 韓国の人とはLINEの翻訳ボットで頑張る
      • 韓国語は単語の並びが近いので、翻訳ボットでなんとかなる
  • 60 developer
  • 100 co-worker

参考リンク