端末向けバンキングソフトウェアの負荷テストの自動化

この投稿では、ロシアおよび海外の銀行端末の巨大なネットワークに対応するサーバーソフトウェアのテストに焦点を当てます。 銀行の名前を公開することはできません。設定の一部の行は非表示になっています。



そのため、最新のCI / CDアプローチを使用してこのソフトウェアを開発しています。これにより、機能、修正プログラム、リリースを本番環境に高速で配信できます。 年の初めに、テストソリューションに負荷テストを提供し、サブタスクとステップをCI / CDに統合する機能をお客様に示すタスクを提供されました。



一般的な言葉に加えて、ウィッシュリストは次のように要約されています：ロードスタンドでの自動ソフトウェア展開の提供、データを生成する簡単な方法の考案、テストを実行するための自動および半自動の方法の実装、イベントでのテストの自動開始および停止トリガーの装備、NTメカニクスのタスクトラッカーへの短い接続レポート、テストシステムを利用可能なNT分析システムに接続し、ワークフロー内のさらなるアクション（ロールアウトまたは送信）のために良いリリースと悪いリリースを「ペイント」する機能を作成します。 報告する）。 確かに、要件は完全に適切で理解しやすいものです。

自動化

遠くから始めましょう。 私たちは常に同じことを聞きます。「銀行および金融ソフトウェアの負荷テストを自動化することは不可能です！ 関係が多すぎます！ 私たちは非常に複雑です！」 この課題は、問題を解決する興奮を高めただけです。 特定の例で複雑さを常にチェックしたかったのです。



ピラミッドとホーンアイスクリームの形でのテストに関する素晴らしい写真を覚えていますか？ ピラミッドとは、安価な自動ユニットテストが多く、少し高価なUIがある場合です。 アイスクリームホーン-その逆。 ホーンは高価で、遅く、スケールしません;ピラミッドは安価で柔軟です。









システムの相互作用のレベルでソフトウェアの負荷テストを行う代わりに、銀行システム部門では、ワンピースシステムやアプリケーションの時代から一般的に行われているように、すべてのユーザーがUIを通じてテストされます。 それには多くの時間と労力がかかり、それが銀行ソフトウェアの開発を遅くし、低品質でローテクにします。 Jet Infosystemsでは、これらのステレオタイプから解放されました。開発者はコード自体のユニットテストを作成し、機能テスターはSelenium + Cucumberを使用してUIテストを完全にプログラミングしました。 負荷テストの追加段階をプロセスに統合することだけが残っています。

インフラ設計

冒頭で、私たちは、効率的で信頼性の高いコードを開発するという質問に対する答えを複雑にし、侵食する関係を放棄することにしました。 たとえば、操作の承認とトークンの発行はサードパーティシステムの機能であり、タスクの一部としてのパフォーマンスを調査するには過剰です。 さらに、いくつかのバックオフィスシステムとの統合をすぐに拒否し、一定の遅延でシステムに応答するスタブを作成しました（超高速のモックでシステムをテストすることがどれほど危険かを知っています）。

しかし、テストパラダイムの最も重要な変更は、UI端末の負荷テストの拒否です。 これまでは、これは奇妙に思えますが、私たちの前では、このサーバーソフトウェアはUI ATMで徹底的にテストされていました。 それは次のように起こりました：平均的なユーザーがエミュレートされ、中間のポーズ（ペーシング、思考時間）のセットである種のスクリプトプールを通過し、ロードツールは複数のロードジェネレーターからの長い「コールド」スクリプトで構成されるロードを作成することを強制されましたHP Loadrunner。一方、APIサーバーの1つのノードで発生する負荷は、1秒あたりわずか100（！）トランザクションでした。 （数千人の市民が1つの銀行ターミナルのコントロールをクリックしようとする勇敢な写真を残しましょう）。 その結果、ATMバックエンドのパフォーマンスに関係のないほぼすべてのものがスタンドから廃棄されました。









残りのインフラストラクチャを設計および検査した後、プロセスがどのように構築されるか、どのようなメリットが得られるかがほぼ明確になり、NTプロセス自体の作成を開始する必要がありました。

CI / CDプロセスおよびソフトウェア

