継続的インテグレーションの一部としてのWebサービスパフォーマンステスト。 Yandexの経験

Yandexの新しい従業員のほぼ全員が、当社の製品が経験するストレスの大きさに驚いています。 毎秒数十万のリクエストがある数千のホスト。 そして、これはサービスの1つにすぎません。 同時に、一瞬でリクエストに応答する必要があります。 製品のわずかな変更でもパフォーマンスに大きな影響を与える可能性があるため、サービスに対するコードの影響をテストおよび評価することが重要です。

広告テクノロジーのサービスでは、テストは継続的インテグレーション手法のフレームワーク内で機能します。これは、内部からのYandexイベントで10月25日に開催される組織について詳しく説明します。本日、サービスパフォーマンスに関連する重要な製品メトリックの評価を自動化した経験をHabr読者と共有します。 分析をグラフに委ねるのではなく、分析を機械に任せる方法を学習します。 行こう！

サイトのテスト方法ではありません。 これには多くのオンラインツールがあります。 今日は、高負荷の内部バックエンドサービスについて説明します。これは、大規模システムの一部であり、外部サービスの情報を準備します。 この場合、検索結果ページとパートナーサイト用です。 コンポーネントに応答する時間がない場合、そのコンポーネントからの情報はユーザーに提供されません。 そのため、会社はお金を失います。 したがって、時間通りに応答することが非常に重要です。

強調表示できる重要なサーバーメトリックは何ですか？

• 1秒あたりの要求（RPS） 。 もちろん、1人のユーザーの幸せは私たちにとって重要です。 しかし、1人ではないにしても何千人ものユーザーがあなたに来ました。 サーバーは1秒間にいくつのリクエストに耐えることができますか？
• リクエストごとの時間 。 サイトのコンテンツは、ユーザーが待つことに飽きさせず、ポップコーンの店に行かないように、できるだけ早くレンダリングする必要があります。 私たちの場合、彼はページの情報の重要な部分を見ることはありません。
• 居住者セットサイズ（RSS） 。 プログラムがメモリを消費する量を必ず監視してください。 サービスがすべてのメモリを使い果たした場合、耐障害性について話すことはほとんど不可能です。
• HTTPエラー 。

順番に取得しましょう。

1秒あたりのリクエスト

長い間負荷テストを行ってきた開発者は、システムの重要なリソースについて話すのが好きです。 それが何であるか見てみましょう。

各システムには、作業を決定する独自の構成特性があります。 たとえば、キュ​​ーの長さ、応答タイムアウト、スレッドワーカープールなど。 そのため、サービスの容量がこれらのリソースのいずれかにかかっていることがあります。 実験を行うことができます。 各リソースを順番に増やします。 リソースを増やすと、サービスの容量が増えますが、これは非常に重要です。 適切に構成されたシステムでは、容量を増やすために、1つのリソースではなく、複数のリソースを増やす必要があります。 しかし、これはまだ「感じられます」。 すべてのリソースが完全に機能するようにシステムを構成でき、サービスがシステムに与えられた時間枠内に収まるようにすれば素晴らしいことです。

サーバーが1秒間に耐えられるリクエスト数を見積もるには、リクエストのストリームをサーバーに送信する必要があります。 このプロセスはCIシステムに組み込まれているため、機能が制限された非常に単純な「銃」を使用します。 しかし、オープンソースソフトウェアのYandex.Tankはこのタスクに最適です。 彼は詳細なドキュメントを持っています 。 タンクへの贈り物は、結果を見るためのサービスです。

小さなオフトップ。 Yandex.Tankには、シェル化要求の自動化に限らず、かなり豊富な機能があります。 また、サービスのメトリックを収集し、グラフを作成し、必要なロジックでモジュールを固定するのに役立ちます。 一般的に、彼と知り合うことを強くお勧めします。

ここで、リクエストをタンクに送信して、サービスで発砲できるようにする必要があります。 サーバーのシェルを作成するリクエストは、同じタイプで、人為的に作成および伝播できます。 ただし、一定期間、ユーザーからの実際のリクエストのプールを収集できる場合、測定ははるかに正確になります。

容量は2つの方法で測定できます。

オープンロードモデル（ストレステスト）

「ユーザー」、つまり、システムに要求を送信する複数のスレッドを作成します。 私たちが与えないであろう負荷は一定ですが、それを積み上げるか、波にさえ送ります。 そして、それは私たちを現実の生活に近づけます。 RPSを増やし、シェルサービスがSLAを「突破」するポイントをキャッチします。 したがって、システムの限界を見つけることができます。

ユーザー数を計算するには、リトル式を使用できます（詳細については、 こちらを参照してください ）。 理論を省略すると、式は次のようになります。

RPS = 1000 / T *ワーカー、ここで

