Elastic Load Balancing の Application Load Balancer で発生する高レイテンシーをトラブルシューティングするにはどうすればよいですか。

簡単な説明

以下は、Application Load Balancer で高レイテンシーが発生する原因です。

• クライアントと Application Load Balancer 間の接続の問題、パケット損失、DNS 解決の遅延などのネットワークの問題
• アイドルタイムアウト設定、サブネットキャパシティの不足、ルートの欠落、セキュリティグループまたはネットワークアクセスコントロールリスト (ACL) ルールの制限など、Application Load Balancer またはインフラストラクチャの設定ミス
• POST リクエストを処理するための AWS WAF のオーバーヘッド
• SSL/TLS ハンドシェイクのオーバーヘッドまたは証明書の問題
• 残りの正常なターゲットにトラフィック過負荷を引き起こすヘルスチェックの失敗
• CPU またはメモリ使用率の高さ、Web サーバー設定の誤り、アプリケーション依存関係の遅延など、バックエンドの問題

解決策

Application Load Balancer の高レイテンシーをトラブルシューティングするには、次のアクションを実行してください。

レイテンシーが発生しているフェーズを特定する

レイテンシーが発生しているフェーズを特定するには、Application Load Balancer のアクセスログで次のフィールドの値を確認してください。

• request_processing_time
• target_processing_time
• response_processing_time

アクセスログエントリの例:

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 が高い場合、バックエンドのターゲットがレイテンシーの原因であることを示します。詳細については、「アクセスログのエントリ」を参照してください。クライアントが観測した合計レイテンシーと、3 つのタイミングフィールドの合計を比較してください。大きな差がある場合は、クライアントと Application Load Balancer 間のネットワークに問題があることを示しています。

CloudWatch メトリクスで次のことを確認してください。

• TargetResponseTime の Average 統計情報。値が高い場合、バックエンドまたは依存関係の問題を示している。詳細については、『Application Load Balancer で TargetResponseTime メトリクスが増加している場合のトラブルシューティング方法を教えてください。』を参照する。
• UnHealthyHostCount。ターゲットのヘルスチェックが失敗している場合、Application Load Balancer は正常なターゲットにのみトラフィックをルーティングするため、それらが過負荷になりレイテンシーが増加する可能性がある。

複数のアベイラビリティーゾーンにわたるメトリクスを確認して、レイテンシーが特定の AZ に固有かどうかを判断してください。特定の AZ で高レイテンシーが発生している場合は、その AZ のターゲットの正常性と AZ 間の依存関係を調査します。

ネットワークと DNS の問題を確認する

クライアントと Application Load Balancer 間のネットワーク接続の問題は、高レイテンシーを引き起こす可能性があります。ネットワークと DNS の問題を確認するには、次の手順を実行してください。

• Application Load Balancer への基本的な接続性を確認する。詳細については、『Application Load Balancer のトラブルシューティング』を参照する。

• My Traceroute (MTR) を使用して、クライアントと Application Load Balancer 間のパケット損失とレイテンシーを確認する。次のコマンドを実行する。

  mtr -rw  example-alb.us-east-1.elb.amazonaws.com -report-cycles 100

  注: example-alb.us-east-1.elb.amazonaws.com を Application Load Balancer の DNS 名に置き換えてください。

  出力例:

  HOST: ip-10-0-1-50                Loss%   Snt    Last   Avg  Best   Wrst StDev  
   1.|-- 10.0.1.1                    0.0%   100     0.5    0.6   0.4      1.2   0.1  
   2.|-- 52.93.1.100                 0.0%   100     1.2    1.3   1.0      3.5   0.3  
   3.|-- 54.239.110.5                2.0%   100     1.5    1.8   1.2      5.1   0.5  
   4.|-- example-alb.us-east-1.elb.amazonaws.com   0.0%   100    2.1    2.3   1.8   4.2    0.4

  番号付きの各行は、クライアントと Application Load Balancer 間でトラフィックが通過するネットワークデバイスに対応しています。

• Loss% の値が高い、または Avg と Wrst のレイテンシー値の比率が高いネットワークデバイスを探す。中間ネットワークデバイスでのパケット損失は、ネットワークの輻輳を示している。最終ネットワークデバイスでパケット損失が発生している場合、問題は Application Load Balancer のサブネット設定またはネットワークパスにある。

• クライアント側と、Application Load Balancer と同じ Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon EC2 インスタンスの両方から MTR を実行する。結果を比較して、問題が AWS の外部か内部かを特定する。詳細については、"Diagnosing packet loss and latency with MTR" (MTR によるパケット損失とレイテンシーの診断) を参照する。

  次の curl コマンドを実行します。

  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/  
  

  注: example.com を DNS 名に置き換えてください。
  出力例:

  ===============| 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 page" (curl man ページ) を参照してください。App connect 時間 (TLS ハンドシェイク) が Connect 時間 (TCP ハンドシェイク) よりも大幅に長い場合、TLS ネゴシエーションが遅いことを示します。

Application Load Balancer とインフラストラクチャの設定を確認する

アイドルタイムアウト

• アクセスログの target_processing_time がアイドルタイムアウト値と正確に一致する場合は、Application Load Balancer のアイドルタイムアウトを増やすか、アプリケーションの応答時間を最適化する。アイドルタイムアウトを変更するには、『Application Load Balancer とは?』を参照する。デフォルトのアイドルタイムアウトは 60 秒である。現在のアイドルタイムアウト値を確認するには、次のコマンドを実行する。

  aws elbv2  describe-load-balancer-attributes --load-balancer-arn  example-alb-arn --query  "Attributes[?Key=='idle_timeout.timeout_seconds']"

  注: example-alb-arn を Application Load Balancer の Amazon リソースネーム (ARN) に置き換えてください。

