SRE: パフォーマンス分析。 Goでの簡易Webサーバーを使った設定方法

パフォーマンスの分析とチューニングは、クライアントのパフォーマンスのコンプライアンスを検証するための強力なツールです。

パフォーマンス分析を使用すると、科学的アプローチをチューニング実験のテストに適用することで、プログラム内のボトルネックをチェックできます。 この記事では、Go Web サーバーを例として使用して、パフォーマンス分析とチューニングへの一般的なアプローチを定義します。

Go にはプロファイリング ツールがあるため、ここでは特に優れています pprof 標準ライブラリにあります。

戦略

構造分析のための要約リストを作成しましょう。 直感や推測に基づいて変更を加えるのではなく、何らかのデータを使用して意思決定を行うよう努めます。 これを行うには、次のようにします。

• 最適化の境界 (要件) を決定します。
• システムのトランザクション負荷を計算します。
• テスト（データ作成）を行います。
• 私たちは観察します。
• すべての要件が満たされているかどうかを分析します。
• 私たちはそれを科学的に設定し、仮説を立てます。
• この仮説を検証するために実験を実行します。

シンプルなHTTPサーバーアーキテクチャ

この記事では、Golang の小規模な HTTP サーバーを使用します。 この記事のコードはすべて見つかります ここで.

分析対象のアプリケーションは、リクエストごとに Postgresql をポーリングする HTTP サーバーです。 さらに、アプリケーションとシステムのメトリクスを収集および表示するための Prometheus、node_exporter、および Grafana があります。

単純化するために、水平スケーリング (および計算の簡素化) のために、各サービスとデータベースが一緒にデプロイされると考えます。

目標の定義

このステップでは、目標を決定します。 私たちは何を分析しようとしているのでしょうか? 終了時刻をどうやって知ることができるのでしょうか? この記事では、クライアントがあり、サービスが 10 秒あたり 000 件のリクエストを処理すると想定します。

В Google SRE ブック 選択とモデリングの方法について詳しく説明します。 同じことをしてモデルを構築してみましょう。

• レイテンシー: リクエストの 99% は 60 ミリ秒未満で完了する必要があります。
• コスト: サービスは、合理的に可能であると考えられる最小限の金額を消費する必要があります。 これを行うために、スループットを最大化します。
• キャパシティ プランニング: 全体的なスケーリング機能を含め、実行する必要があるアプリケーションのインスタンスの数と、初期負荷とプロビジョニングの要件を満たすために必要なインスタンスの数を理解し、文書化する必要があります。 冗長性 n+1.

レイテンシーには分析に加えて最適化が必要な場合がありますが、スループットは明らかに分析する必要があります。 SRE SLO プロセスを使用する場合、遅延リクエストは、製品所有者が代表する顧客または企業から行われます。 そして、私たちのサービスは、設定なしで最初からこの義務を果たします。

テスト環境のセットアップ

テスト環境の助けを借りて、システムに測定された負荷をかけることができます。 分析のために、Web サービスのパフォーマンスに関するデータが生成されます。

トランザクション負荷

この環境では、 ボーッとして時を過ごします 停止するまでのカスタム HTTP リクエスト レートを作成するには、次のようにします。

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

サーベイランス

トランザクション負荷は実行時に適用されます。 アプリケーション (リクエスト数、応答遅延) およびオペレーティング システム (メモリ、CPU、IOPS) のメトリクスに加えて、アプリケーション プロファイリングが実行され、どこに問題があるのか​​、CPU 時間がどのように消費されているのかが把握されます。

プロファイリング

プロファイリングは、アプリケーションの実行中に CPU 時間がどのようになっているかを確認できる測定の一種です。 これにより、プロセッサ時間がどこでどれだけ費やされたかを正確に判断できます。

このデータは分析中に使用して、無駄な CPU 時間や実行されている不要な作業についての洞察を得ることができます。 Go (pprof) は、標準のツール セットを使用してプロファイルを生成し、フレーム グラフとして視覚化できます。 その使用方法とセットアップ ガイドについては、記事の後半で説明します。

