はじめに
Webシステムのレスポンスタイムやスループットは、CPU・メモリ・ストレージだけで決まりません。クライアントからWebサーバ、APサーバ、データベースまでの通信経路では、回線帯域、Latency、Packet Loss、TCPの制御、NICやネットワーク機器の処理能力など、複数の要素が性能へ影響します。
ネットワーク性能を考えるときに重要なのは、単に「1Gbpsだから十分」「pingが通るから問題ない」と判断しないことです。どの程度のデータを、どのくらいの遅延で、どれだけ安定して運べるかを、実際のワークロードと対応付けて考える必要があります。
本記事ではLinuxベースのWebシステムを想定し、Bandwidth、Throughput、Latency / RTT、Packet Rate、Packet Loss、TCP Retransmissionといった主要指標から、TCP Window、MTU、Socket Buffer、Backlog Queue、ネットワーク機器の性能設計、縮退時の設計、性能試験、ボトルネック調査までを一通り解説します。
ネットワーク性能の全体像
Webシステムでは、1回のリクエストでも複数のネットワーク区間を通過します。例えばクライアントからロードバランサ、Webサーバ、APサーバ、データベースへ通信する構成では、それぞれの区間で通信時間や待ち時間が発生します。
ネットワーク性能は、主に「どれだけ運べるか」「どれだけ早く届くか」「途中で失われていないか」の3つに分けると理解しやすくなります。
| 指標 | 意味 | 単位 |
|---|---|---|
| Bandwidth | 通信路が持つ帯域幅 | Mbps / Gbps |
| Throughput | 実際に単位時間あたり転送できたデータ量 | Mbps / Gbps |
| Latency | データが一方向へ届くまでの遅延 | ms |
| RTT | 送信して応答が戻るまでの往復時間 | ms |
| Packet Rate | 1秒あたりに処理するPacket数 | pps |
| Packet Loss | 途中で失われたPacketの割合 | % |
| Retransmission | TCPで再送されたSegment | 回数 / 割合 |
これらは独立した指標ではありません。例えばPacket Lossが発生するとTCP Retransmissionが増え、実効Throughputが低下し、結果としてアプリケーションのレスポンスタイムが悪化することがあります。
BandwidthとThroughput
Bandwidthは「通せる量」、Throughputは「実際に運べた量」
Bandwidthは通信路が持つ帯域幅です。例えば1GbpsのEthernetであれば、リンクの公称速度は1Gbpsです。一方、Throughputは実際の通信で単位時間あたりに転送できたデータ量です。
公称1Gbpsのリンクだから、アプリケーションが常に1Gbpsで転送できるわけではありません。プロトコルのオーバーヘッド、他通信との共有、TCP制御、Packet Loss、サーバ処理などの影響を受けます。
また、同じBandwidthでもPacket Sizeが小さいほど1秒あたりに処理するPacket数（pps）は増加します。そのため、Gbpsに余裕があるからといって、NICやネットワーク機器の処理能力にも余裕があるとは限りません。Bandwidthと合わせてPacket Rateも確認します。
平均値だけでなくピークトラフィックを見る
日次平均や5分平均だけを見ると短時間のバーストを見落とすことがあります。通常時は帯域に余裕があっても、アクセス集中やバッチ転送、バックアップなどが重なると、一時的にQueueやDropが発生する可能性があります。
平均Throughputだけでなく、ピーク時の通信量、Packet Rate、Drop、Queueを確認します。必要な性能余力は固定の割合ではなく、負荷変動、将来の増加、増速に必要な時間、障害時の残存帯域などから決めます。
LatencyとRTT
Bandwidthが十分でも、Latencyが大きければWebシステムのレスポンスタイムは悪化します。Latencyは通信の遅延時間、RTT（Round Trip Time）は送信したデータに対する応答が戻るまでの往復時間です。
Latencyには物理的な伝搬時間だけでなく、Router / Firewall / Load Balancerなどでの処理、Queueによる待ち時間、回線の混雑なども影響します。
WebシステムではLatencyが積み重なる
1回の画面表示の裏側で複数回の通信が発生する場合、1回あたりのRTTが小さくても、その回数が多ければ待ち時間が積み重なります。帯域だけでなく、どの通信区間でどの程度のRTTが発生し、その通信が何回繰り返されるかを確認します。
Packet LossとTCP Retransmission
Packet Lossは送信されたPacketが途中で失われることです。原因にはネットワーク機器やNICのQueueあふれ、輻輳、物理エラー、設定不整合などがあります。
TCPは必要に応じて失われたデータを再送します。そのためPacket Lossが発生すると、TCP Retransmissionによる追加通信と待ち時間が発生します。
特に高Latencyの通信では、再送による待ち時間の影響が大きくなることがあります。「通信は成功しているが遅い」という場合でもRetransmissionを確認します。
TCPの性能設計
TCP Windowとは
TCPでは、受信側が受け入れ可能なデータ量をWindowとして送信側へ通知します。送信側はACKを1つずつ待ってから次のデータを送るのではなく、Windowの範囲内で複数のデータを送信できます。
RTTが大きい高速回線では、Windowが小さすぎると回線に空きがあってもACK待ちによって十分なThroughputを出せないことがあります。
ここで説明しているWindowは、受信側が通知するReceive Window（rwnd）です。TCPの送信量はrwndだけで決まるわけではなく、送信側が輻輳制御で管理するCongestion Window（cwnd）にも制約されます。概念的には、送信側がACKを待たずに送れるデータ量はrwndとcwndの小さい方によって制約されます。
Bandwidth-Delay Productで考える
帯域とRTTの関係を考えるときに役立つのがBandwidth-Delay Product（BDP）です。
BDP = Bandwidth × RTT 例： 1 Gbps × 20 ms = 20 Mbit ≒ 2.5 MB
BDPは通信経路上に同時に存在し得るデータ量の目安として利用できます。高Bandwidth・高RTTの通信でThroughputを十分に引き出すには、TCP WindowやSocket Bufferが小さすぎないことが重要です。ただし、BDPだけで最適値が決まるわけではなく、輻輳制御、Loss、受信側の処理能力なども影響します。
Window ScalingとSocket Buffer
TCP Window Scalingは大きなWindowを利用するためのTCP拡張です。以下のパラメータを設定することで、LinuxではWindow Scalingや受信Bufferの自動調整を利用できます。
| パラメータ | 意味 | 見るポイント |
|---|---|---|
net.ipv4.tcp_window_scaling | TCP Window Scalingを有効化 | 1で有効。TCPヘッダのWindowフィールドだけでは不足する大きな受信Windowを扱えるようにする |
net.ipv4.tcp_moderate_rcvbuf | TCP受信バッファの自動調整 | 1で有効。通信状況に応じてLinuxが受信バッファを自動的に拡張する |
net.ipv4.tcp_rmem | TCP受信バッファの範囲 | min default max の3値。特に高速・高RTT環境ではmaxが十分か確認 |
net.ipv4.tcp_wmem | TCP送信バッファの範囲 | min default max の3値。大量データ送信時などに送信バッファが制約になっていないか確認 |
パラメータ設定例：
TCP Congestion Control
TCPにはネットワークの輻輳状態に応じて送信量を調整するCongestion Controlがあります。受信側が通知するReceive Window（rwnd）が受信能力による制約であるのに対し、Congestion Window（cwnd）はネットワークの輻輳状態を考慮して送信側が管理する制約です。
利用できるアルゴリズムや既定値はOS・Kernel・環境によって異なるため、特定のアルゴリズムへ変更すれば必ず高速化するとは考えません。まず現在のアルゴリズムと実際のRTT、Loss、Retransmission、Throughputを確認します。
Congestion Window（cwnd）はどのように変化するか
輻輳制御では、送信側がCongestion Window（cwnd）を調整し、ACKを待たずにネットワークへ送り出せるデータ量を制御します。基本的な考え方は、ネットワークに余裕がある間はcwndを増やし、輻輳の兆候を検知したらcwndを減らして送信量を抑える、というものです。
上図は、TCP輻輳制御におけるcwndの増減を模式的に示したものです。接続開始直後などはSlow Startによってcwndを大きく増加させ、一定の条件に達するとCongestion Avoidanceへ移行して、より慎重にcwndを増やします。
Packet Lossなどから輻輳を検知すると、送信側はcwndを減少させてネットワークへ送り出すデータ量を抑えます。その後、通信状況を確認しながら再びcwndを増加させます。この「増加 → 輻輳検知 → 減少 → 再び増加」という制御によって、TCPは利用可能な帯域を活用しつつ、ネットワークの混雑を悪化させないように送信量を調整します。
ただし、図は輻輳制御の考え方を理解するための模式図です。cwndの増加方法、輻輳の検知方法、Loss発生時にどの程度cwndを減らすかは、Reno、CUBIC、BBRなどのアルゴリズムによって異なります。例えばCUBICは単純な直線ではなく、3次関数を利用してcwndを調整します。またBBRはPacket Lossだけを主な判断材料とせず、Bottleneck BandwidthやRTTの推定値を利用して送信量を制御します。
前述したReceive Window（rwnd）と合わせると、TCPの送信量は受信側の処理能力による制約（rwnd）とネットワークの輻輳状態による制約（cwnd）の両方を受けます。そのため、高速・高LatencyのネットワークでThroughputを考える場合は、Socket BufferやReceive Windowだけでなく、Congestion Controlの動作も確認することが重要です。
| パラメータ | 意味 | 見るポイント |
|---|---|---|
net.ipv4.tcp_congestion_control | TCPで現在使用する輻輳制御アルゴリズム | cubic、reno、bbrなど。新しく確立するTCP接続で、どのアルゴリズムをデフォルトとして使用するか |
net.ipv4.tcp_available_congestion_control | Kernelで現在利用可能な輻輳制御アルゴリズムの一覧 | reno cubicなど。tcp_congestion_controlに設定できる候補を確認する |
パラメータ設定例：
| アルゴリズム | 特徴 | 輻輳の判断・制御 | 見るポイント |
|---|---|---|---|
| Reno | 古典的でシンプル | 主にPacket Lossを契機に送信量を減らす | 基本的なLoss-based方式。現在も比較対象として分かりやすい |
| CUBIC | 高速・高遅延回線でもWindowを拡大しやすい | 主にPacket Lossを契機に、3次関数（Cubic）でcwndを調整 | Linuxで広く使われる代表的な方式。今回の環境でもcubicが選択されている |
| BBR | 帯域幅とRTTを推定して送信量を制御 | 推定したBottleneck BandwidthとRTTを利用 | Lossだけに依存せず、回線の利用率と遅延を考慮して制御する |
MTUとPacket Size
MTU（Maximum Transmission Unit）は、ネットワークインターフェースで一度に送信できるIP Packetの最大サイズを示します。Ethernetでは1500 bytesが一般的ですが、環境によって異なります。重要なのは送信元だけでなく、通信経路全体で利用可能なMTUを考えることです。
Jumbo Frameは「大きければ速い」ではない
標準より大きいMTUを利用するJumbo Frameでは、同じデータ量をより少ないPacket数で転送できるため、特定の大容量転送ではCPU処理やPacket処理のオーバーヘッドを減らせる場合があります。一方、経路上の機器や対向ホストを含めてMTUを整合させる必要があります。
Jumbo Frameは「インターネットを高速化する設定」ではなく、主にStorage NetworkやVirtualization基盤など、経路全体のMTUを管理できる高速LANで効果を期待できる技術です。
| 主な用途 | 例 | 利用する理由 |
|---|---|---|
| Storage Network | iSCSI / NFS / NAS | 大容量I/OでPacket処理回数を減らす |
| Virtualization基盤 | VM移行やHost間通信 | Host間の大容量データ転送を効率化する |
| Backup | 大容量バックアップ | 連続した大容量転送のオーバーヘッドを抑える |
| Replication | Storage Replication | 管理されたネットワーク内の大容量転送に利用する |
Linuxサーバのネットワーク性能設計
前述したTCP WindowやSocket Bufferに加えて、LinuxサーバではTCP接続を受け付けるQueueとNICの処理状況も重要です。特に短時間に大量の接続が到着するシステムでは、データ転送の帯域に余裕があっても接続確立処理がボトルネックになることがあります。
SYN QueueとAccept Queue
サーバへ短時間に大量のTCP接続が到着すると、データ転送以前に接続確立処理がボトルネックになることがあります。Linuxでは、接続確立途中の状態と、接続確立後にアプリケーションがacceptするまでの状態をQueueで管理します。
関連する代表的なKernel Parameterにはnet.ipv4.tcp_max_syn_backlogとnet.core.somaxconnがあります。ただし実際のQueue上限にはアプリケーションがlisten()で指定するbacklogなども関係します。Kernel Parameterだけを増やすのではなく、接続数、Queue、アプリケーションのaccept処理能力を合わせて確認します。
| パラメータ | 関係するQueue | 意味 | 見るポイント |
|---|---|---|---|
net.ipv4.tcp_max_syn_backlog | SYN Queue | SYNを受信し、3-way handshake完了を待つ接続のQueue上限に関係する | SYNが大量に到着する環境でQueue不足が起きていないか |
net.ipv4.tcp_syncookies | SYN Queue関連 | SYN backlogがあふれる状況などでSYN Cookieを利用する防御機構 | SYN Queueの容量を増やす設定ではない。SYN floodなどでSYN backlogがあふれる状況への防御として確認する |
net.core.somaxconn | Accept Queue | listen()のbacklogに対するKernel側の上限 | Application側のbacklogを大きくしても、これが小さいと上限になる |
Applicationのlisten(backlog) | Accept Queue | Applicationが指定する待ち行列サイズ | Apache、Nginx、TomcatなどApplication側の設定も合わせて確認 |
NICの帯域とDropを確認する
サーバ側ではNIC自体も性能要素です。リンク速度だけでなく、実際の送受信量、Packet Rate、Drop、Errorを確認します。小さいPacketを大量に処理する場合は、bpsに余裕があってもppsやCPU処理が制約になることがあります。
ネットワーク機器の性能設計
Router、Switch、Firewall、Load Balancerなどを選定するときは、単一のカタログ値だけで判断しません。機器によって性能条件が異なるため、実際に利用する機能とワークロードに近い条件で評価します。
| 観点 | 確認すること |
|---|---|
| bps | 単位時間あたりに転送できるデータ量 |
| pps | 単位時間あたりに処理できるPacket数 |
| Connection | 同時接続数・新規接続数 |
| Latency | 機器通過による遅延 |
| Drop / Error | 高負荷時にPacketを失っていないか |
| 機能有効時 | Firewall、暗号化、検査などを有効にした条件で性能を満たすか |
bpsだけでなくppsを見る
同じ1Gbpsの通信でもPacket Sizeが小さければ1秒あたりに処理するPacket数は増えます。ネットワーク機器やサーバの処理能力はbpsだけでは判断できないため、Packet Rateも確認します。
Link Aggregation
Link Aggregationは複数の物理リンクを論理的に束ね、帯域拡張や冗長化に利用する技術です。ただし、単一通信が必ず複数リンクの合計帯域を使えるとは限りません。通信の振り分け方法によって特定リンクへ偏る可能性があるため、複数Flowを含む実際の通信パターンで確認します。
QoS
QoS（Quality of Service）は、通信の優先制御や帯域制御などにより、限られたネットワークリソースを用途に応じて配分する仕組みです。QoS自体が物理帯域を増やすわけではありません。どの通信を優先するかはサービス要件から決め、輻輳時に意図した制御が行われるかを試験します。
障害・縮退時のネットワーク性能設計
冗長構成では「通信が継続できること」と「必要な性能を維持できること」を分けて考えます。2系統で負荷を分散している場合、1系統が停止すると残った経路へ通信が集中します。
通常時には余裕があっても、縮退時にBandwidth、pps、Connection数、CPU、Queueなどの上限へ達する可能性があります。縮退時に通常時と同じ性能を求めるのか、一時的なレスポンスタイム悪化を許容するのかを性能要件として決め、その条件で試験します。
ネットワーク性能試験
ネットワーク性能は設定値やカタログ値だけではなく実測で確認します。単純な帯域試験だけでなく、本番の通信特性を意識して試験条件を作ります。
性能要件から合格条件を決める
性能試験では負荷をかけるだけでなく、事前に合格条件を定義します。例えば「ピーク負荷時でもResponse Timeが要件以内」「必要Throughputを維持する」「許容範囲を超えるPacket LossやRetransmissionが発生しない」「縮退時でも定めた性能を維持する」など、システムの性能要件と試験結果を対応付けます。
本番に近い条件で確認する
| 試験 | 確認すること |
|---|---|
| Throughput試験 | 必要なデータ転送量を維持できるか |
| Latency / RTT試験 | 通常時・高負荷時の遅延 |
| Loss / Retransmission | 負荷上昇時にPacket LossやTCP再送が増えないか |
| Connection試験 | 同時接続・新規接続の増加へ対応できるか |
| バースト試験 | 短時間の急増でQueueやDropが発生しないか |
| 縮退試験 | 1系統停止後も必要な性能を維持できるか |
性能試験ではアプリケーションのレスポンスタイムやスループットと同時に、Bandwidth、RTT、Loss、Retransmission、Drop、Queueなどを取得します。これにより「アプリケーションが遅くなった時刻にネットワークで何が起きていたか」を対応付けられます。
ネットワークボトルネックの確認方法
Webシステムが遅いとき、最初からTCP Parameterを変更するのではなく、症状から問題区間を絞ります。
Linuxで確認する代表的なコマンド
| 目的 | コマンド例 | 主な確認内容 |
|---|---|---|
| Interface | ip -s link | RX / TX、Drop、Error |
| 帯域・Packet | sar -n DEV | 送受信量、Packet Rate |
| Socket | ss | Connection、Socket状態、Queue |
| NIC | ethtool | Link速度、Duplex、Driver、統計 |
| TCP統計 | nstat | RetransmissionなどTCP/IP統計 |
| RTT | ping | 到達性、RTT、Lossの参考 |
| 経路 | traceroute / tracepath | 通信経路、Path MTU調査の参考 |
| Packet解析 | tcpdump | Handshake、Retransmission、RSTなど |
単一のコマンド結果だけで原因を決めつけないことが重要です。例えばpingのRTTが正常でも、特定のTCP Connectionやアプリケーション通信だけで問題が発生している場合があります。Packet CaptureでRetransmissionが見えても、どの区間でLossしたかは追加調査が必要です。
値が高い場所ではなく「待ちを作っている場所」を探す
ネットワーク性能調査の目的は、単に使用率が高いInterfaceを探すことではありません。どの制約がQueueや再送を発生させ、その待ちが利用者のレスポンスタイムへ影響しているかを確認します。帯域使用率が低くても、Packet Rateの上限、NIC Drop、FirewallのConnection処理、TCP再送などがボトルネックになる場合があります。
まとめ
- Bandwidth / Throughput：公称帯域と実際の転送量を分け、ピークやバーストも確認する。
- Latency / RTT：通信1回の遅延だけでなく、Webシステム内で何回通信するかも考える。
- Packet Loss：Loss → Retransmission → Throughput低下 → Response Time悪化という関係を見る。
- TCP：Window、BDP、Congestion Controlを理解し、設定変更より先に実際の通信を観測する。
- MTU：送信元だけでなく通信経路全体で整合性を確認する。
- Linux：Socket Buffer、Backlog Queue、NIC、Drop、TCP統計を確認する。
- ネットワーク機器：bpsだけでなくpps、Connection、Latency、機能有効時の処理能力も見る。
- 縮退時：通信できるだけでなく、残存経路で性能要件を維持できるか試験する。
- 性能調査：Bandwidth、Latency、Loss、Retransmission、Drop、Queueを時系列で対応付ける。
ネットワーク性能で重要なのは個々のParameterを最大化することではありません。想定するワークロードを必要なレスポンスタイムとスループットで安定して運べる通信経路を設計し、その状態を性能試験と運用監視で確認できるようにすることです。
参考資料
TCPやLinuxネットワークの詳細な仕様・設定値は、利用しているOS・Kernel・ネットワーク製品のバージョンによって異なる場合があります。実際の設計・変更時は対象環境の公式ドキュメントと合わせて確認してください。
Japanese 
English
コメント