200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6

ULS Powered by
Copyright © 2011-2018 UL Systems, Inc. All rights reserved.
Proprietary & Confidential
200,000 Req/sec をさばく
広告入札システムを支えるパフォーマンスチューニング術
2018/12/15
ウルシステムズ株式会社
http://www.ulsystems.co.jp
mailto:info@ulsystems.co.jp
Tel: 03-6220-1420 Fax: 03-6220-1402
#jjug_ccc #ccc_g6

ULS
Proprietary & Confidential Powered by 1
#jjug_ccc #ccc_g6
1. 自己紹介
2. Logicadについて
3. 広告業界におけるRTB
4. アーキテクチャ概要
5. Logicadにおける Java パフォーマンスチューニング
6. Java の外側にも目を向ける
7. まとめ
8. QA
アジェンダ

ULS
#jjug_ccc #ccc_g6自己紹介
磯田　浩靖
● 所属：ウルシステムズ株式会社
● 連絡先：hironobu.isoda@ulsystems.co.jp
● twitter：hiroisojp
● 認定スクラムマスタ
山崎　良祐
● 所属：ソネット・メディア・ネットワークス株式会社
● 連絡先：ryamazaki@so-netmedia.jp
● twitter : nappa
● 認定肩こりマスタ

ULS
#jjug_ccc #ccc_g6
● 余談: AWS re:Invent 2018 に行ってきました
– Amazon Corretto の情報はとくに得てないです
– Java の父・James Gosling さんがいたらしい
すぐ近くにいたはずなのに全然気づかなかった
(帰宅してから twitter で知った)
re:Invent & Amazon Corretto

ULS
#jjug_ccc #ccc_g6Logicadについて
● お客様
– ソネット・メディア・ネットワークス株式会社
● 主な事業内容
– DSP事業
● Logicad を提供
● RTBを活用した広告配信最適化
● 機械学習・人工知能を活用したDMPによる広告配信精度の向上
● プロジェクト支援概要
– DSP/RTBシステム開発支援
– VALIS-Engine（機械学習・人工知能）開発支援
2018/11からロゴが
新しくなりました

ULS
#jjug_ccc #ccc_g6
1. 自己紹介
7. まとめ
8. QA

ULS
#jjug_ccc #ccc_g6
● 広告配信はオークション形式で実施
RTB（リアルタイムビッディング）の概要
AD
WebサイトA に、XYZさんが来ました。
誰か広告を出したい方いませんか？
Webサイト
SSP
事業者
DSP3
DSP2
DSP１
3円
2円
1円
ID=XYZ
訪問通知
入札リクエスト
&レスポンス
本日お話する
のはココ

ULS
#jjug_ccc #ccc_g6
● 入札に勝つと広告を表示する権利を得ることができる
● 表示された広告に応じて売上が発生するビジネスモデル
RTB（リアルタイムビッディング）の概要
AD
Webサイト
SSP
事業者
DSP3
DSP2
DSP１
3円
2円
1円
ID=XYZ
訪問通知
①広告配信
　リクエスト
本日お話する
のはココ
WIN
②広告配信レスポンス
③Webサイトに
　広告表示用の
　URLを設定

ULS
#jjug_ccc #ccc_g6
● タイムアウトが発生するとオークションに参加できない
– オークションの開催期間はわずか100ミリ秒
性能要求を満たせないと会社の存続に関わる
AD
Webサイト
SSP
事業者
DSP3
DSP2
DSP１
3円
2円
1円
ID=XYZ
訪問通知
入札リクエスト
&レスポンス
本日お話する
のはココ
タイムアウトが多く発生すると
他のDSPに権利をもっていかれて、
ビジネスとして成り立たない！

ULS
#jjug_ccc #ccc_g6
スループット向上
単位時間あたりの処理能力を高めて、
よりたくさん捌く
レイテンシの低減
要求〜結果が返ってくるまでの時間
をできるだけ短くする
Client Server
1回あたりの処理が
高速であること
同時にたくさん
捌くことができること
悩める性能要求
Client ServerClientClient
タイムアウトを減らして売上を確保するためには・・・
両方を経済合理的な範囲で最適化する

