コンテンツに移動
ネットワーキング

ネットワーク パフォーマンスの解読: パフォーマンスの制限要因について

2025年1月10日
Sumit Singh

Senior Product Manager

Rick Jones

Network Software Engineer

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

数か月前にお届けした「ネットワーク パフォーマンスの解読」では、ネットワーク パフォーマンスとベンチマークのベスト プラクティスに関するホワイトペーパーについてご紹介しました。本日お届けする第 2 弾では、多くのお客様が直面する厄介な問題である、パフォーマンスの制限要因についてご紹介します。このブログ投稿では、これらの問題に取り組む方法について、より詳細な情報をお届けします。

A Brief Look at Network Performance Limiters(ネットワーク パフォーマンスの制限要因について)

このホワイトペーパーは、ネットワーク インターフェース カードの速度がネットワーク パフォーマンスのすべてであるという通説を打ち破りますMbit/ Gbit/秒といった高速性が素晴らしいことは確かですが、ネットワークの実際の効率性は、パケットサイズやオフロード技術によって大きな違いが生じます。その一部をご紹介します。

  • Mbit/秒がすべてではない: 速度だけが重要なのではありません。データのパッケージ方法(パケットサイズ)は、スループットと CPU 使用率に重大な影響を与えます。

  • パケットの大きさが結果に影響する: パケットが大きいほどパケットあたりのオーバーヘッドが少なくなり、スループットの向上と CPU 負荷の軽減につながります。

  • オフロードで TCP スループットを向上: TCP セグメンテーション オフロード(TSO)や汎用受信オフロード(GRO)によって、負荷のかかる作業の一部をネットワーク インターフェース カードに代行させることで、CPU を解放し、パケットが小さい場合でも TCP スループットを向上させることができます。

  • 1 秒あたりのパケット数制限に注意: システムが 1 秒あたりに処理できるパケット数によっては、パケットが小さくてもボトルネックが発生することがあります。

  • ビットレートが一定の場合はパケットが大きいほど高効率: ビットレートが一定の場合でも、個々のパケットが大きいほど全体的なパケット数は少なくなるため、CPU オーバーヘッドが減り、ネットワークが効率的になります。

これらのコンセプトを理解すれば、提示されている速度に捉われず、ネットワークを微調整してパフォーマンスと効率性を向上させることができます。

A Brief Look at Round Trip Time(ラウンドトリップ時間について)

このホワイトペーパーは、ネットワーク パフォーマンスの主要な測定基準である TCP ラウンドトリップ時間(RTTについて詳しく説明しています。RTT の測定方法や RTT に影響を与える要因、それらの情報を利用してネットワークの問題をプロ並みにトラブルシューティングする方法をご紹介します。また、受信側アプリケーションの動作が RTT の測定にどのような影響を与えるかを示し、考慮すべき重要な違いについても説明します。たとえば、TCP RTT 測定には、アプリケーションがレイテンシとして認識する、TCP が損失したセグメントを再送信するために費やす時間は含まれません。最後に、netperfPerfKit Benchmarker ツールキットにも含まれています)などのツールを使用してエンドツーエンドの全体像を把握する方法をご紹介します。

A Brief Look at Path MTU Discovery(パス MTU 探索について)

このホワイトペーパーは、IP の断片化を防止するプロセスであるパス MTU 探索について詳しく説明しています。ネットワークがパケットサイズをどのように処理するかを理解することで、ネットワーク設定の最適化、断片化の問題の回避、効果的なトラブルシューティングが可能になります。また、一般的な問題とその解決方法についても説明します。たとえば、送信者に通知されることなく大きなパケットがドロップされてしまう ICMP ブロックなどを取り上げます。さらに、ネットワークの構成やパケットサイズの問題のトラブルシューティングに役立つ、最大伝送単位(MTU)と最大セグメント サイズ(MSS)の違いについても説明します。

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

これらのリソースは、ネットワーク パフォーマンスのベンチマークやトラブルシューティングのためのオープンで協力的なスペースを創出するという Google のミッションの一環です。事例が Google Cloud のものであっても、その考え方はどこにでも当てはまります。ワークロードが実行されている場所は問いません。公開済みおよび今後公開されるすべてのホワイトペーパーは、こちらのウェブページからご覧いただけます。今後もご期待ください。

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

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

 

投稿先