開発者向けの CI サービスとしての負荷テスト

複数製品のソフトウェア ベンダーがしばしば直面する問題の XNUMX つは、開発者、テスター、インフラストラクチャ管理者などのエンジニアの能力がほぼすべてのチームで重複していることです。 これは、負荷テストの分野の専門家である高価なエンジニアにも当てはまります。

エンジニアは、直接の業務を遂行し、独自の経験を活かして負荷テスト プロセスを構築し、方法論、最適なメトリクスを選択し、負荷プロファイルに従って自動テストを作成する代わりに、多くの場合、テスト インフラストラクチャを最初から展開し、負荷ツールを構成し、それらを埋め込む必要があります。 CI システム内で監視を設定し、レポートを発行します。

組織の問題の解決策は、Positive Technologies で使用されているテストで見つけることができます。 別の記事。 そして今回は、「サービスとしての負荷テスト」(サービスとしての負荷テスト) の概念を使用して、負荷テストを一般的な CI パイプラインに統合する可能性について説明します。 CI パイプラインでロード ソースのどの Docker イメージを使用する方法と使用できるかを学びます。 ビルド テンプレートを使用してロード ソースを CI プロジェクトに接続する方法。 負荷テストを実行して結果を公開するためのデモ パイプラインがどのように見えるか。 この記事は、負荷システムのアーキテクチャを検討している CI のソフトウェア テスト エンジニアや自動化エンジニアにとって役立つ可能性があります。

コンセプトの本質

サービスとしての負荷テストの概念は、負荷ツール Apache JMeter、Yandex.Tank、および独自のフレームワークを任意の継続的統合システムに統合できる機能を意味します。 このデモは GitLab CI 用ですが、原則はすべての CI システムに共通です。

サービスとしての負荷テストは、負荷テストのための一元的なサービスです。 負荷テストは専用のエージェント プールで実行され、結果は GitLab Pages、Influx DB、Grafana、またはテスト レポート システム (TestRail、ReportPortal など) で自動的に公開されます。 自動化とスケーリングは、GitLab CI プロジェクトに通常の gitlab-ci.yml テンプレートを追加してパラメータ化することで、できるだけ簡単に実装されます。

このアプローチの利点は、CI インフラストラクチャ全体、ロード エージェント、ロード ソースの Docker イメージ、テスト パイプライン、およびレポートの発行が集中化された自動化部門 (DevOps エンジニア) によって維持される一方、ロード テスト エンジニアはテスト開発に集中できることです。インフラストラクチャの問題に対処することなく、その結果を分析します。

説明を簡単にするため、テスト対象のターゲット アプリケーションまたはサーバーが事前にデプロイおよび構成されていると仮定します (これには、Python、SaltStack、Ansible などの自動スクリプトを使用できます)。 したがって、サービスとしての負荷テストの概念全体は、次の XNUMX つの段階に当てはまります。 レポートの準備、テスト、発行。 図の詳細 (すべての写真はクリック可能です):

負荷テストの基本概念と定義

負荷テストを実施する際には、次のことを遵守するよう努めます。 ISTQB の標準と方法論、適切な用語と推奨される指標を使用してください。 負荷テストの主な概念と定義の短いリストを示します。

ロードエージェント - アプリケーションが起動される仮想マシン - ロード ソース (Apache JMeter、Yandex.Tank、または自己作成のロード モジュール)。

テストのゴール（目標） - サーバー、またはサーバーにインストールされている負荷のかかるアプリケーション。

テストシナリオ（テストケース） - パラメータ化された一連のステップ: 指定されたパラメータに応じて、固定のネットワーク要求と応答を伴う、ユーザーのアクションとこれらのアクションに対する予想される反応。

プロファイルまたは負荷計画 (プロファイル) - で ISTQB 方法論 (セクション 4.2.4、p. 43) 負荷プロファイルは、特定のテストにとって重要なメトリクスと、テスト中に負荷パラメータを変更するためのオプションを定義します。 図にプロファイルの例を示します。

テスト — 事前に設定されたパラメータのセットを含むスクリプト。

