winds.from.oz 技術メモ

Tag: Cloudfront

MediaLiveでライブ配信システムを構築する

Posted:   |   Categories: AWS   |   Tags: Cloudfront, LiveShell, MediaLive, MediaStore

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

映像データは下記のように流れる。

カメラ、マイク -> ローランドの映像ミキサー -> LiveShell X -> MediaLive -> MediaStore -> CloudFront -> 各プラットフォームのプレーヤー

この手順では、MediaLive、MediaStore、CloudFrontの設定について行う。

このうち、MediaLiveには

  1. インプット( LiveShell X からの RTMP を受け取る )
  2. チャンネル( 映像データをエンコードする ) で構成されている。

またMediaStoreはストレージで、MediaLiveでエンコードされたデータを保存する領域になっている( MediaLive だけでは映像を保存できない、かならず別の保存する領域に転送する必要がある )

CloudFrontは大規模配信で使われるCDNで、 複数ユーザにキャッシュを見せる事で、MediaStoreの負荷を下げるために用いている。つまりCloudFront無しでも配信は可能だが、CloudFront無しだとライブ授業のユーザー数には耐えられないため、導入しておいた方がよい。

MediaStore( 映像チャンク置き場 )を作る

MediaStoreは「MediaLiveでエンコードされた映像のチャンクを置く場所」として必要( MediaLiveにはストレージが無いので、別途つくる必要がある ) MediaLiveを作る際にMediaStoreのアドレスを指定する必要があるので、事前に作成する。

チャンネルを作成する

MediaLiveで映像データをエンコードするチャンネルを作成する

管理画面 からログイン

設定例

入力名: dev 入力タイプ: RTMP (プッシュ) Network mode: Public 入力セキュリティグループ: 既存の使用、0.0.0.0/0 入力の送信先: SINGLE_PIPELINE

  1. [チャンネルの作成] をクリック

  2. ( その環境にMediaLive用のロールが無ければ作る必要があるので )テンプレートからロールを作成する

チャンネルテンプレートは[ Live Action ]をベースに作成する事にした。 ( このテンプレートの内容は時代によって変わるようだ。以前よりテンプレートも増えているし内容も異なる )

[ Channel class ] は [ SINGLE PIPELINE ]を選択する。　標準では[ STANDARD ]になっているが、正しく冗長化を試みるとなると、インターネット回線を2つ用意するような話になるので、シンプルに[ SINGLE PIPELINE ]で設定する。

Read more...

nuxt向けのCloudFront設定

Posted:   |   Tags: AWS, CloudFront, nuxt

nuxt用の設定についてまとめた

nuxt.js向けのCloudFront設定をまとめた。

オリジンとCDNの関係

CloudFrontでは、複数のオリジンサーバを指定可能。例えば s3 や 複数のALBで振り分ける事ができる( Layer7レベルでの振り分けが可能 )、 更にALBはリスナーに設定を追加することで複数のドメインをLayer7レベルで振り分けられる。

  1. ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する
  2. CloudFrontで、 ALBの名前を指定する www-36?????.ap-northeast-1.elb.amazonaws.com ( CloudFront から ALB に要求されるFQDNの情報は飛ぶ )
  3. Route53 で、ユーザーがアクセスするFQDNをCloudFrontに振り向ける

それぞれの手順を下記に残しておく

1. ALBで、FQDNで正しいターゲットグループに振り分けられる用に設定する