•T-平均リクエスト処理時間（ミリ秒単位）。

•ワーカー-スレッドの数。

•1000 / Tリクエスト/秒-この値は、シングルスレッドジェネレーターによって生成されます。

閉じた負荷モデル（負荷テスト）

固定数の「ユーザー」を採用しています。 サービスの構成に対応する入力キューが常に詰まるように構成する必要があります。 同時に、スレッドの数をキューの制限より大きくすることは意味がありません。この数にとどまり、残りのリクエストは5xxエラーでサーバーによって破棄されるためです。 デザインが発行できる1秒あたりのリクエスト数を調べます。 一般的な場合のこのようなスキームは、リクエストの実際のフローとは異なりますが、最大負荷でのシステムの動作を示し、現時点でのスループットを推定するのに役立ちます。

大部分のシステム（重要なリソースが接続処理に関連していない場合）の場合、結果は同じになります。 同時に、システムはテスト中ずっと関心のある負荷領域にあるため、閉じたモデルのノイズは少なくなります。

サービスをテストするときは、閉じたモデルを使用します。 射撃後、銃は私たちのサービスが発行できる1秒あたりのリクエスト数を提供します。 Yandex.Tankこのインジケーターもわかりやすいです。

リクエストごとの時間

前の段落に戻ると、このようなスキームでは、リクエストに対する応答時間を評価することは意味がないことが明らかになります。 システムの読み込みが強いほど、システムの劣化が大きくなり、応答時間が長くなります。 したがって、応答時間をテストするには、アプローチが異なる必要があります。

平均応答時間を取得するには、同じYandex.Tankを使用します。 ここでのみ、運用中のシステムの平均に対応するRPSを設定しましょう。 シェル処理後、各リクエストの応答時間を取得します。 収集されたデータに基づいて、応答時間のパーセンタイルを計算できます。

次に、重要なパーセンタイルを理解する必要があります。 たとえば、実稼働環境で構築します。 エラー、無回答、長時間動作するデバッグリクエスト、ネットワークの問題などのリクエストの1％を残すことができます。 したがって、99％の要求に対応する応答時間を大幅に考慮します。

居住者セットサイズ

サーバーはmmapを介してファイルを直接処理します。 RSSインデックスを測定して、動作中にプログラムがオペレーティングシステムからどれだけのメモリを消費したかを知りたいと思います。

Linuxでは、ファイル/ proc / PID / smapsが書き込まれます-これは、各プロセスマッピングのメモリ消費を示すマップベースの拡張機能です。 プロセスがtmpfsを使用する場合、匿名メモリと非匿名メモリの両方がsmapに入ります。 非匿名メモリには、たとえば、メモリにロードされたファイルが含まれます。 smapsのエントリの例を次に示します。 特定のファイルが指定され、そのパラメーターは匿名= 0kBです。

7fea65a60000-7fea65a61000 r--s 00000000 09:03 79169191 /place/home/.../some.yabs Size: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 4 kB Private_Dirty: 0 kB Referenced: 4 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd mr me ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは匿名のメモリ割り当ての例です。 プロセス（同じmmap）がオペレーティングシステムに特定のサイズのメモリを割り当てる要求を行うと、アドレスが割り当てられます。 プロセスは仮想メモリのみを占有します。 この時点では、どの物理メモリが割り当てられるかはまだわかりません。 名前のないレコードがあります。 これは、匿名メモリを割り当てる例です。 システムは24572 kBのサイズを要求されましたが、使用しなかったため、実際にはRSS = 4 kBのみが使用されました。

 7fea67264000-7fea68a63000 rw-p 00000000 00:00 0 Size: 24572 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd wr mr mw me ac
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロセスが停止した後、割り当てられた非匿名メモリはどこにも移動しないため、ファイルは削除されません。そのようなRSSには興味がありません。

サーバーでの撮影を開始する前に、匿名メモリに割り当てられている/ proc / PID / smapsからのRSSをまとめて記憶します。 リクエストごとのテスト時間と同様に、シェルを実行します。 終了したら、もう一度RSSを検討してください。 初期状態と最終状態の違いは、プロセスが操作中に使用したメモリ量です。

HTTPエラー

テスト中にサービスが返す応答コードに従うことを忘れないでください。 テストまたは環境のセットアップで何かがうまくいかず、サーバーがすべてのリクエストに対して5xxおよび4xxエラーを返した場合、そのようなテストにはあまり意味がありませんでした。 悪い反応の割合を監視しています。 エラーが多い場合、テストは無効と見なされます。

測定精度について少し

