数百台のLinuxサーバーを管理してきた中で、ある共通の不満に気づきました。それは、理論上は「高速」なギガビット接続であるはずなのに、ファイル転送が遅かったりWebアプリの動作がもたついたりするというものです。多くの場合、ボトルネックはハードウェアやプロバイダーではなく、Linuxのデフォルトのネットワーク混雑制御の仕組みにあります。
ほとんどのディストリビューションは、今でもCUBICというアルゴリズムに依存しています。これは、パケットロスが発生するとネットワークが完全に過負荷状態であると判断し、即座にブレーキをかける、古い時代の設計に基づいています。しかし、現代のネットワークはそれほど単純ではありません。そこで登場するのがGoogle BBRです。
BBRは「Bottleneck Bandwidth and Round-trip propagation time（ボトルネック帯域幅および往復伝搬時間）」の略です。パケットがドロップするまで待ってから減速するCUBICとは異なり、BBRはネットワークのリアルタイムモデルを構築します。常に実際の実効最大スループットと最小遅延を探索し続けます。BBRの習得は、特に高遅延や微細なパケットロスが常態化しているグローバルなトラフィックを扱う現代のシステム管理者にとって、不可欠なスキルです。
クイックスタート：2分以内にBBRを有効にする
Ubuntu 22.04、Debian 11以降、あるいはRHEL 9のような最新のディストリビューションを使用している場合、カーネルはすでにBBRをサポートしています。スイッチを切り替えるだけで完了です。私は新しいサーバーをデプロイする際、以下の4つのステップで最適化を行っています。
ステップ1：カーネルバージョンの確認
BBRを利用するには、Linuxカーネルのバージョンが4.9以上である必要があります。以下のコマンドを実行して確認してください：
uname -r5.15.x や 6.1.x といったバージョンが表示されれば準備は万端です。現在のほとんどのVPSプロバイダーは、すでに4.x系よりも新しいバージョンに移行しています。
ステップ2：利用可能なアルゴリズムの確認
現在のシステムでサポートされているアルゴリズムを確認するには、次のコマンドを実行します：
sysctl net.ipv4.tcp_available_congestion_control通常、出力には reno cubic と表示されます。もし bbr がリストにない場合は、モジュールがロードされていないことを意味しますが、最近の商用カーネルのほとんどには組み込まれています。
ステップ3：BBRの有効化
最良の結果を得るために、デフォルトのキューイング規則（qdisc）を fq (Fair Queuing) に設定します。BBRはパケットの送出間隔を正しく制御するためにこれを必要とします。以下の行を /etc/sysctl.conf ファイルに追加してください：
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf変更を即座に適用します：
sudo sysctl -pステップ4：有効化の確認
BBRがアクティブであることを確認します：
sysctl net.ipv4.tcp_congestion_controlbbr と返ってくれば完了です。高遅延の接続環境では、即座にスループットの向上が実感できるはずです。
ディープダイブ：なぜBBRが革新的なのか
BBRの価値を理解するには、現代のネットワーク回線においてなぜCUBICが力不足なのかを知る必要があります。CUBICは「ロスベース（損失ベース）」のアルゴリズムです。パケットロスが発生すると、即座に回線が混雑しているとみなし、送信速度を一気に（多くの場合50%も）落とします。しかし、現代の光ファイバーや長距離回線では、混雑以外の多くの理由でパケットがドロップします。そのため、CUBICは過剰に慎重になり、膨大な帯域幅を使い残してしまうのです。
BBRはランダムなパケットドロップを無視します。代わりに、受信確認（ACK）が返ってくる実際のレートを測定します。これにより、真のボトルネックと一時的な不具合を区別できるのです。私が1.5%のパケットロスがある100Mbpsの回線でテストした際、CUBICはわずか12Mbpsで頭打ちになりましたが、BBRに切り替えると88Mbpsまで回復しました。設定ファイルを変更するだけで、実に7倍もの改善が得られたのです。
これを高速道路の運転に例えてみましょう。CUBICは、3台前の車がブレーキを踏むたびにパニックブレーキをかけるドライバーです。対してBBRは、交通全体の流れを観察し、常に一定かつ最適な速度を維持するドライバーと言えます。
高度なモニタリングとBBRv3
私は「ブラックボックス」のような最適化は好みません。 ss (socket statistics) コマンドを使えば、BBRがアクティブな接続をどのようにモデル化しているかを正確に把握できます：
ss -tinbw (bandwidth) と mrtt (min RTT) の値に注目してください。 bw がプロバイダーの公称速度に近い値であれば、BBRは完璧に機能しています。
初期のBBRは画期的な一歩でしたが、時に「欲張りすぎる（greedy）」と批判され、CUBICのトラフィックを圧迫することがありました。Googleはこの問題に BBRv3 で対処しました。まだ多くのカーネルで標準採用されてはいませんが、XanModカーネルや最新のローリングリリースで見つけることができます。高ロス環境での安定性が大幅に向上し、「公平性」も改善されています。
本番環境向けのプロのアドバイス
- 「Long Fat Pipe」シナリオ： BBRは、ニューヨークとシンガポール間の1Gbps回線のような, 高遅延の接続において驚異的な効果を発揮します。逆に、遅延が0.1ms程度のローカルな10Gbps LANでは、違いはほとんど感じられません。
- 常に fq を使用する： BBRがデータを適切にペース配分するには
fqが不可欠です。これがないとマイクロバースト（微小なパケットの塊）が発生し、安価なスイッチをパンクさせて、回避しようとしていた混雑を自ら引き起こしてしまいます。 - VPNの魔法： ネットワークの制限を回避するためにVPNやShadowsocksなどのプロキシを使用している場合、BBRは秘密兵器になります。OpenVPNトンネルの実効速度が一晩で2倍になったケースを何度も見てきました。
- スムーズな動画視聴： CUBICは速度が「のこぎり状」に変動するため、頻繁にバッファリングが発生します。BBRはフラットで安定したフローを提供するため、ストリーミングプラットフォームに最適です。
BBRは、期待通りの成果を確実にもたらしてくれる数少ない最適化手法の一つです。私のサーバーセキュリティ・最適化チェックリストの標準項目になっています。サーバーと世界との通信を現代化しましょう。1ミリ秒を争う業界において、これを無効のままにしておく手はありません。
