概要
負荷試験のノウハウについてまとめられた教材って少ないですよね。
Amazon Web Service負荷試験入門という書籍がクラウドアプリケーションの負荷試験ノウハウについて整理されており非常に参考になります。(2~3周読みました。)
この書籍を読んで、今後参考にしたい、注意したいと感じた点を激選してまとめます。
メモ
- 負荷試験の指標の目標値の定め方
負荷試験の指標としては①スループット、②レイテンシの２つが一般的かと思いますが、具体的な事例を元にそれぞれの値の定め方が記載されております。
①スループット：1日の利用者数、一人あたりの1日の平均アクセス数、1日の平均アクセスに対するピーク時の倍率、の3つから最大rps(回/秒)を算出されています。
②レイテンシ：「各APIエンドポイントのレスポンスが〇ms以下」のような目標値が設定されています。〇は適切な値の判断が難しいですが、本書を読んだ感じでは長くても200ms以下が望ましいような印象でした。 - 負荷試験シナリオの決め方
クラウド時代の負荷試験の目的は 「システムのスケール性を確認すること」 であるため、シナリオはユーザー導線を完全に再現したものである必要はないとされています。(そもそもユーザー導線の完全再現は困難)
「アクセス頻度の高いページ」や「DB参照・更新を伴うページ」などの負荷試験シナリオに取り入れるべきページを網羅できていれば、具体的なシナリオの内容自体は問題ないということです。 -
全体に対して一度に負荷試験を実施すべきではない
いきなりシナリオ試験から実施すべきではないという内容です。いきなりシナリオ試験から実施すると、根本のボトルネックがどこなのかわからなくなってしまい、性能の改善が難しくなってしまうためです。
本書では、9つのステップで負荷試験を進めており、実際にシナリオ試験を実施するのはステップ6です。ステップ5までは負荷試験ツールや環境の検証、DB関連の性能検証・・・のように、ボトルネックとなり得る箇所をパーツ単位で試験していきます。これにより、各条件下での最大の性能値を確認しながら負荷試験を進めることができます。前のステップに比べて著しく性能の低下が見られた場合やボトルネックが作り出せない状態になった場合は、現在のステップに何か改善すべき点が隠れているということになります。
なお本書では、良い負荷試験の条件として 「ボトルネックがどこなのか特定できている」 が挙げられています。
「ボトルネックがどこなのか特定できている」を満たしていれば、必ずしも9つ全てのステップを実施する必要はないのだと思います。 - 試験対象に負荷が集中していること
「試験対象システムに負荷が集中していること」 も良い負荷試験の条件として挙げられています。評価する必要のない外部連携サービスや周辺システムがボトルネックとなってしまって、肝心な試験対象に十分な負荷がかかっていない状態はNGだということです。(前述の「ボトルネックがどこなのか特定できている」が達成できなくなる)
試験対象システムに負荷を集中させるためには一部本番環境と異なる構成にするという選択もアリだとされています。 - 負荷試験ツールの攻撃クライアント数は多すぎても少なすぎてもNG
少なすぎる場合は試験対象に十分な負荷がかからずボトルネックを作り出すことができないためNGだというのは想像がつきます。(前述の「ボトルネックがどこなのか特定できている」が満たせない)
一方で多すぎる場合は、レイテンシが正しく測定できなくなる場合があります。実際に処理にかかる時間に加えて、処理に入るまでの順番待ちの時間がレイテンシに加算されてしまうためです。
攻撃クライアント数を徐々に増やしながら、「ボトルネックを作り出せており十分なスループットも観測できている、かつレイテンシの急激な悪化も見られない」クライアント数を見極める必要があります。 - New Relic便利そう
本書の中で負荷試験のケーススタディの章があり、New Relicが解析ツールとして使われています。New Relicでは1つのWebアクセスをTransactionと呼び、各Transactionの時間消費の内訳が確認できます。例えば外部APIへのアクセスでどれくらいかかっているとか、DB周りの処理でどれくらいかかっているのか、といったことがビジュアルで確認できます。これは負荷試験でボトルネックを分析する際に大いに役立ちそうです。
最後に
本書の中で 「負荷試験は卓球のラリーである」 というコラムがあり、この説明が負荷試験の概念を理解する上で非常にわかりやすかったです。
また本書ではJMeterの使い方についてかなり詳しくまとめられていますが、個人的にはk6が非常に使いやすいと感じています。後日記事でまとめたいと思います。