個性化的1：1觀看體驗正在改變電視體驗。 觀眾可以根據觀眾的設備類型，位置，歷史記錄，人口統計數據和其他數據獲得定向且高度相關的廣告，定制內容，新節目建議以及精確的DRM/中斷管理，而不是一刀切。
但是，將個性化影片流擴展至數百萬觀眾，特別是針對體育等直播節目，幾乎與打棒球賽道一樣具有挑戰性。 觀眾的數量可以大幅波動，在必須觀看的時刻(如啟動，加班和近似比賽)，激增數十萬。 假設您用於支援個性化的基礎架構無法適應和擴展。 在這種情況下，您的個性化體驗將會結束，您的整個企業在OTT世界中可能面臨風險。
清單服務器在個性化中的中心角色
OTT個性化取決於清單伺服器的性能，以生成包含內容，廣告和播放說明的唯一播放列表。 清單伺服器必須與以下依賴關係進行競爭：
- AD伺服器延遲—與AD伺服器的通信可能會增加延遲，這必須納入工作流中，尤其是涉及多個躍點時。
- 營利/報告—廣告播放後，必須將信標傳回廣告伺服器，以測量廣告曝光量並實現營利。
- 網際網路的無狀態方面—要使個性化清單大規模工作，必須針對每個查看者的多個請求維護狀態。
- DRM/身份驗證—清單伺服器必須在數字權限管理(DRM)，會話級加密和身份驗證方面保留選項卡。
- 中斷/內容權限和限制—根據用戶的位置，流式傳輸內容可能受到各種中斷規則的限制，所有這些規則都必須得到精確管理。
- 內容推薦—線上觀眾期望您了解他們並個性化推薦，幫助他們完成搜尋和發現過程。
- 內容本地化—對於重大事件，向用戶提供適當的區域變化非常重要，包括音訊曲目，隱藏式字幕和字幕。
實時個性化流
如本部落格系列第1部分所述，我們的Slicer軟體應用程式會吸收，編碼和打包直播或VOD源。 可以插入廣告邊界，使內容所有者能夠自定義觀看者的體驗。 當廣告被攝入時，也會透過雲端執行的切片器進行處理，以獲得更像廣播般的播放體驗。
當Slicer開始擷取直播或VOD串流時，會持續與我們的後端基礎架構通訊，讓資料庫持續更新可用區段的數量。 清單伺服器使用該數據來個性化每個查看器的體驗。 當播放器請求流時，清單伺服器確定應在清單文件中列出哪些影片和音訊段，該文件充當播放列表。 在每個用戶級別動態更改或自定義清單的功能使您可以定制查看體驗。 在實時視頻的情況下，每隔幾秒鐘就會請求一個新的清單，允許清單服務器在查看條件發生變化時動態應用調整。
清單服務器在個性化視頻流中的中心角色
如上所述，個性化的核心是溝通。 對於大多數OTT業務需求，這意味著與AD伺服器通信，以實時提供有針對性的個性化廣告。 各個數據(包括查看者的IP地址，位置和設備類型)都會提供給廣告決策系統，實際上，我們可以捕獲的所有信息都同時遵守嚴格的PII規則和法規。 結果解決方案非常強大，能夠了解在直播流媒體中投放廣告時與觀眾相關的內容。 該系統還足夠強大，能夠應對各種挑戰，例如管理中斷限制和每個用戶的內容權限，同時支援重要的個性化功能，如內容推薦和其他本地化。
構建可擴展的清單基礎架構
在我們的影片平臺中，清單伺服器負責為每個查看器生成自定義流媒體清單。 它還需要了解上面提到的其他要求，如內容限制和建議。 在此模型中，我們發送一個集成流，這意味着客戶端在流中間等待加載廣告時不會出現“緩衝輪”問題。
為了構建彈性清單交付系統，我們在雲中維護分布在全球不同地理區域的清單生成伺服器群集。 例如，在美國，這些伺服器被組織到全國的五個地區。 當來自美國的玩家對新流媒體的請求發出時，該請求將隨機路由到美國的某個區域。
“‘群集”挑戰
這可能看起來與直覺相反，但這樣做是為了防止級聯故障模式。 大部分美國觀眾都在美國東部地區。 如果我們將它們全部路由到離它們最近的區域，而我們的雲提供商在該區域遇到故障，我們的大多數觀眾都會遇到這種故障。 更為復雜的是，如果所有觀看者都刷新流媒體，而我們現在將觀眾引導到下一個最接近的健康區，我們將遇到“雷鳴般的群集”問題，即失敗區的所有觀看者現在都會跑到下一個最近的區域。 由此產生的意外流量高峰可能會導致二級故障，直到新區域中的系統能夠擴展以滿足額外需求。
相反，隨機分發我們的美國查看器有助於減輕任何初始故障的影響，並使我們能夠將故障轉移流量平均分配到其他健康區域。
在我們的流式平臺中，我們將清單伺服器負載分布在各個區域中。 這可防止在觀眾人數激增時任何特定區域超載，尤其是在故障轉移期間觀眾突然轉移到相鄰區域時。
我們的每個區域都有一個單獨的數據存儲，專用於存儲相關會話數據。 查看器路由到某個區域後，我們將爲該查看器創建一個會話，並將其保存在該區域的會話羣集中。 該會話是有關查看器的大量數據，以及客戶提供的有關如何爲該查看器自定義會話的參數。 爲了克服因特網的無狀態性質而帶來的挑戰，清單服務器將爲返回給播放器的清單中包含的每個會話構建URL。 隨後來自播放器的請求將直接路由到創建和存儲查看器會話的區域(而不是隨機路由到其它區域之一)。
如下麵的三個圖表所示，不同的活動可能有許多不同的要求，具體取決於觀眾的規模以及觀眾是當地的還是地理位置分散的。 看看三個例子，說明廣播公司在支援直播活動時所面臨的基礎架構挑戰。
在第一個場景中，我們將舉辦飲食競賽(是的，我們將其中一個項目進行直播)，因為它展示了分布式但觀眾規模較小的情況。 也許有一天美食比賽將成為主流，但目前，這些比賽仍是吸引廣大地區少數觀眾的特殊活動。 清單伺服器負載可輕鬆分散在多個區域和清單伺服器群集上。 在這裡，您可以輕鬆插入適合每個地區的廣告，並能夠管理權利和中斷，從而顯著地體現個性化的價值。
德克薩斯州足球錦標賽的場景發生了很大變化，在這場比賽中，觀眾人數眾多，所處的地理區域相同。 我們通過幾種方式來處理這一問題。 如上所述，我們發現我們可以將查看者分配到位於鄰近地理區域以外區域的清單伺服器，而不會影響查看者的體驗。 此外，我們還擁有一個系統，可監控每個區域的觀看人數級別，並可根據需要自動啟動每個區域的清單生成伺服器。
我們可能會根據NBA總決賽等大型活動的預期收視率預先調整規模。 然而，我們的自動縮放系統在許多活動中，無需預熱即可處理近100萬觀眾。 除了提高可伸縮性之外，還能夠以與區域無關的方式在清單伺服器之間即時分散負載，這大大提高了網路中的可靠性和冗餘性。
播放器請求和廣告信標
業界的許多變化和趨勢使雲擴展比以往任何時候都更加重要。 一個主要驅動因素是播放器發出的請求之間的間隔縮短。 我們標準的線性直播8秒“下一步是什麼”播放器請求被驅動到5秒，對於低延遲至關重要的流媒體，它的速度可達每2秒。 這主要影響CPU利用率，因爲服務器必須響應4倍多的請求(每隔2秒，而每隔8秒)。 此外，現在還必須比過去更頻繁地檢查中斷和內容建議，以避免出錯。
同樣，廣告技術世界也變得越來越復雜和要求越來越高。 對於流中插入的每個廣告，AD伺服器將至少有五個用於報告目的的信標。 需要伺服器端廣告插入(SSAI)解決方案，以確保它發送這些信標，從而使其客戶獲得廣告商的付款。 儘管最少五個信標，但可能還有更多。 事實上，我們曾見過一個廣告有30至100個信標可供報告的個案。
此外，復雜的廣告伺服器網路在我們的客戶活動中也越來越常見。 多個AD網路躍點可能會導致延遲問題。 例如，網路#1可能會說“這是這次休息中的廣告列表”，但只是發現這次休息中的廣告2需要向另一個網路發出請求。 廣告3引入了另外兩個躍點，依此類推。
在上面的示例中，廣告中斷可以使CPU利用率翻倍或翻倍。 直播影片播放器請求可能會將此因子複合10–30 %。
Looking領先—微服務和可擴展性
隨着複雜性的增加，我們採取的步驟之一是將以前由清單服務器處理的不同工作負荷分爲更小的微服務。 我們採取的第一步是將AD伺服器通信和信標轉移到自己的服務中，幫助解決AD伺服器延遲的挑戰。 此廣告代理服務提供了幾種高級功能，我們將在即將發佈的博客文章中詳細討論這些功能。
今後，我們將繼續開發其他微服務，以消除清單伺服器上的更多工作，並提供針對性更強的可擴展性方法。 不久，我們將添加來自多個雲提供商的區域，以適應任何單個雲提供商的故障。
通過將可擴展的SSAI與微服務相結合，我們可以優化伺服器成本，我們的代碼庫結構以及特定於AD流量的其他特徵。 此外，我們還可以克服幾個關鍵挑戰，包括AD伺服器延遲，中斷限制和盈利。 同時，通過將處理負擔分散到多個區域，我們的實時影片流服務可以廣泛擴展並克服關鍵挑戰，使我們能夠可靠地同時交付數百萬個個性化流，而不會給我們的交付網路帶來壓力。
