実例javaトラブルシューティング！...

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

Shin TanimotoAcroquest 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


私の名は@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) fluentd（収集）• 各サーバで動くログ収集のエージェント• 平たく言えば、ログをtailしてElasticsearchに送るヤツ

32



典型的な問題の検出(1) ENdoSnipe

• OSSのトラブルシュートツール

• メモリリークや同一SQL発行回数の警告など典型的な問題を検出する

• 平たく言えば、動的なFindBugs

33



Elasticsearch + Kibanaによるログ可視化

34



35

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


Mission 1

検索処理を高速化せよ！


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秒

なんか重いバッチ。キニシナイ！


Mission 1

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


Mission 2

購入エラーをぶっ潰せ！



問題点の確認(1)購入処理の途中でエラーが発生する

• システム内要因（NullPointerExceptionなど）• 外部システム要因（応答なし、など）

(2)お客様からのクレームで気づくことも。(3)カード決済など絡んでいるので、色々まずい。

55



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

56



成功（青）　失敗（赤）　ユーザ起因（他）

57

この日は10件のエラー。少なめです！



ここでもトリアージ(1)エラー原因ごとに発生件数を整理して、発生件数が多いエラーから順に対応する。

(2)バグパッチを当てるたびに、購入エラー数が半減した。

(3)現在は、外部システム要因を除き、ほぼエラーが発生しない。

58



成功（青）　失敗（赤）　ユーザ起因（他）

59

この日はエラーが0件でした！


Mission 2

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


Mission 3

大量アクセスを捌ききれ！


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

問題点の確認(1) TV放送などで大量アクセスがあると、レスポンスが悪化し、システムがダウンする。

(2) TV放送前にはAPサーバの台数を増やしているが、捌ききれない。

(3)例のストアドプロシージャが、やはりネックになっている。

62


Mission 3 : 大量アクセスを捌ききれ！問題解決へのアプローチ(1)同時アクセス数制限の強化

• APサーバごとに、検索処理の同時リクエスト数が一定数を超えたら、503エラーページを表示。

(2)検索結果のキャッシング＆同時検索数を制限• APサーバごとに、重いストアドプロシージャの同時実行数を制限。

• 単なる順番待ちにならないよう、後続の処理は、検索結果のキャッシュを利用。 →一定の成果は出たが、根本解決はしない。

63



64

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



65

ん・・・？



66

←スケールアウト

システム構成

↑こいつが重い



67

　DBがボトルネックなのになんでAPサーバを

スケールアウトするの？



68

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



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

69


Mission 3

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


このシステムの今後


このシステムの今後将来的なロードマップ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トラブルシューティング！...

Travel