P4 が NAT64 と出会うと、UCloud はどのようにして IPv4 から IPv6 に迅速に進化するのでしょうか?

IPv4 には、アドレス枯渇、セキュリティやサービス品質の確保の難しさ、経路拡張など、現時点では多くの欠陥があります。これらの問題は、クラウド コンピューティングやその他の関連 IT 産業の発展を大きく制限することになります。 IPv6 は、より広いアドレス空間とより高いセキュリティを備えており、IPv4 のこれらの欠陥を効果的に解決できます。

UCloud は、2018 年上半期にパブリック ネットワーク エントランスの IPv6 変換の開発を開始しました。NAT64 テクノロジーとプログラム可能な P4 スイッチを活用して、無料の UCloud パブリック ネットワーク エントランス IPv6 変換サービスを正常に開始しました。製品はシンプルで使いやすいです。 EIPを申請後、ワンクリックでIPv6変換を開始できます。変更を加えることなく、外部に IPv6 アクセスを提供できます。現在、UCloud IPv6 変換サービスは、クラウド ホスト、EIP、負荷分散、コンテナ クラスター、要塞ホストなどの製品で使用されています。リージョン内の単一のクラスター (16 台の NAT64 サーバー、4 台の P4 スイッチ) は、最大 3.2M CPS および 1.6G の同時接続を実現でき、将来の進化に合わせてスムーズに拡張できます。

UCloud IPv6 進化の戦略的ステップ UCloud は数年前から IPv6 テクノロジーの予備調査と研究を開始しており、すでに社内に完全な IPv6 予備調査計画を策定しています。しかし、ネットワーク インフラストラクチャの変革は一夜にして達成できるものではないことを明確に認識する必要があります。それは技術的な困難を克服することだけでなく、それ自体が大きなエンジニアリング上の問題でもあります。

そして最も重要なことは、ユーザーの既存ビジネスに影響を与えることなく、段階的に IPv6 に移行していくことです。この考慮に基づいて、UCloud は IPv4 から IPv6 への進化に向けて次の戦略を策定しました。

1. 2018年にインターネットポータルのIPv6変換サービスを完了し、UCloud製品の50%以上がIPv6をサポートできるようになります。お客様は、業務を変更することなく、EIP で IPv6 変換サービスを有効にするだけで、企業が外部に IPv6 アクセス サービスを提供できるようになり、企業と IPv6 ネットワーク間のスムーズなドッキングが実現します。

2. 2018年に管理ネットワークのIPv6化を完了し、ホスト侵入検知やコンテナイメージライブラリなどの管理ネットワークに基づくクラウド製品がIPv6をサポートするようにします。

3. UCloud の主要製品は 2019 年に IPv6 をサポートする予定です。その中でも、VPC や ULB (UCloud ロード バランシング) などの重要な製品は 2019 年第 2 四半期までに IPv6 をサポートし、IPv6 ネットワークに積極的にアクセスできるようになります。

4. 2019 年に IDC デュアルスタック変換を完了し、データセンターが IPv6 をサポートし、完全な IPv6 サポートを提供できるようにします。

IPv6 の技術から実装までのプロセスにおいて、UCloud は多くの作業を行い、多くの課題にも遭遇しました。この記事では、技術的な観点から、UCloud IPv6 変換サービスの実装と最適化された進化について詳しく紹介します。

UCloud IPv6 変換サービス

◆ NAT64とその技術的課題

実装技術の面では、UCloud はステートフル NAT64 技術を使用して IPv6 変換サービスを実装します。 NAT64 は、ネットワーク アドレス変換 (NAT) を通じて IPv6 ホストと IPv4 ホスト間の通信を容易にする IPv6 変換メカニズムです。 NAT64 ゲートウェイでは、IPv4 プロトコルと IPv6 プロトコル間の変換を完了するために、少なくとも 1 つの IPv4 アドレスと、32 ビットのアドレス空間を含む IPv6 ネットワーク セグメントが必要です。

