hbstudy#82 FullGCとの闘い

UZABASE SRE Teamとして「FullGCとの闘い」というテーマで発表 @SRE大全(hbstudy#82)

Transcript

1. hbstudy #82 SRE 大全 UZABASE SRE
2. FullGCとの闘い
3. 自己紹介 • 久保 裕史 (Hirofumi Kubo) – UZABASE, Inc SRE Team – Infrastructure Engineer • 前職(2014/04 ~ 2017/03) – 新卒で入社した大手SIerで3年 – 様々な顧客の業務システムやWebサービスのインフラ構築・運用 – AWS/オンプレ両方 • UZABASEにJoin（2017/05 ~） – SPEEDAのインフラ構築・運用 – UZABASEグループ内のWordPressサイト運用 – 最近は、GoでCleanArchitecture&DDDでアプリケーション開発も
4. ここ数年のプロダクトの成長ともに浮き彫りになってきた FullGC問題の改善について
5. • SPEEDA の特徴 • SPEEDA のJVMメモリ設計 • SPEEDA における課題 • どのように改善したか？ ◦ Step1：GC起動オプションチューニング ◦ Step2：sessionサーバ導入 ◦ Step3：Tomcat定期restart ◦ Step4：GC/JVM変更 • まとめ
6. SPEEDA の特徴
7. • 約500万社を超える企業情報・財務情報、業界情報などを検索し、分析できる • アプリケーションはJava8で実装している • クライアント側に返すデータ量（ブラウザで表示するデータ量）は非常に多い
8. SPEEDA のJVMメモリ設計
9. • 速いレスポンスの実現のために、ユーザセッションはオンメモリ • 速いレスポンスの実現のために、約500万社のすべての企業情報や財務情報 などをAPサーバにキャッシュデータとしてオンメモリで保持 • データが更新されたタイミングで、キャッシュデータの再作成を実施する必要が あるため、倍のメモリ量を用意 →富豪的プログラミングのススメ （https://www.slideshare.net/chimerast/web-17668560 ） • 結果、APサーバはJVMメモリ60GB/台 で構成 JVMメモリ設計 20GB 20GB 20GB APサーバ ユーザのメモリ領域 キャッシュデータ 20GB 20GB 20GB APサーバ ユーザのメモリ領域 キャッシュデータ（古） キャッシュデータ（新） キャッシュ再作成
10. SPEEDA における課題
11. • ローカルメモリにセッションを利用しているためアプリケーションを停止できない • モノリシックで超大なアプリケーションのため、スケールアウト・分散化が難しい ※もちろんモノリシックを切り崩し、マイクロサービス化し、 　分散化できるアーキテクチャへのリファクタリングは現在進行中 • メモリ60GBと大きいため、FullGC発生時のアプリケーション停止時間が非常に 長い ⇒つまり、簡単にはアプリケーションのアーキテクチャを変更することは難しいため、 今のアーキテクチャの中で、FullGC発生時の停止時間の改善を行う必要がある
12. これは完全に... 技術的負債である レジェンドアプリケーション化している
13. では、なぜレジェンド化してしまったのか？
14. • リリース当初は数万社のデータであったため、オンメモリで問題なかった • プロダクトの成長に合わせて、データ量も数万社 から 500万社に • データ量の増加にともなってリソース不足になった際に、リソースを増強するとい う選択をとってきた
15. どのように改善したか？
16. 4つのStep STEP1：GC起動オプションのチューニング STEP2：SESSIONサーバ導入（ 内製） STEP3：Tomcat定期restart STEP4：GC/JVM変更
17. 4つのStep STEP1：GC起動オプションのチューニング STEP2：SESSIONサーバ導入（ 内製） STEP3：Tomcat定期restart STEP4：GC/JVM変更
18. STEP1：GC起動オプションのチューニング • アプリケーション設計、メモリ設計を変更するのは一朝一夕には対応できない • CMSにおけるGC起動オプションのチューニングによって停止時間の短縮
19. STEP1：GC起動オプションのチューニング チューニング戦略 • キャッシュデータなど大きなオブジェクトは積極的にOld領域に置く • ユーザのセッション情報はなるべくNew領域でGCを行う • FullGCの発生を極力抑えるため、積極的にGCを行う JVMメモリ設計 Old領域 APサーバ ユーザデータ キャッシュデータ New領域
20. ・チューニング方針 　①Eden領域を小さくし、再利用回数を減らし 　　すぐにOLD領域へ移動させる 　　　⇒オブジェクトサイズが大きく、 　　　　Edenに置くメリットが小さい 　 　②フルGCの発生を抑制 　　OLD領域が大きいため、早めにCMS実行 　　しかし、出来るだけ置いておきたい -XX:CMSInitiatingOccupancyFraction=80 -XX:TargetSurvivorRatio=90 -XX:NewRatio=5 -XX:MaxTenuringThreshold=15
21. 4つのStep STEP1：GC起動オプションのチューニング STEP2：SESSIONサーバ導入（ 内製） STEP3：Tomcat定期restart STEP4：GC/JVM変更
22. STEP2：sessionサーバ導入（内製） • ①session情報の外出し – よりSPEEDAに最適化されたsessionサーバを内製 – アプリケーションを改修し、session情報の削減 ⇒1GB/ユーザ　から　数MB/ユーザ　に • ②ユーザのsession情報を外出しできたことで、LBから切り離してのキャッシュデータ最新化が 可能に 　⇒オンラインリロードのために必要だった倍のメモリ量（ 20GB）は不要に 20GB 20GB 20GB APサーバ ユーザのデータ領域 キャッシュデータ（新） キャッシュデータ（古） 20GB 20GB 20GB APサーバ 20GB 20GB APサーバ ①session情報の削減 ②LBから切り離し 最新化可能
23. 4つのStep STEP1：GC起動オプションのチューニング STEP2：SESSIONサーバ導入（ 内製） STEP3：Tomcat定期restart STEP4：GC/JVM変更
24. STEP3：Tomcat定期restart • sessionサーバの導入によって、ローカルセッションからリモートセッションに • その結果、LoadBalancerからAPサーバを切り離し可能 • アプリケーション側で不要なオブジェクトを解放できていない可能性が高い（メモリ リークしている） 　　⇒1日2回、Tomcatをrestartさせる
25. 結果、大幅に改善
26. 4つのStep STEP1：GC起動オプションのチューニング STEP2：SESSIONサーバ導入（ 内製） STEP3：Tomcat定期restart STEP4：GC/JVM変更
27. STEP4：GC/JVM変更 • Step3によってFullGC発生は大幅に削減できたが、依然としてFullGCによるアプ リケーション停止の問題は残 • このFullGC問題の改善のため、様々なGC/JVMをプレ本番環境にテスト導入し、 検証を実施 • 現在の本番APサーバのGCアルゴリズムは、CMS/OracleJDK • 下記の3つのGC/JVMを検証対象として追加し、比較を行った – G1GC/OracleJDK – shenandoahGC/OpenJDK – ZingGC/ZingJVM
28. CMS / HotSpot • Concurrent Mark Sweep Garbage Collection • 世代別GC • 一時停止の短縮が優先される • MinorGC:New領域対象。早い。断片化しない。 • MajorGC:Old領域対象。一部アプリケーション止める。 • Old領域は、compactionがないため断片化する。 • Initial markとremark(final mark)でアプリケーション停止 • MajorGC時にメモリ溢れになるとSTW(Stop The World)
29. G1GC / HotSpot • Garbage First Garbage Collection • 世代別GC • ヒープ領域をリージョンという細かい単位で管理する • 目標停止時間を守ってコレクションを実施 • ガーベッジ率の高そうなヒープに対して実施 • YoungGC、MixedGC、FullGCの3種類 – YoungGC：Eden,Surviver領域対象 – MixedGC：Young領域 + Old領域対象
30. ZingGC / Zing • Azul Systems社（ https://www.azul.com/ ）が提供しているJVM • 独自のC4（Continuously Concurrent Compacting Collector）を使用 • pauseless garbage collection = Non Stop The World • New GenerationとOld Generationの両方でcompactionをconcurrentに実行 し、STWなし • チューニング不要
31. • OpenJDKにて開発中のGC（ http://openjdk.java.net/projects/shenandoah/ ） • compactionもconcurrentに実施 • アプリケーション停止が少ない “Shenandoah is an ultra-low pause time garbage collector that reduces GC pause times by performing more garbage collection work concurrently with the running Java program. CMS and G1 both perform concurrent marking of live objects. Shenandoah adds concurrent compaction” • initial markとfinal markではpauseする • 停止時間はヒープのサイズによらず、100GBでも2GBでも変わらない • ヒープ領域をリージョンという細かい単位で管理する shenandoahGC / OpenJDK
32. • GC発生回数 • GC発生時間（合計時間、最大値、平均値） • FullGC発生回数 • FullGC発生時間（合計時間、最大値、平均値） • 通常時のレスポンスタイム（主要機能ごと） 比較項目
33. 結果（GC発生）
34. 結果（FullGC発生）
35. • GC/FullGCともに発生回数が多くや発生時間が長いZingとshenandoahは導入 検討の対象としては外れる • CMSとG1GCの比較では、判断が難しい • 各GC/JVMごとにGCアルゴリズムやメモリ使用の設計が異なる中で正確に比較す るのは難しいが、CMSの代替としてG1GCは有力 • どのJVMであってもレスポンスへの影響は大差がないことはわかった • 実際に導入を検討する場合、次のステップとしては、アプリケーションの停止時間の 比較が必要 結論
36. まとめ
37. • FullGCとの闘いはまだ続きそう • SREチームとしては、いかにユーザ体験を向上 できるかを重要視して引き続き改善を行ってい きます
38. ありがとうございました
39. Any questions? Thank you for listening！