動画配信プラットフォームの例

#System Design Interview

September 18, 2024

システム設計面接におけるNetflixやYoutubeのような動画サービスの問題における要点を整理する。

要件

どの参考文献でも視聴とアップロードが機能要件にある。また非機能要件については、解答例のシステム設計はすべてマイクロサービスであり、性能・拡張性を重視し、一貫性モデルを妥協してBASE (Basically available, Soft state, Eventual consistency) を認めている。参考文献では、以下の要件が目にとまった。

機能要件
- ストリーミング配信される動画の視聴
  - 対応クライアント
    - ブラウザ
    - モバイル
    - スマートTV
- 動画のアップロード
- 動画の品質の変更
- 動画の検索
- 動画の評価
  - Like
  - Dislike
  - コメント
非機能要件
- 高可用性
- 性能・拡張性
- 完全性

Back of the envelope estimation

Back of the envelope estimationでは、以下の数が与えられていた。

DAUユーザ数
ユーザが視聴する動画の平均数
アップロードされる動画の数
アップロードれる動画の平均サイズ

アーキテクチャ

参考文献の複数の解答例が、動画のアップロードして保存するまでの処理を分割して非同期にし、動画をCDNで配信している。この2点が動画配信の問題の要点になるのだろう。

アップロードされた動画の処理

解答例は、動画のアップロードから保存までの処理を小さな処理に分割し、Kafkaなどのキューで各処理を個別にスケールできるように実装している。キューを介してマシン間のデータの受け渡すことで、エンキュー後はマシン同士が依存しなくなり、非同期にマシンの数をスケールできるようになる。ある参考文献は処理を以下の処理のように分割し、分割した処理の実行を非同期化する。

動画のダウンロード
動画のサムネイル作成
コンテンツフィルダリング
ウォーターマークの追加
動画のエンコード
動画のアップロード

動画のエンコードと動画へのタグづけをキューで非同期するなら下図の構成になりえる。 queue

メッセージキューシステムにエンキューできるメッセージのサイズには上限があり、処理対象のデータ自体をメッセージとしてキューに入れられないことがある。たとえば、SQSのメッセージの最大サイズは256KBであり、Kafkaであれば1MBの制限がある。あつかえる動画のサイズの要件が1MBを超える場合、図のように処理中のファイルを外に置く必要がありそうだ。

どの解答例もメッセージキューシステムの選定基準について詳しく議論していない。たとえば、代表的なメッセージキューシステムにPull型のKafkaやPush型のRabbitMQがある。 RabbitMQは優先度つきメッセージなどでKafkaよりも細かいルーティング制御ができ、KafkaはRabbitMQよりも処理性能が高いように、実装ごとに異なる一長一短がある。 AWSであれば、RabbitMQのかわりにAmazon MQやマネージド型のKafka, SNSが選択肢になるだろう。

ストリーミング配信できない形式の動画ファイルをアップロードできるようにする場合、動画ファイルをストリーミング配信できる形式に変換する必要がある。試したことはないが、OSSであればFFmpegやAWS Elemental MediaConvertで変換できそうだ。配信プロトコルにはHLSやDASHがある。

CDNでの動画配信

動画をCDNで配信しダウンロード速度を高速化する場合、動画を認証やWAFで保護しなければならない。 AWSであれば、CDNのCloudFrontをWAFで保護できる。また、CloudFrontはS3にある静的ファイルを配信できる。ファイルへのCRUD操作を認証されたユーザのみに許可したい場合、認証したユーザに署名つきURLや署名つきCookieを発行する。 1つのURLだけを制限する場合は署名つきURLを、複数のURLを制限する場合は署名つきCookieを選ぶとよい。署名つきURLでアップロード先を指定する場合、サーバーを中継せずにファイルをS3に送ることで、サーバーにかかるアップロード処理の負荷を下げることができる。