TCP 輻輳制御を本番 Linux で BBR に切り替える｜アルゴリズム選択の判断基準と性能差の計測・切り戻し

CUBIC が抱える課題と BBR が注目される背景

Linux のデフォルト TCP 輻輳制御アルゴリズムは長らく CUBIC が採用されてきました。CUBIC はパケットロスを輻輳の主要シグナルとして扱い、ウィンドウサイズを積極的に拡大しながら帯域を探索するロスベースのアルゴリズムです。データセンター内のような低遅延・低ロス環境では十分に機能しますが、高レイテンシ回線や無線・モバイル回線のようにパケットロスが輻輳以外の要因でも発生する環境では、不必要なウィンドウ縮小が頻発するという課題があります。

BBR（Bottleneck Bandwidth and Round-trip propagation time）は Google が 2016 年に公開したモデルベースのアルゴリズムです。ロスではなく「ボトルネック帯域幅」と「最小 RTT」の推定値を組み合わせて送信レートを決定するため、バッファが肥大化する前に輻輳を検知できます。公開当初から YouTube のスループット改善事例が広く知られ、2026 年現在では国内のクラウド・CDN・ゲームサーバー運用でも採用事例が増えています。

アルゴリズム選択の判断基準――どんな環境で BBR が効くか

BBR への切り替えを検討する前に、自環境が BBR の恩恵を受けやすいかを見極めることが重要です。以下の特徴に複数あてはまる場合は切り替えの優先度が高いといえます。

• エンドユーザーとの RTT が 50ms を超えるグローバル配信サービス
• モバイル回線やサテライト回線など、非輻輳起因のパケットロスが常態化する経路
• 単一フローの最大スループットよりもフロー多重化時の公平性と安定性を重視する構成
• バッファブロート（ルーターのキューが過剰に積み上がる現象）による遅延スパイクが計測されている

一方、以下の条件では CUBIC のままが安全な場合があります。同一データセンター内の East-West トラフィックが中心で RTT が数ミリ秒以下の場合、BBR の帯域推定が過剰に積極的になり、同居するフローとの公平性が崩れる報告があります。また、古いカーネル（4.9 未満）では BBR モジュール自体が存在しないため、カーネルの更新を先行させる必要があります。

本番環境での切り替え手順

カーネルモジュールの確認と有効化

まず BBR モジュールがカーネルに組み込まれているかを確認します。

uname -r
modinfo tcp_bbr

modinfo がモジュール情報を返せば BBR は利用可能です。動的ロードが必要な場合は modprobe tcp_bbr を実行します。再起動後も自動ロードされるよう /etc/modules-load.d/bbr.conf に tcp_bbr の1行を追加しておきます。

sysctl による永続設定

アルゴリズムの切り替え自体は sysctl 2 パラメーターで完結します。

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

現在値を確認したうえで、/etc/sysctl.d/99-bbr.conf を新規作成して以下を記述します。

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

fq（Fair Queuing）は BBR との組み合わせで推奨されるキューイングディシプリンです。BBR は送信ペーシングを前提とした設計になっており、fq がそのペーシングを正確に実現します。設定を即時反映するには sysctl --system を実行します。ファイルに書くことで再起動後も永続化されます。

反映確認は次のコマンドで行います。

sysctl net.ipv4.tcp_congestion_control
ss -i | grep bbr

ss -i の出力に bbr の文字列が現れれば、既存セッションも含めて BBR が動作していることが確認できます。なお、設定変更は新規に確立される TCP セッションから適用されます。既存の長期セッションは sysctl --system 実行直後には影響を受けないため、ロードバランサー配下のサービスでは新旧アルゴリズムが混在する時間帯が生じることを念頭に置いてください。

切り替え後の性能差を計測する

切り替えの効果を定量的に把握するためには、切り替え前後の計測が欠かせません。現場でよく使われるのは iperf3 による帯域計測と、ss --extended によるセッション単位の RTT・再送数の観察です。

iperf3 を使う場合は、実際のユーザー経路に近いネットワーク上でサーバー・クライアントを立て、複数フローを同時に流します。1フローだけの計測はピーク帯域の比較には使えますが、多重化時のフロー間公平性は見えません。並列フロー数を 4〜8 に設定して RTT とスループットの両方を記録することを推奨します。

アプリケーション層での観察には tc -s qdisc show dev eth0 でキューのドロップ数を確認する方法があります。BBR 導入後にキュードロップが減少し、かつスループットが向上しているなら切り替えは成功していると判断できます。逆にドロップが増加する場合は、NIC のリングバッファ設定や fq の quantum 値の調整が必要になるケースもあります。

Prometheus + Node Exporter を使っている環境であれば、node_netstat_TcpExt_TCPRetransFail や node_netstat_Tcp_RetransSegs の推移をグラフ化することで、切り替え前後の再送率変化をダッシュボードで継続監視できます。

切り戻し手順と運用上の注意点

BBR への切り替えが思わしくない結果をもたらした場合、切り戻しは設定ファイルの削除（または変更）と sysctl --system の再実行で完了します。

rm /etc/sysctl.d/99-bbr.conf
sysctl --system
sysctl net.ipv4.tcp_congestion_control  # cubic に戻っていることを確認

切り戻しは即座に実行できますが、運用上いくつかの注意点があります。まず、カーネルのバージョンによっては BBR v1 の実装にバグが確認されているケースがあります。特に 4.9〜4.14 系では特定条件下での誤ったウィンドウ推定が報告されており、本番投入前にカーネルのマイナーバージョンに対するバグ情報を調査することを強くお勧めします。

次に、コンテナ環境（Docker・Kubernetes）では、ホスト OS の sysctl 設定がネームスペースを越えて共有される点に注意が必要です。Pod 単位で net.ipv4.tcp_congestion_control を上書きしている場合は、ホスト設定との優先関係を明示的に整理しておきます。セキュリティポリシーによっては Pod 側からの sysctl 変更が制限されているクラスターもあるため、変更の権限と影響範囲を事前に確認してください。

また、TCP フェアネスの問題として、BBR フローと CUBIC フローが同一ボトルネックリンクを共有する場合に CUBIC フローが不利になるという研究報告があります。自社サービスだけでなく、同じ上流 ISP を使う他テナントへの影響も含め、大規模なトラフィックを扱う運用者は特に意識しておく必要があります。

2026年現在の環境差分――BBRv3 と主要ディストリビューションの動向

2026年9月時点での主要ディストリビューションと BBR の対応状況は以下のとおりです。

Ubuntu 24.04 LTS はカーネル 6.8 系をデフォルトで採用しており、BBR v1 モジュールが標準搭載されています。Google が開発を続ける BBR v3 は 2025 年末にメインラインカーネル（6.13 前後）へのマージ提案が進んでおり、Ubuntu 25.10 以降や HWE カーネルを使用している環境では BBR v3 が選択肢に入ります。BBR v3 は v1 に比べてフロー間の公平性が改善され、CUBIC フローとの共存性が向上しているとされています。

RHEL 9 系（AlmaLinux 9・Rocky Linux 9 を含む）はカーネル 5.14 ベースであり、BBR v1 が利用可能です。RHEL 10 は 2025 年にリリースされ、カーネル 6.11 系を採用しているため、こちらも BBR v1 が標準で使えます。エンタープライズサポートを重視する環境では RHEL 系の KPATCH や Extended Kernel での適用も選択肢となります。

Debian 12（Bookworm）はカーネル 6.1 系で BBR v1 が利用可能です。Debian 13（Trixie）はカーネル 6.12 系が採用される見込みであり、BBR v3 へのアクセスがより容易になると期待されています。

クラウドマネージドサービスの観点では、AWS EC2 や GCP Compute Engine のデフォルトカーネルが BBR を有効化済みのケースが増えています。特に Google Cloud は自社ネットワーク全体で BBR を標準的に使用しており、インスタンス側でも BBR が推奨設定とされています。マネージドサービスを使用している場合は、プロバイダーのドキュメントで推奨設定を確認したうえで上書き設定を検討してください。

カーネルの更新なしに BBR v3 を試したい場合は、Google が公開している BBR v3 パッチセットを自前ビルドする方法もありますが、本番環境への適用にはサポートポリシーとの整合性を十分に確認することが前提となります。ディストリビューション標準のカーネルが BBR v3 に対応するタイミングを待ち、その際に改めてアルゴリズムを評価し直すというアプローチが、多くの運用者にとって現実的な選択肢といえるでしょう。