APIロードテスト:オンラインでAPIをロードテストするための究極のガイド

ほとんどすべてのタイプのシステムまたはインフラストラクチャで動的 API ロード テストを実施します。
実行可能なロード テスト データを取得する – 問題がどこにあるかを確認し、迅速に解決します。

API ロード テストとは

API (アプリケーション プログラミング インターフェイス) ロード テストは、シミュレートされた高負荷の下で API のパフォーマンスとスケーラビリティをテストするプロセスです。 これは、API が予想されるトラフィックを処理し、一貫性のある信頼性の高いパフォーマンスをユーザーに提供できるようにするために行われます。

API のロード テストは、API が公開される前に潜在的なパフォーマンスの問題を特定して解決するのに役立つため、API の開発とデプロイのプロセスにおける重要な手順です。 これにより、サービスの中断を防ぎ、ユーザー エクスペリエンスを向上させることができます。

API ロード テストは、テスト プロセスの特定の目標と目的に応じて、さまざまな方法で実行できます。 API ロード テストの一般的な目標には、次のようなものがあります。

  • API の最大容量を決定し、潜在的なボトルネックや脆弱性を特定する
  • さまざまな負荷条件下でのAPIのパフォーマンスと効率の測定
  • API の限界点を特定し、トラフィックの予期しない急増を処理する能力を判断する
  • 長期間にわたるAPIの安定性と信頼性の評価

API ロード テストの種類

テスト プロセスの特定の目標と目的に応じて、実行できる API ロード テストにはいくつかの種類があります。 API ロード テストの一般的な種類には、次のようなものがあります。

ストレステスト: このタイプのテストは、API が失敗するか使用できなくなるまで負荷を徐々に増やすことで、API のブレークポイントを判断するように設計されています。 これは、API の最大容量と潜在的なボトルネックや脆弱性を特定するのに役立ちます。

浸漬テスト: 耐久テストとも呼ばれるこのタイプのテストは、長期間にわたるAPIの安定性と信頼性を判断するように設計されています。 これは、APIを長期間(数時間または数日など)持続的な負荷にさらすことによって行われます。

スパイクテスト: このタイプのテストは、トラフィックの突然の予期しない急増にAPIがどのように応答するかを判断するように設計されています。 これは、負荷の急激な増加を処理する API の機能に関する問題を特定し、これらの種類のイベントから迅速に回復できるようにするのに役立ちます。

パフォーマンステスト: このタイプのテストは、さまざまな負荷条件下でのAPIのパフォーマンスと効率の測定に重点を置いています。 これには、応答時間、スループット、リソース使用率などの測定値を含めることができます。

API のロード テスト時に考慮すべき要素

API ロード テストを計画および実施する際に考慮する必要があるいくつかの要因があります。 重要な考慮事項のいくつかは次のとおりです。

テスト環境: テスト環境が、ハードウェア、ソフトウェア、およびネットワーク構成の点で運用環境にできるだけ近いことを確認することが重要です。 これは、テスト結果が正確であり、APIの実際のパフォーマンスを代表するものであることを確認するのに役立ちます。

テストデータ: API ロード テストを実施するときは、現実的で代表的なテスト データを使用することが重要です。 これは、テスト結果が通常の条件下でのAPIのパフォーマンスを正確に反映していることを確認するのに役立ちます。

テスト シナリオ: API の予想される使用パターンを反映する一連のテスト シナリオを定義することが重要です。 これには、ポジティブとネガティブの両方のテストケースを含めて、APIが堅牢であり、幅広い入力を処理できることを確認することができます。

負荷レベル: テスト中に使用される負荷レベルを定義し、時間の経過とともに負荷を徐々に増加させて、実際の使用パターンをシミュレートすることが重要です。

API ロード テストのためのツールと手法

API ロード テストの実施に使用できるツールと手法は多岐にわたります。 最も一般的に使用されるツールと手法には、次のものがあります。

