バージョン: 4.6.1-saas

k6でNetFUNNELキューシミュレーション

このガイドでは、k6を使用してNetFUNNELに直接負荷を生成し、順次進入、キューイング、TTLサイクル、完了を再現および測定する方法を説明します。スクリプトが実際のクライアント呼び出しを模倣するため、構成効果とユーザー体験を安全に検証できます。

テストシナリオ:

基本コントロール: nfStart → (作業シミュレーション) → nfStop
区間コントロール: nfStartSection → (Alive Notice 5003ループ) → nfStopSection

使用する理由

順次進入およびキュー検証: 意図的に待機条件を生成して、ユーザーが順番に進入し、TTLサイクルが構成どおりに動作するか確認します。
待合室UX観察: k6が負荷を生成している間、ブラウザを開き、同じセグメントで保護されたページに移動して、待合室および後続の進入を視覚的に確認します。
セグメント構成ドライラン: バックエンドに触れずに実際の効果を確認するため、さまざまな流入速度、進入状態、タイミングを試します。
容量およびSLO確認: opcode遅延時間(5101, 5002, 5003, 5004)を測定し、予想VUレベルで目標を満たしているか確認します。
リスクのない統合テスト: バックエンド負荷を導入する準備が整うまで、NetFUNNELのみをテストします。
インシデントリハーサル: スパイクおよびキュー構築をシミュレートして、通知およびダッシュボードを確認します。

待合室を観察する迅速な方法:

NetFUNNELコンソールで流入(例: TPS)を下げるか、進入状態を設定してセグメントに対するキューイングを強制します。
該当セグメント(基本または区間コントロール)に対するk6スクリプトを実行して圧力を生成します。
ブラウザで同じセグメントで保護されたページにアクセスします。待合室が表示され、許可されると進入が表示されます。

このスクリプトがすること(そしてしないこと)

NetFUNNELにのみ負荷を生成します。サービスロジック(Web/WAS/DB)を呼び出しません。必要に応じてカスタム呼び出しを追加できます。
ライブ構成を取得し、進入キーをリクエストし、オプションで待機および再試行してから完了(キー返却)します。
迅速な分析のためにk6 Trendsでopcode別タイミングを測定します。

ダウンストリームサービスにもストレスを与えるには、成功した進入(200)とキー返却(5004)の間にサービス呼び出しを挿入してください。以下のサンプルのコメントを参照してください。

このシミュレーションが実際のユーザーと同じ理由(opcode説明)

k6仮想ユーザーは実際のクライアント(エージェント/SDK)が送信するものと同じNetFUNNEL opcodeを送信します。そのため、見える動作(キュー、速度調整、許可、完了)が最終ユーザー体験と一致します。

5101 — 進入リクエスト(キー発行)
- 最終ユーザー観点: "入れてください。" 容量があればユーザーが許可され、そうでなければキューに配置されます。
- スクリプト動作: GET 5101; 応答を状態(200/201)およびkey/sticky/ttlでパースします。
5002 — キューポーリング(待機/再試行)
- 最終ユーザー観点: "待機中です。後で再度確認してください。" クライアントはttl秒を待機してから再度リクエストします。
- スクリプト動作: sleep(ttl), GET 5002; 200になるまでループします。
5003 — Alive Notice(区間コントロールのみ)
- 最終ユーザー観点: "保護された区間をまだ使用中です。" 区間内でセッションをアクティブ状態に維持します。
- スクリプト動作: section_count回数だけ (sleep ttl → GET 5003)を繰り返します。
5004 — 完了(キー返却)
- 最終ユーザー観点: "完了しました。" 次のユーザーのための容量を解放します。
- スクリプト動作: シミュレートされたサービス持続時間(btn_click_delay)後にGET 5004を実行します。

最終ユーザー観点からのシーケンス(基本 vs 区間):

前提条件

アクセス可能なNetFUNNELエンドポイント(クラウドまたはオンプレミス)
プロジェクトID(sid)およびセグメントID(aid)
- 基本コントロールセグメントおよび/または
- 区間コントロールセグメント
k6がインストールされたLinux/macOS/WSL環境

k6インストール

Linux (Debian/Ubuntu)
macOS (Homebrew)
Windows (chocolatey | scoop)

sudo gpg -k || true
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update && sudo apt-get install -y k6

brew update
brew install k6

# Chocolatey
choco install k6 -y

# or Scoop
scoop bucket add main
scoop install k6

WindowsではWSL(Windows Subsystem for Linux)を使用することもでき、Linux指示にそのまま従うことができます。

提供されるスクリプト

実行準備が整った2つのスクリプトが提供されます。完全なコピー/貼り付けコードおよび使用方法は下位ページを参照してください:

拡張された演習については、別の方法ガイドを参照してください。

構成および設定

ほとんどの設定は2つのスクリプトに共通です。区間コントロール専用フィールドは表示されています。

