寛容ライセンスの OSS 負荷テストツールを比較する — k6 の代替候補と用途別の使い分け
k6 は JavaScript でテストシナリオを書ける軽量で高速なランタイムを持ち、ここ数年は OSS 負荷テストツールのデファクトとして広く採用されてきました。一方で、k6 のコアは Load Impact 時代から一貫して AGPL-3.0 で配布されており、2021 年に Grafana が k6 を取り込み、Grafana / Loki / Tempo を Apache 2.0 から AGPL-3.0 へ relicense した流れと相まって、SaaS への組み込みやプロダクトとの再頒布を伴うケースでは法務的な確認が増えるツールになっています。
実務上、k6 をスクリプトで呼び出す通常の利用は AGPL の「ネットワーク公開条項（network use clause）」の影響を受けにくい、というのが Grafana コミュニティでの一般的な解釈ですが、組織の法務ガイドラインで AGPL を一律で除外しているケースや、ベンダーから提供する SaaS の中で k6 を内蔵させたいケースでは、「Apache 2.0、MIT、BSD のいずれかに絞った負荷テストツール群で組み直したい」という要件が立ち上がります。
本記事では、k6 の代替として寛容ライセンス（permissive license）に分類される OSS 負荷テストツールを、対応プロトコル、スクリプト体験、リソース効率、CI/CD、観測性の連携、用途特化度の観点で比較し、目的別の使い分けを整理します。
寛容ライセンスとコピーレフトの線引き
Open Source Initiative の分類で「寛容（permissive）」に該当するのは、商用利用、改変、再頒布のいずれにも開示義務を課さない Apache License 2.0、MIT License、BSD 系ライセンス、ISC License などです。
これに対し GPL や AGPL は派生物にもソース開示義務を伝播させる「強コピーレフト」、MPL 2.0 や LGPL はファイル単位やライブラリリンク単位で開示義務が発生する「弱コピーレフト」に分類されます。さらに最近は BSL（Business Source License） のような「期間経過後にコピーレフトへ移行する」遅延型のライセンスも増えており、選定時には現行版の LICENSE ファイルを必ず一次資料で確認しておくのが安全です。
主要な負荷テストツールをライセンス区分で並べると、次のように整理できます。
| カテゴリ | 該当ツール |
|---|---|
| 寛容ライセンス（採用候補） | Locust、Gatling OSS、Apache JMeter、Goose、Taurus、Vegeta、oha、autocannon、plow、Fortio、ghz、h2load (nghttp2)、Yandex.Tank（Apache 2.0） |
| 参考（記事の比較起点） | k6（AGPL-3.0） |
用途別の地図を先に押さえる
寛容ライセンスの OSS 負荷テストツールは数が多いため、用途軸でざっくりした地図を先に持っておくと選定が早まります。
flowchart LR
A[広いプロトコル + コードでシナリオ記述] --> A1[Gatling OSS]
A --> A2[Locust]
A --> A3[Goose]
B[多プロトコル + 既存資産活用] --> B1[Apache JMeter]
C[HTTP 中心の高効率 CLI] --> C1[Vegeta]
C --> C2[oha]
C --> C3[plow]
D[Node.js プロジェクト密着] --> D1[autocannon]
E[gRPC 中心] --> E1[ghz]
F[マイクロサービス / Service Mesh] --> F1[Fortio]
G[HTTP/2、HTTP/3 詳細プロファイル] --> G1[h2load]
H[複数ツール統合] --> H1[Taurus]
「コードでシナリオを書きたい」「HTTP API を CLI で素早く叩きたい」「gRPC やサービスメッシュを試験したい」「複数ツールを束ねたい」、という大きな分岐点で道具が変わります。以下、それぞれのカテゴリを順番に見ていきます。
コードでシナリオを書く本格派 — Gatling、Locust、Goose、JMeter
ここは k6 と直接比較される領域で、複雑なユーザーフロー、認証フロー、データ駆動シナリオなどを「コード」として書きたい場合の中心地です。
Gatling OSS — 非同期アーキテクチャと多言語 DSL
Gatling OSS は Apache License 2.0 で提供される Scala / Akka / Netty ベースの負荷テストツールで、k6 の代替として最も「総合力」が高い候補です。HTTP/1.1、HTTP/2、WebSocket、SSE (Server-Sent Events)、gRPC、MQTT、JMS を一つの DSL から扱え、シナリオは Java、Kotlin、Scala、JavaScript、TypeScript のいずれでも書けます。
アーキテクチャは Akka アクターモデルを活用した完全非同期で、仮想ユーザーをスレッドではなくメッセージとして扱うため、単一インジェクタでも 1 万 VU 級の同時実行に耐えます。標準で出力される HTML レポートはパーセンタイル、RPS、エラー内訳まで対話的に確認でき、CI 連携も Maven / Gradle / sbt から自然に入ります。
注意点として、レポート用の Highcharts モジュールはコアの Apache 2.0 とは別ライセンス（Gatling-Highcharts License）で、Gatling の用途に閉じている限りは無料ですが、Highcharts のコードを Gatling 以外に再利用することは認められていません。多くの組織にとっては実質無視できる制約ですが、純粋に Apache 2.0 のみで構成したい場合は別レポーターへの差し替えを検討します。OSS 単体では分散実行は公式サポートが薄く、本格的にスケールさせるなら Kubernetes Helm で自前構築するか、Gatling Enterprise に寄せる構成になります。
Locust — Python の柔軟性と分散モード
Locust は MIT License の Python 製ツールで、テストシナリオを「普通の Python コード」として書けるのが最大の魅力です。User クラスに @task を生やし、必要に応じて Requests や任意の Python クライアントライブラリを呼び出すだけでよく、シナリオの記述コストが極めて低くなります。
内部的には gevent のグリーンレットを使ってイベント駆動で並行処理しており、GIL（Global Interpreter Lock） の制約下でも I/O 待ちが大半の負荷テスト用途では効率的に走ります。組み込みの master / worker による分散モードを使えば、ワーカーごとに数千〜数万 VU を担当させながら複数ノードへ横方向にスケールでき、公式の 分散実行ガイド でも実装パターンが整理されています。
Web UI はリアルタイムで秒間リクエスト数や失敗率を見られますが、Gatling のような静的レポートは弱めです。観測性を強化したい場合は、Prometheus exporter や Grafana ダッシュボード経由での可視化が定番です。Python チームや、業務ロジックの絡んだ複雑なシナリオを書きたい場合の第一候補です。
Goose — Rust の効率性と Locust ライクな API
Goose は Apache License 2.0 で提供される Rust 製の負荷テストフレームワークで、Locust と同じ「コードでユーザー行動を書く」モデルを採用しつつ、Rust の Tokio ランタイムで非同期に走らせます。シナリオは Cargo プロジェクトに Goose クレートを追加してビルドする形式で、公式ドキュメントでは「コアあたり Locust 比で 11 倍以上のスループット」と謳っています（あくまでプロジェクト自身のベンチマークなので、実環境では PoC を推奨します）。
分散モードは Gaggle (manager / worker) として実装されていますが、Goose 0.17.0 で一時的に削除されており、現行版では使えません（必要な場合は 0.16.4 を選ぶ運用になります）。出力は HTML レポート、JSON、CSV など主要なフォーマットが揃っています。Rust の型安全性と単一バイナリのデプロイの容易さは魅力ですが、シナリオを書くたびにコンパイルが入ること、Locust ほどの巨大なエコシステムはないこと、Reqwest ベースで非 HTTP プロトコルは record_custom_request で自前実装する形になることは前提として押さえておきます。
Apache JMeter — 多プロトコル資産の老舗
Apache JMeter は Apache 2.0 の最古参 OSS 負荷テストツールで、HTTP / HTTPS、SOAP / REST、FTP、JDBC、LDAP、JMS、SMTP / POP3 / IMAP、TCP、Java オブジェクトを標準サポートします。WebSocket や gRPC、MQTT は外部プラグインで広げる形で、JMeter Plugins のエコシステムは現在も活発です。
設計は thread-per-user モデルで、仮想ユーザーごとに OS スレッドを 1 本ずつ消費します。直感的でデバッグしやすい反面、リソース効率は同期 / スレッド型の限界があり、Gatling や Goose のような非同期型と比べると同じハードウェアでさばける VU 数は少なくなります。実運用では GUI モードでスクリプトを作り、負荷生成は -n -t test.jmx -l result.jtl -e -o report のように CLI モードで走らせるのが基本構成です。
バージョン 5.6 でプログラマティック APIが改善され、.jmx の XML を直接さわらずに Java や Kotlin のコードでテスト計画を組みやすくなっています。既存の JMX 資産がある組織、JDBC や JMS など Web 以外のプロトコルを多用するエンタープライズ環境では、依然として最有力です。
コード駆動型の比較
| 比較項目 | Gatling OSS | Locust | Goose | Apache JMeter |
|---|---|---|---|---|
| ライセンス | Apache 2.0 | MIT | Apache 2.0 | Apache 2.0 |
| 言語 / ランタイム | Scala / Netty | Python / gevent | Rust / Tokio | Java / JVM |
| シナリオ記述 | Java / Kotlin / Scala / JS / TS DSL | 普通の Python | Rust（Cargo） | XML（GUI）/ Groovy / Java DSL |
| 並行モデル | アクターモデル（非同期） | greenlet（イベント駆動） | async / multi-core | スレッド・パー・ユーザー |
| 主なプロトコル | HTTP/1.1, HTTP/2, WebSocket, SSE, gRPC, MQTT, JMS | HTTP/HTTPS（拡張で任意） | HTTP/HTTPS（カスタム計測可） | HTTP, JDBC, LDAP, JMS, FTP, TCP ほか |
| 分散実行 | OSS は単一インジェクタ | 組み込みの master / worker | Gaggle（master / worker） | master / slave |
| 観測性 | リッチな HTML レポート | Web UI、OTel、Prometheus exporter | HTML / JSON / CSV | HTML、Backend Listener（InfluxDB、Graphite） |
HTTP 中心の高効率 CLI ツール群
「複雑なユーザーフローはいらない、特定エンドポイントの限界性能だけ見たい」という用途では、単一バイナリの軽量ツールが圧倒的に効率良く回せます。CI でビルドのリグレッションを止めるためのゲートとしても、これらのツールが扱いやすい層です。
Vegeta — 定常 RPS と Prometheus 連携
Vegeta は MIT License の Go 製ツールで、HTTP / HTTPS に特化しています。固定レート（constant request rate）を厳密に維持する設計が中心で、Coordinated Omission の問題を回避しやすいことから、SLO 検証用の負荷生成によく使われます。
UNIX パイプ的な設計（echo "GET https://example.com" | vegeta attack -rate=100 -duration=30s | vegeta report のように構成可能）と、組み込みの Prometheus exporter、JSON / CSV / プロット出力が揃っています。Go ライブラリとして自前のロードジェネレータに組み込む使い方もできるため、社内ツールに埋め込んで定常運用するパターンとも相性が良いです。
oha — Rust と TUI のモダンな選択肢
oha は MIT License の Rust / Tokio 製ツールで、CLI ながら ratatui ベースのターミナル UI を持ち、テスト中のヒストグラムやレイテンシの推移をリアルタイムに可視化できます。HTTP/1.1、HTTP/2 に加えて HTTP/3 を実験的にサポートし、--latency-correction で Coordinated Omission の補正もかけられます。
Rust の単一バイナリで配布されるため Homebrew や GHCR のコンテナイメージ経由で導入しやすく、最近の HTTP API ベンチでは事実上の標準に近い位置を獲得しつつあります。
plow — リアルタイム Web UI 付きの Go 製ツール
plow は Apache License 2.0 の Go / fasthttp ベースのツールで、:18888 で立ち上がるリアルタイム Web UI が特徴です。秒間リクエスト数とレイテンシ分布を Web から直接見られるため、SRE / 開発者が同じ画面で結果を共有しながら回す用途に向きます。
autocannon — Node.js プロジェクトに密着
autocannon は MIT の Node.js 製で、npm i -D autocannon で同じプロジェクトに同梱できる手軽さが最大の魅力です。CLI でも JS API でも使え、Worker threads による並列モードもあります。一方、README 自身が CPU-bound と明言しているとおり、極限スループットでは Go / Rust / C 系に劣りやすく、HTTP/1.1 中心という制約もあります。「Node エコシステム内で完結させたい」「API 開発者が PR ごとに回す軽量ベンチが欲しい」用途には強い選択です。
CLI ツール群の比較
| ツール | 言語 | HTTP/2 | HTTP/3 | 観測性 / 出力 | 特徴 |
|---|---|---|---|---|---|
| Vegeta | Go | ◯ | × | 組み込み Prometheus、JSON、プロット | 定常 RPS、UNIX パイプ |
| oha | Rust | ◯ | △（実験的） | TUI、JSON、CSV、SQLite | 単一バイナリ、レイテンシ補正 |
| plow | Go | ◯ | × | リアルタイム Web UI | :18888 ダッシュボード |
| autocannon | Node.js | × | × | JSON、HTML | npm 配布、CI への組み込みが容易 |
プロトコル特化のツール群
ghz — gRPC の業界標準ベンチ
ghz は Apache License 2.0 の Go 製ツールで、gRPC のロードテストに特化しています。.proto または protoset ファイルから動的に呼び出すため、サーバー側に専用エンドポイントを足す必要がなく、unary、client / server / bidirectional streaming も網羅します。
レポートは JSON / HTML / CSV、メトリクスは Prometheus または InfluxDB の line protocol で書き出せ、CI から呼び出してリグレッションを止める運用に乗せやすい設計です。runner パッケージを Go プログラムから直接呼び出して、E2E テストの一部として組み込むこともできます。gRPC マイクロサービスを継続的に試験するなら、寛容ライセンス縛りの中ではほぼ第一択です。
h2load — HTTP/2 と HTTP/3 の詳細統計
h2load は MIT License の nghttp2 に同梱される C++ 製ベンチで、HTTP/1.1、HTTP/2、HTTP/3（QUIC）に対応しています。ALPN ネゴシエーション、HPACK 圧縮効率、ストリームのフロー制御まで含めた詳細な統計を取れるため、HTTP/2、HTTP/3 のプロトコルレベルでの挙動を見たい場合に強力です。
シナリオ性は弱く、ヘッダのカスタマイズ程度に留まりますが、--enable-http3 を有効にしてビルドすれば QUIC 越しの負荷もそのまま試せるため、CDN や TLS スタックの検証用途には今でも有力です。
Fortio — マイクロサービスとサービスメッシュ
Fortio は Apache License 2.0 の Go 製ツールで、もともとは Istio プロジェクトの負荷ジェネレータとして始まり、現在は独立したリポジトリで運営されています。HTTP / HTTPS、HTTP/2（gRPC 経由）、gRPC、TCP / UDP / echo / nc / proxy をカバーし、QPS を厳密に固定して負荷をかけられるのが特徴です。
fortio server で立ち上げると Web UI と REST API が一緒に立ち上がり、結果のヒストグラム表示、テストの再実行、結果の比較がブラウザだけで完結します。Docker イメージは 6 MB 以下に抑えられており、Kubernetes 上のサイドカーや CI ジョブに同梱しやすい設計です。Service Mesh、gRPC、TCP / UDP の健全性試験を SRE / Platform チームが回したい場面では、ghz と並んで定番になります。
Taurus — 複数ツールを束ねる抽象層
Taurus は Apache 2.0 の Python 製抽象化フレームワークで、JMeter、Gatling、Locust、Selenium、k6、Newman、ApacheBench、Molotov などの実行エンジンを共通の YAML / JSON 設定でラップします。
execution:
- concurrency: 100
ramp-up: 1m
hold-for: 5m
scenario: quick-test
scenarios:
quick-test:
requests:
- http://example.com/api/v1/status下層ツールごとに散らばっていた起動引数、しきい値、レポート設定をまとめて 1 ファイルで管理できるため、複数ツールを並走させる組織や、JMeter の既存資産を活かしつつモダンな YAML 設定に寄せたい場合に有効です。注意点として、Taurus 自身は Apache 2.0 ですが、下層ツールのライセンスは継承されるため、Taurus 経由で k6 を呼び出せばその構成は AGPL の影響下に置かれます。寛容ライセンス縛りで使う場合は、下層に置くエンジンも JMeter / Gatling / Locust などの寛容組に絞る必要があります。
リソース効率と「現場で何 VU 出せるか」
ツール選定では「同じハードウェアで何 VU 出せるか」が直接コストに跳ね返ります。古典的な thread-per-user 型と、非同期 / goroutine / 軽量プロセス型では、メモリ消費に大きな差があります。
| ツール | アーキテクチャ | VU あたりのコスト | 備考 |
|---|---|---|---|
| Apache JMeter | スレッド・パー・ユーザー | 約 1 MB（OS スレッド） | ヒープサイズの調整が必須 |
| k6（参考） | goroutine | 約 100 KB | 軽量だが本記事の対象外（AGPL） |
| Gatling OSS | アクターモデル | 軽量メッセージ | 単一インジェクタで 1 万 VU 級 |
| Locust | gevent / greenlet | 数十〜数百 KB | 分散モードで横にも伸ばせる |
| Goose | Rust async | 数十 KB | マルチコア活用、単一プロセスで高効率 |
| Vegeta / oha / Fortio | Go / Rust ランタイム | 数十 KB 程度 | 単一バイナリで運用が軽い |
数値はベンチマーク条件によって幅が出るため、最終判断は本番に近いハードウェアでの PoC をおすすめします。出典付きの計測値ではなく現場での経験則ですが、傾向としては「JMeter 単一台の限界に対し、Gatling や Locust なら数倍（おおむね 2〜5 倍）出る」「専用 CLI 系（Vegeta、oha、Fortio など）なら同じハードでさらに高い RPS を維持できる」と捉えておけば、複数台にまたがる分散テストが必要かどうかの最初の判断軸になります。
CI/CD パイプラインへの組み込みと品質ゲート
寛容ライセンスの主要ツールはどれも CI で走らせる前提で作られており、テスト結果でビルドを止める「品質ゲート」も標準機能として持っています。
- Gatling: シナリオに Assertions DSL を書くと、95 パーセンタイルやエラー率の閾値を超えたとき非ゼロ終了コードでビルドを失敗させられる
- Locust: 既定で失敗があると終了コード 1 を返す。詳細な閾値判定は公式ドキュメントの「Controlling the exit code」のとおり、
quittingイベントでenvironment.stats.total.fail_ratioや 95 パーセンタイルを評価してenvironment.process_exit_codeを上書きするのが公式パターン。--headlessモードで Web UI なしの CI 実行が可能 - Vegeta / oha / Fortio: JSON 出力をパースして閾値判定するワンライナーを CI に書く運用が定番。Vegeta は組み込みの Prometheus exporter から SLO 監視へつなぐ手もある
- ghz:
--rpsと--totalを使って固定負荷を投げ、JSON レポートのレイテンシ / エラー率を jq で取り出して閾値判定する
GitHub Actions、GitLab CI/CD、Jenkins のいずれにも対応するテンプレートが用意されており、PR ごとに回すのか、夜間バッチで回すのかは組織のサイクルに合わせやすい設計です。
ブラウザ越しの本物のユーザー負荷
寛容ライセンスのみでブラウザ負荷テストを完結させる場合、k6 の k6/browser が AGPL のため使えないという制約が出ます。代替として現実的なのは、Playwright（Microsoft、Apache 2.0）または Puppeteer（Google、Apache 2.0）を Kubernetes Job や Vercel Sandbox のような並列実行基盤に流し込み、メトリクスを Prometheus に送る自前構成です。
ブラウザ負荷は VU あたり数百 MB 級のメモリを使うため、本来は「プロトコルレベルの負荷（Locust や Gatling）+ 少数のブラウザシナリオ」というハイブリッド構成にしておく方が、コストもデバッグの見通しも良くなります。Playwright 互換のアサーション API を自前で組みたい場合は、Apache 2.0 で公開されている grafana/k6-jslib-testing（k6 専用の JS ライブラリ）の実装が参考になります。
用途別の選び方
実際の選定では、「どのツールが最強か」よりも「自チームの運用とプロトコルにどれが一番なじむか」のほうが効きます。最後に、用途別のおすすめを整理します。
- 新規に組織標準を選び直す（k6 を寛容ライセンスで置き換える）: Gatling OSS を第一候補に。HTTP/2、WebSocket、gRPC、MQTT、JMS まで一つの DSL で扱え、Java / Kotlin / TypeScript いずれでも書けるため、既存スキルを活かしやすい。
- 業務ロジックの絡んだ複雑なシナリオを書きたい / Python チーム: Locust。Python ライブラリの自由度と分散モードのスケールが効く。
- Rust とコンパイル時の型安全性を重視 / 単一プロセスで限界まで回したい: Goose。マルチコア活用と Cargo ビルドの一貫性が魅力。
- 既存 JMeter 資産を活かしつつ、JDBC や JMS など多プロトコルを混ぜる: Apache JMeter。Web 以外のプロトコル網羅性は依然として最強。
- HTTP API のリグレッションテストを CI で軽量に回す: Vegeta（定常 RPS）または oha（TUI とモダンな出力）。Node.js プロジェクトなら autocannon。
- gRPC マイクロサービス専用: ghz。プロトファイルを直接読み込めるのが効率的。
- サービスメッシュ、SRE 視点で TCP / UDP / gRPC を横断: Fortio。Istio 文脈との親和性が高い。
- HTTP/2、HTTP/3 のプロトコル詳細を見たい: h2load。CDN や TLS スタックの検証に。
- 複数ツールを統一インターフェースで束ねたい: Taurus。下層ライセンスの継承に注意。
寛容ライセンス縛りの中でも、単純な「k6 の代替」という見方を一段ほどけば、用途と組織の体制に応じて多様な選択肢が揃っています。HTTP API のリグレッションは Vegeta や oha で軽く回し、複雑なシナリオは Gatling か Locust に寄せ、gRPC は ghz で押さえる、という多層構成にすると、ライセンス要件と運用コストの両方を素直に下げられます。導入時は必ず LICENSE の現行版を一次資料で確認し、PoC で実機性能を測ってから本採用に進めるのが安全です。
以上、k6 の代替として寛容ライセンスの OSS 負荷テストツールを比較した、現場からお送りしました。