動画配信システムの設計

要件と規模の見積もり

まず「どちらの動画配信か」を確定させます。YouTube型はユーザー投稿（UGC）で誰でもアップロードし本数が爆発的に増え、書き込みとトランスコードが重い。Netflix型はプロが用意した有限のカタログ（VOD）で、投稿は日次バッチに近く、支配的なのは視聴の読み取りです。両者は「アップロード＋トランスコードのパイプライン」と「配信網」を共有しますが、力点が逆なので、機能要件と非機能要件を先に固定します。

• 機能要件: 動画のアップロードとトランスコード、複数解像度でのストリーミング再生、再生位置のシーク、視聴回数などのメタデータ、検索とおすすめ。
• 非機能要件: 再生の低遅延な開始（起動2秒以内）と途切れない再生（リバッファ率を最小化）、高可用性、投稿から視聴可能になるまでの許容遅延（数分〜数十分で可）。ここで「アップロードは遅くてよいが視聴は速く」という非対称性が設計を規定します。

数値をフェルミ推定で桁まで置きます（YouTube型を主対象、根拠を明示した仮定）。

肝は読み書きの比です。投稿58本/秒に対し視聴5.8万/秒はおよそ1000倍で、視聴が完全に支配します。しかも動画1本のペイロードは記事や画像より桁違いに大きく、ピーク50Tbpsという帯域はデータセンターのオリジンから直接は供給不能です。したがって「配信はCDNのエッジで終わらせ、オリジンにはほぼ到達させない」ことが最上位の設計制約になります。

大枠の設計

全体は明確に分離した3系統で構成します。判断根拠は、それぞれ負荷特性が全く違うため独立にスケールさせたいからです。

• アップロード＆処理系: クライアント → アップロードサービス → オブジェクトストレージ（原本） → トランスコードのジョブキュー → ワーカー群 → 派生（複数ビットレート）を再びストレージへ。
• 配信系: プレーヤー → CDNエッジ（HLS/DASHのセグメントを配信、ヒット率が命） → ミスのみオリジン（ストレージ）へ。
• メタデータ系: 動画メタ・視聴回数・ユーザー・おすすめのためのDB群と、検索インデックス。

APIは最小限、次の形にします。アップロードは巨大ファイルなので、サーバーを経由させず署名付きURLでオブジェクトストレージへ直接、かつ分割（マルチパート）で送らせるのが定石です。

POST /videos                      -> 動画IDを発番、メタデータの器を作成
POST /videos/{id}/upload-url      -> 署名付きの分割アップロードURLを返す
                                     （クライアントがストレージへ直接PUT）
POST /videos/{id}/complete        -> 全パート完了を通知、トランスコード起動
GET  /videos/{id}                 -> メタデータとマニフェストURLを返す
GET  /videos/{id}/master.m3u8     -> 解像度一覧のマスタープレイリスト（CDN経由）

データモデルは、可変で頻繁に更新される数値（視聴回数）と、不変に近い実体（動画メタ）を分けます。視聴回数のような高頻度カウンタをリレーショナルDBの1行で更新すると行ロックが競合するため、書き込みに強いストアへ寄せます。

メタデータの水平分割（シャーディング）は video_id をキーにします。動画は互いに独立で結合をまたぐ必要が薄く、キー分散で素直にスケールするからです。分割方式の選び方はシャーディング戦略、ノード増減時の再配置を最小化する割り当てはコンシステントハッシュ法を前提にします。

主要コンポーネントの深掘り

トランスコードのファンアウト。 1本の原本を複数の解像度・ビットレート（例: 240p/480p/720p/1080p/4K）へ変換します。ここでの鍵は、動画を数秒単位のチャンクに切ってから並列変換することです。10分の動画を1本のワーカーで直列に全解像度エンコードすると分単位で待たされますが、6秒チャンクへ分割すれば数百の断片を数百ワーカーで同時処理でき、投稿から視聴可能までの遅延が桁で縮みます。処理はDAG（有向非巡回グラフ）として組みます。分割 → 各チャンク×各解像度のエンコード（ここが最大のファンアウト） → セグメント化とプレイリスト生成 → サムネイル抽出、の順に依存します。

