30msの広告配信を支えるレイテンシ短縮の技術

by やーびー

Embed

Start on current slide

Slide 1

Slide 1 text

30msの広告配信を支えるレイテンシ短縮の技術 DMM.go #12 屋比久怜央

Slide 2

Slide 2 text

自己紹介屋比久怜央　やびくれお名前開発統括本部マーケティングテクノロジー部所属ビリヤード・リアル脱出ゲーム趣味 2

Slide 3

Slide 3 text

3 こんな開発をしています

Slide 4

Slide 4 text

4 bytedance/sonic

Slide 5

Slide 5 text

5 bytedance/sonicパッケージ広告配信に、bytedance/sonic パッケージを利用しています本日の主役出典: https://pkg.go.dev/github.com/bytedance/sonic

Slide 6

Slide 6 text

6 bytedance/sonic とは高速なJSONシリアライザつまり、高速に動作するencoding/json bytedance/sonicパッケージの特徴 { “key”: “value”, “name”: “yabiku” } type Hoge struct { Key string Name string } JSON 構造体

Slide 7

Slide 7 text

7 bytedance/sonic の使い方 sonic.Marshal()によるエンコード sonic.Unmarshal()によるデコード基本的には encoding/jsonと全く同じ { “key”: “value”, “name”: “yabiku” } type Hoge struct { Key string Name string } JSON 構造体 sonic.Marshal() sonic.Unmarshal()

Slide 8

Slide 8 text

8 bytedance/sonicの速さを示すベンチマーク出典: https://github.com/bytedance/sonic 公式が提供するベンチマーク

Slide 9

Slide 9 text

9 bytedance/sonic 速さの理由汎用性故に抱えるオーバーヘッドがボトルネックになる encoding/jsonのパフォーマンス上の弱点構造体に特化したアセンブリを生成して高速化する解決策としての JITコンパイル

Slide 10

Slide 10 text

10 encoding/jsonのパフォーマンス上の弱点パッケージとしては、任意の構造体に対応する必要がある変換するまで構造体のフィールドがわからない reflectパッケージで構造体を読み取る時にメモリアロケーションとGCが頻発動的な型解釈によるオーバーヘッド

Slide 11

Slide 11 text

11 encoding/jsonのパフォーマンス上の弱点 reflectが利用されている様子出典: https://cs.opensource.google/go/go/+/refs/tags/go1.25.6:src/encoding/json/encode.go;l=439-466

Slide 12

Slide 12 text

12 解決策としてのJITコンパイル

Slide 13

Slide 13 text

13 JITコンパイルとは事前に機械語を生成する通常のコンパイルに対し、実行時に機械語を生成する形式のこと Just-In-Timeコンパイル通常のコンパイル JITコンパイルソースコード機械語実行中のソース機械語実行環境実行環境

Slide 14

Slide 14 text

14 JITコンパイルの恩恵実行環境に合わせて機械語が生成される単一のソースコードを、異なる環境で使い回せるソースコードがプラットフォームに依存しない実行時のプロファイルや入力値に応じた最適化を行うことができる実行環境を加味した最適化

Slide 15

Slide 15 text

15 解決策としての JITコンパイル変換対象の構造体に特化したJITコンパイルを行う JITコンパイル JSONパーサ・シリアライザをJITコンパイルして高速化

Slide 16

Slide 16 text

16 bytedance/sonic はなぜ高速なのか - まとめ構造体やJSONの構造に応じたJITコンパイルを行う encoding/jsonのパフォーマンス上の弱点を克服異なるサイズのデータの混在に適応するためのSIMD 自作のasm2asmツールによる高度な最適化 ASTパーサーにおけるLazy Load そのほかにも ... 出典: https://github.com/bytedance/sonic/blob/main/docs/INTRODUCTION.md

Slide 17

Slide 17 text

17 bytedance/sonicの導入事例

Slide 18

Slide 18 text

18 広告配信基盤での bytedance/sonic利用 DMM.com社内で利用される内製の広告配信基盤社員が登録した広告バナーを、DMMが管理するWebサイトに配信する広告配信基盤とは DMMが管理するWebサイトに対して、低レイテンシでの広告配信を実現する bytedance/sonicパッケージが果たす役割

Slide 19

Slide 19 text

19 広告配信基盤のアーキテクチャ利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ

Slide 20

Slide 20 text