NAT64 は、この 32 ビット IPv4 アドレスに埋め込まれた IPv6 宛先アドレスを宛先 IPv4 アドレスに変換し、送信元 IPv6 アドレスを特定の送信元 IPv4 アドレスに変換します。 NAT64 ゲートウェイは、手動で構成することも、自動的に決定することもできる IPv6 アドレスと IPv4 アドレス間のマッピングを作成します。

下図に示すように、UCloud の IPv6 変換機能は NAT64 に基づいて実装されており、ユーザーの既存の IPv4 EIP に対して IPv6 アドレスを生成することができます。既存の IPv4 ネットワークと対応するサービスを変更することなく、対応するクラウド リソースとサービスにパブリック IPv6 ネットワークからアクセスでき、ユーザーのクラウド リソースとサービスに IPv4 と IPv6 の両方から同時にアクセスできるようになります。

IPv6 と IPv4 間の変換はステートフル変換です。システム全体の安定性と拡張性の要件を考慮すると、IPv6 変換サービスの実装には主に 2 つの技術的なポイントがあります。

• 高可用性。 IPv6 変換サービスはステートフル サービスであるため、クラスター内のノードが変更されても既存の接続が影響を受けないようにする必要があります (正確には、影響は 1/n 以下です。n はバックエンド ノードの数を表します)。
• セキュリティ保護: IPv6 変換サービスはステートフル サービスであるため、悪意のある攻撃 (DDoS など) に遭遇すると、サーバーがクラッシュしてサービスが利用できなくなる可能性があります。したがって、特定の DDoS 保護機能はシステム全体にとって非常に重要です。

◆ システムアーキテクチャ

上記の要点を踏まえ、次の図に示すように、IPv6 変換機能を実装するために、NAT64 と P4 スイッチに基づくシステム アーキテクチャの設計を開始しました。 NAT64 アクセスは P4 スイッチを使用して実装され、NAT64 アクセスの一貫したハッシュによって高可用性が実現されます。同時に、DDoS 保護を実現するために、NAT64 アクセスでは CPS の速度が制限されます。

NAT64 アクセスと物理スイッチ 1 は 3 層ネットワークを形成し、リージョンの IPv6 プレフィックスとして BGP を介して物理スイッチ 1 に /96 IPv6 アドレス セグメントを通知します。 POP1 と POP2 のアクセスによって外部に通知されるアドレス セグメントは同じであるため、負荷分散と POP レベルの災害復旧が実現します。同様に、POP ポイント内の 2 つのアクセス ポイント間でも負荷分散と災害復旧が実装されます。

アクセス、物理スイッチ 2、および NAT64 サーバーはレイヤー 2 ネットワークを形成します。 NAT64 サーバーは北方向の BGP 経由で VIP を Access に通知し、Access は VIP に対応するネクストホップ情報 (MAC アドレス) を取得できます。インターネットからの着信 IPv6 メッセージを受信すると、メッセージの MAC アドレスが特定の NAT64 サーバーの MAC アドレスに設定され、メッセージが特定の NAT64 サーバーに配信されるようになります。同時に、NAT64 サーバーは、戻り到達可能性を実現するために、南方向の物理スイッチ 4 への送信元アドレス プールを宣言する必要があります。

実際の展開では、物理スイッチ 2 と 1 は通常一緒に展開され、並列方式で NAT64 アクセスを形成することに注意してください。以下では、クラウド ホストを例に、ビジネス プロセスを通じてシステム全体の動作メカニズムを簡単に説明します。

• ビジネスプロセス

各 NAT64 サーバーは重複しない送信元アドレス プール (IPv4_1 は NAT64 送信元アドレス プール内のアドレス、IPv4_2 は EIP に対応) で構成されており、アドレス プールがサウスバウンドにアナウンスされているため、クラウド ホストの応答メッセージ (宛先アドレスは送信元アドレス プール内のアドレス、つまり IPv4_1) はルーティングを通じて対応する NAT64 サーバーに到達できます。

◆ P4がNAT64と出会うとき

NAT64アクセスは高可用性をサポートします

