🎉
Youtubeのシステムデザインを考える
YouTubeのシステムデザインを考える（動画アップロード編）
なぜYouTubeの設計を学ぶのか？
YouTubeは世界最大級の動画共有プラットフォームであり、日々膨大なデータを扱っています。
設計のスケーラビリティ、信頼性、処理効率の高さは、多くのWeb系サービスが参考にすべきロールモデルです。
本記事では、動画のアップロードから再生可能になるまでの一連のシステム設計を、要件整理からインフラ構成、非同期処理の設計まで実践的に分解して解説します。
ちなみにGoogle統計によると、約1分間に500時間以上の動画がアップロードされているそうです。
要件定義
今回は動画アップロードのみにフォーカスするので以下のように最低限の機能要件と非機能要件を定義します。
機能要件
- ユーザーが動画をアップロードできる
- アップロード後、自動で再エンコードが走る
- 動画が適切なフォーマットに変換される
- CDN経由で高速かつ安定して配信される
非機能要件
- 高スループット（同時大量アップロードに耐える）
- 耐障害性（失敗時のリトライ・途中復元）
- スケーラビリティ（国・地域別トラフィックへの最適化）
- コスト効率（ストレージや配信コストの最適化）
アーキテクチャ概要
YouTubeの動画アップロード～配信までの流れは大まかに次のようになっています。
- クライアントから動画をChunked Upload（分割アップロード）⇒Presigned URLでS3に送信。
- S3アップロード完了後、S3イベントでSQSへ通知。
- ワーカーがSQSをポーリング⇒FFmpegで変換（HLS/MP4）
- エンコード後、S3に保存
- CloudFrontなどCDN経由でユーザーに配信（HLS）
この流れを図にすると以下のようになります。
各コンポーネントの設計
上のアーキテクチャの概要を詳しく説明していきます。
ステップ1:アップロード処理
- ユーザーから動画ファイルを送信します。動画ファイルの容量が大きいため、Chunked Upload（分割アップロード）を使用します。
- Presigned URL（署名付きURL）を発行し、S3に直送してます。これによりバックエンドを通らず、帯域を節約できます。
※メタ情報（タイトル・説明など）は別途APIで登録
ステップ2:S3アップロード完了⇒通知トリガー
- S3にアップロード完了後、S3イベント が発火し、→ SQS or EventBridge → Lambda/Fargate
- このイベントが、Amazon SQSやEventBridgeなどの非同期通知システムに転送されます。
ステップ3:バックエンドワーカーで動画変換
- LambdaやFargate(ECS)などのWorkerが、SQSからメッセージを受け取り、動画ファイルの変換処理を開始。
- FFmpegを使って、動画をHLS形式（HTTP Live Streaming）やMP4形式にトランスコード。
HLS:.m3u8 + .tsファイルでストリーミングに適している・
ステップ4:変換後ファイルをS3に保存
- 上記で変換された.m3u8(プレイリスト)と.ts（セグメントファイル）がS3に再保存されます。
ステップ5:CloudFront経由でユーザーに高速配信（HLS再生）
- ユーザーはCloudFrontのURLからHLSを再生。
- CloudFrontは、世界中に配置されたCDNエッジロケーションを利用して、低遅延・高パフォーマンスな動画配信を実現。
おわりに
今回はAWSを例に説明しましたが、GCPやAzureなど他のクラウドサービスでも同様に設計できます。
大規模サービスのスケーラブルな設計を自分で分解して考えることで、システム設計の実践力・面接対応力が飛躍的に高まりまり、AI時代にも貴重な設計力を身に付けることが出来ると思います。
レコメンド機能なども調べてみると面白いかもしれません。
Discussion