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

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

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

ULS 2 Copyright © 2011-2021 UL Systems, Inc. All rights
reserved. Proprietary & Confidential 自己紹介

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

reserved. Proprietary & Confidential この資料のねらい

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

reserved. Proprietary & Confidential ZGCへの期待

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

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

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

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

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

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

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

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

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

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

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

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

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

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

reserved. Proprietary & Confidential ZGCのパラメータチューニング

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

reserved. Proprietary & Confidential ZGCのパラメータチューニング課題1: JVMパラメータの最適な組み合わせがわからない

Proprietary & Confidential 24 課題1: JVMパラメータの最適な組み合わせがわからない ZGC用のJVMパラメータはそこそこあるため膨大な組み合わせから良さそうな組み合わせを見つけるのは大変 https://wiki.openjdk.java.net/display/zgc/Main

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

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

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

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

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

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

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

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

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

Proprietary & Confidential 34 -XX:ZMarkStackSpaceLimit、-XX:ZFragmentationLimitはともに低い値の組み合わせのときに性能が良さそうパラメータ間の関連に着目した例色が濃い=性能が悪い部分色が薄い=性能が良い部分

Proprietary & Confidential 35 ヒープサイズ、-XX:ZMarkStackSpaceLimitはあまり相関がなく、ヒープサイズが大きければ大きいほど性能が良さそうパラメータ間の関連に着目した例色が薄い=性能が良い部分がヒープが大きい時にまんべんなく現れている

Proprietary & Confidential 36 [再掲]パラメータチューニングの流れベンチマーク環境にて、ZGCのJVMパラメータの組み合わせをいろいろ変えて性能評価を試行したいが課題が2つあった課題１ JVMパラメータの最適な組み合わせがわからない -> Optunaで組み合わせを探索課題２ GCログの結果をグラフィカル（手間をかけず）に判断したい課題１課題２

reserved. Proprietary & Confidential ZGCのパラメータチューニング課題2: GCログの結果をグラフィカルに判断したい

Proprietary & Confidential 38 課題2: GCログの結果をグラフィカルに判断したい 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 ] GC(1) Pause Roots (ZWorker#4) 0.811ms [2021-03-15T20:31:40.909+0900][debug][gc,phases ] GC(1) Pause Roots (ZWorker#10) 0.559ms [2021-03-15T20:31:40.909+0900][debug][gc,phases ] GC(1) Pause Roots (ZWorker#6) 0.401ms [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

Proprietary & Confidential 39 GCeasyというGC解析サービスを利用課題2: GCログの結果をグラフィカルに判断したい https://gceasy.io/

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

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

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

Proprietary & Confidential 43 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

Proprietary & Confidential 44 G1GCは時々ものすごく遅いがZGCよりGC回数が少ない ZGCは0-2msに集中しているがGCが頻繁に発生（参考情報）ZGCとG1GCのGC停止時間の傾向 ZGC G1GC 時々ものすごく遅い処理時間は安定している 3ms 1200ms 200ms

Proprietary & Confidential 45 [再掲]パラメータチューニングの流れベンチマーク環境にて、ZGCのJVMパラメータの組み合わせをいろいろ変えて性能評価を試行したいが課題が2つあった課題１ JVMパラメータの最適な組み合わせがわからない -> Optunaで組み合わせを探索課題２ GCログの結果をグラフィカル（手間をかけず）に判断したい -> GCeasyのレポートを利用課題１課題２

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

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

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

reserved. Proprietary & Confidential 本番環境におけるZGCとG1GCの比較

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

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

Proprietary & Confidential 52 （参考情報）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

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

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

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

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

Proprietary & Confidential 57 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

Proprietary & Confidential 58 G1GCは時々ものすごく遅いがZGCよりGC回数が少ない ZGCは0-2msに集中しているがGCが頻繁に発生 ZGCとG1GCの比較 GC停止時間の傾向 ZGC G1GC 時々ものすごく遅い処理時間は安定している 3ms 1200ms 200ms

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

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

reserved. Proprietary & Confidential まとめ

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

Proprietary & Confidential 63 お問い合わせ先 mailto: [email protected] https://www.ulsystems.co.jp/

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

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

More Decks by hiroisojp

Other Decks in Programming

Featured

Transcript