ロードバランサー -> リスナー -> ルールの表示` をクリックして、Layer7設定を確認。

  • 目的のFQDNが存在するか?
  • ALBからの転送先が存在するか?
  • 転送先のターゲットグループにはサーバは存在するか? を確認する。

CloudFront設定

設定する前に…

  • SSL証明書はAWSで発行済か( CloudFrontのSSL証明書はバージニア北部に存在する必要がある )
  • ALBの設定はできているか
  • s3にログ用のバケットはあるか

を確認したほうが良い( でないと、CloudFrontの設定をやり直す必要がある )

オリジンサーバとしてALBのFQDN( dandelive-eikoh-51???.ap-northeast-1.elb.amazonaws.com のようなもの、EC2の「ロードバランサー」のページで確認できる)

オリジンサーバでALBを登録後、振る舞いとして /nuxt/配下を追加する。 デフォルトはキャッシュしないが、/nuxt/配下はキャッシュする。

  • Minimum Origin SSL Protocol : TLSv1
  • Origin Protocol Policy : HTTPS Only ( 暗号化された通信だけにしたい )
  • Origin Response Timeout : 60
  • Viewer Protocol Policy : Redirect HTTP to HTTPS ( http接続はhttpsにリダイレクトして暗号化を促す )
  • Allowed HTTP Methods : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
  • Origin Keep-alive Timeout : 60 ( コネクションを再接続するコストを払わない )
  • Cache and origin request settings : 「Use a cache policy and origin request policy」と「Use legacy cache settings」がある。以前は legacy に該当する設定しかなかった。 最初に設定するオリジンはキャッシュしないポリシー「CachingDisable」を選択する。
  • Origin Request Policy : Managed-AllViewer ( 全てのリクエストヘッダ、クッキーなどをオリジンに通す )
  • Alternate Domain Names (CNAMEs) : test.net ( 都度、変えること )

Behaviors を追加する

CloudFrontを設定( ディストリビューションの設定 )を追加するウィザードで設定されるのは、 デフォルトのアクセスだけなので、 /_nuxt のようなURLごとの設定の場合、設定を追加する必要がある。

Read more...

MediaLive+MediaStore+CloudFrontで手軽に動画配信

Posted:   |   Categories: AWS   |   Tags: CloudFront, MediaLive, MediaStore

2018年初頭 ライブ配信基盤を AdobeMdiaServer から MediaLive によるライブ配信に切り替えました。 2020年以降ですとVimeo Liveが有力候補です。

背景

  • 動画配信システムだけで良いのでシンプルに立てたい( カメラの映像を手っ取り早くユーザに届けたい )
  • 必要なときだけ配信システムを立てて終了したい。
  • 似たような案件ができたときに、似たようなシステムをスピーディーに構築したい
  • 現状、EC2 で AdobeMediaServer 立ててライブ配信している
  • AdobeMediaServer のバージョンアップ? <- それに伴う検証したいか、というと検証工数を割きづらい…
  • その点、AWS 上のサービスなら、後から機能追加があったりする。
  • 今回は使っていませんが、CMAF 対応が追加された。機能追加の検証をクラウドベンダがやってくれて、我々はその時間をもっと別な事に使える。あるいは早く帰れてハッピー。
  • 逆に「我々は配信方法で独自のチャレンジをして差別化を狙うぜ」には向いてない(現状、弊社的にそこでチャレンジはしてない)その観点でのチャレンジは EC2 上で構築した方が様々な戦術がとり得る
  • 何か仕様変更に伴う負荷上昇(対応ビットレートの追加とか)に対する検証工数がビジネスに繋がりにくい

なぜ、MediaService?

  • AWS で費用をまとめられる。あとトラフィックが増えた場合、ネットワーク費用のディスカウントができるかもという。
  • lambda から配信システムの起動/終了とかできそう
  • Azure も魅力的に見える。ただ CLI や API での操作ってどうやるんだろうか、という調査に時間とられそうだった(その点、AWS なら手軽に CLI で操作できるのは知っていった)

システム構成

カメラ -> エンコーダー -> MediaLive -> MediaStore -> CloudFront -> Safari

CDN でコストを下げつつ、ライブ配信したい構成ですね。

それぞれの役割は

  • MediaLive: RTMP などカメラからの情報を受け付ける。目的の動画フォーマットにエンコードする。ただ、これ自体にはストレージ機能は無い。

  • MediaStore: CloudFront と経由するためのストレージ

  • CloudFront: MediaStore に貯められた

それぞれを構築する順序だが、MediaLive の設定で「どこに動画データを貯めるのか」という設定が必要なため、 MediaStore の設定から行う

Read more...

CloudFrontに関する雑多なメモ

Posted:   |   Categories: AWS   |   Tags: CloudFront

障害時の対応に付いて

AWS - Amazon CloudFront の障害に備えてフェイルオーバーを設定する

ログフォーマット

s3, MediaPackageをオリジンとして使った時

ウェブディストリビューションでの Amazon S3 オリジン、MediaPackage チャネル、およびカスタムオリジンの使用

TTLがどのように効くのか

【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました！ ｜ Developers.IO

パスパターンはワイルドカード

このため、HLSを配信するCDNは様に設定しました。

/studio*-lq.m3u8
/studio*.m3u8

重要 エラーページについて

『どの程度エラーページを保持するべきか』という設定がある

エラーレスポンスのカスタマイズ - Amazon CloudFront

CloudFrontのエラーキャッシュのTTLを変更する - Qiita

カスタムオリジンの話 別ドメインをオリジンとする。大抵のサービスはこれなのではないか

カスタムオリジンの場合のリクエストとレスポンスの動作 - Amazon CloudFront

初期設定

参考 キャッシュしないCloudFrontを設置する | // sakura note

Minimum TTL / Maximum TTL の話 一覧がある

【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました！ ｜ Developers.IO

「Mimimum TTL / Maximum TTLはヘッダより強い」
「ブラウザのキャッシュはヘッダが優先される」
「何も設定しなければDefault TTLの値になる」
くらいのざっくりで覚えておいて、実際に設定する際にこの記事を参考にして頂ければと思います。

CDNのレイテンシ比較

Is TLS Fast Yet? コアな人々が反応してる

Read more...