Gateway Load Balancer の設定可能な TCP アイドルタイムアウトのご紹介

この記事は Introducing configurable TCP idle timeout for Gateway Load Balancer を翻訳したものです。

Amazon Web Service (AWS) Gateway Load Balancer (GWLB) は、サードパーティのファイアウォールアプライアンスをデータ経路に挿入できるマネージドな AWS サービスです。 GWLB は、サードパーティアプライアンスのデプロイ、スケーリング、管理を支援し、「Bump-in-the-Wire」デバイスとしてトラフィックをターゲットに透過的に渡します。顧客は、トラフィック検査のユースケースにおいて、GWLBターゲットとしてサードパーティのファイアウォールアプライアンスをデプロイします。詳細については、GWLB ドキュメントを参照してください。

GWLBの設定可能なTCPアイドルタイムアウト機能を紹介します。この機能により、GWLB の Transmission Control Protocol (TCP) アイドルタイムアウトを60秒から6000秒の範囲で設定できるようになります。

この投稿では、この機能の基本と利用のベストプラクティス、および AWSマネジメントコンソールと API を使用してセットアップする方法について説明します。

前提条件

以下のセクションでは、仮想プライベートクラウド ( VPC ) 、サブネット、 VPC ルーティングテーブルなどの基本的な AWS のネットワーキングサービスを理解していることを前提としています。また、 GWLB のターゲットとしてサードパーティのファイアウォールをセットアップする方法を理解していることも前提とします。 GWLB アーキテクチャの詳細については、 GWLB の投稿を参照してください。

GWLB の TCP アイドルタイムアウトとは？

GWLB は、フローの最初のパケットを確認するとフローテーブルにフローエントリを作成します。 GWLB は、2 タプル、3 タプル、または 5 タプルのハッシュを使ってフローを定義し、フローのすべてのパケットをバックエンドターゲットの1つにルーティングします。 GWLBは、各フローエントリを1つのバックエンドターゲットアプライアンスに結びつけることで、トラフィックの対称性を維持します。このトラフィックの対称性は、トラフィック検査やファイアウォールのユースケースにおいて必要不可欠です。

GWLB は、そのフローのパケットが GWLB を通過する限り、フローをアクティブと見なします。フローのパケットが停止すると、そのフローはアイドルと見なされ、アイドルタイマーが開始されます。所定のアイドル時間が経過すると GWLB はフローテーブルからフローエントリを削除します。

なぜ GWLB に設定可能な TCP タイムアウトが必要か？

これまで、GWLB は固定のTCPアイドルタイムアウト値 (350秒) をサポートしていました。アイドルタイムアウト後に GWLB に到着するパケットは新しいフローと見なされ、別のターゲットに転送される可能性がありました。

しかし、多くのファイアウォールやレガシーデータベースなどのアプリケーションは、デフォルトの TCP アイドルタイムアウト値としてより長い時間が設定されています。 GWLB とアプリケーションのタイムアウト値の不一致により、アプリケーション側で長時間アイドル状態だったフローが GWLB のタイムアウトによって異なるターゲットに転送され、トラフィックフローの中断を引き起こす可能性があります。

GWLBの設定可能なTCPアイドルタイムアウト機能を使用すると、ファイアウォールやアプリケーションの TCP アイドルタイムアウト値を GWLB と合わせることができ、トラフィックフローの継続性を確保し、トラフィックの中断を減らすことができます。

Palo Alto Networks、Fortinet、Cisco、Check Point などのサードパーティのファイアウォールは、350 秒を超える TCP アイドルタイムアウト値をサポートしており、デフォルトの TCP アイドルタイムアウト値が 3600 秒に設定されていることもよくあります。このGWLB とターゲットアプライアンスの TCP アイドルタイムアウト値の不一致により、トラフィックが中断する可能性があります。図1a、図1b にて、トラフィック中断につながる構成例と一連の動作を示します。このシナリオでは、バックエンドのファイアウォールアプライアンスのTCPアイドルタイムアウト値はデフォルトの60分を使用している想定です。

図1a は、フローが最初に確立されたときの GWLB とバックエンドファイアウォールアプライアンスのフローテーブルを示しています。

図1a: 新規フロー確立時の GWLB とファイアウォールのフローテーブル

[1] VPC – 1 にデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが、TCP フローを開始し、Availability Zone (AZ) – b の GWLB エンドポイント (GWLB-EP B) にデータを送信します。

[2] GWLB – EP Bはトラフィックをファイアウォール VPC にデプロイされた GWLB に送信します。

[3] GWLB はこのフローをフローテーブルに見つけられないため、新しいフローエントリを作成します。TCP アイドルタイムアウト値は 350 秒に設定されます。GWLB はこのフローのバックエンドターゲットとして T2 を選択します。

[4] GWLB は元のトラフィックを GENEVE トンネルにカプセル化し、このデータを T2 に送信します。

[5] T2はテーブル内に新しいフローエントリを作成し、TCP アイドルタイムアウト値を 3600 秒に設定します。

