[レポート] 回復力のあるライブストリーミングビデオワークフローの構築 #MDS306 #reinvent

こんにちは、大前です。夜のラスベガスの大通りにはたくさんミッ○ーがいました。

このブログは、AWS re:Invent 2019 のセッションレポートになります。

概要

スピーカー

Nicolas Weil - Senior Product Manager, Amazon Web Services

Ramya Krishnamoorthy - Sr Software Development Eng, Amazon Web Services

Kiran Patel - Solutions Marketing Manager, Amazon Web Services

Dan Gehred - Solutions Marketing Manager, Amazon Web Services

原題

Building resilient live streaming video workflows

概要

Delivering reliable and resilient live streaming is a must for video providers, who depend on live video workflows being highly available and scalable with audience size so viewers never miss a moment of content. A truly resilient live video stream delivers a smooth and consistent experience for viewers, without gaps, stalls, or silences. In this session, learn how to use the AWS Cloud and AWS Media Services, like AWS Elemental MediaLive, AWS Elemental MediaConnect, AWS Elemental MediaStore, and AWS Elemental MediaPackage, to build highly available and reliable live video workflows in a cost-effective and scalable way, complete with monitoring, alerts, and security.

概要（機械翻訳）

信頼性と回復力に優れたライブストリーミングを提供することは、視聴者がコンテンツの瞬間を逃さないように、ライブビデオワークフローの可用性と視聴者の規模に合わせて拡張できることに依存しているビデオプロバイダーにとって不可欠です。 真に回復力のあるライブビデオストリームは、隙間、失速、または沈黙なしに、視聴者にスムーズで一貫したエクスペリエンスを提供します。 このセッションでは、AWS Elemental MediaLive、AWS Elemental MediaConnect、AWS Elemental MediaStore、AWS Elemental MediaPackageなどのAWSクラウドとAWS Media Servicesを使用して、費用対効果の高いスケーラブルな可用性と信頼性の高いライブビデオワークフローを構築する方法を学びます 方法、監視、アラート、およびセキュリティを完備。

レポート

AWS MediaServices の可用性や信頼性に関する Chalk Talk でした。

最初に20分ほど実事例のアーキテクチャ図を交えながら各サービスの特徴を説明し、その後の残り時間は参加者からのフリーQAタイムとなっていました。

QA に関しては私の英語力が残念なため、聞き取れた範囲でレポートを書いていきます。

ライブストリームアーキテクチャの要素

基本的には以下要素の組み合わせでライブストリーミングのアーキテクチャは成り立っています。

• エンコーダー
• 転送
• ABRトランスコーディング
• パッケージング
• オリジネーション
• 配布

図で言うと左から処理が流れていくイメージですね。

カオスエンジニアリングの視点から、「Resilience（弾力性）」の定義が述べられました。

Resilience（弾力性） = Redundancy（冗長性）+ Failover（フェイルオーバー）であり、

クラウドにおける「Better resilience」は、オートスケーリングと自動回復を持つクラウドネイティブな冗長性に加え、自動的なフェイルオーバーを兼ね備えたものと定義されました。

「自動でスケールする」「自動回復する」「冗長性を持つ」「フェイルオーバーは自動」を兼ね備えるべき、と理解しました。

各事例を通じたサービスの弾力性について

CBSi社様の事例

• エンコーダーまでオンプレミスで行われている
  • Elemental Liveが使用されている
  • ARBトランスコードとパッケージングはここで実施
• MediaStoreをオリジネーションとして使用

主系とは別に副系のマニフェストファイルも生成しておくことにより、主系でリクエストが失敗した際には副系に切り替えることでシームレスなフェイルオーバーが可能とのこと。

このアーキテクチャ図では、ECSでHLSエンドポイントの監視を行なっています。

メディアのワークロードをコンテナを使って監視する発想が今までなかったため、非常に勉強になりました。

Discovery社様の事例

Discovery社様のアーキテクチャを元に、MediaLiveとMediaPackageの特徴について説明がありました。

Elemental MediaLiveについて

• ABRトランスコーディングのために提供しているマネージドサービス
• 各MediaLiveチャンネルには2のパイプラインがある
  • 各パイプラインは異なるソースからの入力を受け付ける
  • 片方のパイプラインが停止しても、サービスは継続する事ができる
  • 出力に関しては、2つのパイプラインを自動的に同期して出力を行う

2つのパイプラインを意識せずに使用できるため、MediaLiveを使用するだけで冗長化を意識する必要が無くなるのはかなり楽だと感じました。

MediaLiveでエンコードされたデータはMediaPackageに渡されます。

• MediaPackageは2つの入力を処理し、出力ではどちらか片方のみ使用する
• 入力が足りない、多いなどの異常を検知した際は自動で他の入力に切り替わる

MediaPackageについても冗長化を意識しなくて良いのは楽ですね。

APIGateway+Lambdaを使用したMediaServicesのワークフロー監視も紹介されました。

CloudWatchなどと統合することにより、各サービスの死活状況を可視化する事が可能になります。

最後に

• 多くの冗長性や復元機能を備えると言うことは、多くのトレードオフがあるということ
  • どのレベルの冗長性が必要なのかを確認する
  • マルチリージョンにする必要もない場合もあるかもしれない
• ただし、フェイルオーバーは必要
  • 問題を発見し、修復する手間がかかってしまうため
  • フェイルオーバーは自動化した方が優れている

QAタイム

ここからは、聞き取れた範囲でキーワードを箇条書きしていきます。

• MediaServices間の接続は暗号化され、セキュアに管理されている
• 今のところ、プロトコルを追加する予定はない
  • ZistやRistに対応している
• MediaTailorを使用する場合にはMediaPackageを使用する
• MediaPackageを使用することで簡単にパフォーマンスを向上させる事が可能となっている

終わりに

「Building resilient live streaming video workflows」のセッションレポートでした。

MediaServicesだけでなく、他サービスを組み合わせてアーキテクチャについてもキャッチアップしていく必要があるなと強く感じました。

あとは、英語力を高めてQAのやりとりを理解できるようになりたいと思います。。

 

以上、AWS事業本部の大前でした。