80人が同時にチェックアウトをヒットしたときに、あなたのAPIに何が起こるか知りたいとします。そこでLocustを開くと、最初にPythonクラスを書くように求められます。HttpUserを定義し、メソッドを@taskでデコレートします。locustfile.pyを構築し、仮想環境をセットアップし、いくつかの依存関係を固定し、そして認証トークンがリクエスト間で再利用されない理由を解明する。これらはすべてテストではありません。テストが始まる前の、入場料のようなものです。
Locustは優れたツールであり、そのコードファーストな設計がその目的です。しかし、もしあなたの目標が「ログインエンドポイントは100人の同時ユーザーに耐えられるか」という率直な答えを得ることであれば、Pythonハーネスを書いて維持するのは、一つの数字のために多大なヤクの毛刈り（無駄な骨折り）です。叩きたいAPIリクエストがすでにAPIクライアントに存在する場合、より速いパスがあります。Apidogを使えば、既存のテストシナリオに対してパフォーマンステストを指示し、仮想ユーザー数と実行時間を設定するだけで、スループット、応答時間、エラー率をライブチャートで読み取ることができます。locustfileも、pipインストールも、Pythonも一切不要です。
Locustが実際に優れている点
LocustはPythonで書かれたオープンソースの負荷テストツールであり、そのために作られた目的に優れています。ユーザーの行動をコードとして記述します。仮想ユーザーはPythonクラスであり、そのユーザーが行うことはタスクとしてタグ付けされたメソッドです。locustfile.pyの典型的な形は次のとおりです。
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
これをlocust -f locustfile.pyで実行し、localhost:8089でWeb UIを開き、ユーザー数と生成レートを設定し、数字が上昇するのを観察します。動作がコードであるため、真の表現力を得られます。条件付きロジック、重み付けされたタスク分布、シーケンシャルなユーザー体験、HTTP以外のプロトコル用カスタムクライアント、リクエスト間で共有される状態など。上記の@task(3)と@task(1)の重み付けは、ブラウジングがカートへの追加の3倍の頻度で発生することを意味しており、これは単純なリクエストリストでは捉えられない現実性です。
Locustは水平方向にもスケーリングします。複数のワーカープロセスやマシンに分散して実行し、単一のマスターがそれらを調整することで、一台のマシンで生成できる以上の負荷をかけることができます。内部ではイベント駆動型であるため、各ワーカーはユーザーごとにスレッドを消費することなく、数千の同時ユーザーを処理できます。すでにPythonを使用しており、負荷テストをバージョン管理されたコードとして扱い、複雑な多段階のユーザー行動をモデル化する必要があるチームにとって、Locustは強力な選択肢です。この点について異論はありません。
コストはコードです。すべてのテストは、あなたが記述し、デバッグし、保守するプログラムです。APIが変更されれば、locustfileも変更されます。新しいエンジニアがテストを実行する必要がある場合、それに合わせたPython環境が必要です。そして、もしあなたがすでにPythonを書いていないのであれば、その言語自体が、Pythonとは何の関係もない質問に答えるための前提条件となります。
コードファーストモデルが摩擦となる場所
摩擦は3つの場所で現れます。
まず、セットアップ。何かを測定する前に、Pythonをインストールし、仮想環境を作成し、pip install locustを実行し、ハーネスを記述します。「このエンドポイントは50人のユーザーに耐えられるか」という簡単なチェックのために、それはペイロードよりも多くの配管作業です。
次に、重複。おそらく、これらのリクエストはすでにどこかで定義されているでしょう。Postmanで、あるいは.httpファイルで、あるいはチームが毎日使っているAPIクライアントで。locustfileは、認証フロー、ヘッダー、リクエストボディを含め、すでに存在するリクエストを再記述します。これで、同じAPI知識を2つのコピーで保守することになり、それらは乖離していきます。
第三に、答えを必要とする人々。QAエンジニア、ローンチに汗を流すプロダクトマネージャー、あるいはAPIがマーケティングメールに耐えられるかを知りたいだけのフロントエンド開発者など、誰もが負荷テストの結果を必要としています。彼らは必ずしもそれを享受するためにPythonを読んだり書いたりする必要はありません。テストがlocustfileの背後に閉じ込められている場合、答えは特定のスキルセットの背後に閉じ込められています。
もしあなたの負荷テストが本当に条件分岐ロジックとカスタムプロトコルクライアントを必要とするのであれば、その摩擦は払う価値があり、Locustが適切なツールです。「実際のAPIリクエストを同時負荷の下で実行し、数字を表示する」という一般的なケースでは、Pythonレイヤーが何かをもたらしているのかどうかを問う価値があります。
Apidogのアプローチ：すでにあるリクエストの負荷テスト
Apidogは別の方向から負荷テストに取り組みます。リクエストを記述するスクリプトは書きません。すでに構築したリクエストを取り出し、負荷の下で実行します。負荷テストの単位はテストシナリオであり、これは環境、変数、アサーションがすでに関連付けられたAPIリクエストの順序付けられたセットにすぎません。Apidogを使用してエンドポイントをテストまたはデバッグしたことがある場合、そのリクエストはすでにそこにあります。パフォーマンステストはそれを再利用します。
全体的な流れは次のとおりです。
- 負荷テストを行いたいテストシナリオを開きます。これは、通常の機能テストとして実行するのと同じシナリオであり、同じリクエストと同じ環境変数を使用します。
- 単一のパスとしてではなく、パフォーマンステストとして実行することを選択します。
- 仮想ユーザー数を設定します。Apidogは最大100の仮想ユーザーをサポートし、各ユーザーはテスト全体でシナリオ内のすべてのリクエストを並行してループします。
- テスト実行時間を設定します。これは仮想ユーザーがループを続ける時間です。
- 段階的な増加が必要な場合は、ランプアップ時間を設定します。最初のX分間で、Apidogはすべてのユーザーを一度にではなく、徐々にオンラインにします。0に設定すると、すべての仮想ユーザーがすぐに開始されます。
- シナリオがデータ駆動型の場合、一致モードを選択します。「ランダムマッチ」では、各仮想ユーザーが各ループでテストデータからランダムな行をプルします。「シーケンシャルマッチ」では、行を順番に処理します。
- テストを開始し、ライブパネルを監視します。
チャートはリアルタイムで更新されます。シナリオ内の各APIについて、合計リクエスト数、平均スループット、平均応答時間、最大および最小応答時間、およびエラーが得られます。チャートにマウスを合わせると、指定された時間スライスでの数値が表示されます。「エラー」タブでは失敗したリクエストが内訳され、どのエンドポイントがいつから限界に達し始めたかを確認できます。実行が終了すると、「テストレポート」タブが履歴を保持するため、変更をデプロイした後に今日の実行と先週の実行を比較できます。
重要なのは、書くべきlocustfileがなく、管理するPython環境がないということです。機能テストに合格した同じリクエストが負荷を生成します。それが負荷テストを記述することと実行することの違いです。ApidogはオールインワンAPIプラットフォームであるため、エンドポイントの設計、デバッグ、機能テスト、および負荷テストはすべて、そのエンドポイントの単一の定義に対して行われます。
具体的な比較
ログインエンドポイントが、30秒のランプアップで2分間、100人の同時ユーザーを処理できることを確認したいとします。
Locustでは、資格情報をPOSTするタスクを持つユーザーiクラスを記述し、応答が返すトークンを処理し、フォローアップ呼び出しのために保存し、ファイルを保存し、locust -f login_test.pyを開始し、Web UIを開き、100人のユーザー、生成レート、実行時間を入力します。トークンの処理が間違っている場合、APIをデバッグする前にPythonをデバッグします。
Apidogでは、すでに構築したログインテストシナリオを開き、パフォーマンステストに切り替え、仮想ユーザーに100、期間に2分、ランプアップに30秒と入力して開始します。機能テストで動作していた認証は、同じシナリオであるため、引き続き動作します。応答時間曲線とエラー率がリアルタイムで表示されます。
どちらも同じ種類の答えにたどり着きます。一方はまずプログラムを書き、保守することを求めます。もう一方は、すでに持っているものを再利用します。複雑なコードモデル化されたユーザー体験の場合、プログラムはそれだけの価値があります。「エンドポイントは負荷の下で高速で安定しているか」という質問には、再利用が時間で勝利します。
双方の正直な限界
トレードオフについては明確な目を持ちましょう。なぜなら、間違ったツールを選ぶと、どちらにしても一日を無駄にするからです。
Apidogのパフォーマンステストは、単一の実行で最大100の仮想ユーザーでピークに達し、負荷はアプリを実行しているマシンから生成されます。数万人のユーザーをシミュレートしたり、複数の地理的地域から同時に負荷を生成したりする必要がある場合、それはアプリ内パフォーマンステストのターゲットを超えており、Locustワーカーのような分散セットアップや専用の負荷生成クラスターが適切な選択となります。また、Apidogは失敗したリクエストを統計的に記録するだけで、すべての失敗について完全なリクエストとレスポンスボディをキャプチャするわけではないため、負荷中の特定の失敗した呼び出しの詳細な法医学的デバッグは得意ではありません。
Locustのトレードオフは、この記事全体が扱っているものです。その力はコードから来ており、コードは固定費用です。シナリオごとにlocustfileを保守し、Python環境を維持し、テストを実行したい人は誰でもそれを理解するためにPythonを読む必要があることを受け入れます。非常に多くの仮想ユーザー数とオーダーメイドのプロトコルロジックの場合、その費用は真の価値をもたらします。日常的なAPI負荷チェックの場合、それはオーバーヘッドです。
合理的なルール：テストを「これらのリクエストをこの並行度でこの期間実行する」と記述できる場合は、アプリ内パフォーマンステストを選びましょう。条件分岐、重み付けされたタスクグラフ、カスタムクライアント、または6桁のユーザー数が必要な場合は、コードを選びましょう。各オプションがどこにフィットするかのより広範な調査については、最高の負荷テストツールのまとめと、API固有の負荷テストツール比較を参照してください。
返される数字の読み方
負荷テストは、その出力が何を意味するかを知って初めて有用になります。4つの主要な指標がほとんどの重みを占めます。
スループット（RPS/TPS）は、1秒あたりのリクエスト数またはトランザクション数であり、APIが実際に処理したレートです。これはシステムが処理できる上限です。仮想ユーザーを追加し続けてもスループットが横ばいになる場合、飽和点に達していることを示します。
応答時間（レイテンシー）は、各リクエストにかかった時間です。平均値に注目しますが、最大値にはより厳しく注目してください。ほとんどのユーザーは問題なくても、平均値が良好で最大値が悪いということは、一部のユーザーが悪い体験をしていることを意味します。テールレイテンシーは、実際のユーザーが不満を感じる点です。
エラー率は、失敗したリクエストの割合です。低負荷では問題ないが、仮想ユーザーが増えるにつれて500エラーやタイムアウトが発生し始めるテストは、システムがどこで破綻するかを正確に教えてくれます。エラーが発生し始める点は、通常、生のスループットの数値よりも興味深いものです。
同時実行数は、アクティブな仮想ユーザー数です。Apidogでは、これはあなたが設定する仮想ユーザー数であり、ランプアップはそこに到達する速度を制御します。ランプアップが重要なのは、徐々に100人のユーザーに達するシステムでも、すべての100人が同じ秒に到着すると倒れてしまう可能性があるためです。
これのより詳細なバージョンが必要な場合は、APIパフォーマンステストに関するガイドで、メトリクス、テストタイプ、曲線を読む方法を説明しており、パフォーマンステストの基礎に関する記事では、より広範な規律について取り上げています。
すでに比較しているツールとの関連性
JMeterを使用したことがある場合、ApidogのメンタルモデルはJMeterと似ています。どちらもコードではなくUIを通じて負荷テストを設定できるためです。JMeterは、より重いXMLベースのテストプランとより急な学習曲線と引き換えにこれを提供します。JMeter負荷テストチュートリアルで詳しく説明しています。Postmanのコレクションランナーを通じて負荷を実行したことがある場合、同じアイデアの軽いバージョンを見たことがあるでしょう（Postmanでの負荷テストで説明）。Apidogは、PostmanなしのAPIテストにも使用できるリクエストの上に専用のパフォーマンスレポート機能を追加します。Apidogは、人々が求めるノーコードのシンプルさと、個別のハーネスを維持せずに済むリクエストの再利用の間に位置します。
これらすべてに共通するテーマは、負荷テストが、すでにエンコードしたAPI知識を再利用すべきであり、新しい言語でそれを重複させるべきではないということです。LocustはPythonをその強みとしているため、Pythonでそれを重複させます。Apidogは再利用をその強みとしているため、あなたのシナリオを再利用します。
始め方
もしあなたのリクエストがすでにApidogに存在する場合、次の5分以内にパフォーマンステストを実行できます。テストシナリオを開き、パフォーマンステストに切り替え、仮想ユーザーと実行時間を設定し、開始します。もしlocustfileから来ていて、Pythonレイヤーの維持に疲れているなら、アプリでシナリオを一度再構築すれば、そのエンドポイントの負荷テストコードを二度と書く必要はありません。
Apidogをダウンロードし、すでにテストしているエンドポイントに対してパフォーマンステストを実施してください。同等のlocustfileを書き終える前に、スループット、レイテンシー、エラー率の曲線を得られるでしょう。Locustは、大規模な分散コードモデル化された負荷には依然として正しい選択肢です。ほとんどの開発者が実際に求めている質問に対しては、すでにあるリクエストを実行してください。
FAQ
ApidogはLocustの完全な代替品ですか？
すべての用途に対してではありません。コードを書かずに最大100の仮想ユーザーでAPIリクエストの負荷テストを行う場合、Apidogは既存のテストシナリオを直接実行するため、Locustのワークフロー全体を置き換えます。非常に高いユーザー数での分散負荷や、コードでモデル化されたカスタムの非HTTPプロトコルの場合、Locustの方がまだ適しています。
Apidogで負荷テストを行うのにコードを書く必要がありますか？
いいえ。仮想ユーザー、テスト期間、ランプアップ時間はUIで設定し、テストはすでに構築したテストシナリオのリクエストを実行します。locustfileもPython環境もセットアップする必要はありません。
Apidogはいくつの仮想ユーザーをシミュレートできますか？
単一のパフォーマンステストで最大100の仮想ユーザーをシミュレートできます。各ユーザーは、設定した期間中、シナリオ内のすべてのAPIを並行してループします。それよりもはるかに多くのユーザーや複数の地域からの負荷が必要な場合は、Locustのような分散型コードベースのツールが適切な選択となります。
Apidogのパフォーマンステストではどのような指標が報告されますか？
シナリオ内の各APIについて、合計リクエスト数、平均スループット、平均応答時間、最大および最小応答時間、およびエラーがライブチャートでリアルタイムに更新されます。エラータブでは失敗したリクエストの内訳が示され、テストレポートタブには実行履歴が保持されるため、変更後の実行結果と比較できます。
データ駆動型リクエストで負荷テストを行うことはできますか？
はい。シナリオがテストデータに裏打ちされている場合、「ランダムマッチ」を選択すると、各仮想ユーザーが各ループでランダムな行をプルし、「シーケンシャルマッチ」を選択すると、行を順番に処理します。
それでもLocustを使用すべきですか？
はい、その強みがあなたのニーズと一致する場合です。条件分岐と重み付けされたタスクを持つコード定義のユーザー行動、カスタムプロトコルクライアント、および100仮想ユーザーをはるかに超える分散負荷生成が必要な場合です。テストの形に合わせて適切なツールを使用してください。