上記のシステム アーキテクチャから、物理スイッチを使用して POP レベルで負荷分散と災害復旧を実現できることがわかります。ただし、システムの高可用性を実現するための鍵は、NAT64 サービス ノードのステータスが変化する場合 (拡張やノードのダウンなど)、システムが既存の接続が破壊されないようにする必要があることです。これには、バックエンド ノードを選択するときに一貫したハッシュをサポートするために NAT64 アクセスが必要です。したがって、NAT64 アクセスの最も重要な属性は、本質的に一貫性のあるハッシュ ゲートウェイです。

主要なクラウド コンピューティング ベンダーの間では、DPDK が現在、一貫性のあるハッシュ ゲートウェイの主流の実装ソリューションとなっています。ただし、DPDK には次のような欠陥もあります。

• DPDK ベースのアプリケーションは非常に高いパケット転送速度を実現できますが、これはマルチサーバー、マルチコアの負荷分散によって実現されます。さらに、負荷分散アルゴリズムは通常、ハードウェア スイッチまたはネットワーク カードによって実装され、ソフトウェアでは定義できません。ネットワークに単一のエレファントフローが発生し、ハードウェアスイッチまたはネットワークカードの負荷分散アルゴリズムによって適切に分散できない場合、単一のネットワークケーブルまたは単一の CPU コアで輻輳が発生し、ビジネスに大きな影響を与えます。
• ネットワーク帯域幅が 10G から 25G、40G、50G、100G へと進化するにつれて、DPDK では回線速度に到達するためにさらに強力な CPU が必要になりますが、より強力な CPU は通常高価であり、コスト効率が良くありません。特に、シングルコアの主周波数が高くなるほど価格も高くなり、主周波数の上昇と価格の上昇には非線形の関係があります。

そのため、最終的に、NAT64 アクセスを実装するために P4 プログラマブル スイッチ (Barefoot Tofino チップに基づく) を使用することを決定しました。実際、UCloud は 2017 年から P4 プログラマブル スイッチの事前研究を開始しており、現在では P4 プログラマブル スイッチをベースにした GW がグレースケールで発売されています。 DPDK ゲートウェイと比較して、P4 プログラマブル スイッチには多くの利点があります。

1. DPDKと比較して、より高い転送性能（1.8T〜6.4T）を備えています。

2. 転送性能は安定しており、CPU負荷などの影響を受けません。

3. シングルライン 100G はシングルラインの混雑を回避できます。

4. P4 言語はオープンであり、強力なプログラミング性を備えています。

5. 非常に優れたエコシステムで、P4 ランタイムをサポートします。

磁気浮上ハッシュ

磁気浮上アルゴリズムの選択と検証

一貫性ハッシュアルゴリズムを選択する際には、Google Maglev プロジェクトで使用されているハッシュアルゴリズム (以下、Maglev Hash と呼びます) を選択しました。このアルゴリズムの主な利点は、バックエンド サービス ノードが変更されても極めて安定していることです。また、ルックアップ テーブルのサイズは変更されないため、P4 スイッチがルックアップ テーブルを運ぶのに非常に適しています。 (原著論文: Maglev: 高速で信頼性の高いソフトウェア ネットワーク ロード バランサー)

論文で紹介されているコンシステント ハッシュ法によれば、Maglev ハッシュ アルゴリズムは基本的に、各バックエンドが特定のルールに従って配列ルックアップ テーブルの空のエントリを埋めるように設計されており、構築されたルックアップ テーブルの要素にすべてのバックエンド サーバーが出現する回数が可能な限り均等になるようにします (実際、アルゴリズムによれば、出現回数が最も多いノードと出現回数が最も少ないノードの最大差は 1 です)。これにより、最終的な平均パフォーマンスを実現できます。

Maglev ハッシュ アルゴリズムによって生成されたルックアップ テーブルのパフォーマンスは極めて平均的ですが、バックエンド サービス ノードが変更されると、一部の接続が中断されるという欠陥もあります (理想的な一貫性ハッシュ アルゴリズムの接続中断率は 1/N ですが、Maglev ハッシュでは 1/N の比率がわずかに高くなる場合があります)。

