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

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

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

RTBの仕組みをおさらい 

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

でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲  • どのキャンペーンの広告をいくらで出すのか？  • 入札したあと、勝ったのか？それを見たのか？クリックしたのか？  

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

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

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

アーキテクチャ概観 

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

bid処理を高速化する 

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

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

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

最適化ロジック周り 

でレスポンス   ・  ・  ・  ・  ・  ・  DSP  ユーザー  広告主  キャンペーン1  キャンペーン2  キャンペーン3  ・  ・  ・  再掲  • どのキャンペーンの広告をいくらで出すのか？  • 入札したあと、勝ったのか？それを見たのか？クリックしたのか？  

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

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

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

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

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

tokku5552

Transcript