1,650萬人全球線上影音首播大考驗,HBO如何不怕熱門影集權力遊戲爆量串流

1,650萬人全球線上影音首播大考驗,HBO如何不怕熱門影集權力遊戲爆量串流 雖然AWS提供的隨需擴充服務很好用,但是擴充速度仍不夠快,碰上流量高峰期時,更讓服務執行速度無可避免地變慢,因此HBO IT團隊選擇在AWS環境中部署Kubernetes來優化資源利用率,撐過了《冰與火之歌》第7季的放映壓力 文/王立恒 | 2018-02-10發表 去年結束的《冰與火之歌》第7季,收視率創下該影集的歷史新高,全球1,650萬人同時線上觀看,雖然數字亮眼,卻為HBO線上影音平臺的基礎架構團隊帶來相當大的挑戰(圖片來源/HBO)。 去年7月16日,全球火熱的《冰與火之歌:權力遊戲》正式首播,收視率再次創新高,這一季最高有1,650萬人同時線上觀看。儘管爆量收視流量帶來了龐大收益,但每逢禮拜天晚間的黃金時段,新一集的《冰與火之歌》開播之前10分鐘,負責HBO線上影音平臺基礎架構的工程團隊都會浮現這個問題:「是否能繼續撐住下一季的流量呢?」HBO影音平臺團隊的HBO資深主任工程師Illya Chekrygin在去年一次公開分享時坦言,收視流量會從晚上8點50分開始逐漸攀升,至9點整達到最高峰,「面臨這些流量大軍,也帶給工程師非常大的壓力」,他認為,狀況越來越不樂觀。成立於1972年的大型電視、電影製作公司HBO,40年來除了製作紀錄片、播放運動賽事及脫口秀節目外,也製作過許多膾炙人口的影劇,像是《黑道家族》、《慾望城市》,以及近年風靡全球的《西方極樂園》及《冰與火之歌》。而近年HBO的線上放映管道,主要是透過HBO Go、HBO Now等訂閱服務提供,讓觀眾可以透過有線電視、衛星電視,或是線上串流,並且搭配行動裝置、電腦等裝置觀看HBO所製作的節目。雖然這些數字表現亮眼,不過卻也為HBO工程團隊帶來相當大的挑戰。為了解決流量的挑戰,HBO也開始踏出新的IT架構革新之旅。Illya Chekrygin表示,一開始並未沒有使用容器技術執行任何服務。除了API服務使用Node.js開發外,還有一些服務是使用Go語言開發。同時,HBO所有的服務,也都部署在AWS EC2中執行,讓服務可以自動部署、擴充。他表示,HBO也搭配了外部、內部負載平衡機制,負責處理DNS需求。不過使用Node.js也導致巨大的資源浪費。Illya Chekrygin解釋,使用Node.js搭配EC2的缺點在於,Node.js的程式碼往往只使用CPU的一個核心。他表示,雖然AWS EC2能應付相當程度的網路流量,但它是以雙核心CPU架構為基礎,導致HBO僅使用了整個部署叢集CPU容量的50%。再者,雖然AWS提供的隨需擴充服務很好用,但是擴充速度仍不夠快,而且碰上流量高峰期時,更讓服務執行速度無可避免地變慢。Illya Chekrygin表示,因此HBO必須提前準備2至3倍以上的資源,應付無法預期的爆量事件發生,「導致許多CPU、系統資源都沒有妥善使用。」除了使用AWS EC2外,HBO亦有使用AWS的雲端負載工具ELB,「每個服務間的連線都必須仰賴ELB」,為加強了服務可靠性,只要在任何的時候,ELB和其他資源的使用率發現越過80%,系統就會發出警示,如果超過95%時,HBO就會直接和AWS聯繫。碰上這些挑戰,也逼得HBO必須開始找尋求新技術,「這些問題帶我們找上Kubernetes」,Illya Chekrygin表示,為了導入Kubernetes,IT團隊的首要工作是將所有服務先進行容器化。在2015年年底時,HBO開始在AWS環境中部署Kubernetes。而Illya Chekrygin表示,IT團隊必須向高層證明,「Kubernetes足以應付正式環境的挑戰。」HBO開始自建Terraform使用模板而HBO資深主任工程師Zihao Yu表示,該公司在Kubernetes之旅中,其中一個學到的重要經驗是找到基礎架構管理工具Terraform。一開始HBO是使用一些開源專案,像是Kube-aws、Kops、Kubespray等專案,在AWS基礎架構中部署新Kubernetes叢集。最後,而IT團隊才選中了Terraform,建立了一套專屬的Terraform模板,建置Kubernetes叢集。同時,HBO也有建立高可用性架構。Zihao Yu表示,最初HBO的Master叢集與Minion叢集的架構,就是採用自動水平擴充架構,同時,也有搭配AWS所提供的multi-AZ部署,建立異地同步備份部署。對於Master叢集而言,HBO希望讓該叢集維持一定數量,「一旦某個服務失效,AWS會自動重啟另一份新服務。」而對於Minion叢集,HBO則要讓該類型叢集水平擴充、收縮的速度加快。他表示,Terraform為IT帶來模組性架構,而HBO也為Master叢集、Minion叢集建立了一套專屬的Terraform部署模組。當IT團隊想要新開一組叢集時,只要開啟該套模板,系統自然會從GitHub中找到相對應的組態設定。Prometheus服務隨系統水平收縮而關閉不過在使用Terraform數周之後,HBO團隊也發現了一些問題。Zihao Yu舉例,像是Kubernetes叢集中,HBO也部署Prometheus服務,用於監控AWS EBS、檔案儲存等服務,「由於所用的叢集規模也不停改變」,但有時負責運作的Prometheus的Minion叢集也會無預警關閉,等待Prometheus服務重啟得花上不少時間,HBO也因為這個空窗期而失去了部分數據。第2個問題,則是當碰上一些特定活動,IT團隊得提前擴大叢集規模,「但有時AWS無法及時增加資源,擴充Minion叢集。」新增多種叢集類型,避免服務無預警關閉也因此,HBO開始推出第2套Terraform模組。Zihao Yu表示,HBO開始在該模組中,定義Minion叢集所需要的Instance Type,協助Minion叢集部署在所需要的實例類型中運作。同時,IT團隊也開始新加了不同一個叢集類型,首先是備份(Backup)Minion叢集,他表示,除了它運作在備份叢集上外,其餘都與一般的Minion叢集沒有區別。第2種叢集則是預留(Reserved)Minion叢集,當叢集水平收縮時,這類叢集不會關閉,仍然會持續運作。利用這兩種新類型叢集,HBO可以解決上述的痛點。Zihao Yu表示,假設水平擴充資源不足時,備份Minion叢集會自動啟動,「為基礎架構準備更多資源」,再者,在預留Minion叢集中執行的Prometheus服務,也不會因為系統水平收縮而關閉。使用Kubernetes內建負載平衡機制搞定容器網路除了使用Terraform作為基礎架構管理工具外,Zihao Yu表示,一開始HBO選用的容器網路層,選中CoreOS所開發的Flannel,「相比其他解決方案,它更容易設定」,並且支援所有HBO所使用的CoreOS作業系統。不過HBO發現,當Flannel處理過大的流量時,也會出現不少問題,像是Kubernetes叢集內的Pod網路連線,或者處理外部服務的延遲性開始提高,或是開始出現更多UDP封包遺失的狀況。因此,HBO開始實驗不同的方式解決網路流量的痛點。首先HBO團隊使用了Kubernetes內建的NodePort服務,嘗試在每個Kubernetes叢集都會建置一個ELB節點,「不過AWS水平擴充群組(AWS Scaling Group,ASG)最多只能搭配50個ELB」,Zihao Yu表示,為此,團隊還得要主動追蹤ELB的運作狀況。而第2種嘗試中,HBO在則是搭配Kubernetes內建的ClusterIP服務,並且在Ingress Controller前部署了ELB,「不過這種作法仍然有許多問題」,Zihao Yu舉例,像是Amazon CloudWatch蒐集的數據中,顯示服務開始出現一些伺服器錯誤訊息。再者Ingress Controller碰上暴增流量時,效能表現也力不從心。最後,HBO則是使用了Kubernetes內建的Loadbalancer服務。他表示,在此使用情境下,可以利用Kubernetes可以建置ELB服務,「此種方法,不會受到ASG只能搭配50個ELB的影響。」Zihao Yu表示。同時,HBO也開始嘗試更加多元的開源監控工具。Illya Chekrygin表示,先前HBO還沒有走向容器化服務時,HBO使用相當多Splunk的解決方案。他表示,使用Splunk的解決方案必須仰賴許多客製化工作,並且還需要進行許多調校,才能提供穩定的服務。現在HBO則開始使用了許多新興開源的監控、串流分析解決方案,除了Prometheus外,現在HBO也開始嘗試使用Grafana、ELK、Fluentd等工具。導入Kubernetes後,舊有IT架構漏洞隨之出現Illya Chekrygin表示,在《冰與火之歌》要推出新一季之前,HBO團隊會每周執行流量測試,經過多次修改、測試後,HBO也開始對使用Kubernetes執行服務感到更有信心。他表示,雖然在使用的過程中HBO也發現許多問題,「但這並非使用Kubernetes所造成,而是這些問題原本就存在,只是使用Kubernetes讓它們浮現出來。」不過,Illya Chekrygin表示, Kubernetes讓HBO撐過了《冰與火之歌》第7季的放映壓力。

更多訊息更多資料都在這裡喔!~~~~~~~~~~~~~~~~~~

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *