オンライン広告入札システムとZGC ( JJUG CCC 2021 Spring )

ULS
Copyright © 2011-2021 UL Systems, Inc. All rights reserved.
Proprietary & Confidential
オンライン広告入札システムとZGC

ULS
Proprietary & Confidential 1
アジェンダ
1.自己紹介
2.この資料のねらい
3.ZGCへの期待
4.ZGCのパラメータチューニング
5.本番環境におけるZGCとG1GCの比較
6.まとめ

ULS 2
自己紹介

ULS
磯田浩靖
- 所属：ウルシステムズ株式会社
- 連絡先：hironobu.isoda@ulsystems.co.jp
- twitter：hiroisojp
- Javaエンジニア、認定スクラムマスタ
- AWS DeepRacer（強化学習）の大会とか出てます
栗原秀馬
- 所属：SMN株式会社
- 連絡先：shuma_kurihara@so-netmedia.jp
- 競技プログラミングにハマっている。Atcoderで青色です。
自己紹介

ULS 4
この資料のねらい

ULS
この資料のねらい
- ねらいとするところ
- ZGCパラメータチューニング手法を紹介
- 資料を読んだ人がチューニングできる一助としたい
- ZGCで実際にあるシステムに適用した結果を共有
- こういうシステム特性だとこういう結果になったという一例
- ねらいとしないところ
- ZGC自体の詳細な解説
- 過去のJJUGの発表を参考にしてください
- https://speakerdeck.com/line_developers/zgc-in-future-line-hbase
- https://speakerdeck.com/yokotaso/introduction-to-modern-gc

ULS 6
ZGCへの期待

ULS
ZGCは次の目標を達成するように設計されたGC
- サブミリ秒の最大一時停止時間
- 一時停止時間がヒープサイズに応じて増加しない
- 8MBから16TBのヒープを処理
ZGCは低レイテンシなGC
https://wiki.openjdk.java.net/display/zgc/Main

ULS
Logicad = オンライン広告入札システム
- 秒間40万件のリクエストを処理
- 100ms以内のレスポンスが求められる
対象システムは高スループット & 低レイテンシが求められている

ULS
定期ロード
リアルタイム
入札サーバ
Java
(netty)
JDK14
対象システムのアーキテクチャ概要
SSP
nginx
入札サーバ
入札サーバ
入札サーバ
入札サーバ
入札サーバ
Aerospike
(KVS)
RDS
Redis
gRPCサーバ
各種データストア
X
X
X
X
X
X
入札サーバ
入札サーバ
nginx
本日お話する
のはココ

ULS
広告配信はオークション形式で実施
高スループット & 低レイテンシが求められているワケ
AD
WebサイトA に、XYZさんが来ました。
誰か広告を出したい方いませんか？
Webサイト
SSP
事業者
DSP3
DSP2
DSP
１
3円
2円
1円
ユーザID
XYZ
訪問通知
入札リクエスト
&レスポンス
本日お話する
のはココ

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

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

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

ULS
ネットワークレイテンシ
- ネットワークレイテンシ
- 入札処理のレイテンシ
– 最適な広告を選択する処理
オークションに関わるレイテンシ
入札処理のレイテンシ
SSP
事業者
DSP
最大 100ミリ秒
オークション開始 JSON受信
32ミリ秒
オークション終了 JSON返却
32ミリ秒

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

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

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

ULS
平均では高速だが99パーセンタイルではムラがある
しかし99パーセンタイルでは遅いときも
3.7ミリ秒
99thだと75ミリ秒かかるケースもある
平均
99th

ULS
処理ボリューム
- 秒間40万件
- 約6,500億 req/月
– 約200億 req/日
Logicadの処理ボリューム
99thといっても相当な件数がある

ULS
ZGCにより99thのムラをなくすことができないか、またそれに
よってタイムアウトする入札数を減らせないかと考えた
ZGCへの期待サブミリ秒の最大一時停止時間
これらのムラをなくしたい

ULS 21
ZGCのパラメータチューニング

ULS
ベンチマーク環境でのパラメータチューニング
入札サーバ（Javaアプリケーションがあるサーバ）の構成
- JDK16、CPU：28コア、メモリ：128GB
ZGCのJVMパラメータの組み合わせをいろいろ変えて性能評価
を試行したいが課題が2つあった
課題１
JVMパラメータの最適な組み合わせ
がわからない
課題２
GCログの結果をグラフィカル
（手間をかけず）に判断したい
課題１
課題２