• HTTP 502 エラーを回避するために、バックエンド Web サーバーの keep-alive タイムアウトが Application Load Balancer のアイドルタイムアウトより長くなるようにする。

• アクセスログで HTTP 460 エラーを確認します。これは、アイドルタイムアウトが経過する前にクライアントが接続を閉じたことを示している。

サブネットキャパシティ
各 Application Load Balancer サブネットには、少なくとも 8 つの空き IP アドレスを持つ少なくとも /27 の Classless Inter-Domain Routing (CIDR) ブロックが必要です。トラフィックが急増している時には、Application Load Balancer がスケールし、追加の IP が必要になります。サブネットが不足すると、Application Load Balancer がスケールできず、レイテンシーや 5xx エラーが発生します。予想される急増に備えるには、LCU 予約 を使用してキャパシティを事前にプロビジョニングしてください。

AWS WAF
AWS WAF が Application Load Balancer に関連付けられている場合、WAF ルールの評価が request_processing_time フィールドに加算されます。この増加は、リクエストボディが大きい POST リクエストで最大になります。WAF がターゲットに転送する前にボディを検査するためです。詳細については、『Application Load Balancer のトラブルシューティング』を参照してください。

SSL/TLS 設定
Application Load Balancer がより高速なハンドシェイクのために最新のセキュリティポリシーを使用していることを確認します。カスタム証明書の場合は、完全な証明書チェーンが構成されていることを確認してください。中間証明書が欠落していると、TLS ハンドシェイクにレイテンシーが追加されます。

ネットワークインフラストラクチャ
Application Load Balancer のサブネットに、外部向けインターネットゲートウェイへのルートまたは適切な内部ルートがあることを確認します。

**注: ** 内部 Application Load Balancer の場合、サブネットにインターネットゲートウェイのルートは必要ありません。バックエンドターゲットが外部サービスにアクセスする必要がある場合は、サブネットに NAT ゲートウェイへのルートがあることを確認してください。VPC Reachability Analyzer を使用して、Application Load Balancer の Elastic Network Interface (ENI) とターゲット間の接続の問題を診断することもできます。

バックエンドサーバーと依存関係を確認する

バックエンドサーバーと依存関係を確認するには、次のアクションを実行してください。

• 高い CPU 使用率を特定するには、バックエンドインスタンスの CloudWatch の CPUUtilization メトリクスを確認する。高い CPU 使用率を解決するには、インスタンスをより大きなインスタンスタイプにアップグレードする。

• バックエンドで実行されているプロセスおよびメモリの問題をチェックするには、次の Linux コマンドを実行する。

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

  注: httpd をサーバーのプロセス名に置き換えてください。
  出力例:

  Every  1.0s: echo -n 'Apache Processes:' && ps -C httpd --no-headers | wc -l  && free -m  Apache  Processes:6 total used free shared buff/cache availableMem:  961 332 78 3 550 483Swap:  0 0 0

• 現在実行されている Web サーバープロセスの数を確認するには、次の Linux コマンドを実行します。

  ps aux  | grep httpd | wc -l

  注: httpd をサーバーのプロセス名に置き換えてください。

  出力例:

  7

• ウェブサーバーの最大同時接続数またはワーカー制限を確認する。各 Web サーバーには、処理できる同時リクエストの最大数を制御する構成設定がある。この制限に達すると、Application Load Balancer からの新しいリクエストがキューに溜まり、レイテンシーが増加する。ウェブサーバーの種類に応じた関連設定を確認する。

• バックエンドインスタンス上でレイテンシーの問題を引き起こす可能性のある依存関係を確認する。依存関係の例としては、Amazon Simple Storage Service (Amazon S3) バケット、ネットワークアドレス変換 (NAT) インスタンスまたはプロキシサーバー、リモート Web サービス、データベースなどがある。

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

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

• uptime コマンドを実行して、リソースの競合による高いシステムロードアベレージを確認する。
• mpstat -P ALL 1 コマンドを実行して、各コアの CPU 使用率の内訳を表示し、使用率の偏りを判断する。
• pidstat 1 コマンドを実行して、リソースを大量に消費するプロセスと経時的なパターンを特定する。
• dmesg | tail コマンドを実行して、パフォーマンスに影響を与える可能性のある最近のシステムレベルのイベントを特定する。出力には、最新 10 件のシステムメッセージが表示される。
• iostat -xz 1 コマンドを実行して、読み取りまたは書き込み操作の多さ、あるいはディスクパフォーマンスの低下を特定する。
• free -m コマンドを実行して、利用可能なシステムメモリを表示する。利用可能なメモリが少ない場合、システムがスワップに依存し、ディスク I/O とレイテンシーが増加する可能性がある。
• sar -n DEV 1 コマンドを実行して、帯域幅の飽和を特定する。出力には、ネットワークインターフェイスのスループットが表示される。
• sar -n TCP,ETCP 1 を実行して TCP メトリクスを表示する。retrans/s メトリクスは、1 秒あたりの TCP 再送信回数を示す。このメトリクスが高い場合、パケット損失または輻輳が発生している可能性がある。
• ネットワークで最も帯域幅を使用しているものを特定するには、iftop コマンドを実行する。出力には、各接続のアクティブな帯域幅使用量がリアルタイムで表示される。
• niftop コマンドは iftop の派生版で、Red Hat Enterprise Linux (RHEL) および Debian ベースのディストリビューションのサードパーティーリポジトリから入手できる場合がある。iftop がシステムにプリインストールされていない場合は、niftop を使用する。

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