クラウドのキュウリ：製品ストレステストにBDDスクリプトを使用する

Pixonic DevGAMM Talksによるレポートの別のトランスクリプト。 Anton Kosyakinはテクニカルプロダクトマネージャーであり、ALICEプラットフォーム（ホテルのJiraなど）に取り組んでいます。 彼は、既存のテストツールをプロジェクトに統合する方法、ロードテストが必要な理由、コミュニティが提供するツール、およびクラウドでこれらのツールを実行する方法について説明しました。 以下は、プレゼンテーションとレポートのテキストです。


ALICE Platformと呼ばれる製品を作成しています。負荷テストの問題をどのように解決したかを説明します。



アリスはホテルのジラです。 私たちは、彼らが彼らの内面に対処するのを助けるプラットフォームを構築しています。 コンシェルジュ、フロントオペレーター、クリーナー-チケットも必要です。 例：ゲストが電話をかける>部屋を掃除する必要があると言う>従業員がチケットを作成する>掃除をする人、タスクの配置先を知る>実行>ステータスを変更する。

b2bがあるので、数字は目立たないかもしれません-わずか1,000ホテル、5,000 DAUです。 ゲームの場合、これはそれほど多くありませんが、私たちにとっては非常にクールです。最大8つのprod-serverがあり、これらの5,000人のアクティブユーザーにほとんど対処できないからです。 内部ではわずかに異なることが発生するため、データベース、トランザクションなどの束が発生します。



最も重要なこと：過去1年間で2倍に成長し、現在50人の地域にエンジニアリングチームがあり、2019年にはユーザーベースを2倍にする予定です。 そして、これは私たちが直面する主な課題です。

人生からの例。 金曜日の夜、週60時間の勤務の後、23：00に私は最後の電話を終え、すぐにプレゼンテーションを完了し、電車に飛び乗ってここに来ました。 約5分前、プレゼンテーションを少しやり直しました。 私たちはスタートアップであり、クールだからです。 私が運転している間、技術チームの一部（本番環境では火事と呼びます）がシステムがダウンしないことを確認しようとしましたが、同時にユーザーはこれに気づきませんでした。 彼らは成功し、私たちは救われました。

ご覧のとおり、今のところ夜はあまりよく眠れていません。 私たちはインフラが崩壊することを確信しています。 私たちは真実に直面し、これを理解しています。 一つの質問：いつ？ これが、負荷テストが救いの鍵であることを理解した方法です。 これは私たちが気にする必要があるものです。



私たちの目標は何ですか。 まず、システムの容量とパフォーマンス、現在のユーザーにとってどれだけうまく機能するかを正確に理解する必要があります。 そして、何かが機能していないか非常に遅いという事実のために、ユーザーが私たちとの契約を破る前にこれが起こるはずです（これは150のホテルとたくさんのお金のクライアントになる可能性があります）。 さらに、営業部門には次の計画があります：来年に2倍の成長。 そして、主な競合他社を購入し、ユーザーを自分自身に移行したのです。

そして、これらすべてが耐えられることを知っておく必要があります。 これらのユーザーが来てすべてが落ちる前に、事前に知っておいてください。

リリースも行います。 毎週。 月曜日に。 もちろん、すべてのリリースが機能、どこかでのメンテナンス、どこかでのバグ修正を拡張するわけではありませんが、ユーザーがこれに気付かず、ユーザーの体験が悪化しないことを理解する必要があります。

しかし、私たちは優れた開発者として、怠け者であり、仕事をするのは好きではありません。 そのため、彼らはコミュニティとGoogleに、負荷テストにどのようなサービス/ソリューションがあるかを尋ねました。 たくさんありました。 Apache Benchのように、URL内の100スレッドでサイトを単純にキックするような単純なものがいくつかあります。 マシンガンを搭載した蜂の邪悪で奇妙なバージョンがあり、すべてが同じですが、アプリケーションを飛ばして配置するインスタンスを開始します。 JMeterがあります。そこでは、いくつかのスクリプトを作成し、クラウドで実行できます。



