実例Javaトラブルシューティング！〜稼働中のシステムを立て直した半年間の軌跡

実例Javaトラブルシューティング！ 
∼稼働中のシステムを立て直した半年間の軌跡
Shin Tanimoto 
Acroquest Technology Co., LTD

Copyright © Acroquest Technology Co., Ltd. All rights reserved.
自己紹介
2
• 谷本心 (Shin Tanimoto)
- Acroquest Technology株式会社
- 開発＆トラブルシュート教育
- JavaOneスピーカー
- JJUG / 関ジャバ / S2JSFコミッタ
- Twitter : @cero_t (日本語)
- Facebook : shin.tanimoto (英語)

Copyright © Acroquest Technology Co., Ltd. All rights reserved.Copyright © Acroquest Technology Co., Ltd. All rights reserved.
世の中のシステムは 
完璧だろうか？
3

最近、あなたが 
リリースしたシステムは 
完璧だろうか？
4

5

私の名は@cero_t！ 
完璧ならざるシステムに 
戦いを挑む、 
君の友人である！
6

ここで滑るのも 
想定の範囲内である！
7

完璧ならざるシステム
8
皆さんもご存知の通り 
世の中のシステムは 
往々にして問題を抱えている

処理が遅い
大量アクセスを捌けない
セキュリティの脆弱性がある
システムエラーが発生する
直そうにもソースの可読性が低い
9

10
では、今日お話する 
システムは？

とある有名企業のECサイト
TV番組でもよく取り上げられる企業。
そのブランドのファンも多い。
ECサイトの月間PVは1000万ぐらい。
秒間アクセス数は10∼1000ぐらい。
11

12
←TV放送前に起動
システム構成

13
しかし、

とにかく処理が遅い！
検索に30秒ぐらい掛かる。
購入に1∼3分ぐらい掛かる。
大量アクセスを裁けない！
TV放送時にシステムダウン。
購入しようとした人も諦める。
セキュリティの脆弱性がある！
詳しく話せるわけないだろ！
14

システムエラーが発生する！
購入時のシステムエラーが毎日数十回。
たまに金額を間違える（！）
直そうにもソースの可読性が低い！
ネストは10段ぐらい余裕。
ifとelseで同じ処理を書くとか余裕。
複雑度とか200ぐらい余裕。
15

元の開発会社には、直せない！
そもそも、ちゃんと作れない。
問題を直すと、他の問題を発生させる。
他の開発会社にも、直せない！
A社「これはイチから作り直しですね」
B社「これは作り直すこともできませんね」
弊社「やりましょう」
16

17
＿人人人人人人人人＿
＞やりましょう＜
￣Y^Y^Y^Y^Y^Y^Y￣

アジェンダ
トラブルシュートの方針
Mission 1 : 検索処理を高速化せよ！
Mission 2 : 購入エラーをぶっ潰せ！
Mission 3 : 大量アクセスを捌ききれ！
システムの今後
18

最初の方針
(1) Seleniumの自動試験を作成しよう
–直す過程で壊すことがないように。
(2) Checkstyle / FindBugsを掛けつつリファクタ。
– 可読性を向上させながら、ソースを理解しよう。 
 
その結果・・・
19

ダメでした。
20

何がダメだったのか？
(1) 300KLもあるクソコード。
– しかも大半がデッドコード。
(2) 試験項目の作成中にもエラーが頻発。
– まともに試験項目が作れない。
(3) その間にも、本番システムではエラーが多発。
– 事件は現場で起きてるんだ！
21

22
トリアージ

23
「一番の問題は何か？」

24
一番の問題は 
「購入に失敗する」 
ということ

購入に失敗する理由
(1) 購入時にシステムエラーが起きる。
(2) 検索が遅くて、購入までりつけない。
(3) TV放送などでアクセスが集中すると、 
システムがダウンしてしまう。
25

26
これらの改善こそ 
「顧客が望むこと」 
である

27
では、どうやって 
重要な問題を見つけるか？

「現場で起きている問題」を掴む
(1) エラーの発生頻度
• HTTPステータス
• アプリケーションエラー
(2) 性能の傾向
• レスポンス時間
• アクセス数とレスポンス時間の関係
• レスポンス悪化時のリソース状況
(3)その他の典型的な問題
28

どうやって現場の問題を掴むのか？
(1) ログの収集
• アクセスログ
• アプリケーションログ
• MySQLのスロークエリログ
(2) 低負荷な解析ツールの適用
• ENdoSnipe
29

30
ログ分析が必要だ。 
そうだ、 
Elasticsearchを使おう。

31

ログの収集と分析
(1) Elasticsearch（蓄積）
• リアルタイム検索・解析エンジン
• 平たく言えば、ログの検索システム
(2) Kibana（可視化）
• ログ検索＆可視化ツール
• 平たく言えば、Elasticsearchのフロントエンド
(3) ﬂuentd（収集）
• 各サーバで動くログ収集のエージェント
• 平たく言えば、ログをtailしてElasticsearchに送るヤツ
32

典型的な問題の検出
(1) ENdoSnipe
• OSSのトラブルシュートツール
• メモリリークや同一SQL発行回数の警告など 
典型的な問題を検出する
• 平たく言えば、動的なFindBugs
33

Elasticsearch + Kibanaによるログ可視化
34

35
さて、これで準備はできた。 
いざ、トラシュー開始！

36
Mission 1 
 
検索処理を高速化せよ！

問題点の確認
(1) 検索処理が、日常的に遅い。
• ページによるが、10∼30秒程度。
(2) 2∼3日に一度の頻度で、極めて遅くなる。
• 数時間で回復する or システムがダウンする。
37