ULS
#jjug_ccc #ccc_g6
ネットワークレイテンシ
● ネットワークレイテンシ
● 入札処理のレイテンシ
– 最適な広告を選択する処理
オークションに関わるレイテンシ
入札処理のレイテンシ
SSP
事業者
DSP
最大 100ミリ秒

ULS
#jjug_ccc #ccc_g6ネットワークレイテンシ
● ネットワークレイテンシは一定ではない
– 伝送距離の長さによって決まる
通信相手往復時間
東京～東京約1～2ミリ秒
東京〜大阪約7～10ミリ秒
東京～台湾約65ミリ秒
東京〜西海岸約120ミリ秒
東京〜ドイツ約210〜290ミリ秒

ULS
● ネットワークレイテンシは一定ではない
– 伝送距離の長さによって決まる
通信相手往復時間
東京～東京約1～2ミリ秒
東京〜大阪約7～10ミリ秒
東京～台湾約65ミリ秒
東京〜西海岸約120ミリ秒
東京〜ドイツ約210〜290ミリ秒
ただし、オークションの開催期間はわずか100ミリ秒

ULS
#jjug_ccc #ccc_g6光速が遅い
https://imgur.com/gallery/litaH

ULS
● 台湾と接続する場合
65ミリ 100ミリ
ココから先は
タイムアウトに
なってしまう

ULS
#jjug_ccc #ccc_g6オークションのレイテンシ
● 入札処理が加わるとさらにタイムアウトは増える
– 最適化アルゴリズム（機械学習）、最適な広告入札の機能開発
によって処理時間は増えてしまう
65ミリ 100ミリ
入札処理が加わって
タイムアウトになった分

ULS
#jjug_ccc #ccc_g6入札処理のレイテンシは平均3ミリ秒！
● Logicadの入札処理は平均3ミリ秒！
– 機能が増えてもレイテンシを短くできればタイムアウトが減らせる
– 高速化が売上につながる、最適化アルゴリズムに使える時間が増える
65ミリ 100ミリ
入札処理を短くすることが
できればもっとタイムアウトが
減らせる

ULS
#jjug_ccc #ccc_g6
● 処理ボリューム
– 約4億ユニークブラウザ
– 約3,000億 req/月
● 約100億 req/日
● 約22万 req/sec
（参考）Logicadの処理ボリューム
補足: 20万->22万とJJUG応募時点より増えました

ULS
#jjug_ccc #ccc_g6
1. 自己紹介
7. まとめ
8. QA

ULS
#jjug_ccc #ccc_g6
・広告商品情報
広告に表示する文章、画像URL、
サイズなどの情報を格納
・ユーザ情報
・広告予算消化情報
リアルタイムに扱う情報を格納
入札サーバ
Java
(netty)
Logicadのアーキテクチャ概要
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
・広告キャンペーン情報
事前定義、定期的にロードする
必要がある情報を格納
・アドフラウド情報
3rd Partyから提供された
情報を格納
Aerospike
(KVS)
RDS
Redis
広告商品
情報サーバ
(gRPC)

ULS
#jjug_ccc #ccc_g6
・ユーザ情報
入札サーバ
Java
(netty)
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
情報を格納
Aerospike
(KVS)
RDS
Redis
広告商品
情報サーバ
(gRPC)
スループットを上げたい場合は
スケールアウト（入札サーバを増やす）でも
一定の効果はあるがコストも増加
入札サーバ

ULS
#jjug_ccc #ccc_g6
・ユーザ情報
入札サーバ
Java
(netty)
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
X
X
X
X
情報を格納
Aerospike
(KVS)
RDS
Redis
広告商品
情報サーバ
(gRPC)
1台あたりのレイテンシを低減させる
ことができれば、スループットも向上し、コスト
もスケールアウトよりかからない