データフローが停止すると、GWLB の TCP アイドルタイムアウトがトリガーされます。図1bは、データフローが停止してから350秒後の GWLB とバックエンドファイアウォールのフローテーブルを示しています。

[6] Flow-1 の GWLB TCP アイドルタイムアウトが期限切れになります。この時点で、GWLB はフローテーブルからこのフローエントリを削除します。

[7] バックエンドのファイアウォールアプライアンスは、フローエントリをテーブルに保持します。アイドルタイマーは 3250 秒になります。

図1bは、送信元のEC2インスタンスが同じフローの他のパケットを送信したときの一連の動作を示しています。

図1b: トラフィックフローが再びアクティブになったときのGWLBとファイアウォールのフローテーブル

[8] 350秒以上アイドル状態が続いた後、ソースのEC2インスタンスが同じフローの他のパケットを GWLB-EP B に送信します。

[9] GWLB-EP B はトラフィックを GWLB に送信します。

[10] GWLB はこのフローをフローテーブルに見つけられないため、GWLB はこのフローを新規のフローと見なし、新しいフローエントリ (Flow-2) を作成します。アイドルタイムアウトは 350 秒に設定されます。今回は GWLB のハッシュアルゴリズムによって T1 がこのフローのバックエンドターゲットとして選択されます。

[11、12] T1 はパケットを受信しますが、 TCP フローであるためパケットをドロップします。これは、ステートフルファイアウォールでは、TCP フローのトラフィックを同じファイアウォールアプライアンスに対称的にルーティングする必要があるためです。この場合、T1 はこのフローの TCP ハンドシェイクを見ていないため、このフローを拒否します。これにより、トラフィックが中断します。

ステップ [10] は、GWLB がクロスゾーンロードバランシングを有効にしていることを前提としています。ただし、クロスゾーンロードバランシングが無効で、同じAZに複数のファイアウォールアプライアンスがデプロイされている場合でも、ステップ [11] と [12] で説明した問題が発生する可能性があります。

設定可能なTCPアイドルタイムアウトをどのように使用するか?

GWLB の IP リスナーに対して TCP アイドルタイムアウトを設定できます。この設定は IPv4 トラフィックと IPv6 トラフィックの両方に適用されます。

ステップ 1: GWLB リスナーの詳細を編集する

GWLB の詳細ページで、[Actions] を選択し、[View listener details] を選択します (図 2 参照)。

図 2: GWLB リスナーの詳細

ステップ 2: TCP アイドルタイムアウト値を編集する

GWLB の [Attributes] タブで、TCP アイドルタイムアウトの詳細を編集 [Edit] します (図 3 参照)。

図 3: TCP アイドルタイムアウトを編集する

希望の TCP アイドルタイムアウト値を入力し、変更を保存します (図 4 参照)。

図 4: TCP アイドルタイムアウト値を入力する

新しく導入された modify-listener-attributes アプリケーションプログラムインターフェイス (API) 呼び出しを使用して、TCP アイドルタイムアウト値を編集できます。

aws elbv2 modify-listener-attributes \ 
--listener-arn arn:aws:elasticloadbalancing:<Region>:<AWS Account ID>:listener/gwy/<GWLB name>/<GWLB ID>/<Listener ID> \
--attributes \
Key=tcp.idle_timeout.seconds,Value=3700

modify-listener-attributes API 呼び出しを使用する際は、TCP アイドルタイムアウト値をキーと値のペアとして指定する必要があります。elbv2 CLI ドキュメントを参照して、サポートされているコマンドの完全なリストを確認してください。

ステップ 3: 新しい構成を確認する

図 5: GWLB IP リスナーの新しい TCP アイドルタイムアウトを確認する

ステップ 4: Amazon CloudWatch メトリクスを使用して監視する

GWLB は、タイムアウトしたフローの総数を監視できる新しい Amazon CloudWatch メトリクスをサポートするようになりました。RejectedFlowCount と RejectedFlowCount_TCP メトリクスを使用して、拒否されたフローの総数と拒否された TCP フローの総数を監視できます (図 6 参照)。これらのメトリクスは、GWLB のフローテーブルが上限に達し、 GWLB がフローを拒否した場合にのみ増加します。GWLB の TCP アイドルタイムアウトは徐々に増やすことをお勧めします。

図 6: RejectedFlowCount メトリクスを使用した CloudWatch アラーム

GWLB TCP アイドルタイムアウト値の設定に関する推奨事項

GWLB の TCP アイドルタイムアウトに非常に高い値に設定すると、GWLB はフローエントリをフローテーブル内でより長い期間アクティブに保ちます。そのため、GWLB のフローテーブルが大きくなります。これにより、GWLB のフローテーブルサイズを使い果たすリスクが生じます。このリスクを軽減するために、GWLB のフローテーブル内の使用可能なフロー数を示す AvailableFlowCount CloudWatch メトリクスを監視することをお勧めします。