すべてがうまくいくように思えますが、考えた後、私たちは本当に働き、いくつかの問題を最初に解決しなければならないことに気付きました。



最初に、全負荷をシミュレートする実際のシナリオを作成する必要があります。 一部のシステムでは、ランダムデータを使用してランダムAPI呼び出しを生成するだけで十分です。 私たちの場合、これらは長いユーザーシナリオです。電話を受信し、画面を開き、すべてのデータ（だれが望むものを呼び出したか）を保存しました。 次に、リクエストを実行する別の人のモバイルアプリケーションに表示されます。 最も簡単なタスクではありません。

また、毎週リリースしています。 機能が更新され、スクリプトは本当に関連している必要があります。 最初にそれらを作成し、次にそれらをサポートする必要があります。

しかし、それは最大の問題ではありませんでした。 flood.ioを例に取ります。 クールなツールです。Seleniumを実行できます。これは、Chromeが起動したときに制御でき、何らかのスクリプトを実行します。 その中でJMeterスクリプトを実行できます。 しかし、SeleniumをJMeterスクリプト内で実行したい場合、すべてが突然ばらばらになります。これは、Seleniumを組み立てた人が多くのアーキテクチャ上の決定を下したためです。 または、たとえば、一部のサービスはJUnitを実行できます。これは単純で簡単ですが、これらのサービスの1つは独自のJUnitを作成し、いくつかのことを単に無視します。



各ツールは独自の方法で生成を要求するため、負荷生成の問題は緊急です。 そして、シナリオが適切であることを確認できたとしても、疑問が生じます。2〜4倍実行する方法ですか。 どうやら：実行し、すべてが正常です。 しかし、ありません。 これらのリクエストにはあらゆる種類のIDがあります。何かを作成し、新しいIDを取得し、古いIDを変更し、IDによってエンティティをロードし、そのフィールドを別のフィールドに変更します。 また、同じエンティティを10回ロードする10個のテストはあまり面白くありません。 10回は異なるエンティティをロードし、このロードを正しくスケーリングする必要があるためです。

負荷テストの問題を解決して、アプリケーションが耐えるユーザー数を正確に把握し、計画が営業部門の計画と一致していることを確認します。 市場に出ているソリューションを分析し、パスタとスティックのインベントリを作成しました。

毎週リリースを行うので、当然、統合やその他のテストを自動化しました。 これにはキュウリを使用します。 これは、行動駆動型開発のためのBDDフレームワークです。 つまり 手順で構成されるいくつかのシナリオを尋ねます。



インフラストラクチャにより、統合および機能テストを2つのモードで実行できました。バックエンドをキックする、APIを作動させる、または実際にSeleniumを介してChromeを実行して管理するというものです。

NewRelicが大好きです。 サーバー、主な指標を単純に監視できます。 JVMに統合され、コントローラーおよびエンドポイントAPIへのすべての呼び出しをインターセプトします。 また、ブラウザソリューションもあり、ほとんどの機能を備えているため、ブラウザで何かを実行し、何らかのメトリックスを提供します。



したがって、すべてをまとめる必要があります。 主なシナリオはすでに自動化されています。 スクリプト（BDDに似ているため）は実際のユーザーをシミュレートし、負荷は実際の本番に似ています。 同時に、スケーリングすることもできます。 これはリリースプロセスの一部であるため、常に最新の状態に保たれます。



次に、現在市販されているツールを取り上げます。 それらは同じプリミティブで動作します：http、httpのAPI呼び出し、JSON、JUnit、それだけです。 しかし、Cucumberでテストを実行するとすぐに、同じことを行い、同じことを実行しますが、何も機能しません。 私たちはこのタスクにどう対処するかを考え始めました。

余談ですが、BDDはゲーム開発ではあまり一般的な用語ではないため、エンタープライズソリューション向けです。



