負荷テスト：どこから始めてどこを見るか

おそらく、アプリケーション/サービスがどのように機能するかには、それを使用するユーザーの数に応じて大きな違いがあることをご存じでしょう。 開発中に機能したものは、その環境の最初の実際のユーザーが到着したときにバラバラになる可能性があり、100人のユーザーで機能したものは、1万人のユーザーがいるときに死にます。 または、人工データですべてをテストした後、İnariというユーザーが原因でデータベースの速度が低下し始めることがあります。

Alexei Lavrenyuk（Yandex）およびVladimir Sitnikov（Netcracker）と、バグがどのように生き残るか、プロジェクトに負荷テストを「含める」タイミング、それらのデータを取得する場所、テストをまったく行わずにすぐに実稼働にダンプできるかどうかについて話しました。 。




あなた自身とあなたの仕事についてのいくつかの言葉。 あなたの仕事はテストにどのように関係していますか？

Alexey Lavrenyuk：負荷テストサービスのYandexの開発者です。 パフォーマンステスト用のツールとサービスを作成しています。 オープンソースの負荷テストツールであるYandex.TankとPandora 、および負荷テストのためのサービス-Overloadをご覧ください。 無料のベータ版アクセスが利用可能になりました 。

以前は、サーバーアプリケーションのパフォーマンスしかテストできませんでしたが、現在はモバイルアプリケーションをマスターしています-これは新しいトレンドです。 たとえば、電話の消費電力をテストします。 ここでそれについて読んでください 。

Vladimir Sitnikov：私はNetcrackerで12年間働いています。 今、私は生産性エンジニアの地位を占めています。 製品のテストは行っていませんが、実際の使用時およびテスト時のシステムの動作を観察しています。 私の責任分野には、開発と設計の分野における特定のソリューションが最終結果にどのように影響するかの分析が含まれます。 したがって、私はしばしばテスト結果を見るだけでなく、それを計画します。 これは主にストレステストを指します。

かつて私自身がテストに携わっていましたが、今は過去です。

-理論について少し話しましょう。 テスト段階で問題が発生するのは、タスクの一部のパラメーターを考慮に入れていない開発者や間違ったソリューションを使用している開発者のためだと言うのは正しいですか？

Alexey Lavrenyuk：事前にすべてを予測することはできません。 典型的なサービスには多くの工夫があります。製品の問題を解決するために、さまざまなアルゴリズムを選択し、これらのアルゴリズムのパラメーターを選択し、ライブラリ、フレームワーク、運用中のサービス設定、ハードウェアパラメーターを選択できます。 これらのツイスターを組み合わせると、数十億の組み合わせが生成され、サービスの仕組みを深く理解していなくても、非常に長い間選別できます。 また、実験を行ってその結果を分析するためのツールがない限り、この理解は得られません。

ロードテストは、開発者が非生産的なコードを書くときに頭を悩ますクラブではありません。 これは非常に強力な測定デバイスであり、実際には電子技術者向けのオシロスコープであり、コードをプローブしてその中のボトルネックを見つけることができます。 そして、最適化の後、結果を数値とグラフで表示（および実証）します。

ウラジミール・シトニコフ：追加したいと思います。 「バグはどこから来るのか」は千年紀の問題です。 そして、それは別の興味深い質問と密接に関係しています-なぜ、すべてのテストにもかかわらず、バグは実際のシステムに残ってそこにしか現れないのか。 テスト中にそれらが見つからないのはなぜですか？ タスクを間違って設定していますか？

私の意見では、これは開発チームとサポートチームが異なるためです。 一部の人々は決定を下し、まったく異なる-運用中にそれをサポートします。

生産におけるすべての問題の半分は、2〜3個の愚かな間違いまたは開発の仮定の組み合わせです。誰かが間違ったコードを作成したか、愚かなアルゴリズムを使用したなどです。 そのようなエラー自体は生産性に影響を与えません。最新のハードウェアは非常に強力であり、多くを消化します。 しかし、一緒に、2つまたは3つの間違いが「解雇」されます。 また、開発とサポートが分離されているため、これらのエラーの作成者はそれらについて知りません。

