ネットワーク パフォーマンスの解読: ヘッダー、データ、ビットレートについて

※この投稿は米国時間 2025 年 9 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

Network Performance Decoded ホワイトペーパー シリーズの第 3 弾をお届けします。今回は、クラウドベースのワークロードのトラブルシューティング、デプロイ、スケーリング、アーキテクチャ設計を行う際に頻繁に発生する、ネットワーク パフォーマンスとベンチマークのベスト プラクティスに関するトピックについて詳しく説明します。このシリーズは、ネットワークを最大限に活用するだけでなく、アプリケーションのパフォーマンスに大きな影響を与える可能性のあるコストのかかるミスを回避するためのヒントを提供するために、昨年開始されました。前回の 2 回の記事では、TCP と UDP のバルクフローのパフォーマンスのチューニングとネットワーク パフォーマンスの制限要因について説明しました。

今回は、最近の 3 つのホワイトペーパーの概要を紹介します。1 つ目は TCP 再送信に関するもの、2 つ目はヘッダーと MTU がデータ転送のパフォーマンスに与える影響に関するもの、3 つ目は netperf を使用して 1 秒あたりのパケット数を測定するものです。

1. 迅速な対応: TCP 再送信動作の調整

TCP 再送信動作のチューニングの概要に関するホワイトペーパーでは、2 つの Linux TCP 設定（net.ipv4.tcp_thin_linear_timeouts と net.ipv4.tcp_rto_min_us（または rto_min））を調整して、オンライン アプリケーションの応答性を高める方法について説明しています。これは、アプリケーションの応答時間と、ネットワークに問題が発生した場合のアプリケーションの復旧速度を微調整するようなものです。

詳細については論文をお読みいただく必要がありますが、ここでは論文で取り上げられている内容の概要をご紹介します。

• より迅速な復元が可能に: これらの設定、特に rto_min を小さくすることで、ネットワークに短時間の中断が起きた後に、TCP 接続が何もせずに待機する時間を大幅に短縮できます。つまり、アプリの応答が速くなり、ユーザーはよりスムーズな体験を得られます。

• 新しいカーネルはより便利に: 新しい Linux カーネル（6.11 以降）を実行している場合は、rto_min をさらに低く（5 ミリ秒まで）設定できます。これは、新しいカーネルではよりスマートな方法で処理が行われるため、復元がさらに速くなるからです。

• Protective ReRoute で、復元力は次のレベルに: Google Cloud をご利用のお客様は、net.ipv4.tcp_rto_min_us を調整することで、Google Cloud の Protective ReRoute（PRR）メカニズムをより早く起動させ、アプリケーションのネットワーク問題に対する復元力を高めることができます。

• 一時的な停止以外も対象に: ランダムで個別に発生したパケットロスの場合にも、これらの調整は効果を発揮します。アプリの応答速度の目標がある場合は、これらの設定を使用して、TCP がその期限よりも前にデータを再送信するようにできます。

2. ネットワークのリンク速度を超える

ネットワーク パフォーマンスを考えるときは、「リンク速度」だけを考慮するのではなく、Google のホワイトペーパー「ヘッダー、データ、ビットレート」では、データ転送の真の速度がどのように決まるかについて説明しています。

• ヘッダー: パケットごとに送信される実際のデータを減らすために必要なパッケージングと考えてください。

• 最大伝送単位（MTU）: 最大パケットサイズを決定します。MTU が大きいほど、パケットあたりのデータ量が多くなり、データ転送の効率が向上します。

クラウド環境では、VM のアウトバウンド データの上限（下り上限）は、必ずしも物理ネットワークの速度と同じではありません。クラウド固有の追加ヘッダーは、近い場合でも最終的なスループットに影響を与える可能性があります。MTU 設定を最適化して、クラウド ネットワークを最大限に活用しましょう。つまり、宣伝されている速度だけでなく、データがどれだけ効率的に移動するかが重要です。

3. 処理できるトランザクションの数は？

netperf を使用して 1 秒あたりのパケットの集計数を測定するでは、netperf を使用して、ネットワークが 1 秒あたりに処理できるトランザクション（つまりパケット）の数を把握する方法を学びます。これは、巨大なファイルを移動するだけではないシステムにとって非常に便利です。大量の転送を測定するだけでなく、リクエスト/レスポンス アプリケーションのパフォーマンスを制限する可能性がある 1 秒あたりのパケット数を測定する方法を学びます。

主なポイント:

• スキューエラーの解消: netperf 一度に多数のテストを実行すると、奇妙な結果になることに気づいたことはありませんか？これは「スキューエラー」と呼ばれます。このホワイトペーパーでは、「デモモード」を使用してこのエラーを修正し、全体的なパフォーマンスの数値をより正確に取得する方法について説明します。

• テストの規模を把握する: 信頼できる結果を得るために必要な「ロードジェネレータ」（トラフィックを送信するマシン）の数と同時ストリームの数に関する実用的なヒントを入手できます。基本的には、システムに真に挑戦できるだけのパワーが必要です。

• UDP バーストモードが役立つ理由: 「バーストモード UDP/RR」を使用することが、1 秒あたりのパケット数を測定するための秘訣である理由を説明しています。TCP は非常にスマートですが、効率性を追求しすぎるあまり、パケットの真のレートを隠してしまうことがあります。

• フルスペクトルのテストと分析: ホワイトペーパーでは、runemomniaggdemo.sh スクリプトで実行できるさまざまなテストタイプについて説明し、テスト対象のインスタンスが 1 秒あたりに処理できるネットワーク トランザクション数を効果的に測定する方法を示しています。これにより、このベンチマークに影響を与える、ネットワークの他の部分の側面を推測できる可能性があります。さらに、数値を処理する方法や、結果を可視化するためのグラフを作成する方法も紹介します。

今後の情報にご注目ください 

これらのリソースを通じて、ネットワークのベンチマークとトラブルシューティングのためのオープンで協力的なコミュニティを育成することが Google の目標です。例は Google Cloud から引用していますが、その根底にある原則は、ワークロードがどこで動作していても普遍的に適用できます。公開済みおよび今後公開されるすべてのホワイトペーパーは、こちらのウェブページからご覧いただけます。今後もぜひご期待ください。

-シニア プロダクト マネージャー、Sumit Singh

-ネットワーク ソフトウェア エンジニア、Rick Jones