shimadama
4/5/2019 - 1:06 PM
負荷試験コトハジメ
負荷試験コトハジメ
#############################
負荷試験コトハジメ
#############################
:更新: 2019-04-05
:作者: @voluntas
:バージョン: 19.04.4
:URL: https://voluntas.github.io/
.. image:: https://img.shields.io/badge/License-CC%20BY--NC--ND%204.0-lightgrey.svg
:target: https://creativecommons.org/licenses/by-nc-nd/4.0/
**この記事が良いと思ったらこの記事に Star をお願いします。**
概要
====
ミドルウェアを開発するのが仕事ということもあり、負荷試験がとても身近な存在です。たまにですが仕事で負荷試験を依頼されたりもします。
ただ負荷試験は条件や環境にとても依存するということもあり、あまり一般化できません。
そこで特定の条件下での負荷試験について、自分なりに書いていきます。
特定のツールの話はしません。負荷試験を実際にやるにあたっての方針について書いていきます。
著者
====
時雨堂という零細企業で WebRTC や QUIC とかを利用したミドルウェアを開発しています。
`FGO を支える負荷試験ツール – shiguredo – Medium <https://medium.com/shiguredo/fgo-%E3%81%AB%E6%8E%A1%E7%94%A8%E3%81%95%E3%82%8C%E3%81%9F%E8%B2%A0%E8%8D%B7%E8%A9%A6%E9%A8%93%E3%83%84%E3%83%BC%E3%83%AB-2fa3de337e20>`_
前提
====
- 負荷をかける先は HTTP/1.1 API
- ボディは JSON
間違い
======
- とりあえず負荷試験をやろうとする
- 負荷試験が本当に必要なのかを確認する
- どんなに多くても分 1 リクエストもこないサービスに負荷試験は不要です
- 独自でツールを作り始める
- すでにあるツールを使え
- いきなり難しいことをやろうとする
- 負荷試験は徐々に難しいことをやっていくべき
- 独自でメトリクスを頑張ろうとする
- すでにあるツールを使え
- 負荷試験先のサーバスペックをケチる
- スペック厳しいのに負荷かけてもなんの意味もない
- 負荷試験クライアントのサーバスペックをケチる
- 普通負荷試験はクライアントがボトルネックになるのでケチるな
- サーバ側の HTTPS を外さない
- 外して問題ない、HTTPS を有効にするとクライアントの負荷が高くなる
- ついでに機能試験をやろうとする
- 負荷試験のみに絞れ
- ついでに E2E 試験をやろうとする
- 負荷試験のみに絞れ
フェーズ 0
==========
- 負荷試験ツールを理解する
- 負荷試験ツール自体に詳しくないと負荷試験がボトルネックになる可能性を推測しにくいです
- 殆どの場合で負荷試験ツールがボトルネックになります
- 負荷をかけるサービスの仕組みを理解する
- どこが重そうとかのヒアリングをするべきです
- API や仕様のドキュメントがなければ作る
- よくわからない相手には負荷をかけるのは難しいです
フェーズ 1
==========
- 異常系はやらず正常系のみにする
- クライアントは 1 つで、それを繰り返し実行する試験をする
- 指定する API も一つ
- 認証は外す
- 外せないならがんばる
- HTTPS は外す
- 絶対外す
一番シンプルで簡単な負荷試験をやるべきです。いきなり難しいことをやるとはまります。
まずは特定の API をしつこく叩き続けるのがおすすめです。特にデータベースのアクセスがおもそうな API を狙い撃ちして行きましょう。
問題がでなければ、他の重そうな API に対して負荷をかけていきましょう。
フェーズ 2
==========
- 異常系はやらず正常系のみにする
- クライアント増やして、それを繰り返し実行する試験をする
- 指定する API も一つ
- 認証は入れる
- HTTPS は外す
- 絶対外す
フェーズ 2 はフェーズ 1 でやった試験を並列にしていくというものです。クライアントが異なることを実現するために、認証が必須になります。
やることはクライアントをまずは 2 にして負荷をかけることです。それで問題が出なければクライアントを増やしていきましょう。
おそらくですがクライアントが 1000 くらいになったとき、クライアントかサーバのどちらかがうまく動かなくなることが多いです。 すぐにファイルディスクリプタの数をチェックしてください、数を増やしましょう。
フェーズ 3
==========
- 異常系はやらず正常系のみにする
- クライアント増やして、シナリオベースで API を叩く
- 認証は入れる
- HTTPS は外す
- 絶対外す
フェーズ 2 まで負荷試験は十分な事が多いです。フェーズ 3 はシナリオベースの負荷試験になります。そのシステムのよくあるパターンで実際に負荷をかけるというものです。
これはツールを選ぶことが多いので、このタイミングでツールを変更してもいいと思います。
シナリオは仕様を守って実装しましょう。イレギュラーケースはまだこの段階では不要です。徹底的に正常系にこだわってください。
フェーズ 4
==========
**ここまでやれる会社はとても少ない**
- 異常系のみに絞る
- クライアント増やして、シナリオベースで API を叩く
- 認証は入れる
- HTTPS は外す
- 絶対外す
異常系の負荷試験です。つまり **想定外** の API 実行で負荷をかけます。想定外を実現するためには想定内を理解しておく必要があるため、相当仕様を読み込んでください。
フェーズ 5
==========
**ここまでやれたら本当に素晴らしい**
- 実機同様の動作をする仕組みを用意する
- HTTPS は外す
- 絶対外す
貴方が考えた最高の負荷試験ツールを自作してください。経験から言わせてもらうと大変辛いのでがんばってください。
よくある
========
- JSON がデブすぎて重い
- JSON パースコストはそこそこあります
- レポートを出せと言われる
- がんばりましょう
- HTTPS が重い
- がんばりましょう
おすすめ
========
- 継続的に負荷試験を行える仕組みを作る
- コードや構成を変更したタイミングで負荷試験をかけるのはとても効果的です
- フェーズ 2 まででいいので大きな変更があったらできるだけ負荷試験を行うのが良いです
- 書籍
- `Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかる Software Design plus | 仲川 樽八, 森下 健 | 工学 | Kindleストア | Amazon <https://www.amazon.co.jp/dp/B075SV3VN3>`_
- AWS と書いてありますが、前半は一般的な話なのでとても参考になります
- 資料
- `負荷試験入門公開資料 201611 <https://www.slideshare.net/taruhachi/201611-69516073>`_
- Amazon Web Services 負荷試験入門の著者の方が書かれた資料でとてもわかりやすいです
- `失敗事例で学ぶ負荷試験 <https://www.slideshare.net/taruhachi/ss-82020794>`_
- Amazon Web Services 負荷試験入門の著者の方が書かれた資料でなぜ HTTPS を外したほうがいいのか書かれています
- `The Guide to Load Test gRPC Application - Speaker Deck <https://speakerdeck.com/kenju/the-guide-to-load-test-grpc-application>`_
- HTTP/2 をベースにした gRPC の負荷試験ガイドで、いかに統計を取るかが書かれています
まとめ
======
負荷試験はまずやることが重要です。きっちりやる、しっかりやるではなくやることが重要です。やり始めたら徐々にフェーズを進めます。そして継続的にやってください。単発の負荷試験はやった瞬間のなんとなくの安心感を得られるだけでほぼ役に立ちません。
継続的に負荷試験ができるようになってから、きっちり、しっかりを考え始めてください。
もし興味あれば、きっちりとしっかりを継続的にやる、自動負荷試験という最高の世界があるので是非チャレンジしてみてください。