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

人気番組との戦い！ 
Javaシステムのパフォーマンスチューニング奮闘記
Shin Tanimoto 
Acroquest 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 (英語)

4
Java Performance: The Deﬁnitive Guide
日本語版、 
オライリーブースで 
先行販売中！！

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

6

7
たぶん、ほぼほぼ 
寺田さんの 
サイン希望者ですけどね！

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

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

10
どれぐらいの人が？

11
たとえば、視聴率8%の 
あの番組に 
超潜入されたとすると。

12
127,000,000 (人) 
* 0.08 (視聴率) 
≒10,000,000 (人)

13
10,000,000 (人) 
* 0.01 (検索する率) 
* 6 (一人あたりの検索回数) 
≒ 600,000 (回)

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

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

16
じゃ、どうするの？

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

18
そう、AWS!!

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

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

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

22
では、 
いま動いているシステムを 
どうやって 
改善すれば良いのか？

23
0. 問題の定義

0. 問題の定義
対象
人気宿泊施設の予約システム
いま、そこで、実際に動いているシステム 
→ 早く治したい、すぐ治したい、いま治したい！
問題点
TV放送のたびにシステムダウンする 
→ 予約しようとした人が諦める。
24

0. 問題の定義
問題の原因
APサーバ側の問題？
DBサーバ側の問題？
ネットワークの問題？ 
→ どこにボトルネックがあるかは不明
25

0. 問題の定義
26
さて、あなたなら 
どうする？

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

28
全部、順番にやろう！

29
1. アクセス数の制限 
2. 問題箇所の性能改善 
暫定対処 
低コスト
根本解決 
高コスト

30
1. アクセス数の制限

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

32
APサーバへのアクセス数が 
閾値を越えたら 
503エラーを返すServletFilter 
を適用。

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

34
これでサーバが落ちる頻度は 
グッと下がった。 
ただし、キャパシティも 
スループットも低いまま。

35
2. 問題箇所の性能改善

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

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

どこに問題があるのか？
1. APサーバのCPU使用率測定
top 
2. APサーバのスレッドダンプ取得（遅い時に複数回）
jstack <PID> 
3. DBサーバのCPU使用率測定
top
38

APサーバのCPU使用率が高い場合
1. スレッドごとのCPU使用率を取得
top -H
ps auxww -L | grep java 
→重いスレッドのスレッドID（10進数）を確認
スレッドダンプのスレッドID（16進数）と対応させて絞り込み
2. 重い処理が「VM Thread」以外の場合
スタックトレースに表れている処理が問題箇所。
3. 重い処理が「VM Thread」の場合
GCが頻発している可能性あり（次ページへ）
39

GCが頻発している可能性がある場合
ヒープの使用状況、GCの発生回数を確認する
jstat -gc <PID> 1000
OC : 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
そっから先は、 
頑張れ！

45

46
の前に、 
ワンポイント 
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 + 
JOverﬂowプラグインの場合

56

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

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

59

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) ﬂuentd（収集）
• 各サーバで動くログ収集のエージェント
• 平たく言えば、ログをtailしてElasticsearchに送るヤツ
(4) logstash（収集）
• ﬂuentdと同じ
• ただキューがれても捨てないから、 
過去ログ投入に利用
• いつかはEmBulk
74

75

76
ログを可視化した結果

3. ログ収集と可視化（アクセス数）
77
↑テレビテレビの影響↑

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

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

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

普段から、キャパシティぎりぎりのようだ
TVが来た時に増えたアクセス数が、 
503エラーにせざるを得ない。
レスポンス悪化するタイミングと、 
スロークエリが悪化するタイミングが 
完全に一致。つまりDBネック。 
→あとは、ネックのSQLを改善するだけ。
81

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

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

84

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

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

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

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

89
I love AWS❤

90
まとめ

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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

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

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

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