負荷テスト ツール: API のパフォーマンスとスケーラビリティをテストするために特別に設計された特殊なロード テスト ツールが多数あります。 通常、これらのツールを使用すると、ユーザーはテスト シナリオを定義し、負荷レベルを設定し、パフォーマンス メトリックをリアルタイムで監視できます。

オープンソースツール: API ロード テストに使用できるオープンソース ツールも多数あります。 これらのツールは、商用ロード テスト ツールのすべての機能を備えているとは限りませんが、予算内で作業している開発者にとっては良いオプションです。 API ロード テスト用のオープンソース ツールの例には、Apache JMeter や Gatling などがあります。

クラウドベースのサービス: API ロード テストを実行するための別のオプションは、クラウドベースのサービスを使用することです。 これらのサービスは通常、ロード テストを実行するためのさまざまなツールと機能を提供し、クラウドでホストされている API のテストに特に役立ちます。

カスタムスクリプト: API ロード テストを実行するためのカスタム スクリプトを作成することもできます。 これは、テスト プロセスをきめ細かく制御したい開発者や、既存のツールでは満たされない特定の要件がある開発者に適したオプションです。 API ロード テストで一般的なスクリプト言語には、Python、Java、シェルなどがあります。

手動テスト: 場合によっては、API のパフォーマンスとスケーラビリティを評価するために手動テストを実行する必要があります。 これは、自動化が難しい API や、高度な人間の操作を必要とする API をテストする場合に役立ちます。

API ロード テストは、API の開発とデプロイのプロセスにおける重要な手順です。 これは、API が予想されるトラフィックを処理し、一貫性のある信頼性の高いパフォーマンスをユーザーに提供できるようにするのに役立ちます。 API ロード テストの実施に使用できるツールと手法は多岐にわたり、最も適切な方法は、テスト プロセスの特定の目標と目的によって異なります。

ロード テスト API

API のロード テストは、API と基盤となるインフラストラクチャが、予想される数の同時要求を処理できることを証明します。 ボリューム テストとも呼ばれるロード テストでは、システムが定義済みのトラフィック量を処理できることを確認します。

ストレス テスト API

ストレス テスト API は、サービスの理論上の容量を超える要求数を増やすことで、同時ユーザーの上限をテストします。 ストレス テストでは、システムが回復を処理する方法を確認するために、リソースが過負荷になるまで負荷が増加します。

API テスト シナリオの設計

複数の API テスト シナリオを設計し、システムの全体的なパフォーマンスに関する洞察を得ます。

ロードビュー API ロード テスト – レストフル、SOAP、SaaS、および動的

ほとんどすべてのタイプのシステムまたはインフラストラクチャで動的 API ロード テストを実施します。

ロード テスト API を使用する理由

ネットワーク内から API をロード テストすると、理論的にはシステムの問題を検出するのに役立ちますが、ネットワークの外部からエンド ユーザー エクスペリエンスをエミュレートする追加のテストを実行することをお勧めします。 API を外部でテストすると、エンド ユーザーまたはサードパーティのシステムの観点から応答時間の平均を識別できます。 これらの平均応答時間は、将来の応答性を比較できるベースライン パフォーマンス メトリックとしてサーバーを値します。 通常、外部テストの結果は、ファイアウォール内からの低待機時間テストよりも、顧客のエクスペリエンスを表す方が多いものです。 外部 API テストは、ファイアウォールの背後でテスト中に発生しない問題を特定するのにも役立ちます。

API パフォーマンステストに関する質問

API パフォーマンス テストをセットアップする際に、次のようないくつかの質問に答える必要があります。

• エンドユーザーまたはターゲットオーディエンスは誰ですか。
• なぜ API を使用しているのですか。
• ユーザーは API を使用して何を達成しようとしているのか。
• ユーザーにとって API はどのくらい重要ですか。
• API が使用できない場合や信頼性が低い場合はどうなりますか。
• ユーザーは API からフィードバックを受け取ることを期待していますか。
• これらの各前提をどのようにテストしますか。

