Tailscaleをさらに高速化する

Tailscaleをより高速にする

Tailscaleを少しでもフォローしている方なら、私たちがインターネット接続に強いこだわりを持つギーク集団であることをご存知でしょう。私たちがよく話題にするものの一つにNATトラバーサルがあります。それがTailscaleのコアバリューの一つです。NATを克服したのです。すべてのネットワークが友好的というわけではありませんが、Tailscaleは幅広い条件下で経路を見つけることができます。インターネットプロトコルにとって重要なのはそれだけではありません。データプレーンも高性能でなければなりません。

長年にわたり、私たちはTailscaleを高速化するために投資してきました。まず、LinuxデバイスでのTCPスループットの向上から始めました。次に、wireguard-goで大きなブレークスルーを達成し、ベアメタル上で10Gb/sを超える性能を実現しました。その後、セグメンテーションオフロードを活用して、UDPベースのアプリケーションのスループットを4倍以上に向上させました。これらのデータプレーンの改善と並行して、Tailscale Peer Relaysのようなプリミティブを構築し、困難な条件下でのネットワークパフォーマンスを向上させました。

これらのすべてにより、Tailscaleはよりパフォーマンスが要求されるワークロードにも実用的になりました。継続的インテグレーション、エージェント型ワークフロー、リモート開発環境、ロボットエッジデバイス、大量のデータおよびテレメトリワークロードなどでTailscaleを使用できるようになります。Tailscaleは、これらのデバイスが幅広いネットワーク条件下で接続できるように支援します。

そう、私たちはTailscaleが高速だと考えています。しかし、さらに高速化できるとも考えています。

本日、私たちはマルチキュー技術（2026年後半にリリース予定）を使用して、アプリコネクタ、サブネットルーター、出口ノードのスループットを向上させる方法を詳しく説明します。また、今後の安定版クライアントリリースで展開するスループットとメモリオーバーヘッドの改善についてもプレビューします。そして、お客様のために解決したいパフォーマンスツールの問題についても見ていきます。

小さなパケットのためのメモリオーバーヘッドの削減

ほとんどのネットワークパケットは、1 KiBのような小さなサイズです。しかし、Linuxの最も効率的なスループットツールであるGeneric Receive Offload (GRO) を使用するために、Tailscaleは一度に64 KiBのトラフィックを受け入れる準備をしておく必要があります。これはコンテナ船に似ています。港、船、トラックは、コンテナの満杯度に関わらず、一つのコンテナ形状に合わせて作られています。

Tailscaleはそのコンテナを開封する必要があります。各パケットは復号化され、個別に配信されます。Tailscaleの暗号化とネットワークの基本を担うwireguard-goの実装では、展開用のバッファサイズは64 KiBのものが1つしか提供されません。そのため、1 KiBのパケットは、毎回独自の64 KiBバッファにコピーされます。これは豊富な最適化ターゲットです。

LinuxとAndroidでは、Tailscaleはこれらのパケットが着地した場所にそのまま配置するようになりました。新しい場所にコピーするのではなく、単一の大きな読み取りバッファ内で各パケットの開始位置と終了位置を識別します。小さなパケットはメモリ内で小さく保たれ、多くは1つの割り当てを共有し、コピーにかかる時間が短縮されます。これだけでも、多くのネットワーク構成で約5%の速度向上が見られました。

［画像: パケットバッファ割り当ての最適化前後の比較図。最適化前：3つのパケットがそれぞれ未使用スペースのある個別の64 KiBバッファにコピーされている。最適化後：宛先用にサイズ設定されタグ付けされた3つのパケットが、区切り線付きの単一バッファに統合されている。］

別途、パケットがパイプラインのステージ間を待機するキューを短縮しました。キューはトラフィックのバーストを吸収するために存在します。テストでは、その深さのほとんどが未使用であることが示され、短いキューは待機時間の短縮とメモリオーバーヘッドの削減を意味しました。