ULS
#jjug_ccc #ccc_g6
1. スケールアウト（並列化）によって実現
2. レイテンシを低減することによっても向上
レイテンシとスループット
1. サーバ1台あたりの処理高速化によって実現
入札サーバ
ココの遅延
ココの処理数
SSP
入札サーバSSP

ULS
#jjug_ccc #ccc_g6
1. スケールアウト（並列化）によって実現
2. レイテンシを低減することによっても向上
レイテンシとスループット
1. サーバ1台あたりの処理高速化によって実現
入札サーバ
ココの遅延
ココの処理数
SSP
入札サーバSSP
3ミリ秒を維持・高速化する
= パフォーマンスチューニングの主体

ULS
#jjug_ccc #ccc_g6
1. 自己紹介
6. FlameScope
8. まとめ
9. QA

ULS
#jjug_ccc #ccc_g6
● 高速化するにはホットスポットをみつけることが必要
● 場当たり的にやるのではなく、ツールやプロファイラによっ
て計測して目星をつける
「推測するな、計測せよ」という格言もある
● デプロイ前に必ず計測
→現状維持を目標としてまずは最適化
● 数値だけでなく、パッとみでわかる＝可視化する
Logicadにおけるパフォーマンスチューニング

ULS
#jjug_ccc #ccc_g6
● CPU workload のホットスポットの
特定に perf と FlameGraphを利用
● FlameGraph
– NetflixのBrendan Gregg氏が開発したツール
– https://github.com/brendangregg/FlameGraph
● JMeter
– 負荷テストツール
本日詳しく話をするツール
Logicadにおけるパフォーマンスチューニング

ULS
#jjug_ccc #ccc_g6
perf.data
perf record
● FlameGraph は perf の結果をグラフ化するツール
FlameGraphとperfの関係
perf script
● perf
– Linux向けのプロファイラ
– 通常は C, C++プログラムの
プロファイリングに用いる
● perf-map-agent
– JVMTI を使って Java メソッドと
perf 出力結果との対応関係を紐
付け
● FlameGraph
– perf-map-agentで出力された
結果をグラフ化
7f89a84819e0 160 Ljava/lang/String;::<init>
7f89a8481d80 1e8
Ljava/lang/Class;::getModifiers
7f89a84820e0 c0 Ljava/lang/Float;::valueOf
7f89a8482400 100
Lorg/msgpack/io/LinkedBufferInput;::requireテキスト
perf-map-agent
FlameGraphの
スクリプトを用いる
バイナリ

ULS
#jjug_ccc #ccc_g6
● FlameGraph は perf の結果をグラフ化するツール
FlameGraph

ULS
#jjug_ccc #ccc_g6
● この例では CPU 時間を可視化
FlameGraph
一定時間の全体（30秒など）
全体から見た相対的な処理時間の割合
下から上に行くほど
メソッドの呼び出し先になる

ULS
#jjug_ccc #ccc_g6
下から上に行くほど
メソッドの呼び出し先になる
FlameGraphの見方
● 縦軸：メソッドコールの流れを表示

ULS
#jjug_ccc #ccc_g6
● 横軸：メソッドの処理時間の割合を表示
FlameGraphの見方
あるメソッドの例
自身の処理が3〜4割程度占めているがそれ以外は他のメソッドの処理で時間がかかっている
グラフ全体の処理時間全体の
占める割合も表示される
String:::startsWithで2割 HashMap$KeyIterator:::nextで4割

ULS
#jjug_ccc #ccc_g6FlameGraphの見方
● 対象があらかじめわかっている場合は、正規表現検索で該当箇所
をハイライトでき、パッと探せる
マッチしている箇所が紫色で
ハイライトされる

ULS
#jjug_ccc #ccc_g6
FlameGraphの見方について、
Logicadの実際のグラフを用いて
デモでお見せします
FlameGraph デモ

ULS
#jjug_ccc #ccc_g6
● どのようなグラフの波形を確認すればよいのか？
● A. 幅を取っているところをまず見る
– 高速化できると全体に対する寄与が大きいため
全体に対して幅を取っている箇所
FlameGraphを用いてのホットスポットの発見方法

