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 つの正常なターゲットが登録されている場合、Network Load Balancer は、この正常な登録済みターゲットに対してのみリクエストをルーティングします。

登録されているのが異常なターゲットのみの場合、Network Load Balancer は、登録されたすべてのターゲットに対しリクエストをルーティングします。これは、fail-open モードと呼ばれます。すべてのターゲットに異常があり、各アベイラビリティーゾーン内にリクエストの送信先となる正常なターゲットが見つからない場合、Network Load Balancer は、DNS からすべての IP アドレスを削除する代わりに、この fail-open モードを使用します。

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

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

セキュリティグループをロードバランサーに関連付けできない

Network Load Balancer がセキュリティグループなしで作成された場合、作成後にセキュリティグループをサポートすることはできません。セキュリティグループは、作成中にロードバランサに関連付けるか、または最初にセキュリティグループを使用して作成した既存のロードバランサーに関連付けることができます。

すべてのセキュリティグループを削除できない

セキュリティグループを使用して Network Load Balancer が作成された場合は、常に 1 つ以上のセキュリティグループが関連付けられている必要があります。ロードバランサーからすべてのセキュリティグループを同時に削除することはできません。

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

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

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

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

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

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

AWS PrivateLink を介した接続のポート割り当てエラー

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

クライアント 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 アドレスの割り当てを解除し、作成プロセスを再試行することで解決できます。

DNS の名前解決の対象 IP アドレスの数が有効なアベイラビリティーゾーンの数より少ないです。

アベイラビリティーゾーンに少なくとも 1 つの正常なホストがある場合、Network Load Balancer は有効なアベイラビリティーゾーンごとに IP アドレスを 1 つ提供するのが理想です。特定のアベイラビリティーゾーンに正常なホストがなく、クロスゾーンのロードバランシングが無効になっている場合は、その AZ に対応する Network Load Balancer の IP アドレスが DNS から削除されます。

例えば、Network Load Balancer が有効なアベイラビリティーゾーンを 3 つ持っており、すべてのアベイラビリティーゾーンには、正常なターゲットインスタンスが少なくとも 1 つ登録されているとします。

• アベイラビリティーゾーン A に登録されているターゲットインスタンス (のいずれか) が異常になると、Network Load Balancer でアベイラビリティーゾーン A に対応する IP アドレスが DNS から削除されます。

• 有効なアベイラビリティーゾーンのうち 2 つで、登録されたターゲットインスタンス (のいずれか) に異常がある場合は、対応する 2 つの Network Load Balancer の IP アドレスが DNS から削除されます。

• 有効なすべてのアベイラビリティーゾーンで、登録されたすべてのターゲットインスタンスが正常ではない場合、フェールオープンモードが有効化され、その結果、DNS は有効な 3 つの AZ からのすべての IP アドレスを提供するようになります。