HyperEdge: An edge CDN infrastructure for cost efficient video streamingのメモ

HyperEdge: An edge CDN infrastructure for cost efficient video streaming

Wei, Dehui and Zhang, Jiao and Li, Haozhe and Han, Rui and Xue, Zhichen and Peng, Yajie and Pang, Xiaofei and Ma, Yan and Li, Jialin

23rd USENIX Symposium on Networked Systems Design and Implementation (NSDI 26)

2026

どんなもの？

ByteDanceのTikTokの動画配信で利用しているPublicなCDNと組合せて動作するHyperEdgeという動画配信ネットワークの紹介。

先行研究と比べてどこがすごい？

通常のWebのCDNを上手く作るという話ではなく、ほぼほぼTikTokのためだけのコンテンツ配信基盤をCDNと組合せて動く形で作る点。 Application側でCDNと組合せるSDKを利用して動画の取得をまず最初の数セグメントをPublicなCDN経由で行い、その間にHyperEdgeに接続し後続の動画のセグメントを取得する。 CDNをそのまま利用可能な状態とする事で、安定性を担保した上で、コストの最適化を行う事が出来ている。

また、このHyperEdgeをDataCenterやRackを借りるのではなく、さまざまなデバイスの余剰リソースを共有するボランティアコンピューティングに近いような構成で構築している点。 ボランティアコンビューティングではなく、世界中の余剰のコンピュータリソースを集めて貸し出す業者を経由して余剰リソースにプログラムを配布してそれをCDNのポイントとする。 そのため、対応OSがLinuxだけではなく、OpenWrtやAndroidにまで対応しているらしい。

技術や手法のキモ

動画の配信方法

Image from Gyazo

Clientはまず動画を視聴する時に、最初の動画セグメントをExternalなCDNから取得する。 そしてその間にTrackerサーバに対して視聴している動画のIDを送信する。 そして、Trackerからその動画のセグメントをCacheとして保持しているHyperEdge Device(Hdevice)のリストを取得する。 Hdeviceはコンピュータなどの余剰リソースを共有している普通のコンピュータなどなのでClientと直接接続するためにNAT Punchingを実施してコネクションを確立する。 そして、その確立したコネクションを利用して複数のデバイスからセグメントをそれぞれ分割して取得する。

クライアントはTrackerから最大で20台のHdeviceの情報を受け取る。 そして、それぞれに接続し最初に接続出来た8台をアクティブな接続先として利用する。 接続はNAT Punchingを実施してP2Pで接続する。 それ以外のHdeviceへの接続はbackup poolとして利用する。 Backup poolはActiveな8台のうちミリ秒単位でレイテンシが悪化した物などと即座に入れ替える。

HyperEdgeクラスタの構築

HyperEdgeクラスタは中央のTrackerと、websocketで接続している。 このwebsocketでは30秒に1度、Hdeviceから統計情報を載せてKeepaliveを送信する。 TrackerはKeepaliveの応答としてダウンロードしておくべき動画のIDの一覧を応答する。 HdeviceはこのKeepaliveの応答を元に新しい動画をダウンロードし、ストレージのサイズやCacheの利用のされかたなどのヒューリスティックに応じて動画のCleaningを実施する。

TrackerはRedisをメインのDBとして構築されており、VideoIDとそれをCachingしているHdeviceのリストとHdeviceの稼動状況を保持している。 稼動状況としては地理的な位置、帯域の消費量、ストレージ利用率などが保存されている。

これらの情報を利用して、TrackerはClientからリクエストされた情報を元に迅速に対応するHdeviceを応答している。 TrackerはまずVideoIDからHdeviceの一覧を取得する。 そして、その一覧からフィルタリングとランキングを行う。 フィルタリングでは、帯域の利用率が高いデバイス、異なるISPや異なる地域のデバイス、互換性のないNATタイプをフィルタリングします。 ランキングでは、メトリクスによる余剰、クライアントとのネットワーク的な近さ、NATマッチング、過去の統計情報(過去の通信が安定的か)を元にランキングし上位20件を取得する。 HyperEdgeのnodeは現在10万台となっており、これらを迅速に応答を行うためのデータ構造となっている。

どうやって有効だと検証した？

お金に関して

