<-- mermaid -->

NewsPicksの動画配信の仕組み - 自動化でエンジニアの見守り0に -

こんにちは、NewsPicksエンジニアの桐畑です。

NewsPicks Advent Calendar 2022 の 12 日目です。 全25回の Advent Calenderも、明日から折り返しとなります。

qiita.com

本日は、NewsPicksの動画配信の仕組みを書かせていただければと思います。

NewPicksでは 2017年から動画コンテンツを配信しています。多い時だと毎日、少ない時でも週3本は配信をしています。

5年間、配信の安定化および人手を最小化するためにシステムの改善を続けてきました。当初は動画配信中にエンジニアが待機していましたが、2020年ごろより、エンジニア待機無しで配信をしています。2022年 現在、主にAWSのMediaServices を使った構成になっています。今回は配信形式ごと(ユースケースごと)にどのような仕組みになっているかご紹介させていただきます。

newspicks.com

動画配信の配信形式

2017年当時はライブ配信だけだったのですが、その後、収録動画の配信などが増えていきました。今では、大きく以下の3パターンの配信形式で動画を配信しています。

1. ライブ番組

スタジオの映像をリアルタイムに配信する形式です。

※非常に紛らわしくて、恐縮なのですが、区別するためにここでは以下の言葉の定義とさせてください。

ライブ配信 :リアルタイムに映像配信すること

ライブ番組 :スタジオの映像をリアルタイムに配信する番組のこと

現在配信しているライブ番組は、WEEKLY OCHIAI, THE UPDATE 等になります。

newspicks.com

newspicks.com

2. 収録番組のライブ配信

事前に収録した映像をリアルタイムに配信する形式です。現在ライブ配信している番組は、HORIE ONE, NewSchool 等になります。 ※TVで収録済みの映像を配信しているのをイメージしてもらうとわかりやすいかもしれません。

newspicks.com

newspicks.com

3. アーカイブ配信のみ

リアルタイムでは配信せず、動画を公開した後はユーザーが好きなタイミングで好きな箇所から再生できます。

配信方式ごとの仕組み

順番が逆になってしまって申し訳ないのですが、 3. アーカイブ配信のみ が仕組みとしてシンプルなので こちらから紹介いたします。

「アーカイブ配信のみ」の 仕組み

配信自体は特に説明も不要なぐらいシンプルです。AWSのS3に保存した動画データをCDN(CloudFront)を通して配信しています。

アーカイブ配信

動画入稿の仕組み

アーカイブ動画は入稿時にエンコードタスクが実施される作りになっています。というのも、動画ファイルは、単一高画質の動画ファイル(mp4)で入稿されるのですが、視聴環境ごとに映像を最適化するために HLS形式 に変換する必要があります。

具体的には、動画ファイルをS3の所定の場所にアップロードすると、Lambda > MediaConverterとトリガーされエンコードタスクが開始されます。エンコードタスクが完了するとSlackに通知が来る仕組みになっています。エンコードタスク内で、画質最適化と音声平準化も実施されます。

動画入稿時のエンコード処理

アーカイブ配信は、完成されている動画ファイルを静的に提供するだけなので、ライブ配信と比べると仕組みがシンプルな分問題が発生し難いです。実際に5年間で大きな問題は起きていません。

「収録番組のライブ配信」の 仕組み

次に収録番組のライブ配信の仕組みについて紹介します。ここから映像をリアルタイムに流す必要があります。

配信はS3に配置された動画ファイルを、MediaLiveが読み込みMediaPackageに流すシンプルな仕組みになっています。

収録動画のライブ配信

ライブ配信の難しいポイント

ライブ配信は映像配信に加えて、

時刻に合わせて、アプリの配信開始・終了 / プッシュ通知送信

といった要件を満たす必要があります。

NewsPicksでは実現する方法として、サーバーの常駐プロセスを設置して、所定の時刻になったら各種処理を実施する作りにしています。

アプリの配信開始・終了 / プッシュ通知

過去にライブ配信で発生した問題

実際に配信を続ける中で、

  • 配信設定が間違っている(オペミス)
  • サーバーの常駐プロセスが不安定

といった問題が度々発生しました。

ありきたりな方法なのですが、それぞれ以下の方法で解消しました。

  • 配信設定が間違っている(オペミス) 設定の間違いをパターン化して、システムでバリデーションするようにし、Slackなどで通知が来るようにしました。 合わせて、配信30分前に設定されている内容を通知するようにしています。

  • サーバーの常駐プロセスが不安定 1プロセスの中で複数の処理を並行実施していたのですが、1処理1プロセスとすることで安定化。 さらに、プロセスを監視して落ちている場合は通知が来るようにしました。

「ライブ番組」 の仕組み

スタジオの映像をElementalLiveでエンコードし、MediaLiveにアップロード。その後は収録番組と同様にMediaPackageから配信しています。

ライブ番組

ライブ配信という特性は、前出の 収録動画のライブ配信 と同じなのですが、スタジオの映像のアップロードする要件が増えます。

「ライブ番組」のリスクポイント

S3のファイルを読み取るのとは違って、映像を圧縮して通信回線を使ってAWS上にアップロードする必要があります。クラウド上とは異なり、機材の故障 / 通信の不安定化といったリスクが伴います。(厳密にはクラウド上でも同様のリスクは存在していますが...責任の所在という意味で)

リスクヘッジとして、

  • 機材を冗長構成にする(エンコーダー、通信回線、クラウド上のパイプライン)
  • アップロード用通信回線を帯域保証契約にする
  • スタジオとの通信状況をCloudWatchで監視する

といった対策を実施しています。

上記の対策を講じた2018-19年以降は、数百回以上配信して、アップロードの部分で問題になったことはありません。

「ライブ番組」のアーカイブ処理

ライブ番組では、配信終了後にライブ配信した映像をアーカイブ化する必要があります。 MediaPackageのHarvestJobという機能を使って、配信した映像のうち、アーカイブ化する開始・終了日時に設定して切り出しています。その後、画質最適化・音声平準化のエンコードを行い、アーカイブ用の動画ファイルを作成します。

ライブ番組のアーカイブ処理

以前はエンコードに時間がかかっていたのですが、MediaConverterに高速エンコードモードが追加されて、1時間の番組であれば概ね20分以内に完了します。

おわりに

ここまで読んでいただきありがとうございます。もしこの記事が動画配信を今から始める方や運用改善進めている方の少しでも役に立てばなによりです。

今後の改善点として、配信容量の最適化や、配信機材の最新化などを進めていく予定です。

Page top