k6入門：k6 Scenarios のドロップされたイテレーションについて

今日は、k6 Scenarios のドロップされたイテレーションについてご紹介します。

背景

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

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

シナリオのコンセプト

シナリオとその実行者の基本的な概念がどのように機能するかについて説明しています。

異なるシナリオの設定は、生成される負荷、利用されるリソース、および発行されるメトリクスなど、システムのさまざまな側面に影響を与える可能性があります。シナリオの動作について少し知っていると、より良いテストを設計し、テスト結果を理解するのに役立ちます。

1. オープンモデルとクローズドモデル：k6がVU（仮想ユーザー）をスケジュールするさまざまな方法、それらがテスト結果に及ぼす影響、およびk6が到達率エグゼキューターでオープンモデルをどのように実装しているかについての情報です。
2. Graceful Stop：テストが予定の時間を終えた後、イテレーションを終了または段階的に減少させるための構成可能な期間についての情報です。
3. 到達率VUの割り当て：k6が到達率エグゼキューターでVUを割り当てる方法についての情報です。
4. ドロップされたイテレーション：k6が予定されたイテレーションを削除する可能性がある理由についての情報です。

この記事では、ドロップされたイテレーション について記載しています。

ドロップされたイテレーション

時折、シナリオが予想されるイテレーションの数を実行できないことがあります。k6は、未送信のイテレーションの数をカウンターメトリクスで追跡し、それを”dropped_iterations”というメトリクスで記録します。ドロップされたイテレーションの数は、エグゼキューターのデバッグや結果の分析時に有用なデータとなります。

通常、イテレーションがドロップされるのは以下の2つの理由が考えられます：

1. エグゼキューターの設定が不十分な場合。
2. テスト対象システムが設定されたVUの到達率を処理できない場合。

設定関連のイテレーションのドロップ

異なるタイプのエグゼキューターでは、異なる理由でイテレーションがドロップすることがあります。

• shared-iterations および per-vu-iterations：これらのエグゼキューターでは、すべてのイテレーションが終了する前にシナリオがmaxDurationに達すると、イテレーションがドロップします。これを軽減するには、おそらくdurationの値を増やす必要があります。
• constant-arrival-rate および ramping-arrival-rate：これらのエグゼキューターでは、空いているVUがない場合にイテレーションがドロップします。テストの初めにこれが発生する場合、単により多くのVUを割り当てる必要があるかもしれません。これがテストの後半で発生する場合、ドロップされたイテレーションはテスト対象のシステムのパフォーマンスが低下し、イテレーションが完了するのに時間がかかるためかもしれません。

SUT 関連の反復ドロップ

一定の高いレイテンシまたは長いイテレーション期間に達した場合、k6は設定されたレートでイテレーションを開始するための空いているVUを持たなくなり、その結果、エグゼキューターはイテレーションをドロップします。

これらのドロップされたイテレーションの理由は様々です：

1. テスト対象のシステムの応答が非常に遅くなり、k6はキューからスケジュールされたイテレーションをドロップし始める。
2. テスト対象のシステムのイテレーション期間が非常に長くなり、k6は目標到達率に到達するためにより多くのVUをスケジュールする必要があり、スケジュールされたイテレーションの数を超える。

原因が異なるため、ドロップされたイテレーションには異なる意味があるかもしれません。数個のドロップされたイテレーションは、迅速なネットワークエラーを示すかもしれません。多くのドロップされたイテレーションは、テスト対象のシステムが完全に応答しなくなったことを示すかもしれません。

テストを設計する際に、受け入れ可能なドロップされたイテレーションのレート（エラーバジェット）を考慮してください。このエラーバジェット内でSUTが応答することを確認するために、Thresholdでdropped_iterationsメトリクスを使用できます。

おわりに

今日は、k6 Scenarios のドロップされたイテレーションについてご紹介しました。