こんにちは。よっしーです(^^)
今日は、APIの負荷テストについてご紹介します。
背景
Dockerで構築したWebアプリの開発環境において、k6を利用した負荷テストについて調査したときの内容を備忘として残しました。
開発環境のソースは下記のリポジトリにあります。
負荷試験の実施場所
テストを計画する際に、負荷試験の場所(テストを実行するマシン)を考慮する必要があります。場所の指定はテストの要件に基づくことがあります。また、場所は便宜性や実用性に基づいて選択することもあります。どちらの場合でも、負荷生成器の場所を設定する際に以下の点に注意してください:
- 必要な場所: パフォーマンスを比較したり、正確な結果を確保するために、一部の負荷テストは特定の場所からのレイテンシを測定する必要があります。これらのテストは、そのユーザーの地域と一致する場所から負荷生成器を起動します。
- オプションの場所: 他のテストでは、パフォーマンスのベースラインに対する測定を試みます。つまり、システムのパフォーマンスが特定のパフォーマンスステータスや時間からどのように変化するかを測定します。偏ったレイテンシの結果を避けるために、テスト実行間で負荷生成器の場所が一定であることを確認し、SUT(テスト対象システム)に近すぎる場所からテストを実行しないようにします。
内部API
エンドツーエンドのAPIテストは、リアルワールドのユーザーフローを再現しようとします。これには外部システムからの公開APIへのアクセスが含まれます。一方、他のAPIは内部的で外部から到達できない場合もあります。API統合や個別のエンドポイントをテストする際に、内部テストを実行する必要があることは一般的です。
APIが内部環境または制限された環境にある場合、k6を使用していくつかの異なる方法でテストできます:
- k6 runコマンドまたはKubernetesオペレーターを使用して、プライベートネットワークからテストを実行します。オプションで、テスト結果をk6 Cloudや他の外部サービスに保存します。
- クラウドテストの場合:
- クラウドテストトラフィックのためにファイアウォールを開きます。
- プライベートなAWS EC2インスタンスからクラウドテストを実行します。
補助ツール
k6を他のAPIツールと組み合わせて使用することがあります。以下は、k6をさまざまなAPIツールと統合する方法です。
APIツールと統合 REST API周りのツールは多岐にわたりますが、パフォーマンステストにはあまり焦点が当てられていません。k6は、広範なAPIツールエコシステムを負荷テストに組み込むのに役立ついくつかのコンバーターを提供しています。
- Postman-to-k6コンバーター:Postmanコレクションからk6テストを作成します。
postman-to-k6 collection.json -o k6-script.js
- OpenAPI k6ジェネレーター:Open API(以前はSwagger)定義からk6テストを作成します。
openapi-generator-cli generate -i my-api-spec.json -g k6
これらのツールは、k6テストを生成し、通常通りに編集および実行できるようにします。
k6 run k6-script.js
テストタイプに応じて、これらのコンバーターは最初のテストを素早く作成したり、k6への新規ユーザーをオンボードしたりするのに役立つかもしれません。ただし、k6のJavaScript APIに慣れ親しむことをお勧めします。自分自身のテストをスクリプト化することが最良の方法です。
プロキシレコーダーの使用
別のオプションは、記録セッションからk6テストを自動生成することです。これらのスクリプトは、より複雑なエンドツーエンドおよび統合テストの構築を開始するのに役立つかもしれません。
har-to-k6コンバーターは、HTTPトラフィックを収集するHAR形式の記録セッションからk6テストを作成します。
har-to-k6 archive.tar -o k6-script.js
生成されたk6テストは通常通り編集および実行できます。
k6 run k6-script.js
記録セッションをHAR形式にエクスポートするには、FiddlerプロキシやGitLab HARレコーダーなどのプロキシレコーダーを使用します。
前述のコンバーターと同様に、レコーダーはテストのプロトタイプを作成するのに役立つ場合があります。しかし、再度、自分自身でテストスクリプトを書く方法を学ぶことをお勧めします。
HTTP API 以外について
HTTP APIに関するガイドでは、ウェブとREST APIの人気が高いため、HTTP APIに焦点を当てています。ただし、APIはHTTPプロトコルに制限されているわけではありません。
デフォルトでは、k6は以下のプロトコルをサポートしています。
- HTTP/1.1、HTTP/2
- WebSocket
- Redis(実験的)
- gRPC
したがって、これらのプロトコルを使用したAPIのパフォーマンステストもk6を使用して実施できます。
import grpc from 'k6/net/grpc';
import { check, sleep } from 'k6';
const client = new grpc.Client();
client.load(['definitions'], 'hello.proto');
export default () => {
client.connect('grpcbin.test.k6.io:9001');
const data = { greeting: 'Bert' };
const response = client.invoke('hello.HelloService/SayHello', data);
check(response, {
'status is OK': (r) => r && r.status === grpc.StatusOK,
});
client.close();
sleep(1);
};
しかし、現代のソフトウェアはこれらのプロトコルだけに基づいて構築されているわけではありません。現代のインフラストラクチャやアプリケーションは、新しい機能を提供したり、性能、スループット、信頼性を向上させるために他のAPIプロトコルに依存しています。
これらのシステムのパフォーマンスと容量をテストするためには、テストツールがそれらのAPIに対してプロトコル固有のリクエストを生成できる必要があります。
k6が必要なプロトコルをサポートしていない場合、拡張機能(エクステンション)を使用するか、作成することができます。利用可能な拡張機能のリストは長く、以下のようなものがあります:
- Avro
- ZeroMQ
- Ethereum
- STOMP
- MLLP
- NATS
- その他多数
したがって、k6を拡張することで、必要なプロトコルに対するテストを実施することができます。
おわりに
今日は、APIの負荷テストについてご紹介しました。
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント