負荷試験入門

2018/04/15 #インフラ勉強会

Transcript

1. 負荷試験入門 2018.4.15 #インフラ勉強会 @morix1500
2. じこしょうかい ・@morix1500 ・2010/04～2016/05 Webアプリエンジニア ・2016/05～2018/03 インフラエンジニア ・2018/04～ SRE?
3. あじぇんだ ・負荷試験とは？ ・負荷試験の目的 ・性能の指標について ・負荷試験の方法 ・負荷試験ツールの紹介 ・TIPS
4. 負荷試験とは？
5. 負荷試験とは システムが実際の業務に耐えられる処理能力を持っているのか どうか検証するためのテスト。 ※これから話す内容は 　・クラウド 　・Webシステム　に対してを想定している
6. 負荷試験の目的は？
7. 負荷試験の目的は？ ・システムの応答性能を推測する ・高負荷時におけるシステムの性能改善を行う ・目的の性能を達成するために必要なハードウェアをあらかじめ 選定する ・システムがスケール性を持つことを確認する ・システムのスケール特性を把握する
8. システムの応答性能を推測する 以下のようなユースケースの場合のそれぞれに対して、 システム全体の応答性能がどれくらいなのか推測する。 ・サービス利用開始直後にユーザが大量に登録される ・キャンペーン告知などで急激にアクセス数が増える など
9. 高負荷時におけるシステムの性能改善を行う 高負荷時のシステムの挙動を検証しないと 以下のような不具合を検出できない ・応答速度の低下 ・システムのロック競合 ・データの不整合や破損 など
10. 目的の性能を達成するために必要なハードウェアを あらかじめ選定する 最適なサーバースペックがわからないと… ・スペックが大きすぎる場合 　・コスト・リソースの無駄 ・スペックが小さすぎる場合 　・サービス障害 といった問題が発生する。
11. システムがスケール性を持つことを確認する 実際に高負荷になったときに、 スケールアウト/アップをした場合 本当に改善するのか確認する必要がある。
12. システムのスケール特性を把握する どこの部分を増強すれば性能が向上するのか　というのを知る必 要がある。 例えば、アクセスが増えて高負荷になったら ・Webサーバーを増やせばいいのか？ ・DBをスペックアップすればいいのか？ ・それとも上記どっちも対応が必要なのか？
13. 性能の指標について
14. 性能の指標 負荷試験では以下のような分類がある。 ・目標性能テスト 　あらかじめ設定した目標のパフォーマンスが出せるか ・限界性能テスト 　どのくらいのパフォーマンスが出せるのか ・ヒートラン 　長期間（24時間とか)負荷をかけつづけても問題が起こらないか
15. 指標 以下の指標が、性能の目標とされることが多い ・スループット ・レイテンシ
16. スループット 単位時間に処理を行う量のこと。 Webシステムでは「1秒間に処理を行うHTTPリクエストの数」を基 準にすることが多い。 RPS(Request Per Second)と呼ぶ。「req/sec」と表記することも。
17. レイテンシ 処理時間のこと。 例えば、Webシステムでの1回のHTTPリクエストを送ってから返っ てくるまでの時間のこと。
18. 目標設定のやり方 プロダクトによって異なるが、例えばニュースサイトのようなもので あれば、以下のようなことをプロダクトの責任者にヒアリングする。 ・1日にどれくらいのユーザがアクセスするの？ ・1人あたり1日どれくらいアクセスすんの？ ・1日のアクセスに波はある？ピーク時は平均のどれくらいのアク セスある？
19. 目標設定のやり方 DAU: 100万人 平均アクセス数: 10回 ピーク倍率: 3倍 100万人 * 10回 = 1000万回（1日の総アクセス数） 1000万回 / 86400（1日の秒数） = 平均115.7req/sec 11.6req/sec * 3倍 = 最大347.2req/sec
20. 目標設定のやり方 これで出た最大RPSに安全係数（2〜3）をかけた数字を性能目標 とする。 347.2req/sec * 3 = 1041.6req/sec なので、ざっくりと「1000RPSを目標とする」 これはシステム全体としてのスループットを目標としているサー バー1台の目標ではないので注意。
21. どうやって 負荷試験するの？
22. どうやって負荷試験するの？ 0. 準備 1. 負荷試験ツールや環境の検証 2. フレームワークの検証 3. 参照系の検証 4. 更新系の検証 5. 外部サービス連携部分の検証 6. シナリオ試験 7.スケールアップ・アウトの検証 8.限界性能テスト 9.ヒートラン
23. 0. 準備 いろいろあります ・プロダクトチームとの調整 ・負荷試験用環境構築 ・負荷試験ツールのセットアップ ・シナリオの作成 ・関係各所への連絡
24. プロダクトチームとの調整 負荷試験のシナリオを作らないといけないんだけど、 インフラチームでやるのは難しいので、作ってもらわないといけない。 いつまでにどういう試験がないといけないのか、その辺を調整する。 またできれば負荷試験の時はプロダクトチームと一緒にやったほうがス ムーズなので、その時間調整もする。
25. 負荷試験用の環境構築 本番想定のスペックでやるテストを行う必要があるため、 負荷試験をするための環境を用意したほうがよい。
26. 負荷試験ツールのセットアップ 負荷試験ツールをセットアップする。 先ほど用意した負荷試験用の環境と同じネットワークであること。
27. シナリオの作成/検証 プロダクトチームが作ったシナリオが正しく動くのか検証する。 自分たちで作る場合はシナリオを作る。 またシナリオを動作させるためのDBデータなども用意する必要が ある。
28. 関係各所への連絡 社内の共通システムを使っている場合は、 そこに負荷をかけてしまうので事前に連絡して置く必要がある。 AWSの場合はリソース上限が色々あるので、 その緩和設定を行う必要がある。
29. 1.攻撃ツールや環境の検証 まず攻撃ツールの実力を知る必要がある。 Webサーバーに適当なhtmlファイルを置いて、そこに対して負荷を かけるだけかけてみる。 ここで思うような負荷が出ない場合は、攻撃ツールの設定やネット ワークを疑ったほうがいい。
30. 2.フレームワークの検証 つづいて、採用しているフレームワークの実力を確認する。 フレームワークの機能を利用して「Hello World」のアプリを作ってそれに 対して負荷をかけてみる。 ここでパフォーマンスがあまり出ない場合、フレームワークの設定を疑っ てみる。
31. 以後の試験をする際の注意点 以後の試験でもそうだが、 負荷をかける際はサーバーリソース（CPUやメモリなど）の どこかが逼迫するまで負荷を増やしてみる。 サーバーリソースが逼迫する前に、スループットが頭打ちになってしまっ た場合、どこかの設定がおかしいため調査が必要。
32. 3.参照系の検証 ここからは実際のアプリへの負荷試験となる。 任意の参照が発生するページに対して負荷をかけていく。 DBの参照がある場合、このタイミングでテストする。 DBの参照のみのテストであって、更新が含まれてるとボトルネックの切 り分けがしづらいので注意。 ここでパフォーマンスが出ない場合は、DBの接続方法や設定、SQLを 疑う。
33. 4.更新系の検証 DBの更新のテストを行う。 ここでパフォーマンスが出ない場合は、DBの接続方法や設定、SQL、 ロックを疑う。
34. 5.外部サービス連携部分の検証 外部のAPIに接続する部分をテストする。 ただその外部のAPIへの負荷試験が難しい場合もあるので、その時は スタブサーバーを用意するなどする。 ここでパフォーマンスが出ない場合は、その外部のAPIがボトルネックと なっていることがあるので そのときは構わず次に進む。
35. 6.シナリオ試験 これまでは単体のページへの負荷試験だったが、 ここからは実際のユースケースに基づいたシナリオを使用した負荷試験 を行う。 例えばこんなシナリオ 1. ユーザ登録 2. ログイン 3. 商品検索 4. 商品購入
36. 6.シナリオ試験 今までの負荷試験の結果と比較して、著しくスループット・レイテンシが 悪化してなければOK。 ここでは性能指標の確認も大事ではあるが、負荷試験を行なった結果、 データが不整合を起こしていないかも確認していく。
37. 7.スケールアップ・アウトの検証 これまでの試験を、サーバーリソースが逼迫するまで負荷をかけ て行う。 そこで出たスループット・レイテンシが、スケールアップ・アウトに よって改善されるか検証を行う。
38. 8.限界性能テスト 攻撃サーバーを増やし、サーバーのスケールアップ・アウトを行い 続け どのくらいのスループットが出せるかをテストする。 本当の限界までやらなくても、十分な性能が出ていればそこでや めてかまわない。
39. 9.ヒートラン 24時間以上動作するシナリオを作成し、負荷をかけつづけてみ る。 メモリリークやデータ数増大後の挙動を見てみる。
40. 負荷試験ツールの紹介
41. 負荷試験ツールの紹介 システムを利用する側の行動をシミュレーションし、対象のシステ ムを高負荷状態にするツール。 主なツールとしては以下がある。 ・Apache Bench ・Apache JMeter ・Locust ・Gatling
42. Apache Bench 通称「ab」 ・単一のURLに対して簡単に負荷をかけられる ・シナリオが書けない ・そんなに高い負荷はかけられない ・ちょっと負荷かけたいときに使える
43. Apache JMeter 負荷ツールの大定番「JMeter」 ・GUIでシナリオを作成できる ・シナリオの実態はXML ・どんなパターンのシナリオも大抵作れる ・大量の負荷をかけることができる ・スケールアウトが簡単なためさらなる負荷をかけることができる ・レポーティングもしてくれる ・ドキュメントが豊富 ・XMLなのでソースコード管理ができない（しづらい） ・ある種の職人芸が要求される ・JMeter自身が重いのでうまく負荷をかけられないことも
45. Locust Pythonでシナリオが書ける「Locust」 ・Pythonでシナリオが書ける ・シナリオのソースコード管理ができる ・大量の負荷をかけることができる ・スケールアウトが簡単なためさらなる負荷をかけることができる ・負荷をかけるトリガーはGUI（Web）で行う ・GUI(Web)にレポーティングを表示してくれる ・Pythonを書ける必要がある ・ドキュメントが少ない
47. Gatling Scalaでシナリオがかける「Gatling」 ・Scalaでシナリオが書ける ・シナリオのソースコード管理ができる ・大量の負荷をかけることができる ・レポートがHTMLで出力される ・負荷をかけるトリガーはCUIで行う ・スケールアウトできない(しづらい) ・Scalaを書ける必要がある ・ドキュメントが少ない
49. TIPS
50. 開発スケジュールに負荷試験は必ず入れるべき 開発スケジュールに、負荷試験が入っていないことが多いです。 というか負荷試験をやる習慣があるところもそんなにない印象。 クラウド時代の昨今、スケールアップ・アウトは容易な時代です。 当然負荷に応じたスケール性は持ち合わせているべきで、立派な非機能要件 です。 システムが落ちればユーザからの信用度が下がります。 そのテストをしないで出すのは大変な暴挙です。 負荷試験の必要性をマネジメント層に説き、必ずスケジュールに入れてもらい ましょう。
51. 予算にも負荷試験を想定して 負荷試験は本番想定のスペックやトラフィックを出すため、少なくない額のお金 がかかります。 事前に本番想定のスペック・台数を見積もり、偉い人に伝えましょう。
52. エビデンスを残そう せっかく負荷試験をやったのに、その試験の結果をどこにも残さない　という不 可解な現象も度々見てます。 ちゃんとやったことを示すエビデンスを残しましょう。 その際に必要になる情報はこんな感じ。 ・目標性能に対しての結果 ・限界性能がどれくらいだったか ・システムのスケール特性 ・負荷試験実施時のおおざっぱなシナリオ ・負荷試験実施時のサーバーリソースのメトリクス ・負荷試験時に出た問題と対処法
53. 障害リハを負荷テスト中にやるといい 直接は負荷試験と関係ないですが、 せっかく大量の負荷をかけ、ユーザシミュレートしたシナリオがあるのですか ら、ちょうどいいので障害リハーサルに利用しましょう。 例えば、DBのフェイルオーバー機能があるとして 実際にフェイルオーバーが走ったらシステムもちゃんとそれに追従できるの か？ Readerに書き込みをし続けたりしないかというのをチェックします。 そんな感じで障害時に発生する現象をチェックして見ると色々見えてくるものが あるのでおすすめです。
54. まとめ 負荷試験やっていこう
55. こちらの書籍をぜひぜひお読みください Amazon Web Services 負荷試験入門 2017/09/23 発売 仲川樽八，森下健　著 今回の発表資料は こちらの書籍を大いに参考にさせて いただきました。