Maglev プロジェクトでは、この欠陥を補うために接続トラック テーブルが使用されます。ただし、Connection Track には一連の欠点があり、NAT64 アクセスがステートフルになり、攻撃に対して脆弱になります。論文によれば、ルックアップ テーブルのサイズがバックエンド ノードの 100 倍になると、接続中断率は 2% 未満になることがわかります。しかし、2％はまだ比較的高い比率です。私たちは厳格な姿勢で、拡張と縮小のシナリオにおけるルックアップ テーブルのサイズとバックエンド ノードの比率に関する一連のテストと検証を実施しました (縮小は NAT64 サーバーのダウンタイムにも対応します)。

上の図は、バックエンドノードがそれぞれ増加した場合と減少した場合に対応しています。上記のテストから、ルックアップ テーブルのサイズが小さい場合、アルゴリズムの安定性がわずかに低下することがわかります。上記のテストを例にとると、ルックアップ テーブルのサイズが 1024 の場合、拡張および縮小のシナリオでは、接続の約 2% が影響を受けます (具体的にはエントリの変更として現れます)。これは基本的に Maglev の論文の結論と一致しています。

ただし、ルックアップ テーブルのサイズが大きくなるにつれて、既存の接続への影響は小さくなり、最終的には 1/n に近づきます。具体的には、上図 2 に示すように、ルックアップ テーブルのサイズがバックエンド サービス ノードのサイズの 2000 倍を超えると、接続中断の割合は 0.01% 未満になります。ただし、接続追跡がないため、NAT64 アクセス全体がステートレスになり、NAT64 アクセスの安定性が大幅に向上し、実装の複雑さが大幅に軽減されます。

NAT64 アクセスの仕組み

NAT64 アクセスは、次の形式のルックアップ テーブルを持ちます。

ここでのルックアップ テーブルは、実際には Maglev 内の複数のルックアップ テーブルで構成されており、VIP によって区別されることに注意してください。

具体的な動作メカニズムは次のとおりです。

異なる NAT64 クラスターは、BGP を介して NAT64 アクセスに異なる VIP を通知します。 NAT64 マネージャは、GRPC を介して NAT64 アクセスのルーティング テーブル情報とネイバー テーブル情報を取得し、各 VIP の情報と対応するネクスト ホップ MAC アドレスを取得します。次に、すべての VIP をトラバースし、各 VIP のネクストホップ情報に従って Maglev Hash Engine を呼び出して、各クラスターに対応するエントリ リストを生成します (特定の値は各 NAT64 の MAC アドレスです)。すべてのエントリ リストと VIP が上記のルックアップ テーブルを構成します。

データ プレーンはメッセージを受信すると、EIP (別のテーブルとコントロール プレーンの対応するロジックを通じて実装されますが、ここでは詳しく説明しません) に基づいて VIP を照会し、P4 言語のハッシュ関数を呼び出して、データ パケットの送信元 IP、宛先 IP、送信元ポート、宛先ポートに基づいてエントリ インデックスを計算します。最後に、ルックアップ テーブルは VIP とエントリ インデックスに従って照合され、宛先 MAC が設定されます。この時点で、バックエンド サービス ノードの選択は完了です。

NAT64 マネージャーは、NAT64 アクセスのルーティング テーブルとネイバー テーブルを継続的に監視します。 VIP の次のホップが変更されると (容量拡張や NAT64 ダウンなど)、Maglev Hash Engine が再度呼び出され、VIP に対応するルックアップ テーブル内のエントリの対応する部分が再生成され、GRPC を通じて対応するエントリが変更され、ノードが変更されたときに迅速な応答が実現されます。

NAT64 アクセス DDoS セキュリティ保護

