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 のネットワーク接続に関する問題をトラブルシューティングします。
2. ユースケースに合わせて、適切な Classic Load Balancer の設定を行います。
3. Classic Load Balancer のアクセスログを確認して、高いレイテンシーが発生しているバックエンドインスタンスを特定します。レイテンシーの問題があるバックエンドインスタンスは、 backend_processing_time を調べることで発見できます。
バックエンドインスタンスのウェブアプリケーションサーバーで高いレイテンシーが発生しているかは、curl を使用して第 1 バイトのレスポンスを測定することで確認できます。その例を次に示します。
[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. Latency メトリクスのパターンを確認します。メトリクス値に、一定の間隔や一定パターンでのスパイクがある場合、バックエンドインスタンスのパフォーマンスに問題があることも考えられます。この問題は、スケジュールされたタスクでのオーバーヘッドが原因となり発生することもあります。
7. CloudWatch で、ELB に関する 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) インスタンスなどの外部リソース接続、リモートウェブサービス、プロキシサーバーなどが含まれますが、以上に限定されている訳ではありません。