ソフトウェアコードは、内部gitリポジトリ（GitLab）に配置されます。 特別なトリガーにコミットした後、Jenkinsはコードをアセンブリマシンにプルし、開始されたすべてのユニットテストを実行してリリースをビルドしようとします。 スクリプトを使用したアセンブリの成功後、アセンブルされたビルドは2つのテスト環境（NTおよびFT）にインストールされ、テストの再起動が行われます。 バックエンドを上げると、ジェンキンスはFT、UI、IFTテストを次々に実行します。 負荷テストは個別のタスクとして起動されますが、個別に説明する価値があります。



誰もが知っているように、従来の負荷テストツールは、テストデータジェネレーター、負荷ジェネレーター、結果のアナライザーという3つの「柱」で構成されています。 したがって、3つの方向で問題を解決しました。



関連するAPIリクエストを収集し、変化する仕様の下で毎回XMLを書き換えないために、別の方法で行った-UIテスト実行時に主要な支払いシナリオのTOP-10を「奪取」しました。 これを行うために、テストベンチにtsharkをデプロイし、そこからダンプからXMLを収集します（後でAPIに送信します）。 これにより、テストデータの準備に多くの時間と労力が節約されます。



負荷ジェネレーターとして、 オープンソース市場で最も人気のあるツールであるJMeterを使用しましたが、 Yandex.Tankをバインディングとして使用しました。 JMeterは、ノードあたり毎秒100トランザクションを送信するのに十分な能力を備えており、Tankは自動化の便利さといくつかの便利な機能を提供します-ヒッチハイク、インタラクティブグラフィックス、NTプロセスを再描画せずに他の負荷ジェネレーターを使用する機能など



NT構築の段階で最も難しい部分は分析部分です。 市場でパフォーマンステスト用の独自の分析を作成するための個別のソリューションはないため、 YandexのOverloadを使用することにしました。 過負荷は、ストレステストの結果を保存および分析するためのサービスです。 負荷ジェネレーターから負荷を作成し、結果をサービスにロードして、グラフ形式でそれらを観察します。 現在、サービスはパブリックベータ版であり、YandexはJet Infosystemのパイロットプライベートインスタンスを作成しました。



JMeterからのすべてのデータは集約された形式でオーバーロードに送られ、支払いと顧客に関する個人情報は含まれません。ユーザーにはパフォーマンステストのグラフィック表示のみが表示されます。

最も興味深い

ビルドがロードスタンドに到達すると、Jenkinsのスクリプトを介してロードテスト用の特別なタスクが開始されます。 タスクは、シェルスクリプトとパラメーター化を通じて、古典的な方法で構成されます。



たとえば、この方法でヒッチハイクを構成できます。









これは、Yandex.Tankの設定が次のように見えるものです。









これは、NTプロセス全体を開始するシェルスクリプトの例です。









ご覧のとおり、すべての設定は非常に原始的です。 ジョブが自動的に開始されると、デフォルトのパラメーターが自動的に適用されます。手動で開始した場合、ドキュメントを理解したり、Linuxマシンを掘り下げたり、必要な構成をソートしたりすることなく、Jenkinsパラメーターでシューターを構成できます。



開発者の「ボタンで開始」モードは次のようになります。









テストを開始すると、コンソールビューのJenkinsとTelegramにリンクが表示され、クリックしてリアルタイムで負荷テストを見ることができます。















テスト結果がSLAの範囲外である場合、テストは自動的に停止し、リリースに関する問題について電報、メール、およびJIRAでレポートを受け取ります。 結果が良好な場合、レポートの後、リリースはSUCCESSのステータスを受け取り、本番環境でロードされた環境に展開する準備ができています。



テレグラム画面の画面：









そのため、ボットは結果をJIRAに報告します。









Yandexの企業「グッディー」として、ベンチマーク比較にアクセスできました。









KPIメトリックに関する回帰レポートの作成へのアクセス：

問題と解決策

仕事中につまずいたいくつかの熊手を説明しなかった場合、この話は不完全になります。



