Network Load Balancer をトラブルシューティングする - Elastic Load Balancing
登録されたターゲットが実行中でないリクエストがターゲットにルーティングされないターゲットが受け取るヘルスチェックリクエストが想定よりも多いターゲットが受け取るヘルスチェックリクエストが想定よりも少ない異常なターゲットがロードバランサーからリクエストを受信するホストヘッダーの不一致により、ターゲットが HTTP または HTTPS ヘルスチェックに失敗するTCP_ELB_Reset_count メトリクスを増加ターゲットからそのロードバランサーへのリクエストが接続タイムアウトになるNetwork Load Balancer にターゲットを移動する際にパフォーマンスが低下するAWS PrivateLink を介した接続のポート割り当てエラークライアント IP 保存が有効になっている場合の断続的な接続障害TCP 接続の遅延ロードバランサーのプロビジョニング時に発生する可能性のあるエラーApplication Load Balancer をターゲットとして使用したときの断続的な 503 エラー

Network Load Balancer をトラブルシューティングする

以下の情報は、Network Load Balancer の問題のトラブルシューティングに役立ちます。

登録されたターゲットが実行中でない

ターゲットが InService 状態になるまでに予想以上に時間がかかっている場合、ヘルスチェックに合格していない可能性があります。ターゲットは、ヘルスチェックに合格するまで実行されません。詳細については、「」を参照してくださいターゲットグループのヘルスチェック

インスタンスがヘルスチェックに合格していないことを確認したら、以下についてチェックします。

セキュリティグループでトラフィックが許可されていない

インスタンスに関連付けられたセキュリティグループでは、ヘルスチェックポートとヘルスチェックプロトコルを使用してロードバランサーからのトラフィックを許可する必要があります。詳細については、「ターゲットセキュリティグループ」を参照してください。

ネットワークアクセスコントロールリスト (ACL) ではトラフィックが許可されない

インスタンスのサブネットとロードバランサーのサブネットに関連付けられているネットワーク ACL は、ロードバランサーからのトラフィックとヘルスチェックを許可する必要があります。詳細については、「ネットワーク ACL」を参照してください。

リクエストがターゲットにルーティングされない

以下を確認します。

セキュリティグループでトラフィックが許可されていない

インスタンスに関連付けられているセキュリティグループでは、リスナーポートからクライアント IP アドレス (ターゲットがインスタンス ID で指定されている場合) またはロードバランサーノード (ターゲットが IP アドレスで指定されている場合) へのトラフィックが許可されている必要があります。詳細については、「ターゲットセキュリティグループ」を参照してください。

ネットワークアクセスコントロールリスト (ACL) ではトラフィックが許可されない

VPC のサブネットに関連付けられているネットワーク ACL では、リスナーポートでロードバランサーとターゲットの双方向の通信が許可されている必要があります。詳細については、「ネットワーク ACL」を参照してください。

有効になっていないアベイラビリティーゾーンにターゲットがある

ターゲットをアベイラビリティーゾーンに登録したが、アベイラビリティーゾーンを有効にしていない場合、登録したターゲットはロードバランサーからのトラフィックを受信しません。

インスタンスがピア接続 VPC にある

ロードバランサー VPC とピア接続されている VPC にインスタンスがある場合、インスタンス ID ではなく IP アドレスで、そのインスタンスをロードバランサーに登録する必要があります。

ターゲットが受け取るヘルスチェックリクエストが想定よりも多い

Network Load Balancer のヘルスチェックは分散され、コンセンサスメカニズムを使用してターゲットのヘルスを判断します。そのため、ターゲットは HealthCheckIntervalSeconds 設定で設定されているヘルスチェック数よりも多くのヘルスチェックを受けます。

ターゲットが受け取るヘルスチェックリクエストが想定よりも少ない

net.ipv4.tcp_tw_recycle が有効化されているかどうかを確認します。この設定は、ロードバランサーに関する問題が発生することが判っています。net.ipv4.tcp_tw_reuse 設定の方が安全であると見なされています。

異常なターゲットがロードバランサーからリクエストを受信する

ロードバランサーに対して少なくとも 1 つの正常な登録済みターゲットがある場合、ロードバランサーは正常な登録済みターゲットにのみリクエストをルーティングします。異常な登録済みターゲットのみがある場合、ロードバランサーはすべての登録済みターゲットにリクエストをルーティングします。

ホストヘッダーの不一致により、ターゲットが HTTP または HTTPS ヘルスチェックに失敗する

ヘルスチェックリクエストの HTTP ホストヘッダーには、ターゲットの IP アドレスおよびヘルスチェックポートではなく、ロードバランサーノードの IP アドレスおよびリスナーポートが含まれます。受信リクエストをホストヘッダーでマッピングする場合は、ヘルスチェックが任意の HTTP ホストヘッダーと一致することを確認する必要があります。別のオプションとして、別のポートに別々の HTTP サービスを追加し、代わりにそのポートをヘルスチェックに使用するようにターゲットグループを設定することもできます。または、TCP ヘルスチェックの使用を検討してください。

TCP_ELB_Reset_count メトリクスを増加

クライアントが Network Load Balancer を通じて行う TCP リクエストごとに、その接続の状態が追跡されます。アイドルタイムアウトよりも長い時間、クライアントからもターゲットからもその接続経由でデータが送信されない場合、接続は閉じられます。アイドルタイムアウト期間の経過後にクライアントまたはターゲットがデータを送信した場合、TCP RST パケットを受信して、接続が無効になったことを示します。さらに、ターゲットが異常になると、ロードバランサーは、ターゲットに関連付けられたクライアント接続で受信したパケットの TCP RST を送信します (異常なターゲットがトリガーしたロードバランサーが起動しなかった場合以外)。