ジョブ配分はメッセージキューで行い、ワーカーはプリエンプティブルな計算資源で安く回します。ここで配信保証の設計判断が要ります。トランスコードは冪等（同じ入力から同じ出力）に作れるので、少なくとも一度（at-least-once）で配送し、重複実行は出力の上書きで吸収するのが実務的です。配信セマンティクスの整理はメッセージキューの配信保証を参照してください。

HLS/DASHによるアダプティブ配信。 変換結果は「マニフェスト（プレイリスト）」と「セグメント」に分けて置きます。マスタープレイリストが解像度の一覧を示し、各解像度のメディアプレイリストが数秒ごとのセグメント（.ts や fMP4）を列挙します。

master.m3u8
├─ 480p/index.m3u8  ├─ seg0.ts, seg1.ts, ...（各6秒）
├─ 720p/index.m3u8  ├─ seg0.ts, seg1.ts, ...
└─ 1080p/index.m3u8 └─ seg0.ts, seg1.ts, ...

アダプティブビットレート（ABR）の本質は、切り替え判断がサーバーではなくプレーヤー側にあることです。プレーヤーは直近セグメントのダウンロード速度と再生バッファの残量を監視し、次に取得するセグメントの解像度を毎回選び直します。帯域が細ればより低いビットレートへ、バッファに余裕が戻れば上げる。セグメントを短く（6秒前後）固定するのは、切り替えの粒度を細かくしつつ、リクエスト数の増加とのバランスを取るためです。HLSとDASHは思想はほぼ同一で、コンテナと対応環境が違います。

CDNとエッジキャッシュ。 50Tbpsのピークをオリジンへ通さない仕組みがここです。セグメントは不変（一度作れば書き換えない）なのでキャッシュに極めて向きます。人気動画の冒頭セグメントほど繰り返し要求されるため、エッジのヒット率は容易に95%を超えられます。到達経路の制御はDNSやAnycastで最寄りエッジへ誘導し、エッジミス時のみ上位キャッシュ、最後にオリジンという多段構成にします。CDNの内部動作はCDN、エッジや前段での負荷分散はL4ロードバランサの内部を土台にします。Netflix型では、需要予測に基づき人気タイトルを深夜のうちにISP網内のキャッシュ（Open Connect相当）へ先回りで押し込む「事前配置」も併用し、ピーク時のオリジン負荷をほぼゼロにします。

メタデータとおすすめ。 おすすめは大きく2段です。まず候補生成で数百万本から数百本へ荒く絞り（協調フィルタリングや、視聴履歴を埋め込みベクトル化した近傍探索）、次にランキングで機械学習モデルが視聴継続確率などを推定して並べ替えます。候補生成を近傍探索に寄せるのは、全カタログのスコア計算が計算量的に非現実的だからです。特徴量やモデルの学習パイプラインはAIの領域と重なります。

ボトルネックとトレードオフ

横にスクロール

スケール時に効いてくる論点を、代替案の比較で押さえます。

視聴回数カウンタのホットスポット。 バズった動画は毎秒数万の加算が1キーに集中し、単純な行更新では競合します。厳密な即時一致を諦め、エッジやアプリ層で一定時間バッファして周期的にフラッシュする「近似カウント＋非同期集計」にします。視聴回数はビジネス上、多少の遅延や誤差が許容される代表例で、正確性より書き込みスループットを優先する判断です。書き込み最適化ストアの内部はLSMツリーを参照。

ストレージ階層とコスト。 全動画を高速ストレージに置くのは非現実的で、アクセス頻度で階層化します。ロングテール（大多数の動画はほとんど見られない）という視聴分布を前提に、視聴減衰に応じてホット→ウォーム→コールドへ自動で移送します。

強整合か可用性か。 動画配信は視聴の可用性を最優先し、多くの箇所で結果整合を選びます。投稿直後に世界中で同時に見えなくても、数分の伝播遅延は許容されます。この判断の理論的背景はCAP定理にあり、分断時に一貫性より可用性を取る典型です。一方で課金や視聴権限のように誤りが許されない領域だけは強整合を守り、系統ごとに整合性レベルを使い分けます。

分散システム全般の基盤はデータベース、配信網とプロトコルはネットワーク、運用とデプロイはDevOpsの各トピックも併せて参照してください。