すべてのシナリオは、実際にある種の動作を説明しています。 シナリオの記述形式は非常に単純です。Gherkinと呼ばれるBDDの観点から、Given、When、Thenの場合です。 キュウリは、アノテーションと属性を使用して、これをJavaコードにマッピングします。 彼はシナリオで彼が見ていることをします。あなたはその人にリンゴを与える必要があります。これを実装する方法を見つけましょう。



次に、機能ロボットのようなコンセプトを導入しました。 これはアプリケーションの特定のクライアントであり、ユーザーのログイン、ログアウト、チケットの作成、チケットのリストの表示などのメソッドがあります。 また、モバイルアプリケーション、Webアプリケーション、およびAPI呼び出しを行う3つのモードで動作します。



簡単に言えば、スライド上の同じものです。 機能ファイルはスクリプトに分割されており、手順があり、これはすべて英語で書かれています。



次に、JavaコードであるCucumberが登場し、これらのスクリプトを実際に実行されているコードにマップします。



このコードはアプリケーションを使用します。



そして、選択した内容に応じて、Selenium Chromeを介してALICEアプリケーションに移動します。



または、HTTP APIを介した同じこと。



そして、（アリュールレポートのYandexのおかげで）これはすべて、私たちに美しく示されています-どれくらいの時間、どのテストが反転し、どのステップで、何かがうまくいかなかったらスクリーンショットを適用します。



ここに、私たちがすでに持っていたものの簡単な要約があります。



これから負荷テストを構築する方法は？ Cucumber Suiteを実行したJenkinsがいました。 これらは私たちのテストであり、ALICEに行きました。 主な問題は何でしたか？ Jenkinsはテストをローカルで実行します;永久に拡張することはできません。 はい、Amazonでホストされています。クラウドで、特大のマシンを要求できます。 とにかく、ある時点で、少なくともネットワークにヒットします。 何らかの方法でこの負荷をロードする必要があります。 アマゾンのおかげで、彼は私たちのために考えました。 Cucumber SuiteをDockerコンテナーにパックし、AWSサービス（Fargateと呼ばれる）を使用して、「それらを起動してください」と言うことができます。 問題は解決し、すでにクラウドでテストを実行できます。



次に、クラウドにいるので、5-10-20 Cucumber Suiteを実行します。 ただし、微妙な違いがあります。すべての機能テストを実行するたびにレポートが生成されます。 400のテストを実行し、400のレポートが生成されました。

オープンソースのYandexのスタッフのおかげで、ドキュメントとソースコードを読み、400のレポートすべてを1つにまとめる方法があることに気付きました。 データをわずかに修正し、いくつかの拡張機能を作成しましたが、すべてうまくいきました。



Jenkinsから、「200個のインスタンスを提供してください」と言います。 特定のオーケストレーションスクリプトがAmazonに送信され、「400のコンテナーを起動する」と言います。 それぞれに統合テストが含まれており、レポートを生成します。レポートはアグリゲーターを介して1ピースに収集され、ジェンキンスに置かれ、ジョブに適用され、非常に機能します。

しかし。

多くの人がテスターから奇妙なことを受け取ったと思います。「ゲームをプレイし、10回ジャンプし、撮影を激しく押して、誤ってシャットダウンボタンを押した-キャラクターが点滅し始め、空中でフリーズし、コンピューターの電源が切れた、これに対処する。」 あなたはまだ人に同意し、あなたが知っている、それは複製することは不可能だと言うことができます。 しかし、魂のないマシンがあり、すべてを非常に迅速に実行し、データがロードされなかった場所、レンダリングが迅速に行われなかった場所、ボタンを押しようとしましたが、ボタンがまだない、またはサーバーからまだダウンロードされていないデータを使用している。 すべてが崩壊し、テストに欠陥があります。 （これに集中したいのですが）Chromeを実行するJavaコードがあります。Chromeは、ラッパーを介して別のJavaに接続し、何かを実行し、それでも超高速で動作します。

さて、これから生じる明らかな問題：5000人のユーザーがおり、機能テストのインスタンスを100のみ起動し、同じ負荷を作成しました。 来月には6,000人のユーザーを予定しているため、これはまさに望んでいたものではありません。 そのような負荷を理解すること、開始するスレッドの数を理解することは困難です。

