人気番組との戦い！ Javaシステムのパフォーマンスチューニング奮闘記

人気番組との戦い！Javaシステムのパフォーマンスチューニング奮闘記

Shin TanimotoAcroquest Technology Co., LTD

Copyright © Acroquest Technology Co., Ltd. All rights reserved.Copyright © Acroquest Technology Co., Ltd. All rights reserved.2

満員御礼！ありがとうございます！！

Copyright © Acroquest Technology Co., Ltd. All rights reserved.

自己紹介

3

• 谷本心 (Shin Tanimoto)

- Acroquest Technology株式会社

- 開発＆トラブルシュート教育

- JavaOneスピーカー

- JJUG / 関ジャバ / S2JSFコミッタ

- Twitter : @cero_t (日本語)

- Facebook : shin.tanimoto (英語)


Java Performance: The Definitive Guide

日本語版、オライリーブースで先行販売中！！

Copyright © Acroquest Technology Co., Ltd. All rights reserved.Copyright © Acroquest Technology Co., Ltd. All rights reserved.

先ほどまでサイン会してました！

5


たぶん、ほぼほぼ寺田さんの

サイン希望者ですけどね！


ところで、いまJavaパフォーマンス本をググった人？


そう、PC・スマホの時代。視聴者は気になったものを

すぐにググル。


どれぐらいの人が？


たとえば、視聴率8%のあの番組に

超潜入されたとすると。


127,000,000 (人)* 0.08 (視聴率)

≒10,000,000 (人)


10,000,000 (人)* 0.01 (検索する率)

* 6 (一人あたりの検索回数)≒ 600,000 (回)


仮に10分間で来るとすれば60,000回／分1,000回／秒


最大同時100アクセス／秒ぐらいのキャパだと、これは捌けないわけですよ


じゃ、どうするの？


スケーラビリティ重要ピーキー対応重要ということは・・・


そう、AWS!!


って現実、そんなに甘くないんだよ！


そのシステム、スケールするの？あと、関連システムを含めて全部AWSに持って行くの？誰がやるの？死ぬの？


誰しもが、すぐAWSに移行できるわけではない。


では、いま動いているシステムを

どうやって改善すれば良いのか？


0. 問題の定義


0. 問題の定義

対象人気宿泊施設の予約システムいま、そこで、実際に動いているシステム→ 早く治したい、すぐ治したい、いま治したい！

問題点TV放送のたびにシステムダウンする→ 予約しようとした人が諦める。

24


0. 問題の定義

問題の原因APサーバ側の問題？

DBサーバ側の問題？

ネットワークの問題？→ どこにボトルネックがあるかは不明

25


0. 問題の定義

26

さて、あなたならどうする？


1. アクセス数の制限2. 問題箇所の性能改善3. ログ収集と可視化4. インフラの改善


全部、順番にやろう！


1. アクセス数の制限2. 問題箇所の性能改善3. ログ収集と可視化4. インフラの改善

暫定対処低コスト

根本解決高コスト


1. アクセス数の制限



31

アクセスを捌けないならブロックすればいいのよ



32

APサーバへのアクセス数が閾値を越えたら

503エラーを返すServletFilter を適用。



33

※ただし予約処理に進んでいる人は除く



34

これでサーバが落ちる頻度はグッと下がった。

ただし、キャパシティもスループットも低いまま。


2. 問題箇所の性能改善



36

事件は現場で起きてるんだ！



37

商用環境で実際に起きているパフォーマンス問題に対してどうアプローチするか？



どこに問題があるのか？1. APサーバのCPU使用率測定

top

2. APサーバのスレッドダンプ取得（遅い時に複数回）

jstack <PID>

3. DBサーバのCPU使用率測定

top

38


2. 問題箇所の性能改善APサーバのCPU使用率が高い場合1. スレッドごとのCPU使用率を取得

top -Hps auxww -L | grep java →重いスレッドのスレッドID（10進数）を確認

スレッドダンプのスレッドID（16進数）と対応させて絞り込み

2. 重い処理が「VM Thread」以外の場合

スタックトレースに表れている処理が問題箇所。3. 重い処理が「VM Thread」の場合

GCが頻発している可能性あり（次ページへ）

39



GCが頻発している可能性がある場合ヒープの使用状況、GCの発生回数を確認する

jstat -gc <PID> 1000OC : Old領域のキャパシティサイズ

OU : Old領域の利用サイズ

FGC : フルGCの回数

40



APサーバのCPU使用率が低い場合何度か取得したスレッドダンプから、頻出するメソッドを特定する。

DPサーバのCPU使用率が高い場合何度か取得したスレッドダンプから、頻出するDBアクセスメソッドを特定する。

