1,650萬人全球線上影音首播大考驗，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季的放映壓力。