ライブストリーミングの設定ガイドライン

Fastly はパブリックまたはプライベートクラウドのストレージなどにアーカイブまたは録画された HTTP ストリーミング用コンテンツをライブで配信することができます。ライブストリーミングの配信を行う場合、以下のガイドラインに沿った VCL の設定をおすすめしています。不明な点についてはカスタマーサポートまでお問い合わせ下さい。

シールドの有効化

オリジンサーバーに対し特定のシールド POP を指定し Shielding を有効化することで、Fastly ネットワーク内でのライブストリーミングの可用性をより高める事ができます。注目度の高いイベントなどのためにプライマリ、セカンダリのオリジンを設定している場合は、地理的に近いシールド POP をそれぞれのオリジンに設定して下さい。

動画マニフェストファイルとセグメントキャッシュの TTL 設定

HLS などでは、新しいセグメントが使用可能になるとビデオのマニフェストファイルが定期的に更新されます。マニフェストファイルの TTL は、ビデオセグメントの長さの半分以下 (例えば 5 秒のビデオセグメントの場合は通常 1 - 2 秒) に設定することをお勧めします。長時間の DVR やライブストリームから VOD へ変換する場合は、セグメントの TTL をシールド POP で長く、エッジ POP ではメモリから確実に配信されるよう短く (つまり3600秒以下) に設定します。

以下のVCL コードのサンプルを、動画マニフェストとセグメントに異なる TTL を設定する際の参考にしてください。このコードは VCL スニペットに追加して利用することが可能です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
sub vcl_fetch {
#FASTLY fetch

  # Set 1s ttls for video manifest and 3600s ttls for segments of HTTP Streaming formats.
  # Microsoft Smooth Streaming format manifest and segments do not have file extensions.
  # Look for the keywords "Manifest" and "QualityLevel" to identify manifest and segment requests.
  if (req.url.ext ~ "m3u8|mpd" || req.url.path ~ "Manifest") {
    set beresp.ttl = 1s;
    return (deliver);
  }
  else {
    if (req.url.ext ~ "aac|dash|m4s|mp4|ts" || req.url.path ~ "QualityLevel") {
      set beresp.ttl = 3600s;
      return (deliver);
    }
  }

  return (deliver);
}

MIME タイプに応じてビデオマニフェストとセグメントを識別することも可能です。

エラーに対する TTL は短く設定

Fastly は、オリジンからのCache-Controlヘッダーに基づきキャッシュ可能なオブジェクトの TTL を設定するようにデフォルト設定されています。しかし、200や206以外の HTTP ステータスコードレスポンスに対しては、オリジンサーバーから Cache-Controlヘッダーは送信されるとは限りません。その場合、Fastly はオリジンへ大量のリクエストを送信することを防ぐために、キャッシュ対象のステータスコードをデフォルト TTL (通常は 3600秒) でキャッシュします。キャッシュ対象外のステータスコードは、 beresp.cacheableフラグを true設定することでキャッシュさせることができます。

ライブストリームの場合は、ビデオセグメントが数秒ごとに追加されます。ライブストリームトランスコーダーの一般的な設定では、5秒毎にビデオセグメントを生成し、ビデオセグメントが使用可能になり次第マニフェストファイルが更新されるようになっています。ただし、ビデオプレイヤーがまだ使用可能でないセグメントへアクセスを行い、500や503といったエラーレスポンスが返却されることがしばしば発生します。このような場合は、ステータスコードレスポンスをキャッシュ可能にし、短い TTL を設定することで、オリジンに回復する時間 (1秒程度) を与えることができます。

以下は、ステータスコードが200、206以外の場合のエラーレスポンスを1秒間キャッシュする VCL コードのサンプルです。このコードは VCL スニペットに追加して利用することが可能です。

1
2
3
4
5
6
7
8
9
10
11
12
sub vcl_fetch {
#FASTLY fetch

  # Set 1s ttl if origin response HTTP status code is anything other than 200 and 206
  if (!http_status_matches(beresp.status, "200,206")) {
    set beresp.ttl = 1s;
    set beresp.cacheable = true;
    return (deliver);
  }

  return (deliver);
}

ストリーミングミスの設定

ストリーミングミス を設定することで、Fastly サーバーがオリジンからコンテンツを取得する必要がある場合のクライアント (ビデオプレイヤー) でのストリームのダウンロード待ち時間を減らすことが出来ます。ストリーミングミスはチャンクやセグメントと呼ばれるビデオとオーディオオブジェクトにのみ有効化すべきです。

ストリーミングミスを設定に以下の VCL コードのサンプルをご活用ください。このコードは VCL スニペットに追加して利用することが可能です。