41



42

top top -H ps auxww -L

jstack <PID>

CPU使用率：高

対象を特定

CPU使用率：低

スレッドごとの CPU使用率取得

スレッドダンプ取得

対象がVM Thread

jstack <PID>

対象を推定対象がVM Thread以外

jstat -gc <PID> 1000スタックトレース確認フルGC頻度確認



43

パフォーマンス問題の8割はこれで問題箇所を特定できる



44

そっから先は、頑張れ！


3. ログ収集と可視化


の前に、ワンポイント

Javaトラシュー講座


x. ワンポイントJavaトラシュー講座

47

Java標準のGUIトラブルシューティングツールと言えば？


1. VisualVM

48


2. Java Mission Control

49



50

どっちがいいの？



51

ヒープダンプの解析で今夜くらべてみました



52

VisualVMの場合



53



54

char[]とStringが大きい。ヒープダンプあるある。



55

Mission Control +JOverflowプラグインの場合



56



57

Pentahoのログが大きいことが、一目で分かる。


教訓

58

ツールでできることの「本質」は変わらないけど「効率」は大きく変わる。



60

事件は現場で起きているのか？



なぜログ収集が必要なのか？実際に問題が起きているかどうかの、貴重な証拠になるため。「この機能、本当にきちんと動いてるの？」 → 500エラーが○回発生している！

「文字列を + で結合しているから遅くなる」 → この機能の平均レスポンスタイムは○秒である

61



なぜ可視化が必要なのか？状況が一目で分かるみんなで同じものを見られる→ 野球のスコアボードと同じ

62



63

っていうか可視化しないと

どうせ見ないでしょ！？



64

きっと、きちんと動いているだろう（不安だけど）



65

きっと、パフォーマンスも良好だろう（不安だけど）



66

楽観的推測ではなくきちんとログで確認するため

に可視化が必要



67

つまりログ可視化はエンジニアの「責任」



68

じゃ、何を見ましょうか



69

CPU 使用率

メモリ使用量

アクセス数レスポンスタイム

処理成功数

遅いSQL

リソースログ ○ ○アクセスログ ○ ○ ○スロークエリ ○

他にも・・・ GCログ、I/Oサイズ、スレッド数、セッション数など

すぐに見たい情報と、収集元ログの例



70

そしてログ可視化、と言えば。



71

Elasticseach+

Kibana



72

簡単に、小さく、今すぐ始められる



ログの収集と分析(1) Elasticsearch（蓄積）

• リアルタイム検索・解析エンジン• 平たく言えば、ログの検索システム

(2) Kibana（可視化）• ログ検索＆可視化ツール• 平たく言えば、Elasticsearchのフロントエンド

73


3. ログ収集と可視化ログの収集と分析(3) fluentd（収集）

• 各サーバで動くログ収集のエージェント• 平たく言えば、ログをtailしてElasticsearchに送るヤツ

(4) logstash（収集）

• fluentdと同じ

• ただキューが溢れても捨てないから、過去ログ投入に利用

• いつかはEmBulk

74



75



76

ログを可視化した結果


3. ログ収集と可視化（アクセス数）

77

↑テレビテレビの影響↑


3. ログ収集と可視化（上：アクセス数、下：エラー数）

78


3. ログ収集と可視化（上：アクセス数、下：レスポンスタイム）

79


3. ログ収集と可視化（上：レスポンスタイム、下：スロークエリ）

80



普段から、キャパシティぎりぎりのようだTVが来た時に増えたアクセス数が、503エラーにせざるを得ない。

レスポンス悪化するタイミングと、スロークエリが悪化するタイミングが完全に一致。つまりDBネック。→あとは、ネックのSQLを改善するだけ。

81



さらなる可視化ROI（投資対効果）コンバージョンレート（成約率）売り上げ

82



さらなる可視化ROI（投資対効果）コンバージョンレート（成約率）売り上げ→何の話しとんねん、ここJava Day Tokyoやぞ！

83


4. インフラの改善



85

すぐに、AWS、AWS言いやがって・・・



86

なので僕もAWSにしました。



87

大規模改修のタイミングでREST API化 + AWS化



88

既存の周辺システムとはDirectConnectで接続



89

I love AWS❤


まとめ


まとめ

「理論的に」ではなく「今そこにある問題」を解決するための手法を考えることが重要。パフォーマンス問題は、Javaのコマンドラインツールを使って一瞬で絞り込め！ログを見よう！そのために、可視化重要。

91

人気番組との戦い！ Javaシステムのパフォーマンスチューニング奮闘記

Software

Transcript of 人気番組との戦い！ Javaシステムのパフォーマンスチューニング奮闘記