私たちの戦車。 Yandexでのストレステストの歴史

今日、ストレステストがYandexにどのように現れ、現在開発され、配置されたかを思い出したいと思います。







ちなみに、このストーリーが気に入ったら、11月30日にサンクトペテルブルクオフィスのテスト水曜日に来てください（ 登録 ）-テストのゲームメカニクスについて詳しくお話しします。喜んでお話しします。 だから。



2005年から2006年にかけて、Yandexの非検索インフラストラクチャの一部は、Runetの酵母による成長の負担を経験し始めました。 まず、検索に隣接するサービスのパフォーマンスをテストする必要がありました-バナーツイスト。 当時ストレステストを担当していたTimur Khayrullinは、適切なツールの検索に困惑していました。



しかし、その時点で存在していたオープンソリューションは、非常に原始的（ab /包囲）であるか、生産性が不十分（jmeter）でした。 HP Load Runnerは商用ユーティリティとは一線を画していましたが、ライセンスのコストが高く、プロプライエタリソフトウェアとの結びつきは満足しませんでした。 そのため、高性能ファントムWebサーバーの開発者であるZhenya Mamchitsと一緒に、Timurはトリッキーなトリックを思い付きました。彼らはサーバーにクライアントモードで動作するように教えました。 これが、ファントムベンチマークモジュールの由来です。 ファントムコード自体は現在開いており、ここからダウンロードできます 。また、ファントムに関するストーリーは、プレゼンテーションビデオから見ることができます 。



その後、Phantomは非常にシンプルで、サーバーの最大パフォーマンスのみを測定する方法を知っていたため、スレッド数を制限することしかできませんでした。 しかし、その当時すでに、私たちのユーティリティは、そのアナログよりも生産性が頭と肩にありました。 そのため、負荷テストはますます多くのサービスに向けられ始めました。 2006年から2009年にかけて、負荷テストチームは10人になりました。 「ターゲット」の「タンク」から「カートリッジ」と「シュート」を「テープ」にロードする「タンカー」という名前が非常にすばやく付け加えられました。 戦車のテーマはまだ残っています。 リソースを節約するために、特別な「トレーニング場」または「鶏小屋」を作成し、ストレステスト用に仮想マシンを保持しました。 当時の仮想化プラットフォームはopenvzでしたが、新しいカーネルとubuntuサーバーのディストリビューションのサポートが改善されたため、 lxcに完全に切り替えました。 lxcコミュニティを尊重してください！



着信サービスと負荷テストの人気の高まり、またはむしろサービスチームの自己認識の成長と並行して、ツールの機能の制限について理解が得られました。



開発者の支援と「タンカー」アンドレイ・ババカ・クズミチェフのリーダーシップの下で、ファントムを負荷テストをサポートするための実際のフレームワーク、Lunaparkに開発し始めました。 以前は、ウィキ、JIRA、メールなどでレポートの編成が貧弱だったため、結果は偶然でした。非常に不便でした。この痛い箇所に多くの作業を入れ、徐々にダッシュボードとグラフを備えた実際のWebインターフェイスを取得しました。 JIRAのチケットに関連付けられていたため、すべてのレポートが最終的に均一で明確なデザインになりました。 Webインターフェースは、パーセンタイル、タイミング、平均時間、応答コード、送受信データの量、および約30の異なるグラフと表を表示することを学びました。 さらに、Lunaparkはメール、ジャバー、その他のサービスと接続されていました。 Phantom Load Generator自体も変更に合格しませんでした-彼は以前は知らなかったことの多くを行うことを学びました。 たとえば、スケジュールに従って要求を送信します-線形、段階的、負荷を減らし、ゼロおよび部分負荷を均等に（！）提供します。 データの量、エラー、回答を監視するパーセンタイル付きの出力をコンソール出力に追加しました。 これは、2009サンプルのコンソール出力のようです。







徐々に、一部のサービスを常にテストするだけでなく、リリースごとにそれらのサービスを随時追加する必要があり、テスト同士を比較することも必要であることが理解されました。 これは、ロードテスターの作業に重要なLunaparkページがどのように表示されたかです：テストの比較と回帰。 だから彼らの最初のバージョンが見えた。











テスター、開発者、またはマネージャーはいつでも、パフォーマンスの観点から製品の開発状況を知ることができます。 現在、これらのページの改善とフレームワークの先頭への配置に取り組んでいます。 開発の現在の段階で最も重要なのは、単体テストではなく、生産性の傾向です。



2011年に重要なイベントが発生しました。私たちはYandexで初めてワークフローのゲーミフィケーションを開始した最初のチームになりました。これについては、テスト環境に関する別のレポートを作成します。 現在でも、これは最先端のIT企業ではめったに見られません。 ルナパークのページでは、「殿堂」を掲げており、フレームワークのこの部分を非常に誇りに思っています。 特定のテストについては、負荷テスターに​​本当に親切な「ありがとう」と伝えることができます。 各テスターは、このイベントまたはそのイベントに対して異なるバッジを受け取り、「タンク司令官」（Forskverikの市長）になり、実行されたテストの数に対して発行される「ランク」にさえなります。 日常の仕事の中で、どんな成果や感謝も、金の重さの価値があります。 これは非常にクールな動機です。







2011年は、ストレステストの転換点と考えています。 開発チームは、Pohilkoの下のAndreiが率いていました。 テスターコミュニティは、彼がJmeterの優れたプラグインの開発者であることを知っています。 アンドレイは新鮮なアイデアとアプローチを持ち込みましたが、今では仕事に非常に役立ちます。



