負荷テスト、プロセス自動化の歴史

こんにちは、Habr！ 私はシステム管理者として働いており、このビジネスとさまざまなプロジェクト（ゲームではなく）の負荷テストの編成と実施を組み合わせています。 たった1人の人だけが負荷に関与していることが起こりました（私です）。



私の会社には同時に複数のスタジオがあり、これらの各スタジオの各ゲームプロジェクトの品質を維持するために、互いに独立してストレステストを実行する必要があります。これにより、このビジネスを最大限に自動化し、手動による参加を最小限に抑える必要が生じました。



私の頭の中のストレステストのプロセスは、いくつかの段階に分かれています。





最初の3つのステップは、単にシステム分析とスクリプト開発です。 次に、最も退屈で長い反復段階が始まります。つまり、それ自体をテストし、結果を分析します。その結果、結果に応じて、最も興味深い部分であるチューニングに進みます。



ただし、チューニングフェーズには数分かかりますが、結果が数時間待機します。 次に、結果を収集して分析する必要がありますが、最近では多くの手作業が必要になりましたが、実際には、プロセス全体をより興味深いものに減らすために、スクリプト開発とチューニングを取り除く必要がありました。

ソースデータ

負荷テストのツールとして、（当然） Apache Jmeterを使用します。



Innogamesプロジェクトは、http、websocket、protobuf、protobuf + STOMP、さらにはudpなど、この製品を使用して（もちろん、多くの場合、独自の追加プラグインを使用して）簡単にエミュレートできるさまざまなプロトコルを使用します。 また、優れた負荷分散システムのおかげで、必要な数のVU（仮想ユーザー）とトラフィックを簡単にエミュレートできます。 たとえば、あるプロジェクトでは、65k VUを上げて3000リクエスト/秒を生成する必要がありました。



当然、すべてのファッションオフィスと同様に、Jenkins CIを使用してテストを実行し始めました。 しかし、結果の分析に関する問題、そして最も重要なことには、結果と以前のテストの結果との比較は非常に関連性がありました。 オンライン監視の問題と同様に、テストはもちろんコンソールモードで実行され、jmeterからのコンソール出力しかありませんが、グラフが必要です。



最初は、ソリューションがどのようにうまく機能したかJenkinsのパフォーマンスプラグイン 。 しかし、各プロジェクトのテスト数の増加と分析用の非常に大きなファイルの出現により（3000リクエスト/秒の3時間テストでは4Gb + CSVファイルが生成されます）、このプラグインは数時間動作し始め、jenkinsでOOMに落ちました。



プロジェクト、データ、利害関係者の数が増え、何かをする必要がありました。

初期決定

既製のソリューションの人生の意味を検索しても、結果は得られませんでした。 著者がpythonとpandas（ データ分析用のライブラリ ）を使用して、方法を説明した1つの記事に出会うまで、彼はJmeterからcsvファイルを分析し、グラフを作成しました。 これを読んで、パンダがギガバイトのファイルを簡単に処理し、そこからデータを集約できることを理解した後、テスト結果を含むHTMLレポートを生成し、 HTML Publisherプラグインを使用してjenkinsで公開する簡単なスクリプトを書きました。



ここにこのスクリプトへのリンクがあります、そこを見てはいけません。



しばらくの間、これで問題は解決しました。 しかし、それは非常に悪い決定でした。ローカルCSVファイルを読み取り、タブレットを作成する多数のロードされた画像とJavaスクリプトがありました。



ある時点で、レポートは長時間（数分）読み込まれ始め、みんなを激怒させ、有名なSaaSの1つである負荷テストプロバイダーとのコラボレーションを検討することを提案しました-そのサービスは無料のJmeterを使用した負荷生成に基づいていますが、彼らはこのビジネスを多額のお金で売り、テストを実行して結果を分析するための便利な環境を提供します。 私はこれらのサービスはあまり好きではありませんが、同じJmeter（たとえば、BlazeMeter）に対しては多くのことをします。



非標準プロトコルをエミュレートして多数のVUを発生させる方法を理解できなかったと言わなければなりませんが、これらすべてのグラフとレポートを使用した負荷テストの便利な環境のアイデアと 、多くの人が同時に使用できるという事実が好きでした。