ULS
#jjug_ccc #ccc_g6
● A. 小さい幅のところは省く
– 小さい幅を高速化しても全体に対する寄与が小さいため
高速化しても微々たるもの
高速化しても微々たるもの

ULS
#jjug_ccc #ccc_g6
● A. 修正前後で比較
– 幅が膨らんでる箇所があると、コードの変更によりデグレ（処理が遅くなっ
ている）している可能性があるため
デグレの可能性あり
Before
After

ULS
#jjug_ccc #ccc_g6
FlameGraphでの
ホットスポット発見方法について、
Logicadの実際のグラフを用いて
デモでお見せします
FlameGraph デモ

ULS
#jjug_ccc #ccc_g6
● チューニングとデグレを計測しながら進める
FlameGraphでのチューニング
改善
別の処理が相対的に増えるので
新たな改善箇所を見つける
デグレして
いないことを
確認

ULS
#jjug_ccc #ccc_g6
● あるSSPから計測されたレスポンスタイムの比較
高速化に取り組んだ結果

ULS
#jjug_ccc #ccc_g6（参考）FlameGraphによるパフォーマンス計測方法
⑤FlameGraph実行
③perf取得
アプリサーバ
Java
ストレスサーバ
JMeter
②大量リクエスト
①JVMオプション
　設定&起動
ターミナルetc
④perf-map-agent実行
● FlameGraph取得の流れ

ULS
#jjug_ccc #ccc_g6（参考）JVMオプション設定&起動
● JVMオプションに以下を追加
-XX:+PreserveFramePointer
-XX:-Inline
● -XX:+PreserveFramePointer
– これによりメソッドの呼び出し先メソッドが判る
● -XX:-Inline
– 呼び出し頻度の多いメソッドがインライン化
（呼び出し元に展開）されることを抑制
– perfで小さいメソッドが見えなくならないようにする

ULS
#jjug_ccc #ccc_g6
● 十分な時間の負荷を与えて JIT
(Just-in-time Compile) させる
● Logicadでは負荷はJMeterで実施
（参考）大量リクエスト
アプリサーバ
Java
ストレスサーバ
JMeter
Logicadでは、
約200万リクエスト
約200並列を5〜10分程度与え続けて実施

ULS
#jjug_ccc #ccc_g6
● perf record で当該PIDの
(もしくは全体)サンプリング取得
● perfバイナリ（perf.data）が取得で
きる
（参考）perf取得
# perf record -F 99 -a -g -- sleep 30
30秒間、99Hz のサンプリングで取得する例

ULS
#jjug_ccc #ccc_g6
● perf-map-agent を実行
● perf-<PID>.mapが生成される
（参考）perf-map-agent実行
# java -cp
attach-main.jar:$JAVA_HOME/lib/tools.jar
net.virtualvoid.perf.AttachOnce <PID>
7f89a8481680 200 Lsun/misc/Unsafe;::getLongVolatile
7f89a84819e0 160 Ljava/lang/String;::<init>
7f89a8481d80 1e8 Ljava/lang/Class;::getModifiers
7f89a84820e0 c0 Ljava/lang/Float;::valueOf
7f89a8482400 100 Lorg/msgpack/io/LinkedBufferInput;::require
7f89a8482820 60 Ljava/util/BitSet;::wordIndex
7f89a8482b00 180 Lio/grpc/okhttp/AsyncFrameWriter$WriteRunnable;::run
7f89a8483040 160 Lnet/citrusleaf/CitrusleafClient;::getResult
7f89a84834c0 e0 Lcom/aerospike/client/AerospikeException$Timeout;::<init>
7f89a8483840 4a0 Ljava/math/BigInteger;::multiplyToLen

ULS
#jjug_ccc #ccc_g6
● FlameGraphのスクリプトで
グラフ化
# perf script | stackcollapse-perf.pl |
flamegraph.pl --color=java --hash >
/tmp/flame_graph.svg
（参考）FlameGraph実行
ブラウザで表示するとグラフとして見れる

