TCP BBR 輻輳制御を本番カーネルへ段階投入｜帯域改善の計測と切り戻し手順

TCP BBR とは――輻輳制御の仕組みを最低限押さえる

TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）は、Google が2016年に発表し Linux カーネル 4.9 でメインラインにマージされた輻輳制御アルゴリズムです。長年の標準だった CUBIC がパケットロスを輻輳シグナルとして扱うのに対し、BBR はボトルネックリンクの帯域幅と RTT（往復遅延）を継続的に推定し、バッファを無駄に積み上げずに最大スループットを狙う設計です。

CUBIC 環境では、ルーターやスイッチのバッファが深いほどキューが膨らみ続け、遅延が増大する「バッファブロート」が発生しやすくなります。BBR はこの問題を構造的に回避しようとするため、広域 WAN・高遅延回線・CDN エッジなど、パケットロスが少なくても RTT が大きいシナリオで効果が出やすいとされています。

ただし、同一リンクを CUBIC と BBR が共存して使う環境では帯域の取り合いが偏ることが実測で確認されており、全サーバーを一斉に切り替えるのではなく段階的に投入する理由の一つになっています。本記事ではこの段階投入の実務手順を中心に解説します。

有効化前の確認事項――カーネルバージョンとディストリビューション

BBR を使うにはカーネル 4.9 以上が必要です。まず稼働中のカーネルバージョンを確認します。

uname -r

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

modprobe tcp_bbr
lsmod | grep bbr

tcp_bbr と表示されれば利用可能です。表示されない場合はカーネルアップグレードが必要です。

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

• Ubuntu 22.04 LTS / 24.04 LTS：カーネル 5.15・6.8 標準搭載。BBR はモジュールとして利用可能
• Debian 12（bookworm）：カーネル 6.1 標準搭載。同様に利用可能
• RHEL 9 / AlmaLinux 9 / Rocky Linux 9：カーネル 5.14 系。BBR は利用可能だが、BBR v3 は別途対応を要する
• Amazon Linux 2023：カーネル 6.1 系。BBR は標準で利用可能

また、現在の輻輳制御アルゴリズムを確認しておきます。切り戻し時の基準になります。

sysctl net.ipv4.tcp_congestion_control
# 例: net.ipv4.tcp_congestion_control = cubic

sysctl による段階的な有効化手順

本番環境への投入は、まず1台のサーバーで一時的に有効化して計測し、問題がなければ設定ファイルへの永続化・他サーバーへの展開という流れが基本です。

ステップ 1：1台で一時的に有効化する

まずモジュールを読み込み、実行時のみ有効な設定として BBR に切り替えます。再起動すると元に戻るため、影響を試すのに適しています。

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq

net.core.default_qdisc=fq（Fair Queue）は BBR と組み合わせることが公式推奨です。BBR はパケットのペーシング（送出間隔の制御）に依存しており、fq がそれを担います。pfifo_fast のままでも動作はしますが、BBR 本来のパフォーマンスを引き出せないため、必ず合わせて設定します。

ステップ 2：計測・検証（次節で詳述）

一時有効化後に後述の計測を行い、スループットや RTT に問題がないことを確認します。

ステップ 3：永続化と他サーバーへの展開

問題がなければ /etc/sysctl.d/ 以下に設定ファイルを作成して永続化します。

cat <<'EOF' > /etc/sysctl.d/10-tcp-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF

sysctl --system

Ansible や Salt などの構成管理ツールを使っている場合は、このファイルをロールに組み込み、ステージング環境・一部の本番ノード・全本番ノードという順で段階的にデプロイするのが一般的な進め方です。一度に全台を切り替えると問題発生時の切り分けが難しくなります。

帯域改善を計測する――ss・iperf3 の活用

設定変更後は、実際にアルゴリズムが切り替わっていることと、スループットの変化を確認します。

アルゴリズムの適用確認

ss コマンドで確立済みの TCP セッションが BBR を使っているか確認できます。

# 確立済みセッションの輻輳制御アルゴリズムを表示
ss -tin dst :443 | grep -i bbr

出力に bbr が含まれていれば、新規コネクションに BBR が適用されています。sysctl で変更した直後は既存コネクションには適用されず、新規に張られたコネクションから順に切り替わります。

iperf3 によるスループット計測

スループットの変化を定量的に把握するには、同一経路で CUBIC と BBR の双方を計測して比較します。想定例として、同一 VPC 内のサーバー同士でテストする場合の手順は以下のとおりです。

# サーバー側（受信）
iperf3 -s

# クライアント側（送信）：30秒間計測
iperf3 -c <サーバーIP> -t 30 -P 4

比較は「同一時間帯・同一経路」で行うのが基本です。広域 WAN 経由のテストでは時間帯によって回線の混雑状況が変わるため、CUBIC と BBR のテストをなるべく近い時刻に実施します。また、-P 4（並列ストリーム数）は実際のアプリケーションのコネクション数に近い値に合わせると、より実態に即した結果が得られます。

ss の詳細情報で RTT とバッファの変化を見る

スループットに加えて RTT とバッファの状態を確認します。

ss -tin | grep -A2 bbr | head -40

rtt（平均 RTT）と snd_wnd（送信ウィンドウ）の値を CUBIC 時と比較します。バッファブロートが改善している場合、rtt が低下していることが多いです。

切り戻し手順と本番投入前の注意点

即時切り戻し（再起動不要）

問題が発生した場合、再起動なしで元のアルゴリズムに戻せます。

sysctl -w net.ipv4.tcp_congestion_control=cubic

この変更も既存コネクションには適用されず、新規コネクションから反映されます。多くの場合は数分待てばほぼすべてのセッションが切り替わります。

永続設定の削除

次回起動時の反映も止めるには、先ほど作成したファイルを削除し、設定を再読み込みします。

rm /etc/sysctl.d/10-tcp-bbr.conf
sysctl --system

よくあるつまずきと注意点

• qdisc を変更し忘れる：BBR に切り替えても net.core.default_qdisc が pfifo_fast のままだと、ペーシングが機能せず期待したスループット改善が出ないことがあります。セットで設定する習慣をつけてください。
• CUBIC と混在するセグメントでの公平性：一般的には、同じ制約リンクを CUBIC と BBR が競合する場合、BBR が帯域を多く占有する傾向が報告されています。エンドポイント全体を段階的に揃えていく理由の一つです。
• コンテナ・VM 環境：ホストの sysctl 設定はコンテナ内のネームスペースに引き継がれますが、cgroup や仮想 NIC のドライバーによって qdisc の扱いが異なる場合があります。Kubernetes ノードで変更する際は、ノードごとに設定が反映されているか kubectl debug node 等で確認してください。
• クラウドプロバイダーの制約：一部のクラウド環境では、仮想 NIC レイヤーで独自の帯域制御が入るため、BBR の効果が LAN 環境と異なる場合があります。まずステージング環境で計測データを取ってから本番に適用するのが確実です。

2026年時点の BBR バージョン動向と主要ディストリの対応状況

BBR はバージョン 1（v1）以降も開発が続いており、2026年時点では v3 がメインラインカーネルへのマージを経て実用段階に入っています。

BBR v1（カーネル 4.9～）は安定して広く使われており、現在も多くのプロダクション環境の標準です。BBR v2 は v1 の公平性問題（CUBIC との競合）を改善する目的で開発されましたが、メインラインマージには至らず、パッチとして流通した経緯があります。BBR v3 は v2 の知見を取り込みつつ再設計されたもので、2023年から 2024年にかけて Google が発表し、Linux 6.3～6.5 系へのマージ議論が進んだ結果、2025年以降の一部ディストリビューションカーネルに取り込まれ始めています。

2026年現在の実用上の判断基準は以下のとおりです。

• 安定性を最優先する場合：カーネル 5.x・6.x 付属の BBR v1 を使う。実績が最も多く、デフォルト構成での挙動が予測しやすい。
• 公平性を改善したい場合：BBR v3 が含まれるカーネル（Ubuntu 24.04 の HWE カーネルや自前ビルドの 6.6 以降）への移行を検討する。ただし本番適用前に自環境での計測が必須。
• RHEL 系：RHEL 9 / AlmaLinux 9 / Rocky Linux 9 はカーネル 5.14 系のため、BBR v3 はデフォルトでは含まれません。BBR v3 を使うには ELRepo 等のサードパーティカーネル、または RHEL 10（カーネル 6.x 系）への移行が必要です。

稼働中のサーバーで BBR のバージョンを確認する直接的なコマンドはなく、カーネルバージョンとディストリビューションのリリースノートから判断するのが現実的です。uname -r でカーネルバージョンを把握し、そのカーネルのソース（net/ipv4/tcp_bbr.c）や Changelog を参照することで、どの実装が含まれているかを確認できます。

TCP BBR の段階投入は、カーネルアップグレードを伴わない sysctl 変更だけで始められる点が運用上の利点です。まず1台で一時有効化して計測データを取り、問題がなければ構成管理ツールで順次展開する流れを守れば、切り戻しコストを低く抑えながら帯域改善の効果を検証できます。