ネットワークの自動化が Fastly ライブストリーミングにもたらすメリット

クリーンでクリアなライブストリーミング体験を実現するには、ネットワーク輻輳の適切な管理が重要です。Fastly のプラットフォームの多くは、24時間体制で、手動介入を抑えながら、自動管理を実行します。第54回スーパーボウルを放映した Fox Sports のライブイベントストリーミングチームの一員として、1年でネットが最も盛り上がる日に、自動化がマジックを実現するのを私たちは目の当たりにしました。ここでは、ネットワークの自動化、少数精鋭のエンジニアチーム、過去に発生した極端な高トラフィックから得た学びを活かし、お客様の大規模なパフォーマンスをサポートした事例を順を追って説明します。

自動化 + エキスパート：ドリームチーム

Fastly のライブストリーミングのプロセスは、国内に多数ある ISP との直接接続から始まります。可能な限りエンドユーザーに近い距離でビデオストリーミングを配信するために、ライブ動画のトラフィックを相互接続パートナーとのダイレクトパスに可能な限り維持します。しかし、トラフィックの需要の増加に伴って、こうした相互接続点に輻輳が発生することは珍しくありません。輻輳の発生で影響を受けるのは品質です。パケットロスの結果、ビデオのバッファリングやストリーム品質の低下などのパフォーマンスの問題に直面すると、ライブストリーミングの視聴者の半数以上が、90秒以内に視聴を止めてしまいます。 

この時点で、組み込みネットワークの自動化（社内では Auto Peer Slasher または APS と呼ばれる）が有効になります。このオーケストレーションは、StackStorm によって支えられています。詳しい仕組みについては、今後のブログ記事で共有していきたいと思います。

リンク利用率が上限に近づくと、チームへのアラートにより APS が起動し、リンクを輻輳のしきい値以下に維持するよう、トラフィックの一部を自動的に迂回させます。このトラフィックは、通常は IP トランジットを介して指定の ISP への最適な代替パスに自動的に迂回されます。ライブストリーミングのトラフィックが膨大になると、この動作が数分間に何度も発生し、プラットフォームは相互接続パートナーから IP トランジットに何度もトラフィックを制限することになります。ほとんどの場合、接続状態は維持されるので、プレイヤーがセッションを最初から再開する必要はありません。

このプロセスの動きの例を以下に示します。アラートを受信した APS が特定のワークフローを実行し、ワシントン D.C. 大都市圏の ISP へのリンクに対して複数のアクションを行い、Slack 経由で Fastly チームに報告しました。

以下のグラフでは、リンク利用率が90%に近づくと、リンクが輻輳ゾーンから抜けるのに十分なトラフィックを APS が分離していることがわかります。

ライブイベントが終わりに近づくと、ピークトラフィックが減少し、APS はこのアクションを解除し、いわゆる振り出しに戻ります。

しかし、リンク利用率は指標のひとつでしかなく、特定のバックボーンや ISP ネットワークの奥に潜む潜在的な輻輳を示すわけではありません。損失率や再送率は非常に有用な情報で、高速パスフェイルオーバー (FPF) と呼ばれる別の手法を使用してリアルタイムで観測し、対処します。エッジキャッシュは、各エンドユーザーの TCP フローの進行状況を監視します。フローが特定のパスを介して停止しているように見える場合、キャッシュのトリガーにより、安定した状態と接続品質を維持できるよう、代替パスでのフロー転送が自動的に試行されます。

自動的に迂回されたトラフィックが代替パスの容量上限を超えた場合、あるいは FPF が輻輳していない代替パスを見つけられない場合、次のトラフィックの迂回方法を決定する必要があります。そこで力を発揮するのが、Fastly のスタッフです。

過去の大規模イベントの経験から、「全員参加型」のアプローチでは、トラフィックエンジニアリングがさらに複雑化することが明らかになりました。Fastly の優秀なネットワークエンジニアリングチームは、すでに極めて少数精鋭の効率性の高いグループになっていますが、大規模なライブイベントの場合は、コントロールするエンジニアの数をさらに減らし、平均で約12人強のメンバーに絞り込んでいます。地域を4つに分割し、それぞれにエンジニアリーダーを配置します。各エンジニアリーダーにはアシスタントエンジニアが付き、アラートやしきい値を監視しながら、必要に応じてリーダーに情報を送り、リーダーが実施した変更の二次的な検証や確認を行います。ISP との直接接続によるトラフィックの自動シフトが配信拠点 (POP) 容量の上限に近づくと、この2人のエンジニアが協力して次のトラフィックの移行方法と移行先を決定します。通常は、ボーダーゲートウェイプロトコル (BGP) のエニーキャスト通知を変更したり、ドメイン命名システム (DNS) の管理プラットフォームを介したりしてエンドユーザーの POP 選択に影響を与えます。このように、ライブイベントのリアルタイム配信を確実に行うため、舞台裏ではさまざまな作業が行われています。

プロセスの実践

上記の自動化とシステムは、毎日常時稼動し、ピークトラフィック中にすべてのお客様にメリットをもたらす永続的な改善策です。とはいえ、トラフィックが急増したときや、大規模なライブストリーミングイベントの準備の際に発揮されるパフォーマンスにはいつも驚かされます。

以下のグラフが示すように、米国のある POP でトラフィックが大幅に急増したため、FPF が起動しました。ここでは、POP の1つのキャッシュが、約 1.8 Gbps をピークに急増イベントが終了するまで FPF フローをプッシュしていることがわかります。これは、この1台のマシンが処理する総トラフィックのごく一部にすぎません。しかし、POP 内の多数のマシンで処理されるトラフィックを合計すると、かなり多くなると推定されます。

これとは別の、数日間開催された大規模イベントを調査したところ、APS システムが大きな影響を及ぼしていることがわかりました。最もアクティブな10か所の POP と相互接続パートナーの48時間を見ると、APS はネットワークに対して合計349件のアクションを実行しています。複雑で面倒な作業は APS が処理するため、チームはシステムの選択肢を微調整することにエネルギーを注ぎ、エッジクラウドプラットフォームのパフォーマンス向上に集中して取り組むことができます。

2020年2月の1か月間を通して見ると、刻々と変化するインターネットの状況に対応するため、APS はグローバルネットワーク全体で2,900件以上の自動アクションを実行しました。一方、すぐに対応できるように待機しているエンジニアの数は500人以上です。つまり、APS はフィールドに十分な数のプレイヤーを配置するようなものなのです。 

ライブストリーミング成功へのカウントダウン

トラフィックの多いライブイベントのストリーミング配信では、膨大な作業量が発生します。そんな中でも、ビルトインの自動化機能、優秀なエンジニアグループ、その背後にパワフルなネットワークを備えた Fastly のプラットフォームは、通常と同じ要領でイベントを処理します。Fastly は、お客様が大切な一瞬を迎えるにあたって必要なキャパシティもテクノロジーも準備作業も熟知しています。お客様にとって、評判、信用、ユーザー体感品質を安心して任せられる存在なのです。