Skip to content

Instantly share code, notes, and snippets.

@hykw

hykw/loadtest.rst

Forked from voluntas/loadtest.rst
Created June 9, 2022 07:26
Show Gist options
  • Save hykw/49a210af6001964ae7da4266da54cb9f to your computer and use it in GitHub Desktop.
Save hykw/49a210af6001964ae7da4266da54cb9f to your computer and use it in GitHub Desktop.
Download ZIP
負荷試験コトハジメ
Raw
loadtest.rst

負荷試験コトハジメ

更新:2021-05-23
作者:@voluntas
バージョン:2021.1
URL:https://voluntas.github.io/

この記事が良いと思ったらこの記事に Star をお願いします。

概要

ミドルウェアを開発するのが仕事ということもあり、負荷試験がとても身近な存在です。たまにですが仕事で負荷試験を依頼されたりもします。

ただ負荷試験は条件や環境にとても依存するということもあり、あまり一般化できません。 そこで特定の条件下での負荷試験について、自分なりに書いていきます。

特定のツールの話はしません。負荷試験を実際にやるにあたっての方針について書いていきます。

著者

時雨堂という零細企業で WebRTC を利用したミドルウェアを開発しています。

前提

  • 負荷をかける先は 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 が重い
    • がんばりましょう

おすすめ

まとめ

負荷試験はまずやることが重要です。きっちりやる、しっかりやるではなくやることが重要です。やり始めたら徐々にフェーズを進めます。そして継続的にやってください。単発の負荷試験はやった瞬間のなんとなくの安心感を得られるだけでほぼ役に立ちません。

継続的に負荷試験ができるようになってから、きっちり、しっかりを考え始めてください。

もし興味あれば、きっちりとしっかりを継続的にやる、自動負荷試験という最高の世界があるので是非チャレンジしてみてください。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment