負荷試験入門 - Speaker Deck

Slide 1

Slide 1 text

負荷試験入門 2018.4.15 #インフラ勉強会 @morix1500

Slide 2

Slide 2 text

じこしょうかい・@morix1500 ・2010/04～2016/05 Webアプリエンジニア・2016/05～2018/03 インフラエンジニア・2018/04～ SRE?

Slide 3

Slide 3 text

あじぇんだ・負荷試験とは？・負荷試験の目的・性能の指標について・負荷試験の方法・負荷試験ツールの紹介・TIPS

Slide 4

Slide 4 text

負荷試験とは？

Slide 5

Slide 5 text

負荷試験とはシステムが実際の業務に耐えられる処理能力を持っているのかどうか検証するためのテスト。 ※これから話す内容は　・クラウド　・Webシステム　に対してを想定している

Slide 6

Slide 6 text

負荷試験の目的は？

Slide 7

Slide 7 text

負荷試験の目的は？・システムの応答性能を推測する・高負荷時におけるシステムの性能改善を行う・目的の性能を達成するために必要なハードウェアをあらかじめ選定する・システムがスケール性を持つことを確認する・システムのスケール特性を把握する

Slide 8

Slide 8 text

システムの応答性能を推測する以下のようなユースケースの場合のそれぞれに対して、システム全体の応答性能がどれくらいなのか推測する。・サービス利用開始直後にユーザが大量に登録される・キャンペーン告知などで急激にアクセス数が増えるなど

Slide 9

Slide 9 text

高負荷時におけるシステムの性能改善を行う高負荷時のシステムの挙動を検証しないと以下のような不具合を検出できない・応答速度の低下・システムのロック競合・データの不整合や破損など

Slide 10

Slide 10 text

目的の性能を達成するために必要なハードウェアをあらかじめ選定する最適なサーバースペックがわからないと… ・スペックが大きすぎる場合　・コスト・リソースの無駄・スペックが小さすぎる場合　・サービス障害といった問題が発生する。

Slide 11

Slide 11 text

システムがスケール性を持つことを確認する実際に高負荷になったときに、スケールアウト/アップをした場合本当に改善するのか確認する必要がある。

Slide 12

Slide 12 text

システムのスケール特性を把握するどこの部分を増強すれば性能が向上するのか　というのを知る必要がある。例えば、アクセスが増えて高負荷になったら・Webサーバーを増やせばいいのか？・DBをスペックアップすればいいのか？・それとも上記どっちも対応が必要なのか？

Slide 13

Slide 13 text

性能の指標について

Slide 14

Slide 14 text

性能の指標負荷試験では以下のような分類がある。・目標性能テスト　あらかじめ設定した目標のパフォーマンスが出せるか・限界性能テスト　どのくらいのパフォーマンスが出せるのか・ヒートラン　長期間（24時間とか)負荷をかけつづけても問題が起こらないか

Slide 15

Slide 15 text

指標以下の指標が、性能の目標とされることが多い・スループット・レイテンシ

Slide 16

Slide 16 text

スループット単位時間に処理を行う量のこと。 Webシステムでは「1秒間に処理を行うHTTPリクエストの数」を基準にすることが多い。 RPS(Request Per Second)と呼ぶ。「req/sec」と表記することも。

Slide 17

Slide 17 text

レイテンシ処理時間のこと。例えば、Webシステムでの1回のHTTPリクエストを送ってから返ってくるまでの時間のこと。

Slide 18

Slide 18 text

目標設定のやり方プロダクトによって異なるが、例えばニュースサイトのようなものであれば、以下のようなことをプロダクトの責任者にヒアリングする。・1日にどれくらいのユーザがアクセスするの？・1人あたり1日どれくらいアクセスすんの？・1日のアクセスに波はある？ピーク時は平均のどれくらいのアクセスある？

Slide 19

Slide 19 text

目標設定のやり方 DAU: 100万人平均アクセス数: 10回ピーク倍率: 3倍 100万人 * 10回 = 1000万回（1日の総アクセス数） 1000万回 / 86400（1日の秒数） = 平均115.7req/sec 11.6req/sec * 3倍 = 最大347.2req/sec

Slide 20

Slide 20 text

目標設定のやり方これで出た最大RPSに安全係数（2〜3）をかけた数字を性能目標とする。 347.2req/sec * 3 = 1041.6req/sec なので、ざっくりと「1000RPSを目標とする」これはシステム全体としてのスループットを目標としているサーバー1台の目標ではないので注意。

Slide 21

Slide 21 text

どうやって負荷試験するの？