実際、彼らがコードの作者を探して、「もう、それを書く必要はありません。」と言うのはまれです。 しかし、将来そのような間違いをしないことが保証されるためには、開発者はこの経験を積む必要があります。 独自のシステムのサポートがあれば、「詰め込まれたコーン」からの結論がより速くなります。

-早期の負荷テスト（開発段階）で意味がありますか？

Alexei Lavrenyuk：最も費用のかかるエラーは、負荷テストが耳によって完成したプロジェクトに引きずられたときに得られます（コードが実稼働環境でテストされる場合については話していません）。 コードは書かれており、機能しますが、1秒あたり10個の回答（何か）が必要な場合、サービスは1つだけをダイジェストできます。 さらに悪いことに、基盤が非難される場合-「誰もがそれを使用する」または「まあ、それはとても新しくてクールだ」という理由で選択するフレームワークです。 つまり、すべてをすべて書き換える必要があります。

問題が早く検出されるほど、簡単に解決できます。

-つまり、私たちはテストを開発し、同時に開始しますか？

ウラジミール・シトニコフ：はい、いいえ。 早い段階で、何が起こっているかを大まかに見る必要がある場合があります。 それは理にかなっているかもしれません。 しかし、原則として、最初はコードは機能しません。 また、たとえば間違った答えを返すコードのパフォーマンスを測定することは悲惨なことです。 私たちは時間とリソース（マシンのものを含む）を費やし、結果は不明です。

ただし、テストの開始はかなり長い話です。 何かを測定する前に、何を正確に測定し、どのデータを使用するのか、テスト中にこれらのデータに到達するかどうか、再開する方法、監視するメトリックス、結果に関してどのような期待があるかなどを理解する必要があります。 .p。 非常に小さなプロジェクトでは、これらすべてを1日または2日で議論し、適切な決定を下すだけで実行できます。 ただし、多かれ少なかれ大規模なプロジェクトの場合、特にここで顧客との密接な対話が必要なため、このような問題は1日で解決されません。

顧客が最初から特定の要件を満たしている場合もありますが、多くの場合、「接続」負荷テストの段階でのみ策定する必要があります。

したがって、最初からストレステストを検討する必要があります。 そして、負荷テストを最終製品とは考えません。 これは、特定の間違いを避けるために従うべきプロセスです。 ソリューションが作成されると（開発からテスト、出力から実稼働へと直接移行するプロセスで）、負荷テストの目的も変わります。 最初はデバッグに使用され、次にエラーを検出し、最後に、ソリューションの生産準備ができているという基準として使用されます。

ここで、従来のテストとの類推は私にとって適切なようです。 いつオンにする必要がありますか？ 開発の終わりではありません。 開発の最後にテスターが来てすべてを修正するという事実は神話です。 テストでは修正されませんが、エラーを検索します。 負荷テストは、特定の種類のエラーを見つけるためのツールです。 ただし、アルゴリズム分岐に沿ってプログラムを特定のポイントに渡す可能性のみを本質的にチェックする従来のテストとは異なり、負荷テストは生産のベータテストであり、データ、負荷、ミックスのテスト比などの違いにつながります

エラーを正常に見つけるには、検索条件が必要です。 したがって、プロセスとして、負荷テストは開発の開始に近づき、実際、システム全体が正常に動作することを誰かが許可したときに、最初のテストサイクル（自動または手動）の後に条件付きで合格します。

-絶対にすべてをテストしないことは明らかです。 （負荷テストの観点から）最初にどのポイントをテストする必要がありますか？

Alexey Lavrenyuk：まず第一に、重大なシナリオ、つまりお金をもたらすシナリオをテストする必要があります。 さらに、少なくとも2種類のテストを実行します。パフォーマンス制限を決定するためのデバッグと、サービスがSLAに適合することを確認するためのタイミング測定です。 つまり、サービスは「終了」し、実稼働で予想される負荷レベルでタイミングを測定する必要があります。

-ストレステストをどこから開始する必要がありますか？

Alexei Lavrenyuk：ストレステストを開始する前に、機能を実行し、すべてのバグを修正したことを確認する必要があります。 そして、それはあなたの立場です。 撮影の途中で、数百ギガバイトをダウンロードするために誰もブースに来ないようにしてください。 一般的に、誰も煩わさない便利なテスト環境を準備します。