質問に答えたら、API テストケースを作成しましょう

これらの質問に答えたら、API テスト ケースをビルドして、各テスト ケースのニーズが満たされていることを確認します。 これらの質問の答えに応じて、テスト ケースの前提条件を検証するためにさまざまな種類のテストが必要になる場合があります。 たとえば、データを API に送信すると、API からの 「成功」 応答のみが検索される場合があります。 同様に、クエリを送信すると、サーバーからの応答の特定のキーワードや値が引き出される可能性があります。 また、API テストの結果も、テストの理由によって異なります。 開発プロセス中、さらにはポストプロダクションでは、API をテストする場合にも、さまざまな時間があります。 これらのインスタンスはそれぞれ異なる設定が必要な場合があります。

APIで何をロードテストしますか?

要件に関する最初の質問に答えた後、APIが成功したか失敗したかをどのように知るのでしょうか? 次のようなパラメーターを指定して、テスト ケースを設計する必要があります。

• 入力パラメータ
• 期待される出力
• 応答を受信する最大時間
• 入力の解析
• エラー処理
• 適切な応答の書式設定

新しいコード ビルドのたびに、テスト スクリプトに各テスト ケースを含め、正常に実行されることを確認します。 また、各テスト ケースをスケジュールされたロード テストに含めると、API が同時読み込みを処理できることを確認できます。

テスト API をロードする方法: API パフォーマンス テストの種類

以下に示すように、追加の API テスト目標を達成できるテストおよびテストの種類に関する追加の名前が多数あります。 LoadView プラットフォームの性質上、機能テストとロードテスト API やストレス テストに重点を置きます。

統合テスト

統合テストでは、API に対する新しい変更によって、他のモジュールやシステムに問題やバグが発生しないことが保証されます。

ロードテスト

ロード テストにより、運用インフラストラクチャは、システムにアクセスするユーザーの予想数を処理できます。

回帰テスト

回帰テストでは、既存の機能のテストが成功した場合に、新しい変更が悪影響を及ぼすかどうかを判断します。

スケーラビリティテスト

スケーラビリティ テストを使用して、同時ユーザー数の変化に対するシステムの応答方法を確認します。 同時ユーザー数に応じてシステムのスケールアップやスケールダウンが予想され、一貫性のある安定したユーザーエクスペリエンスのために利用されるリソースを調整します。

セキュリティテスト

セキュリティ テストは、システムまたは基盤となるフレームワークの潜在的な脆弱性を悪用しようとします。

UI テスト

UI テストでは、GUI を使用して可能な限りすべてのケースをテストして、正常に機能するようにユーザー インターフェイスのあらゆる側面が期待どおりに機能することを確認します。

機能テスト

機能テストでは、システム要件とユーザー ストーリーを取り、各ユース ケースをテストして、システムが必要なすべてのシナリオを処理できることを確認します。

ストレステスト

ストレス テストは、一般的なユース ケースを使用して、同時にケースの多くの同時インスタンスを実行する可能性があるという点で負荷テストのようなものです。 ストレス テストでは、システムが障害点に達するまで、追加の同時ユーザーをシステムにプッシュし続けるため、負荷テストよりも 1 つのステップ進みます。 システム全体のレベルと、システムの特定のコンポーネントの両方でストレス テストを実行します。 負荷テストとストレステストの違いを調べる素晴らしい記事があります。

What tool is used for API load testing?

使用可能な API ロード テスト ツールがいくつかあります。 例としては、Postman や SoapUI などがあります。 このようなツールは、パイプライン統合、非同期テスト、GUI、チームコラボレーション、そして最も重要なこととして、APIドキュメントの直接生成を提供します。

How do you load test an API?

API のロード テストは、API の明確な定義から始まります。 次に、テストの範囲を確立し、次にテスト手法を適用します。 これらの手法には、値分析、エラー推測、およびテスト ケースを含めることができます。

Why do we test API?

