Tailscale パフォーマンス強化レポート：高速化・最適化の最新動向と将来ロードマップ

Tailscale は、単なる VPN だけでなく、複雑なネットワーク環境下でも常に最適な経路を見つけ出すことに特化し続けています。その核心となるのは「NAT トラバース」技術と、データプレーンにおける高パフォーマンスの実装です。過去数年間にわたり Linux や wireguard-go を中心に開発を進め、現在は以下のような多様なワークロード（CI/CD、リモート開発、エッジデバイスなど）に対応可能です。

さらに速く、より効率的にするために、本稿ではメモリ負荷削減、マルチキュー実装、スループット向上、そして起動速度改善の 4 つの柱について詳しく解説します。

1. メモリ負荷の低減：小容量パケットへの最適化

ネットワーク上の多くのパケットは極めて小さく（例：1 KiB）、Tailscale は一度に64 KiBのトラフィックを処理する「Generic Receive Offload (GRO)」規格に対応しています。これにより、小さなパケットごとに重複した処理を防ぎます。

以前の仕組み

• コンテナモデル: GRO を利用するには、Tailscale は各パケットを一度に 64 KiB のサイズに拡張（展開）して処理する必要がありました。
• コストの問題: wireguard-go という基盤実装では、単一の固定サイズバッファ（64 KiB）しか提供しませんでした。
• 結果: 1 KiB のパケットでも、必ず独自の 64 KiB バッファにコピーされるため、メモリの非効率な使用が続いていました。

新しい仕組みと効果

• ゼロコピー処理: Linux および Android 環境において、パケットを新たな場所へコピーせず、保持したまま利用する技術を実装しました。
  • 各パケットの開始・終了位置を特定し、単一の大規模読み込み操作内で処理します。
  • メモリ上でもパケットサイズは小さく保たれ、複数のパケットが一つの割り当てメモリを共有できます。
• キュー短縮: パケット待ち行列（キュー）の長さを短縮。未使用なキューによる不要なメモリ消費を防ぎました。

【成果】

• これらの改良により、多くのネットワーク環境において約 5% の速度向上を実現しました。

メモリ解放先の活用

解放されたメモリスペースは、最も過酷な環境で稼働する以下のノードに還元されています。

• サブネットルーター
• アプリケーションコネクタ

2. サブネットルーター・エグジットノード向け：マルチキュー機能の導入

サブネットルーターやアプリケーションコネクタは、接続数やトラフィック量がユーザーごとに大きく異なる環境（ホームラボから大規模クラウドまで）で動作します。従来は複数の独立したストリームを、一連の順序付き単スレッドパイプラインで処理しており、これは「一つの経路が多数の接続を共有」する構造でした。

メモリフットプリントの削減を機に、マルチキューシステムを実装しました。

• レインの概念: 単一のレーンを廃止し、複数のレーン（並列処理経路）を設けます。
  • スケール基準はピア数ではなく、マシンのリソースに基づきます。
• 並列処理: 各ストリームのパケットは個別のレーンに割り当てられ、CPU コア全体に処理負荷が分散されます。

期待される効果

• キャパシティ向上: 総合的な処理能力の飛躍的向上。
• レイテンシ低減: パケット受信から転送までの間隔（OS への送出まで）を本質的に短縮。
  • 特に多数のユーザーと短命な接続を持つアプリケーションコネクタおよびエグジットノードで顕著なパフォーマンス改善が見込まれます。

Alex Valiushko（Tailscale 技術スタッフ） 「これはレイテンシ低下に直結しており、データを受信した瞬間から OS へ送出するまでの間隔を本質的に短縮することを意味します。」

3. writev を用いたスループット向上（Linux 限定）

Tailscale クライアント（Linux）では、

writev

• 仕組み: 「ベクトル（vector）」を指す「v」を含むこの機能は、複数のデータをコピーして結合する手間を省きます。
  • データを移動させることなく、書き込むべきデータ区分を一括で記述できます。
• メリット:
  • メモリ上のパケットデータの複製回数削減。
  • 書き込みオペレーションの減少。
  • その結果、スループットの向上が実現します。

4. netmap キャッシングによる起動時間の短縮

現在は Linux および Android システム限定ですが、近い将来他のシステムにも適用可能な機能として開発が進んでいます。

背景と課題

• 通常の流れ: デバイスはまずコントロールプレーンに接続し（認証：約 100ms）、次に「ネットワークマップ（netmap）」を取得します。
• 問題点: 飛行機内の Wi-Fi や厳格なフィルタリング環境など、コントロールプレーンへの到達が困難な場合、機器が他のデバイスと通信できなくなります。
  • 理想的な環境でも 100ms という起動時のレイテンシは、一部の感度の高いワークロードにとっては遅すぎます。

netmap キャッシングの仕組み

• ディスク上の保持: テールネット上の各デバイスが、netmap のコピーをディスク上に保持します。
• 通信断絶時でも動作: コントロールプレーンと通信できない場合でも、キャッシュされたコピーを使用してテールネット内の他のデバイスとの接続を確立できます（機器間接続は Tailscale を介さず直結）。

Claus Lensbøl（Tailscale 技術スタッフ） 「悪質なネットワーク環境こそ、netmap キャッシングが最も活かせると言えます。デバイスのクライアントからは、『まだコントロールプレーンとは話し合えていませんが、いずれ到達できるでしょう。その間でも既に作業を開始できます』と言っているようなものです。」

導入の制限事項

以下の条件を満たす必要があります。

1. 初回接続: デバイスが以前にテールネットと一度も接続し、コントロールプレーンからネットワークマップを取得している必要がある。
2. ディスク容量: キャッシュ保存用の永続的なディスクが必要（不要な書き込み最小化は実施中）。

【導入しない推奨ケース】

• 極めて大規模なテールネット（キャッシュ更新に伴うディスクトラフィックが膨大な場合）。
• SD カードのような低速または寿命に敏感なストレージを使用するデバイス。

【成果】

• コントロールプレーン到達が困難な環境でも、「冷たい起動」から「温かい起動」へのシフトにより、データ転送開始速度を約 1～2 オーダー（10～100 倍）高速化しました。
• DERPS サーバーやコントロールプレーンから遠いデバイスにおいて特に恩恵が大きい。

5. 新機能提供のスケジュール

6. パフォーマンス診断・テストの取り組み

Tailscale は高速であることを確信していますが、お客様への信頼だけを理由にするつもりはありません。そのため、Tailscale 固有の状態を可視化できる新しいモニタリングおよびテストキットの開発に取り組んでいます。

既存のパフォーマンステストツールには以下のような課題があります：

• 配布コスト（Distribution Tax）: ポイント対ポイント方式が多く、エンドポイントごとにソフトウェアインストールが必要。
• ワークフローの柔軟性の欠如: 不適切なテスト実行や誤った結果による問題の追及が容易。
• プロトコル対応性: QUIC や HTTP/3 など、新しいプロトコルに対応していないツールが多い。
• Tailscale 固有の可視化不足: 汎用ツールでは以下の情報を理解できません。
  • 接続経路が DERP を介しているか、直結か？
  • ピアリelay が有効なのか？
  • 接続経路が時間とともにどのように変化しているか？

Tailscale 固有のパターンや状態を理解できる新しいツール開発を進め、お客様と共にパフォーマンステストの未来を創造していきます。