テスト計画 (テスト計画) - 一連のテストと負荷プロファイル。

テストラン (テストラン) - 完全に実行された負荷シナリオと受信したレポートを使用して XNUMX つのテストを実行する XNUMX 回の反復。

ネットワークリクエスト（リクエスト） — エージェントからターゲットに送信される HTTP リクエスト。

ネットワーク応答（応答） — ターゲットからエージェントに送信される HTTP 応答。
HTTP 応答コード (HTTP 応答ステータス) - アプリケーション サーバーからの標準応答コード。
トランザクションは、完全な要求と応答のサイクルです。 トランザクションは、リクエスト（リクエスト）の送信を開始してから応答（レスポンス）の受信が完了するまでカウントされます。

取引ステータス - 要求と応答のサイクルを正常に完了できたかどうか。 このサイクルでエラーが発生した場合、トランザクション全体が失敗したとみなされます。

応答時間（レイテンシ） - リクエスト（リクエスト）の送信が終了してから応答（レスポンス）の受信が開始されるまでの時間。

ロードメトリクス — 負荷テストのプロセスで決定された、負荷されたサービスと負荷エージェントの特性。

負荷パラメータを測定するための基本的なメトリクス

方法論で最も一般的に使用され、推奨されるもののいくつか ISTQB (p. 36、52) 指標を以下の表に示します。 エージェントとターゲットの同様のメトリックが同じ行にリストされます。

ロードエージェントのメトリクス
負荷下でテストされるターゲット システムまたはアプリケーションのメトリクス

数  vCPU そして記憶 RAM,
ディスク - 負荷剤の「鉄」特性
CPU, メモリ、ディスク使用量 - CPU、メモリ、ディスク負荷のダイナミクス
テスト中です。 通常、次の割合として測定されます。
利用可能な最大値

ネットワークスループット (エージェント負荷時) - スループット
サーバー上のネットワークインターフェイス、
ロード エージェントがインストールされている場所。
通常、XNUMX 秒あたりのバイト数 (bps) で測定されます。
ネットワークスループット(目標通り) - ネットワーク インターフェイスの帯域幅
ターゲットサーバー上で。 通常、XNUMX 秒あたりのバイト数 (bps) で測定されます。

仮想ユーザー- 仮想ユーザーの数、
負荷シナリオの実装と
実際のユーザーのアクションを模倣する
仮想ユーザーのステータス、成功/失敗/合計 - 成功した数と失敗した数
仮想ユーザーの失敗ステータス
負荷シナリオとその合計数。

一般に、すべてのユーザーが完了できることが期待されます。
負荷プロファイルで指定されたすべてのタスク。
エラーが発生すると、実際のユーザーは次の操作を行うことができなくなります。
システムを操作する際の問題を解決する

XNUMX 秒あたりのリクエスト数 (分)- XNUMX 秒 (または XNUMX 分) あたりのネットワーク リクエストの数。

ロード エージェントの重要な特性は、生成できるリクエストの数です。
実際、これは仮想ユーザーによるアプリケーションへのアクセスを模倣したものです。
XNUMX 秒あたりの応答数 (分)
- XNUMX 秒 (または XNUMX 分) あたりのネットワーク応答の数。

対象サービスの重要な特徴: 金額
クエリに対する応答を生成して送信します。
ローディングエージェント

HTTP応答ステータス— 異なる応答コードの数
ロード エージェントが受信したアプリケーション サーバーから。
たとえば、200 OK は呼び出しが成功したことを意味します。
および 404 - リソースが見つからなかったこと

レイテンシ (応答時間) - 終了からの時間
応答 (応答) の受信を開始する前に要求 (リクエスト) を送信します。
通常はミリ秒 (ms) 単位で測定されます。

トランザクション応答時間— XNUMX つの完了したトランザクションの時間、
要求と応答のサイクルが完了すること。
リクエスト（リクエスト）の送信開始からの時間です
応答（レスポンス）の受信が完了するまで。