API ロード テストでは、要求を満たすためのデータの送信と出力の受信について説明しますが、最も重要な理由はデータの検証です。 全体的なプロセスは、API がユーザーと正しく対話し、適切な結果を生成するのに役立ちます。

What are the main challenges of API load testing?

API ロード テストの 6 つの主な課題は、テスト シーケンスのほぼ全体に及びます。 API テストの初期設定から始まり、データ検証に向けて API 関数サイクルが実行されます。 追加の課題は、APIテストがデータを正確に追跡することを保証することです。

What are API load testing tools?

APIロードテストツールは、稼働時間、負荷、およびパフォーマンスについてAPIでさまざまなテストを実行するために使用されるさまざまなソフトウェアプログラムまたは ウェブ アプリケーションです。 APIロードテストツールは、通常、企業がAPIのパフォーマンスを検証するために使用し、エンドユーザーが料金を支払っている(または使用している)APIが期待どおりに実行されていることを確認するためにも使用されます。

API テスト用の複数のロード カーブ テスト

 

API テストの要件に応じて、LoadView プラットフォームでは複数の荷重曲線から選択できます。 システムを適切にテストするために必要な同時ユーザー数を増やすロードカーブを実装して、必要なペースでトラフィックをシミュレートする API ロード テストを定義します。

荷重ステップ曲線

[ステップ カーブの読み込み]オプションは、事前に定義された数の同時ユーザーで負荷を生成し、指定した時間に同時に実行するユーザーの数が増加する際の応答時間を確認できるようにします。

目標に基づく曲線

目標に基づく曲線を使用すると、ユーザが必要なトランザクションレートに達するように自動的に調整できます。 この種類のテストは、通常、運用環境でサービス レベル アグリーメント (SLA) を検証するために使用されます。

ダイナミック調整可能曲線

動的調整可能曲線を使用すると、テスト中にリアルタイムでユーザー負荷を変更できます。 事前に決定された同時ユーザー数から始め、定義された最小と最大の間で調整できます。

世界各国の API ロード テスト オプション

世界中のさまざまな地域からの負荷が高い場合、API の可用性をテストします。 LoadView を使用すると、20 以上の地理的地域から任意の方法で負荷を分散できます。 たとえば、ほとんどの顧客が米国の東海岸にいる場合、ロード テストの 60% を東海岸のサーバーから送信し、その他の 40% を他の Google の場所に分散するように選択できます。 なぜあなたはこれをするのですか? 速度が重要であり、実際の顧客に最も近い場所を選択すると、ロード テスト中に実際のユーザーの最も効果的なエミュレーションが提供されるためです。

API ロード テスト

API ロード テスト オプション: ファイアウォールの内側

「なぜ API をテストする」セクションでこれについて簡単に触れましたが、LoadView プラットフォームには、ファイアウォールの内側から、一般に公開されていない API をテストするために利用できる柔軟性もあります。 プラットフォームには、ビジネスの要件に応じて、いくつかの異なるオプションが用意されています。 たとえば、一般的なロード テストでは、ロード インジェクタは動的に開始されるため、IP アドレスは静的ではなく、ロード テストによって異なります。 ただし、ファイアウォールの背後で API ターゲットをテストする必要がある場合、LoadView には、追加の将来のテストのためにこれらのホワイトリストを維持するという利点を備えた静的 IP アドレスを使用してテストを実行するプロキシ オプションが用意されています。

また、内部セキュリティ ポリシーにより、組織がネットワークを外部の負荷インジェクタに開放できない場合、LoadView は、組織が外部トラフィックにネットワークをアクセスできるようにする必要のない、独自のネットワーク内からロード テストを実行するオンサイト エージェント機能を提供します。 ファイアウォールの背後からロード テストを設定および構成する方法の詳細については、 サポート技術情報のページを参照 してください。

負荷の下での API パフォーマンス テスト