長期実行フローのあるアプリケーションに関する推奨事項

このセクションでは、インライントラフィック検査のユースケースでトラフィックの中断を回避するために、GWLB の設定可能な TCP アイドルタイムアウト機能を使用する 3 つの推奨事項について説明します。

推奨事項 1: GWLB の TCP アイドルタイムアウト値を、ファイアウォールアプライアンスの TCP アイドルタイムアウト値よりわずかに高い値に設定することで、トラフィックの中断を回避できます。また、ファイアウォールアプライアンスが TCP セッションがタイムアウトしたときに TCP RST を送信するように設定することをお勧めします (サポートについてはファイアウォールベンダーに確認してください)。長期間アイドル状態が続く TCP フローにおいて、この設定より、バックエンドのファイアウォールターゲットがフローをタイムアウトさせることができます。バックエンドファイアウォールからの TCP RST により、クライアントの TCP セッションが適切に閉じられます。この構成により、クライアントデバイスやアプリケーションのコードを変更せずに、検査アーキテクチャを展開できます。

この構成は、TCP キープアライブをアプリケーションコード内に実装できない従来のアプリケーション、および Red Hat Enterprise Linux などの基盤となる OS のデフォルト設定を継承するアプリケーションに対して推奨されます。大規模なレガシーアプリケーションを抱えており、すべてのアプリケーション/クライアント/サーバーをアップグレードするためには長期間のメンテナンスウインドウが必要となる場合、この方法は実用的なアプローチです。

推奨事項 2: クライアント/サーバーの TCP アイドルタイムアウト値を、GWLB またはファイアウォールアプライアンスよりも低い値に設定します。これにより、クライアントまたはサーバーが、 GWLB またはファイアウォールアプライアンスでタイムアウトする前に、接続を適切に更新できるようになります。このアプローチでは、すべてのクライアント/サーバーを更新する必要があります。詳細については、Implementing long-running TCP connections within VPC networking を参照してください。この方法は優れた解決策ですが、すべてのクライアント/サーバー/アプリケーションを更新する必要があります。

推奨事項 3: アプリケーション内で TCP キープアライブを実装します。これにより、クライアント/サーバーが TCP キープアライブを送信して TCP セッションを維持できるようになります。このオプションでも、アプリケーションを変更する必要があります。

表 1 にこれらの推奨事項の概要を示します。

	必要な構成変更	作業量
推奨事項 1	GWLB タイムアウト値 > ファイアウォールのタイムアウト値に設定	低 GWLB のみ構成する必要あり。
推奨事項 2	クライアント/サーバーのタイムアウトを GWLB/ファイアウォールのタイムアウトより短く設定	高すべてのクライアントまたはサーバーを更新する必要あり
推奨事項 3	アプリケーション内で TCP キープアライブを設定	高すべてのアプリケーションを更新する必要があり

表 1 :推奨事項の概要

短期間のフローに関する推奨事項

アクティブなフローの総数は、GWLB の使用コストを決定する要素の 1 つです。TCP セッションが短期間で終了すると予想されるアプリケーションの場合、GWLB の TCP アイドルタイムアウト値を減らすことで、GWLB の使用量を最適化できます。このようなユースケースでは、GWLB の TCP アイドルタイムアウト値を予想されるセッション期間よりわずかに長い値に設定することをお勧めします。

このような要件は、一般的に、パトロールカー、救急車、軍用車両などのデバイスが、複数のセルラーネットワークやモバイルネットワーク事業者（MNOs）を使用して AWS にデータをストリーミングする場合に見られます。デバイスのセッションは、異なる MNOs 間を切り替えるたびに途切れ、アプリケーションコードが新しい TCP セッションを作成します。

留意事項

GWLB の既存のフローは、TCP アイドルタイムアウト値を変更しても影響を受けません。それらのフローのトラフィックは中断されずに続行されます。新しい TCP アイドルタイムアウトは、GWLB の新しいフローエントリにのみ適用されます。
TCP キープアライブは、GWLB の TCP アイドルタイムアウト値を更新します。
アイドルタイムアウト値は、IPv4 と IPv6 の両方に適用されます。
RejectedFlowCount_TCP メトリクスは、その値がゼロ以外の場合にのみ CloudWatch で利用可能になります。つまり、GWLB のフローテーブルがいっぱいになり、GWLB が TCP フローを拒否し始めた後にこのメトリクスを使用できるようになります。

結論

この投稿では、GWLB の TCP アイドルタイムアウト値を 60 秒から 6000 秒の範囲で設定できる新機能を紹介しました。コンソールと API を使用してこの機能を使用する方法を説明しました。さらに、長期間のフローと短期間のフローの両方に対するこの機能の使用に関するベストプラクティスと、環境に適した値を設定するために特定の CloudWatch メトリクスを監視する推奨事項についても説明しました。

この機能の詳細については、ドキュメントをご覧ください。

この記事の著者は Milind Kulkarni と Ankit Chadha です。

Amazon Web Services ブログ