Upgrade to Pro — share decks privately, control downloads, hide ads and more …

負荷試験入門

Morix
April 17, 2018

 負荷試験入門

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

Morix

April 17, 2018
Tweet

More Decks by Morix

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. 負荷試験とは?

    View Slide

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

    View Slide

  6. 負荷試験の目的は?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  13. 性能の指標について

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  21. どうやって
    負荷試験するの?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. 負荷試験ツールの紹介

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  44. View Slide

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

    View Slide

  46. View Slide

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

    View Slide

  48. View Slide

  49. TIPS

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide