ネットワーク係の手塚です。
はじめに
本記事は、AWS Gateway Load Balancer の TCP フローのアイドルタイムアウトに対するベストプラクティスの紹介です。
AWS Gateway Load Balancer の導入前に一読いただけると幸いです。
AWS Gateway Load Balancer の TCP フローのアイドルタイムアウトとは?
AWS Gateway Load Balancer は自身を経由する TCP フローと転送先のターゲットの紐付けのため、TCP フローを持ちます。
2024年9月5日更新
この TCP フローは 350 秒固定のアイドルタイムアウト値が設定されており、この値の変更はできません。
AWS Gateway Load Balancer で TCP アイドルタイムアウトの変更がサポートされました
- 60秒から6000秒のアイドルタイムアウト設定が可能になりました
- アイドルタイムアウトのデフォルト設定には変更なく、350 秒以上通信が経由しない TCP フローは削除されます
- Cloud Watchメトリクス
RejectedFlowCountおよびRejectedFlowCount_TCP metricsで拒否されたフロー総数の測定が可能です aws.amazon.com aws.amazon.com
以下は上記の更新前の記事ですが、AWSのベストプラクティスや本記事の方向性は大きく変わりません。
影響は?
AWS Gateway Load Balancer を経由し、350 秒以上の無通信が発生した TCP アプリケーションについて、以降の通信継続が不可となる可能性があります。
影響を受けるアプリケーションは?
我々が確認した限りでは、次のアプリケーションに対策が必要でした。
- Active Directory のサイト間レプリケーション
- DB 接続のコネクションプーリング
- SAP GUI
- Oracle データベース・リンク (弊社佐竹の記事) # 2023年6月12日追記
- RPA ツールの通信 (詳細は不明)
- OpenSSH (再現検証で使用)
上記は一例で、該当するアプリケーションは無数にあると考えます。
ベストプラクティス
AWS Gateway Load Balancer の TCP フローのアイドルタイムアウト影響を回避するためのベストプラクティスは、「クライアントもしくサーバ」の「アプリケーションもしくはOS」設定により、TCP 通信を 350 秒未満の間隔で発生させること、です。
上記設定により、AWS Gateway Load Balancer 上の TCP フローは維持されつつ、待機時間が 350 秒を超える TCP アプリケーションを、AWS Gateway Load Balancer 経由で利用できます。
次はアプリケーションと OS の設定例です。
アプリケーション設定例
例) SSH クライアントから 60 秒に 1 回、メッセージを送信
ssh username@server -o ServerAliveInterval=60
利用アプリケーションにて、 350 秒未満の TCP キープアライブに該当する設定がない場合、次の OS 設定で対応します。
OS 設定例
OS による TCP キープライブ設定は、クライアントもしくはサーバのどちらか一方に設定があれば、有効になります。
主要 OS のデフォルトは 7,200 秒であるため、これを 350 秒未満に変更します。
例) Linux OS の TCP キープライブ間隔を 60 秒に設定
net.ipv4.tcp_keepalive_time = 60
例) Windows OS の TCP キープアライブ設定
次のサイト記載の「1. TCP コネクションの接続状態管理に利用されるパラメーター / KeepAliveTime 」が該当します。
https://social.technet.microsoft.com/Forums/ja-JP/30897df3-dc52-4c92-808b-ac01cc6936ee/tcp?forum=Wcsupportjasocial.technet.microsoft.com
上記は OS 上の全ての TCP 接続で有効となるため、本番機への投入時は注意です。
より大きな値にすることで負荷は軽減しますが、350 秒未満である必要があります。
他の対策はないか?
「クライアント・サーバ設定の変更は難しい」「AWS 側で対応できないか ?」というリクエストをよくいただきますが、 まず 本記事のベストプラクティスの実施をお願いします。
2024年9月5日更新
現状、セカンドベストは無く、アプリケーションもしくは OS の TCP キープアライブ設定が、ベストプラクティスかつ唯一の対策です。
AWS Gateway Load Balancer で最大6,000秒のアイドルタイムアウト設定が可能になりました。
Introducing configurable TCP idle timeout for Gateway Load Balancer | Networking & Content Delivery
これにより一次対応や恒久対策までの繋ぎとして有益なケースがあると考えます。
また AWS Gateway Load Balance のアイドルタイムアウト値を増やすことにより、フローテーブルのエントリ数の上限に抵触する懸念がありますが、これによるフローの拒否数は次の CloudWatch メトリクスで計測可能です。
- RejectedFlowCount
- RejectedFlowCount_TCP
AWS Gateway Load Balancer のアイドルタイムアウト設定は、上記メトリクスが増加しないよう行う必要があります。
AWS 公式ベストプラクティスについて
次の記事は AWS Gateway Load Balancer の公式ベストプラクティスです。この中の 1 番目の章に、本記事のベストプラクティスが含まれます。
- Tune TCP keep-alive or timeout values to support long-lived TCP flows)
ファイアウォールのタイムアウトを 350 秒未満にする案は ?
次の文に記載されている、ファイアウォールのタイムアウト設定と考えますが、本記事では推奨しません。
To prevent this from happening, we recommend configuring the TCP keep-alive setting to less than 350 seconds on either client/server’s application/Operating System (OS) or update your firewall’s timeout settings to less than 350 seconds for TCP and less than 120 seconds for non-TCP flows
Best practices for deploying Gateway Load Balancer | Networking & Content Delivery
これを防ぐには、クライアント/サーバーのアプリケーション/オペレーティングシステム（OS）でTCPキープアライブ設定を350秒未満に設定するか、ファイアウォールのタイムアウト設定をTCPで350秒未満、TCP以外のフローで120秒未満に更新することを推奨します。
推測ですが、上記のファイアウォール設定による対策は、次の 2 つの前提条件で成り立つと考えます。
- ファイアウォールは、自身の TCP フローのアイドルタイムアウト時に TCP リセットを送信する。
- クライアントおよびサーバのアプリケーションは、TCP リセットを受信しても、アプリケーション終了やエラーを発生させず、新規 TCP 接続で通信を継続できる仕様である。
この前提では、対策の可否がファイアウォール仕様に加えてクライアント・サーバ仕様にも依存するため、クライアント・サーバの TCP キープアライブ設定による対策と比較すると汎用性が低く、広く推奨しづらいと考えます。
おわりに
AWS Gateway Load Balancer の導入前に、これを利用するクライアント・サーバ管理者に本記事のベストプラクティスの周知と実施が必要と考えます。 しかし実際には対策漏れも発生しうるため、影響が発生した環境に対して、速やかに本記事のベストプラクティスの情報を提供ができる体制が重要と考えます。
2024年9月5日更新
また本記事では、ベストプラクティスが唯一の対策である理由について、説明することができませんでしたが、ネットワークエンジニアは把握したい内容と考えるため、別の記事で共有させていただきます。
AWS Gateway Load Balancer で TCP アイドルタイムアウトの変更がサポートされましたが、全てのケースに対応できる訳ではありません。 アプリケーション通信の待機時間が 6,000 秒を超えるケースや、アイドルタイムアウトの増加により AWS Gateway Load Balancer を経由するアクティブフローが増え、この上限に抵触し、転送拒否される可能性もあると考えます。
よってベストプラクティスは従来通り、「クライアントもしくサーバ」の「アプリケーションもしくはOS」設定により、TCP 通信を 350 秒未満の間隔で発生させること、となります。
以上
手塚 忠 (Tadashi Tetsuka) 記事一覧はコチラ
カスタマーサクセス部所属、2019 年 2 月入社のネットワークエンジニア。シリアルコンソールがマネジメントコンソールに変わったが、スイッチ愛は今も変わらず。 2023 Japan AWS Top Engineers (Networking), 2023 AWS ALL Certifications Engineers