UnhealthyHostCount メトリクスが増加する直前または増加すると同時に、TCP_ELB_Reset_Count メトリクスにスパイクが見られる場合は、ターゲットが失敗し始めたが異常とマークされていないため、TCP RST パケットが送信された可能性があります。TCP_ELB_Reset_Count で永続的な増加が見られたら、ターゲットが正常でないとマークされない場合、期限切れのフローでデータを送信しているクライアントの VPC フローログを確認できます。

ターゲットからそのロードバランサーへのリクエストが接続タイムアウトになる

ターゲットグループでクライアント IP 保存が有効になっているかどうかを確認します。クライアント IP 保存が有効になっているロードバランサーは、ヘアピニングまたはループバックをサポートしていません。インスタンスが、登録されているロードバランサーのクライアントである場合で、クライアント IP 保護が有効になっている場合、リクエストが別のインスタンスにルーティングされる場合のみ接続が成功します。それ以外の場合は、送信元と宛先の IP アドレスが同じであるため、接続がタイムアウトします。

インスタンスが、それが登録されているロードバランサーにリクエストを送信する必要がある場合は、次のいずれかを実行します。

  • クライアント IP の無効化

  • 通信する必要があるコンテナが異なるコンテナインスタンスにあることを確認します。

Network Load Balancer にターゲットを移動する際にパフォーマンスが低下する

Classic Load Balancer と Application Load Balancer はどちらも接続の多重化を使用しますが、Network Load Balancer では使用しません。したがって、ターゲットは Network Load Balancer の背後で複数の TCP 接続を受け取ることができます。必ず、ターゲットが受信する可能性のある接続リクエストのボリュームを処理できるようにしてください。

Network Load Balancer が VPC エンドポイントサービスに関連付けられている場合、ロードバランサーは一意の各ターゲット (IP アドレスとポート) に対して 55,000 の同時接続または 1 分あたり約 55,000 の接続をサポートできます。これらの接続数を超えた場合、ポート割り当てエラーが発生する可能性が高くなります。ポート割り当てエラーは、PortAllocationErrorCount メトリクスを使用して追跡できます。ポート割り当てエラーを修正するには、ターゲットグループにさらに多くのターゲットを追加します。詳細については、「Network Load Balancer の CloudWatch メトリクス」を参照してください。

クライアント IP 保存が有効になっている場合の断続的な接続障害

クライアント IP の保存が有効な場合、ターゲットで確認されたソケットの再利用に関連する TCP/IP 接続の制限が発生することがあります。これらの接続制限が発生する可能性があるのは、クライアント、またはクライアントの前面にある NAT デバイスが、複数のロードバランサーノードに同時に接続する際に、同じ送信元 IP アドレスと送信元ポートを使用する場合です。ロードバランサーがこれらの接続を同じターゲットにルーティングする場合、接続は同じ送信元ソケットからの接続のようにターゲットに表示され、それにより接続エラーが発生します。その場合、クライアントは再試行 (接続が失敗した場合)、または再接続 (接続が中断した場合) できます。このタイプの接続エラーは、送信元の一時ポートの数を増やすか、ロードバランサーのターゲット数を増やすことによって減らすことができます。このタイプの接続エラーは、クライアント IP の保存を無効にするか、クロスゾーン負荷分散を無効にすることで防止できます。

さらに、クライアント IP の保存が有効な場合、Network Load Balancer に接続しているクライアントがロードバランサーの背後にあるターゲットにも接続されると接続に失敗することがあります。この問題を解決するには、影響を受けるターゲットグループでクライアント IP 保存を無効にすることができます。または、クライアントを Network Load Balancer にのみ接続するか、ターゲットにのみ接続します。ただし、両方に接続することはできません。

TCP 接続の遅延

クロスゾーン負荷分散とクライアント IP の保存の両方が有効になっている場合、同じロードバランサー上の異なる IP に接続しているクライアントが同じターゲットにルーティングされることがあります。クライアントがこれらの接続の両方に同じソースポートを使用する場合、ターゲットでは重複しているかのような接続を受信します。これにより、接続エラーや新しい接続を確立する際の TCP 遅延が発生する可能性があります。このタイプの接続エラーは、クロスゾーン負荷分散を無効にすることで防止できます。詳細については、「クロスゾーン負荷分散」を参照してください。

ロードバランサーのプロビジョニング時に発生する可能性のあるエラー

Network Load Balancer がプロビジョニング中に失敗する理由の 1 つとして、既に割り当てられているか、別の場所で割り当てられている IP アドレス (EC2 インスタンスのセカンダリ IP アドレスとして割り当てられているなど) を使用していることが考えられます。この IP アドレスにより、ロードバランサーの設定が妨げられ、状態は failed になります。この問題は、関連付けられた IP アドレスの割り当てを解除し、作成プロセスを再試行することで解決できます。

Application Load Balancer をターゲットとして使用したときの断続的な 503 エラー

Network Load Balancer のクロスゾーンロードバランシングが無効になっていて、Application Load Balancer でクロスゾーンロードバランシングが有効になっている場合、Application Load Balancer を Network Load Balancer のターゲットとして使用すると、断続的な 53 エラーが発生する可能性があります。両方のロードバランサーを構成してクロスゾーンロードバランシングに同じ設定を使用することによって、この問題を防止できます。