HTTPエンドポイントを作成して、Postmanから1回叩くと正常に動く。では、200クライアントが同時に叩いたらどうなるでしょうか。確認すべき指標は、1秒あたりのリクエスト数、レイテンシのパーセンタイル、2xx以外のレスポンス数です。autocannonを使うと、これらを約10秒でターミナルから確認できます。
autocannonは、Node.js製のHTTP/1.1ベンチマーキングツールです。指定したURLに対して大量のリクエストを制御しながら送信し、スループットとレイテンシをレポートします。この記事では、インストール、基本コマンド、実運用でよく使うフラグ、結果の読み方、Node.jsスクリプトからの実行方法までを実装ベースで説明します。
autocannonとは
autocannonは、指定したURLに対して一定数の同時接続を開き、指定時間または指定リクエスト数に到達するまでリクエストを送り続けます。実行中にレイテンシをサンプリングし、レスポンス数、スループット、読み取りバイト数を集計します。
測定できるのは、主に次の2点です。
- サーバーがどれくらいの負荷を処理できるか
- その負荷の下でどれくらい速く応答するか
一方で、以下はチェックしません。
- レスポンスボディが正しいか
- APIがOpenAPI仕様に一致しているか
- 複数ステップのワークフローが期待どおりのデータを返すか
つまり、autocannonはロードテスト用です。機能テストや契約テストの代替ではありません。
wrkやApache Benchを使ったことがあるなら、autocannonはNode.js環境に寄せた同種のツールです。npmで導入でき、JavaScriptからプログラマティックに呼び出せます。
インストール
グローバルにインストールすると、どこからでもautocannonコマンドを実行できます。
npm i autocannon -g
Node.jsがインストールされていることを確認してください。
グローバルインストールしたくない場合は、npxで実行できます。
npx autocannon http://localhost:3000
CIやプロジェクト内スクリプトで使う場合は、開発依存関係として追加します。
npm i autocannon --save-dev
インストール確認は次のコマンドです。
autocannon --version
基本的な実行
最小構成はURLを渡すだけです。デフォルトでは、10秒間、10接続でベンチマークを実行します。
autocannon http://localhost:3000
実際の検証では、主に次の3つのフラグを調整します。
| フラグ | 意味 |
|---|---|
-c |
同時接続数 |
-d |
実行時間、秒単位 |
-p |
パイプライン数。各接続がレスポンスを待つ前に送るリクエスト数 |
例:
autocannon -c 100 -d 30 -p 10 http://localhost:3000
このコマンドは、100接続を開き、30秒間実行し、各接続で10リクエストをパイプライン処理します。
レイテンシがどこから急に悪化するかを知りたい場合は、-cを段階的に増やします。
autocannon -c 10 -d 30 http://localhost:3000
autocannon -c 50 -d 30 http://localhost:3000
autocannon -c 100 -d 30 http://localhost:3000
autocannon -c 200 -d 30 http://localhost:3000
一定時間ではなく、固定数のリクエストを送信したい場合は-aを使います。
autocannon -c 10 -a 10000 http://localhost:3000
この例では、10,000リクエストが完了した時点で停止します。
POSTリクエスト、ヘッダー、ボディを送る
HTTPメソッドは-mで指定します。ヘッダーは-H、ボディは-bで渡します。
autocannon -c 50 -d 20 \
-m POST \
-H 'Content-Type=application/json' \
-H 'Authorization=Bearer YOUR_TOKEN' \
-b '{"name":"load-test","active":true}' \
http://localhost:3000/api/users
ヘッダーは次の形式です。
-H 'Key=Value'
複数ヘッダーが必要な場合は、-Hを繰り返します。
ボディが大きい場合やJSONファイルとして管理している場合は、-iでファイルから読み込みます。
autocannon -m POST \
-H 'Content-Type=application/json' \
-i payload.json \
http://localhost:3000/api/users
リクエストレートを固定する
デフォルトでは、autocannonは可能な限り高速にリクエストを送信します。
最大負荷ではなく、想定本番トラフィックに近いレートで測りたい場合は-Rを使います。-Rは、全接続合計の1秒あたりリクエスト数を制限します。
autocannon -c 50 -R 500 -d 60 http://localhost:3000
この例では、60秒間、毎秒500リクエストを維持します。
限界性能を探すのではなく、「通常時の想定負荷でp95/p99が許容範囲に収まるか」を確認したい場合に有効です。
ウォームアップとワーカースレッド
重いベンチマークでは、次のフラグも検討します。
| フラグ | 用途 |
|---|---|
-W |
測定前にウォームアップトラフィックを流す |
-w |
複数のNode.jsワーカースレッドで負荷を生成する |
例:
autocannon -c 200 -d 30 -w 4 http://localhost:3000
-Wは、コールドキャッシュやJITウォームアップの影響で最初の測定値が歪むのを避けたい場合に使います。
-wは、負荷を生成する側がボトルネックになっている場合に使います。たとえば、-cを増やしてもレイテンシが不自然に変わらず、リクエスト数も伸びない場合は、クライアント側が限界に達している可能性があります。
結果の読み方
実行後、autocannonはレイテンシ表と概要を表示します。
http://localhost:3000 で10秒テストを実行中
10接続
┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ 統計 │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ レイテンシ│ 0 ms │ 1 ms │ 4 ms │ 6 ms │ 1.2 ms │ 0.9 ms │ 24.1 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘
10.05秒で25.1万リクエスト、27.9 MB読み込み済み
見るべきポイントは次のとおりです。
- 50%: 中央値。典型的なユーザーが経験するレイテンシ。
- 97.5% / 99%: テールレイテンシ。遅いリクエストがどれくらい悪化しているかを見る。
- Avg: 平均値。ただし外れ値に引っ張られるため、単独では判断しない。
- Stdev: レイテンシのばらつき。大きいほど応答時間が不安定。
- 概要行: 総リクエスト数と読み込みバイト数。リクエスト数を秒数で割ると、おおよそのRPSになります。
より詳細なパーセンタイルとステータスコード別の内訳を出したい場合は、-lと--renderStatusCodesを追加します。
autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000
重要なのは、スループットだけで成功と判断しないことです。
2xx以外のステータスコード、エラー、タイムアウトが発生している場合、高いRPSは成功ではなく失敗を高速に返しているだけかもしれません。
Node.jsスクリプトから実行する
autocannonはNode.js APIを提供しています。CIで実行したり、結果に応じてビルドを失敗させたりできます。
const autocannon = require('autocannon')
async function run() {
const result = await autocannon({
url: 'http://localhost:3000',
connections: 100,
duration: 20,
pipelining: 1
})
console.log(`Avg latency: ${result.latency.average} ms`)
console.log(`Req/sec: ${result.requests.average}`)
console.log(`Non-2xx: ${result.non2xx}`)
}
run()
resultには、主に次の情報が含まれます。
latencyrequeststhroughputerrorstimeoutsnon2xx
latencyやrequestsには、average、min、max、p99などの値が含まれます。
パフォーマンス予算でCIを失敗させる
p99レイテンシや2xx以外のレスポンス数を使って、CIのゲートにできます。
const autocannon = require('autocannon')
const P99_BUDGET_MS = 250
async function run() {
const result = await autocannon({
url: 'http://localhost:3000/api/health',
connections: 100,
duration: 30
})
const p99 = result.latency.p99
console.log(`p99 latency: ${p99} ms (budget ${P99_BUDGET_MS} ms)`)
if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
console.error('Performance budget exceeded')
process.exit(1)
}
}
run()
このスクリプトは、次のどちらかに該当すると失敗します。
- p99レイテンシが250msを超えた
- 2xx以外のレスポンスが1件以上あった
CLIと同じ進捗表示を出す
CLIと同様のプログレスバーや結果テーブルを表示したい場合は、autocannon.trackを使います。
const autocannon = require('autocannon')
const instance = autocannon({
url: 'http://localhost:3000',
connections: 10,
duration: 10
}, console.log)
autocannon.track(instance, { renderProgressBar: true })
process.once('SIGINT', () => instance.stop())
複数リクエストのシナリオを実行する
複数のエンドポイントを順番に叩きたい場合は、requests配列を渡します。
autocannon({
url: 'http://localhost:3000',
connections: 20,
duration: 15,
requests: [
{
method: 'GET',
path: '/api/users'
},
{
method: 'POST',
path: '/api/data',
body: '{"x":1}',
headers: {
'Content-Type': 'application/json'
}
}
]
}, console.log)
これは、単一エンドポイントではなく、簡単なAPIフロー全体に負荷をかけたい場合に使えます。
autocannon vs wrk vs ab
autocannon、wrk、abはいずれも「どれくらい速く、どれくらいの負荷に耐えられるか」を測るツールです。
| ツール | 特徴 |
|---|---|
Apache Bench (ab) |
古典的でシンプル。単一バイナリで使いやすいが、シングルスレッドで古い |
wrk |
高速。Luaスクリプトでカスタムリクエストを扱える。npmとは別に導入が必要 |
autocannon |
npmで導入でき、Node.jsから直接使える。JavaScript API、パイプライン処理、HARファイル、複数リクエストシナリオに対応 |
Node.jsプロジェクトで使うなら、autocannonは導入コストが低い選択肢です。
Python系ツールを検討している場合は、Pythonなしでロードテストを行う方法も参考になります。よりスクリプト可能な選択肢を比較したい場合は、k6のロードテストも確認してください。
機能テストとApidogが適合する場所
autocannonは、「このエンドポイントはp99 40msで毎秒12,000リクエストを処理できる」といった性能を示せます。
しかし、次のような正しさは検証しません。
- 正しいJSONを返しているか
- 認証ヘッダーを正しく扱っているか
- OpenAPI契約から逸脱していないか
- 複数ステップのAPIフローで期待値が引き継がれているか
スループットは正確性ではありません。
このギャップを埋めるのが、機能テストと契約テストです。Apidogはロードジェネレーターではありません。保存したテストシナリオを実行し、ステータスコード、レスポンススキーマ、複数ステップフローの値を検証します。
CIでは、次のように役割を分けると実用的です。
-
autocannon: 負荷の下で十分速いかを確認する - Apidog CLI: APIが正しく動作するかを確認する
Apidog CLIは、Node.jsが使えるCI環境からヘッドレスで実行できます。
npm install -g apidog-cli
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
各オプションの意味は次のとおりです。
| オプション | 用途 |
|---|---|
--access-token |
Apidogのアクセストークン |
-t |
シナリオ、フォルダー、またはスイートID |
-e |
環境ID |
-r |
レポーター。cli、html、json、junitなど |
詳細は、Apidog CLIからAPIテストを実行する方法、コピー&ペーストで使えるCI/CDパイプライン、GitHub Actionsワークフローを参照してください。
実用的なパイプラインでは、プッシュごとに機能テストと契約テストを実行し、リリース前にロードテストを実行します。autocannonは「持ちこたえるか」を確認し、Apidogは「正しく動くか」を確認します。
よくある質問
autocannonは本番環境のロードテストで正確ですか?
autocannonはHTTP/1.1エンドポイントに対して、スループットとレイテンシを測定できます。正確な結果を得るには、サーバーに近いマシンから実行し、ネットワークレイテンシが支配的にならないようにしてください。
本番環境そのものではなく、本番に近いステージング環境で実行するのが安全です。ローカルPC上の開発サーバーだけで測ると、実際のキャパシティ判断には不十分です。
autocannonはHTTP/2またはWebSocketをサポートしていますか?
いいえ。autocannonはHTTP/1.1のベンチマークツールです。
HTTP/2やWebSocketのロードテストには、別のツールを検討してください。
接続数はいくつにすべきですか?
まずはデフォルトの10接続から始めます。
autocannon -c 10 -d 30 http://localhost:3000
その後、-cを段階的に増やします。
autocannon -c 50 -d 30 http://localhost:3000
autocannon -c 100 -d 30 http://localhost:3000
autocannon -c 200 -d 30 http://localhost:3000
RPSの伸びが止まり、レイテンシが上がり始める地点が、おおよその容量の目安です。
CIでautocannonを実行できますか?
はい。Node.js APIを使うと、CIステップに組み込めます。
result.latency.p99、result.non2xx、result.errorsなどを読み取り、許容値を超えたらprocess.exit(1)でビルドを失敗させます。
-aと-dの違いは何ですか?
-dは指定した秒数だけ実行します。
autocannon -c 50 -d 30 http://localhost:3000
-aは指定したリクエスト数が完了するまで実行します。
autocannon -c 50 -a 10000 http://localhost:3000
定常状態の負荷を見るなら-d、正確なリクエスト数を送信したいなら-aを使います。

Top comments (0)