ベンダーや開発者が、自社の製品やプロジェクトが直接の競合他社と同等（または遅れている）と表現されるベンチマークを公開しているのを見たことがありますか?このような例はあるはずですが、思いつくのに苦労しています。それにもかかわらず、なぜ誰もがこれを行うことを選択するのでしょうか？この記事がこれらの結果を公開する理由を明らかにし、パフォーマンスに関するよくある誤解を解くのに役立つことを願っています。
最初のセクションではその方法と理由について説明しますが、結果までスキップしたい場合は自由に読んでください。このかなり複雑なトピックについて説明したい場合は、前のセクションを参照することをお勧めします。
背景
私たちは 2017 年の初めに Nebula の開発を開始しました。オープンソースのそれはほぼ 3 年後の 2019 年末でした。私たちは急速に成長していた会社である Slack 内で Nebula を構築したため、最初から規模と信頼性を考慮する必要がありました。
驚かれるかもしれませんが、それ以来、同様のソフトウェアに対して Nebula のベンチマークを行ってきました。<メモを確認する>この git commit によると、2018 年 10 月:
これらのベンチマークは、私たちが長年にわたって Nebula に加えた大きな変更を検証する貴重な方法であり、また、競合他社と比較して自分たちの立ち位置を確認するのにも役立ちました。この分野が進化するにつれて、テスト対象のほぼすべての製品の結果が向上していることがわかりました。私たち自身の目的のために、Nebula の古いバージョンに対して Nebula のベンチマークを実行し、バージョン間のメモリ リークや予期しない CPU 使用率などを確実に検出して解決します。ソフトウェアが何百万もの人々が依存するサービスのインフラストラクチャに接続する場合、パフォーマンス回帰テストを行うことが重要です。リソースの使用とパフォーマンスの一貫性と予測可能性は、私たちが重視しているものです。
私たちがこれを何年も行ってきたにもかかわらず、このような優れた公開バージョンのデータはありません。ベンチマークが存在すると思われる場合、それらは通常、恐ろしいほど 非科学的なまたは、継続的な取り組みではなく、特定時点のスナップショットです。メッシュ VPN サービスを常に改善している賢明な人々はいますが、進捗状況をその都度追跡している人はいません。私たちは、ベンチマーク手法を一般のレビューと貢献に公開することで、この状況を変えることを目指しています。
論文を読むことをお勧めします」公平なベンチマークは難しいと考えられている: データベースのパフォーマンス テストによくある落とし穴Centrum Wiskunde & Informatica (CWI) より、Mark Raasveldt、Pedro Holanda、Tim Gubner、Hannes Mühleisen 著。それは本当に素晴らしく、時間を費やす価値があります。タイトルにはデータベースについて言及されており、これは彼らの専門知識ですが、論文自体はあらゆるベンチマークに適用できる優れたポイントを述べています。図 1 は非常に正確なので、大声で笑ってしまいました。
有意義なベンチマーク テストのためのガイドライン
私たちは長年にわたり、テストを有益かつ公平なものにする方法について多くのことを考えてきました。テストで従う最も重要なガイドラインの一部を次に示します。
できるだけ客観的になってください。私たちは Nebula を非常に気に入っていますが、これらの結果のテストに関しては可能な限り客観的であることを目指しています。長年にわたり、これらのテストは内部でのみ使用されてきたため、データを操作したり歪めたりする動機はありません。これは常に私たちの利益のためであり、今後も私たちのテストプロセスにおいて非常に価値のある部分であり続けるでしょう。
ハードウェアを購入します。当初、私たちは他の皆さんと同じ間違いを犯しました。さまざまなクラウド プロバイダーでホストを起動して、意味のある再現可能なベンチマーク数値を取得しようとしました。公平を期すために言うと、テストに対する非常に現実的な注意事項を受け入れるのであれば、これはコードベースへの変更をテストするのに役立つかもしれません。精度が目標である場合、さまざまなベンダーのソフトウェアを比較するのはひどい方法です。私たちは、さまざまなクラウド プロバイダーのホスト上で Nebula を大規模に実行した豊富な経験があります。私たちが確認した唯一の一貫した点は、結果の一貫性のなさです。数年前、私たちは比較的退屈な i7-10700 CPU を搭載した非常に退屈な Dell デスクトップ コンピュータを 5 台購入し、それぞれに 10 ギガビット ネットワーク インターフェイス カードを取り付け、どのコンピュータよりも高価なスイッチに接続しました。テストは、ベンチマークを実行するたびに新しい OS をネットブートして行われます。通常、テストの各ラウンドの前に、Ubuntu の最新の LTS リリースを起動します。私たちの結果は再現可能で一貫性があり、結果を検証するために同じテストを複数回実行します。
熱の問題と戦わないようにハードウェアを調整します。CPU と冷却ソリューションには大きなばらつきがあるため、チップ工場の調子が悪かったり、ファンのブレードに目に見えない乱流亀裂が入っていたりすると、2 つの「同一の」ボックスでも、いったん環境が変化するとパフォーマンスが異なる可能性が非常に高くなります。先端。これを取り除くために、一貫性のないパフォーマンスを引き起こす可能性のあるいくつかの速度状態を無効にしました。これらのホストではハイパースレッディングも無効になっています。
複数のホスト間の複数のストリームをテストします。メッシュ VPN ソフトウェアを評価するときは、すべてのソフトウェアからのトラフィックを同時に送受信する必要があります。複数のホストを関与させると、驚くほど多くの新しい異なるパフォーマンス特性が現れます。誰かがベンチマークを投稿すると、2 つのホストを起動し、それらの間で 1 つの iperf3 ストリームを使用していることがよくありますが、その価値は限られています。まず、iperf3 が完全なコアを使用し、iperf3 がボトルネックになることがあります。これにより、無意味な結果が生じる可能性があります。 (著者の意見: iperf3 は非常に使いやすく便利なツールですが、これは幸いでもあり、呪いでもあります。) メッシュ VPN を使用している場合は、おそらく常に 3 つ以上のホストが通信していることでしょう。正直なところ、ポイントツーポイント接続のみを気にする場合は、好きなものを使用してください。ワイヤーガードは素晴らしいです。 IPsecは存在します。最近では OpenVPN もそれほど悪くはありません。
機能的に同等のものを比較します。これまで、ZeroTier や Tinc などのメッシュ VPN ソフトウェアだけでなく、Wireguard や OpenVPN などの従来の VPN に対しても Nebula のベンチマークを実施しました。このスペースにある商品は減りましたが、それはここ数年で大きく変わりました。 Nebula と Wireguard の目標はまったく異なり、Wireguard は ACL やホスト ID などには関与しません。この記事とテストのサブセットは、異なるソフトウェア間の違いについて必然的に長くなる説明を避けるために、機能的に Nebula と同等のものに意図的に限定されています。
競争の場を平等にします。ここでテストしたメッシュ VPN オプションはすべて、異なるデフォルト MTU を使用します。これに問題はありませんが、これらの製品間のパフォーマンスを有意義に比較する唯一の方法は、最小公倍数のパケット サイズを設定することです。特定の瞬間に送信するデータの量は、使用するアプリケーションによって決まります。そのため、アプリケーションが常に大きな MTU を最大限に活用するパケットを送信するとは考えにくいです。私たちは長年にわたり、実効 MTU 1240 と 1040 の間を何度も行ったり来たりしてきました。MSS クランプiperf3内。結果から分かるように、最も関連性の高い指標は通常、1 秒あたりのパケット数です。さまざまな MTU オプションを使用してスケールアップまたはスケールダウンしても、1 秒あたりのピークパケット数がボトルネックのままになります。ほとんどのネットワーキング ハードウェア ベンダーはこれらの用語で話しており、最終的に重要なのは、特定の時間枠内に送受信できるパケットの数だけです。
ホスト上でテストしているソフトウェアを決して混ぜ合わせないでください。私はずさんなテストのせいで、とんでもなく悪い結果をいくつか目撃しました。ほとんどのメッシュ VPN は、ピア間の新しいパスを継続的に検出しようとします。たまたま 2 つを同時に実行し、実行可能なパスとして相互に除外するように指示しなかった場合、たとえば、ZeroTier トンネルを介して Nebula トラフィックを送信することになる可能性があります。実際、私自身も誤ってこれをやってしまったことがある。さらに、一部のメッシュ VPN は、ルーティング テーブルを変更し、iptables ルールを追加し、次のテストに影響を与える可能性のあるあらゆる種類の処理をホスト システムに対して実行します。これらは削除する必要がある変数です。
自分のことだけでなく、あらゆるものを調整する方法を学びましょう。長年にわたり、私たちはテスト対象すべてのパフォーマンス特性を理解することに多くの時間を費やしてきました。通常、競合他社のソフトウェアのパフォーマンスを向上させる方法を学ぶ動機はありませんが、私たちの場合、それが起こっているかどうかを知り、その結果から学びたいと考えています。自分のことを調整して他のすべてを無視する一連のテストは疑わしいです。
楽しむ。冗談です。これは何年にもわたって大変な労力を要しました。面白いですが、特に面白いとは言えません。
メッシュ VPN の比較
この最初のデータ公開リリースでは、私たちが知っている中で最も人気のあるメッシュ VPN オプションをテストすることを選択したため、Nebula (AES モード)、Netmaker、Tailscale、ZeroTier を比較します (このリストは公平性への取り組みをさらに確認するために、意図的にアルファベット順に並べています）。これらのオプションを比較する場合、パフォーマンスに影響するため、考慮すべき非常に重要な注意事項があります。 Nebula と Tailscale のみがステートフル パケット フィルタリングを直接実装します。メッシュ オーバーレイに関連付けられた仮想ネットワーク インターフェイスに追加のルールを適用することなく、どちらも使用できます。 ZeroTier のステートレス ファイアウォールは機能がより制限されていますが、ステートフル パケット フィルタリングとステートレス パケット フィルタリングの利点についての議論は、この文書の範囲外です。
Netmaker には「ACL」と呼ばれるものがありますが、実際には、ホスト全体が相互に通信することを防ぐことしかできません。特定のポートやプロトコルを指定するために使用することはできません。 Netmaker では、きめ細かい制御のために iptables などを使用することをお勧めします。 iptables は実質的に「無料」であるのに十分な速さであると思われるかもしれませんが、これは絶対に当てはまりません。 INPUT チェーン上の単一のステートフル conntrack ルールであっても、テストではパフォーマンスに約 10% 影響を与える可能性があります。ほとんどの大規模な展開ではホスト間のトラフィックのきめの細かいフィルタリングを使用するし、使用する必要があるという事実にもかかわらず、ここで Netmaker をテストするときはそのようなルールを使用しないことにしました。
提案を歓迎します
(別のプロジェクトをここに挿入する) という主張もあるかもしれませんが、他のほとんどは依然として Wireguard または Wireguard-go に基づいています。 Wireguard に基づいて他のプロジェクトを追加するリクエストを検討します。もし皆さんは、私たちがここでテストした同様のオプションとは大きく異なる別のオプションのパフォーマンスの証拠を喜んで送ってくれます。
これらのベンチマークは、パフォーマンスの継続的な記録として使用することを目的としています。この情報の需要を感じたら、公開/比較のペースを落ち着かせるつもりです。これは時間のかかるタスクであるため制限はありますが、構成、テスト パラメーター、コマンド ライン、およびテストの生の結果は、一連のテストを行うたびに GitHub で利用できるようになります。これらのプロジェクトの作成者またはユーザーがテストのさらなる調整と改良に協力を希望する場合は、合理的な変更を喜んで統合し、可能であれば新しいバージョンのベンチマークを行います。
テスト
私たちは何年にもわたっていくつかの異なるテストを行ってきましたが、これを 3 つの主要なテストに絞り込み、さまざまなメッシュ VPN オプションを有効に比較できるようにしました。使用したテスト方法を説明し、さまざまな結果の視覚化とデータの解釈および注意事項を示します。
テスト 1: マルチホストの一方向送信
説明: 1 つのホストが、事前に設定されたレート制限なしで 10 分間、他の 4 つのホストにデータを同時に送信します。このテストでは、意図的に各オプションの送信側に焦点を当てているため、非対称のボトルネックがあるかどうかを判断できます。
使用した方法:iperf3 [ホスト 2,3,4,5] -M 1200 -t 600
このグラフは、4 つのオプションのうち 3 つ (Nebula、Netmaker、Tailscale) が、基盤となるハードウェアの制限に一致するスループット (ほぼ 10 ギガビット/秒 (Gbps)) に達できることを示しています。 4 番目のオプションである ZeroTier は、シングルスレッドつまり、他のホストとは異なり、利用可能な多数の CPU コアを持つホストを利用できません。その結果、ZeroTier のパフォーマンスは他のものと比べて大幅に制限されます。 Tailscale の結果は、上部にある他の 2 つの結果よりも少し変動が大きく、さまざまな短期間の低下と、テスト中に +/- ~900 Mbps というわずかに一貫性のないパフォーマンスが見られます。
注: ZeroTier の奇妙な低下は、時間は異なりますが、これまでに行ったすべての送信専用テストで一時的に発生しました。このような一時的なスループット低下の原因はまだ特定されていません。
これは、4 つのオプションのうち 3 つのプロセスによって使用される合計メモリです。テールスケールのメモリ使用量はテスト中に非常に変動しており、セグメンテーション オフロードのためにパケットを結合する取り組みに関連しているようです。このメモリの一部はテスト後にガベージ コレクションによって回復される可能性がありますが、これもこの記事の範囲外です。テスト中にメモリ使用量が 1 GB を超えることが確認されており、変動を切り分けるのは困難でした。ここでのメモリ結果は、これまでに記録した最良の実行結果からのものです (Tailscale が他の実行と比較してメモリ使用量が最も少ない場合)。
Nebula と ZeroTier はメモリ使用において非常に一貫性があり、テスト全体を通じて目立った変化はほとんどありません。 Nebula では平均 27 メガバイトのメモリが使用され、ZeroTier では平均 10 メガバイトのメモリが使用されます。
注: Linux 上の Netmaker は Wireguard カーネル モジュールを使用するため、メモリ使用量に関するデータを有意義に収集することはできませんが、外部からの観察によると、データは一般に効率的で一貫性があります。
このグラフは、スループットと CPU リソースの関係を示しています。ここでは、ZeroTier と Nebula は非常によく似ていますが、ZeroTier の方が少し変化しやすいことがわかります。 Nebula は、追加の CPU に応じて非常に直線的に拡張します。 Tailscale の結果は、さまざまな Linux セグメンテーション オフロード メカニズムを使用しているため、ここでは大幅に改善されています。これにより、パケット処理パスで使用するシステムコールを減らすことができます。ただし、これらの「スーパーパケット」を処理する場合、カーネルによる CPU 使用率が増加することに注意してください。そのため、セグメンテーション オフロードは確かに効率を向上させますが、合計を考慮すると、見た目ほど劇的ではありません。システムリソース。いずれにせよ、セグメンテーション オフロードは印象的であり、これによって Tailscale の Linux パフォーマンスが 2023 年初頭に Nebula のスループット数値に追いつくことができました。非 Linux プラットフォームに関するいくつかの重要な注意事項については、この記事の最後にある注 1 を参照してください。
注: Netmaker は、カーネル スレッドの CPU 使用量を定量化することが難しいため、ここでも含まれていません。これは他のものと非常に似ており、これらの速度では大量のリソースを使用することに注意してください。
テスト 2: マルチホストの一方向受信
説明: 4 台のホストが 10 分間できるだけ速くデータを個々のホストに送信します。このテストでは、意図的に各オプションの受信側に焦点を当てているため、非対称のボトルネックがあるかどうかを判断できます。
使用した方法:iperf3 [ホスト 2,3,4,5] -M 1200 -t 600 -R
このグラフは、4 つのオプションのうち 2 つ、Netmaker と Tailscale が、基盤となるハードウェアの制限に一致するスループット (ほぼ 10 Gbps) に達できることを示しています。 Netmaker のラインを図 2 と比較すると、受信側で Netmaker のラインがフラットではなくなっていることがわかります。これは、他のすべてのオプションと同様に、受信側の CPU が制限されているためです。これは、カーネル Wireguard の受信側の処理パス スタイルが異なることに関連しており、ボトルネックになります。 Nebula はこのテストで遅れをとっており、リーダーよりも常に約 900 Mbit/s 遅れていることがわかります。以前と同様、ZeroTier はパケット処理に複数の CPU コアを使用できないことによって妨げられています。
これも、4 つのオプションのうち 3 つのプロセスによって使用される、受信側の合計メモリです。テールスケール メモリは、テスト中は引き続き大きく変動しますが、受信時には変動が若干少なくなります。繰り返しになりますが、Tailscale のメモリ使用量の一部は、テスト後にガベージ コレクションを通じて回復される可能性がありますが、これもこの記事の範囲外です。ここでのメモリの結果も、これまでに記録した最良の場合の実行からのものです (Tailscale が他の実行と比較してメモリ使用量が最も少ない場合)。
Nebula と ZeroTier のメモリ使用量は非常に一貫しており、ここでもテスト全体を通じて目立った変化は見られません。 Nebula では再び平均 27 メガバイトのメモリが使用され、ZeroTier では平均 10 メガバイトのメモリが使用されています。
注: Linux 上の Netmaker は Wireguard カーネル モジュールを使用するため、メモリ使用量に関するデータを有意義に収集することはできませんが、外部からの観察によると、データは一般に効率的で一貫性があります。
図 4 と同様に、このグラフはスループットと CPU リソースの関係を示しています。 ZeroTier は以前とよく似ていますが、Nebula の方が効率的であることがわかります。これは事実ですが、図 4 で Tailscale の方が効率的であるように見える理由と似ています。この場合、Nebula は長い間、recvmmsg システムコールを実装しており、負荷をカーネル側にわずかにシフトしますが、おそらくセグメンテーション オフロードほど大きくはありません。これを確認するにはテストが必要です）。
ここでも、Tailscale の結果は、さまざまな Linux セグメンテーション オフロード メカニズムを使用しているため、大幅に改善されているように見えますが、これもパケット処理オーバーヘッドの負担の一部をセグメンテーション オフロードを通じてカーネルにシフトしたことによるものです。
注: Netmaker は、カーネル スレッドの CPU 使用量を定量化することが難しいため、ここでも含まれていません。これは他のものと非常に似ており、これらの速度では大量のリソースを使用することに注意してください。
テスト 3: マルチホスト双方向送受信
説明: 1 つのホストが、事前に設定されたレート制限なしで 10 分間、他の 4 つのホストとの間で同時にデータを送受信します。このテストでは、送信ストリームと受信ストリームを意図的に結合するため、ボックスが限界で送受信しているときにボトルネックがあるかどうかを判断できます。
使用した方法:iperf3 [ホスト 2,3,4,5] -M 1200 -t 600そしてiperf3 [ホスト 2,3,4,5] -M 1200 -t 600 -Rホスト 1 で同時に実行されます
このグラフは、合計スループット数に追加される同時送受信トラフィックの独立した線を示しています。ここで達成可能な最大値は 19 ～ 20 Gbps であり、どのオプションもこのパフォーマンスを達成していないことがわかります。 Netmaker は合計送受信スループットの平均約 13 Gbps を達成し、続いて Nebula と Tailscale が平均約 9.6 Gbps でほぼ同率となっています。 ZeroTier は再び残りに遅れをとりましたが、送信と受信を個別に処理する機能があり、指向性テストよりも改善が見られ、平均 ~3Gbps であることがわかります。
注: ZeroTier の奇妙な低下は、双方向テスト中には発生しないようです。
結果は以前のメモリ使用量と一致しており、Nebula と ZeroTier は一貫した量を使用しており、Tailscale はより変動しており、パケットの処理に大幅に多くのメモリを使用しています。
注: Linux 上の Netmaker は Wireguard カーネル モジュールを使用するため、メモリ使用量に関するデータを有意義に収集することはできませんが、外部からの観察によると、データは一般に効率的で一貫性があります。
図 4 および図 7 と同様、このグラフはスループットと CPU リソースの関係を示しています。 Nebula と同様に、ZeroTier も以前と非常によく似ていることがわかります。このテストは最終的に送信負荷が大幅に高くなるため、結果は送信側をより顕著に表す傾向があります。やはり Tailscale の方が効率的であるように見えますが、カーネルがより多くの作業を実行していることに注意してください。
注: Netmaker は、カーネル スレッドの CPU 使用量を定量化することが難しいため、ここでも含まれていません。これは他のものと非常に似ており、これらの速度では大量のリソースを使用することに注意してください。
結論
単一の「最適な」ソリューションはありません。 Nebula、Netmaker、および Tailscale は、最新の CPU 上で単一方向の 10 Gbps ネットワークを飽和させるパフォーマンスを現実的に達成でき、総 CPU 使用率に関しては非常に類似したプロファイルを持つ傾向があります。 Tailscale は、テストした他のオプションよりも常に大幅に多くのメモリを使用します。 (注: 歴史的に Tailscale はかなり遅れをとっていたが、セグメンテーション オフロードにより、複雑な内部パケット処理パスのオーバーヘッドが高いにもかかわらず、はるかに優れたパフォーマンスを達成できるようになりました。)
上で述べたように、ステートフル パケット フィルタリングを備えているのは Nebula と Tailscale だけですが、これはここで重要な考慮事項です。 Netmaker に対する iptables ルールの影響を示すこのテストの最新バージョンをご希望の場合は、お知らせください。今のところ、一見不必要に見える iptables ルールを追加した理由を説明するよりも、Netmaker にわずかながら不当な利点を与えたほうが安全です。
ネットワークがギガビットの場合、ZeroTier は他のものと同等の能力を持ち、測定された 3 つの中でメモリ使用量が最も低くなります。これは非常に効率的ですが、マルチスレッドがないため制限されています。
最後に、一部のテストでは基盤となるネットワークが制限になっているため、40 ギガビット イーサネット ハードウェアの調達を開始する必要があると思います。
ありがとう + 追加メモ
この比較的密度の高いパフォーマンスの探求を読んでいただくために時間を割いていただき、心から「ありがとう」と思います。最もパフォーマンスの高いメッシュに関する簡単な答えを期待してこの記事を読んだ人は、きっととてもがっかりするでしょう。公平を期すために、私たちはこれが記事のタイトルに当てはまるだろうと電報しました。生データと構成が含まれる Github リポジトリは間もなく利用可能になる予定です。パフォーマンスを調整するための適切な提案を提供して、喜んでテストを再度実行します。
特にどこにも当てはまらなかったが、おそらく誰かが興味深いと思うかもしれないので含まれているボーナスノート:
これらのプロジェクトによって実装されたパフォーマンスの最適化のほとんどは、Linux にのみ影響します。セグメンテーション オフロードなどは、Windows や MacOS では一般的に利用できません。ここでは範囲外ですが、Nebula が Wireguard-go (Netmaker と Tailscale の両方が Linux 以外のプラットフォームで使用している) よりも大幅に効率的であることを証明するデータがあります。このデータを知りたい人がいれば、フォローアップを書くかもしれません。記事。
基盤となるネットワークによっては、より高い MTU 値を使用して合計スループットを大幅に向上させることができます。 AWS のデフォルトの MTU は 9001 なので、Nebula の MTU は 8600 です。ただし、もう 1 つの重要な詳細: AZ を離れると、MTU は 1500 に低下します。大きな Nebula パケットを送信すると、パケットが断片化されます。 AWS (およびその他) は断片化されたパケットを積極的にレート制限するため、それに注意してください。 Nebula には、異なるネットワーク範囲で異なる MTU を使用できる機能が組み込まれており、AZ の内部では大きな MTU を利用できますが、他の場所ではデフォルトで小さな MTU を使用することができます。
Tinc を結果から除外したのは、パフォーマンスの点で競争力がほとんどないという理由だけです。私は Guus Sliepen とその人々が何年も Tinc で行ってきた仕事を尊敬しており、2010 年代半ばまでは幸せなユーザーでしたが、パフォーマンスの点では競争力がありません。さらに、他のオプションでは複製されない斬新な内部ルーティング機能がいくつかあります。
Raspberry Pi 5 は、AES 命令をサポートする最初の Pi であり、AES モードの Nebula は、複数のコアを使用せずに簡単にギガビットを飽和させます。
カーネル スレッドはユーザー空間ほど測定するのが簡単ではないため、カーネル ベースのオプションを直接評価するのは難しい (または不可能) 場合があります。これが、カーネル Wireguard (Netmaker) のメモリ使用量の数値がない理由です。おそらく間接的な観察によってある程度は近づける可能性がありますが、それが目的に十分正確であるかどうかは自信がありません。
iOS でのテストから WiFi の変動性を排除したかったため、Lightning Ethernet アダプタを所有していますが、Lightning Ethernet アダプタには Wifi よりもはるかに変動性があります。それは楽しいですね。