パンダを念頭に置いて、私は自分のソリューションを試してみることにしました。

解決策

最後に、メイントピックに進みます。 かなりの試行錯誤の中で、Django、HTML、javaスクリプトなどの研究を通じて 、次のソリューションが生まれました。これをInnogames Load Testing Center （以下、 LTC ）と呼びます。



会社の公式GitハブであるJmeter Load Testing Centerから、プロジェクトの開発にダウンロードして参加できます（そこには多くの良いことがあります）。



これはDjango Webアプリケーションであり、Postgresを使用してデータを保存します。 pandasモジュールは、データファイルの分析に使用されます。



次の主要コンポーネントで構成されます（Django言語-アプリケーション）。

• ダッシュボードは、最新の実行中のテストに関する一般情報が記載されたフロントページです。
• アナライザー -ここでレポートを作成し、テスト結果を分析します
• オンライン -テストをオンラインで見ることができます
• コントローラー -ここで、テストを構成および実行できます（開発中）
• 管理者 -さまざまなパラメーター/変数を構成します。

現時点では、Jenkinsはどこにも行っていません。Controllerアプリケーションはまだ開発中です。 しかし、すぐにジェンキンスが交換される可能性があります。



したがって、Hansという名前のユーザーがテストを実行する場合、Jenkinsがプロジェクトを選択して開き、開始を押します。







その後、Jenkinsはメインサーバー上でメインのJmeterインスタンスを起動し（JenkinsとLTC自体が配置されているadmin.loadtestと呼びます）、必要な量の1つ以上のリモート仮想マシン上のJmeterサーバー（これについては後で説明します）を実際に起動しますテストプロセス。



テスト中に、JMeterの結果を含むCSVファイルが作成され、プロジェクトの$ WORKSPACEフォルダー内のデータと、リモートホストの監視データを含む別のCSVファイルで更新されます。

その後、HansはLTCを開き、テストパスをオンラインで見ることができます。 （この時点で、アプリケーションは前述のCSVファイルを解析し、それらをOnlineがグラフを描くデータベース内の一時テーブルに配置します。







または、同じHansはテストの終了まで待機できます。テストの終了時に、特別なスクリプトがデータベース内のすべてのデータを収集し、分析および他の結果との比較にアナライザーで使用できます。







最後の問題は残っています：いくつかのプロジェクトがあり、プロジェクトは負荷を運ぶために異なる容量を必要とします（読み取り、異なる数のVUをエミュレートします）、ユーザーはそれらを同時に実行できますか、しないかもしれません。 すべての利用可能な10の仮想マシンジェネレーターを配布する方法。 各プロジェクトを特定のジェネレーター（当初）に割り当てたり、スケジュールを設定したり、Jenkinsのブロッキングプラグインを使用したり、何か面白いことをしたりできます。 以下について。

一般的なデバイス

私が言ったように、バックエンドはDjangoフレームワークで書かれています。 フロントエンドの開発では、すべての標準ライブラリjqueryとbootstrapを使用しました。 グラフとして、受け取ったデータをJSON形式で簡単に描画するソリューションが必要でした。 C3.jsはこれをうまく処理します。



データベースのテーブルには、通常、キーペアとJSONField（）データ型の1つのフィールドがあります。 JSONFieldが使用されるのは、その後、構造を変更せずにこのテーブルに新しいメトリックを簡単に追加できるためです。



したがって、1つのテスト中に応答時間、エラーの数などのデータを保存する典型的なモデルは非常に単純に見えます。

class TestData(models.Model): test = models.ForeignKey(Test) data = JSONField() class Meta: db_table = 'test_data'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データフィールドのデータ自体は、それぞれ1分間に集約された情報を保存するJSONです。







このテーブルからデータを抽出するために、urls.pyファイルには、このデータを処理し、読みやすいJSONを返す関数を呼び出すエンドポイントが1つあります。

エンドポイント：

 url(r'^test/(?P<test_id>\d+)/rtot/$', views.test_rtot),
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

