コンテンツにスキップ

YouTubeアーキテクチャ（日本語訳）

YouTube Architecture

多くの「YouTubeアーキテクチャ」記事は、システム設計のファンフィクションになりがちです。 この文章は、公開情報で正当化できる範囲にだけ絞っています。

  • Google / YouTube / Google Cloud の資料
  • Googleエンジニアの論文
  • Vitessメンテナのドキュメント
  • YouTube配信ネットワークの測定研究

根拠が薄い部分は、その旨を明記します。

規模感

YouTubeは、GoogleのMedia CDNを支えるグローバル基盤上で、20億人以上のユーザーにサービスを提供しています。 そのネットワークは200以上の国・地域、1,300以上の都市に広がっています。 YouTubeのレコメンドシステムは、Google自身が「産業界で最も大規模かつ高度なレコメンダの1つ」と述べています。 グローバルにバイトを動かすサービスを作るなら、YouTubeは参照アーキテクチャです。

TL;DR

YouTubeは次の組み合わせです。

  • フロントエンドアプリ + Borg上のバックエンドマイクロサービス
  • シャーディングされたMySQL（Vitess）
  • Bigtable
  • オブジェクトストレージ（GCS/Colossus）
  • 動画とメタデータのための多層CDN/キャッシュ

これが全体像です。ここからパーツに分解します。

4つのリクエスト形状

YouTubeを理解したいなら「1つのアーキテクチャ」と考えるのをやめましょう。1つのブランドに4つのアーキテクチャが共存しています。

  1. 動的ページとAPI Watchページ、コメント、登録、検索、レコメンド。

  2. 動画バイト 巨大な順次読み出し、適応ビットレート、キャッシュ階層。

  3. サムネイルと小さなオブジェクト 小さなペイロード、猛烈なQPS、ファイルシステムの負担。

  4. メタデータと関係性 ユーザー、動画、カウンタ、登録。整合性制約下での読み書き。

それぞれの経路には異なるボトルネックがあります。

1) 動画配信: CDNがプロダクト

YouTube規模では「動画サービス」はほぼキャッシュの問題です。 YouTubeの動画配信クラウドの測定研究では、次の点が述べられています。

  • フラットな動画ID空間
  • 多層の論理キャッシュ階層を表す複数のDNS名前空間
  • 物理的に3層のキャッシュ階層（プライマリ / セカンダリ / ティアシアリ）

重要な仕組みは次の通りです。

動画ID → DNSマッピング → 論理名前空間 → 物理キャッシュ位置

つまり、以下が可能になります。

  • サーバ追加
  • 負荷移動
  • キャッシュポリシー変更

これらをアプリコードのデプロイではなく、マッピング更新だけで実現できます。

プロトコル挙動

GoogleのMedia CDNスタックは最新のトランスポートを使います。

  • QUIC / HTTP/3
  • TLS 1.3
  • 近代的な輻輳制御（BBRなど）

クライアント側では適応ストリーミングを使います。

  • DASH / HLS
  • 帯域とバッファ状態に応じたレイヤ切り替え

つまり「動画を見る」とは次の一連です。

  • マニフェスト取得
  • セグメント取得
  • ビットレート調整
  • バッファ維持
  • リバッファ回避

オリジンはトラフィックが最後に到達するべき場所です。 オリジン負荷が高いなら、上流のどこかが壊れています。

2) 動的リクエスト: Borg上のマイクロサービス

Watchページ、フィード、コメント、登録などの一般的な公開モデルは次の流れです。

クライアント → エッジ → LB/APIレイヤ → バックエンドマイクロサービス → データレイヤ

これはYouTube公式の厳密な図ではありませんが、以下と整合します。

  • Googleの大規模サービス運用
  • 配信挙動から見える構造
  • システム設計の分析記事

公開情報として確かなことは、YouTubeがGoogle内部のクラスタ基盤（Borg）上の巨大ワークロードとして動いている点です。

Borgが重要な理由は、YouTubeが2つの異なるワークロードを持つからです。

  • レイテンシに敏感な処理（API、ページ組み立て）
  • バッチ/スループット重視の処理（トランスコード、分析）

Borgは両方を効率的に動かすために設計されています。

  • スケジューリングとビンパッキングによる高い利用率
  • マシン故障時の高速回復
  • 1つのワークロードがクラスタを食い潰さないための隔離と入場制御

安定したフリートを前提としたアーキテクチャは、すでに遅れています。 YouTube規模では、マシン障害は日常的な背景ノイズです。

3) サムネイル: 小さなファイルは罠

多くのチームが遅すぎるタイミングで学ぶことがあります。 小さなオブジェクトは、大きなオブジェクトより難しい。

Watchページには何十枚ものサムネイルが出ます。 それが小さなペイロードへの膨大なリクエストを生みます。

公開情報では、YouTubeが画像/サムネイルなどの複製データや大規模キー・バリューデータセットにBigtableを使っていることが示されています。