さて、システムを人間化しましょう。 ユーザーインターフェイスは次のようになります。



誰かが電話をかけていて、コンシェルジュは「新しいチケットを作成する」ボタンを押したいと思っています。ウィンドウが表示され、彼はすべてのフィールドに入力する必要があります。



しかし、これはすぐには起こりません。 マウスに到達するまで、入力を開始するまで、何かを選択するまで、[保存]をクリックするまでの実際の人物。 それではテストを遅くしましょう。



ヒューマンモードと呼びます。 ステップがどれだけ続くかを測定し、速すぎる場合は少し「スリープ」する必要があります。 同時に、原則としてこのステップがどれくらいかかったかを測定できます-5分であれば、おそらくユーザーエクスペリエンスが壊れています。

かなりの数のテストがあったので、このことでそれぞれを書き直すことはしませんでした。 彼らはAspectJを取得し、コードに追加し、さらに5行のコードを追加しました。

短いデモ。







これはタイムラインの実行です。 グリーンテストは良い、どこかが悪い。 アリュールは、反転する場所の詳細を表示します。

そして、ここに多くのインスタンスがあったことを示すタイムラインがあります。 彼らはテストを行い、どこかで落ちました。



このシステムは本当に機能しています。先週、戦闘生産に関する最初のテストを行いました。

次のステップについては、どのように改善できると信じています。



最も重要なことは、人々にクールなユーザーエクスペリエンスを提供することです。 アイデアは、アプリケーションに大きな負荷をかけることができ、すべてが単純であるかのようです-サーバーへの各リクエストのパフォーマンスを、高速で応答し続けるか、パフォーマンスの低下が始まるか（サーバーは着信リクエストの処理をより遅く開始しました） しかし、ありません。 実際には、クライアント/アプリケーションは一度に複数のリクエストをサーバーに一度に投げることができます。 そして、それらがすべて処理されるまで待ちます。 そして、リクエストのいずれかが最長で、5秒間機能し、5秒間機能し続けた場合、他のすべてのユーザーがどのように動作するかはまったく気にしません-高速または4秒まで減速します。 結局のところ、私たちは最長の5秒を待ちます。 または、チケットを作成すると、すべてが1ミリ秒で機能しましたが、内部インデックスキャッシュのためにチケットがシステムに表示されるのが遅すぎました。 通常のアプローチではこの問題を解決できないため、すべてのシナリオを測定し、チケット作成スクリプトが実際にどれだけ悪化したかを確認したいと思います。

なぜなら 使用法に基づいたすべてのシナリオがあり、受付で1人と10人のクリーナーを実行することで模倣できます。 その後、20または30のクリーナー。 しかし、人々の正面はまだ同じです。 つまり 実際の負荷に非常に近い、動作パターンによって実際の負荷を生成できます。

また、複数地域のテスト。 私たちのシステムは世界中で使用されています（すべてがアメリカでホストされていますが）。したがって、ロシアとアメリカの両方から負荷を生成し、どちらがより速く減速し始めるかを確認できます。

聴衆からの質問

-大量のロジックを書くことを余儀なくされ、何かが少し変更されると、機能テストで多くのことを壊します。 テストをサポートするためには、開発するよりもほとんど時間がかかりますか？

「はい、でもいいえ」 これはBDDです。これらは完全に機能的なテストではなく、統合テストに近いものです。 そして、どのような変更を行っても、シナリオは変わりません。 ボタンを押すと、ウィンドウが表示されます。その中に、リクエストを受け取った部屋の番号、人の名前、テーブルを予約する日付を入力します。 レイアウトが変更され、フィールドが逆になり、バックエンドで何かが発生した場合、テストは保存されます。非常に高いレベルにいるため、ブラウザーのボタンを押します。 そのため、多数の変更から保護されています。 すべてが壊れる場合があります。 したがって、リリース手順では、新しい機能を作成する人たち-何かが壊れていることを確認して修正する責任があります。 しかし、これまでのところ、そのような問題は多数ありません。