トランザクション時間は秒 (または分) 単位で測定できます。
いくつかの方法で: 最小限を考慮し、
最大値、平均値、およびたとえば 90 パーセンタイル。
最小値と最大値が極端に大きい
システムのパフォーマンスステータス。
XNUMX パーセンタイルが最も一般的に使用されます。
ほとんどのユーザーが表示されているため、
システムパフォーマンスの閾値で快適に動作する

XNUMX 秒あたりのトランザクション数 (分) - 完了した数
XNUMX 秒あたりのトランザクション (分)、
つまり、アプリケーションがどれだけ受け入れることができたか、
リクエストを処理し、レスポンスを発行します。
実際、これはシステムのスループットです。

取引ステータス 、合格 / 失敗 / 合計 - 数
成功、失敗、およびトランザクションの合計数。

実際のユーザーが失敗した場合
トランザクションは実際には次のことを意味します
負荷がかかるとシステムが動作しなくなる

負荷テストの概略図

負荷テストの概念は非常にシンプルで、すでに述べた XNUMX つの主要な段階で構成されています。 テストレポートの準備つまり、テスト目標を準備し、負荷ソースのパラメーターを設定し、次に負荷テストを実行し、最後にテスト レポートを生成して公開します。

回路図のメモ:

• QA.Tester は負荷テストの専門家です。
• Target は、負荷時の動作を知りたいターゲット アプリケーションです。

図内のエンティティ、ステージ、ステップの分類子

段階とステップ
何が起こる
入り口には何がありますか
出力は何ですか

準備: テストの準備段階

ロードパラメータ
設定と初期化
ユーザー
パラメータをロードし、
メトリクスの選択と
テスト計画の準備
(負荷プロファイル)
カスタムオプション
ロードエージェントの初期化
テスト計画
テストの目的

VM
クラウド展開
仮想マシンと
必要な特性
ロードエージェントのVM設定
自動化スクリプト
VMの作成
VM が構成されている
クラウド

環境
OSのセットアップと準備
のための環境
エージェントの作業をロードする
の環境設定
ロードエージェント
自動化スクリプト
環境設定
用意された環境：
OS、サービス、アプリケーション、
仕事に必要な
ロードエージェント

ロードエージェント
インストール、構成、パラメータ設定
積み込みエージェント。
または、から Docker イメージをダウンロードします。
事前構成されたロードソース
ソース Docker イメージをロードする
(YAT、JM、または自作フレームワーク)
設定
ロードエージェント
セットアップして準備完了
作業負荷エージェントへ

テスト: 負荷テストの実行段階。 ソースは、GitLab CI の専用エージェント プールにデプロイされたロード エージェントです

負荷
ロードエージェントの開始
選択したテスト計画を使用して
そしてパラメータをロードします
ユーザーオプション
初期化用
ロードエージェント
テスト計画
テストの目的
実行ログ
負荷テスト
システムログ
目標指標と負荷エージェントの変化のダイナミクス

エージェントの実行
エージェントの実行
大量のテストスクリプト
всоответствиис
負荷プロファイル
ロードエージェントの対話
テストの目的で
テスト計画
テストの目的

ログ
「生」ログの収集
負荷テスト中:
エージェントのアクティビティ記録をロードし、
テスト対象の状態
およびエージェントを実行している VM

実行ログ
負荷テスト
システムログ

メトリック
テスト中に「生の」メトリクスを収集する

目標指標の変化のダイナミクス
そしてエージェントをロードします

レポート：テストレポート作成段階

発生器
収集された処理
ローディングシステムと
モニタリングシステム「生」
メトリクスとログ
でのレポートの作成
人間が読める形式
要素で可能
アナリスト
実行ログ
負荷テスト
システムログ
指標の変化のダイナミクス
ターゲットとロードエージェント
処理された「生」ログ
に適したフォーマットで
外部ストレージにアップロードする
静荷重レポート、
人間が読める

パブリッシュ
報告書の発行
負荷について
外部でのテスト
サービス
加工された「生」
適切な形式のログ
外部への荷降ろし用
ボールト
外部に保存
ストレージレポート
負荷、適切な
人間の分析用

CI テンプレートでのロード ソースの接続