そして今、最も重要なこと。 前のパラグラフに戻りましょう。 私たちが計算したメトリックの絶対値は、私たちにとってそれほど重要ではないことがわかりました。 いいえ、もちろん、すべての要因、エラー、変動を考慮して、インジケーターの安定性を達成できます。 並行して、このトピックに関する科学的な記事を書きます（ところで、誰かが探しているなら、これは良い選択肢かもしれません）。 しかし、これは私たちの関心事ではありません。

システムの以前の状態に関連するコードの特定のコミットに影響を与えることが重要です。 つまり、コミットごとのメトリックの違いは重要です。 そして、ここでは、この差を比較し、同時にこの間隔で絶対値の安定性を確保するプロセスを設定する必要があります。

環境、リクエスト、データ、サービスステータス-利用可能なすべての要因を修正する必要があります。 継続的インテグレーションの一部として機能するのはこのシステムであり、各コミット内で発生したあらゆる種類の変更に関する情報を提供します。 それにもかかわらず、すべてを修正することは不可能であり、ノイズがあります。 サンプルを増やすことで、つまり、撮影を何度か繰り返すことで、明らかにノイズを減らすことができます。 さらに、たとえば15回の繰り返しを撮影した後、結果のサンプルの中央値を計算できます。 さらに、ノイズと撮影時間のバランスを見つける必要があります。 たとえば、1％の誤差に落ち着きました。 要件に応じてより複雑で正確な統計方法を選択する場合は、使用するタイミングと使用方法の説明が記載されたオプションをリストした本をお勧めします。

ノイズで他にできることは何ですか？

テストを実施する環境は、そのようなテストで重要な役割を果たすことに注意してください。 テストベンチは信頼性が高く、他のプログラムを実行しないでください。サービスが低下する可能性があります。 さらに、結果は負荷プロファイル、環境、データベース、およびさまざまな「磁気嵐」に依存する可能性があります。

単一のコミットテストの一環として、異なるホストで複数の反復を実行します。 まず、クラウドを使用すると、そこで何が起こるかわかりません。 クラウドが私たちのように特殊化されていても、サービスプロセスはそこで機能します。 したがって、1つのホストからの結果に依存することはできません。 また、クラウドのように環境を高める標準的なメカニズムがない鉄のホストがある場合は、誤って一度壊してそのままにしておくこともできます。 そして彼はいつもあなたに嘘をつきます。 したがって、クラウドでテストを実行します。

確かに、これから別の疑問が生じます。 異なるホストで毎回測定が行われると、結果に多少のノイズが生じる場合があります。 次に、測定値をホストに正規化できます。 つまり、履歴データに従って、「ホスト係数」を収集し、結果を分析するときにそれを考慮します。

履歴データを分析すると、ハードウェアが異なっていることがわかります。 ここで言う「ハードウェア」という語には、カーネルバージョンと稼働時間の影響（明らかに、メモリ内で移動可能なカーネルオブジェクトではない）が含まれます。

したがって、各「ホスト」に（再起動すると、ホストが「死に」、「新しい」が表示されます）、修正前にRPSを乗算する修正を関連付けます。

私たちは非常に不器用な方法で修正を検討し、更新します。これは、一部の強化トレーニングオプションを疑わしく連想させます。

ポストホスト補正の特定のベクトルについて、目的関数を考慮します。

• 各テストでは、得られた「修正された」RPS結果の標準偏差を考慮します
• 等しい重みでそれらから平均を取る $$$exp（（testtimestamp-now）/ tau）$ 、
• タウ= 1週間です。

次に、1つの修正を修正し（これらの重みの合計が最大であるホストに対して）、1.0に修正し、目的関数の最小値を与える他のすべての修正の値を探します。

履歴データの結果を検証するために、古いデータの修正を考慮し、新しいデータの修正結果を考慮し、未修正と比較します。

結果を調整してノイズを減らす別のオプションは、「合成」に正規化することです。 テストするサービスを開始する前に、ホストで「合成プログラム」を実行します。このプログラムから、ホストの状態を評価し、補正係数を計算できます。 しかし、私たちのケースでは、ホストベースの修正を使用していますが、このアイデアはアイデアのままです。 おそらくあなたの一人が彼女を好きになるでしょう。

自動化とそのすべての利点にもかかわらず、インジケーターのダイナミクスを忘れないでください。 サービスが時間の経過とともに低下しないようにすることが重要です。 小さなドローダウンに気付かない場合がありますが、それらは蓄積する可能性があり、長期間にわたってインジケーターがたるむ場合があります。 以下は、RPSで見ているグラフの例です。 チェックされた各コミットの相対値、その数、およびリリースの割り当て元を確認する機能が表示されます。

この記事を読むと、Yandex.Tankに関するレポートと負荷テストの結果の分析を見るのは間違いなく興味深いでしょう 。

また、継続的インテグレーションの組織の詳細については、10月25日のYandexイベントの内部について説明します。 訪問してください！