Slide 22

Slide 22 text

どうやって負荷試験するの？ 0. 準備 1. 負荷試験ツールや環境の検証 2. フレームワークの検証 3. 参照系の検証 4. 更新系の検証 5. 外部サービス連携部分の検証 6. シナリオ試験 7.スケールアップ・アウトの検証 8.限界性能テスト 9.ヒートラン

Slide 23

Slide 23 text

0. 準備いろいろあります・プロダクトチームとの調整・負荷試験用環境構築・負荷試験ツールのセットアップ・シナリオの作成・関係各所への連絡

Slide 24

Slide 24 text

プロダクトチームとの調整負荷試験のシナリオを作らないといけないんだけど、インフラチームでやるのは難しいので、作ってもらわないといけない。いつまでにどういう試験がないといけないのか、その辺を調整する。またできれば負荷試験の時はプロダクトチームと一緒にやったほうがスムーズなので、その時間調整もする。

Slide 25

Slide 25 text

負荷試験用の環境構築本番想定のスペックでやるテストを行う必要があるため、負荷試験をするための環境を用意したほうがよい。

Slide 26

Slide 26 text

負荷試験ツールのセットアップ負荷試験ツールをセットアップする。先ほど用意した負荷試験用の環境と同じネットワークであること。

Slide 27

Slide 27 text

シナリオの作成/検証プロダクトチームが作ったシナリオが正しく動くのか検証する。自分たちで作る場合はシナリオを作る。またシナリオを動作させるためのDBデータなども用意する必要がある。

Slide 28

Slide 28 text

関係各所への連絡社内の共通システムを使っている場合は、そこに負荷をかけてしまうので事前に連絡して置く必要がある。 AWSの場合はリソース上限が色々あるので、その緩和設定を行う必要がある。

Slide 29

Slide 29 text

1.攻撃ツールや環境の検証まず攻撃ツールの実力を知る必要がある。 Webサーバーに適当なhtmlファイルを置いて、そこに対して負荷をかけるだけかけてみる。ここで思うような負荷が出ない場合は、攻撃ツールの設定やネットワークを疑ったほうがいい。

Slide 30

Slide 30 text

2.フレームワークの検証つづいて、採用しているフレームワークの実力を確認する。フレームワークの機能を利用して「Hello World」のアプリを作ってそれに対して負荷をかけてみる。ここでパフォーマンスがあまり出ない場合、フレームワークの設定を疑ってみる。

Slide 31

Slide 31 text

以後の試験をする際の注意点以後の試験でもそうだが、負荷をかける際はサーバーリソース（CPUやメモリなど）のどこかが逼迫するまで負荷を増やしてみる。サーバーリソースが逼迫する前に、スループットが頭打ちになってしまった場合、どこかの設定がおかしいため調査が必要。

Slide 32

Slide 32 text

3.参照系の検証ここからは実際のアプリへの負荷試験となる。任意の参照が発生するページに対して負荷をかけていく。 DBの参照がある場合、このタイミングでテストする。 DBの参照のみのテストであって、更新が含まれてるとボトルネックの切り分けがしづらいので注意。ここでパフォーマンスが出ない場合は、DBの接続方法や設定、SQLを疑う。

Slide 33

Slide 33 text

4.更新系の検証 DBの更新のテストを行う。ここでパフォーマンスが出ない場合は、DBの接続方法や設定、SQL、ロックを疑う。

Slide 34

Slide 34 text

5.外部サービス連携部分の検証外部のAPIに接続する部分をテストする。ただその外部のAPIへの負荷試験が難しい場合もあるので、その時はスタブサーバーを用意するなどする。ここでパフォーマンスが出ない場合は、その外部のAPIがボトルネックとなっていることがあるのでそのときは構わず次に進む。

Slide 35

Slide 35 text

6.シナリオ試験これまでは単体のページへの負荷試験だったが、ここからは実際のユースケースに基づいたシナリオを使用した負荷試験を行う。例えばこんなシナリオ 1. ユーザ登録 2. ログイン 3. 商品検索 4. 商品購入

Slide 36

Slide 36 text

6.シナリオ試験今までの負荷試験の結果と比較して、著しくスループット・レイテンシが悪化してなければOK。ここでは性能指標の確認も大事ではあるが、負荷試験を行なった結果、データが不整合を起こしていないかも確認していく。

Slide 37

Slide 37 text

7.スケールアップ・アウトの検証これまでの試験を、サーバーリソースが逼迫するまで負荷をかけて行う。そこで出たスループット・レイテンシが、スケールアップ・アウトによって改善されるか検証を行う。

