Application Load Balancer のレイテンシーが高い場合のトラブルシューティング方法を教えてください。
Application Load Balancer の背後に登録されたターゲット上で実行されているウェブアプリケーションにアクセスしようとすると、レイテンシーが高くなり、タイムアウトが発生します。これらの問題をどのように修正すればよいですか?
簡単な説明
Application Load Balancer のレイテンシーが高くなる原因としては、次のものがあります。
- ネットワーク接続の問題
- バックエンドインスタンスでの高いメモリ (RAM) 使用率
- バックエンドインスタンスでの高い CPU 使用率
- バックエンドインスタンスでのウェブサーバーの誤った設定
- 外部データベース、Amazon Simple Storage Service (Amazon S3) バケットなどのバックエンドインスタンスで実行中のウェブアプリケーションの依存関係に関する問題
解決方法
1. Application Load Balancer のトラブルシューティングのトラブルシューティング手順を使用して、ネットワーク接続の問題がないかどうかを確認します。
2. curl を使用して、最初のバイト応答を測定し、低速な DNS 解決がレイテンシーに寄与しているかどうかを確認します。
curl -kso /dev/null https://www.example.com -w "==============\n\n | dnslookup: %{time_namelookup}\n | connect: %{time_connect}\n | appconnect: %{time_appconnect}\n | pretransfer: %{time_pretransfer}\n | starttransfer: %{time_starttransfer}\n | total: %{time_total}\n | size: %{size_download}\n | HTTPCode=%{http_code}\n\n"
出力例:
| dnslookup: 0.005330 | connect: 0.006682 | appconnect: 0.026540 | pretransfer: 0.026636 | starttransfer: 0.076980 | total: 0.077111 | size: 12130 | HTTPCode=200
Application Load Balancer を使用して、これらのテストを実行します。次に、Application Load Balancer をターゲットにバイパスしながらテストを実行します。このアプローチは、レイテンシーを引き起こすコンポーネントを分離するのに役立ちます。curl 機能の詳細については、curl 機能の使用方法を参照してください。
3. Application Load Balancer の Amazon CloudWatch TargetResponseTime メトリクスの Average 統計を確認します。値が大きい場合、バックエンドインスタンスまたはアプリケーション依存サーバーに問題がある可能性があります。
4. Application Load Balancer のアクセスログエントリを確認して、どのバックエンドインスタンスで高いレイテンシーが見られるかを確認します。target_processing_time を確認して、レイテンシーの問題が発生しているバックエンドインスタンスを見つけます。また、request_processing_time フィールドと response_processing_time フィールドで、Application Load Balancer に関する問題を確認します。
5. バックエンドインスタンスの CloudWatch CPUUtilization メトリクスを確認します。高い CPU 使用率または CPU 使用率の急増を探します。CPU 使用率が高い場合、インスタンスをより大規模なインスタンスタイプにアップグレードすることを検討してください。
6. バックエンドインスタンスの Apache プロセスを確認して、メモリの問題を確認します。
コマンド例:
watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"
出力例:
Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no- headers | wc -1 && free –m Apache Processes: 27 total used free shared buffers cached Mem: 8204 7445 758 0 385 4567 -/+ buffers/cache: 2402 5801 Swap: 16383 189 16194
7. バックエンドインスタンス上のウェブサーバーの MaxClient 設定を確認します。この設定では、インスタンスが処理できる同時リクエストの数を定義します。メモリと CPU 使用率が適切なインスタンスで長いレイテンシーが発生している場合は、MaxClient の値を増やすことを検討します。
Apache (httpd) と MaxClient 設定によって生成されたプロセスの数を比較します。Apache プロセスの数が頻繁に MaxClient 値に到達する場合は、この値を増やすことを検討してください。
[root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15
<IfModule prefork.c> StartServers 10 MinSpareServers 5 MaxSpareServers 10 ServerLimit 15 MaxClients 15 MaxRequestsPerChild 4000 </IfModule>
8. レイテンシーの問題を発生させている可能性がある、バックエンドインスタンスの依存関係について確認します。依存関係には、共有データベースまたは外部リソース (Amazon S3 バケットなど) が含まれる場合があります。依存関係には、ネットワークアドレス変換 (NAT) インスタンス、リモートウェブサービス、プロキシサーバーなどの外部リソース接続も含まれます。
9. 次の Linux ツールを使用して、サーバー上のパフォーマンスのボトルネックを特定します。
uptime – 実行を待機しているタスク (プロセス) の数を特定するのに役立つ負荷平均を表示します。Linux システムでは、この数には、CPU で実行を待機しているプロセスと、無停電 I/O (通常はディスク I/O) でブロックされているプロセスが含まれます。このデータにより、他のツールを使用して解釈する必要があるリソースの負荷 (または需要) の概要を知ることができます。Linux の負荷平均が増加すると、リソースの需要が高くなります。需要が高いリソースを特定するには、他のメトリクスを使用する必要があります。たとえば、CPU の場合、mpstat -P ALL 1 を使用して CPU 単位の使用率を測定し、top または pidstat 1 を使用してプロセス単位の CPU 使用率を測定できます。
mpstat -P ALL 1 – CPU ごとの CPU 時間の詳細を表示します。これを使用して、不均衡をチェックできます。単一のホット CPU は、シングルスレッドアプリケーションを示唆している場合があります。
pidstat 1 – プロセスごとの CPU 使用率を表示し、時間の経過に伴うパターンの監視に役立つローリングサマリーを出力します。
dmesg | tail – 直近の 10 個のシステムメッセージを表示します (存在する場合)。パフォーマンスの問題を引き起こす可能性のあるエラーを探します。
iostat -xz 1 – ブロックデバイス (ディスク) に適用されるワークロードと、結果として得られるパフォーマンスを表示します。
free -m – 空きメモリの量を表示します。これらの数値が 0 に近いサイズでないことを確認します。0 に近いサイズの場合、ディスク I/O が増加し (iostat を使用して確認)、パフォーマンスが低下する可能性があります。
sar -n DEV 1 – ネットワークインターフェイスのスループット (rxkB/s および txkB/s) をワークロードの指標として表示します。制限に達していないか確認してください。
sar -n TCP,ETCP 1 – active/s (ローカルで開始される TCP 接続数/秒)、passive/s (リモートで開始される TCP 接続数/秒)、retrans/s (TCP 再送信数/秒) などの主要な TCP メトリクスを表示します。
iftop – 最も多く帯域幅を消費しているサーバーとリモート IP アドレス間の接続を表示します。n iftop は、Red Hat および Debian ベースのディストリビューションで同じ名前のパッケージで提供されています。ただし、Red Hat ベースのディストリビューションでは、サードパーティーのリポジトリに n iftop があるかもしれません。

関連するコンテンツ
- 質問済み 6年前lg...
- 質問済み 3年前lg...
- 質問済み 3年前lg...
- 質問済み 4年前lg...
- AWS公式更新しました 3年前