Amazon Web Services ブログ

Amazon S3 を使用したライブ動画ストリーミング

はじめに

Amazon Simple Storage Service (Amazon S3)  は、ライブ動画ストリーミングワークフローのベーシックなオリジンとして必要なスケーラビリティ、データの可用性、セキュリティ、パフォーマンス、整合性を提供するオプジェクトストレージサービスです。この記事では、AWS Elemental LiveAWS Elemental MediaLive を使用して Amazon S3 で HLS 出力グループを生成する際の、設定および耐障害性に関するベストプラクティスを紹介します。Amazon S3 は、ライブ動画向けの低コストでベーシックなオリジンとして、 AWS Elemental MediaStore の代わりに利用できるようになりました。動画コンテンツを準備、保護、配信するうえで包括的な機能を必要とするライブストリーミングのワークフローについては、AWS Elemental MediaPackage を参照してください。

ライブオリジンのアーキテクチャ

冗長なライブストリーミングアーキテクチャは、同一出力を持つ2つのメディア処理パイプラインを提供します。こちらの例では、MediaLive Standard チャンネルRedundant HLS manifests 機能を使用して、2 つの異なる Amazon S3 バケットのパスに HLS 出力を生成します。一方、MediaLive の Single Pipeline クラスでは、出力先が 1 つしかないため、中断が入ると視聴体験に影響が生じます。

どちらのアーキテクチャでも、マニフェストやセグメントの更新に失敗すると、ライブストリームが「古い」状態になり、プレーヤーはオリジンから 200 HTTP のコードレスポンスを受信しますが、通常は動画/音声の最後の数セグメントを再生し、その後停止します。この記事では、このような古いバリアントマニフェストを検出して無効にする方法について紹介します。- 404 HTTP エラーコードを下流の Amazon CloudFront コンテンツデリバリーネットワーク (CDN) とビデオプレーヤーに強制的に送信することで、HL S仕様に記述されている通り、冗長フェイルオーバーがトリガーされます。

Amazon S3 をオリジンストレージとして選択し、上の図が示すように下流の CDN とプレーヤーが冗長マニフェストを処理できるようにするためには、次の基準を考慮する必要があります。

パフォーマンス

オーバーザトップ(OTT)ストリーミングに使用されるアダプティブビットレート (ABR) メディアは、通常、動画/音声メディアを含む連続的に命名された一連のファイルセグメントをベースとしています。Amazon S3 のパフォーマンス最適化に関するベストプラクティスでは、Amazon S3 が高いリクエストレートに自動的にスケールされ、パーティション化されたプレフィックスごとに少なくとも毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成する方法を概説しています。

ABR ワークフローでは、各ライブチャンネル形式および関連する品質バリアントの区切り文字としてスラッシュ (/) を使用することで、このプレフィックスが付与されます。MediaLiveの出力パスの構文は、このプレフィックスを提供するドキュメントに概説されています。

プレイリストやメディアセグメントサイズのオブジェクトに対する PUT/GET リクエストのレイテンシー測定結果の p99.9 で、Amazon S3 のパフォーマンスは AWS Elemental MediaStore のパフォーマンスと比べて機能的に全く同じです。

整合性

Amazon S3 は、すべての AWS リージョンの Amazon S3 バケットのオブジェクトの PUT/DELETE リクエストに対して、強力な書き込み後の読み取り整合性を提供します。この動作は、新しいオブジェクトの書き込みだけでなく、既存のオブジェクトを上書きする PUT リクエスト、そして DELETE リクエストにも適用されます。詳細については、Amazon S3 data consistency model を参照してください。

新しいオブジェクトの書き込みまたは既存オブジェクトの上書きが成功すると、それ以降の読み取りリクエストには直ちに最新バージョンのオブジェクトが提供されます。また、Amazon S3 はリスト操作でも強力な整合性を提供するため、書き込み後すぐに、すべての変更が反映された状態でバケット内のオブジェクトの一覧を取得できます。マニフェストやセグメントをポストするエンコーダーの書き込みが失敗した場合、使用可能なセグメントが中断されないように再試行の実施を設定する必要があります。

耐障害性

