高スループット・低レイテンシを実現する技術

by tokku5552

Slide 1

Slide 1 text

高スループット・低レイテンシを実現する技術  株式会社CyberAgent AI事業本部　徳田真之介

Slide 2

Slide 2 text

自己紹介  ● 徳田真之介(@tokkuu)   ● 略歴  ○ 2023/05 〜   ■ CyberAgent AI事業本部   ○ 2021/10 - 2023/04   ■ ミロゴス株式会社(Web系)   ○ 2017/04 - 2021/09   ■ 日鉄日立システムエンジニアリング(SIer)   ● 好きな技術  ○ TypeScript/Next.js/AWS/Golang/Terraform/Flutter   ● 趣味  ○ バンド(ex. ggrks)  ○ 娘  ○ ディズニーランド 

Slide 3

Slide 3 text

RTBの仕組みをおさらい 

Slide 4

Slide 4 text

AD  AD  AD  SSP  SSP  SSP  秒間数十万リクエストに対して 50ms でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲 

Slide 5

Slide 5 text

AD  AD  AD  SSP  SSP  SSP  秒間数十万リクエストに対して 50ms でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲  ● どのキャンペーンの広告をいくらで出すのか？  ● 入札したあと、勝ったのか？それを見たのか？クリックしたのか？  

Slide 6

Slide 6 text

AD  AD  AD  SSP  SSP  SSP  秒間数十万リクエストに対して 50ms でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲  ・bid 　SSPからのリクエストを受けて　入札額を返す・imp 　広告が表示されたら　リクエストが来る・その他　計測用

Slide 7

Slide 7 text

AD  AD  AD  SSP  SSP  SSP  秒間数十万リクエストに対して 50ms でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲  ・bid 　SSPからのリクエストを受けて　入札額を返す・imp 　広告が表示されたら　リクエストが来る・その他　計測用・ユーザー情報から候補となる広告を選定   ・ユーザーの属性に合わせて入札額を決定   ・入札額と広告内容をSSPへ応答  

Slide 8

Slide 8 text

AD  AD  AD  SSP  SSP  SSP  秒間数十万リクエストに対して 50ms でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲  ・bid 　SSPからのリクエストを受けて　入札額を返す・imp 　広告が表示されたら　リクエストが来る・その他　計測用・どのキャンペーンの広告が見られたかを計測   ・消化額++  ・予算に到達していたらストップ  

Slide 9

Slide 9 text

アーキテクチャ概観 

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

● SSPからbidサーバーへ入札リクエストが飛んでくる   ● 広告のマスターデータや最適化パラメータはAuroraや DynamoDBに格納されており、これを元に入札額を決定し、広告データをレスポンス  ● 最適化パラメータはパートナーのユーザー情報DB からS3を経てCA側の Snowflakeで計算し、 DynamoDBに格納 

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

bid処理を高速化する 

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

bid処理の基本構成と高速化  ● 使用言語はGolang  ● 標準出力をfluentdでKinesis Data Streams->Kinesis Data Firehose->S3へと流している  ● Auroraにあるマスタデータはインメモリキャッシュへ  ● DynamoDBへの情報はMemcached などを挟んで取得 

Slide 17

Slide 17 text

bid処理の基本構成と高速化  ● 使用言語はGolang  ● 標準出力をfluentdでKinesis Data Streams->Kinesis Data Firehose->S3へと流している  ● Auroraにあるマスタデータはインメモリキャッシュへ  ● DynamoDBへの情報はMemcached などを挟んで取得  多段キャッシュでread処理を高速化   出力は標準出力のみ 

Slide 18

Slide 18 text

imp処理の高速化  ● impではDynamoDBへの書き込みが発生する   ● DynamoDBにそのまま書き込んでもある程度耐えられるはずだが、bidレスポンスほどの即時性は必要ないため、SQSを挟んで非同期化  

Slide 19

Slide 19 text

最適化ロジック周り 

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

最適化ロジック  ● どの広告をいくらで出すのかを決めるために、配信実績をもとに定期的にパラメーターを更新している  ● 配信実績はS3のログからSFnのworkflowでリフレッシュをかけてSnowflakeに保存   ● DynamoDBへテーブルを分けてユーザー毎、広告毎に一意にパラメーターが取得できる  

Slide 23

Slide 23 text

まとめ  ● read処理はインメモリ→ memcached/redis → Aurora/DynamoDBと多段にキャッシュすることで高速化  ● writeが必要な処理はSQSを使って非同期化   ● 複雑なロジックが必要な部分のうち、予め計算しておけるところは   バッチ処理で計算 