DMMグループの一番深くておもしろいトコロ。
テクノロジー

コスパよくセキュアでスケーラブルなライブ配信システムを構築する

DMMグループの一番深くておもしろいトコロ。

この記事は、DMMグループAdvent Calendar 2021の15日目の記事です。

こんにちは、DMM.com の小田 大輔(@daidai1025xx)と申します。最近はVRChatとワインにハマりながら、動画配信事業部 配信基盤グループで頑張っています。

今回は私個人が最近試した、AWS上でのライブ配信システム構築についてご紹介します。AWSと、動画配信の基本的な知識があることを前提にしています。予めご了承ください。

ライブ配信・リアルタイム配信の形態としては、1:1のリアルタイム通信や1:nのブロードキャスト配信などがありますが、今回は1:nのブロードキャストライブ配信の文脈で語っていきます。

この記事に含まれていないこと

各種ツールの具体的な使い方については解説していません。

ライブ動画配信における「品質」とは

ライブ動画配信サービスにおいての品質を考えてみましょう。まずは大きく、ユーザにとっての品質である「外部品質」と、開発者側にとっての品質である「内部品質」の２つに大別してみます。そこから最初に外部品質における要素を分解していくと、おおまかに以下のものがあると考えます。どれも視聴体験の良さ、という文脈でくくれるのではないかと思います。

  1. 動画の画質・音質
  2. プレーヤの操作性の良さ
  3. 動画の読み込みの速さ etc.

次に、内部品質の要素を分解してみます。内部品質とは、いわゆるメンテのしやすさ等の文脈を想定しています。ライブ動画配信に限った話ではないかもしれませんが、おおまかに以下をはじめとする要素があるのではないかと考えます。

  1. テスタビリティ
  2. 理解容易性
  3. スケーラビリティ
  4. セキュリティ etc.

セキュリティという文脈で、特にインターネット動画配信ではDRMが必要になってくるケースが多々あると思います。しかしながら、DRMはある程度の知見がないと実装に苦労する部分でもあります。そういった実装難易度の高い部分をクラウドに乗っかれると、システムの可搬性や理解容易性を高めることができ、内部品質を高められるという側面があるのではないでしょうか。しかしながら、クラウドを使うとどうしてもチューニングできる要素が限られるため、細かい設定をしたい場面で痒いところに手が届かないというケースもあるかと思います。この辺りはクラウドとオンプレの二律背反といったところでしょうか。配信システムに限らず、技術選定はケースバイケースで臨機応変に行うのが得策と考えつつ、今回はセキュアでクオリティの高いライブ配信システムを高コスパで構築したい、という場面でこの記事が役に立てばと思います。

ということで、AWS Media Servicesを使った「イイ感じ」のライブ配信構成についてお話していきます。

AWSを用いたライブ動画配信システム

全体構成

f:id:dmmadcale2021:20211209010352p:plain

ライブ配信システム構成図

配信部分は、AWS Elemental Media Servicesを駆使しつつ、キーサーバ(後述)でAPI GatewayとLambdaを使います。CDN部分ではCloud Frontを使った構成となっています。

Media Liveでのエンコード

Media Liveでは、映像打ち上げ元のクライアントからのRTMPを受け付けて、エンコードする部分を担います。

動画のビットレートやフレームレート、GOP長、コーデックのプロファイル・レベル等を細かく指定できるうえで、ABR用に複数ストリームを生成することも可能です。また、今のところはHEVC(H265)しか対応してないようですが、4K映像のエンコードも可能なようです。

最終的にMedia Liveがクライアントから受け取ったRTMPストリームは、リアルタイムでエンコードしつつ後続のMedia Packageに転送されます。

以下の設定でエンコードするようにしてみました。主要な設定のみ記載しています。

  • 映像コーデック：H264 Main(プロファイルレベルはAUTO)
  • 音声コーデック：AAC LC
  • 音声のサンプリングレート：48khz
  • ビットレート：VBRで複数ビットレートにエンコード。最大画質は6MbpsのFullHD。
  • フレームレート：29.97fpsでプログレッシブ
  • チャンクサイズ：２秒
  • GOP長：２秒
  • GOPに含まれるBフレームの数：２

チャンクサイズは、AWSの場合１秒でも設定できるようですが、あまり短いとクライアント側のデコード負荷が上がってしまう問題が考えられます。チャンクサイズを短くするメリットとしてはEnd-to-Endのレイテンシが低くなるメリットがあると思いますが、こちらはデコード負荷問題と二律背反していますね。今回はお試しで配信する程度の用途なので、チャンクサイズは2秒としてみました。

Media Packageでのパッケージングと配信

MediaPackage側では、MediaLiveのエンコーダから受け取ったHLSのストリームを、JIT(Just-In-Time)でパッケージングしていきます。 いわゆる「オリジンサーバ」としての役割を担うわけです。自動である程度スケールしてくれるみたいなので、便利ですね。

2021年12月現在では、以下の形式のパッケージングに対応しています。

  • MPEG-DASH
  • Microsoft Smooth Streaming(MSS)
  • HLS
  • CMAF

