ELB Classic Load Balancer での長いレイテンシーのトラブルシューティングを行う方法を教えてください。

最終更新日: 2022 年 5 月 17 日

Classic Load Balancer に登録された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されているウェブアプリケーションへの接続時に長いレイテンシーが発生します。Elastic Load Balancing でのレイテンシーのトラブルシューティングを行う方法を教えてください。

簡単な説明

Classic Load Balancer で長いレイテンシーは次の理由が原因で発生します。

ネットワーク接続の問題
Classic Load Balancer の不適切な設定
バックエンドインスタンスでの高いメモリ (RAM) 使用率
バックエンドインスタンスでの高い CPU 使用率
バックエンドインスタンスでのウェブサーバーの不適切な設定
外部データベース、Amazon Simple Storage Service (Amazon S3) バケットなどのバックエンドインスタンスで実行中のウェブアプリケーションの依存関係に関する問題

解決方法

1. Classic Load Balancer のネットワーク接続に関する問題のトラブルシューティングを行います。

2. ユースケースに合わせて Classic Load Balancer を設定します。

3. Classic Load Balancer のアクセスログを確認して、長いレイテンシーが発生しているバックエンドインスタンスを特定します。backend_processing_time を確認して、レイテンシーの問題が発生しているバックエンドインスタンスを見つけます。

バックエンドインスタンスのウェブアプリケーションサーバーで長いレイテンシーが発生していることを確認するには、curl を使用して最初のバイトのレスポンスを測定します。例:

[ec2-user@ip-192.0.2.0 ~]$ for X in `seq 6`; do curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" http://www.example.com/ -so /dev/null; done

High Latency sample output:
HTTPCode=200 TotalTime=2.452
HTTPCode=200 TotalTime=1.035

Low latency sample output:
HTTPCode=200 TotalTime=0.515
HTTPCode=200 TotalTime=0.013

4. Classic Load Balancer の CloudWatch Latency メトリクスの Average 統計を確認します。値が大きい場合、バックエンドインスタンスまたはアプリケーション依存サーバーに問題があります。

5. Latency メトリクスの Maximum 統計を確認します。値がアイドルタイムアウト値以上になると、リクエストがタイムアウトし、HTTP 504 エラーが発生します。

6. Latency メトリクスのパターンを確認します。一定の間隔でメトリクスのスパイクが発生する場合は、スケジュールされたタスクのオーバーヘッドに起因するバックエンドインスタンスのパフォーマンスの問題を示しています。

7. Elastic Load Balancing の CloudWatch SurgeQueueLength メトリクスを確認します。Classic Load Balancer へのリクエストが最大値 (1024) を超える場合、リクエストは拒否され、ロードバランサーによって HTTP 503 エラーが生成されます。SpilloverCount メトリクスの合計の統計では、拒否されたリクエストの合計数が測定されます。詳細については、「ELB での Classic Load Balancer のキャパシティーの問題のトラブルシューティングを教えてください」を参照してください。

8. バックエンドインスタンスの 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

9. バックエンドインスタンスの CloudWatch CPUUtilization メトリクスを確認します。高い CPU 使用率または CPU 使用率のスパイクを探します。CPU 使用率が高い場合、インスタンスをより大規模なインスタンスタイプにアップグレードすることを検討してください。

10. バックエンドインスタンスのウェブサーバーの 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>

11. バックエンドインスタンスでレイテンシーの問題を引き起こす依存関係をチェックします。こうした依存関係には、共有データベース、外部リソース (S3 バケットなど)、ネットワークアドレス変換 (NAT) インスタンスなどの外部リソース接続、リモートウェブサービス、プロキシサーバーなどが含まれますが、必ずしもこれらに限定るものではありません。

ELB Classic Load Balancer での長いレイテンシーのトラブルシューティングを行う方法を教えてください。

簡単な説明

解決方法

関連情報

Internet Explorer のサポートの終了