AWS ELBレイテンシーについて
CloudWatchによって提供されるELBレイテンシ統計が何を意味するのかを正確に理解したいと思っています。
ドキュメントによると：
- ELBレイテンシ：「リクエストがロードバランサーを出てからレスポンスが受信されるまでの経過時間を秒単位で測定します。」
100％明確ではないのは、クライアントに転送される前に応答がELBにバッファーされるかどうかです。
ドキュメントのステートメントは次の意味ですか？
- ELBレイテンシ：「リクエストがロードバランサーを出てから、応答が[クライアントによって]受信されるまでの経過時間を秒単位で測定します。」
または：
- ELBレイテンシ：「リクエストがロードバランサーを出てから、レスポンスが[ELBによって]受信されるまでの経過時間を秒単位で測定します。」
最大遅延のCloudWatchメトリックスが不十分である理由は、かなりの数のユーザーが不安定な3G接続を持っていることで説明できるのか、それとも、アプリサーバーが時々応答が遅くなるという根本的な問題があることを示しているのかを知りたいです。
AWSサポートによると：
ELB（HTTPリスナーで構成されている場合）がプロキシとして機能するため（リクエストヘッダーが受信され、検証されてからバックエンドに送信されます）、ヘッダーがバックエンドに送信されるとすぐに、レイテンシメトリックがバックエンドに送信されるまで刻み始めます最初のバイト応答。
POST（または顧客が追加のデータを送信しているときのHTTPメソッド）の場合、顧客がデータをアップロードしているときでも（バックエンドが応答を送信するために完全なリクエストを必要とするため）レイテンシは刻々と過ぎ、バックエンドが送信すると停止します最初のバイト応答。したがって、遅いクライアントがデータを送信している場合、レイテンシはアップロード時間+バックエンドが応答するのにかかった時間を考慮に入れます。
これは、ELBがクライアントに応答を返すために必要な時間に関係なく、サーバーがELBの観点からその応答を生成するのにかかる時間の測定値のようです。
ELBを別のロードバランサーHAProxyの前で使用しているアプリケーションの1つで自分のログを確認することでこの結論に達しました。HAProxyは実際のアプリケーションサーバーの前にあります。 （これは冗長に見えるかもしれませんが、ELBのみまたはHAProxyのみを使用するよりもいくつかの利点があります。）
これが私が言及している設定です：
ELB -->>-- EC2+HAProxy -->>-- EC2+Nginx (multipe instances)
HAProxyは、リクエストごとにTrと呼ばれるものを含め、 いくつかの時間メトリック をログに記録します。
Tr：サーバーの応答時間（HTTPモードのみ）。TCP接続が確立された瞬間から経過した時間です。サーバーへの応答と、サーバーが完全な応答ヘッダーを送信した瞬間データ転送によるネットワークオーバーヘッドなしで、純粋に要求処理時間を示します。
ここで、HAProxyがここで行っていることについての多くの議論がELBとレイテンシメトリックに関連する理由の説明を私に付けてください。
HAProxyは、リクエスト/レスポンスごとにプロキシがさまざまなイベントの待機に費やす時間に関連する他の多くのタイマーを記録しますが、このTrタイマーは、HAProxyの単一のタイマーですELBのCloudwatchの「レイテンシ」メトリックスによってログに記録された値に分単位できちんと対応しているログ。 ...したがって、このELBメトリックは同様にアプリケーションサーバーの応答時間をログに記録することをお勧めします。これは、クライアントに応答を返すのに必要な追加時間とは関係ありません。
これらのシステムは文字通りパフォーマンスを測定しているので、ELBのタイマーがHAProxyが測定しているものと非常に類似しているものを測定していない限り、HAProxyの問題のタイマーの定義を考えると、HAProxyとELBが非常に一貫して一致している可能性は非常に低いようです。同じ正確なリクエストの同じ正確なアプリサーバーの。
アプリケーションサーバー自体がベンチマークを実行せず、独自のパフォーマンスのタイマーをログに記録しない場合は、（私の観察によると）待ち時間メトリックの高い値がアプリケーションに、クライアント接続の品質とは関係のない応答性の問題がある可能性があることを提案します。