工作,生活,休閒,專業,分享,記錄

App Insights JS

Total Pageviews

August 4, 2017

直播問題:HLS 直播內容是不是不需要透過 CDN 來傳播呢?



日前安裝一部 VM 上面安裝 NGINX Server 來做直播服務,透過 RTMP push 上傳直播內容到 NGINX rtmp streaming module,並且轉換成 HLS (m3u8) 格式來播放 (playbackurl),並且連接到 CDN endpoint 來做內容傳遞的播放,預期讓世界各地的 client 可以連接 CDN edge 來觀看直播內容,聽起來這樣的架構很合理吧!(但是,世事不是憨人所想的那麼簡單!待我詳細說來,鏘,鏘,鏘!)

直播內容原本很順利地透過 CDN 傳播到世界各地的 Client Player,但是突然之間,湧入了大量的使用者來觀看直播,結果造成直播內容會停頓,且斷斷續續,甚至有的無法連接播放直播內容,這時候馬上接到電話 “不能直播了,怎麼辦?” (客戶的問題描述永遠是簡單明暸,但是問題永遠是複雜難明,這是資訊人心中永遠的痛!)

接到 outage call,馬上進入測試環境,一測試果然是正常可以使用,資訊人的正規回答就是 "在我的電腦正常啊,可以正常播放直播啊" (這是大部分資訊人會回答的),但是我們身為專業的顧問,必須正視客戶的問題,站在客戶的角度著想,秉持著同理心的心態,提供專業的諮詢顧問服務,這才是我們專業資訊顧問應該有的態度啊。

問題發生的當下,還真的找不出來 root cause 在哪邊,就先以讓服務可以正常使用為主,但是,接下來的一週,仔細的把 Server 以及 CDN 的各項數據資料拿出來做分析,大約發現有幾個可能的問題發生原因,提供來供大家參考。(但是我還是沒辦法確定主要問題發生在哪邊,未來該怎麼防止,解決方案是什麼?)

1. CDN 發現的問題:Cache Hit Rate 為 0%,這也就是表示 CDN edge 完全沒有發揮效用,Client request 都還是回到原始來源(也就是 Streaming VM)來抓取直播內容。
==> 可參考下列各數據表格:

CDN 的頻寬報表

CDN 的流量報表

CDN 的 Status Code (所有 request 的 Hit 數,會這麼多是因為 m3u8 設定為 1 秒一個檔案,所以播放直播會一直來抓取每一秒的內容檔案做播放)
Status Code 304 (Not Modified) 只有 0.33% Hit rate 表示 CDN edge 發揮不到 1% 的散佈功能。

CDN 的 Cache Status report (發現幾乎所有的 Hit 都是 Uncacheable,所以都是回原始內容 VM 去抓取內容。)
UNCACHEABLE - 當資產的 Cache-Control 和 Expires 標頭指出不應該在 POP 上或由 HTTP 用戶端將其快取時,就會傳回此狀態。 這些要求類型會由原始伺服器提供

CDN Cache Hit Rate 為 0% (表示內容的傳遞都並未使用到 CDN Cache 的功能)


2. VM 效能問題:雖然 VM 的網路沒有頻寬的限制,但是從 VM 的數據來看,buttleneck 發生在 Disk IO 的極限,也就是 Disk Read 已經到達該 VM 的最大限制。
==> 可參考下列各數據表格:

VM 的 Network In/Out report

VM 的 Disk Read/Write report

所以得到結論如下:

1. HLS 直播內容透過 CDN 來傳播,無效,等於直接跟原始來源抓取內容,沒有發揮 CDN Edge Cache 的功效。

2. VM 頻寬的大小會受限於 VM 本身 capacity 的限制(如:CPU, Memory, Disk IO等的限制),如果沒有控制好,那麼從網路擠進來的 request 將會造成 VM 的 resource 用盡,有可能會造成 VM Server or Service Crash,需要密切注意這一點。


以上兩點結論是這是使用上的心得,不知道我目前推論的方向是否正確,尚未得到各方資訊的最後證實,在這邊先記錄目前 Survey 的結果,提供大家參考!

#備註:
有一個地方覺得比較奇怪的是:
CDN 最大頻寬到達 320Mbps(這是 CDN 得到的報表)
直播的播放 Bitrate 是 720P @ 3Mbps
所以從 CDN 算出來的 concurrent user 數量是 320 / 3 ,大約是 107 人
可是 VM Network Out 的流量是每 5 秒為 2.5GB(這是 VM 抓出來的報表)
如果拿來算 concurrent connection 的話,則計算如下:
( 2.5 GB * 1024 * 8 / 5) Mbps / 3Mbps = 273
算出來 concurrent user 應該會是大約 273 人
這兩個數字無法 match,目前還不知道怎麼會這樣???