k6入門：負荷テストの種類について

今日は、負荷テストの種類 についてご紹介します。

背景

Dockerで構築したWebアプリの開発環境において、k6を利用した負荷テストについて調査したときの内容を備忘として残しました。

開発環境のソースは下記のリポジトリにあります。

概要

システムが負荷下にあると、多くの問題が発生する可能性があります。システムは同時に多くの操作を実行し、さまざまなユーザーからの異なるリクエストに応答する必要があります。これらのパフォーマンスリスクに備えるため、チームは負荷テストを使用します。

しかし、良い負荷テスト戦略には、単一のスクリプトを実行するだけでは十分ではありません。トラフィックの異なるパターンは、アプリケーションの異なるリスクプロファイルを作成します。包括的な準備のために、チームはさまざまなテストタイプでシステムをテストする必要があります。

負荷テストの種類

異なる目標に対して異なるテストを行います。スモークテストから始めて、負荷を高め、時間をかけてテストを進めます。

主なタイプは以下の通りです。それぞれのタイプには、その重要な概念を説明した記事があります。

• スモークテスト: スクリプトが正常に動作し、システムが最小限の負荷下でも適切に動作することを検証します。
• 平均負荷テスト: システムが予想される通常の条件下でどのように動作するかを評価します。
• ストレステスト: システムが予想される平均負荷を超えた場合にどのように動作するかを評価します。
• 浸漬テスト: 長時間にわたってシステムの信頼性とパフォーマンスを評価します。
• スパイクテスト: 突然、短期間で大量のアクティビティが増加した場合にシステムの振る舞いと生存性を検証します。
• ブレークポイントテスト: 負荷を徐々に増やしてシステムの容量限界を特定します。

これらのタイプは、アプリケーションの特定の要件や目標に応じて使用されます。

k6 スクリプトでは、オプションまたはシナリオを使用して負荷構成を構成します。これにより、ワークロード構成が反復ロジックから分離されます。

テストタイプのチートシート

次の表は、いくつかの大まかな比較を示しています。

TYPE	VUS/THROUGHPUT	DURATION	WHEN?
Smoke	低	短期間（秒または分）	関連するシステムやアプリケーションコードが変更されたとき。機能ロジック、基準メトリクス、偏差を確認します。
Load	平均的な本番環境	中期間（5-60分）	よく、システムが平均的な使用状況でパフォーマンスを維持しているかを確認します。
Stress	高い（平均以上）	中期間（5-60分）	システムが平均以上の負荷を受ける可能性があるとき、その管理方法を確認します。
Soak	平均	長期間（時間）	変更後、システムが長時間連続して使用されている状況を確認します。
Spike	非常に高い	短期間（数分）	システムが季節イベントの準備を行うか、頻繁なトラフィックピークを受けるときに実施します。
Breakpoint	壊れるまで増加	必要な時間まで	システムの上限を見つけるために何度か実施します。

一般的な推奨事項

k6でさまざまなテストタイプを作成および実行する際には、以下を考慮してください。

スモークテストから開始 スモークテストから始めましょう。大規模なテストを始める前に、スクリプトが期待通りに機能し、システムが少数のユーザーで正常に動作することを検証します。

スクリプトが動作し、システムが最小の負荷に正しく応答することがわかったら、平均負荷のテストに進むことができます。そこから、より複雑な負荷パターンに進むことができます。

具体的なアプローチはユースケースに依存します。

システムは異なるアーキテクチャを持ち、異なるユーザーベースを持っています。そのため、正しい負荷テスト戦略は、組織のリスクプロファイルに大きく依存します。絶対的な考えに固執しないようにしましょう。

たとえば、k6はVUs（Virtual Usersの数）または秒あたりのイテレーションの数（オープン対クローズ）によって負荷をモデル化できます。テストを設計する際に、どのパターンがそのタイプに適しているかを考慮してください。

さらに、単一のテストタイプだけではすべてのリスクを排除できません。システムの異なる障害モードを評価するために、複数のテストタイプを組み込みましょう。システムのリスクプロファイルによって、どのテストタイプに重点を置くかが決まります。

一部のシステムは長時間の使用のリスクが高いため、浸漬テストが優先されるべきです。 他のシステムは高負荷の使用のリスクが高いため、ストレステストが優先されるべきです。 いずれの場合も、単一のテストではすべての問題を明らかにすることはできません。

さらに、カテゴリ自体もユースケースに相対的です。あるアプリケーションにとってのストレステストは、別のアプリケーションにとっての平均負荷テストかもしれません。実際、これらのテストタイプの名前については一致した合意が存在しないことさえあります（以下の各トピックが代替の名前を提供しています）。

シンプルな設計と再現可能な結果を目指す 具体的なアプローチは文脈に大きく依存しますが、一貫して求められるのは、比較可能で解釈可能な結果を得ることです。

シンプルな負荷パターンに従いましょう。すべてのテストタイプに対して、ランプアップ、プラトー、ランプダウンが十分です。

負荷が何度も増減する「ジェットコースター」のようなシリーズは避けましょう。これらはリソースを浪費し、問題を単独で特定するのが難しくなります。

おわりに

今日は、負荷テストの種類 についてご紹介しました。