機能：

 def test_rtot(request, test_id): #  timestamp   min_timestamp = TestData.objects. \ filter(test_id=test_id). \ values("test_id").\ aggregate(min_timestamp=Min( RawSQL("((data->>%s)::timestamp)", ('timestamp',))))['min_timestamp'] #    ,    min_timestamp,     ,   timestamp,   JSON  . d = TestData.objects. \ filter(test_id=test_id). \ annotate(timestamp=(RawSQL("((data->>%s)::timestamp)", ('timestamp',)) - min_timestamp)). \ annotate(average=RawSQL("((data->>%s)::numeric)", ('avg',))). \ annotate(median=RawSQL("((data->>%s)::numeric)", ('median',))). \ annotate(rps=(RawSQL("((data->>%s)::numeric)", ('count',))) / 60). \ values('timestamp', "average", "median", "rps"). \ order_by('timestamp') data = json.loads( json.dumps(list(d), indent=4, sort_keys=True, default=str)) return JsonResponse(data, safe=False)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フロントエンドには、このエンドポイントを参照するc3.jsチャートがあります。

  var test_rtot_graph = c3.generate({ data: { url: '/analyzer/test/' + test_id_1 + '/rtot/', mimeType: 'json', type: 'line', keys: { x: 'timestamp', value: ['average', 'median', 'rps'], }, xFormat: '%H:%M:%S', axes: { rps: 'y2' }, }, zoom: { enabled: true }, axis: { x: { type: 'timeseries', tick: { format: '%H:%M:%S' } }, y: { padding: { top: 0, bottom: 0 }, label: 'response times (ms)', }, y2: { min: 0, show: true, padding: { top: 0, bottom: 0 }, label: 'Requests/s', } }, bindto: '#test_rtot_graph' });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、次のようになります。







実際、アプリケーション全体は、バックエンドの対応するエンドポイントからデータを描画するグラフで構成されています。



テストを分析するためのシステム全体がソースコードからどのように機能するかを確認できます。次に、Innogamesで負荷テストを実行するプロセスを説明します（この部分は、これまでのところ当社にのみ関連しています）。

ファイアー！

負荷テスト環境

前述したように、負荷テスト環境全体は、1つのメインサーバーadmin.loadtestと複数のgeneratorN.loadtestサーバーで構成されています。



admin.loadtest -Debian Linux 9 仮想マシン 、16コア/ 16ギグ、Jenkins、LTCおよびその他の重要でないソフトウェアを実行します。



generatorN.loadtest -Java 8がインストールされた裸のDebian Linux 8仮想マシンパワーは異なりますが、32コア/ 32ギグとしましょう。



admin.loadtestでは、 / var / lib / apache-jmeterフォルダーにインストールされたJmeter（最も基本的なプラグインを備えた最新バージョン）は、事前に組み立てられたdebディストリビューションとしてインストールされます。

Git

各プロジェクトのテスト計画は、InnoGames内のGitLabの個別のプロジェクトにあるため、各チームの開発者またはQAは独自の修正を行うことができます。 そして、各プロジェクトはGitで動作するように構成されています。







各プロジェクトの構成は次のとおりです。



./jmeter_ext_libs/src/

./test-plan.jmx

./prepareAccouts.sh

• jmeter_ext_libs-Gradleを使用してビルドされ、各テストの前に/ var / lib / apache-jmeter / lib / extに配置される追加プラグインのソースフォルダー。
• test-plan.jmx-テスト計画
• * .sh-ユーザーアカウントなどを準備するための追加スクリプト。

テスト計画

各テスト計画は、 スレッドグループとして3つの変数を持つスレッドスレッドのステップを使用します：thread_count、ramp_up、duration：







これらの変数の値は、テストの開始時にJenkinsから取得されますが、最初に、他のすべてのパラメーター化された変数と同様に、ユーザー定義変数のテスト計画のメイン要素で適切に宣言する必要があります。 重要なものの1つ、プールと呼びましょう-使用中のデータプール（ユーザーログインなど）を後で区別するために、実行中のJmeterサーバーごとにシリアル番号が送信されます。







ここで$ {__ P（THREAD_COUNT、1）}：THREAD_COUNTはJenkinsから取得される変数の名前であり、そうでない場合は1がデフォルト値です。



また、各テスト計画には、サンプラーの結果をCSVファイルに書き込むSimpleDataWriterがあります。 次のオプションが有効になっています。

  <time>true</time> <latency>true</latency> <timestamp>true</timestamp> <success>true</success> <label>true</label> <code>true</code> <fieldNames>true</fieldNames> <bytes>true</bytes> <threadCounts> true</threadCounts>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ジェンキンス