IPv6 変換サービス自体はステートフルであるため、DDoS 攻撃を受ける可能性があります。したがって、NAT64 アクセスの各 EIP の TCP SYN パケットに対して、受信および送信 PPS レート制限を設定します。 UCloud はパブリック ネットワーク アクセスにおいて強力なセキュリティ保護と DDoS 検出およびクリーニング機能を備えているため、NAT64 アクセスで実行される SYN メッセージのレート制限は補足的かつ二次的な保護としてのみ使用されます。ただし、その利点は、検出や分析なしで直接速度を制限できるため、極端な攻撃シナリオで NAT64 サービスが利用できなくなる時間を短縮できることです (セキュリティ センターの完全な DDoS 保護には通常、検出や分析などの手順があり、ある程度の遅延があります)。

現在、単一の EIP の SYN パケット レートは 50,000 に制限されています。 50,000 を超えるとパケットはドロップされます。このパラメータは調整可能です。ユーザーがビジネスレベルで非常に大きな CPS を要求している場合、UCloud の関連技術サポート担当者が調整の支援も行います。

P4テーブル構成の最適化

Tofino チップには 4 つのパイプラインが含まれており、各パイプラインには 12 のステージが含まれています。現在の主流のシナリオは、すべてのパイプラインが同じテーブル構成、つまり同じ P4 コードを使用することです。ただし、2 つのテーブルが相互に依存すると、同じステージに配置することはできません。これは、基盤となるチップの実行ロジックによって決まります。

ビジネス ロジックの複雑さを考慮すると、通常、データ プレーンではビジネス ロジック全体を完了するために多くのテーブルを定義する必要があり、これらのテーブルは相互に大きく依存しています。そのため、実際のエンコード処理ではステージが使い尽くされますが、各ステージのリソース使用率は非常に低くなります。特に私たちのプロジェクトでは、リソース使用率が低いため、NAT64 アクセスがサポートできる EIP の数が限られます。この問題には通常、3 つの解決策があります。

• テーブル構成を最適化したり、特定のビジネス ロジックを変更してテーブル間の相互依存性を減らしたりすることで、ステージ リソースの使用率を大幅に向上させることができます。
• 入力と出力は同じステージを共有しますが、ハードウェア レベルでは入力テーブルと出力テーブルの間に依存関係はありません。したがって、ビジネス ロジックは分割され、1 つの部分は入力に配置され、他の部分は出力に配置されます。このソリューションは比較的シンプルで実装が簡単で、通常は明らかな結果が得られます。
• パイプラインのシリアル化によりビジネス ロジックが分割され、各パイプラインはビジネス ロジックの一部を配置し、異なるパイプラインはカスタム メタデータを通じて情報を送信します。このソリューションも効果的なソリューションであり、Tofino の全体的なテーブル スペースを改善できます。将来的にはこのようなアプリケーションが多数登場することが予想されます。

NAT64 プロジェクトでは、ソリューション 1 と 2 を組み合わせて採用しました。最適化後、リソース使用率は約 70% に達しました (最適化前は約 30% でした)。次の図は、最適化後の Tofino チップのリソース使用率とテーブル占有率の図を示しています。

システムパフォーマンステスト

システム構築後、単一の NAT64 サーバー (NAT64 サーバーの構成は、CPU: 32 コア、メモリ: 64GB、ネットワーク カード: X710 10Gb * 2) で完全なパフォーマンス テストを実施しました。クライアントは IPv6、サーバーは双方向 UDP データ フロー、1 つの応答と 1 つの回答を備えた IPv4 でした。クライアントはサーバーにリクエストを送信し、サーバーはクライアントに応答を返します。最も重要な CPS と同時接続のテスト結果は次のとおりです。

• CPS テスト結果:

• 同時接続テストの結果:

当社は当初、1 セットに 16 台の NAT64 サーバーを導入したため、1 つのリージョンで最大 320 万 CPS と 160 万の同時接続を実現できます。さらに、システム全体でスムーズかつシームレスな拡張をサポートし、NAT64 アクセスおよび NAT64 サーバーの任意の追加をサポートします。

現在、UCloud IPv6 変換サービスは無料のパブリックベータ段階にあり、ぜひご利用ください。