冗長なライブエンコーディングパイプラインの出力は、異なるプレフィックスを使って 1 つの Amazon S3 バケットに、あるいは 2 つの個別の Amazon S3 バケットに送ることが可能です。冗長マニフェスト機能が有効になっている場合、各パイプラインのメインプレイリストは、自身の子マニフェストともう一方のパイプラインの子マニフェストの両方を参照します。パイプラインに問題があると、そのパイプラインの子マニフェストにも問題が生じます。その場合、下流のプレーヤーはメインマニフェストを再度参照して、もう一方のパイプラインの子マニフェストを見つけることができます。

Architecture drawing showing AWS Elemental MediaLive standard channel to Amazon S3 with Amazon CloudFront. Scenario shown is redundant manifest when 404 error occurs at S3 origin.

セキュリティ

Amazon S3 を使うとお客様は、暗号化機能とアクセス管理ツールを活用して、データを保存し、不正アクセスから保護することができます。Amazon S3 は、PCI-DSS、HIPAA/HITECH、FedRAMP、EU Data Protection Directive、FISMA などに対応するコンプライアンスプログラムを整備しており、お客様が規制要件を満たすお手伝いをします。AWS では更に、Amazon S3 リソースへのアクセス要求を監視するための多数の監査機能もサポートしています。

メディア配信コンテンツのセキュリティは、ライブエンコーダーでの暗号化、およびエッジでの安全なメディア配信を AWS で実現するソリューションを使用したアクセスのトークン化により提供されます。ただし、完全なデジタル著作権管理 (DRM) を行うには、AWS Elemental MediaPackage などの他サービスを使用する必要があります。

古いマニフェストの無効化

エンコーダーがメディアプレイリストへの更新内容のアップロードに失敗したとき、プレイリストが古いと見なされた時点でこのオブジェクトに 404 エラーを返させることが望ましい場合がよくあります。古いプレイリストには、ライブエッジよりも過去のセグメントしか含まれていないため、別のバリアントプレイリストへの再生切り替えが必要になる場合があります。404 エラーが返されることでクライアントの再生デバイスは、古いプレイリストのまま行き詰まるのではなく、再生を続行すべく切り替えの判断を下すことができます。

このリファレンス SAM は、デプロイされると、指定された Amazon S3 バケットにアップロードされたプレイリストファイルをすべて監視し、古いプレイリストが検出された場合は削除します (https://github.com/aws-samples/amazon-cloudfront-s3-hls-invalidator)。

チェックする必要があるのは、エンドリスト、つまり HLS の #EXT-X-ENDLIST タグがないバリアントプレイリストのみです。マスターのマルチバリアントプレイリストは通常、配信開始時にライブエンコーダーからポストされるだけで、その後は更新されないため、Amazon S3 バケットに残しておく必要があります。

Architecture drawing for example variant manifest invalidation - showing AWS Elemental MediaLive output to Amazon S3, AWS Lambda deletes playlist if stale. CloudFront delivers stream to Players.

ライブエンコーダーでは、チャンネルが再起動した場合にセグメントが互いをオーバーライドするのを防ぐのと、CloudFront に異なるキャッシュキーを割り当てるために、セグメント名にはタイムスタンプを追加することが推奨されます。MediaLive の使用については Identifiers for variable data(変数データの識別子)を使用した segmentModifier の設計を参照してください。

料金

ほとんどの AWS サービスと同様に、Amazon S3AWS Lambda には最低料金の設定はありません。実際に使用した分だけお支払いいただきます。ライブストリーミングのアプリケーションで考慮すべきコストの要素は、ストレージ、リクエスト、データ転送、Lambda 実行時間です。Amazon S3 の料金についてはこちら、AWS Lambda についてはこちらより詳細を確認してください。

まとめ

Amazon S3 を使用した AWS 上でのライブストリーミングをセットアップするために利用できるリファレンスアーキテクチャが利用可能です。そしてこの記事では、古いマニフェストを無効化することで、耐障害性を最適化するためのベストプラクティスをいくつか紹介しています。更なる背景情報については、AWS re:Invent 2022 – Deep dive on Amazon S3 を参照してください。


参考リンク

AWS Media Services
AWS Media & Entertainment Blog (日本語)
AWS Media & Entertainment Blog (英語)

AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp
※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は BD 山口、SA 石井が担当しました。原文はこちらをご覧ください。