メディアワークロード向け!AWS Well-Architected FrameworkのStreaming Media Lensホワイトペーパーが公開されています

AWS Well-Architected Lensesでメディアワークロード向けのベストプラクティス集「Streaming Media Lens」がホワイトペーパーとして公開されています。リンク先や概要などをまとめてみました。
2022.01.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。AWSではWell-Architectedというベストプラクティス集が公開されています。またWell-Architectedの中でも、レンズ(AWS Well-Architected Lenses)という特定の業界およびテクノロジー領域向けに焦点を当てて説明する概念があります。このAWS Well-Architected Lensesにメディアワークロード向けのベストプラクティス集、「Streaming Media Lens」がホワイトペーパーのかたちで公開されていました。いきなりですがホワイトペーパーへのリンクから紹介しましょう、こちらです!

私はAWS Media Blogの2022/01/13付でポストれたエントリでこの「Streaming Media Lens」を知りました。ホワイトペーパー自体にはPublication dateとして2021/09/29と記載されています。昨年後半ごろには作成されていたことになりますね。本エントリでは、この「Streaming Media Lens」の概要についてお伝えします。私もざっと斜め読みしぐらいではありますが、本家AWS Well-Architected同様、とても参考になるベストプラクティスがまとまっているかと思います。AWSを用いたメディアワークロードに関わっている場合は、本家AWS Well-Architectedとあわせて必読ではないでしょうか。

なお、こちらの「Streaming Media Lens」、ホワイトペーパーへのリンクを覚えておく必要はありません。AWS Well-Architectedのページからたどることが可能です。Google検索などでAWS Well-Architectedのページに進みましょう。

AWS Well-Architected – 安全で効率的なクラウドアプリケーション

画面を少し下にスクロールすると、「AWS Well-Architected レンズ」という項目が見つかります。ここに「Streaming Media Lens」も掲載されているというわけです。

AWS Well-Architected – 安全で効率的なクラウドアプリケーション

Streaming Media Lens概要

以下の見出しで構成されています。(この「Streaming Media Lens概要」の章の日本語訳はGoogle翻訳をベースに私のほうで付与しました。)

  • Abstract and introduction / 要約と紹介
  • Definitions / 定義
  • Design principles / 設計原則
  • Streaming media scenarios / ストリーミングメディアシナリオ
  • The pillars of the Well-Architected Framework / Well-Architected Frameworkの柱
  • Conclusion / 結論
  • Document history and contributors / ドキュメントの履歴と寄稿者
  • Glossary / 用語集
  • Notices / お知らせ

以下、ポイントとなりそうな点を概要というかたちで簡単にまとめてみたいと思います。

Design principles / 設計原則

Streaming Media Lensの設計原則として、以下4つが挙げられています。

  • ガラスからガラス(カメラからビューアデバイス)への視点を保つ
  • オーディエンスを理解する
  • コンテンツの価値を知る
  • 中断の設計

Streaming media scenarios / ストリーミングメディアシナリオ

ストリーミングメディアの各シナリオがワークロードのアーキテクチャにどのように影響するかについて解説しています。シナリオとしてはVideo-on-Demand (VOD)ストリーミング、ライブストリーミング(Live video streaming)の他、広告サポートによるコンテンツのマネタイゼーションについても触れている点が大きいかなと思いました。

The pillars of the Well-Architected Framework / Well-Architected Frameworkの柱

