Amazon Web Services ブログ
NLB で設定可能な TCP アイドルタイムアウトの導入
この投稿では、AWS Network Load Balancer (NLB) の Transmission Control Protocol (TCP) フローのアイドルタイムアウトを設定する手順を説明します。
NLB は Open Systems Interconnection (OSI) モデルのレイヤー 4 で動作する Amazon Web Services (AWS) の Elastic Load Balancing ファミリの一部で、TCP または User Datagram Protocol (UDP) でクライアント接続を管理し、それらをロードバランサーのターゲットに分散します。
NLB は接続の確立から、非アクティブ (アイドルタイムアウト) による閉鎖またはタイムアウトまでを追跡します。
デフォルトでは、TCP 接続のアイドルタイムアウトは 350 秒、UDP 接続のタイムアウトは 120 秒です。
新しく TCP のアイドルタイムアウトが設定可能になったため、既存および新規の NLB TCP リスナーでこの属性を変更できるようになり、NLB が非アクティブな接続を終了するまでの時間を決められるようになりました。
TCP 接続確率の手順の理解
始める前に、TCP プロトコルの動作の概要を説明します。より深く理解するには、TCP の RFC(RFC 9293) を参照してください。
TCP 接続には確立、データ転送、正常なクローズなどのいくつかの段階があります。
- ハーフオープン: クライアントが SYN を送信し、サーバーが応答しますが、まだクライアントがハンドシェイクを完了していない状態。
- 接続確立: 3 ウェイハンドシェイクが完了した状態。
- データ転送: ハンドシェイク後、クライアントとサーバーの間でデータを交換している状態。この図の部分は、読みやすくするために簡略化されています。
- クローズ: クライアントが FIN パケットを送信し、正常にクローズされます。
NLB の TCP 接続処理
NLB は、レイヤー 4 プロキシとして動作し、確立された各接続をフローテーブルで追跡します。
ハーフオープン、正常にクローズした接続、またはクライアントまたはサーバーでリセットされた接続は追跡されません。
単一の接続は 5 つの属性の組み合わせ (5 タプル) によって定義され、プロトコル (TCP)、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポートからなります。
図 2. NLB デプロイのサンプルアーキテクチャ
デフォルトでは、クライアントとターゲット間でトラフィックがない状態が 350 秒続くと、NLB のフローテーブルからその接続が削除されます。
接続が追跡されなくなった後にクライアントがトラフィックを送信しようとすると、NLB は新しい接続を確立する必要があることを示す TCP RST を返します。
多くのアプリケーションでは、接続がタイムアウトしても問題ありません。
しかし、一部の場合は問題となることがあります。
例えば、定期的にデータを送信する IoT (Internet of Things) デバイスは、それぞれの送信時で少量のデータしか転送しません。
そのたびにデータが送信されるごとに、特に暗号化された接続を再度開くと、リソースを大量に消費し、コストがかかります。
接続がタイムアウトしないように、TCP キープアライブを設定して、確立された接続に対して決められた間隔でプローブ(※1)を送信することができます。このプローブにはデータは含まれていませんが、NLB などの中継システムでのアイドルタイマーをリセットすることができます。TCP キープアライブの設定方法の詳細については、以前の記事”Implementing long-running TCP Connections within VPC networking“を参照してください。
アプリケーションで長期間持続する永続的な TCP 接続が必要で、TCP キープアライブを使用できない場合は、NLB の TCP アイドルタイムアウトを変更できます。
TCP アイドルタイムアウトの更新時の考慮事項
各 NLB TCP リスナーのアイドル タイムアウト値は 60 ~ 6000 秒の範囲内で調整できます。
この変更はすでに進行中の接続には影響せず、新しい TCP 接続にのみ影響します。
その他のリスナの種類 (TLS、UDP など) では、現時点でアイドル タイムアウト値の調整はサポートされていません。
アイドルタイムアウト値を設定する前に、アプリケーションのニーズを理解し、TCP キープアライブが代替手段になり得るかを検討してください。
NLB の TCP アイドルタイムアウトは、アプリケーションの TCP アイドルタイムアウトよりも長く設定するのが適切です。
つまり、NLB ではなく、アプリケーションが接続管理とタイムアウトを処理することになります。
アイドルタイムアウトを高すぎる値に設定すると、フローテーブルがいっぱいになるリスクが高まります。テーブルがいっぱいになると、NLB が新しい接続を暗黙に拒否するようになります。Amazon CloudWatch の新しいメトリクス (監視セクションで説明) を使って、接続拒否を監視する必要があります。
接続が拒否された場合は、TCP アイドルタイムアウトの値を小さくする必要があります。
TCP アイドルタイムアウトを AWS API/CLI で設定する手順
AWS は TCP アイドルタイムアウト機能を Network Load Balancer に導入するにあたり、新しい API を公開しました。以下の例は API の動作を示しています。
TCP アイドルタイムアウトの現在の値を確認するための、NLB リスナーについて説明します。
入力:
出力:
TCP アイドルタイムアウトの値を変更する
入力:
出力:
TCP アイドルタイムアウトを AWS マネジメントコンソールで設定する手順
次の手順では、AWS マネジメントコンソールでタイムアウト値を変更する方法を示します。
1. NLB の TCP リスナーを見つけます。
2. Attributes セクションで現在の TCP アイドルタイムアウト の値を確認します。
3. リスナー属性の編集セクションで、新しいTCP アイドルタイムアウト値を入力します。
図 5. アイドルタイムアウトの設定
監視
Network Load Balancer の TCP アイドルタイムアウトの導入により、2 つの新しいメトリクス RejectedFlowCount (フローテーブルがいっぱいで拒否されたフロー数の合計) と RejectedFlowCount_TCP (同じ理由で拒否された TCP フロー数) が追加されました。
これらのメトリクスを使って、アイドルタイムアウト設定の影響を監視できます。
NLB がフローの受け入れを拒否し始めたときにあなたに通知を受け取れるように、CloudWatch アラームをセットアップすることをお勧めします。
RejectedFlowCount の増加は、タイムアウトを短縮する必要があることを示していて、より早くフローを削除し、フローテーブルが一杯になるのを防ぐことができます。
既存の NLB メトリクス (NewFlowCount、NewFlowCount_TCP、ActiveFlowCount、ActiveFlowCount_TCP など) は変更されません。
結論
NLB での TCP アイドルタイムアウトを設定すると、長時間接続するアプリケーションなどで特に接続管理をより詳細に制御できます。アイドルタイムアウトを調整し関連するメトリクスを監視することで、NLB のパフォーマンスを最適化し接続の問題を防ぐことができます。
本稿は、2024年9月3日に Networking & Content Delivery で公開された “Introducing NLB TCP configurable idle timeout” を翻訳したものです。翻訳は Solutions Architect の長屋が担当しました。