17直播SRE團隊的關鍵武器,靠容器標準化IT架構搶速度

2018.02.17 iThome / 王立恒 撰文

原文出處: https://www.ithome.com.tw/people/121264

成立未滿3年的17 Media沒有老舊系統包袱,可以大膽採納新技術,不僅成立SRE團隊,用公有雲容器服務作為基礎架構,還導入基礎架構即程式碼的新興觀念,即便面臨直播產業的高強度競爭,也有IT作為堅強後盾

17 Media資深產品科技副總裁李昀樵

結束一整天勞累的工作,回家打開手機、平板瀏覽各類直播節目,已成當代大眾的舒壓管道。成立未滿3年的直播平臺17 Media,累積了2,700萬個使用者,以超過50%的市占率坐穩臺灣直播龍頭,近年開始將業務版圖拓展至鄰近的香港、日本,今年還要以自家IT技術為基礎,加強即時互動性,往影音3.0發展。然而直播產業相當競爭,大型社群平臺如臉書、YouTube、Instagram、Line也相繼推出直播服務。強敵環伺之下,如何讓服務快速上線,也是17 Media資深產品科技副總裁李昀樵所面對的重大挑戰,而他構思的IT布局,「都是為了縮短上線時程。」

草創初期,17 Media的IT架構就碰上相當考驗,除了系統擴充性不佳,系統容錯系也不高,只要觀看人數增加,服務就容易當機。不僅如此,李昀樵表示,最初17 Media選擇使用客製化的通訊協定(Protocol),亦導致直播品質不佳。因此,17 Media展開一場IT架構大改革,「我們的故事很像《矽谷群瞎傳》的劇情」,在這場變革之旅中碰上許多戲劇性發展。

從2016年開始,首先通盤捨棄自家開發的通訊協定,改用標準RTMP協定外,也幾乎重新開發整套API,「就是要維持IT競爭力」,李昀樵認為,IT最關鍵的兩大要素,「就是快跟穩定」,必須讓工程師所有的專注力集中於開發新功能,而非花費精力維運基礎架構。

靠SRE團隊把關部署工作

李昀樵表示,目前17 Media的IT分工中,除了後端團隊負責開發、測試新功能,每天也會開發新版本容器映像檔,將程式碼提交至版本控制系統Git。為達到開發維運一體化的目標,現在17 Media亦有SRE(Site Reliability Engineer,網站可靠性工程師)團隊。而SRE團隊的職責,得要管理17 Media的基礎架構、資料庫、公有雲容器部署,以及建置開發環境。

如果要縮短開發者推出新功能的周期,「就必須讓開發環境非常接近正式環境」,因此,李昀樵表示,SRE團隊也會利用容器,替每位工程師建立一個獨立開發環境。而容器占用的資源不多,不需要花費過多成本外,該員所開發的程式碼上傳至正式環境時,幾乎不會產生相容性問題,「所有的IT策略,都是為了能加快上線時間。」

而SRE團隊每天最重要的例行工作就是部署程式碼,相比傳統大型公司以周計算的部署頻率,「17 Media每天都必須執行部署工作」,李昀樵表示,當程式碼部署至半正式環境,通過End-to-End測試後,便上傳至正式環境。而如此工作方法,也符合最新的DevOps工作觀念:「少量多次」,減少每次上傳至正式環境的程式碼數量,拉高部署頻率,藉以降低每次更新的風險。現在國外也相當流行自助IT服務的概念,「不過我們不會做到如此徹底」,他解釋,如果要打造徹底的自助式IT服務,必須建立完整的測試、監控流程,而一旦花費多時間進行測試工作,便會嚴重拖累開發進度。不過李昀樵也清楚,求快便會拉高風險,「必須搭配各項機制降低風險」, 因此,現階段程式碼部署至正式環境的流程,仍要靠SRE把關。

同時,IT團隊的開發流程也有導入持續整合(CI)的工作方法,除了使用Jenkins外,17 Media也有導入CI服務CircleCI。李昀樵表示,該服務與GitHub整合相當完整,可以自動整合GitHub上每個版本所提交的程式碼。此外,每一個更新檔都必須撰寫測試,並通過建置流程,才可以合併至主幹。

同時,結合容器技術,開發者也可以在本地環境建立一個迷你叢集,在上傳程式碼前,可以先在規模非常小的正式環境下先行執行服務,「從本地端就開始把關程式碼品質。」

建立監控機制,把關系統運作狀況工作

不僅如此,SRE團隊也有24小時的On-Call制度,負責監控系統運作。為了加深數據應用,17 Media也建立一套完整Log監控制度,李昀樵表示,該團隊監控的資料顆粒度非常細緻,「細至追蹤每個函式的呼叫時間」。而SRE團隊也將各項系統的效能表現,制定量化指標,做為系統發布警報的標準,並且透過Slack自動發布警報。他表示,透過布建許多監控工具,SRE團隊可以快速了解基礎架構當前的大致運作狀況,「我們追蹤至少100至200項系統數據。」

例如,如果開發者上傳新版本的程式碼,將會導致資料庫的QPS上升兩倍,SRE團隊就得繼續深入追蹤,「雖然不會導致當前服務當機,但會對資料庫產生相當壓力。」除QPS外,SRE也會追蹤資料庫的延遲時間,一旦延遲時間從1ms飆升至5ms,「這就是非常嚴重的問題」,當下就一定要排除。

而根據事件緊急性,17 Media也將警報分成兩類。最緊急的事件分級為P0,次嚴重的則為P1。當碰上P0等級事件,SRE團隊會緊急將維修工作分派給相關負責人,而當事人必須當下放下手邊的任何工作,立即排除問題,「而P1則是隔天上班日再進行修復。」

手動部署工作拖累開發速度

起初,17 Media的IT架構並沒有導入容器技術,當程式碼開發完成後,工程師得要自行手動打包、上傳。李昀樵表示,如此工作流程有許多痛點。首先,部署工作自動化程度不高,導致出錯機率高。再者,過程非常耗費時間,碰上這些問題,也讓17 Media萌生使用Docker容器技術的想法。

一開始17 Media選用AWS Elastic Beanstalk作為切入點,「其底層就是容器技術」,不過礙於PaaS的僵固性,使用至一定程度時,17 Media開始轉用AWS容器服務ECS。

李昀樵表示,使用Docker容器技術並不會對開發者造成困擾,「由於我們有劃分開發團隊及維運團隊」,即使基礎架構有所異動,程式碼依舊是打包成Docker容器。而使用容器技術的好處,就是可以快速建置多種環境,如半正式、正式環境,「使用容器映像檔,可以快速建立標準化的IT環境。」

同時Docker的可攜性非常高,李昀樵解釋,17 Media的正式環境是使用Linux作業系統,但是開發者在本機的Mac環境,也能建立同樣的環境,讓開發者擁有更多自由,「想要快速讓服務上線,就要減少各IT環境間存在的摩擦力」,而透過容器技術,可以提高各環境一致性,他笑著說,這樣才不會發生「程式碼可以在我電腦上執行」的窘境。

(攝影/洪政偉)
想要快速讓服務上線,就要提高環境一致性,減少各IT環境間存在的摩擦力。── 17 Media資深產品科技副總裁 李昀樵

Kubernetes可以加強部署彈性

雖然該公司從2016年就開始使用容器調度工具,不過李昀樵表示,當時是使用AWS ECS的內建調度服務,現在17 Media已準備要導入Kubernetes,「目前非正式環境已經開始使用Kubernetes,因為此技術可以讓IT變得更有彈性」,而李昀樵追求彈性的原因,就是在求快的同時,也能降低風險。他舉例,採用金絲雀部署(Canary Deployment),即使程式碼存在系統臭蟲,部署過程中馬上就可以發現問題,藉以提高開發速度。同時,Kubernetes也讓開發者可以更簡單在本地環境中,複製一個正式環境的鏡像,讓開發環境、正式環境的組態設定更趨於一致。

用Terraform加速基礎架構建置速度

由於17 Media的IT架構高度仰賴公有雲,IT團隊也必須思考如何更快複製出另外一套半正式、正式環境,「也因此我們也引入了基礎架構即程式碼(Infrastructure as Code)的概念」,李昀樵表示,目前IT團隊使用的工具是由HashiCorp推出的基礎架構工具Terraform,每個雲端環境的組態設定,都有一套專屬的Terraform模板。

Terraform定義了一套標準格式,「而此規範可以描述雲端環境的長相」,李昀樵舉例,假設開發者所需的雲端環境,是由10種相異服務組成,便可透過Terraform定義的語法,撰寫出完整模板。而系統也會自動比對當前基礎架構與新版組態設定的差異,一旦有異動,Terraform也會補齊相關服務。