ULS
#jjug_ccc #ccc_g6
1. 自己紹介
7. まとめ
8. QA

ULS
#jjug_ccc #ccc_g6Java その外側に目を向ける必要性
● ここまでは Java のコードかつ CPU バウンドの
処理を調べるケースの話
– デプロイごとに実施するレギュラーな作業としての計測と最適化
としてはこれで十分
● そうでない場所にもレイテンシ源はいっぱいある
– リアルワールドでは急にレイテンシが増えたり消えたりする

ULS
#jjug_ccc #ccc_g6数字が物語る
あるSSPから計測された当社レスポンスタイム平均

ULS
#jjug_ccc #ccc_g6数字が物語る
曰く「御社のレスポンスタイムが悪化しています」
ここが

ULS
#jjug_ccc #ccc_g6

ULS
#jjug_ccc #ccc_g6なんとなく
● なんとなく JavaVM が疑われがち
● システム全体としてレイテンシを改善するには
Java の外側も含めて全体的に目を向ける必要がある
● もっと言うと、Java の無罪を証明する方法を
Java エンジニアが持つべき

ULS
#jjug_ccc #ccc_g6
DSP
Java の外側の世界
SSP
kernel
nginx
kernel
JVM
Java
Bytecode
Hardware Hardware
LAN
インターネット

ULS
#jjug_ccc #ccc_g6
DSP
そとの世界は広い
SSP
kernel
nginx
kernel
JVM
Java
Bytecode
Hardware Hardware
LAN
本当に
ギルティ？

ULS
#jjug_ccc #ccc_g6
DSP
たとえば…
SSP
kernel
nginx
kernel
JVM
Java
Bytecode
Hardware Hardware
LAN
実はココが
問題だったり

ULS
#jjug_ccc #ccc_g6
● 世界各社の ISP が公開している、Web から
ping/traceroute をたたけるツール
● オープンな Looking Glass のリストは
http://www.traceroute.org/
● SSP が Looking Glass を公開してくれていると
大変ありがたい
● シンガポール →東京間の通信が北米周りになったり 😱
したときに使う
Looking Glass

ULS
#jjug_ccc #ccc_g6ある SSP (AppNexus) の Looking Glass
traceroute コマンドの
パラメータを入力
(ふつうは自社側IPアドレス)

ULS
#jjug_ccc #ccc_g6

ULS
#jjug_ccc #ccc_g6
シンガポール
っぽいホスト名
東京っぽい
ホスト名自社までの
パケット
往復時間(RTT)
= 約70msec

ULS
#jjug_ccc #ccc_g6
DSP
たとえば…
SSP
kernel
nginx
kernel
JVM
Java
Bytecode
Hardware Hardware
LAN
実はココが
問題だったり

ULS
#jjug_ccc #ccc_g6計測せよ
nginx Java
HTTP Request
HTTP Response
HTTP Request
HTTP Response

ULS
nginx Java
HTTP Request
HTTP Response
HTTP Request
HTTP Response
ここの時間
と…
ここの時間
との差は…

ULS
nginx Java
HTTP Request
HTTP Response
HTTP Request
HTTP Response
1. nginx が動いているマシンと、JavaVM が動いているマシンの
両方で tcpdump -w a.cap -i eth0 -s 65535 tcp port 80
(約60秒間)
2. a.cap を tshark でテキストファイルに変換
3. 同一の HTTP Request, Response となっている組を抽出して
タイムスタンプからレスポンスタイムを割り出すプログラム (Ruby製) に食わせる
4. 結果…
詳しくは割愛

ULS
#jjug_ccc #ccc_g6nginx がわりとレイテンシ源になってた件

ULS
#jjug_ccc #ccc_g6nginx がわりとレイテンシ源になってた件
nginx
起因のレイテンシ

ULS
#jjug_ccc #ccc_g6銀の弾丸はない
● Java の外側にも問題がよくみつかる
● いろいろな計測手法を駆使して見つけ出す
● 計測によって新しく見えるものもある