1
2
3
4
5
6
7
8
9
10
11
12
sub vcl_fetch {
#FASTLY fetch

  # Enable Streaming Miss only for video or audio objects.
  # Below conditions checks for video or audio file extensions commonly used in
  # HTTP Streaming formats.
  if (req.url.ext ~ "aac|dash|m4s|mp4|ts") {
    set beresp.do_stream = true;
  }

  return (deliver);
}

自動 Gzip 圧縮の設定

以下の表を参考にして、拡張子、または content-type を条件にマニフェストファイルを 自動 Gzip 圧縮することができます。

CORS ヘッダーの設定

別ドメインでビデオやオーディオの再生を行う場合は、CORS ヘッダーを設定します。

試験的な BBR TCP 輻輳制御アルゴリズムの有効化

BBR TCP の輻輳制御アルゴリズムは、ユーザーエクスペリエンスを改善できる追加 TCP 設定です。デフォルトで使用されている、レイテンシベースではなくパケットロスに基づくCUBIC TCP 輻輳制御アルゴリズムとは異なり、BBR は一時的なパケットロス時にも遅延をコントロールしながら帯域を最大化できるように設計されています。

BBR を適用するには、VCL スニペットを利用して以下のコードを追加して下さい。

1
2
3
4
5
6
7
8
9
10
sub vcl_deliver {
#FASTLY deliver

  # set congestion algorithm for client requests
  if (!req.http.Fastly-FF && client.requests == 1) {
    set client.socket.congestion_algorithm = "bbr";
  }

  return(deliver);
}

オリジンタイムアウトの設定

オリジンからライブストリームのセグメントが遅延なくダウンロードされるように、最適なオリジンタイムアウトの設定を行います。例えば、ライブストリームのセグメントファイルが5秒の場合は、Origin Connect 値は1秒、First byte と Between bytes timeout は2秒に設定します。通常、これらの値は Fastly がクライアントのリクエストに適切なレスポンスを返却する前に、別のオリジン (設定されている場合) に対してリトライが行えるように設定します。

フェイルオーバー (フォールバック) オリジンの設定

エンコーダーやリソースの高負荷などの問題による配信障害に備えて、フェイルオーバーオリジンの設定をご検討下さい。

リアルタイムログ配信の設定

ライブストリーム配信に関するトラブルシュートやデバッグに備えて、リアルタイムログストリーミングを設定し、以下のような TCP コネクション、キャッシュ、その他の処理時間に関する指標を vcl_log で記録することをお勧めします。例えば、以下を含めることをご検討ください。

• fastly_info.state (キャッシュヒットまたはミス)
• client.socket.tcpi_rtt (クライアントの往復時間)
• time.to_first_byte (クライアントのリクエストから最初の1バイトを受信するまでの時間)
• time.elapsed (オリジンとクライアントの両方のレスポンス時間、または最終バイトまでの時間を計算するためのリクエスト開始からの時間)
• client.as.number および client.as.name (クライアント IP と関連する 自律システム番号および名前)
• client.socket.tcpi_delta_retrans (クライアントに再度送信されたパケット数)
• client.socket.tcpi_snd_mss (クライアントにレスポンスを送信するために使用される最大セグメントサイズ)
• client.requests (これまでの接続でのリクエスト数)
• client.socket.nexthop (Fastly がクライアントレスポンスを送信しているネットワークパス)
• req.restarts (リクエストの再起動数は再試行が行われていることを示します)
• server.datacenter (リクエストを配信した Fastly POP)
• resp.http.content-length および resp.body_bytes_written (送信されると予想されていたバイト数に対し、実際にクライアントに送信されたバイト数)

これらの指標を分析することにより、スループット上の問題や、ABR プレイバック を利用している場合にビデオプレイヤーが別の品質のストリームに切り替えた原因の調査に役に立つ可能性があります。

サロゲートキーによるパージの活用

Fastly の Surrogate キーを利用することで、特定のライブストリームに関するすべてのセグメントファイル、マニフェストファイルを一度の API コールで Fastly ネットワーク上からパージ (削除) することができます。

ライブから VOD へのスムーズな変換

エンコーダーは通常、ライブストリームしたビデオを VOD 用に変換する際、別の動画マニフェストを生成します。VOD 用のマニフェストファイルがライブ用のマニフェストファイルと同じ URL を利用する場合、ライブ用のマニフェストファイルをパージするか、キャッシュが無効化される (通常短い TTL が設定されているため) まで待つ必要があります。ライブビデオが mp4 でアーカイブに保管される場合は、Fastly の OTFP サービス を利用して配信することをご検討下さい。