2016年8月17日に開催されたskill wednesdayの時に発表した資料です。

1. 負荷テストについて
skill wednesday
2016.8.17

2. 自己紹介
なまえ: 石田尭大
おしごと: サーバーサイド
好きなもの: 酒, 音楽
好きな言語: Ruby, Python, PHP etc…
(まあ何か動的なやつ)
(でもelixirいいよね。
最近全然書いてないけど)

3. 負荷テストについて
※HTTP APIを中心に話します

4. …そもそも何で負荷テストをするの？

5. Web(に限らずですが)アプリケーションが直面する問題
・運用開始したは良いけれども、思うような性能が出ていない
(大してユーザー居ないのに全然アクセス捌けない！！！)
・ユーザーが順調に集まって開始早々サーバーがヒーヒー言っている
(性能上限が分かっていなかった！)

6. チューニングの必要性のため
つまるところ…

7. 最終的にはこのようなサイクルを回したい
テストの実施
ボトルネックを推測
改善施策を実施

8. でも負荷テストって何すればいいんだ？

9. そもそも負荷テストにはどのような種類があるのか
基礎テスト : システムの負荷特性を調べるための基本的なテスト
ストレステスト : システムの限界値を探るためのテスト
ピークロードテスト : 高負荷時を想定したテスト
スパイクテスト : メディア露出など、瞬間的なアクセス発生と発生後を想定したテスト
耐久テスト : 長時間の稼働を想定したテスト

10. 知りたいことはなんだろう

11. 負荷テストを行う上で最低限知りたい事
スループット : 単位時間あたりに処理出来るデータ量
レスポンスタイム : 処理要求に対してシステムが応答するまでに掛かる時間
リソース使用量 : メモリ・CPU・ネットワーク使用量

12. こんな感じの図で表現したい

13. この図を得るため以下を実施
5分間、エンドポイントに対して、リクエストを発生させて負荷を掛ける
このテストを10クライアントずつ数を変化させて、グラフを生成するのに必要な分計測を
実施
基礎テスト+ストレステストのような感じ

14. テストするAPIを選別
本来は全てやるべきであるが、
コードと設計書から重要なAPIを選別してテスト対象に

15. 計測に使用したツール
cURL
dstat
(pm2-interface)
テストツール。pythonでシナリオ作成可能
レスポンスタイムをlogに出力するために使用。
リソース使用量をlogに出力するために使用。
プロセス自体のリソース使用量を logに出力するために使用。
計測自体はスクリプトを書いて、半自動実行できるように

16. データを整理して図が得られた！

17. ここで結果をダラダラ並べても面白くはないので…

18. ボトルネックについて考えてみる

19. ボトルネックと言っても多岐に渡る
DBネック
ネットワークネック
CPUネック
ディスクネック(I/Oネック)
etc...

20. どこが問題なのか切り分ける
DBのCPU Utilizationが高騰していないか
SQL実行数が予想以上に多くないか
不要なデーター読み出しをしていないか
キャッシュを利用出来ているか

21. ここの部分で何が起きているか考える
※GETパラメータに応じてデーターを DBから持ってきてJSONにして返す処理

22. 問題の切り分け
RDSのCPU Utilizationは最大でも11%
Network Trafficも20Mbps程度
APサーバー内部で、ディスクに書くような処理は無い
(dstatで見てもioの読み書きは発生していない)
APサーバーのCPU Utilizationが50%
CPUネックの疑いが大！！！

23. CPUネックと分かったら
サーバー側コードでの該当部分を見る
処理内容精査
冗長な部分が有れば修正
これ以上修正出来なければサーバーの
台数を増やせないか検討
再度負荷テスト

24. 結論
・ボトルネックの箇所は処理内容で全然異なる
・吐き出されるログが全て物語っているので、頭を回して読み取る

25. ご清聴ありがとうございました