実際に負荷試験を進めていくにあたって、何をどこまでやるのか、という問題があります。
まずなんとなく始めてしまうことも大事ですし、なんとなく納得いくまでやるってのもアリですが、その辺の考え方を整理してみます。
全体図
今回はこの辺。環境の用意はだいたいできて、ではどんな感じで進めていきましょうかって話。
まずは始めてしまう
前にも（リクエストの分類）触れましたが、まずは簡単なシナリオを作成し、その動作確認と、ユーザーセッションなどの基本部分の取り扱いの正常性を確認してしまうべきです。この土台を整えないうちに、長々とシナリオ作りに精を出しても、どうせ多くの調整を行うことになるので、まずは負荷試験という一連の流れを作ってしまいましょう。それと同時に、実際のアプリケーションをテスト環境で動かし、デバイスでアクセスもしてみます。試験者はアプリ開発者ではないとすると、さすがにログやデータだけで、アプリケーションの全容を掴むのは厳しいので、サービス現物を触って機能を把握しながら調整をしていくことになります。
文章で書くとたったこれだけですが、セッションを確立するにもデバッグ機能を流用できるか開発者に聞いたり、なければ負荷試験用のコードを書くこともあります。テスト環境を作るにも、ミドルウェアやフレームワーク等の理解が必要なので、慣れない環境条件だとやはり開発者とのコミュニケーションが重要になってきます。
ここまででも、腕やモノ次第で結構時間を取られます。なので、アプリケーション構造やプロトコル仕様、サーバー構築など、丸っとサービスを１つ面倒見れるくらいの技術が要求され、
プラス、それに擬似大量ユーザートラフィックや、課題あぶり出し、リソース量算出、と進んでいくので、エンジニアとしてはわりと総合力を試される良い機会になると思われます。
目標を大きくしすぎない
まれにやりがちなのが、提示された条件に対して、バカ正直に動作保証をしようとすることです。上層部に、ン十万ユーザーを想定していると言われて、それっぽい大きなサーバーリソースを用意して、それっぽい大きなトラフィックを発生させて、ハイOKです！ってヤツ。それでは、精度が低いどころか、肝心の動作保証すら怪しいモノになってしまいます。
（参考）
また、負荷試験はリリース前に行う事柄であるため、時間の余裕がそう多くありません。大きい目的に対して大きい試験ばかりしていると、雑な結果ばかりのまま、未達成で終わってしまうこともあります。
効率的に、精度を高く、締切に柔軟にと考えると──
小さく始めて、課題と目的を更新し、徐々に大きくしつつ、優先度で進行する── と、良好な結果を残せ、仮に全てをやりきれなくとも、重要部は済ませることができます。重要な順に８～９割でも済ませられれば、残り１割が未達でも、全体の負荷的な影響度としてはせいぜい数％だったりするので、内容と進行次第では細かい調査を切り捨てる判断も有効になります。
100個の調査対象があるとして、重要順に50個片付けたとしたら、その負荷影響度が50％ということはありえなく、ほぼ90％以上になっているはずです。残り50個も絶対にこなす必要がある業務もあるでしょうが、”負荷試験”は”負荷対策”が目的なので、その判断材料が十分であれば全ての調査が必要なわけではありません。
大きな目標ありきで進行するのではなく、小さく積み上げた結果、理論的に大きな目標を達成できるし、最終試験でも動作確認を取れました、という流れが望ましいと考えます。そして、時間の許す中で出した結果は精度が高く、手つかずになった残りカスの影響度は限りなく低いので問題ない、と割り切る判断も手札に入れておきましょう。
目的の基本
初心にかえって、負荷試験は何の目的で行うかを整理してみます。動作保証
ある特定の条件下で、ユーザートラフィックやバッチ処理などを捌ききれるか、を保証するために行います。項目としては見方が２つあり、最大同時接続ユーザー数や最大スループット（RPS = Requests per second や RPM）を主として、来るであろう予測トラフィックに対して、どのくらいのサーバー・リソースを用意すればよいかを保証する方向。
もう１つは、限定的なサーバー・リソースに対して、最大でどれほどのトラフィックまで捌くことができるのかを保証する方向です。
局所的にはどちらも使う考え方ですし、最終的には環境によって使う考えは異なります。
また、動作保証といっても、リソース量やアーキテクチャに基づく挙動が対象であり、アプリケーション仕様やデータ内容によって起きるエラーの有無を保証するものではない、としておきます。アプリケーションの機能テスト自体とは切り分けて取り組まないと、おそらく非効率な試験となってしまいます。
未来の推測
最終目標に対して段階的に結果を採取していくと、その値の変化から、目標のさらに先の条件を推測することができます。所々で障害やオーバーヘッドによって崩れることはありますが、基本的にリソース量とトラフィックは比例関係にあるので、いつか先のどこかで崩れるにせよ、推測自体は可能であるものです。想定トラフィックは所詮、想定でしかないので、いざ本番ではその２倍３倍になることは珍しくないですし、もっと言えば数ヶ月後・数年後と長い目で見れば、やはり数倍に成長することは見込まなくてはいけない事項です。
目標想定は保証しました。ではさらに数倍を考慮した場合、その時どのような対策で乗り切るのか、それとも今の時点で対策を仕込むなり構成を変更するなりが必要なのか。
サービスの成長は水物ですので、成長しなければ水の泡となりますが、いざという時に対応するよりも、今対応してしまう方がコスパが良いはずです。丁寧に進行すれば、そう難しい話でもないので、一歩二歩先を見据えた試験にしたいところです。
性能改善
提示された条件下での動作保証をしました、だけで試験を終わらせるのは勿体ありません。結果数値には、平均より悪い数値や、許容範囲より悪い数値が確認できるはずです。また、ある処理において速度が不規則だったり、一定以上のアクセスやデータ量によって重くなるなど、表面を撫でただけではわからないパターンもあります。仮に全てが許容範囲の数値だとしても、負荷試験１発目でそのアプリケーションがベストなチューニングであることは考えづらく、多少の改善を施すだけで、数割のパフォーマンス向上を見込めることがほとんどです。
重さが100のアプリを100のリソースで捌くのは最低限として、改善によって、重さを80にして80のリソースで動かすことで、費用を節約できます。リソースを減らさず軽くしただけでも、それだけ処理能力に猶予が生まれますし、単純に１レスポンスあたりが速くなればユーザー体感も良くなります。
全てをベストチューニングにすることは難しいので、どこまでやるかの判断は必要ですが、重要な処理から施すことで、少なくとも劣悪な処理をなくし、平均性能を上げることは多くのアプリで可能です。
目的の整理と判断
目的の基本を抑えつつ、ひとまずアプリケーションの散歩と簡単なシナリオ試験を済ませたとして、次に見据えるのは優先順位です。ひとつひとつ全ての処理を平均的に精査していくのではなく、アクセス頻度が高い箇所、ユーザー体感の影響が強い箇所、特にレスポンス速度が遅い箇所、に絞って優先的に片付けていきます。
優先的な箇所を整理し、その中でも調査しやすい箇所や、改善しやすい箇所から取り掛かります。数を減らせると、精神的に良いというのもありますが、１つ改善すれば芋づる式に治せる箇所があり、より一気に数を減らせるからです。
そういう意味では、影響度が多少低くとも、簡単に改善できる箇所があるなら、先に済ませてしまうのもアリです。
試験は時間の許す限り、優先順にやっていくわけですが、必ずしも時間切れや全箇所対応するまで続けることはありません。進行中に、ここまでやりきればOKラインってのが見えてきますし、OK判断者が別にいる場合、その基準の考えと擦り合わせていく必要があります。
最終的な結果として何を望まれるかは場合によりますが、想定条件に対してレスポンス速度・リソース量・費用、そして改善内容あたりをまとめていくとよいでしょう。そしてその数値が自他共に納得できればよく、それプラス未来の対応策もある程度提示しておくと、より万全な仕上がりとなります。
様々な環境と目的
おまけで、どのような環境での試験や目的があるのかを書いてみます。オンプレミス
クラウド時代の今でもオンプレ志向な企業はありますが、昔は全てがオンプレでした。オンプレの負荷試験は非常に難しく、理由としてはサーバー調達に２～６週間ほどかかるため、リリース時の想定外のトラフィックに対して緊急対応が不可能だったからです。試験が難しいというよりは、想定と算出結果の責任が重いと言った方がよいでしょうか。
負荷試験をするにも、本番で動かす想定のサーバーが手元にない。代替機を探して算出したり、購入予定のサーバーを先に１台借りて試すこともありました。
それでも昔はサービスリリース時の異常なトラフィックは発生しづらい時代だったため、なんとか誤魔化してやっていけた、というのもあります。
リリース時などあるタイミングで用意できるリソース量が限定的な場合、想定ユーザー数に対して必要なサーバーリソース量をバシッと算出する必要があります。もしくは、あまりないでしょうが、予算の許す限りのサーバーを準備してしまって、ン万ユーザーまで耐久可能である、と結論づけます。
まァどちらにせよリソース上限が確定している時点で不安で苦しいのは変わらなく、緊急対応＝アプリケーションの軽量化、という知恵と工夫で乗り切ることが多い時代でした。
そういう時代を乗り越えてくると、自然と高品質に仕上げるように腕が磨かれるのですが、増やせば対応できるヌルいクラウド時代だと磨く必要性が若干薄れるのも事実。しかし、負荷試験には品質改善も含むとすると、今でも腕前を磨く機会は十分にあるということになります。
クラウド
インスタンスタイプやリソース量を簡単に増減できるクラウドでは、負荷試験の意味が薄れるかと思いきや、むしろ本領発揮できると言えます。試験結果から、想定条件を捌くためのサーバーリソース量を算出して保証することは当然ですが、未来の推測や品質改善を手掛けることで、リソース増減の必要性を判明し、即座に反映して費用の最適化と負荷対策をすることが可能です。
試験も物理サーバーがなくとも、すぐに取りかかれるし、そのリソース量も自由自在で、瞬間的な利用にすれば費用もたいしてかかりません。
クラウドはオンプレより総合的に高いと言われることもありますが、リソースの自由度が高いがゆえに、時間も、費用も、結果の幅と精度も、工夫次第で非常に高い成果を残しやすいと言えるでしょう。
新規サービス
最近のサービス事情では、リリース直後にトラフィックが集まりやすく、その負荷に耐えきれず、数時間後に即メンテイン。酷いと数日・数週間と再開の目処が立たないこともあります。クラウド環境が前提だとしても、誰が負荷試験を担当したとしても、そういう大変な目に合うことはありえます。それは、本番に勝る負荷試験はないからです。当たり前のことですが、本番のトラフィックや同時接続数、データの蓄積や偏りを、ほぼ予測しきって負荷試験することは不可能です。
特に、トラフィックに耐えることを証明するだけの負荷試験と算出だけでは、そうなりやすいでしょう。必ずどこかが異常に悪化する箇所がある前提で負荷試験をし、その改善に着手しないと、リリース直後に悪化が表面化する可能性が高いです。
少しでも改善に着手していれば、そのアプリケーションの悪い手法のクセみたいのが判明するので、１つ見つかれば複数箇所を改善できることが多いです。少なくとも、試験者が見つけようとして見つかる箇所くらいは改善してしまわないと、リリース後の死は見えています。
それでも見つからない箇所は、メトリクス採取など監視システムを堅固にし、リリース後の数日から数週間は変化に敏感に反応して対応することになります。
増やせば対応できそうなクラウド環境だからこそ、負荷試験の基本目的をしっかり実施し、人事を尽くして天命を待ちつつも、天命（想定外トラフィックやデータ遷移）をシステムと判断力で抑え込む。負荷試験という手段を軸に、総合的な対応力を肉付けしていく、というのが正しい姿な気もします。
サービス移行
サービスを数年間と長いこと運用していると、オンプレ <=> クラウド や クラウド <=> クラウド 間で、サービスの移行をする機会がまぁまぁでてきます。こういう場合も負荷試験をするのですが、既にユーザー数やトラフィック遷移、データ量は判明しているので、新規サービスよりは簡単と言えるでしょう。
現在の環境でのリソース構成・量を元に、新環境でのリソースを構成し、本番バックアップをリストアして負荷試験をして、動作保証とリソース量の調整をすればいいだけです（たいてい*だけ*では終わりませんが…）。
また、数年間運用されたサービスは、新規機能の開発などで長く忙しくしてきたりするので、古い機能やデータに対して長く放置されていることも多いです。そういうサービスを改めて試験で全体を見通してみると、改善可能な箇所が多く見つかったりするので、移行ついで、もしくは移行前に改善案を提示して反映してもらうと、費用やユーザー体感に直結して良い移行を果たすことができます。
それと移行するとたいてい、CPUなどサーバー性能が上がるので、そういう面でもリソース量を減らせることが多いです。なので、移行後の必要リソース量を提示しつつ、費用がどれだけ変化する想定なのか、安くなるのかも提示すると、より移行作業の意味を強くできるので、成果にもモチベーションにも繋がります。
終わり
その負荷試験は何のために行うのか、を改めて問うと、意外とハッキリしていないことがあります。また、その成功と不足の境界線や、完全な終わりというのも案外曖昧なものだったりもします。それゆえ文章にしてみたわけですが、書いてて全然まとまってる気がしません。
全体を把握しつつ、重要な順に片付けていく。
これができれば、そうそう失敗に終わることはなさそうなのですが、それだけだと試験者の経験や感覚に依る所が大きいので、まだフィーリングの域を出ていない気もします。
身も蓋もないけど、やっぱ執刀をこなすしかねぇ:-)