解放されたメモリスペースを何に使うのか？最も負荷の高いノードであるサブネットルーターとアプリコネクタにその節約分を還元しました。

サブネットルーター、アプリコネクタ、出口ノードのためのマルチキュー

サブネットルーターは、tailnetごとに全く異なる場合があります。小規模なホームラボネットワークを実行している人にとって、サブネットルーターは少数の192.168.x.yのような非Tailscaleデバイスを簡単に処理できます。数百のピアを持つクラウドデプロイメントの前面にあるサブネットルーターは、実質的に大量のトラフィックを処理します。

最近まで、サブネットルーター、アプリコネクタ、出口ノードは、複数の独立したストリームのパケットを、単一の順序付けられたシングルスレッドパイプラインで処理していました。これは、受信アプリケーションが自身のパケットを順序通りに受信することを決して保証してはならないため、多くの接続で単一のレーンが共有されていたことを意味します。

メモリフットプリントを削減したことで、マルチキューシステムを実装する余裕ができました。これは、ピアの数ではなくマシンのリソースに合わせてスケーリングされた、単一のレーンではなく複数のレーンです。各パケットストリームはレーンを取得し、そこに留まります。レーンは並列に実行され、作業をCPUコアに分散させることができます。

［画像: シングルパイプラインとマルチキュー処理アーキテクチャの比較図。前：パケットは1つのReaderから4つのCryptoステージを経てWriterからDevicesへ流れる。後：パケットは4つの並列Reader-Crypto-Writerパイプラインに分散されDevicesへ流れる。］

これにより、サブネットルーターとアプリコネクタのパケット受信から転送までの遅延が減少し、全体のスループットが向上します。既存のハードウェアがより効率的に使用されます。特に、多くのユーザーが短命な接続を持つアプリコネクタと出口ノードは、顕著なブーストを得られます。

「これはレイテンシの低下、つまりデータをワイヤーから読み取ってからOSに送信するまでの処理速度の向上につながります」と、TailscaleのテクニカルスタッフであるAlex Valiushko氏は述べています。

writevによるスループット向上

TailscaleクライアントのLinuxのwritev機能を活用することで、Tailscaleは複数のパケットデータ断片を、それらをコピーして結合してからカーネルに渡すのではなく、単一の操作でLinuxカーネルに渡すことができます。writevのvは「vector」（ベクトル）を表します。Tailscaleは、移動する必要のある個別のデータ断片を、移動せずに記述できます。これは、メモリ内のパケットデータのコピー回数の削減、書き込み操作の削減、そしてスループットの向上を意味します。

netmapキャッシュによる高速起動

現時点では、これらの速度向上はLinuxおよび、該当する場合はAndroidシステムでのみ利用可能です。しかし、他のシステムにも適用できる機能についても取り組んできました。Tailscaleクライアントは間もなく、多くの条件下でより高速に起動するためにnetmapキャッシュを使用できるようになります。

Tailscaleに接続するマシンは通常、約100ミリ秒でTailscaleのコントロールプレーンに接続することから始まります。マシンは認証され、「ネットワークマップ」（netmap）を取得します。これは、到達可能なデバイスとその到達方法を記述したものです。この起動プロセスは高速、おそらく瞬時に感じられるべきであり、良好なネットワーク接続があれば通常はそうなります。

しかし、悪い飛行機のWi-Fi、攻撃的なフィルタリングのあるホテル、その他のあまり良くない接続設定の場合、マシンがコントロールプレーンに到達するのに時間がかかることがあります。そして、時には全く到達できないこともあります。問題がどこにあるのかはしばしば不明瞭ですが、その結果、他のデバイスに到達できなくなります。

理想的なネットワーク条件下でも、100ミリ秒の起動レイテンシは、レイテンシに敏感なワークロードには大きすぎる場合があります。

