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

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

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

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

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

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

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

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

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

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

以下を確認します。

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

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

ネットワークアクセスコントロールリスト (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 アドレスが異なる場合でも、同じ EC2 ワーカーノードインスタンスで実行されている Amazon EKS ポッドに適用されます。

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

• クライアント IP の無効化 代わりに、プロキシプロトコル v2 を使用してクライアント IP アドレスを取得します。

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

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

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

バックエンドフローのポート割り当てエラー

PrivateLink トラフィックまたはクライアント IP 保存が無効になっている場合、Network Load Balancer は各一意のターゲット (IP アドレスとポート) に対して 1 分あたり 55,000 の同時接続または約 55,000 の接続をサポートします。これらの制限を超えると、ポート割り当てエラーが発生する可能性が高くなります。ポート割り当てエラーは、 PortAllocationErrorCountメトリクスを使用して追跡できます。ActiveFlowCount メトリクスを使用してアクティブな接続を追跡できます。詳細については、「Network Load Balancer の CloudWatch メトリクス」を参照してください。

ポート割り当てエラーを修正するには、ターゲットをターゲットグループに追加することをお勧めします。

または、ターゲットグループにターゲットを追加できない場合は、ロードバランサーネットワークインターフェイスに最大 7 つのセカンダリ IP アドレスを追加できます。セカンダリ IP アドレスは、対応するサブネットの IPv4 CIDR ブロックから自動的に割り当てられます。各セカンダリ IP アドレスは、6 つのネットワークアドレス指定ユニットを消費します。セカンダリ IP アドレスを追加した後は、削除できないことに注意してください。セカンダリ IP アドレスを解放する唯一の方法は、ロードバランサーを削除することです。

断続的な TCP 接続確立の失敗または TCP 接続確立の遅延

クライアント IP アドレスの保存が有効になっている場合、クライアントは同じ送信元一時ポートを使用して異なる送信先 IP アドレスに接続できます。これらの送信先 IP アドレスは、クロスゾーン負荷分散が有効になっている場合は同じロードバランサー (異なるアベイラビリティーゾーン) から、同じターゲット IP アドレスと登録されたポートを使用する異なる Network Load Balancer から送信できます。この場合、これらの接続が同じターゲット IP アドレスとポートにルーティングされると、ターゲットは同じクライアント IP アドレスとポートから送信されるため、重複した接続が表示されます。これにより、これらの接続の 1 つを確立するときに、接続エラーや遅延が発生します。これは、クライアントの前にある NAT デバイスがあり、複数の Network Load Balancer IP アドレスに同時に接続するときに同じ送信元 IP アドレスと送信元ポートが割り当てられている場合に頻繁に発生します。

このタイプの接続エラーを減らすには、クライアントまたは NAT デバイスによって割り当てられたソースエフェメラルポートの数を増やすか、ロードバランサーのターゲットの数を増やします。クライアントは、これらの接続の失敗後に再接続するときに使用するソースポートを変更することをお勧めします。このタイプの接続エラーを防ぐために、単一の Network Load Balancer を使用している場合は、クロスゾーン負荷分散を無効にすることを検討できます。複数の Network Load Balancer を使用している場合は、複数のターゲットグループに登録されている同じターゲット IP アドレスとポートを使用しないことを検討できます。または、クライアント IP 保存の無効化を検討することもできます。クライアント IP が必要な場合は、Proxy Protocol v2 を使用して取得できます。Proxy Protocol v2 の詳細については、「」を参照してくださいProxy Protocol。

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

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

トラフィックがターゲット間で不均等に分散されている

TCP および TLS リスナーは TCP 接続をルーティングし、UDP リスナーは UDP ストリームをルーティングします。ロードバランサーは、フローハッシュアルゴリズムを使用してターゲットを選択します。クライアントからの 1 つの接続は本質的にスティッキーです。

一部のターゲットが他のターゲットよりも多くのトラフィックを受信するように見える場合は、VPC フローログを確認することをお勧めします。各ターゲット IP アドレスの一意の接続の数を比較します。ターゲットの登録、登録解除、異常なターゲットはこれらの接続番号に影響するため、時間枠はできるだけ短くしてください。

以下は、接続を不均等に分散できるシナリオです。

• 少数のターゲットから始めて後で追加のターゲットを登録する場合、元のターゲットは引き続きクライアントと接続します。HTTP ワークロードでは、キープアライブによりクライアントが接続を再利用できるようになります。ウェブアプリケーションの最大キープアライブを減らすと、クライアントは新しい接続をより頻繁に開くようになります。

• ターゲットグループの維持が有効になっている場合、少数のクライアントがあり、クライアントは単一の送信元 IP アドレスを持つ NAT デバイスを介して通信し、これらのクライアントからの接続は同じターゲットにルーティングされます。

• クロスゾーン負荷分散が無効になっており、クライアントがロードバランサーの IP アドレスをロードバランサーゾーンの 1 つから優先する場合、接続はロードバランサーゾーン間で不均等に分散されます。

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 アドレスを提供するようになります。

リソースマップを使用して異常なターゲットをトラブルシューティングする

Network Load Balancer ターゲットがヘルスチェックに合格しなかった場合は、リソースマップを使用して異常なターゲットを見つけ、エラー理由コードに基づいてアクションを実行できます。詳細については、「Network Load Balancer リソースマップを表示する」を参照してください。

リソースマップには、[概要] と [異常なターゲットマップ] という 2 つのビューがあります。[概要] はデフォルトで選択されており、ロードバランサーのすべてのリソースが表示されます。[異常なターゲットマップ] ビューを選択すると、Network Load Balancer に関連付けられている各ターゲットグループ内の異常なターゲットのみが表示されます。

注記

リソースマップ内の該当するすべてのリソースのヘルスチェックの概要とエラーメッセージを表示するには、[リソースの詳細を表示] を有効にする必要があります。有効になっていない場合は、各リソースを選択して詳細を表示する必要があります。

[ターゲットグループ] 列には、各ターゲットグループの正常なターゲットと異常なターゲットの概要が表示されます。これは、すべてのターゲットがヘルスチェックに合格しなかったのか、特定のターゲットのみが合格しなかったのかを判断するのに役立ちます。ターゲットグループ内のすべてのターゲットがヘルスチェックに合格しなかった場合は、ターゲットグループのヘルスチェック設定を確認します。ターゲットグループの名前を選択して、新しいタブで詳細ページを開きます。

[ターゲット] 列には、各ターゲットの TargetID と現在のヘルスチェックステータスが表示されます。ターゲットに異常がある場合、ヘルスチェックのエラー理由コードが表示されます。1 つのターゲットがヘルスチェックに合格しなかった場合は、ターゲットに十分なリソースがあることを確認します。ターゲットの ID を選択して、新しいタブで詳細ページを開きます。

[エクスポート] を選択すると、Network Load Balancer のリソースマップの現在のビューを PDF としてエクスポートできます。

インスタンスがヘルスチェックに合格していないことを確認したら、エラー理由コードに基づいて、以下の点を確認します。

• [異常: リクエストがタイムアウトしました]

  • ターゲットと Network Load Balancer に関連付けられたセキュリティグループとネットワークアクセスコントロールリスト (ACL) が接続をブロックしていないことを確認します。

  • Network Load Balancer からの接続を受け入れるのに十分な容量がターゲットにあることを確認します。

  • Network Load Balancer のヘルスチェックレスポンスは、各ターゲットのアプリケーションログで確認できます。詳細については、「ヘルスチェックの理由コード」を参照してください。

• [異常: FailedHealthChecks]

  • ターゲットがヘルスチェックポートのトラフィックをリッスンしていることを確認します。

    TLS リスナーを使用している場合

    フロントエンド接続に使用するセキュリティポリシーを選択します。バックエンド接続に使用するセキュリティポリシーは、使用中のフロントエンドセキュリティポリシーに基づいて自動的に選択されます。

    • TLS リスナーがフロントエンド接続で TLS 1.3 セキュリティポリシーを使用している場合、バックエンド接続には ELBSecurityPolicy-TLS13-1-0-2021-06 セキュリティポリシーが使用されます。

    • TLS リスナーがフロントエンド接続で TLS 1.3 セキュリティポリシーを使用していない場合、バックエンド接続には ELBSecurityPolicy-2016-08 セキュリティポリシーが使用されます。

    詳細については、「セキュリティポリシー」を参照してください。

  • ターゲットがサーバー証明書とキーをセキュリティポリシーで指定された正しい形式で提供していることを確認します。

  • ターゲットが 1 つ以上の一致する暗号と、TLS ハンドシェイクを確立するために Network Load Balancer が提供しているプロトコルをサポートしていることを確認します。