まず、古いパラダイムでツールを開発すると「説明する時間はありません。コード」が失敗し、モジュール型開発パラダイムに切り替わります。そこでは、大きなモノリスがコンポーネントに分解され、プロジェクト全体を脅かすことなく個別のパーツで開発されます。 第二に、負荷テストの注文はhttp-trafficに関心のないサービスから開始され始めたため、SMTP / POP3 / FTP / DNSおよびその他のプロトコルをテストできるツールが必要でした。 そのようなサービスごとにファントムロガーを作成するのは費用がかかるように思われたため、Lunaparkに通常のJmeterを構築することにしました。 したがって、少しの労力で、負荷テストで多数の新しいプロトコルをサポートすることを学びました。 埋め込みにより、Jmeter GUIに切り替えることなく標準のWebインターフェースを終了できました。 Jmeterのサポートに加えて、私たちの戦車は最終的にSSL、IPv6、UDP、エリプティック、単一ジェネレーターから複数のアドレスへの「マルチテスト」、分散ジェネレーターから数百万rpの負荷のロードなどをサポートすることを学びました。



ある時点で、負荷テストの注文が非常に少なくなり、明らかになりました。負荷テスターからルーチンテストと回帰テストを削除しないと、毎年スタッフを2倍にすることはできません。 この問題を解決するために、現在のすべての日常業務を分析し、さまざまなテストの深さでサービスにアプローチする必要があることがわかりました。 次の作業スキームを思いつきました。

• プロトタイプまたは実験アセンブリをテストするために、負荷ジェネレーターの疎外バージョンを作成しました。さらに、準備が整ったプロジェクトから負荷のかかる担当者をそらさないために、プロトタイプの負荷テストをデバッグするために開発者またはシステム管理者に推奨し始めました。 結果はLunaparkフレームワークと互換性があり、「abを使用してプロトタイプをテストしましたが、1000 rpを出力し、Lunaparkでは500のみです」という状況はありません。
• 負荷が突然数回増加する可能性がある1回限りのサービスまたはイベントサービス（スポーツ、統一国家試験、ニュース、プロモプロジェクト）をテストするために、既製のバンドルされたサービスが展開されるクイックリフト仮想マシンを維持します。 テストは手動モードで実行され、ロードオブジェクトからリモートテレメトリが削除されます。 プロセスは、最大5〜10人の「タンカー」、開発者、管理者が座れる特別なチャットルームで調整される場合があります。 内部統計によると、手動テストの50％（！）さまざまなパフォーマンスの問題をキャッチします-誤って構築されたインデックス、ファイル操作の「スパイク」、不十分な数のワーカーなど。 最終結果はJIRAによって文書化されます。

テスト用のオンラインページの例。





分析のために、応答時間などのオプションのグラフを含めることができます。







HTTPおよびネットワークエラー：







相互作用とフローのさまざまな段階での時間：







回帰テスト、または結果が開発者または管理者に受け入れられるテストのために、いわゆる自動テストおよび半自動テストを作成しました。 これについては別に話をする必要があります。



2011年の終わりに、実際にはすべてのテスト操作がスクリプト、呼び出し、またはより簡単に何らかの実行メカニズムで実行できることに気付きました。 そのような活動にイデオロギー的に最も近いのは、プロジェクトを組み立て、一連のテストを実行し、イベントについて通知し、合格時に評決を出すことができるCIフレームワークです。 これらのツールのオプションを調べたところ、多くのオープンフレームワークが存在しないことがわかりました。 Jenkinsはプラグインの助けを借りて機能を拡張するのに最も便利であり、Lunaparkの近くでテストした後、テストで実装しました。 特別なAPIと組み込みスケジューラへの外部呼び出しを使用して、テスターのすべてのルーチン作業をJenkinsに移行することができました。 開発者は、「今すぐサービスをテストしてください」という貴重なボタンを受け取りました。ロードコレクターは、参加せずに1日に数十または数百ものテストを受け、管理者とシステム管理者はビルドごとにパフォーマンスの回帰グラフを受け取りました。 現時点では、自動テストが総フローの約70％を占めており、このインジケータは常に成長しています。 これにより、スタッフの数十人が救われ、テスターの知能を手動テストと研究テストに集中させることができます。







熱心な読者は、Lunaparkが徐々に独立した構造を表すようになったことに気付くでしょう。疎外された負荷ジェネレーター、統計とテレメトリのバックエンド、および独立した自動化フレームワークです。 これを見て、baabakaがLunapark について話していたYAC'10で、Runet全体のテスターがあらゆる機会にLunaparkのオープニングで私たちをだまして、Lunaparkの一部をオープンソースにすることを決めました。 2012年の夏、モスクワのYandex.Subbotniksの1つで、テスターのコミュニティにLOADジェネレーターを提供しました 。 現在、jmeterとabサポートが組み込まれた軽いグラフィックスを備えたYandex.Tankは、外部githubでのみ開発され、クラブでのユーザーの質問に答え、開発者からの外部プルリクエストを受け入れます。



Runetのロードテスターのコミュニティは小さく、利用可能な知識は非常に少なく、表面的ですが、それにもかかわらず、生産性のトピックへの関心は高まっています。 したがって、この分野での経験と知識を共有し、負荷、ツール、テスト方法のトピックに関する記事を定期的に発行することをお約束します。