ULS 23
課題1: JVMパラメータの最適な組み合わせがわからない

ULS
ZGC用のJVMパラメータはそこそこあるため膨大な組み合わせ
から良さそうな組み合わせを見つけるのは大変
https://wiki.openjdk.java.net/display/zgc/Main

ULS
- Python製のハイパーパラメータ最適化フレームワーク
- パラメータ値の試行錯誤を自動化し、良い性能が出る値を自動的に発見
- 枝刈り機能
- 見込みのない組み合わせは処理を打ち切り、効率的に探索を進める機能
- https://github.com/optuna/optuna
良い組み合わせを探索するために今回はOptunaを利用

ULS
Optuna ハイパーパラメータ最適化
手動で値の組み合わせを指定するのではなく、
自動で組み合わせを試して最適なものを探索する
https://www.slideshare.net/pfi/optuna
人が1つ1つ組み合わせを決める Optunaが組み合わせを決めてくれる

ULS
Optuna 枝刈り機能
見込みのない組み合わせは処理を途中で打ち切られ、短時間で
効率的に探索を進めることができる
性能がでないと予測
される組み合わせも
長時間実施
性能がでないと予測
される組み合わせは
途中で打ち切られる
枝刈りなし枝刈りあり

ULS
組み合わせが膨大であるためOptunaで自動化
OptunaでJVMパラメータの組み合わせ、範囲を指定して
ベンチマークを自動化
Trial 1
Xmx=32GB
ParallelGCThreads=5
.
.
Trial 2
Xmx=40GB
ParallelGCThreads=3
.
.
Trial 99
Xmx=80GB
ParallelGCThreads=10
.
.
・・・

ULS
パラメータの組み合わせ、範囲指定方法
OptunaにJVMパラメータの組み合わせを渡す例
利用するJVMパラメータの値を範囲指定
しておくとOptunaが選択してくれる
選択されたJVMパラメータの組み合わせで
Javaアプリケーションを起動するように
スクリプトを作成した

ULS
OptunaでJVMパラメータの組み合わせを探索する
どのJVMパラメータの影響が大きいかを可視化したり、
組み合わせの結果をまとめてみれる
どのJVMパラメータ
が寄与しているか
5分間平均の変遷
（途中経過）がわかる
QPS 5分間平均の性能の例

ULS
１つのパラメータに着目した例
例えば、このアプリケーションでは
ヒープは単純に増やせば増やすほど効果がありそう
32GB〜80GB

ULS
例えば、このアプリケーションでは
-XX:ZFragmentationLimitはデフォルト値（25）近辺が良さそう
１つのパラメータに着目した例
1〜100

ULS
パラメータ間の関連を確認したい場合
等高線としてみることができる
パラメータ間の関連に着目した例
色が濃い=性能が悪い部分
色が薄い=性能が良い部分
点=あるTrialでの値

ULS
-XX:ZMarkStackSpaceLimit、-XX:ZFragmentationLimitは
ともに低い値の組み合わせのときに性能が良さそう
色が濃い=性能が悪い部分
色が薄い=性能が良い部分

ULS
ヒープサイズ、-XX:ZMarkStackSpaceLimitは
あまり相関がなく、ヒープサイズが大きければ大きいほど性能が良さそう
色が薄い=性能が良い部分がヒ
ープが大きい時にまんべんなく
現れている

ULS
[再掲]パラメータチューニングの流れ
ベンチマーク環境にて、ZGCのJVMパラメータの組み合わせを
いろいろ変えて性能評価を試行したいが課題が2つあった
課題１
JVMパラメータの最適な組み合わせが
わからない
-> Optunaで組み合わせを探索
課題２
課題１
課題２

ULS 37
課題2: GCログの結果をグラフィカルに判断したい