実践的な部分に移りましょう。 社内のいくつかのプロジェクトでその方法を示したい ポジティブテクノロジー 私たちは負荷テストの概念をサービスとして実装しました。

まず、DevOps エンジニアの協力を得て、GitLab CI に負荷テストを実行するための専用のエージェント プールを作成しました。 テンプレート内でアセンブリ プールなどの他のエージェントと混同しないように、これらのエージェントにタグを追加しました。 タグ： ロード。 他のわかりやすいタグを使用することもできます。 彼らが聞く 登録中 GitLab CI ランナー。

ハードウェアごとに必要な電力を調べるにはどうすればよいですか? ロード エージェントの特性 (十分な数の vCPU、RAM、ディスク) は、Docker、Python (Yandex.Tank 用)、GitLab CI エージェント、Java (Apache JMeter 用) がエージェント上で実行される必要があるという事実に基づいて計算できます。 。 JMeter での Java の場合、最低 512 MB の RAM を使用することも推奨されます。上限として、 80% の空きメモリ.

したがって、経験に基づいて、ロード エージェントには少なくとも 4 つの vCPU、4 GB RAM、60 GB SSD を使用することをお勧めします。 ネットワーク カードのスループットは、負荷プロファイルの要件に基づいて決定されます。

私たちは主に XNUMX つのロード ソース、Apache JMeter と Yandex.Tank Docker イメージを使用します。

Yandex.Tank Yandex が提供する負荷テスト用のオープンソース ツールです。 そのモジュラー アーキテクチャは、Phantom の高性能非同期ヒットベースの HTTP リクエスト ジェネレーターに基づいています。 タンクには、SSH プロトコルを介してテスト対象サーバーのリソースを監視する機能が組み込まれており、指定された条件下でテストを自動的に停止でき、結果をコンソールとグラフの両方で表示でき、モジュールを接続できます。機能を拡張するためにそれに接続します。 ちなみにタンクはまだ主流ではなかった頃から使用していました。 記事では「Yandex.Tank と負荷テストの自動化» 2013 年にこれを使用して負荷テストを実行した方法のストーリーを読むことができます PT アプリケーション ファイアウォール 弊社の製品の一つです。

アパッチ JMeter は、Apache のオープンソース負荷テスト ツールです。 これは、静的 Web アプリケーションと動的 Web アプリケーションの両方のテストに同様に使用できます。 JMeter は、HTTP、HTTPS (Java、NodeJS、PHP、ASP.NET など)、SOAP / REST Web サービス、FTP、TCP、LDAP、SMTP(S)、POP3(など、アプリケーションと対話するための膨大な数のプロトコルと方法をサポートしています。 S) ) および IMAP(S)、JDBC 経由のデータベースは、シェル コマンドを実行し、Java オブジェクトを操作できます。 JMeter には、テスト計画を作成、デバッグ、実行するための IDE が備わっています。 Java 互換オペレーティング システム (Linux、Windows、Mac OS X) 上でコマンド ライン操作を行うための CLI もあります。 このツールは、HTML テスト レポートを動的に生成できます。

社内での使いやすさと、テスター自身が環境を変更および追加できるように、ロード ソースの Docker イメージのビルドを GitLab CI 上に作成し、社内に公開しました。 Artifactory の Docker レジストリ。 これにより、負荷テストのパイプラインでの接続がより速く簡単になります。 GitLab CI 経由でレジストリに Docker プッシュを行う方法 - を参照してください。 説明書.

Yandex.Tank 用に次の基本的な Docker ファイルを使用しました。

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

Apache JMeter の場合は次のようになります。

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

当社の継続的インテグレーション システムがどのように機能するかについては、記事「」をご覧ください。開発プロセスの自動化: Positive Technologies で DevOps アイデアをどのように実装したか'。

テンプレートとパイプライン

負荷テストを実施するためのテンプレートの例は、プロジェクトで入手できます。 デモロード。 で Readmeファイル テンプレートの使用手順を読むことができます。 テンプレート自体 (ファイル .gitlab-ci.yml) 各ステップの役割についてのメモがあります。