netmapキャッシュは、コントロールプレーンに迅速に到達できない場合に、マシンが接続できるよう支援します。有効にすると、tailnet上の各デバイスはnetmapのコピーをディスクに保存します。デバイスが起動すると、そのキャッシュされたコピーを使用してtailnet上の他のデバイスとの接続を確立できます。これは、最新情報を取得するためにコントロールプレーンに連絡できるようになるまで続きます。（これらの接続はデバイス間で直接ネゴシエートされ、通常通りTailscaleはそのトラフィックを見ることはありません）。

「悪いネットワーク条件、これがnetmapキャッシュから多くのメリットを得られる領域です」と、テクニカルスタッフのClaus Lensbøl氏は述べています。「[デバイスクライアントは言います]、『ねえ、まだコントロールと話せていないんだ。たぶんすぐに到達できるだろう。それまでの間、何か始めてもいいよ』」

いくつかの制限があります。キャッシュは、デバイスがコントロールプレーンからネットワークマップを取得するために、以前にtailnetに少なくとも一度接続した場合にのみ機能します。さらに、netmapキャッシュは、キャッシュを保存するためにデバイスに永続的なディスクスペースが必要です。不要なディスク書き込みを最小限に抑えるように注意しましたが、場合によっては有効にしたくないかもしれません。例えば、例外的に大きなtailnetでは、キャッシュの更新に多くのディスクトラフィックが必要になる場合があります。同様に、SDカードのような遅い、または摩耗しやすいストレージを使用するデバイスは、netmapキャッシュを有効にしないことを好むかもしれません。

しかし、ほとんどのtailnet上のほとんどのデバイスにとって、この機能は起動時にデバイスが互いに連絡を取り合う速度を著しく向上させることができます。コントロールプレーンへの到達性が低いtailnetで、「ウォーム」キャッシュスタート時に、データプレーン経由での通信が「コールド」スタート時と比較して1〜2桁速くなるのを確認しました。起動レイテンシが変動するデバイスや、DERPサーバーまたはコントロールプレーンから遠く離れたデバイスでは、そのメリットは特に顕著です。

これらの速度向上がいつ実感できるか

• メモリ削減（バッファ変更による、Linux/Android）はv1.104クライアントで期待されます。
• マルチキュー（サブネットルーターとアプリコネクタにメリット）はv1.104以降のリリースで計画されています。
• スループット向上（Linux/Android）は2026年春に部分的に実装されました。メモリとスループットの追加的な向上はv1.104以降のリリースで計画されています。
• Netmapキャッシュは現在のTailscaleクライアントで機能フラグとして利用可能です。さらなるテストを経て、v1.104でデフォルトで提供される予定です。モバイルクライアントはv1.104以降のリリースでこの機能を提供する予定です。

パフォーマンスの診断とテストは依然として困難

確かに、私たちはTailscaleが高速だと考えています。しかし、それについて私たちを信頼する必要はありません。だからこそ、Tailscaleを意識した監視およびテストツールキットを検討しています。お客様がTailscaleネイティブな方法で、ネットワーク構成をテスト、診断、理解するために必要なツールを提供したいと考えています。

現代のパフォーマンステストにおけるギャップは以下の通りです。

• 分散の代償: ほとんどのパフォーマンスツールはポイントツーポイントであり、すべてのエンドポイントに何かをインストールする必要があります。
• ワークフローの硬直性: 間違ったテストを実行し、間違った出力を得て、存在しない問題を追いかけるのは非常に簡単です。
• プロトコルサポート: 多くのツールは、QUICやHTTP/3のような新しいプロトコルをサポートしていません。
• Tailscaleネイティブ対応: 一般的なツールはTailscaleネイティブではありません。接続がDERPを使用しているか直接か、ピアリレーが役立つ可能性があるか、接続パスが時間とともにどのように変化するかなどを伝えることができません。

既存のツールはTailscaleネイティブなパスと状態を理解していません。そのため、理解するツールの開発を検討しています。パフォーマンステストの未来を形作るお手伝いをしてください。