ULS
GCログはテキストなのでさっと良いもの悪いものをフィルタ
リングできるようにグラフ化したい
[2021-03-15T20:31:40.909+0900][debug][gc,phases ] GC(1) Pause Roots Java Threads (ZWorker#4) 0.164ms
[2021-03-15T20:31:40.909+0900][debug][gc,phases ] GC(1) Pause Roots (ZWorker#15) 0.392ms
[2021-03-15T20:31:40.910+0900][debug][gc,phases,start] GC(1) Pause Roots Teardown (VM Thread)
[2021-03-15T20:31:40.910+0900][debug][gc,phases ] GC(1) Pause Roots Teardown (VM Thread) 0.030ms
[2021-03-15T20:31:40.910+0900][info ][gc,phases ] GC(1) Pause Relocate Start 1.040ms
[2021-03-15T20:31:40.910+0900][debug][gc,phases,start] GC(1) Concurrent Relocate

ULS
GCeasyというGC解析サービスを利用
https://gceasy.io/

ULS
各種指標に加え、チューニングに関するアドバイスがもらえる
（アドバイスは有償プラン）
GCeasyによるレポート
GCの傾向
GC停止時間

ULS
各種指標に加え、チューニングに関するアドバイスがもらえる
（アドバイスは有償プラン）
GCeasyによるレポート
GCログで悪い傾向が検知された場合、
問題点の指摘&改善案を提示してくれる

ULS
https://blog.gceasy.io/2016/06/18/garbage-collection-log-analysis-api/
GCeasyはRest APIを提供
Rest APIを提供しており、curlでPOSTするだけで簡単にログ
を解析できる（ただし、こちらも有償プラン）

ULS
G1GCは時々ものすごく遅いがZGCよりGC回数が少ない
ZGCは0-2msに集中しているがGCが頻繁に発生
（参考情報）ZGCとG1GCのGC停止時間の傾向
ZGC
G1GC
ZGCは1回のGCが速いが、
回数が多い
G1GCは1回のGCに時間が
かかっているが回数は少ない
0-1ms
1-2ms
2-3ms
0-10ms
10-20ms
20-30ms

ULS
（参考情報）ZGCとG1GCのGC停止時間の傾向
ZGC
G1GC
時々ものすごく遅い
処理時間は安定
している
3ms
1200ms
200ms

ULS
[再掲]パラメータチューニングの流れ
ベンチマーク環境にて、ZGCのJVMパラメータの組み合わせを
いろいろ変えて性能評価を試行したいが課題が2つあった
課題１
JVMパラメータの最適な組み合わせが
わからない
-> Optunaで組み合わせを探索
課題２
-> GCeasyのレポートを利用
課題１
課題２

ULS
実施したパラメータチューニングの構成
Optunaで取得したメトリクスとGCeasyのレポートを元に
性能評価し、めぼしいJVMパラメータの組み合わせを探索
Trial 1
Xmx=32GB
ParallelGCThreads=5
.
.
Trial N
Xmx=80GB
ParallelGCThreads=20
.
.
GCログ
・・・
スコアが良いJVMパラメータの
GCログをレポートで確認
・・・

ULS
Optunaのグラフと値（RDBに格納される）、および
GCeasyのレポートから良さそうな組み合わせに目星を付ける
Optuna、GCeasyを用いて最適なパラメータを探索する

ULS
ZGCのパラメータチューニングによる効果
デフォルトのJVMパラメータと各種JVMパラメータを設定した
ものはきちんと性能が変わる
= JVMパラメータをチューニングする意味はある
JVMパラメータ設定あり
デフォルト設定

ULS 49
本番環境におけるZGCとG1GCの比較

ULS
入札サーバ（Javaアプリケーションがあるサーバ）の構成
- JDK16（2台だけバージョンアップ）
- CPU：28コア、OSメモリ：128GB、Javaメモリ：80GB
本番環境構成
入札サーバの2台をJDK16化
うち1台をZGC
もう1台をG1GCとし、
メモリサイズを合わせたものを用意

ULS
以下の指標に差があるかを確認
- QPS（スループット）
- ETM（処理時間）
ZGCとG1GCでの比較ポイント

ULS
（参考情報）ZGCとG1GCの比較 JVMパラメータ
JVMパラメータ
1702 jp.xxx.yyy.BuyerServer -Xmx80g -Xms80g -XX:MetaspaceSize=512m
-XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:+UseStringDeduplication
-XX:GCTimeRatio=9 -XX:G1HeapRegionSize=32m -
XX:G1ReservePercent=20 -
Xlog:gc*=debug:file=/xxx/gc.log:time,level,tags:filecount=10,filesize=10
M -Djcd.dest=udp://127.0.0.1:3011 -Djcd.instance=Buyer -
Djcd.tmpl=javalang,buyersettings -javaagent:xxx.jar -XX:+UseNUMA -
XX:ReservedCodeCacheSize=384M -XX:-OmitStackTraceInFastThrow -
XX:+ExitOnOutOfMemoryError -javaagent:yyy.jar --illegal-access=warn --
add-opens=java.base/java.lang.invoke=ALL-UNNAMED
5296 jp.xxx.yyy.BuyerServer -Xmx80g -Xms80g -XX:MetaspaceSize=512m
-XX:MaxMetaspaceSize=512m -XX:+UseZGC -XX:ConcGCThreads=28 -
XX:ParallelGCThreads=6 -XX:ZAllocationSpikeTolerance=1.0 -
XX:ZFragmentationLimit=10 -XX:ZMarkStackSpaceLimit=28g -
XX:+UseLargePages -XX:+UseNUMA -
Xlog:gc*=debug:file=/xxx/gc.log:time,level,tags:filecount=10,filesize=10
M -Djcd.dest=udp://127.0.0.1:3011 -Djcd.instance=Buyer -
Djcd.tmpl=javalang,buyersettings -javaagent:xxx.jar -XX:+UseNUMA -
XX:ReservedCodeCacheSize=384M -XX:-OmitStackTraceInFastThrow -
XX:+ExitOnOutOfMemoryError -javaagent:yyy.jar --illegal-access=warn --
add-opens=java.base/java.lang.invoke=ALL-UNNAMED
ZGC
G1GC

ULS
ZGCとG1GCの比較 QPS
QPS（スループット）はほぼ差がなかった
1日
3時間
ほぼ差がない
ほぼ差がない
ZGC
G1GC

ULS
ZGCとG1GCの比較 ETM 99th
ETM（処理時間）99thではZGCのほうが遅くなった
3時間
1日
ZGC
G1GC
20ms 50ms
30ms 50ms

ULS
ETM（処理時間）999thではZGCのほうが安定していた
3時間
1日
ZGC
G1GC
3時間の指標ではわかりにくいが、1日単位で
みるとムラの発生回数はG1GCのほうが多い
200ms
100ms
1秒
1秒
1秒

ULS
ETM（処理時間）999thではZGCのほうが安定していた
...が、結局平均64-67ms程度かかっていた
3時間
1日
ZGC
G1GC
67ms
64ms

ULS
ZGCとG1GCの比較 GC停止時間の傾向
ZGC
G1GC
ZGCは1回のGCが速いが、
回数が多い
G1GCは1回のGCに時間が
かかっているが回数は少ない
0-1ms
1-2ms
2-3ms
0-10ms
10-20ms
20-30ms

ULS
ZGCとG1GCの比較 GC停止時間の傾向
ZGC
G1GC
時々ものすごく遅い
処理時間は安定
している
3ms
1200ms
200ms

ULS
指標の確認結果は次の通り
- QPS（スループット）
- ZGCとG1GCで差はなかった
- ETM（処理時間）
- 99thではG1GCのほうが安定していた
- 999thではZGCのほうが安定していた（が、67ms程度かかる）
- GCログ
- ZGCは0-2msに集中しているがGCが頻繁に発生
- G1GCは時々ものすごく遅いがZGCよりGC回数が少ない
ZGCとG1GCでの比較

ULS
Logicadのシステム特性とマシンスペックでZGCを動かした
限りにおいてはシステムへうまくマッチしなかった
- ETM 999th以降は確かに安定している
- LogicadではNW含めて100ms以内でのレスポンスが求められるため、もう少し低い
値で安定することができればマッチできたかもしれない
- レイテンシの安定（すべての処理に200ms以内で返すなど）が求められるシステム
では合うかもしれない
- GC停止時間は短いがGC回数がG1GCより高頻度でおきている
- 結果、1回あたりのGC時間が短くなったとしてもアプリケーション側がそのまま速く
なったわけではなかった
- 用意できるハードウェアの制限のため、より大きなメモリサイズで実施し
た場合は活きるかもしれない（100GB未満だとあまり効果なさそう）
ZGCの適用結果

ULS 61
まとめ

ULS
まとめ
- ZGCは低レイテンシなGC
- 安定して0-2msのGC停止時間が確認できた
- ただしGC回数はG1GCより増える
- パラメータチューニングの自動化が重要
- JVMパラメータは組み合わせが膨大
- Optunaなどを用いて機械的に探索できるとよい
- GCログは傾向を掴みやすいようにグラフにする
- GCeasyを用いてグラフから傾向を把握し、よいパラメータの組み合わ
せかどうかを確認

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

オンライン広告入札システムとZGC ( JJUG CCC 2021 Spring )

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à オンライン広告入札システムとZGC ( JJUG CCC 2021 Spring )

Similaire à オンライン広告入札システムとZGC ( JJUG CCC 2021 Spring ) (20)

オンライン広告入札システムとZGC ( JJUG CCC 2021 Spring )