全アクセス数（上）と、レスポンス時間（下）
38

全アクセス数（上）と、レスポンス時間（下）
39
10件/秒
100件/秒
30秒
20秒
10秒

時々発生する、のレスポンス劣化
40

時々発生する、のレスポンス劣化
41
3000秒
2000秒
1000秒

レスポンス劣化時のMySQLスロークエリログ
42
ほぼ間違いなくDB要因の問題

レスポンス劣化時のMySQLスロークエリログ
43
2000秒
1000秒
ほぼ間違いなくDB要因の問題

でも、なんで線形的に駆け上がるの？
44
ちなみに、スロークエリはすべて 
同じストアドプロシージャだった

45
仮説
1. ストアドの中でテーブルロックしている？
2. DBコネクション数の上限まで至っている？
3. CPUがボトルネック？
4. ディスクI/Oのボトルネック？

46
ENdoSnipeの結果を確認
1. 同一のSQLを1万回ぐらい実行している 
という警告が出ていた 
→数回のSQLで済むよう修正。 
→改善はしたが、まだ遅い。

47
スロークエリのストアドプロシージャを精査
1. Temporary Tableに数万件のinsert
2. 明らかに無駄な処理が多数 
→とりあえず無駄な処理を削って様子見 
→問題は改善されず (^^;;
3. Temporary Tableをon memoryで作成するよう 
create temporary table文を修正＆メモリチューニング 
→その結果・・・

結果・・・ディスクI/Oが激減！
48

結果・・・I/O wait激減！
49

同等の負荷が 
掛かった時の 
CPU使用率比較
その差は歴然！
50

MySQLスロークエリも大幅改善
51

MySQLスロークエリも大幅改善
52
500秒
100秒
なんか重いバッチ。キニシナイ！

53
Mission 1 
 
検索処理を高速化せよ！ 
→撃破！

54
Mission 2 
 
購入エラーをぶっ潰せ！

問題点の確認
(1) 購入処理の途中でエラーが発生する
• システム内要因（NullPointerExceptionなど）
• 外部システム要因（応答なし、など）
(2) お客様からのクレームで気づくことも。
(3) カード決済など絡んでいるので、色々まずい。
55

問題解決へのアプローチ
(1) 購入処理の開始時にロギング。
(2) 処理の途中、終了時にもロギング。
(3) ログを解析して、 
正常終了した処理と、 
終了していない処理に分類。 
→分類後に可視化
56

成功（青）失敗（赤）ユーザ起因（他）
57
この日は10件のエラー。少なめです！

ここでもトリアージ
(1) エラー原因ごとに発生件数を整理して、 
発生件数が多いエラーから順に対応する。
(2) バグパッチを当てるたびに、 
購入エラー数が半減した。
(3) 現在は、外部システム要因を除き、 
ほぼエラーが発生しない。
58

成功（青）失敗（赤）ユーザ起因（他）
59
この日はエラーが0件でした！

60
Mission 2 
 
購入エラーをぶっ潰せ！ 
→いったん、撃破！

61
Mission 3 
 
大量アクセスを捌ききれ！

問題点の確認
(1) TV放送などで大量アクセスがあると、 
レスポンスが悪化し、システムがダウンする。
(2) TV放送前にはAPサーバの台数を 
増やしているが、捌ききれない。
(3) 例のストアドプロシージャが、 
やはりネックになっている。
62

(1) 同時アクセス数制限の強化
• APサーバごとに、検索処理の同時リクエスト数が 
一定数を超えたら、503エラーページを表示。
(2) 検索結果のキャッシング＆同時検索数を制限
• APサーバごとに、重いストアドプロシージャの 
同時実行数を制限。
• 単なる順番待ちにならないよう、 
後続の処理は、検索結果のキャッシュを利用。 
→一定の成果は出たが、根本解決はしない。
63

64
困った。 
スケールアウトしても 
捌けないし。

65
ん・・・？

66
←スケールアウト
システム構成
↑こいつが重い

67
DBがボトルネックなのに 
なんでAPサーバを 
スケールアウトするの？

68
・・・スケールアウト、 
やめれば？

(1) TV放送時にもスケールアウトしないよう決断。 
→システムダウンはなくなった (^^;; 
→レスポンス改善、 
さらに購入処理の改善にも繋がった。
69

70
Mission 3 
 
大量アクセスを捌ききれ！ 
→撃破！

71
このシステムの今後

将来的なロードマップ
1. 全面的なデザインリニューアルに伴い、 
処理をRESTful APIとして再実装
2. 購入処理を非同期化
• レスポンスの高速化
• 自動リトライにより、エラーをリカバリ
3. AWS化して、HA化 / スケーラビリティも向上
72

将来的なロードマップ
4. Elasticsearch / Kibanaの改善 or リプレース
• シングルノードで運用しているせいか、
たまに死ぬ（今日も死んでる）
• 処理負荷が高すぎて過去ログを 
流し込めない
73

ちなみに・・・
関連する案件もいっぱい受注できて、 
弊社的には嬉しい悲鳴！
Java8 + Spring Bootで開発しているんダ！
一緒に働く仲間を募集しているヨ！
74

まとめ
1. 長期的なトラブルシュートにおいて 
ログを可視化するのは、超効果的。
• 現実に起きてる問題が分かる。
• 改善効果が如実に分かる。
2. スケールアウトを間違えると怖い。
3. Java8 + Spring Bootやりたい人を 
募集しているヨ！（大事なことなので2回）
75

実例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)

Más de 心谷本

Más de 心谷本 (9)

Último

Último (10)