各スクリプト上部で仮想ユーザーおよび持続時間を調整します:

export const options = {
  vus: 30,
  duration: "600s",
  // iterations: 3000, // オプション制限
};

setup()で環境を設定します(共通):

vars["apiurl"] = "https://your-netfunnel-domain"; // NetFUNNEL基本URL
vars["sid"] = "service_1"; // プロジェクトID
vars["aid"] = "basic_control"; // セグメントID
vars["btn_click_delay"] = "2.5"; // シミュレートされたサービス持続時間(秒)
// 区間コントロールのみ:
// vars["section_count"] = "10"; // Alive noticeサイクル

k6オプション意味(VUs, duration, iterations)

vus
- 意味: 基本関数を並列で実行する同時仮想ユーザー(k6ワーカー)数です。
- 効果: より高いvusは同時リクエストとキュー形成(201)の可能性を増加させ、5002/5003ループにストレスを与えます。
duration
- 意味: VUが基本関数ループを実行する壁時計時間です。
- 効果: より長い持続時間は圧力を維持します。VU全体でより多くの5101/5002/5003/5004サイクルが発生します。
iterations (オプション)
- 意味: すべてのVUにわたる総反復回数(基本関数実行)の上限です。
- 効果: 設定すると反復上限に達するとduration前にテストが終了する可能性があります。設定しない場合、VUはdurationが経過するまでループします。
相互作用
- vus + durationのみ設定された場合: 指定された時間窓に対するオープンルーピングです。
- iterationsも設定された場合: 最初に満たされる条件(反復上限または持続時間タイムアウト)が実行を終了します。
- 反復あたりの速度調整はサーバーttl待機およびbtn_click_delayによって決定されます。設計しない限り、固定リクエスト速度はありません。

構成 → フローマッピング

apiurl
- 意味: すべてのリクエスト(設定アセット、5101/5002/5003/5004)に対する基本URLです。
- フローでの位置: 2つのダイアグラムのすべてのリクエスト
sid / aid
- 意味: 制御するNetFUNNELセグメントを識別するプロジェクトIDおよびセグメントIDです。
- フローでの位置: 5101(初期進入リクエスト)に含まれます。
btn_click_delay
- 意味: 進入キーを保持している間のシミュレートされたビジネス処理時間です。キーを返却する前のクライアント側保持時間です。
- フローでの位置:
  - 基本コントロール: 進入が許可された後(200)および5004(完了)直前のみ
  - 区間コントロール: Alive Noticeループ(5003サイクル)後および5004直前
- 使用されない: 201待機サイクル; これらの待機はサーバーのttlによって制御されます
- 選択方法: リクエストあたりの遅延ではなく、実際のユーザー/セッションが保護されたリソース(例: ページ処理、短いトランザクション)を占有する平均時間に近似するように設定します
section_count (区間コントロールのみ)
- 意味: 制御された区間内でセッションが留まることをシミュレートするAlive Notice(5003)サイクル数です。
- フローでの位置: 進入(200)と完了(5004)の間の5003に対するループ反復回数
- ttlとの関係: 各Alive Noticeサイクルは次の5003を送信する前にサーバーが返したttlを待機します

動作方法(リクエストフロー)

以下のダイアグラムは正確なリクエストシーケンスを示します。

基本コントロールフロー

区間コントロールフロー

同時VU(概念的)

VUs/duration/iterationsがフローに与える影響:

より多くのVU → より多くの同時5101リクエストおよび潜在的な201キュー。
より長い持続時間 → 全体的により多くの再試行(5002)およびAlive(5003)サイクル。
iterations上限(設定された場合) → 持続時間に関係なく総フロー実行を制限します。

テスト実行

# 例ファイル名(保存したスクリプト名に合わせて調整)
k6 run basic-control-script.js
k6 run section-control-script.js

実践シナリオ:

コンソール準備: キューを強制するために進入許容数を下げます(セグメントを開いたままにしておくが制限のみを置きます)。
実行: VU >> 進入許容数(例: 進入許容数≈2 vs VU=20–30)および5–10分持続時間を選択します。
観察: モニタリングで待機中のユーザー数および関連指標を含む主要メトリックを確認します。
UX確認: テスト中に保護されたページ/アプリを開きます。待合室 → キュー位置 → 許可を確認します。

このスクリプトを使用して負荷下でNetFUNNEL動作を迅速かつ反復可能に検証してください。

使用する理由​

このスクリプトがすること(そしてしないこと)​

このシミュレーションが実際のユーザーと同じ理由(opcode説明)​

前提条件​

k6インストール​

提供されるスクリプト​

構成および設定​

k6オプション意味(VUs, duration, iterations)​

構成 → フローマッピング​

動作方法(リクエストフロー)​

基本コントロールフロー​

区間コントロールフロー​

同時VU(概念的)​

テスト実行​