このテンプレートは非常にシンプルで、上の図で説明されている負荷テストの XNUMX つの段階 (レポートの準備、テスト、公開) を示しています。 この責任者 ステージ: 準備、テスト、レポート.

1. ステージ 準備 テスト ターゲットを事前設定するか、その可用性を確認するために使用する必要があります。 ロード ソースの環境を構成する必要はありません。ロード ソースは Docker イメージとして事前に構築され、Docker レジストリにポストされます。テスト段階で必要なバージョンを指定するだけです。 ただし、それらを再構築して、変更を加えた独自のイメージを作成することはできます。
2. ステージ ホイール試乗 ロード ソースの指定、テストの実行、テスト アーティファクトの保存に使用されます。 ロード ソースは、Yandex.Tank、Apache JMeter、独自のもの、またはすべてを一緒に選択できます。 不要なソースを無効にするには、ジョブをコメントアウトするか削除します。 ロード ソースのエントリ ポイント:
   • Yandex.Tank の起動パラメータは で指定されます。/tests/yandextank.sh,
   • Apache JMeter 起動パラメータはファイルで指定されます ./tests/jmeter.sh.

   注: アセンブリ構成テンプレートは、CI システムとの対話をセットアップするために使用され、そこにテスト ロジックを配置することを意味するものではありません。 テストの場合、制御 bash スクリプトが配置されるエントリ ポイントが指定されます。 テストの実行方法、レポートの生成方法、およびテスト スクリプト自体は、QA エンジニアによって実装される必要があります。 デモでは、両方のロード ソースに対して、Yandex メイン ページ リクエストが最も単純なテストとして使用されます。 スクリプトとテストパラメータはディレクトリにあります ./テスト.

3. ステージ上 レポート テスト段階で取得したテスト結果を外部ストレージ (GitLab Pages や特別なレポート システムなど) に公開する方法を記述する必要があります。 GitLab Pages では、テスト終了後に ./public ディレクトリが空ではなく、少なくともindex.html ファイルを含む必要があります。 GitLab Pages サービスの微妙な違いについては、こちらをご覧ください。 リンク.

   データをエクスポートする方法の例:

   • JMeterからへ GitLab ページ,
   • Yandex.Tank から InfluxDB と Grafana.

   設定手順の投稿:

   • HTML 静的 GitLab ページ,
   • InfluxDB へ、そして次に グラファナ.

デモの例では、負荷テストと XNUMX つの負荷ソース (不要な負荷ソースは無効にできます) を含むパイプラインは次のようになります。

Apache JMeter はそれ自体で HTML レポートを生成できるため、標準ツールを使用して GitLab Pages に保存する方が有益です。 Apache JMeter レポートは次のようになります。

Yandex.Tank のデモの例では、次のようなものだけが表示されます。 偽のテキストレポート GitLab ページのセクションにあります。 テスト中、Tank は結果を InfluxDB データベースに保存し、そこからたとえば Grafana で表示できます (構成はファイルで行われます) ./tests/example-yandextank-test.yml）。 Grafana での Tank のレポートは次のようになります。

サマリー

この記事では、「Load testing as a Service」（サービスとしての負荷テスト）の概念についてお話しました。 主なアイデアは、事前に構成されたロード エージェントのプール、ロード ソースの Docker イメージ、レポート システム、およびそれらを単純な .gitlab-ci.yml テンプレートに基づいて GitLab CI で組み合わせるパイプラインのインフラストラクチャを使用することです (例) リンク）。 これらすべては自動化エンジニアの小規模チームによってサポートされており、製品チームの要求に応じて複製されます。 貴社で同様の制度を準備し、導入する際の参考になれば幸いです。 清聴ありがとうございました！

PS: 当社でのサービスとしての負荷テストの概念の実装に関して技術支援をしていただいた同僚の Sergey Kurbanov 氏と Nikolai Yusev 氏に多大な感謝を申し上げたいと思います。

著者: ティムール・ギルムリン - 副官Positive Technologies のテクノロジーおよび開発プロセス (DevOps) 責任者

出所： habr.com