Amazon Web Services ブログ

カスタムロジックまたはアプライアンスを AWS Gateway Load Balancer と統合する

AWS Gateway Load Balancer (GWLB) は、2020 年 11 月より一般提供を開始しました。これは、ファイアウォール、侵入検知および防止システム、分析、可視性などのサードパーティの仮想ネットワークアプライアンスのデプロイ、スケーリング、管理を支援する新しいサービスです。Elastic Load Balancer ファミリーに新たに加わった AWS Gateway Load Balancer (GWLB) は、透過的なネットワークゲートウェイ (つまり、すべてのトラフィックの単一の入口と出口点) と、トラフィックを分散し、需要に応じて仮想アプライアンスをスケーリングするロードバランサーを組み合わせたものです。

これは大きなマイルストーンでした。なぜなら、AWS Gateway Load Balancer は、ネットワーク、セキュリティ、分析、通信、モノのインターネット（IoT）などのカスタムロジックやサードパーティ機能をあらゆるネットワークパスに差し込むための新しいフロンティアを切り開いたからです。この機能は、スケール、可用性、サービス提供、フローのスティッキーなどの問題を軽減するとともに、パートナーが中核となる専門知識に集中し、より迅速にイノベーションを起こせるようにします。

この記事では、仮想アプライアンスまたはカスタマイズされた機能を GWLB と統合する方法について詳しく説明します。「アプライアンス」という言葉は、新しいカスタムロジック、または既存の仮想アプライアンスを意味します。基礎に興味がある場合は、 GWLB ページまたは別のブログ投稿「GWLB がサポートするアーキテクチャパターン」を見てみるとい良いかもしれません。GWLB で公開したすべてのブログをご覧になりたい場合は、こちらのページをご確認ください。それでは、早速見ていきましょう。

どのような種類のネットワークアプライアンスが GWLB で動作しますか？

GWLB は各パケットをレイヤー 3 で処理し、アプライアンスの状態に依存しません。この動作により、アプライアンスが Geneve のカプセル化/カプセル化解除と GWLB メタデータをサポートしている限り、任意のカスタムロジック、またはサードパーティアプライアンスを GWLB の背後にあるフリートにデプロイできます。これについては後で詳しく説明します。

GWLB はどのように機能しますか?

下の図に示すように、GWLB は別の VPC のゲートウェイロードバランサーエンドポイント（GWLBE）に接続されています。GWLBE は VPC エンドポイント (VPCE) の一種です。1 つの GWLB を複数の GWLBE に接続できます。

GWLB には 2 つの側面があります。GWBLE に接続する側は、GWLB フロントエンドと呼ばれます。ターゲットアプライアンスに接続されている側は、GWLB バックエンドと呼ばれます。バックエンドでは、GWLB は、複数の同等のターゲットアプライアンスのうちの1つを介してトラフィックフローをルーティングするためのロードバランサーとして機能します。GWLB は、ターゲットアプライアンスへの両方向のフローのスティッキーを確保し、選択したアプライアンスに異常が発生した場合にフローを再ルーティングします。この記事は、バックエンド機能、特にGLWB とアプライアンス間の通信に焦点を当てています。

送信元から宛先に送信されるパケットには、宛先 IP アドレスとして GWLB IP が含まれていませんが、ルートテーブルの設定により GWLB にルーティングされます。透過的な転送動作を実現するため（つまり、元のパケットの内容をそのまま保持するため）、GWLB は Geneve カプセル化を使用して元のパケットをカプセル化し、アプライアンスに（/from）パケットを送信（/receives）します。また、アプライアンスは元のパケットを処理するために Geneve Type-Length-Value（TLV）ペアをカプセル化解除する必要があります。
※訳者注記：TLVはフォーマット表現の一種です。

GWLB はパケットイン/パケットアウトサービスです。アプリケーションの状態は保持されず、TLS/SSL復号化/暗号化も実行されません。これらの機能はアプライアンス自体によって実行されます。

GWLB で動作させるには、アプライアンスにどのような変更を加える必要がありますか？

GWLB と連携するためには、アプライアンスは以下の条件を満たす必要があります。

  • GWLB とトラフィックを交換するための Geneve プロトコルをサポートしている。Geneve のカプセル化は、GWLB とアプライアンス間のパケットの透過的なルーティングや、追加情報（後述のメタデータ）の送信に必要です。
  • GWLB 関連の Geneve Type-Length-Value (TLV) ペアのエンコード/デコードをサポートしている。
  • GWLB からの TCP/HTTP/HTTPS ヘルスチェックに応答する。

プロトタイプのアプライアンスの場合、ユーザーが上記のタスクを1日で完了するのに対し、高度なアプライアンスはさまざまな要因に応じて数日/数週間かかるのを見てきました。上記のタスクを完了すると、アプライアンスとGWLB の相互運用性をテストできます。テストとトラブルシューティングの概要は、この記事の後半で説明します。

アプライアンスが Geneve カプセル化をサポートする必要があるのはなぜですか？

元のパケットをそのまま保持する必要があることは、GWLB が提供する重要な機能である透過的な動作の基本的な要件です。元のパケットを新しいL3パケットにカプセル化することが、GWLB とアプライアンス間でパケットをルーティングするための唯一の実行可能なソリューションです。これは、このようなパケットの送信元/宛先 IP は GWLB またはアプライアンスの IP と同じではないため、これらの IP に基づく通常の VPC ルーティングでは、パケットが GWLB またはアプライアンスをバイパスしてしまうためです。

さらに、CIDR が重複するマルチテナントアプライアンスをサポートするには、アプライアンスがトラフィックのソースを知る必要があります。また、GWLB はフローを追跡し、ユーザートラフィックが混在しないようにする必要があります。GWLB は、パケットごとにType-Length-Value（TLV）トリプレットを使用して追加情報（GWLBE/VPCE ID、フロークッキー、添付ファイルIDなど）をアプライアンスに送信することでこれを実現できます。

Geneve プロトコル (RFC 8926) は柔軟性があり、この追加情報を渡すことができます。この拡張可能でカスタマイズ可能なレイヤ 3 カプセル化メカニズムにより、送信元デバイスと宛先デバイスを変更する必要がないため、幅広いユースケースをサポートし、カスタマーエクスペリエンスを簡素化できます。このドキュメントで後述する Geneve TLV 形式を参照してください。Geneve カプセル化の代替として、VXLAN と GRE が評価されましたが、フィールドのサイズが固定されているため、上記の要件を満たすことができませんでした。

GWLBはフローの送信先となるアプライアンスをどのように選択しますか？

GWLBは新しいTCP/UDPフローを受信すると、5タプルのフローハッシュ（送信元IP、宛先IP、転送プロトコル、送信元ポート、宛先ポート）を使用してターゲットグループから正常なアプライアンスを選択します。その後、GWLBはそのフローのすべてのパケット（順方向と逆方向の両方）を同じアプライアンスにルーティングします（スティッキ性）。TCP/UDP以外のフローでも、GWLBは引き続き3タプル（送信元IP、宛先IP、トランスポートプロトコル）を使用して転送を決定します。

GWLB はアプライアンスのヘルスチェックをどのように実行しますか?

GWLB は、ユーザーが定義した時間間隔に基づいて定期的にヘルスチェックを実行します。GWLB は、TCP/HTTP/HTTPSパケットをアプライアンスに送信することにより、これらのヘルスチェックを実行します。アプライアンスは、以下に説明するように TCP/HTTP/HTTPS パケットに応答する必要があります。

  • TCP : 接続の確立は成功とみなされます。
  • HTTP : GWLB は、ユーザーが指定したパスを使用して、新しい TCP 接続を介してアプライアンスに HTTP リクエストを送信します。アプライアンスは TCP 接続を確立し、200〜399 の範囲のステータスコードで応答する必要があります。TCP 接続の確立に失敗した場合、アプライアンスが他のステータスコードで応答した場合、またはアプライアンスが単に応答しない場合、ヘルスチェックは失敗します。
  • HTTPS : HTTP の動作と同じですが、TLS 経由です。GWLB は証明書のホスト名検証を行わないため、有効な証明書（有効期限が切れていない証明書または自己署名証明書）はすべて機能します。

アプライアンスは、GWLB のタイムアウト内にすべてのチェックを完了する必要があります。これらのチェックは、通常はコントロールプレーンからのTCP/HTTP/HTTPSパケットに正しく応答したアプライアンスが、データプレーンを介して宛先にパケットを転送することもできることを前提としています。ヘルスチェックパケットは Geneve カプセル化されていないことに注意してください。GWLB ヘルスチェックについては、このドキュメントを参照してください。

GWLB とアプライアンス間で、パケットはどのように流れますか?

次の図は、送信元 (IP アドレス A.B.C.D) から宛先 (IP アドレス E.F.G.H) に移動するときのパケットのフローを示しています。送信元からのパケットは、ルートテーブルのネクストホップを使用して GWLBE に送信されます。

ステップ1：GWLBE は送信元からパケットを受信すると、基盤となる PrivateLink 技術を使用してパケットを GWLB に送信します。パケットは AWS ネットワーク上にとどまり、GWLB に到達します。

ステップ 2: GWLB は、受信パケットの 5 タプル (Src IP、Dest IP、Src ポート、Dest ポート、プロトコル) を使用して、特定のアプライアンスをターゲットとして選択します。さらに、GWLB はフロークッキーを生成します (ステップ 4 で説明)。次に、GWLB はフローエントリとそれに対応するフロー Cookie をフローテーブルに保存します。次に、GWLB は Geneve ヘッダーを使用して元のパケット（黄色で表示）をカプセル化し、Type、Length、Valueのトリプレット（TLVとも呼ばれる / 緑色で表示）の形式でメタデータを埋め込みます。TLV はステップ 4 で説明されています。この例では、GWLB の IP アドレスは 10.1.4.10 で、アプライアンスの IP アドレスは 10.1.2.5 です。

ステップ 3: GWLB はカプセル化されたパケットを特定のアプライアンスに転送します。GWLB は、そのフローが存続している間、その 5 タプルフローを両方向のトラフィックの特定のアプライアンスに固定します。

ステップ 4: アプライアンスは、UDP/IP パケットを受け入れることができる IP インターフェースで構成する必要があります。アプライアンスに転送されるすべてのパケットは、その IP インターフェイスで転送されます。

アプライアンスは、TLV 内の情報を解析して意思決定に使用する必要があります。パケットには、次の Geneve TLV が 1 つ以上含まれます。

  • GWLBE/VPCE ID : これは、GWLBE に割り当てられた 64 ビットの ID です。GWLBE は VPC エンドポイントの一種なので、GWLBE ID は VPCE ID と同じです。たとえば、アプライアンスはこの識別子を使用してパケットを設定に関連付けることができます。この GWLBE/VPCE ID は、トラフィックのソース VPC を決定するために使用できます。各 GWLBE は 1 つの VPC にのみ属することができます。GWLBE から VPC へのマッピングをアプライアンスに提供するのは、アプライアンスパートナーの管理ソフトウェアです。
  • フロークッキー:フロークッキーは、GWLB が最初にフローテーブルにフローエントリを作成したときにフロー用に生成される 32 ビットの乱数です。フロークッキーはフローごとに固有であり、パケットの内容から生成されるものではありません。アプライアンスはこの Cookie を「現状のまま」返さなければなりません。GWLB がアプライアンスからパケットを受信すると、アプライアンスから受信したパケットのクッキーがそのフローに割り当てられたクッキーと一致する場合にのみ、パケットはさらに転送されます。Cookie が一致しない場合、または Cookie がない場合、パケットはドロップされます。
  • [未来使用予定] アタッチメント ID：GWLB が TGW、VPNGW、または Direct Connect に直接接続する場合、64 ビットのアタッチメント ID TLV がアプライアンスに送信され、送信元の VPC ID が決定されます。これはオプションの TLV で、別の AWS ゲートウェイデバイスに接続されている場合にのみ表示されます。これは将来の TLV であり、現在は存在しません。

TLV を処理した後、アプライアンスはパケットをドロップするか、転送を許可するかを選択できます。
アプライアンスがパケットを転送する場合、次のことを行う必要があります。

  • 元のパケットを Geneve ヘッダー内にカプセル化します
  • 外部 IPv4 ヘッダーの送信元 IP アドレスと宛先 IP アドレスを交換します（送信元 IP = アプライアンス IP アドレス、宛先 IP = GWLB IP アドレス)
  • 元のポートを保持し、外部 IPv4 ヘッダーの送信元ポートと宛先ポートを交換してはなりません
  • 外側の IPv4 ヘッダーの IP チェックサムを更新します
  • 元の内部パケットの指定された 5 タプルの TLV をそのままにして、パケットを GWLB に返します

ステップ 5 : アプライアンスは Geneve ヘッダーを使用して元のパケット（黄色で表示）をカプセル化し、そのフローで最初に受信したのと同じメタデータ（緑色で表示）を埋め込みます。