参照 - https://docs.aws.amazon.com/mediapackage/latest/ug/endpoints.html

 

配信フォーマットとしては、HLS・DASH・Smooth Streamingのマニフェストのエンコードを試してみました。 またパッケージング設定としては、複数のビットレートでエンコードし、ABR(Adaptive Bit Rate)なマニフェストを配信するようにしてみました。

さらにMediaPackageでは、パッケージングする際にAWS SPEKEというDRM暗号化情報通信のインターフェースに則り動画コンテンツを暗号化することが可能です。仕組みとしては、MediaPackageで動画をパッケージングする際に、AWS SPEKEのインターフェースに則って実装したAPI(キーサーバ)と通信して、DRMに必要な暗号化情報を生成し、暗号化をかけます。ですので、事前にAWS SPEKEを踏襲したAPI(キーサーバ)の準備をする必要があります。

この辺については、公式でリファレンス実装( https://github.com/awslabs/speke-reference-server )を提供しているので、こちらを参考にキーサーバを実装してみるのが良いかと思います。リファレンス実装ではVOD向けの処理が書かれていますが、こちら( https://docs.aws.amazon.com/ja_jp/speke/latest/documentation/live-workflow-methods-v2.html )を参考にライブ向けのワークフローの処理を追加したところ、無事にMedia Packageと連携することができました。

また、MediaPackageでは以下のDRM形式に対応しています。

  • FairPlay
  • PlayReady
  • Widevine(CENCでPlayReadyと同じマニフェストに同梱できます)
  • HLS AES128

参照 - https://docs.aws.amazon.com/ja_jp/speke/latest/documentation/speke-api-specification.html

 

ちなみに、DASHとHLSでDRMをかける場合は、キーのローテーションをすることができます。キーのローテーションとは、一定時間ごとに暗号化情報のキーを新しく生成し、古い複合キーを扱えなくすることでセキュリティを高める仕組みです。デフォルトだと、キーローテーション設定が無効になっていますが、Media Packageの設定画面でチェックマークを入れることでキーロテートが可能になります。

参照 - https://docs.aws.amazon.com/mediapackage/latest/ug/drm-content-key-rotation.html

 

今回はリファレンス実装にならってAPI Gateway+Lambdaという構成でキーサーバを作成してみました。上記のWidevine(DASHで扱う)と、PlayReady(SmoothStreamingで扱う)と、HLS AES128の暗号化情報を生成する処理をキーサーバに追加してみます。

また先述のリファレンス実装ではAPI Gateway + Lambdaという構成でキーサーバを実装していますが、インターフェースさえ踏襲していれば動作するので、オンプレだったり他のプラットフォーム上にキーサーバを構築することも可能です。

過去にVODでAWS SPEKEを使った動画配信ワークフローを実装する記事を書いたので、こちらも合わせてご参照ください。 https://qiita.com/daisukeoda/items/9a8924b16c1dafcbc5f9

CDNでのデリバリー

Media Packageをオリジンとして、Cloud Frontを設定してみました。

実際に配信して再生してみた

検証方法としてはBig Bug Bunny( https://peach.blender.org/ )の動画をダウンロードし、ffmpegからMedia LiveにRTMPで動画を打ち上げてみました。

マニフェストはDASH(Widevine DRM)と、Smooth Streaming(PlayReady DRM)と、HLS(AES128で暗号化)での再生を試しています。 打ち上げ開始から再生開始までの遅延は30秒程度で、まずはDRMの鍵ファイルのリクエストが成功し、復号に成功するステップまで確認しました。

その後、最初は低ビットレートなストリームで再生が始まり、帯域に合わせて徐々に高画質なストリームに正常に切り替わっていくことが無事確認できました。

まとめ

今回はAWSを用いて、DRMありのライブ動画配信を実現するシステムを構築してみました。それなりに安定して配信もできたので、プロダクションレベルでの利用もありなんじゃないかと思っています。

今日、動画配信を実現したいユースケースは多岐に渡ると思います。オンプレで実現する場合だったり、クラウドだったり、はたまたクラウドとオンプレのハイブリッド構成だったりなど。またプロダクションレベルの開発おいては、単にシステムを作って終わりではなく、運用後のオペレーションやモニタリング、必要に応じた機能の増減等、考慮すべき点が多々あるでしょう。今回試したAWSでのライブ配信システムも、あくまで要件を実現するツールの一つとして、開発の選択肢が増えたと考えるのが妥当ではないかと考えています。

今回ご紹介したシステムでいうと、例えば以下のようなユースケースでの利用が考えられるのではないでしょうか。

  1. 少ない開発リソースでそれなりのクオリティの配信システムを短期間で開発したい
  2. 既存の配信システムに障害が起きたときのフェイルオーバー先として、予備の配信経路を持っておきたい

人はついつい銀の弾丸を求めてしまいがちですが、やはりユースケースに応じた臨機応変な技術選定が大事だなと感じます。

  • アドベントカレンダー2021

シェア

関連する記事