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