ULS
#jjug_ccc #ccc_g6Flame Scope
● Flame Scope
– Flame Graph を時間単位でスライスして
可視化するツール
– Netflix が OSS にて公開
– https://github.com/Netflix/flamescope
● 以下、CPU使用率ほぼ100%となるよう負荷をかけ、
サンプリングレート 49Hz で120秒間取得した
perf の結果を Flame Scope でビジュアライズした
例を紹介します。CPUコアは28個です。
( perf record -F 49 -a -g -- sleep 120 )

ULS
#jjug_ccc #ccc_g6

ULS
#jjug_ccc #ccc_g6Flame Scope 上での時間の流れ
0秒 1秒 2秒
時間の流れ

ULS
#jjug_ccc #ccc_g6
秒
ミリ秒
1マス 1/49 秒
1列1秒

ULS
#jjug_ccc #ccc_g6
色が濃い
= 28個のCPUコア
が稼働している
色が薄いところ
= CPUコア28個の
ほとんどが idle 状態

ULS
#jjug_ccc #ccc_g6
とても濃い色になってるセル
= perf がつけるタイムスタンプのズレに起因するものと考えられる
(原因不明)

ULS
#jjug_ccc #ccc_g6
約500msec の白いところ
(1コアしか稼働していない!)

ULS
#jjug_ccc #ccc_g6
何かに起因して
HTTP Request をさばく
処理が待機させられている

ULS
#jjug_ccc #ccc_g6
ココだけを
クローズアップ!
して flame graph 生成

ULS
#jjug_ccc #ccc_g6

ULS
#jjug_ccc #ccc_g6
拡大すると…

ULS
#jjug_ccc #ccc_g6

ULS
#jjug_ccc #ccc_g6
RollingFileAppender;::rollover
sys_write
sys_read sys_unlink

ULS
#jjug_ccc #ccc_g6何が起こっていたのか
● logback の RollingFileAppender の
rollover が発生していた
– rollover はファイルのコピーによって行われる
– 大きいサイズのログを rollover すると時間がかかる
● rollover 中はログ出力が一時止まる
→info, err, warn 等のログ出力メソッドの実行が
　rollover 完了まで待たされる

ULS
#jjug_ccc #ccc_g6
Minor GC
Minor GC
Minor GC
Minor GC

ULS
#jjug_ccc #ccc_g6
!?

ULS
#jjug_ccc #ccc_g6何が起こっていたのか
● 裏で pmap コマンドが実行されていた
(ネイティブコードの
メモリリーク監視のため定期実行)
● pmap コマンドは /proc ファイルシステムを叩く
● どうやら /proc のうちどっかを参照しているときに
ユーザランドのプロセス実行が止まるらしい

ULS
#jjug_ccc #ccc_g6CPU 使用率の罠
● CPU使用率がほぼ100%ということは
「みっちり」とレイテンシに最適化されている
ということを意味しない
– 意外に CPU コアは遊んでいる
● 計測しないと気づかない
– pmap の監視がこんなに影響を与えているとは
まったく気づかなかった

ULS
#jjug_ccc #ccc_g6
1. 自己紹介
7. まとめ
8. QA

ULS
#jjug_ccc #ccc_g6
● FlameGraphを用いてホットスポットを可視化しています
– メソッドレベルでグラフィカルに把握できます
● FlameScope、その他のツールを駆使し日々高速化にとりくんでます
– 2016年から 2018年で5ミリ秒から3ミリ秒に高速化しました
● 高速化はハマるといくらでもチューニングできる余地がありますが、経済合理
性を踏まえてコスパのよい部分にフォーカスしましょう
● 今後もJavaを使って高速化を続けます！
まとめ

ULS
#jjug_ccc #ccc_g6
お問い合わせ先
mailto: info@ulsystems.co.jp
https://www.ulsystems.co.jp/

200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6

More Related Content

What's hot

Similar to 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6

Recently uploaded

200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6