本家Well-Architected Framework同様、オペレーショナル・エクセレンス(運用上の優秀性)の柱、セキュリティの柱、信頼性の柱、パフォーマンス効率の柱、コスト最適化の柱の5本の柱で構成されています。(re:Invent 2021で6本目の柱、サスティナビリティ(持続可能性)が加わりましたが、Streaming Media Lensの発行日が2021/09/29ということで、まだ取り入れられていないのかなと思います。([新要素]サステナビリティ(持続可能性)が6本目の柱としてAWS Well-Architectedフレームワークに追加されました #reinvent | DevelopersIO))

本節では、各柱における質問内容とベストプラクティスについてもまとめてみます。

オペレーショナル・エクセレンス(運用上の優秀性)の柱

準備、オペレーション、レスポンスの3つのベストプラクティス領域で構成されています。特に準備に付いては、質問事項として「大規模なストリーミングメディアイベントにどのように備えますか?」といったことが挙げられ、HLSやDASHを用いた場合のリクエスト見積もり方法等が記載されています。

  • SM_OPS1:大規模なストリーミングメディアイベントにどのように備えますか?
    • SM_OBP1 –コンテンツ配信インフラストラクチャが予想される需要に合わせて拡張できることを確認します
    • SM_OBP2 –事前にワークロードのニーズに合わせてサービスクォータを評価および調整します
    • SM_OBP3 –イベントを支援するためにAWSサポートプログラムに参加する

セキュリティの柱

IDおよびアクセス管理、Detective controls(発見的コントロール)、インフラストラクチャの保護、データ保護、インシデント対応の5つのベストプラクティス領域で構成されます。特にコンテンツの保護にフォーカスしてまとめられているのがStreaming Media Lens特有かなと思います。

  • SM_SEC1:コンテンツへのアクセスとコンテンツの取り込みをどのように承認しますか?
    • SM_ SBP1 – IDプロバイダーを使用して視聴者を認証し、ポリシーにアクセスして、保護されたコンテンツへの最小特権アクセスを実装します
    • SM_SBP2 –コンテンツオリジンアクセスを制限して、許可されたコンテンツ配信ネットワークのみを許可する
  • SM_SEC2:メディア配信ワークロードへのアクセスをどのように監視しますか?
    • SM_SBP3 –不正なアクセスの試みを監視する
  • SM_SEC3 –コンテンツの不正な再配布をどのように監視しますか?
    • SM_SBP4 –コンテンツまたはセッションのフォレンジックを実装する
  • SM_SEC4:コンテンツ取り込みエンドポイントをどのように保護しますか?
    • SM_SBP5 –TLSを使用してコンテンツ取り込みトラフィックを暗号化する
    • SM_SBP6 –パートナーと連携する場合はプライベート接続を使用する
    • SM_SBP7 –物理メディアを介して配信するときに保存中のコンテンツを暗号化する
  • SM_SEC5:不正アクセスや悪意のある攻撃からコンテンツの発信元をどのように保護しますか?
    • SM_SBP8 –DDoS保護サービスを使用してコンテンツの可用性を維持する
    • SM_SBP9 –コンテンツオリジンへのアクセスを制限して既知のエンティティのみを許可する
    • SM_SBP10 – Webアプリケーションファイアウォールを使用して、コンテンツアクセスを監視および制御します
    • SM_SBP11 – TLSを使用して、転送中のオリジンからクライアントへの通信を暗号化します
  • SM_SEC6:不正な配布を防ぐために、保存中および転送中のコンテンツをどのように保護しますか?
    • SM_SBP12 –ビジネスおよび法務の利害関係者と協力して、コンテンツ保護要件を調整します
    • SM_SBP13 –ビジネス目標を満たすコンテンツ保護スキームを選択します

信頼性の柱

本家Well-Architected Frameworkと同様、基盤、ワークロードアーキテクチャ、変更管理、障害の管理の4つのベストプラクティス領域からなります。特にワークロードアーキテクチャ、変更管理、障害の管理についてはメディアワークロード特有の質問が挙げられています。

  • SM_REL1:ストリーミングインフラストラクチャは、取り込み、処理、発信、または配信コンポーネントの障害にどのように耐えますか?
    • SM_RBP1 –コンポーネントに障害が発生した場合に、すべてのワークロードの依存関係と予想される視聴者のエクスペリエンスを文書化します
    • SM_RBP2 – AWSへの多様なネットワークパスを使用する冗長ビデオ信号を取り込むことにより、ソース障害に耐えるようにライブストリーミング取り込みアーキテクチャを設計します
    • SM_RBP3 –冗長ビデオパイプラインを実装することにより、個々の処理と発信の失敗に耐えるライブストリーミングワークフローを設計します
  • SM_REL2:ストリーミングメディアのワークロードは視聴者の需要にどのように適応しますか?
    • SM_RBP4 – CDNを使用し、プロバイダーと容量を計画します
    • SM_RBP5 –視聴者の需要に合わせて自動的にスケーリングするようにオリジンサービスを設計する
  • SM_REL3:ストリーミングインフラストラクチャは、発信コンポーネントまたは配信コンポーネントの障害にどのように対応または回復しますか?
    • SM_RBP6 –冗長な発信元にトラフィックを自動的に配信するようにストリーミングメディアワークフローを設計します
    • SM_RBP7 –ライブストリーミングマニフェストを監視して、予想されるセグメント更新パターンを確認し、古さを警告します

パフォーマンス効率の柱

こちらも本家Well-Architected Frameworkと同様、選択、レビュー、モニタリング、トレードオフの4つのベストプラクティス分野で構成されます。内容はメディアワークロード特有の、オリジンテクノロジーの確認やコンテンツキャッシュ、ビットレートコストとのトレードオフといった質問が挙げられています。

  • SM_PERF1:メディアの発信と処理を通じて、メディア配信をどのように最適化しますか?
    • SM_PBP1 –ワークロードに適切なオリジンテクノロジーを選択します
  • M_PERF2:メディアソースの貢献にどのようにアプローチしますか?
    • SM_PBP2 –合理的に取得できる最高品質のソースから始めます
    • SM_PBP3 –特殊なメディアトランスポートおよびアクセラレーションプロトコルを使用する
    • SM_PBP4 –コンテンツプロバイダーとメディア取り込みの間にプライベートネットワーク接続を使用する
  • SM_PERF3:コンテンツ配信のパフォーマンスを向上させるために、キャッシュをどのように使用しますか?
    • SM_PBP5 –コンテンツ配信ネットワークを使用して、キャッシュヒット率を監視します
    • SM_PBP6 –コンテンツのキャッシュ制御ヘッダーが最適化されていることを確認します
    • SM_PBP7 –キャッシュ無効化のRunbookを用意する
    • SM_PBP8 –ネガティブ(エラー)キャッシングを最小限に抑える
  • SM_PERF4:視聴者の体験をどのように監視しますか?
    • SM_PBP9 –実際のユーザーログとメトリックを収集して分析します
    • SM_PBP10 –再生の異常を認識して対応します
  • SM_PERF5:クライアントエクスペリエンスを向上させ、帯域幅コストを削減するために、メディア処理でどのようなトレードオフを行いましたか?
    • SM_PBP11 –ワークロードに合わせて適応ビットレートレンディションの数を最適化する
    • SM_PBP12 –コンテンツタイプと品質目標に適したエンコーディング設定を選択します
    • SM_PBP13 –より高いコンテンツ処理コストを、人気のあるコンテンツのより低い配信コストと交換します
  • SM_PERF6:ライブグラスツーグラスレイテンシーを下げるために、どのようなトレードオフを行いましたか?
    • SM_PBP14 –処理、発信、配信、およびクライアントを最適化して、待ち時間を短縮します
    • SM_PBP15 –不要な処理ステージを削除します

コスト最適化の柱

こちらもベストプラクティスの分野としては本家と同じく5つからなります。特に費用効果の高いリソース、時間の経過とともに最適化の2つについてはメディアワークロード特有の質問で構成されています。

  • SM_COST1:オブジェクトストレージとデータ転送のコストを最適化するための戦略は何ですか?
    • SM_CBP2 –サービス、アベイラビリティーゾーン、リージョン、およびクライアント間のデータ転送を追跡および制限します
  • SM_COST2:コンテンツ処理コストを最適化するための戦略は何ですか?
    • SM_CBP3 –メディア処理タスクのベースラインリソースとスループット
    • SM_CBP4 –メディア処理タスクを並行して実行する
  • SM_COST3:視覚的な品質を維持しながら、配布コストを最小限に抑えるにはどうすればよいですか?
    • SM_CBP5 –客観的および主観的な測定手法を使用して、ビデオ圧縮効率のベンチマークと改善を行います

ホワイトペーパーの日本語化とレンズのWell-Architected Toolへの対応はまだ

Streaming Media Lensホワイトペーパーの概要についてざっとですがお伝えしました。なお、実際にホワイトペーパーを確認してみるとわかりますが、2022/01/30現時点で日本語化はまだされておりません。英語のみのホワイトペーパー(ドキュメント)となります。早く日本語化対応されるとうれしいですよね!またWell-Architectedレンズについては、Well-Architected Toolのカスタムレンズとして作成できるものもあります。(AWS Well-Architected Tool でカスタムレンズを作成出来るようになりました #reinvent | DevelopersIO)しかしStreaming Media LensについてはまだWell-Architected Toolに対応しておりません。とはいえ、本家Well-Architectedもリリース当初はドキュメントベースで評価をしていくかたちでした。Well-Architected Toolのリリース前ですね。([新サービス] AWS Well-Architected Toolがリリースされました! #reinvent | DevelopersIO)Streaming Media Lensについてもいつの日かWell-Architected Toolsに対応することを期待しましょう!

まとめ

AWS Well-Architected Lensesに追加されていた、メディアワークロード向けのベストプラクティス集「Streaming Media Lens」を確認してみました。本家AWS Well-Architectedと同じく、AWSでメディア向けワークロードをはじめるときには一度目を通しておき、また何かあったときに読み返したり適宜レビューができるよう参照先を覚えておくとよいかと思いました。