Tailscaleをさらに高速化する

Tailscaleをさらに高速化する Kabir Sikand Kevin Purdy Alex Valiushko Claus Lensbøl Michael J. Fromberger Jordan Whited Tailscaleを少しでもフォローしている方なら、私たちがインターネット接続に強いこだわりを持つギークの集まりであることをご存知でしょう。私たちがよく話題にするものの一つにNATトラバーサルがあります。これはTailscaleのコアバリューの一つです。私たちはNATを克服しました。すべてのネットワークが友好的というわけではありませんが、Tailscaleは幅広い条件下で経路を見つけることができます。インターネットプロトコルにとって重要なのはそれだけではありません。データプレーンも高性能でなければなりません。 長年にわたり、私たちはTailscaleを高速化するために投資してきました。LinuxデバイスでのTCPスループットの向上から始めました。次に、wireguard-goで大きな進歩を遂げ、ベアメタルで10Gb/sを超えました。その後、セグメンテーションオフロードを活用して、UDPベースのアプリケーションのスループットを4倍以上に向上させました。これらのデータプレーンの改善と並行して、Tailscaleピアリレーのようなプリミティブを構築し、複雑な条件下でのネットワークパフォーマンスを向上させました。 これらすべてにより、Tailscaleはよりパフォーマンスが求められるワークロードにも実用的になりました。継続的インテグレーション、エージェント型ワークフロー、リモート開発環境、ロボットエッジデバイス、大量のデータおよびテレメトリワークロードなどでTailscaleを使用できるようになります。Tailscaleは、これらのデバイスが幅広いネットワーク条件下で接続できるように支援します。 ええ、Tailscaleは高速だと考えています。しかし、さらに高速化できるとも考えています。 本日、マルチキュー技術（2026年後半にリリース予定）を使用して、アプリコネクタ、サブネットルーター、および出口ノードのスループットを向上させている方法を詳しく説明します。また、今後の安定版クライアントリリースで展開するスループットとメモリオーバーヘッドの改善についてもプレビューします。さらに、お客様のために解決したいパフォーマンスツールに関する問題についても見ていきます。 小さなパケットのメモリオーバーヘッドの削減 ほとんどのネットワークパケットは1KiBのような非常に小さいものです。しかし、Linuxの最も効率的なスループットツールであるGeneric Receive Offload (GRO) を使用するには、Tailscaleは一度に64KiBのトラフィックを受け入れる準備ができている必要があります。これはコンテナ船輸送のようなものです。港、船、トラックは、どれだけ満載であっても、一つのコンテナの形状に合わせて作られています。 Tailscaleはそれらのコンテナを解凍する必要があります。各パケットは個別に復号化され、配信されます。Tailscaleの暗号化とネットワークの基本を支えるwireguard-goの実装は、解凍するための64KiBのバッファサイズを1つしか提供しません。そのため、1KiBのパケットは、毎回、独自の64KiBバッファにコピーされます。これは豊富な最適化ターゲットです。 LinuxとAndroidでは、Tailscaleはこれらのパケットが着陸した場所にそのまま残すようになりました。単一の大きな読み取り内で各パケットがどこから始まりどこで終わるかを特定するのではなく、どこか新しい場所にコピーします。小さなパケットはメモリ内では小さく保たれ、多くは1つのアロケーションを共有し、コピーされる時間が短くなります。これ自体で、多くのネットワーク構成で約5%の速度向上が見られました。 別途、パケットキューを短縮しました。これはパケットがパイプラインのステージ間を待つ列です。キューはトラフィックのバーストを吸収するために存在します。テストでは、その深さのほとんどが未使用であった一方、短いキューは待ち時間とメモリオーバーヘッドを削減しました。 解放されたメモリスペースを何に使うのでしょうか？私たちは、最も負荷の高いノードであるサブネットルーターとアプリコネクタにその節約分を渡しました。 サブネットルーター、アプリコネクタ、および出口ノードのためのマルチキュー サブネットルーターは、異なるtailnet間で完全に異なる場合があります。小規模なホームラボネットワークを実行している人にとって、サブネットルーターは少数の192.168.x.yの非Tailscaleデバイスを簡単に処理できます。クラウドデプロイメントのフロントに立つサブネットルーター、数百のピアを持つサブネットルーターは、実質的により多くのトラフィックを運びます。 最近まで、サブネットルーター、アプリコネクタ、および出口ノードは、複数の独立したストリームのパケットを、1つの順序付けられたシングルスレッドパイプラインで処理していました。これは、受信アプリケーションが自身のパケットを順序通りに受信しないようにする必要があるため、単一のレーンが多くの接続で共有されていたことを意味します。 メモリフットプリントを削減したことで、マルチキューシステムを実装する余裕ができました。1つのレーンではなく複数のレーンがあり、ピアの数ではなくマシンのリソースに合わせてスケーリングされます。各パケットストリームはレーンを取得し、そこに留まります。レーンは並列で実行され、作業をCPUコアに分散させることができます。 これにより、サブネットルーターとアプリコネクタの集約容量が増加し、パケットの受信から転送までの遅延が短縮されます。すでに所有しているハードウェアがより効率的に使用されます。アプリコネクタと出口ノードは、通常、短命の接続を持つ多くのユーザーにサービスを提供するため、特に顕著なブーストが得られます。 「これはレイテンシの低下、つまり、ワイヤからデータを読み取った瞬間からOSに送信する瞬間までのデータ処理の高速化につながります」と、TailscaleのテクニカルスタッフであるAlex Valiushko氏は述べています。 writevによるスループット向上 TailscaleクライアントでLinuxのwritev機能を利用することで、Tailscaleは複数のパケットデータ断片を1つの操作でLinuxカーネルに渡すことができます。カーネルに渡す前にそれらの断片をコピーして結合する必要がなくなります。writevのvは「ベクトル」を意味します。Tailscaleは、移動する必要のある個別のデータ断片を、それらを移動せずに記述できます。これは、メモリ内のパケットデータのコピーが少なくなり、書き込み操作が減り、スループットが高くなることを意味します。 netmapキャッシュによる高速起動 現時点では、これらの速度向上はLinux、および該当する場合はAndroidシステムでのみ利用可能です。しかし、他のシステムに適用される機能についても取り組んできました。Tailscaleクライアントはまもなくnetmapキャッシュを使用して、多くの条件下でより迅速に起動できるようになります。 Tailscaleに接続するマシンは通常、Tailscaleのコントロールプレーンに接続することから始まります。典型的なネットワークでは約100ミリ秒かかります。マシンは認証され、「ネットワークマップ」（netmap）を取得します。これは、到達可能なデバイスとその到達方法を記述したものです。この起動プロセスは高速であるべきです。おそらく瞬時であり、良好なネットワーク接続があれば、通常はそうです。 しかし、悪い飛行機のWi-Fi、積極的なフィルタリングのあるホテル、またはその他のあまり良くない接続設定の場合、マシンがコントロールプレーンに到達するのに時間がかかることがあります。そして、時にはまったく到達できないこともあります。問題がどこにあるのかはしばしば不明ですが、その結果、他のデバイスに到達できなくなります。 理想的なネットワーク条件下でも、100ミリ秒の起動レイテンシは、レイテンシに敏感な一部のワークロードには多すぎる場合があります。 Netmapキャッシュは、コントロールプレーンが迅速に到達できない場合にマシンが接続するのに役立ちます。有効にすると、tailnet上の各デバイスはnetmapのコピーをディスクに保存します。デバイスが起動すると、そのキャッシュされたコピーを使用してtailnet上の他のデバイスとの接続を確立できます。最新の情報を取得するためにコントロールプレーンに連絡できるようになるまでです。（これらの接続はデバイス間で直接ネゴシエートされ、Tailscaleは通常どおりトラフィックを一切表示しません）。 「ネットワーク状態が悪い場合、これは人々がnetmapキャッシュから多くのユーティリティを得られる領域です」と、テクニカルスタッフのClaus Lensbøl氏は述べています。「[デバイスクライアントは]、『ねえ、まだコントロールと話していないんだ。おそらくすぐにそこに着くだろう。それまでの間、まだ何かを始めることができるよ』と言います。」 いくつかの制限があります。キャッシュは、デバイスが少なくとも一度tailnetに接続してコントロールプレーンからネットワークマップを取得した場合にのみ機能します。さらに、netmapキャッシュは、キャッシュを保存するためにデバイスに永続的なディスクスペースが必要です。不要なディスク書き込みを最小限に抑えるように注意しましたが、場合によっては有効にしたくない場合があります。たとえば、例外的に大きなtailnetでは、キャッシュの更新に大量のディスクトラフィックが必要になる場合があります。同様に、SDカードのような遅いまたは摩耗に敏感なストレージを使用するデバイスは、netmapキャッシュを有効にしないことを好むかもしれません。 しかし、ほとんどのtailnet上のほとんどのデバイスにとって、この機能はデバイスが協調して動作を開始できる速度を著しく向上させることができます。