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

問題

Elastic Load Balancing (ELB) ロードバランサーに登録された EC2 インスタンスで実行されているウェブアプリケーションへの接続時にクライアントで長いレイテンシーが発生します。

短い説明

長いレイテンシーは以下のようないくつかの要因により発生することがあります。

ネットワーク接続
ELB の設定
バックエンドウェブアプリケーションサーバーの問題を以下に示していますが、これらに限定されるものではありません。
- メモリ使用量 - ウェブアプリケーションのレイテンシーの最も一般的な原因の 1 つは、利用可能な物理メモリ（RAM）の大部分またはすべてがホスト EC2 インスタンスで消費されることです。
- CPU 使用率 - ホスト EC2 インスタンスでの高い CPU 使用率により、ウェブアプリケーションのパフォーマンスが大幅に下がり、場合によってはサーバーがクラッシュすることがあります。
- ウェブサーバーの設定 - バックエンドウェブアプリケーションサーバーで長いレイテンシーがあってもメモリや CPU の過度の使用率がない場合、ウェブサーバーの設定で潜在的な問題を確認する必要があります。
- ウェブアプリケーションの依存関係 - バックエンドウェブアプリケーションサーバーで、メモリ、CPU、ウェブサーバーの設定の問題を解決した後にも、長いレイテンシーが発生する場合は、ウェブアプリケーションの依存関係（外部データベースや Amazon S3 バケットなど）がパフォーマンスのボトルネックとなっている可能性があります。

解決

以下の手順に従って長いレイテンシーの原因を特定します。

1. ネットワーク接続の問題を確認する

「Elastic Load Balancing 接続の問題のトラブルシューティングを行う方法を教えてください」の手順に従います。

2. バックエンドウェブアプリケーションサーバーのレイテンシーを確認する

Linux の curl コマンドを実行してレスポンスの先頭バイトを評価することで、1 台以上のバックエンドウェブアプリケーションサーバーで長いレイテンシーが発生しているかどうか調べます。

バックエンドウェブアプリケーションサーバーで長いレイテンシーが発生しているか調べるために、ELB アクセスログを見直して、いずれのウェブアプリケーションサーバーが「バックエンド処理時間」の大きい値に関連しているか確認します。

長いレイテンシーが発生しているバックエンドサーバーを中心にウェブアプリケーションのトラブルシューティングを行います。

3. CloudWatch Latency メトリックスを確認する

Latency メトリックスは、ロードバランサーからリクエストが送信されてから、登録されたインスタンスのロードバランサーによってレスポンスが受信されるまでの経過時間を秒単位で表しています。このメトリックスの推奨される統計は average であり、すべてのリクエストの平均レイテンシーをレポートします。[average] の値が大きい場合は一般的に、ロードバランサーではなくバックエンドサーバーに問題があることを示します。maximum 統計を確認して、レイテンシーデータポイントの数がロードバランサーのアイドルタイムアウト値以上になっているか調べます。レイテンシーデータポイントがアイドルタイムアウト値以上になっていると、多くの場合、いくつかのリクエストがタイムアウトになり、クライアントへの HTTP 504 レスポンスが開始されます。

4. レイテンシーパターンを確認する

レイテンシーの maximum 統計で一定期的にスパイクがあるか、特定のパターンがあれば、バックエンドウェブアプリケーションサーバーまたはアプリケーションに、スケジュールされたタスクの実行時に発生するオーバーヘッドによるパフォーマンスの問題があると考えられます。

5. CloudWatch SurgeQueueLength メトリックスを確認する

このメトリックスには、登録されたインスタンスに対して保留されている（キューに入れられている）リクエストの合計数が示されます。SurgeQueueLength の最大値は 1,024 です。最大 SurgeQueueLength 値を超えると、SpilloverCount メトリックスの sum 統計で、キューがいっぱいになったために拒否されたリクエストの合計数の評価が開始されます。SurgeQueueLength 値が大きいことに関する問題のトラブルシューティングの詳細については、「Elastic Load Balancing のキャパシティーの問題のトラブルシューティングを教えてください。」を参照してください。

6. ELB のアクセスログを確認する

ELB のアクセスログを開いて、長いレイテンシーの原因を特定します。アクセスログには、「backend_processing_time」が収集されています。これには、登録されたインスタンスにロードバランサーがリクエスト（HTTP リスナー）/先頭バイト（TCP リスナー）を送信し、インスタンスがレスポンスヘッダー/先頭バイトの送信を開始したときから経過した合計時間（秒単位）が記録されています。アクセスログの詳細については、「Elastic Load Balancing アクセスログを使用したロードバランサーのモニタリング」を参照してください。「request_processing_time」と「response_processing_time」の値が想定よりも大きくなっている場合は、AWS サポートに連絡してください。

