Elastic Load Balancing で、Application Load Balancer の遅延が大きい場合のトラブルシューティング方法を教えてください。

簡単な説明

次の要因で、Application Load Balancer の遅延が増加します。

• ネットワーク接続または輻輳の問題
• バックエンドインスタンスでのメモリ (RAM) 使用率の増加
• バックエンドインスタンスでの CPU 使用率の増加
• バックエンドインスタンスでのウェブサーバー設定に誤りがある
• バックエンドインスタンスで実行されるウェブアプリケーションの依存関係に関する問題
• クライアントまたはオンプレミスターゲットと Application Load Balancer との間の地理的な距離が遠い

解決策

Application Load Balancer での遅延の増加を解決するには、次の手順を実行します。

• ネットワーク接続の問題が発生していないか確認します詳細については、「Application Load Balancer のトラブルシューティング」を参照してください。

• 最初のバイト応答を測定し、遅延を引き起こす可能性のある低速 DNS 解決があるかどうかを確認します。

  curl -kso /dev/null -w "\n===============\n
  | DNS lookup: %{time_namelookup}\n
  | Connect: %{time_connect}\n
  | App connect: %{time_appconnect}\n
  | Pre-transfer: %{time_pretransfer}\n
  | Start transfer: %{time_starttransfer}\n
  | Total: %{time_total}\n
  | HTTP Code: %{http_code}\n===============\n" https://example.com/

  出力例:

  ===============
  | DNS lookup: 0.002346
  | Connect: 0.003080
  | App connect: 0.008422
  | Pre-transfer: 0.008587
  | Start transfer: 0.050238
  | Total: 0.057486
  | HTTP Code: 200
  ===============

  注: 遅延の原因を切り分けるには、Application Load Balancer を含めて上記のステップを完了してから、Application Load Balancer をバイパスしして再度そのステップを実行します。詳細については、curl のウェブサイトで curl man ページを参照してください。

• Amazon CloudWatch で Application Load Balancer に関する TargetResponseTime の Average 統計情報を確認します。この値が高い場合は、バックエンドインスタンスまたはアプリケーション依存関係サーバーに問題があります。詳細については、「Application Load Balancer で TargetResponseTime メトリクスが増加している場合のトラブルシューティング方法を教えてください」を参照してください。

• 遅延が大きいバックエンドインスタンスを特定するには、Application Load Balancer のアクセスログエントリを確認します。

• 遅延の問題があるバックエンドインスタンスを特定するには、target_processing_time が通常よりも長い期間がないか確認します。

• Application Load Balancer に問題があるかどうかを確認するには、ログエントリの request_processing_time および response_processing_time フィールドに通常よりも長い期間がないか確認します。

  ログエントリの例:

  http 2024-04-01T22:23:00.765170Z app/example-loadbalancer/50dc6c495c0c9188
  192.168.131.39:2817 10.0.0.1:80 0.001 12.401 0.001 200 200 34 366
  "GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
  arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/example-targets/73e2d6bc24d8a067
  "Root=1-58337262-36d228ad5d99923122bbe354" "-" "-"
  0 2024-04-01T22:22:48.364000Z "forward" "-" "-" "10.0.0.1:80" "200" "-" "-"

  注: 上記のログエントリ例では、request_processing_time は 0.001、target_processing_time は 12.401、response_processing_time は 0.001 です。target_processing_time の値は通常よりも長い期間を示しており、Application Load Balancer のターゲットが遅延の原因であることが示唆されます。詳細については、「構文」を参照してください。

• CPU 使用率が高くなっていたり、急増したりしている状態を特定するには、バックエンドインスタンスの CloudWatch メトリクス CPUUtilization を確認します。CPU 使用率が高い状態を解決するには、インスタンスを大容量のインスタンスタイプにアップグレードしてください。

• バックエンドの 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

• インスタンスが処理できる同時リクエストの数を確認するには、バックエンドインスタンスのウェブサーバーで MaxClient 設定を確認します。インスタンスに適切な量のメモリと CPU 使用率があるにもかかわらず、遅延が大きい場合は、MaxClient 値を増やしてください。

• Apache (httpd) で生成されるプロセスの数を MaxClient 値と比較します。Apache プロセスの数が頻繁に MaxClient 値に達する場合は、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>

バックエンドの依存関係を確認する

バックエンドインスタンスに遅延の問題の原因となる依存関係がないか確認します。たとえば、依存関係には Amazon Simple Storage Service (Amazon S3) バケット、ネットワークアドレス変換 (NAT) インスタンスまたはプロキシサーバー、リモートウェブサービスなどがあります。

Linux ツールを使用してパフォーマンスのボトルネックを特定する

サーバー上のパフォーマンスのボトルネックを特定するには、次の Linux コマンドを使用します。

• uptime コマンドを実行し、リソースの競合が原因でシステム負荷の平均が高くなっていないか確認します。出力には、実行を待機しているか、入出力でブロックされているタスクの数を示すシステム負荷の平均が表示されます。
• mpstat -P ALL 1 コマンドを実行すると、各コアの CPU 使用率の内訳が表示されます。このコマンドを実行し、バランスが取れていない使用状況を判断します。たとえば、シングルスレッドアプリケーションのほとんどの作業をシングルコアが処理している場合が該当します。
• リソースを大量に消費するプロセスとパターンを経時的に特定するには、pidstat 1 コマンドを実行します。出力には、プロセスごとのリアルタイムの CPU 使用率が表示されます。
• dmesg | tail コマンドを実行すると、最近のシステムレベルのイベントうち、パフォーマンスに影響する可能性のあるものを特定できます。出力には、最新 10 件のシステムメッセージが表示されます。
• 大量の読み取りまたは書き込み操作や、ディスクのパフォーマンス低下を特定するには、iostat -xz 1 コマンドを実行します。出力には、ディスク I/O メトリクスと使用状況が表示されます。
• free-m コマンドを実行すると、使用可能なシステムメモリが表示されます。使用可能なメモリが少ない場合、システムはスワップに依存するため、ディスクの I/O と遅延が増加する可能性があります。
• 帯域幅の飽和状態を特定するには、sar -n DEV 1 tool コマンドを実行します。出力には、受信トラフィック (rxkB/s) と送信トラフィック (txkB/s) を含むネットワークインターフェイスのスループットが表示されます。
• sar -n TCP,ETCP 1 を実行すると、次の主要な TCP メトリクスが表示されます。これらのメトリクスは、接続の問題を特定する参考になります。
  active/s メトリクスは、1 秒間にローカルで開始された TCP 接続の数を表します。
  passive/s メトリクスは、1 秒間にリモートで開始された TCP 接続の数を表します。
  retrans/s メトリクスは、1 秒あたりの TCP 再送信回数を表します。このメトリクスが高い場合は、パケットロスまたは輻輳が発生している可能性があります。
• ネットワークで最も帯域幅を使用している要因を特定するには、iftop コマンドを実行します。出力には、各接続のアクティブな帯域幅使用状況がリアルタイムで表示されます。
• niftop コマンドは iftop のバリアントです。Red Hat Enterprise Linux (RHEL) および Debian ベースのディストリビューションのサードパーティリポジトリから入手できる場合があります。iftop がシステムにプリインストールされていない場合は、niftop を使用してください。

注: Linux ディストリビューションによっては、上記のコマンドの一部を手動でインストールする必要がある場合があります。