ほとんどの API は、正確さと柔軟性についてテストされていますが、API がサポートできる同時接続または同時接続の数を知っていますか。 この質問は、API の結果の正確性を検証するよりも、多くの場合、答えるのが難しくなります。 同時データベース ユーザー、RAM の可用性、ページ ファイル管理、CPU 使用率などの制約により、同時ユーザー数を許容できない場合があります。

LoadView を使用した API のロード テストは、API に複数の呼び出しを連続して送信するスクリプトを作成し、同時ユーザー数を予想されるトラフィックの上限までスケールアップするのと同じくらい簡単です。 スクリプトは再利用可能であり、サービス期間を通じてシステムを監視するために使用できます。 そして、これは間違いなく JMeterのようなツールではできないものです!

API パフォーマンスのボトルネックを見つける

ボトルネック状態を生成できたら、システムが停止する理由を特定できます。 LoadView をメトリックスビューと組み合わせて使用することは、このような減速の原因を特定する優れた方法です。

API キーワードの検証

API サーバーから期待されるキーワードを指定して、成功した応答を確立することもできます。 期待されるキーワードが応答に見つからない場合、個々のテスト セッションにエラーのフラグが付けられます。 最大応答しきい値のタイムアウトを設定することもできるため、API が設定されたしきい値よりも長くかかる場合、テストはエラーを返します。

API 応答時間

ロード テストでは、400 および 500 サーバー エラー応答コードなどのサーバー応答コードも記録されます。 ロード テストの結果を確認すると、グラフに表示される平均テスト応答時間と、レポートを詳しい方法で確認して個々のテスト セッションを確認できます。 これにより、同時ユーザー数を増やすと、平均応答時間がどのように影響を受けるかを視覚化できます。

API レポート データへのドリルダウン

個々のロード テスト セッションを調べて、エラー コードを確認し、DNS traceroute やウォーターフォール チャートなどの追加のトラブルシューティング ツールを使用して、特定の期間内の単一デバイスまたはタスクに対して、サーバー応答のメトリックを使用します。

API パフォーマンスメトリック

API サーバーを監視できるシステム上のファイアウォールの内側に MetricsView プライベート エージェントをインストールすると、API 機能に関連する Windows パフォーマンス カウンターを監視できます。 CPU 使用率、使用可能なメモリ、帯域幅の使用率、SQL データベース トランザクション、ストレージ I/O などのメトリックを測定すると、API がトランザクションをより効率的に完了できないハードウェアまたはソフトウェアのボトルネックがあるかどうかを判断するのに役立ちます。 各セッションの応答時間と、API が各応答で期待される結果を返す検証から構成されるパフォーマンス メトリックを収集します。

ロードビューを使用した RESTful API ロード テスト

 

REST アプリケーションの LoadView テストでは、RESTful API サーバーまたは URL に対する一連の GET/POST 要求を通じて、API と対話するときに実行するステップのリストを定義できます。 一連の API 要求は、Dotcom-Monitor クラウドにスクリプトとして保存され、世界中の数百または数千のロード インジェクタによって同時に実行されるようにキューに登録できます。

複数のリージョンのノードを使用してロード テストを実行すると、ロード テストでの同時接続を、API が平均応答時間の速度を低下し始める時点まで増やすことができます。 さらに、API ロード テストに同時に複数のユーザーを追加すると、最終的には、RESTful 要求がタイムアウトし始める時点で API サーバーに負荷がかかります。 API が一貫してタイムアウトを開始すると、システムのボトルネックを特定できます。

LoadView を使用した API のロード テストは、API に複数の呼び出しを連続して送信するスクリプトを作成し、同時ユーザー数を予想されるトラフィックの上限までスケールアップするのと同じくらい簡単です。 スクリプトは再利用可能であり、サービス期間を通じてシステムを監視するために使用できます。

HTTPS ロード タスク
グローバル構成

異なる地域ゾーン間の仮想ユーザー割り当てを簡単に調整できます。

ロードビュー API ロード テスト

LoadViewは平均的な負荷テストツールではなく、革新的な動的テストソフトウェアです
これにより、システムやインフラストラクチャの見方が変わります。