エッジクラウドプラットフォームであるFastlyのTechOps担当のシニアディレクターであるRyan Landry氏は、スーパーボウルLIVなどの人気のあるライブストリーミングイベント中のトラフィックのピークをどのようにネットワーク自動化を使って管理するかを共有した。
ビデオストリームをできるだけエンドユーザの近くで配信するために、Fastlyは米国中の多数のISPに直接接続されており、ライブビデオトラフィックをパートナーとのこれらの直接パスに維持しようとしている。ただし、トラフィックの需要が増加すると、これらの相互接続ポイントが混雑し、品質に影響を与える可能性がある。ライブストリーミングビューアでは、パケットの損失により、ビデオバッファリングやストリーム品質の低下などのパフォーマンス問題を確認する可能性がある。ユーザのオンラインエクスペリエンスが悪い場合、ユーザの大多数は数分以内にブロードキャストを中止するであろう。
Fastlyには、相互接続ポイントが輻輳し、リンクの使用率がフルキャパシティに近づいたときにアクティブになる組み込みのネットワークオートメーション（内部ではAuto Peer Slasher（APS）で知られており、StackStormでサポートされている）がある。APSは、リンクを輻輳のしきい値以下に保つために、トラフィックのごく一部を自動的に迂回させる。このトラフィックは、通常はIPトランジットを介して、指定されたISPへの代替の最適パスを介して自動的に再ルーティングされる。非常に大きなライブストリーミングトラフィックでは、これは数分で複数回発生する可能性があり、プラットフォームがトラフィックを相互接続パートナーからIPトランジットへの繰り返しの放出を引き起こす。ほとんどの場合、接続状態が維持されるため、プレーヤーがセッションを最初から再開する必要性を減らすことになる。ライブイベントの終わりに向かって、ピークトラフィックが減少すると、APSはそれらのアクションを緩めることができ、効果的に最初の状態に戻る。
リンクの使用率は1つの指標であるが、特定のバックボーンまたはISPネットワークの内部の潜在的な輻輳を必ずしもハイライトするものではない。損失率と再送信率はもう一つの指標であり、Fast Path Failover（FPF）と呼ばれる技術を使用して、Fastlyが観測し、リアルタイムでアクションを実行する。それらのエッジキャッシュは、個々のエンドユーザTCPフローの転送の進行状況を監視する。特定の1つのパスを介してフローが停止しているように見える場合、安定した状態と接続品質を維持されるよう、キャッシュは代替パスを介してフローを転送する自動試行をトリガーする。自動的に迂回されるトラフィックの量が代替パスの利用可能な容量を超える場合、またはFPFが輻輳していない代替パスを見つけられない場合、Fastlyは次にトラフィックをどのように再ルーティングするかについて人による決定に従う。
Fastlyは、経験を通じて、トラフィックエンジニアリングに「オールハンズオンデッキ」アプローチを使用すると複雑さが増すことを学んだ。Fastlyのネットワークエンジニアリングチームは無駄のない効率的なグループであるが、主要なライブイベントのコントロールを担当するエンジニアの数をさらに減らしている。平均して約12人のメンバーがある。彼らは領域を4象限に分割し、それぞれにリードエンジニアを割り当てている。各リードエンジニアは、アラートとしきい値を監視し、必要に応じて象限リーダーに情報を提供する副操縦士のエンジニアと提携している。副操縦士のエンジニアは、それと並行して、リードによって行われた変更の二次的な検証と実証を行う。ダイレクトISPリンクからのトラフィックの自動シフトが利用可能なPOP（Point of Presence）容量の上限に達し始めると、エンジニアがペアで連携して、次にトラフィックを移行する方法と場所を決定する。通常、Fastlyのボーダーゲートウェイプロトコル（BGP）エニーキャストのアナウンスを変更するか、ドメインネームシステム（DNS）管理プラットフォームを介してエンドユーザのPOP選択に影響を与える。
自動システムは24時間365日稼働している。最近、主要な複数日にわたるイベントの1つで、48時間にわたって、チームは、最もアクティブな10個のPOPと相互接続パートナーを通して、APSがネットワークに対して合計349のアクションを実行するのを観測した。APSは重い作業の多くを処理する一方で、チームはシステムの調整とエッジクラウドプラットフォームのパフォーマンスに関する他の要素への対応に時間を費やす。2020年2月、APSはインターネットの状況の変化に応じてグローバルネットワーク全体で2,900以上の自動化アクションを実行した一方で、オンコールエンジニアは500をわずかに超えた数を実行した。
Fastlyのネットワークオートメーションの詳細と、ここで実行されているネットワークオートメーションの実際の例をご覧ください。