20 配信までの大雑把な流れ利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿

Slide 21

Slide 21 text

21 配信までの大雑把な流れ利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿広告データを配信サーバに保存

Slide 22

Slide 22 text

22 配信までの大雑把な流れ利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿広告データを配信サーバに保存広告を配信

Slide 23

Slide 23 text

23 もっと詳しく利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ

Slide 24

Slide 24 text

24 もっと詳しく利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿

Slide 25

Slide 25 text

25 もっと詳しく利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿 sonicによるJSON へのエンコード

Slide 26

Slide 26 text

26 もっと詳しく利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿 sonicによるJSON へのエンコード文字列化された配信の取り込み

Slide 27

Slide 27 text

27 もっと詳しく利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿 sonicによるJSON へのエンコード文字列化された配信の取り込み sonicによるデコード

Slide 28

Slide 28 text

28 もっと詳しく利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ社員による広告入稿 sonicによるJSON へのエンコード文字列化された配信の取り込み sonicによるデコードリクエストを受けて動くのはここだけ

Slide 29

Slide 29 text

29 広告配信基盤の速さの秘訣 Cloud SQLに記録された広告情報を、Memorystoreを介して Cloud Runのメモリに保存している事前に広告情報をメモリにロードしておく配信サーバが動作するCloud Runの外に広告情報を取りに行かずに高速に広告情報を返却するリクエストを受けたら、メモリの情報を返却

Slide 30

Slide 30 text

30 広告配信基盤の速さの秘訣利用者オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ Cloud SQL 広告データ

Slide 31

Slide 31 text

31 広告配信基盤の速さの秘訣利用者オンメモリキャッシュ Cloud Run 配信サーバメモリ上のJSON Goの構造体 sonicによるデコード

Slide 32

Slide 32 text

32 速いのはわかったけど ... 配信情報が全てサーバのメモリに積まれているメモリに配信情報載せて大丈夫なの？コンテナ起動時にメモリが空だったりとかコンテナ終了時にデータが消えたりとかコンテナはスケールするけど大丈夫なの？

Slide 33

Slide 33 text

33 メモリに配信情報を載せて大丈夫なの？リクエストを受けてメモリから配信を返すということは全ての配信情報がメモリに積まれており、その中から選んでいる大量の配信情報によって、メモリが枯渇しないのか？配信情報をJSON化する時に、文字列を圧縮などしない bytedance/sonicが提供するのは高速なシリアライズのみ

Slide 34

Slide 34 text

34 メモリに配信情報を載せて大丈夫なの？出典: https://dmm-corp.com/figures/

Slide 35

Slide 35 text

35 メモリに配信情報を載せて大丈夫なの？ DMM会員数やリクエスト量はまた別の話社内用の広告配信基盤では、広告量が膨大にならないメモリの量は配信情報の量

Slide 36

Slide 36 text

36 速いのはわかったけど ... 配信情報が全てサーバのメモリに積まれているメモリに配信情報載せて大丈夫なの？コンテナ起動時にメモリが空だったりとかコンテナ終了時にデータが消えたりとかコンテナはスケールするけど大丈夫なの？

Slide 37

Slide 37 text

37 コンテナはスケールするけど大丈夫なの？プロセス起動時にキャッシュサーバを参照すれば良いコンテナ起動時にメモリが空にならないの？オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ

Slide 38

Slide 38 text

38 コンテナがスケールしても大丈夫あくまでキャッシュサーバから取得した情報なので問題ないコンテナ終了時にメモリは揮発するけどいいの？オンメモリキャッシュ Cloud Run 配信サーバ Memorystore キャッシュ

Slide 39

Slide 39 text

39 速いのはわかったけど ... 配信情報が全てサーバのメモリに積まれているメモリに配信情報載せて大丈夫なの？コンテナ起動時にメモリが空だったりとかコンテナ終了時にデータが消えたりとかコンテナはスケールするけど大丈夫なの？

Slide 40

Slide 40 text

40 まとめ

Slide 41

Slide 41 text

41 ご清聴ありがとうございました ● bytedance/sonicは高速なJSONシリアライザ ● JITコンパイルにより、reflectのオーバーヘッドを削減 ● DMMの広告配信基盤は、レスポンスの高速化のために3層のデータを保持するアーキテクチャ ● オンメモリキャッシュのシリアライズにsonicを利用し、高速な広告配信を実現まとめ