ステップ 6 : アプライアンスからパケットを受信すると、GWLB は Geneve カプセル化を削除します。次に、GWLBは、着信（内部）パケットの5タプルとフロークッキーを、ステップ 2 で以前に保存したフローエントリとフロークッキーの組み合わせと比較することにより、着信パケットを検証します。着信パケットの 5 タプルとフロークッキーが GWLB キャッシュ内の対応するエントリと一致する場合のみ、GWLB はパケットを GWLBE に転送します。GWLB は、キャッシュに一致するものがない場合、または着信パケットの 5 タプルまたはフロークッキーが変更された場合、着信パケットをサイレントにドロップします。

ステップ 7 : パケットは、基盤となる PrivateLink 技術を使用して GWLBE に転送されます。パケットは AWS ネットワークに留まり、GWLBE に到達します。GWLBE は、ルートテーブルのネクストホップを使用して宛先にパケットを配信します。

GWLB とアプライアンスが交換するパケット形式はどのようなものですか？

以下のパケット形式は、Geneve カプセル化を使用してアプライアンスで受信したパケットを示しています。Geneve ヘッダーの説明については、Geneve プロトコル (RFC 8926) を参照してください。

Outer IPv4 Header:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |Protocol=17 UDP|         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Outer Source IPv4 Address                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Outer Destination IPv4 Address              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Source Port = xxxx      |    Dest Port = 6081 Geneve    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          UDP length           |         UDP Checksum          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outer Geneve Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|Opt Len = 8|O|C|    Rsvd.  | EtherType = 0x0800 or 0x86DD  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Virtual Network Identifier (VNI) = 0       |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outer Geneve Options: AWS Gateway Load Balancer TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Option Class = 0x0108 (AWS)|    Type = 1   |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      64-bit GWLBE/VPCE ID                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Option Class = 0x0108 (AWS)|    Type = 2   |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|              64-bit Customer Visible Attachment ID            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Option Class = 0x0108 (AWS)|    Type = 3   |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     32-bit Flow Cookie                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Customer payload follows…
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 
|   Customer payload identified by EtherType in Geneve header   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

アプライアンス統合のテストとデバッグのプロセスはどのようなものですか?

アプライアンスソフトウェアが Geneve プロトコル、GWLB TLV のエンコード/デコードをサポートし、ヘルスチェックに応答したら、テストを行います。

VPC と必要なコンポーネントを作成します。GWLB、GWLBE、およびターゲットグループにアプライアンスを追加します。最も単純なテストケースとして、単一のアプライアンスから始めることができます。アプライアンスがヘルスチェックに応答しているかどうかを確認します。アプライアンスのパケットキャプチャをオンにすると、パケットフローを確認できます。パケットが前のセクションで示した想定どおりの形式であることを確認します。ヘルスチェックが機能しているときは、アプライアンス VPC の GWLB サブネットで VPC フローログを有効にします。GWLB エンドポイントサブネットのカスタマー VPC で VPC フローログを有効にできます。フローログを使用して、各方向からの送受信パケットを確認します。

まとめ

私たちの目標は、お客様とパートナーが Gateway Load Balancer をあらゆるネットワークパスに簡単に追加する方法として使用できるようにすることです。スケール、可用性、サービス提供、フローのスティッキーといった問題を AWS に任せていただければ、コアとなる専門知識に集中してイノベーションを加速できます。セキュリティ、分析、テレコム、モノのインターネット (IoT) のユースケースや、まったく新しいアプリケーションの可能性を切り開くことを期待しています。

この投稿では、仮想アプライアンスまたはカスタマイズされた機能を GWLB と統合する方法に焦点を当てています。何ができるかについて読者の皆様の想像力を刺激できていましたら幸いです。

詳細を知りたい場合は、次のリンクをご活用ください。

著者について

picture of Milind Kulkarni

Milind Kulkarni

Milind は、アマゾン ウェブ サービス (AWS) のシニアプロダクトマネージャーです。ネットワーキング、データセンター アーキテクチャ、SDN/NFV、クラウド コンピューティングの分野で 20 年以上の経験があります。彼は 9 つの米国特許の共同発明者であり、3 つの IETF 標準を共同執筆しています。

この記事の翻訳はソリューションアーキテクトの長屋が担当しました。原文はこちらです。