テストを開始する前に、各ユーザーは、Jmeterテスト計画の上記の変数に渡されるいくつかのパラメーターを設定できます。

試運転

それでは、スクリプトに移りましょう。 まず、ビルド前スクリプトで、Jmeterディストリビューションを準備します。

• / tmp / jmeter-xvgenq /という形式の一時フォルダーを作成します
• / var / lib / apache-jmeter /からメインディストリビューションをコピーします/
• jmeter_ext_libsフォルダー（存在する場合）から追加のプラグインを収集します。
• 収集した* .jarを/ tmp / jmeter-xvgenq /にコピーします
• 完成した一時配布キットJmeterをロードジェネレーターに拡張します。

 #!/bin/bash export PATH=$PATH:/opt/gradle/gradle-4.2.1/bin echo "JMeter home: $JMETER_HOME" JMETER_INDEX=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 8 | head -n 1) #    JMETER_DIR="/tmp/jmeter-$JMETER_INDEX" echo "JMeter directory: $JMETER_DIR" echo $JMETER_DIR > "/tmp/jmeter_dir$JOB_NAME" mkdir $JMETER_DIR cp -rp $JMETER_HOME* $JMETER_DIR if [ -d "$WORKSPACE/jmeter_ext_libs" ]; then echo "Building additional JMeter lib" cd "$WORKSPACE/jmeter_ext_libs" gradle jar cp ./build/libs/* $JMETER_DIR/lib/ext/ ls $JMETER_DIR/lib/ext/ fi cd $WORKSPACE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、最後のタスクに戻ります：負荷を生成するように設計された10台の仮想マシンがあり（他のプロジェクトのテストが実行されているかどうかもわかりません）、THREAD_COUNTのエミュレートされたスレッドの必要総数に基づいて、これらの仮想マシンで多数のJmeterサーバーを実行する必要があります（異なる）必要な負荷をエミュレートするのに十分です。



スクリプトでは、これはJenkins bashスクリプトの3行の助けを借りて行われます。もちろん、LTC自体のスクリプトのより深刻なものにつながります。

 REMOTE_HOSTS_DATA=`python /var/lib/jltc/manage.py shell -c "import controller.views as views; print(views.prepare_load_generators('"$JOB_NAME"','"$WORKSPACE"','"$JMETER_DIR"', '$THREAD_COUNT', '$duration'));"` THREADS_PER_HOST=`python -c 'import json,sys;data=dict('"$REMOTE_HOSTS_DATA"');print data["threads_per_host"]'` REMOTE_HOSTS_STRING=`python -c 'import json,sys;data=dict('"$REMOTE_HOSTS_DATA"');print data["remote_hosts_string"]'`
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、最初の行で：



prepare_load_generators関数を呼び出し、プロジェクト名、プロジェクトワークスペースディレクトリへのパス、上記で作成した一時Jmeterディストリビューションへのパス（/ tmp / jmeter-xvgenq /）、テスト期間、そして最も重要なエミュレートスレッドの合計数$ THREAD_COUNTを渡します。



一般に次の場合、リポジトリで次に何が表示されますか？