この方向性が合理的な理由は以下です。

  • 何十億もの小さなオブジェクトを持つファイルシステムは運用コストになる
  • inodeの圧迫
  • キャッシュウォームアップの苦痛
  • ディレクトリのスケーリング限界
  • 絶え間ないコールドキャッシュミス

Bigtable系のストレージを使うと次が可能になります。

  • 「1ファイル=1オブジェクト」より密度の高い格納
  • 複数拠点への複製
  • 分散キャッシュレイヤの背後に置く

サムネイルを「ただの静的アセット」と扱うと、サムネイルで呼び出しが来ます。

4) 実証が最も強い部分: VitessでMySQLをスケール

ここは一次証拠が最もきれいです。Vitessがオープンソースで、メンテナが文書化しているためです。

YouTubeのメタデータはMySQLから始まりました。 成長により、典型的な3つの障害モードが生じました。

  • レプリケーション遅延（書き込み下での非同期レプリケーション）
  • コネクション過多（アプリ層がMySQLを溶かす）
  • テーブル肥大化（垂直スケールが効かなくなる）

よくあるストーリーは「SQLをやめる」です。 YouTubeのストーリーは「SQLを使い続けるための基盤を作る」です。

Vitessを一言で

Vitessは、MySQLのシャーディングを運用可能にするコントロールプレーンです。

VitessのGitHub READMEより:

Vitess was a core component of YouTube’s database infrastructure from 2011, and grew to encompass tens of thousands of MySQL nodes.

この一文が見出しです。 印象的だからではなく、YouTubeが選んだ本当のトレードオフを示しているからです。

  • シャーディングの複雑さを受け入れた
  • 自動化でそのコストを支払った

Vitessの主要プリミティブ

VTGate（クエリルータ）

  • クエリを正しいシャードへルーティング
  • コネクションプール（MySQLをコネクション嵐から守る）
  • クエリの安全性/ガードレール（危険なクエリを止める）

VTTablet（シャードごとのエージェント）

  • シャードのMySQL管理
  • フェイルオーバーに参加
  • 運用ワークフローを支援（バックアップ、再親化）

リシャーディング

  • 最小のダウンタイムでシャードを分割/統合
  • 「1シャードが熱くなる」が日常なら必須

重要な教訓

シャーディングは書き込みスループットだけの話ではありません。 目的は隔離とブラスト半径です。

  • ホットユーザーが全体を遅くしない
  • 1つの壊れたシャードがサイト全体を落とさない
  • キャッシュ局所性は悪化ではなく改善すべき

アップロード → トランスコード → 保存 → 配信

公式ではないものの、公開情報と整合する深掘りでは次が述べられます。

  • チャンク化されたアップロード（10〜50MB）で再開と並列化
  • エッジ取り込みで最初のホップをローカル化
  • 非同期トランスコードワーカーが複数の品質を生成（コーデック/ビットレート/解像度）
  • 大容量ブロブ向けに最適化されたストレージ（GCS/Colossusのパターン）
  • キャッシュ性とセグメント取得挙動に最適化された配信

Googleから「YouTubeのトランスコードパイプライン」の単一の正式仕様はありませんが、上記は次と整合します。

  • Media CDNのパターン
  • 一般的なストリーミングアーキテクチャ
  • 公開されているシステム設計分析

重要なメンタルモデルは次の通りです。

アップロードレイテンシと処理レイテンシは別のプロダクトであり、キュー + 冪等性 + バックプレッシャーで分離しなければならない。

レコメンド: 2段階DNNと視聴時間

ここも一次情報が強い領域です。 Googleの論文「Deep Neural Networks for YouTube Recommendations」では、2段階の仕組みが説明されています。

  1. 候補生成 何十億の動画から数百に高速に絞る。

  2. ランキング より豊富な特徴量で候補にスコアをつける。

重要な最適化の詳細は「視聴時間」が第一級の目的になっていることです。 クリックはゲーム化されやすい。 視聴時間はそれより難しい。

また、このシステムには新規アップロードが長い履歴を待たずに浮上できるよう、鮮度特徴量が明示的に含まれます。

レコメンダを作るなら、最大のアーキテクチャ判断はモデルではありません。 それは「指標」です。 最適化する指標が、その行動を生み出します。

何を学ぶべきか

  • リクエスト形状で設計する。動画バイト、サムネイル、動的メタデータ、書き込みは別システム。
  • キャッシュは層として使う。エッジ → リージョン → オリジン。明確なヒット率目標を持つ。
  • ルーティングをコントロールプレーンにする。DNS/サービスディスカバリでコードを変えずに負荷移動。
  • シャーディングは隔離のため。スループットはおまけ。ブラスト半径が本質。
  • ユーザーがゲーム化しにくい指標を選ぶ。ほとんどのメディアフィードではクリックより視聴時間が勝つ。

技術を真似することも、原則を真似することもできます。 しかし制約は無視できません。

読んでくれてありがとう。みんな最高です。