はじめに
先日（2023年6月15日）、PostmanのAPIパフォーマンステストが正式にリリースされました。この機能により、Postmanのコレクションに登録されているAPI群に対して、手軽にクライアントから負荷をかけ、APIのパフォーマンスや性能問題などの確認ができるようになりました。PostmanでAPI開発しながら素早くサクッとAPIの性能フィードバックが得られることがこの機能の魅力です。
本記事ではその使い方、注意点・制限などについて簡単にご紹介します。
Postman APIパフォーマンステストを使ってみる
事前準備
APIパフォーマンステストは、2023年6月時点でPostmanデスクトップアプリからのみ利用可能です。まだインストールしていない方はこちらよりダウンロードしてください。
次に、機能紹介で利用するサンプルAPIを用意します。ここではPublished Postman TemplatesというワークスペースにあるPostman Echo APIコレクションをForkして利用します。キーワードPublished Postman Templatesでワークスペース検索すれば見つかります。その中のPostman Echoを自分のワークスペースにForkしてください。これで準備完了です。
コレクションAPIに対してパフォーマンステストを実行する
ここではPostman EchoコレクションのRequest MethodフォルダのAPIを利用します。次のように、サイドバーにあるPostman EchoコレクションのRequest Methodフォルダを選択してください。そして、右側にあるコレクションOverviewタブにあるRunアイコンをクリックしてください。
次のようなコレクションRunnerタブが開きます。なお、PostmanフッターにあるRunnerを選択しても同じタブが開きます。RunnerタブではPerformanceを選択してください。
NOTE: Run Orderについて。パフォーマンステストでは上図のコレクションRunnerに設定されているRun Orderの順番でリクエストが実行されます。この順番はツール上から変更できます。
Performanceタブで、Virtual Users(仮想ユーザー数)、Test Duration(テスト実行時間、分単位)、Load Profile(負荷プロファイル、FixedまたはRamp up)を指定します。Load Profileで負荷のかけ方を指定します。Fixedは仮想ユーザー数を指定した数で固定で、一方、Ramp upは、徐々に仮想ユーザー数を指定した数まで上げていく方式です。Ramp up durationで仮想ユーザー数を徐々に増加させる期間を指定します。
ここでは、下記のように仮想ユーザー数20、実行時間2分で、１分間のRamp upを指定します。Runボタンをクリックしてテストを開始します。
リアルタイムで負荷シュミレーション結果の表示
テストが開始されるとSummaryタブにてリアルタイムで負荷のシュミレーション結果が表示されます。
上のイメージではレスポンス時間のメトリクス（青線）を平均時間で表示させてますが、平均以外にもMax、Min、90、95、99%thでの表示が可能です。また、マウスでホバーさせるとその時間のリクエスト詳細が表示されます。
Errorsタブを選択すると、発生したエラーのステータスと時間が確認できます。今回のテストでは単発で502 Bad Gatewayエラーが発生しただけなのであまり参考にはなりませんが、エラーが大量に発生する場合は、次のようにエラー時間やトレンドなどが確認できトラブルシュート時に有益な情報になるかと思います。
ref: Testing API performance: Viewing error trends
過去のテスト結果を見る
コレクションの過去のテスト実行結果はコレクションのRunsタブで確認できます。パフォーマンステスト結果の場合は、次のようにコレクションを開いて、Runsタブ選択 → Performanceタブ選択で確認できます。
注意点・制約など
利用可能プラットフォーム
上述のとおり2023年6月時点でAPIパフォーマンステストはPostmanデスクトップアプリからのみ利用可能です。Webブラウザ版やCLIからは利用できません。
仮想ユーザー数とシステムリソースについて
Postmanプランごとに使用できる仮想ユーザー数に制限があるので注意が必要です。無料プランの場合は最大100まで、それ以上の仮想ユーザー数は有料プランへアップグレードすることで設定できます。参考記事: Test your API’s performance by simulating real-world traffic with Postman
また、パフォーマンステストでシュミレーションできる仮想ユーザー数は、実行するクライアントマシンのシステムリソース（CPU、メモリ）やテストで使用するコレクションに依存します。コレクションでpre-requestやtest scripts機能を利用しているとシミュレーションできる仮想ユーザーの数が減るようです。詳しくはこちらの説明を参照ください。
さいごに
APIパフォーマンステストは大規模なピークシナリオをテストするための機能ではありません。冒頭の繰り返しになりますが、API開発しながら素早くサクッとAPIの性能フィードバックが得られることができます。これがこの機能の最大の魅力だと思ってます。
みなさんはシステムの信頼性をあげるために日々さまざまなテストを実施しているとおもいますが、パフォーマンステストは中でも割りと手間のかかる部類であり、ソフトウェアライフサイクルにおける比較的後ろのフェーズで実施されがちではないかと思います。ツールやその設定、実行環境などさまざまな準備を要するし、結局リリース前には負荷試験は実施するからそこでまとめてやればよいだろうという意識もあるかもしれません。少なくとも私の場合はそうでした。
しかし、もしリリース直前の負荷試験でパフォーマンス問題が発覚したらどうでしょう？しかも、アーキテクチャやデータ構造の変更を迫られるようなものだとするとそのダメージは大きいですよね？
そのような事態を避けるためには、比較的早い段階でパフォーマンステストが実施されていることが理想です。本番環境に依存する問題だったりエッジケースで発覚するような比較的レアな問題はあるものの、大部分は開発環境やスモールセットの環境テストで潰せる可能性があります。また、テストは手軽にかつ小刻みに実施できるのが理想です。変更のたびに小刻みに実施することで大きな手戻りのリスクも減らせます。APIパフォーマンステストがフィットするのはまさにそこです。
現場からは以上です。