-そして、1つの変更後にすべてのテストが赤くなる状況はありませんでした。

-そうではなかった。 理論的には、スクリプトにボタンがなく、チケット情報を入力するためのウィンドウを開く他の方法がある場合に発生する可能性があります。 ただし、前に示したように、シナリオはすべてステップで構成されています。 ステップはすべてが多く、同じボタンをクリックする100個のスクリプトがある場合、ステップはまだ1つです。 そして、この特定のステップのためにすべてがダウンした場合、それを修正、書き換え、すべてのテストがすぐに緑色に変わります。

かつて、偶然何かを壊したとき、それは私たちに起こりました。 緑の40％しか残っていませんでしたが、それ以前は99％でした。 それは小さな変化でした。 1ステップ（コードの行）を修正し、すべてが再び緑色になりました。

-統合テストはありませんが、完全に機能するわけではありません。 いずれにせよ、これは何らかのボタンが押されたグラフィカルインターフェイスであり、外部シェルとの相互作用が特に行われます。 この形式のテストがあることを理解しています。同時に多くのスレッドを開始するだけです。 そして、なぜ標準シェル：JMeter、Gatlingによって生成されたリクエストを満たしていないのですか？JMeter、Gatling、これらは外部シェルとは一切やり取りせず、単にリクエストをサーバーに注ぎますか？

-すべてが非常に簡単です。 アプリケーションのアーキテクチャは何ですか？ バックエンドとフロントエンドがあります。 フロントエンドはウェブです。 モバイルアプリケーションがあります。 チケットを作成すると、フロントエンドは、たとえばイベントサーバーにも接続されます。 バックエンドでチケットを作成し、同じホテルに座っているすべての人が同じホテルのチケットを見ると、イベントサーバーから到着します。みんなが更新され、そこでデータが変更されます。 そして、すべてをまとめるために、単一のポイントがあります-これがクライアントです。 多数のさまざまなコンポーネントに接続し、バックエンドでチケットを作成するように手でプログラムしてから、イベントサーバーに接続して登録し、そこからのイベントを待ちます。 , , .

— ? . .

— , , . , Chrome . , , , , , . Chrome — , , . , , Java- . , .

— , , . . , : - ?

— , - . , , , . , , . YouTube , . , . , .

— . - Selenium Grid ? - .

— Cucumber': JAR, JAR Docker image Fargate' , image . flood.io grid Selenium , .

— ? , Chrome, . Internet Explorer 4 ( - ), ? - Android -.

— , enterprise. enterprise , requirements. — , , web view. Android web view , .

— , , Load-? ?

— .



Environment . . , Load, . 4- , , aliceapp.com. Load- , . , 504, , MySQL ElasticSearch.

— ( ), , ? .

— Load- , . つまり .

— , ?

— , . , , , .

— , , .. html API?

— Selenium DOM- : , , key down , — . .

— ? , ?

— . , . QC, , QC. Smoke- -. « -, ». — , , , .

Pixonic DevGAMM Talksとのさらなる講演

• Consulを使用したステートフルサービスのスケーリング （Ivan Bubnov、DevOps at BIT.GAMES）;
• CICD：ダウンタイムなしの分散クラスターシステムへのシームレスな展開 （Egor Panov、Pixonicシステム管理者）;
• Quake Championsゲームのバックエンドプラットフォームでアクターモデルを使用する練習 （Roman Rogozin、バックエンド開発者Sabre Interactive）。
• Tacticoolモバイルオンラインシューターメタサーバーアーキテクチャ （Pavel Platto、PanzerDogのリードソフトウェアエンジニア）;
• ECS、C＃ジョブシステム、SRPがアーキテクチャへのアプローチをどのように変えるか （Valentin Simonov、Unityのフィールドエンジニア）;
• 開発におけるKISS原則 （Konstantin Gladyshev、1C Game Studiosのリードゲームプログラマー）;
• クライアントとサーバーの一般的なゲームロジック （Pixonicの副技術責任者、Anton Grigoriev）。