7. バックエンドウェブアプリケーションサーバーの問題のトラブルシューティングを行う

利用可能なメモリを確認する - メモリが不足すると、長いレイテンシーが発生することがあります。発生したときは、オペレーティングシステムがメモリの一部をスワップに移動することで RAM を解放しようとします。スワップはハードドライブ上の予約された領域です。ウェブアプリケーションサーバーでは、ディスクへのメモリのスワッピングは避けてください。スワッピングにより各リクエストのレイテンシーが大幅に長くなるためです。その結果、今度はユーザーがページの再ロードを試みるようになり、負荷が高くなり、問題が悪化します。Apache プロセスの数と RAM の合計使用量に注目してください。以下の Linux コマンドを実行して、Apache プロセスの数と RAM の合計使用量が毎秒更新されてタブ区切り形式で表示されるようにします。

watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

このコマンドを実行すると、以下のような出力が生成されます。

CPU 使用率を確認する - ウェブサーバーの CPU はウェブページの取得と訪問者への表示に使用されます。静的なページにも動的なページにも使用されます。ウェブページがデータベースやスクリプトから動的に配信されるとき、使用される CPU サイクルやリソースが増えます。CloudWatch メトリックス [CPU Utilization] を確認して CPU 使用率をモニタリングし、より大きなインスタンスタイプへのアップグレードが必要かどうか決めます。平均統計から全体的な CPU 使用率の一般的な見解を得られます。また、maximum 統計を評価して、レイテンシーの問題につながる可能性がある CPU 使用率のスパイクがあるかどうか確認することもできます。

ウェブサーバーの設定を確認する - ほとんどのウェブサーバーには、作成できるウェブサーバープロセスの最大数を定義可能な MaxClient 設定が用意されています。この設定により、ウェブサーバーによって同時に対応できるクライアントの数が制限されます。ウェブサーバーで十分な RAM と CPU リソースが利用可能であっても、依然として長いレイテンシーが発生する場合は、設定されているこの値が小さすぎるかどうかの確認が必要になることがあります。小さすぎる場合、クライアント接続は遅延されてキューに入り、最終的にタイムアウトになることがあります。

再び、Apache ウェブサーバーを例として説明します。Apache ウェブサーバーで Prefork マルチプロセッシングモジュール（MPM）が使用されている場合、Apache プロセスによって起動されたプロセスの数をカウントして、同時接続数を評価できます。これは、Prefork MPM が 1 つのスレッドで複数の子プロセスを使用し、各プロセスが一度に 1 つの接続を処理する例です。

Apache ウェブサーバー（httpd）によって作成されたプロセスの数を調べるには、以下のコマンドを実行します。

  [root@ip-192.168.1.50  conf]# ps aux | grep httpd | wc -l 15

このコマンドの出力により、すべての Apache プロセスの数を Apache ウェブサーバーの設定ファイルの MaxClient 設定に対して比較できます。

Apache プロセスの数が、MaxClient に設定された値に一貫して達しているとわかった場合は、お客様のエンドユーザーが遅さを感じている可能性が高いと考えられます。

ウェブサーバーの依存関係を確認する - バックエンドインスタンスの CPU、メモリ、設定がすべて適切であれば、依存関係の評価が役立つことがあります。ウェブサーバーの依存関係を評価するときに検討できる質問を以下にいくつか示します。

ウェブサーバーが共有データベースに依存しており、過負荷の原因になっている可能性があるか?
ウェブサーバーが外部リソース（S3 バケットなど）に接続するか?
ウェブサーバーが外部リソースに接続するか?たとえば、不適切なサイズの NAT インスタンスを介した接続は、十分なパフォーマンスを発揮するために必要なスループットを制限する場合があります。
ウェブサーバーが実行速度の遅いリモートのウェブサービスを呼び出しているか?
ウェブサーバーは、他のバックエンドインスタンスに対するプロキシサーバーとして動作しているバックエンドロードバランサーを介して、外部リソースに接続しているか?

そのほかにも、ウェブアプリケーションサーバーのパフォーマンスと長いレイテンシーに対するウェブサーバーの依存関係による影響を評価するときに検討できる質問は多数あります。

Keywords

Elastic Load Balancing, バックエンドのトラブルシューティング, maxclient, RAM 使用量, CloudWatch Latency メトリックス, CPU 使用率, プロセスモニター