• 指定されたthread_countに基づいて、必要なJmeterサーバーの数Xが、私が考案した式に従って計算されます。
• さらに、マシンgeneratorN.loadtestの現在の負荷と使用可能なメモリに基づいて、これらのマシンのそれぞれで、合計数がXになるまでn番目のJmeterサーバーが起動されます。
• 選択したgeneratorN.loadtestのそれぞれで、rsyncはその一時的なJmeterディストリビューションをロードします。
• 各ジェネレーターで、n番目の数のJmeterサーバー（前の手順で取得）が起動され、シリアル番号プールを実行中の各プロセスに渡してデータプールを配布します（前に書いたように）。
• Jmeterインスタンスの実行に関するすべてのデータはデータベースに保存され、テスト後、すべてのインスタンスはこのデータに基づいて破棄されます。
• 最後に、関数は次の形式のJSONを返します。

  { “remote_hosts_string”: “generator1.loadtest:10000,generator2.loadtest:10000, generator2.loadtest:10001”, "threads_per_host": 100 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際のところ、すべてのJmeterサーバーは実行中であり、それらが接続されるのを待っており、テスト自体が開始されます。 したがって、2行目と3行目では、このJSONから値を取得してメインJmeterインスタンスに渡します。初期値THREAD_COUNTはリモートjmeterサーバー間で分割され、各サーバーにはthreads_per_hostがあります（上記で取得したthread_per_host値をTHREAD_COUNTとして渡します） ：

 java -jar -server $JAVA_ARGS $JMETER_DIR/bin/ApacheJmeter.jar -n -t $WORKSPACE/test-plan.jmx -R $REMOTE_HOSTS_STRING -GTHREAD_COUNT=$threads_per_host -GDURATION=$DURATION -GRAMPUP=$RAMPUP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、$ JMETER_DIRは、一時的なJmeterディストリビューション（/ tmp / jmeter-xvgenq /）があるフォルダーです。



リモートJmeterサーバーを実行するには、独自のモデルがあります。 どのテストが実行されているか、どの仮想マシン、ポート、このプロセスのIDなどに関するデータを保存します。 これらすべては、これらの同じjmeter-serverを破棄する必要がある場合に、テストをさらに停止するために必要です。

 class JmeterInstance(models.Model): test_running = models.ForeignKey(TestRunning, on_delete=models.CASCADE) load_generator = models.ForeignKey(LoadGenerator) pid = models.IntegerField(default=0) port = models.IntegerField(default=0) jmeter_dir = models.CharField(max_length=300, default="") project = models.ForeignKey(Project, on_delete=models.CASCADE) threads_number = models.IntegerField(default=0) class Meta: db_table = 'jmeter_instance'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、フロントページには、実行中のテストと負荷ジェネレーターのステータスに関する情報が記載された特別な美しいプレートがあります。

テスト停止

テスト後、実行中のすべてのJmeterサーバーを破棄し、一時的なJmeterディストリビューションを削除して、結果を収集する必要があります。



ビルド後スクリプトで次を追加します。

 JMETER_DIR=$(cat /tmp/jmeter_dir$JOB_NAME) echo "Removing Jmeter dir from admin: $JMETER_DIR" rm -rf $JMETER_DIR python /var/lib/jltc/manage.py shell -c "import controller.views as views; print(views.stop_test_for_project('"$JOB_NAME"'))"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、メインサーバーから一時的なdistを削除してから、 stop_test_for_project関数を呼び出してプロジェクト名を渡します。 この関数は、実行中のJmeterインスタンスに関する情報を保存し、それらを停止するデータベース内の特別なテーブルを通過します。



最後のステップである結果の収集は、2つの方法で実行でき、スクリプトを実行します。

 python /var/lib/jltc/datagenerator_linux.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、Webサービスをローカルで呼び出します。

 curl --data "results_dir=$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER/" http://localhost:8888/controller/parse_results
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現時点では、スクリプトを使用して、Jancisフォルダー内のすべてのジョブを実行し、データベース内のジョブと比較して、一貫性を保持しています。

オプショナル

LTCでは、いくつかのkronosを構築しました。たとえば、jmeterサーバープロセスのS0U、S1U、EU、およびOUを収集し、メトリックデータの合計をスレッド数で除算するなど、N分ごとに仮想マシンとjmeterインスタンスのjavaプロセスの実行に関する情報を収集するジャブを作成しました実行中-1つのスレッドが消費するメモリの平均サイズを取得します。 メトリックはかなり奇妙であり、または愚かかもしれませんが、特定の数のスレッドをエミュレートするために必要な、Javaプロセスに必要なメモリサイズを大まかに計算するのに役立ちます。

おわりに

もちろん、多くの人がビルトインのJmeterレポートシステムを使用していますが、これも静止しておらず、常に進化しています。 データを保存し、異なるテスト間で結果を比較する必要がある場合、BlazeMeterなどのサービスを使用できます。



私の現実では、これらのサービスは非常に高価であり、負荷を生成するのに十分な容量があるため、「インサイダー」ソリューションを作成しようとしました。



すでに多くのことを知っていますが、完璧にはほど遠い、完璧にはほど遠いです。 だから今、私は同様の問題を抱えている人々がまだいることを望んでいます。



みなさん、ありがとうございました。