Classic Load Balancer に登録された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されているウェブアプリケーションへの接続時に、クライアントで長いレイテンシーが発生します。この Elastic Load Balancing (ELB) での長いレイテンシーのトラブルシューティングを行う方法を教えてください。
Classic Load Balancer で長いレイテンシーが発生する場合は、次のような理由が考えられます。
- ネットワーク接続の問題
- Classic Load Balancer の不適切な設定
- バックエンドインスタンスでの高いメモリ (RAM) 使用率
- バックエンドインスタンスでの高い CPU 使用率
- バックエンドインスタンスでのウェブサーバーの不適切な設定
- 外部データベース、Amazon Simple Storage Service (Amazon S3) バケットなどのバックエンドインスタンスで実行中のウェブアプリケーションの依存関係に関する問題
1. Classic Load Balancer のネットワーク接続の問題をトラブルシューティングします。詳細については、「Elastic Load Balancing の接続の問題のトラブルシューティングを教えてください」および「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 統計を確認します。値が大きい場合は一般的に、ELB ではなくバックエンドインスタンスまたはアプリケーションが依存しているサーバーに問題があることを示します。
5. Latency メトリクスの Maximum 統計を確認します。値がアイドルタイムアウト値を満たしているか、それを超えている場合、リクエストはタイムアウトする可能性があります。この問題により、クライアントで HTTP 504 エラーが発生します。
6. 3. Latency メトリクスのパターンを確認します。メトリクスが定期的な間隔またはパターンに従って急増する場合、バックエンドインスタンスのパフォーマンスの問題を示している可能性があります。この問題は、スケジュールされたタスクからのオーバーヘッドが原因で発生する可能性があります。
7. ELB の CloudWatch SurgeQueueLength メトリクスを確認します。Classic Load Balancer へのリクエストが最大値 (1024) を超える場合、リクエストは拒否され、ロードバランサーによって HTTP 503 エラーが生成されます。SpilloverCount メトリクスの合計の統計では、拒否されたリクエストの合計数を測定します。詳細については、「Elastic Load Balancing のキャパシティーの問題のトラブルシューティングを教えてください」を参照してください。
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) インスタンスなどの外部リソース接続、リモートウェブサービス、プロキシサーバーなどが含まれますが、これらに限定されません。