ウラジミール・シトニコフ：テスト自体は、非機能要件の策定から開始する必要があります。 パフォーマンスと安定性の要件。

最も一般的な非機能要件（アプリケーションの最も重要な定量的評価）は、処理されたデータのサイズ、処理時間、および起動の頻度です。 これらのメトリックは、ほとんどすべてのプロジェクトにあります。

「非機能要件」の概念は広範です。 異なるプロジェクトでは、コンポーネントの優先順位が異なる場合があります。 たとえば、「システムは再起動せずに3日間機能する必要があります」または「データベースとの通信が失われ、アプリケーションの復元が2分以内に通常の操作に戻る必要がある場合」-これらも非機能要件です。

ところで、「非機能要件」の概念は、それが独立したものであるという考えを形成します。 しかし実際には、これらの要件は、機能がどのように機能するかを説明しています。 つまり 非機能要件なしでは、ランダムに選択された機能要件にNFRを適用することが不可能であるように、機能要件は意味を失います。

-負荷テストを実施するための一般的な推奨事項はありますか？

ウラジミール・シトニコフ：一般に、負荷テストは通常​​と同じです。 最も重要なシナリオ、または最も恐れているシナリオを取り上げます。 したがって、プロジェクトを理解している人が来て、最も危険なシナリオを指摘する必要があります。 さらに、すでに自動化に取り組んでおり、測定を行っています。

-ストレステストの結果の解釈はどの程度重要ですか？

ウラジミール・シトニコフ：素晴らしい。 重要なのは数字ではなく、その理由を理解することです。 42になっても、これは結果が良好であることを意味しません。 顧客は、1分以内に機能することを要求し、30分かかりました。 私たちはよくやった、反対するのか？ いや！ どうして速くできないのか、何に頼るのかを理解することが重要です。 また、レポートが本物であることを確認する必要があります。

例がありました：仮想マシンがアプリケーションのパフォーマンスにどのように影響するかを測定しました。 ハードウェアで実行されているアプリケーションと仮想マシンで実行されているアプリケーションのパフォーマンスを比較しました。 彼らは測定を行い、（予想に近い）良い数値を取得しました。これは、パフォーマンスの10分の数パーセントの不一致です。 これで、すべてが終わる可能性があります。 しかし、誰かが結果をより注意深く見て、アプリケーションを起動する代わりに、ログインエラーのあるページを返したことに気付きました。 テストでは、実際のアプリケーションは実行しませんでした。 代わりに、各ステップを装って、ログインの速度を確認しました。これにより、間違ったパスワードで失敗が発生しました。

この例は何について話しているのですか？ テスト中に何が起こっていたかを分析せずに、間違った結論に至ったという事実。 したがって、負荷テストの観点から、重要なのは得られた図ではなく、これらの図が説明するものの理解です。

Alexei Lavrenyuk：多くの場合、人々はグラフの重要性を過小評価しています。最終的な統計だけを見てください。 これも行う場合は、Enscombe Quartetをグーグルで検索して、 このオートデスクの記事を参照することをお勧めします 。

インターネット上の多くの一般的な負荷対応ツール（abなど）は、負荷時のサービスのパフォーマンスに関する要約統計と誤った信頼のみを提供します。 それらは詳細を隠し、グラフを浸します。 このような障害は費用がかかる可能性があり（買い手が去った）、それを修正するのは非常に簡単です（ガベージコレクタパラメータを修正する）。

さらに、多くの一般的で高価な耐荷重ツールは、構造的に置き忘れられており、嘘をつきます。 これはこの記事に書かれています 。

-Webサービスの負荷テストの機能は何ですか？ 理論的には、コードだけでなく環境もテストする必要がありますが、これはどのように行われますか？

Alexei Lavrenyuk：興味のあることはすべてテストする必要があります。 アプリケーションのパフォーマンスがモスクワの交通渋滞に依存していると思われる場合は、これをテストする方法を見つけてください。 冗談ではありません。ジオサービスは、トラフィックデータのレベルが7ポイントに達すると、トラフィックデータに対して自動的に負荷テストを実行します。