コストの分析を行なった。 externalのCDNを利用する場合には30TB/sの転送が実施される。 これよりも安く出来れば、良い。 HyperEdgeのシステム的な運用のコストには、年間で233Mドル、だいたい375億円。 CDNだと360Mドル、だいたい575億円。 1年間で100億円程度のcost savingが出来ている。

導入時の性能検証について

ByteDanceの実稼働ネットワークにおいて、それぞれ約1,000万人のユーザー（計2,000万人規模）を含む2つのグループを対象にした大規模なA/Bテストを通じて実施した。 一方のグループは従来のCDNのみから動画を配信し、もう一方はHyperEdgeシステムを利用して、毎日数十億回にのぼる再生データを1ヶ月以上にわたり測定・比較した。

動画転送速度としてはHyperEdgeはCDNとほぼ同等の転送性能を示した。 転送速度の差はごくわずか（中央値で2.89%差）で、99パーセンタイルのTail Latencyにおいても、その差は2.58%以内に収まっている。 これは、CDNよりもネットワークの品質は悪いが、並列ダウンロードなどでカバーされている。

動画の滑らかなLoadingに関しても、リバッファ発生率は中央値でCDNより6.41%高いのみ、時間も中央値でCDNの3.41%以内に収まっている。 最初のSegmentをCDNからダウンロードを継続することでユーザには気付かせない品質を提供出来ている。

接続確立時間についてはCDNと比べてSLOを超過していたが、最初のSegmentをCDNからダウンロードを継続することでユーザには気付かせない品質を提供出来ている。

セグメントサイズは10sとする事でユーザの体験がもっとも良くなる事を確認した。

結論としては、サービスの特性もあるが、ExternalのCDNとユーザ体験としては大きな差がない事を確認した。

議論はある？

  1. ISPとの関係
    • 通常のISPは企業向けなど帯域で課金しているが、toCでは固定の価格で提供している。
    • このシステムはそれをabuseしているのであまりよくないかも?
    • とはいえ、これはISPとByteDanceが協調してEdge Deviceをおければ解決するので一緒にやろ?としている
  2. プライバシーとセキュリティ
    • Hdeviceに保存するのは統計情報で動画もPublicなものだけ
    • ClientもP2PのIPしか分からん状態にしている
  3. デバイスのリソースとのノイジーネイバー問題
    • ひとまず、デバイスの80%のリソースを使うようにしている
    • ただ不安定な所があればCDNにFallbackするのでユーザには影響はない
  4. レンタルしつづけるのはちょっと
    • 最終的にはユーザ参加型のP2Pで作りなおしたい
    • レンタルしないと、需要と供給をマッチングするのが難しいよね
    • 需要供給の解決方法を考えるか、共存を考えないとね

次に読むべき論文

感想

開発人数

Next, HyperEdge deploys around 20 dedicated servers to run HyperEdge trackers and management services in ByteDance’s data centers for 30 TB/s of peak traffic. The cost of running these servers (including hardware, network, power, and maintenance) is comparable to other cloud compa- nies, at roughly $72K per year. Lastly, for 30 TB/s of traffic, we employs 20 dedicated engineers and system administra- tors to maintain HyperEdge. With an average annual salary of $100K, the manpower cost is roughly $2.4M per year.

Trackerは20台の物理サーバで動いていて、開発者は20人らしい。 だいたい1人あたり1500万円くらいの給料らしい。

1つのシステムと考えると20人は結構潤沢かもしれない。

Image from Gyazo

全体のコストでみると、このコストを20人で管理は凄い。

余剰リソースの販売

余剰リソースをコンピューティングに利用するのは、ボランティアコンピューティングなどでそれなりに歴史はあると思う。 それをインターネットで帯域を消費するシステムとして利用しているのは面白い。 ちょっと、abuseみはある。

というか、ルータやAndroid端末まで、余剰リソースをレンタル出来るという事だが、これは本当に、みんながお金もらっているのだろうか? 侵入された端末が勝手に登録されて売られてたりしないのだろうか?

TCP Unfairness

Image from Gyazo

P2PでUDPで動画を分割して並列にダウンロードするらしい。 単純にTCPが負けちゃいそうに見える。 こんな帯域出すNodeがそこらにぽこぽこ居ると、他のサービスのTCPが負けちゃう気がする。 これが増えるのは、インターネット的にあまり良い方向ではないんじゃないかなぁ。