モニタリング 明らかに、ストレステスト中は、ビジネスモニタリングツール（トランザクションの検証、キューサイズ、トランジット速度）だけでなく、システムモニタリング（プロセッサの消費、メモリサイズ、ディスク操作の数、自分で発明したメトリックなど）も使用する必要があります。 d。）。 インフラストラクチャ全体がLinux上に構築されている場合（sshに統合されたtelegrafソリューションを使用するとこの問題が解決される）、すべてのデータが統計バックエンドに自動的に注ぎ込まれ、ビジネスメトリックの集計と同期して構築されると便利です。 しかし、Windowsプラットフォーム上に構築されたテスト環境の一部がある場合はどうでしょうか？



さまざまなオプションについて議論し、これに至りました。









この場合、サーバーおよび負荷ジェネレーターからのすべてのメトリックは、ローカルテレグラフエージェントによってInfluxDBに書き込まれ、Yandex.Tankモニタリングは、単純なスクリプトでInfluxDBからデータを抽出し、Overloadにデータをプッシュします。 このアプローチにより、Yandex.Tankによるオペレーティングシステムの動物園全体のサポートを放棄し、「one to all」接続の必要性を回避できます。



次のような簡単なスクリプトを作成します。

from inflow import Client import sys try: connect = Client(sys.argv[1]) try: query_string = "SELECT LAST(" + sys.argv[4] + ") FROM " + sys.argv[3] + " WHERE host='" + sys.argv[2] + "';" result = connect.query(query_string) print (result[0]["values"][0]["last"]) except: print ("Bad request or something wrong with DB. See logs on " + sys.argv[1] + " for details.") except ValueError: print("Something wrong with parameters. " "Usage: python ./influx_picker <http://db_host:port/dbname> <target_host> <group> <metric>") except IndexError: print("Usage: python ./influx_picker <http://db_host:port/dbname> <target_host> <group> <metric>")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この監視構成を使用して、Yandex.TankにInfluxDBからカスタムメトリックを収集させることができます。

  <Monitoring> <Host address="localhost" interval="5"> <Custom diff="0" measure="call" label="cpu_sys">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host cpu usage_system</Custom> <Custom diff="0" measure="call" label="cpu_usr">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host cpu usage_user</Custom> <Custom diff="0" measure="call" label="cpu_iowait">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host cpu usage_iowait</Custom> <Custom diff="0" measure="call" label="mem_free_perc">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host mem available_percent</Custom> <Custom diff="0" measure="call" label="mem_used_perc">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host mem used_percent</Custom> <Custom diff="0" measure="call" label="diskio_read">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host diskio read_bytes</Custom> <Custom diff="0" measure="call" label="diskio_write">python influx_picker.py http://<INFLUXDB_IP>:8086/target_host target_host diskio write_bytes</Custom> </Host> </Monitoring>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、オーバーロードでそのようなグラフを取得します。









報告 2種類のレポート結果を使用しました。



簡単なレポート（時間分布を含む少量のメタ情報と自動停止プラグインからのメッセージ）がメッセージとしてTelegramチャットに送信され、開発者、アーキテクト、マネージャー、テスターが購読しました。



回帰レポート-参照結果との比較が簡単な情報に追加された拡張レポート-は、コメントとしてJIRAに送信されました。



これを行うために、TelegramのGroovyスクリプトと単純なライブラリ（詳細はhttps://pypi.python.org/pypi/jira/ ）を使用してJIRA APIに接続しました。

おわりに

ご覧のとおり、このタスクはRocket Scienceのカテゴリではありません。同様の記事をこちら 、 こちら 、そしてビデオをご覧ください 。 ボンネットの下には通常のスクリプトとサービスがあります-実際、金融セクターは「Devops」および一般的な自動化の時代に長い間準備ができていることを示したかっただけです。



自動化から得られるメリットは何ですか？

1. テスト速度の向上：コミット後最大2時間で結果が得られますが、手動テストには約1〜2週間かかります。
2. 容量使用率の向上：3つの仮想サーバーと約10の物理サーバー（！）。
3. ライセンスコストの増加：Jmeter対Loadrunner、Telegraf対Sitescope / Tivoli、および高いベンダー独立性。

以下の記事では、パフォーマンスとエンジン最適化の観点から、InfluxDBを使用した実験について説明します。 ニュースをフォローしてください！



Jet Infosystemsストレステストチーム。