また、テストにはモバイルアプリケーションがあり、電話が動いている場合にのみアクティブになりました。 つまり、電話はテスト中に揺れなければなりませんでした。 そのため、これらの携帯電話を携帯しました。 特別な電話シャトルを作成するという考えさえありましたが、アプリケーションは修正のために送られ、今までのところ自動化の必要性はなくなりました。

-典型的なプロジェクトのストレステストのデータはどこから来ていますか？ モックまたは生産データは使用されていますか？

ウラジミール・シトニコフ：データに対する典型的なアプローチがあるとは言いません。 プロジェクトはまだ異なります。 システムがデータをまったく保存しないが、特定のチェーンの中間リンクであるものがあります。 それらをテストするには、必要な情報を生成するだけです。 それどころか、システムは何かを保存します。 たとえば、これがレコードの履歴である場合、問題はありません。 ただし、システムが何らかの状態（DBなど）を保存している場合、ニュアンスがここに表示されます。

運用ダンプがない初期段階では、データを生成する必要があります（ビジネス構造について議論し、適切な量の適切なデータタイプを生成します）。 残念ながら、これがうまくいくとは言いません。 生成されたデータを使用すると、しばらく存続できますが、残念ながら、さまざまなシナリオに適した適切なデータを取得することは困難です。 そして、ゲームは、あるタイプのクエリのデータの一部、別のタイプのクエリの一部、第3のクエリの一部を生成するときに始まります。 パーツを生成する方が便利ですが、同時に歪みが発生します：データが多すぎる（シナリオの種類ごとに予約したいため）か、一部のシナリオをスキップします。 このため、遅かれ早かれ、ダンプにほぼ似たものに切り替えます-外部システムからのインポートまたはマスキングを使用した実稼働。

インポートにも問題があります。 私たちは、本番システムのダンプを右から左にコピーできない通信セグメントで働いています。 単純にコピーできない特定の種類のデータがあります。 したがって、システムを動作させる方法を考案する必要がありますが、データはアスタリスクなどに置き換えられています。

-本番環境ですぐにテストして、一部のユーザーを接続する方が簡単ではありませんか？

Alexey Lavrenyuk：私たちの場合、これはテストではなく、きちんとしたリリースです。 良い方法では、常に、テスト後でも、ユーザーのシェアにロールアウトする必要があります。実稼働環境ではすべてがテストとは異なる可能性があるためです。

一部のユーザーを接続することは、ストレステストとどのように異なりますか？ この場合、負荷を完全に管理する能力がなく、サービスを制限までプッシュすることはできません（ユーザーは単に500エラーを受信し始めるだけです）。テストサーバーでできる限り多くのノブを免責して監視することはできません。

一方、ちょっとした空想を得ることができます。運用からのトラフィックの一部をテストサーバーに転送し、そこで負荷対応ツールを使用します。 これは既に負荷テストであり、初期データのみが実稼働環境からリアルタイムで取得されます。

言い換えれば、「保留/保留」応答に満足している場合（およびユーザーの特定の部分を失望させる可能性がある場合）、ストレスをかけてテストすることはできません。 パフォーマンスの限界、ボトルネック、どの監視を検討するのが適切か、最初にどのツイスターをつかみ、誰に実行するかを知りたい場合は、負荷テストを行います。

ウラジミール・シトニコフ：これは私たちの場合ではありません。 問題なく生産をテストする会社があります。 それらには、コードの新しいバージョンにリダイレクトできるクライアントの一部があります。 私たちの場合、顧客のビジネスにとって重要なシステムについて話している。 それが機能しない場合、顧客はお金を失います。 したがって、コードが動作する前に負荷テストが実行されます。

当社のシステムは顧客のビジネスにとって重要であり、多くの場合、顧客の代表者であるまったく異なる人々によってインストールおよびサービスされます。 したがって、当社のお客様は戦闘システムを実験することを望まず、試運転前に負荷テストが実行されます。

-負荷テストを実施するためのお気に入りのツールキットはありますか？

ウラジミール・シトニコフ：もちろんです。 主に3つのツールがあります。サーバー側のテストにはApache JMeterを使用し、ブラウザのテストにはSeleniumを使用し、JavaのテストにはJMHを使用します。 これらのツールは、ほとんどのニーズに対応しています。

, , 2017 Piter. , , web-, real time show «» web- Python Tornado, , , , « », «» «».

, 2017 Piter, .