こんにちは。よっしーです(^^)
今日は、k6 Scenarios のオープンモデルとクローズドモデルについてご紹介します。
背景
Dockerで構築したWebアプリの開発環境において、k6のScenariosについて調査したときの内容を備忘として残しました。
開発環境のソースは下記のリポジトリにあります。
シナリオのコンセプト
シナリオとその実行者の基本的な概念がどのように機能するかについて説明しています。
異なるシナリオの設定は、生成される負荷、利用されるリソース、および発行されるメトリクスなど、システムのさまざまな側面に影響を与える可能性があります。シナリオの動作について少し知っていると、より良いテストを設計し、テスト結果を理解するのに役立ちます。
- オープンモデルとクローズドモデル:k6がVU(仮想ユーザー)をスケジュールするさまざまな方法、それらがテスト結果に及ぼす影響、およびk6が到達率エグゼキューターでオープンモデルをどのように実装しているかについての情報です。
- Graceful Stop(優雅な停止):テストが予定の時間を終えた後、イテレーションを終了または段階的に減少させるための構成可能な期間についての情報です。
- 到達率VUの割り当て:k6が到達率エグゼキューターでVUを割り当てる方法についての情報です。
- ドロップされたイテレーション:k6が予定されたイテレーションを削除する可能性がある理由についての情報です。
この記事では、オープンモデルとクローズドモデル について記載しています。
オープンモデルとクローズドモデル
k6の実行者には、VU(仮想ユーザー)のスケジュール方法が異なるものがあります。一部の実行者はクローズドモデルを使用し、到達率エグゼキューターはオープンモデルを使用します。
要するに、クローズドモデルでは、VUのイテレーションは前のイテレーションが終了したときにのみ開始されます。一方、オープンモデルでは、VUはイテレーションの完了とは無関係に独立して到着します。異なるモデルは異なるテストの目的に適しています。
クローズドモデル
クローズドモデルでは、各イテレーションの実行時間がテストで実行されるイテレーションの数を決定します。次のイテレーションは、前のイテレーションが終了するまで開始されません。
したがって、クローズドモデルでは、新しいVUイテレーションの開始または到達率は、イテレーションの期間(つまり、VUの実行関数の開始から終了までの時間、デフォルトでexport default関数)と密接に結びついています。
import http from 'k6/http';
export const options = {
scenarios: {
closed_model: {
executor: 'constant-vus',
vus: 1,
duration: '1m',
},
},
};
export default function () {
// 以下のリクエストは約6秒かかり、イテレーションの期間は6秒です。
// したがって、新しいVUのイテレーションは6秒ごとに1つずつ開始され、1分間のテストの期間全体で合計10回のイテレーションが完了することが期待されます。
http.get('https://httpbin.test.k6.io/delay/6');
}
このスクリプトを実行すると、次のような結果になります。
running (1m01.5s), 0/1 VUs, 10 complete and 0 interrupted iterations
closed_model ✓ [======================================] 1 VUs 1m0s
クローズドモデルの利用には以下のデメリットがあります。
VUイテレーションの期間が新しいVUイテレーションの開始と密接に結びついている場合、対象システムの応答時間がテストのスループットに影響を与える可能性があります。応答時間が遅い場合、イテレーションが長くなり、新しいイテレーションの到達率が低下し、その逆もまた同様です。この問題は、一部のテスト文献では「協調的な欠落」として知られています。
つまり、対象システムがストレスを受けて応答が遅くなると、クローズドモデルの負荷テストは待機し、イテレーションの期間が増加し、新しいVUイテレーションの到達率が低下する結果となります。
この効果は、新しいVUの到達率(または一般的にはスループット、例:秒間のリクエスト数)をシミュレートすることが目標の場合には理想的ではありません。
オープンモデル
クローズドモデルと比較して、オープンモデルはVUイテレーションをイテレーションの期間から分離します。対象システムの応答時間は、対象システムへの負荷に影響を与えなくなります。
この協調性の問題を解決するために、イテレーションの開始をイテレーションの期間から分離するオープンモデルを使用することができます。これにより、対象システムの応答時間の影響が軽減されます。
import http from 'k6/http';
export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 1,
timeUnit: '1s',
duration: '1m',
preAllocatedVUs: 20,
},
},
};
export default function () {
// 上記のオープンモデルの到達率エグゼキューター設定を使用すると、
// 新しいVUイテレーションは毎秒1つずつ開始され、
// したがって1分間のテストの期間全体で合計60回のイテレーションが完了することが期待されます。
http.get('https://httpbin.test.k6.io/delay/6');
}
このスクリプトを実行すると、次のような結果になります。
running (1m09.3s), 000/011 VUs, 60 complete and 0 interrupted iterations
open_model ✓ [======================================] 011/011 VUs 1m0s 1 iters/s
おわりに
今日は、k6 Scenarios のオープンモデルとクローズドモデルについてご紹介しました。
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント