Netflixがライブ配信にVBRを全面導入した理由と、そこから学ぶインフラ安定性の教訓

はじめに：CBRからVBRへの移行、単なる設定変更ではない

2026年1月、Netflixはすべてのライブイベントのエンコード方式を従来のCBR（Constant Bitrate）からVBR（Variable Bitrate）に切り替えました。一見すると設定値を一つ変えただけのように見えますが、実際にはライブビデオ配信パイプラインの根本的な前提を見直す大規模エンジニアリングプロジェクトでした。

CBRとVBRの本質的な違い

• CBR: すべてのシーンに同一のビットレートを割り当てる。トラフィック予測は容易だが、単純なシーンでは無駄なビットを消費し、複雑なシーンでは品質が低下する。
• VBR: シーンの複雑さに応じてビットレートを動的に調整。効率性は高いが、トラフィック変動が大きくなり、サーバーやCDNの負荷予測が困難になる。

本記事では、Netflixがこの移行プロセスで直面した技術的課題と解決策を分析し、日本の開発者が実務のインフラ設計に応用できる教訓をまとめます。

参考背景資料: 本内容はNetflix Tech Blogの原文を基に分析しました。

VBR導入の技術的課題と解決策

1. 効率性と安定性のジレンマ

VBRの最大の利点は効率性です。単純なシーン（例：スタジオの進行役）ではビットレートを大幅に下げ、複雑なシーン（例：WWEの花火シーン）では高いビットレートを割り当てます。NetflixのA/Bテスト結果では、VBR導入により平均15%のトラフィック削減と約5%のリバッファリング低減効果が得られました。

しかし、ここに落とし穴があります。単純なシーンが長く続くと、サーバーの現在トラフィックが低くなり「余裕がある」と誤判断します。するとロードバランサーがさらに多くのセッションを割り当て、突然複雑なシーンに切り替わった際にビットレートが2〜3倍に急増し、サーバーが過負荷に陥る現象が発生します。

2. Netflixの解決策：公称ビットレートベースの容量予約

Netflixはこの問題を解決するため、現在のトラフィックではなく公称ビットレート（nominal bitrate）を基準にサーバー容量を予約する方式を採用しました。

# 概念的な疑似コード：VBR対応サーバー容量予約ロジック
class ServerCapacityManager:
    def __init__(self, max_bandwidth_gbps: float):
        self.max_bandwidth = max_bandwidth_gbps * 1_000  # Mbpsに変換
        self.reserved_capacity = 0.0  # 現在予約済みの総ビットレート（Mbps）
    
    def can_accept_session(self, stream_nominal_bitrate_mbps: float) -> bool:
        """
        VBRストリームの現在ビットレートが低くても、
        公称ビットレートを基準に予約して安定性を確保
        """
        if self.reserved_capacity + stream_nominal_bitrate_mbps <= self.max_bandwidth:
            return True
        return False
    
    def reserve_session(self, stream_nominal_bitrate_mbps: float):
        self.reserved_capacity += stream_nominal_bitrate_mbps
    
    def release_session(self, stream_nominal_bitrate_mbps: float):
        self.reserved_capacity -= stream_nominal_bitrate_mbps

このアプローチはCBR環境では馴染み深いものですが、VBRではさらに重要になります。「現在のトラフィックが低いから大丈夫だろう」という安易な考えを防止します。

3. 品質マッチング：VBRビットレートラダーの再調整

VBRは同じ公称ビットレートでもCBRより平均ビットレートが低くなることがあります。NetflixはVMAF（ビデオ品質メトリクス）を基準にCBRとVBRの品質を比較し、低ビットレート階層でのみ公称ビットレートを小幅に上方調整する戦略を取りました。

# VBRビットレートラダー調整ロジック（概念例）
# CBRラダー: [(解像度, 公称ビットレート), ...]
cbr_ladder = [
    (4320, 0.5),   # 432p, 0.5 Mbps
    (5760, 1.0),   # 576p, 1.0 Mbps
    (720,  2.5),   # 720p, 2.5 Mbps
    (1080, 5.0),   # 1080p, 5.0 Mbps
]

def adjust_vbr_ladder(cbr_ladder, vmaf_threshold=1.0):
    """
    CBRに対するVMAF差が閾値を超えた場合、
    該当階層のVBR公称ビットレートを増加
    """
    vbr_ladder = []
    for resolution, nominal_bitrate in cbr_ladder:
        vmaf_cbr = measure_vmaf('cbr', resolution, nominal_bitrate)
        vmaf_vbr = measure_vmaf('vbr', resolution, nominal_bitrate)
        
        if vmaf_cbr - vmaf_vbr > vmaf_threshold:
            # 低階層のみビットレート増加
            adjusted_bitrate = nominal_bitrate * 1.15  # 15%増
            vbr_ladder.append((resolution, adjusted_bitrate))
        else:
            vbr_ladder.append((resolution, nominal_bitrate))
    return vbr_ladder

これにより、高ビットレート階層はほとんど変更せず、低ビットレート階層のみ調整することで、全体的なトラフィック利益を維持しました。

技術の限界と注意点

VBR導入時の一般的な落とし穴

• すべてのコンテンツにVBRが最適とは限らない: ニュース速報や証券放送のように画面変化が少ないコンテンツでは、CBRの方が効率的な場合があります。
• プレイヤー互換性: 一部の古いデバイスやブラウザはVBRの急激なビットレート変化に適応できない可能性があります。ABR（Adaptive Bitrate）アルゴリズムの改善が必要です。
• 運用複雑性の増加: VBR導入後は、トラフィック監視ダッシュボードのしきい値を再設定する必要があります。単に「現在の帯域使用率80%」という指標だけではサーバー状態を判断できません。

次のステップとしての学習方向

• ABRアルゴリズムの深掘り: VBR環境に最適化された適応型ビットレートアルゴリズム（BOLA、MPCなど）を学習しましょう。
• ビデオ品質メトリクス: VMAF、PSNR、SSIMなどの客観的品質測定手法の理解を深めましょう。
• CDNアーキテクチャ: エッジサーバーでのVBRトラフィック処理のためのキャッシュ戦略とロードバランシング技術を研究しましょう。

合わせて読みたい記事

• AIエージェントのためのPostgresデータベースGhostで100倍高速プロトタイピング
• Gemini 3で見る現実的なAIエージェント6つのオープンソースフレームワーク実践ガイド

まとめ：実務に活かせる核心的な教訓

NetflixのVBR移行事例から得られる最も重要な教訓は、「効率性は安定性とトレードオフの関係にあり、そのバランスを取るエンジニアリングが重要である」 という点です。

1. 容量予約は保守的に: 現在のトラフィックが低いからといって、サーバーに余裕があると判断しないでください。VBR環境では公称ビットレートベースの予約が安全です。
2. 品質メトリクスを基準に調整: 単にビットレートの数値を合わせるのではなく、最終ユーザー体験（VMAF、リバッファリング率など）を基準に判断しましょう。
3. 段階的ロールアウト: NetflixのようにA/Bテストで影響を測定し、問題が見つかった部分のみ調整する戦略を採用しましょう。

VBRはライブストリーミングの効率を劇的に向上させる一方で、インフラ運用の複雑さも増します。本記事で紹介した教訓を参考に、自身のプロジェクトで適切なバランスを見つけてください。