Slide 38

Slide 38 text

8.限界性能テスト攻撃サーバーを増やし、サーバーのスケールアップ・アウトを行い続けどのくらいのスループットが出せるかをテストする。本当の限界までやらなくても、十分な性能が出ていればそこでやめてかまわない。

Slide 39

Slide 39 text

9.ヒートラン 24時間以上動作するシナリオを作成し、負荷をかけつづけてみる。メモリリークやデータ数増大後の挙動を見てみる。

Slide 40

Slide 40 text

負荷試験ツールの紹介

Slide 41

Slide 41 text

負荷試験ツールの紹介システムを利用する側の行動をシミュレーションし、対象のシステムを高負荷状態にするツール。主なツールとしては以下がある。・Apache Bench ・Apache JMeter ・Locust ・Gatling

Slide 42

Slide 42 text

Apache Bench 通称「ab」・単一のURLに対して簡単に負荷をかけられる・シナリオが書けない・そんなに高い負荷はかけられない・ちょっと負荷かけたいときに使える

Slide 43

Slide 43 text

Apache JMeter 負荷ツールの大定番「JMeter」・GUIでシナリオを作成できる・シナリオの実態はXML ・どんなパターンのシナリオも大抵作れる・大量の負荷をかけることができる・スケールアウトが簡単なためさらなる負荷をかけることができる・レポーティングもしてくれる・ドキュメントが豊富・XMLなのでソースコード管理ができない（しづらい）・ある種の職人芸が要求される・JMeter自身が重いのでうまく負荷をかけられないことも

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Locust Pythonでシナリオが書ける「Locust」・Pythonでシナリオが書ける・シナリオのソースコード管理ができる・大量の負荷をかけることができる・スケールアウトが簡単なためさらなる負荷をかけることができる・負荷をかけるトリガーはGUI（Web）で行う・GUI(Web)にレポーティングを表示してくれる・Pythonを書ける必要がある・ドキュメントが少ない

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

Gatling Scalaでシナリオがかける「Gatling」・Scalaでシナリオが書ける・シナリオのソースコード管理ができる・大量の負荷をかけることができる・レポートがHTMLで出力される・負荷をかけるトリガーはCUIで行う・スケールアウトできない(しづらい) ・Scalaを書ける必要がある・ドキュメントが少ない

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

TIPS

Slide 50

Slide 50 text

開発スケジュールに負荷試験は必ず入れるべき開発スケジュールに、負荷試験が入っていないことが多いです。というか負荷試験をやる習慣があるところもそんなにない印象。クラウド時代の昨今、スケールアップ・アウトは容易な時代です。当然負荷に応じたスケール性は持ち合わせているべきで、立派な非機能要件です。システムが落ちればユーザからの信用度が下がります。そのテストをしないで出すのは大変な暴挙です。負荷試験の必要性をマネジメント層に説き、必ずスケジュールに入れてもらいましょう。

Slide 51

Slide 51 text

予算にも負荷試験を想定して負荷試験は本番想定のスペックやトラフィックを出すため、少なくない額のお金がかかります。事前に本番想定のスペック・台数を見積もり、偉い人に伝えましょう。

Slide 52

Slide 52 text

エビデンスを残そうせっかく負荷試験をやったのに、その試験の結果をどこにも残さない　という不可解な現象も度々見てます。ちゃんとやったことを示すエビデンスを残しましょう。その際に必要になる情報はこんな感じ。・目標性能に対しての結果・限界性能がどれくらいだったか・システムのスケール特性・負荷試験実施時のおおざっぱなシナリオ・負荷試験実施時のサーバーリソースのメトリクス・負荷試験時に出た問題と対処法

Slide 53

Slide 53 text

障害リハを負荷テスト中にやるといい直接は負荷試験と関係ないですが、せっかく大量の負荷をかけ、ユーザシミュレートしたシナリオがあるのですから、ちょうどいいので障害リハーサルに利用しましょう。例えば、DBのフェイルオーバー機能があるとして実際にフェイルオーバーが走ったらシステムもちゃんとそれに追従できるのか？ Readerに書き込みをし続けたりしないかというのをチェックします。そんな感じで障害時に発生する現象をチェックして見ると色々見えてくるものがあるのでおすすめです。

Slide 54

Slide 54 text

まとめ負荷試験やっていこう

Slide 55

Slide 55 text

こちらの書籍をぜひぜひお読みください Amazon Web Services 負荷試験入門 2017/09/23 発売仲川樽八，森下健　著今回の発表資料はこちらの書籍を大いに参考にさせていただきました。