クラウドアプリケーション向けのサービスメッシュであるLinkerdは、長期間にわたって大量のネットワークトラフィックに対処する義務があります。 次のリリースをリリースする前に、この要件への準拠を慎重に確認する必要があります。 この記事では、負荷テストの戦略と使用したツールについて説明し、発見されたいくつかの問題を見ていきます。 これにより、Goで記述されたオープンソースのストレステストツールであるslow_cookerが導入されます。このツールは、長時間のストレステストを実行し、ライフサイクルの問題を特定するように設計されています。
linkeddは透過プロキシとして機能します。 特定のサービスの要求に、接続プールの使用、フェイルオーバー、再試行、遅延を考慮した負荷分散などが追加されます。 実行可能で産業に優しいシステムであるためには、 リンカードは、変化する環境で長期間にわたって非常に多くのリクエストに対処できなければなりません。 幸いなことに、 linkydは nettyとFinagleに基づいて構築されています。 すべてのネットワークプログラムの中で、そのコードは最も広くテストされており、産業運用中にテストされています。 ただし、コードは1つであり、実際のパフォーマンスは別です。
産業環境でのシステムの動作を評価するために、 linkarddは最も厳格で包括的なストレステストを受ける必要があります。 さらに、 linkarddは基盤となるインフラストラクチャの一部であるため、そのインスタンスが停止または再起動することはほとんどなく、それぞれがサービスとそのクライアントの動作の変化を通じて数十億のリクエストを見逃す可能性があります。 これは、ライフサイクルの問題もテストする必要があることを意味します。 リンカなどの高帯域幅ネットワークサーバーの場合、ライフサイクルの問題には、メモリとソケットのリーク、GCの一時停止、ネットワークとディスクサブシステムの輻輳が含まれます。 このようなことはめったに起こりませんが、適切に解決する方法を学ばなければ、結果は悲惨なものになります。
テスト用のテストソフトウェアは誰ですか？
リンカ開発の初期段階では、人気のあるApacheBenchと負荷テストツールを使用しました 。 （もちろん、それらはHTTPでのみ動作し、リンカはThrift、gRPC、Muxを含むさまざまなプロトコルをプロキシします —しかし、どこかから始めなければなりませんでした。）
残念ながら、パフォーマンスデータを迅速に取得するためのこれらのツールの疑いのない有用性にもかかわらず、特定することを学びたいライフサイクルの問題を特定するのがあまり得意ではないことにすぐに気付きました。 これらのツールは、テストの完了に関する一般的な結果を提供し、このアプローチでは、問題に気付くことはありません。 さらに、それらは平均値と標準偏差に依存していますが、これはシステムパフォーマンスの評価方法としては最善ではありません。
ライフサイクルの問題を特定するには、数分ではなく数時間と数日間の長時間のテストで、より良いメトリックとリンカの動作を確認する機能が必要でした。
穏やかなコードを取得するために、ゆっくり調理します
適切なツールを見つけることができなかったため、私は自分でslow_cookerを作成する必要がありました 。 slow_cookerは、長時間のストレステストを実行し、ライフサイクルの問題を特定するために特別に設計されたストレステストプログラムです。 パフォーマンスの問題を探し、製品の変更をテストするために、 slow_cookerを広範囲に使用します。 slow_cookerには、テストプロセス、変更検出（変更検出）、および必要なすべてのメトリックの進捗に関する増分レポートがあります。
他の人がslow_cookerを使用して開発に参加できるように、今日はそのソースコードを開きます。 GitHubのslow_cookerソースおよび最近リリースされた1.0リリースを参照してください。
slow_cookerが提供する機能について話しましょう。
（簡単にするために、Webサービス自体で直接テストします。もちろん、実際には、 slow_cookerを主に使用して、サービスのサービスではなくリンカーの問題を見つけます。）
ネットワーク遅延のウォークスルー
slow_cookerは、長期にわたって発生するライフサイクルの問題を特定することを主な目的としているため、段階的なレポートの考え方を取り入れています。 非常に大量の入力データの平均値を分析する場合、特にガベージコレクターの動作やネットワークの輻輳などの一時的な現象に関しては、スキップしすぎることがあります。 段階的なレポートの助けを借りて、実行中のシステムでスループットと遅延の変化を直接確認できます。
この例は、 リンカストレステストからのslow_cookerの出力を示しています。 このテストケースでは、linkerdは3つのnginxサーバー間で負荷を分散し、各サーバーは静的コンテンツを配信します。 遅延はミリ秒単位で与えられ、10秒間隔で記録されたmin 、 p50 、 p95 、 p99 、 p999 、および最大遅延を表示します。
$ ./slow_cooker_linux_amd64 -url http://target:4140 -qps 50 -concurrency 10 http://perf-target-2:8080 # sending 500 req/s with concurrency=10 to http://perf-target-2:8080 ... # good/b/ft good% min [p50 p95 p99 p999] max change 2016-10-12T20:34:20Z 4990/0/0 5000 99% 10s 0 [ 1 3 4 9 ] 9 2016-10-12T20:34:30Z 5020/0/0 5000 100% 10s 0 [ 1 3 6 11 ] 11 2016-10-12T20:34:40Z 5020/0/0 5000 100% 10s 0 [ 1 3 7 10 ] 10 2016-10-12T20:34:50Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 8 ] 8 2016-10-12T20:35:00Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 9 ] 9 2016-10-12T20:35:11Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 11 ] 11 2016-10-12T20:35:21Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 9 ] 9 2016-10-12T20:36:11Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 9 ] 9 2016-10-12T20:36:21Z 5020/0/0 5000 100% 10s 0 [ 1 3 6 9 ] 9 2016-10-12T20:35:31Z 5019/0/0 5000 100% 10s 0 [ 1 3 5 9 ] 9 2016-10-12T20:35:41Z 5020/0/0 5000 100% 10s 0 [ 1 3 6 10 ] 10 2016-10-12T20:35:51Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 9 ] 9 2016-10-12T20:36:01Z 5020/0/0 5000 100% 10s 0 [ 1 3 5 10 ] 10
このレポートでは、帯域幅がgood%
列に表示されます。1秒あたりの要求数（RPS、1秒あたりの要求数）にどれだけ近いかです。
このレポートは良さそうです。システムは高速で、応答時間は安定しています。 同時に、どこでいつトラブルが発生したかを明確に確認できるはずです。 slow_cookerの出力は、発生した変更のインジケーターと同様に、垂直方向の配置を使用して問題と外れ値の視覚的な検索を容易にするように設定されています。 非常に遅いサーバーを取得した例を見てみましょう：
$ ./slow_cooker_linux_amd64 -totalRequests 100000 -qps 5 -concurrency 100 http://perf-target-1:8080 # sending 500 req/s with concurrency=10 to http://perf-target-2:8080 ... # good/b/ft good% min [p50 p95 p99 p999] max change 2016-11-14T20:58:13Z 4900/0/0 5000 98% 10s 0 [ 1 2 6 8 ] 8 + 2016-11-14T20:58:23Z 5026/0/0 5000 100% 10s 0 [ 1 2 3 4 ] 4 2016-11-14T20:58:33Z 5017/0/0 5000 100% 10s 0 [ 1 2 3 4 ] 4 2016-11-14T20:58:43Z 1709/0/0 5000 34% 10s 0 [ 1 6987 6987 6987 ] 6985 +++ 2016-11-14T20:58:53Z 5020/0/0 5000 100% 10s 0 [ 1 2 2 3 ] 3 -- 2016-11-14T20:59:03Z 5018/0/0 5000 100% 10s 0 [ 1 2 2 3 ] 3 -- 2016-11-14T20:59:13Z 5010/0/0 5000 100% 10s 0 [ 1 2 2 3 ] 3 -- 2016-11-14T20:59:23Z 4985/0/0 5000 99% 10s 0 [ 1 2 2 3 ] 3 -- 2016-11-14T20:59:33Z 5015/0/0 5000 100% 10s 0 [ 1 2 3 4 ] 4 -- 2016-11-14T20:59:43Z 5000/0/0 5000 100% 10s 0 [ 1 2 3 5 ] 5 2016-11-14T20:59:53Z 5000/0/0 5000 100% 10s 0 [ 1 2 2 3 ] 3 FROM TO #REQUESTS 0 2 49159 2 8 4433 8 32 8 32 64 0 64 128 0 128 256 0 256 512 0 512 1024 0 1024 4096 0 4096 16384 100
ご覧のとおり、システムは2016-11-14T20の1回のヒットを除き、迅速かつ応答的に動作します：58：43Z、その間にスループットは34％に低下し、その後通常に戻りました。 このサービスの所有者は、おそらくログまたはパフォーマンスインジケータを調べて、インシデントの原因を見つけることをお勧めします。
ライフサイクルの問題の例：GCの一時停止
概要データのみを表示する通常のレポートと比較した段階的なレポートの利点を示すために、ガベージコレクターがサーバーで実行される状況をシミュレートしましょう。 この例では、静的コンテンツを配信する単一のnginxプロセスを直接テストします。 ガベージコレクターによる遅延をシミュレートするために、 nginxを5秒間隔でループで一時停止および再開します（ kill -STOP $PID
およびkill -CONT $pid
）。
比較のために、 ApacheBenchからのレポートから始めましょう。
$ ab -n 100000 -c 10 http://perf-target-1:8080/ This is ApacheBench, Version 2.3 <$Revision: 1604373 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking perf-target-1 (be patient) Completed 10000 requests Completed 20000 requests Completed 30000 requests Completed 40000 requests Completed 50000 requests Completed 60000 requests Completed 70000 requests Completed 80000 requests Completed 90000 requests Completed 100000 requests Finished 100000 requests Server Software: nginx/1.9.12 Server Hostname: perf-target-1 Server Port: 8080 Document Path: / Document Length: 612 bytes Concurrency Level: 10 Time taken for tests: 15.776 seconds Complete requests: 100000 Failed requests: 0 Total transferred: 84500000 bytes HTML transferred: 61200000 bytes Requests per second: 6338.89 [#/sec] (mean) Time per request: 1.578 [ms] (mean) Time per request: 0.158 [ms] (mean, across all concurrent requests) Transfer rate: 5230.83 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 0 1 64.3 0 5003 Waiting: 0 1 64.3 0 5003 Total: 0 2 64.3 1 5003 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 1 98% 1 99% 2 100% 5003 (longest request)
ここでは、1.5ミリ秒の遅延があり、いくつかの異常値はより長い遅延を持っています。 このようなレポートは、テスト対象のサービスがチェックに費やした時間の正確に半分のリクエストに応答しなかったとしても、簡単に誤って正常と見なされる可能性があります。 目標のSLA値が1秒の場合、サービスは実行の半分以上にわたってそれを超えましたが、レポートからこれに気付かない場合があります！
slow_cookerの段階的なレポートを見ると、持続的な帯域幅の問題があることがわかります。 ここでは、 P99.9がテスト全体を通して一貫して高い値を持っていることもはるかに明白です。
$ ./slow_cooker_linux_amd64 -totalRequests 20000 -qps 50 -concurrency 10 http://perf-target-2:8080 # sending 500 req/s with concurrency=10 to http://perf-target-2:8080 ... # good/b/ft good% min [p50 p95 p99 p999] max change 2016-12-07T19:05:37Z 2510/0/0 5000 50% 10s 0 [ 0 0 2 4995 ] 4994 + 2016-12-07T19:05:47Z 2520/0/0 5000 50% 10s 0 [ 0 0 1 4999 ] 4997 + 2016-12-07T19:05:57Z 2519/0/0 5000 50% 10s 0 [ 0 0 1 5003 ] 5000 + 2016-12-07T19:06:07Z 2521/0/0 5000 50% 10s 0 [ 0 0 1 4983 ] 4983 + 2016-12-07T19:06:17Z 2520/0/0 5000 50% 10s 0 [ 0 0 1 4987 ] 4986 2016-12-07T19:06:27Z 2520/0/0 5000 50% 10s 0 [ 0 0 1 4991 ] 4988 2016-12-07T19:06:37Z 2520/0/0 5000 50% 10s 0 [ 0 0 1 4995 ] 4992 2016-12-07T19:06:47Z 2520/0/0 5000 50% 10s 0 [ 0 0 2 4995 ] 4994 FROM TO #REQUESTS 0 2 19996 2 8 74 8 32 0 32 64 0 64 128 0 128 256 0 256 512 0 512 1024 0 1024 4096 0 4096 16384 80
パーセンタイル遅延レポート
ApacheBenchの例からわかるように、一部の負荷テストツールは平均値と標準偏差のみを表示します。 ただし、これらのメトリックは通常 、正規分布の法則に従わず、多くの場合非常に長いテールを持つ遅延を推定する場合には不適切です。
slow_cookerでは、平均と標準偏差を使用せず、代わりに最小、最大、およびいくつかの高次パーセンタイル（P50、P95、P99、およびP99.9）を表示します。 このアプローチは、最近のソフトウェアでますます使用されており、1つの要求で他のシステムやサービスへの数十または数百の呼び出しを生成できます。 このような状況では、95パーセンタイルや99パーセンタイルなどのメトリックが一般的な遅延値を提供します。
おわりに
現時点では、ストレステストツールの作成はそれほど難しくありませんが（特に、並列処理のサポートが組み込まれており、Goなどのネットワークでの作業に重点を置いている最新のプログラミング言語を使用している場合）、測定システムとレポート構造の実装が大きく影響する可能性がありますそのようなプログラムの有用性について。
現在、 slow_cookerを広く使用して、 リンカーサービスや他のサービス（nginxなど）をテストしています。 リンカーはさまざまなサービスとの相互作用の条件下で24時間365日モードでテストされており、 slow_cookerは深刻なエラーを伴うコードの展開を防ぐだけでなく、すでに動作しているリリースでパフォーマンスの問題を見つけるのにも役立ちました。 Buoyantでのslow_cookerの使用は広く普及しているため、負荷テストプログラムを「スロークッキング」と呼び始めました。
Githubのリリースページに アクセスして、 slow_cookerの使用を開始できます 。 ツールをダウンロードし、お気に入りのサーバーのテストを開始して、パフォーマンスの問題があるかどうかを確認します。 Linkerd slow_cookerはテストの際に非常に役立ちました。同様に役立つことを願っています。