而Terraform帶來的價值,就是讓開發者可以快速複製一套公有雲環境。他表示,雖然建置AWS ECS環境不會花費過多時間,但加上周邊配置如MySQL、AWS RDS、負載平衡器、CDN的建置,至少會花上一至兩周,不僅如此,手動點選公有雲組態設定,往往會發生許多錯誤,「在導入Terraform後,開發者只要開啟所需要的模板,系統便可自動建置基礎架構環境。」

支付高額公有雲成本保障服務品質

而17 Media大量使用者帶來的流量,對基礎架構也是一大考驗。不過李昀樵表示,導入容器技術的助益有限,「流量仍得靠擴大基礎架構規模解決」,雖然容器可以更精細地劃分運算資源,提高使用效率,但它仍仰賴VM作為容器主機,只要VM數量不變,就無法有效排解流量。目前,17 Media基礎架構的CPU使用率維持在30至50%,「寧願讓運算資源閒置,也不要提高風險」,由於17 Media面對觀看直播的一線使用者,「我們要不計代價提供穩定服務」,李昀樵表示,只為維持基礎架構穩定運作,光是1個月的公雲基礎架構費用,就得支出高達數萬美元的成本。不過即便如此,在降低費用與維持服務品質的抉擇,李昀樵也會毫不猶豫地選擇後者。

他笑說,比起廣告費用,其實投資基礎架構較為便宜,而且更直接影響使用者滿意度。他表示,以工程師角度出發,多數人的技術決策,多半選擇當系統負載率飆高至一定程度後,才進行水平擴充,「但以商業角度考量,無疑都是增加營運風險」,只要知名直播主上線,就會對系統帶來非常大的壓力,即使緊急水平擴充也無法分散流量壓力。

導入敏捷開發,新功能兩周就上線

不只引入新技術、新工具,在2015年時,17 Media內部就已經導入敏捷團隊,以兩周為單一循環進行開發,目前該公司已經有3至4個敏捷團隊同步運作。首先,產品經理規畫工作目標後,開發者再根據其計畫,估算兩周內可以完成的進度。而一個敏捷團隊的除了產品負責人、敏捷教練外,同時,Android、iOS開發者也會一同介入。李昀樵表示,當中17 Media也嘗試過1周、2周、3周的周期,最後才挑選至2周作為一個循環。他解釋,如果敏捷開發周期拉得越長,就會趨近於傳統瀑布式開發,開發工作可能更有效率,但是上市速度就慢。由於直播產業相當競爭,一旦觀察到任何使用者需求改變,新功能就必須馬上上線。

大膽擁抱新技術維持競爭力

成立不滿3年的17 Media,其擁有最大優勢就是「沒有老舊包袱」,現今各項IT新技術蓬勃發展下,也可直接擁抱最新觀念,「不過我們也耗費多時,才找到屬於自己的模式。」李昀樵表示,未來17 Media也會朝多媒體平臺發展,除了直播主自行產製內容的UGC模式外,該公司亦開始著手開發自製內容,「但回歸源頭,這些決策都是要維持17 Media的競爭力。」

CTO小檔案

李昀樵
17 Media資深產品科技副總裁

學歷:臺灣大學電信工程學研究所

經歷:在2012年至2014年建立新創公司SMD Lab.,在進入17 Media後先任職後端團隊,而現在則為17 Media資深產品科技副總裁,帶領近百人團隊規畫技術決策及開發新產品,現在17 Media的IT架構也全面使用公有雲容器服務

公司檔案

17 Media

● 成立時間:2015年
● 主要業務:開發直播App,讓領域名人、網路紅人與素人進行直播或錄製節目
● 總部:臺北
● 員工數:350人
● 資本額:3億5,450萬元
● 創辦人:黃立成
● 執行長:潘杰賢

公司大事紀

● 2015年7月:17 Media成立
● 2015年7月:17 Media App正式上架
● 2015年9月:App在中國、美國App Store熱門排行榜上排名第一
● 2015年10月:成立SkyEye團隊專職監控直播,避免出現不當內容
● 2016年12月:新加坡交友平臺Paktor入資17 Media
● 2017年5月:M17 Entertainment集團正式成立
● 2017年7月:17 Media香港分公司成立
● 2017年9月:17 Media日本分公司成立
● 2017年12月:提供用戶以比特幣及以太幣支付即時互動內容