実行、観察、分析。

実験をしてみましょう。 納得のいくまで実行、観察、分析を行います。 任意の低い負荷値を選択して適用し、最初の観測結果を取得しましょう。 後続の各ステップでは、ある程度の変動を加えて選択した特定のスケーリング係数で負荷を増加させます。 各負荷テストの実行は、リクエストの数を調整して実行されます。 make load-test LOAD_TEST_RATE=X.

50 秒あたり XNUMX リクエスト

上の 50 つのグラフに注目してください。 左上は、アプリケーションが XNUMX 秒あたり XNUMX リクエストを処理する (と思われる) ことを示し、右上は各リクエストの継続時間を示します。 どちらのパラメータも、パフォーマンスの限界内にあるかどうかを調べて分析するのに役立ちます。 グラフ上の赤い線 HTTP リクエストのレイテンシ 60ms での SLO を示します。 この線は、最大応答時間を大幅に下回っていることを示しています。

コスト面を見てみましょう。

10000 秒あたり 50 リクエスト / サーバーあたり 200 リクエスト = 1 サーバー + XNUMX

この数字はまだ改善できます。

500 秒あたり XNUMX リクエスト

負荷が 500 秒あたり XNUMX リクエストに達すると、さらに興味深いことが起こり始めます。

再び、左上のグラフでは、アプリケーションが通常の負荷を記録していることがわかります。 そうでない場合は、アプリケーションが実行されているサーバーに問題があります。 応答遅延のグラフは右上にあり、500 秒あたり 25 リクエストにより 40 ～ 99 ミリ秒の応答遅延が発生したことを示しています。 60 パーセンタイルは、上で選択した XNUMX ミリ秒の SLO に依然としてうまく適合します。

コストの観点から:

10000 秒あたり 500 リクエスト / サーバーあたり 20 リクエスト = 1 サーバー + XNUMX

すべてはまだ改善の余地があります。

1000 秒あたり XNUMX リクエスト

素晴らしい打ち上げ！ アプリケーションは 1000 秒あたり 99 件のリクエストを処理したことを示していますが、遅延制限が SLO に違反していました。 これは、右上のグラフの p100 行に見られます。 p60 ラインの方がはるかに高いにもかかわらず、実際の遅延は最大の XNUMXms よりも大きくなります。 アプリケーションが実際に何を行うのかを確認するために、プロファイリングを詳しく見てみましょう。

プロファイリング

プロファイリングでは、負荷を 1000 秒あたり XNUMX リクエストに設定し、次を使用します。 pprof データをキャプチャして、アプリケーションが CPU 時間を費やしている場所を確認します。 これは、HTTP エンドポイントをアクティブ化することで実行できます。 pprof次に、負荷がかかっている状態で、curl を使用して結果を保存します。

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

結果は次のように表示されます。

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

グラフは、アプリケーションが CPU 時間をどこでどれだけ費やしたかを示します。 からの説明より ブレンダン・グレッグ:

X 軸はスタック プロファイルの母集団をアルファベット順に並べたものであり (これは時間ではありません)、Y 軸はスタックの深さを示し、[一番上] で XNUMX から数えます。 各四角形はスタック フレームです。 フレームが広いほど、スタック内に存在する頻度が高くなります。 上にあるものは CPU 上で実行され、下にあるものは子要素です。 通常、色には何の意味もありませんが、フレームを区別するためにランダムに選択されているだけです。

分析 - 仮説

チューニングでは、無駄な CPU 時間を見つけることに重点を置きます。 私たちは無駄な支出の最大の原因を探し、それを排除します。 プロファイリングにより、アプリケーションがプロセッサ時間を費やしている正確な場所が非常に正確に明らかになることを考えると、プロファイリングを数回行う必要がある場合があり、アプリケーションのソース コードを変更し、テストを再実行して、パフォーマンスが目標に近づいているかどうかを確認する必要もあります。

Brendan Gregg の推奨に従って、チャートを上から下に読んでいきます。 各行にはスタック フレーム (関数呼び出し) が表示されます。 最初の行はプログラムへのエントリ ポイントであり、他のすべての呼び出しの親です (つまり、他のすべての呼び出しではスタックにこの行が含まれます)。 次の行はすでに異なります。

グラフ上の関数名の上にカーソルを置くと、デバッグ中にその関数がスタック上にあった合計時間が表示されます。 HTTPServe 関数は 65% の確率で存在し、他のランタイム関数は存在しました runtime.mcall, mstart и gc、残りの時間を費やしました。 面白い事実: 合計時間の 5% が DNS クエリに費やされます。

プログラムが検索するアドレスは Postgresql に属します。 クリック FindByAge:

興味深いことに、このプログラムは、原則として、接続の開閉、データの要求、データベースへの接続という 13 つの主な原因によって遅延が発生することを示しています。 グラフは、DNS リクエスト、接続の開始と終了が合計実行時間の約 XNUMX% を占めていることを示しています。

仮説： プーリングを使用して接続を再利用すると、単一の HTTP リクエストの時間が短縮され、スループットが向上し、レイテンシが低下します。.

アプリケーションのセットアップ - 実験

ソース コードを更新し、リクエストごとに Postgresql への接続を削除しようとします。 最初のオプションは使用することです 接続プール アプリケーションレベルで。 この実験では、 設定しましょう go用SQLドライバーを使用した接続プーリング:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

実行、観察、分析

1000 秒あたり 99 リクエストでテストを再開した後、p60 のレイテンシー レベルが SLO XNUMX ミリ秒の通常の状態に戻っていることは明らかです。

費用は？

10000 秒あたり 1000 リクエスト / サーバーあたり 10 リクエスト = 1 サーバー + XNUMX

もっと上手くやってみよう！

2000 秒あたり XNUMX リクエスト

負荷を 2000 倍にしても同じことがわかります。左上のグラフは、アプリケーションが 100 秒あたり 60 リクエストを処理できること、p99 は XNUMXms 未満、pXNUMX は SLO を満たしていることを示しています。

コストの観点から:

10000 秒あたり 2000 リクエスト / サーバーあたり 5 リクエスト = 1 サーバー + XNUMX

3000 秒あたり XNUMX リクエスト

ここで、アプリケーションは 3000 ミリ秒未満の p99 レイテンシで 60 リクエストを処理できます。 SLO には違反しておらず、コストは次のように受け入れられます。

10000 秒あたり 3000 リクエスト / サーバーあたり 4 リクエスト = 1 サーバー + XNUMX （著者がまとめました、 約。 翻訳者)

別のラウンドの分析を試してみましょう。

分析 - 仮説

アプリケーションのデバッグ結果を 3000 秒あたり XNUMX リクエストで収集して表示します。

それでも時間の 6% は接続の確立に費やされます。 プールを設定するとパフォーマンスが向上しましたが、アプリケーションが引き続きデータベースへの新しい接続を作成していることがわかります。

仮説： プールが存在するにもかかわらず、接続はドロップされ、クリーンアップされるため、アプリケーションは接続をリセットする必要があります。 保留中の接続の数をプール サイズに設定すると、アプリケーションが接続の作成に費やす時間が最小限に抑えられ、遅延が軽減されます。.

アプリケーションのセットアップ - 実験

インストールしようとしています MaxIdleConns プール サイズに等しい (こちらも説明) ここで):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

実行、観察、分析

3000 秒あたり XNUMX リクエスト

p99 は 60ms 未満で、p100 は大幅に減少しています。

フレームグラフを確認すると、接続が目立たなくなっていることがわかります。 さらに詳しく確認してみましょう pg(*conn).query — ここでも接続が確立されていることに気づきません。

まとめ

パフォーマンス分析は、顧客の期待と非機能要件が満たされていることを理解するために重要です。 観察結果と顧客の期待を比較する分析は、何が受け入れられ、何が受け入れられないかを判断するのに役立ちます。 Go は、分析をシンプルにしてアクセスしやすくする、標準ライブラリに組み込まれた強力なツールを提供します。

出所： habr.com