從 GCP 故障看 17 Media 工程團隊的災難應變

GCP 在萬聖節隔天發生了三年來最大規模的故障,17 Media 也是嚴重受災戶之一,但它們是如何迅速恢復並改進的?請見本文詳述。
評論
評論

本文來自 17 Media Tech Blog,並獲作者授權轉載,作者Roy Chung-Cheng Lou,軟體和數學愛好者,喜歡透過技術來幫助人和企業。

Google Cloud Platform (GCP) 在萬聖節隔天發生了三年來最大規模的故障,在故障的 12 小時內,因為網路問題造成無法新增機器。這次故障也是個好機會來檢視 17 Media 的 Site Reliability Engineering (SRE) 團隊平日的防護及練習的成果。筆者有幸參與故障排除全程,本文將以一位 17 Media SRE 觀點來介紹當天發生經過,探討為何這次 17 Media 受影響特別大,以及日後的改進事項,與大家一同交流。

17 Media 系統概述

目前主要負擔線上流量的有十組伺服器,全都以容器透過 Google Kubernetes Engine (GKE) 運行,利用 CPU 用量自動擴容。每日尖峰及離峰流量差距約為六倍,尖峰約在晚上 11 點鐘左右,QPS 超過 10,000。這對開發團隊是相當刺激的一件事,因為每天晚上都是個小小的雙十一挑戰,如果不小心寫出了 bug,當天晚上就會收到很真實的用戶反饋。

17 Media 線上系統QPS流量圖,每日峰值約在 11:00 pm,凹下去那塊就是故障當晚的流量。

17 Media 的主要用戶分布於亞洲及美國,主力開發由台灣團隊負責,整個後端程式由 Golang 所撰寫。為了要讓開發團隊更為敏捷,SRE 每個上班日都會佈署新版本:透過 Jenkins 在凌晨四點自動將前一日 master branch 的代碼佈署到 staging 環境,SRE 則是在上班後將 staging 環境測試穩定後的代碼佈署到生產(production)環境。

發生經過

事故發生於 11/1 中午,當時一位 SRE 發現 staging 環境的伺服器無法正常部署新版本,一段時間後在 GCP 狀態頁面確定是 GCP 的故障,造成無法開啟新機器。這對我們意味著幾件事:

  1. 無法佈署新版本。
  2. 當 GKE 認為某個容器健康狀態異常而決定關閉時,將會無法開啟新機器替換。
  3. 當系統有擴容需求時,將會無法開啟新機器。

其中 3. 的影響最大。在故障剛發生時(12:00)系統處於離峰狀態,依照過往的流量波形,預估稍晚流量上升後系統會無法支撐。但由於以往 GCP 故障多在一小時內修復,當下我們不太擔心。

SRE team lead 在 Slack 的公告,為了要讓各團隊即時同步資訊所以翻譯成英日文。

數個小時過後從 GCP 狀態頁面仍看不出修復跡象,這時團隊開始緊張了,因為晚上就是高峰期,現有的系統資源肯定支撐不住流量。SRE 團隊很快討論後決定了以下應變措施:

  • 用戶限流
  • 關閉次要功能
  • 卸載運算需求低的容器,改運行關鍵容器
  • 跨雲佈署服務

由於無法佈署新版本,需要改動後端代碼的 hotfix 就不在考慮範圍內,所以這次的應變措施大多以運維的角度出發,跟以往與後端團隊合作的模式不同。以下分別介紹各項應變措施:

用戶限流

當新上線用戶因為限流而被無法使用時,app 會顯示爆氣的 17 寶寶

這是一項限制用戶數的功能。系統會持續追蹤目前線上人數,當發現無法支撐過多的用戶時,會將超出上限的新上線用戶擋在系統外。新上線的用戶會看到超載訊息,而已經在線上的用戶可以繼續保有良好的直播體驗。

我們預估了當前系統可以支撐的用戶數並開啟限制功能。從事後看來這個措施效果最好,因為這是一個開發成熟的功能,當下只要定義人數上限就會產生效果。

關閉次要功能

目前 17 Media 線上服務大多為 CPU bounded。當 CPU 成為限制資源時,我們只好透過重新分配 CPU 的運用來讓重要的工作可以順利完成。對於直播平台來說,最重要的體驗就是直播本身,任何佔用 CPU 的非直播功能都可以關閉。但由於這些改動不能牽涉代碼改變(因為無法佈署新版本)所以可以關閉的功能有限。最後僅關閉了一些可以動態開關的功能,例如排行榜以及發送紅包。

卸載運算需求低的容器,改運行關鍵容器

當可以使用的運算資源無法擴充時,除了關閉次要功能外,另一個方式是重新分配各個服務所運行的容器數量。對於某些延遲要求比較低的服務(例如 job queue worker),可以進一步降低機器數,把運算資源分配給延遲要求高的服務(例如 API service)。

這個方式說起來容易做起來難。由於更換容器不屬於 SRE 團隊日常工作之一,實際執行上只能土法煉鋼進入一台一台機器手動更換,而且更換到第三台後就因為不明原因失敗了。相信大家都有聽過寵物跟牲畜的故事,一時要將牲畜當作一隻隻的寵物看待並不是件容易的事。

手動跨雲佈署

17 Media 的伺服器位於美西,剛好是各大雲服務供應商都有機房的位置。如果當下沒辦法在 GCP 開機器,那就在 AWS 開機器吧!

因為總故障時間長達 12 小時,前面幾項工作也很快的嘗試完了,我們大部分的時間花在跨雲佈署的準備。團隊已經好一陣子沒接觸 AWS 的容器服務,我們不確定哪個解決方案能在短時間解決問題,所以決定分頭嘗試不同的服務,包括 EKS / ECS / EC2 以及 Elastic Beanstalk,能夠嘗試的我們都試了。後來每個人分別遭遇了不同的問題,由於團隊對於 GCP 黏著度較深,導致這項方案完全失敗。現在反思當時應該要所有人專注在同一項 AWS 服務,或許能在時限內找出一項解決方案。

為何 17 Media app 受影響特別大?

這是全球性故障,我們原先預期全球各大 app 都會發生問題。但在網路上搜尋一輪的結果超出意料:各大 app 都運作正常。相較於其他公司,17 Media 受到的影響相當大。事後研究發現可能原因有二:

  • 故障發生於台灣時間中午 12:00,也就是美西時間凌晨 2:00,對於大部分美國的 app 來說已經過了尖峰時段,不會有擴容需求,受到的影響也低。相對 17 Media app 從下午過後流量就一路往上到半夜的高峰,無法擴容的影響相當大。
  • 17 Media 的主要功能集中在少數服務上,當服務所承載的一部分功能耗盡服務資源時(例如CPU),該服務上承載的其他功能也跟著異常,造成全面性災難。其他公司的 app 當下僅有部分功能異常。這也是大家所熟知的單體服務(monolith)與微服務(micro services)在災備隔離(fault isolation)上的差異,但實際發生時感受還是特別深刻。

改進事項

SRE 團隊的風格是快速嘗試且不責怪(blamelessness),在故障後的隔天上班日,團隊就開會檢討了當天的應變以及日後的改進。從事後反思當下的措施,真正奏效的反而是平日已經準備好的災難預備方案。這也讓我們認真檢討改進方案,若日後發生一樣的故障時服務能繼續運行。以下兩項是團隊討論之後得出的改進方案:混合雲及微服務,分別屬於 SRE 及 backend 的工作範疇:

混合雲佈署服務

混合雲佈署是個解決雲服務故障的好方法,畢竟各大雲服務商從來沒有同時故障過;當其中一個雲服務故障時,可以將流量導至另一個雲來排除問題。但由於其運維複雜度以及可能帶來的延遲上升,之前並不是 SRE 團隊的工作重心。這次故障讓我們認真思考混合雲的可能性。我們計畫從無狀態(stateless)服務開始,原因如下:

  • 無狀態服務特性:因為無狀態特性,這類服務很適合隨著流量動態增減機器。也因為這個特性,在這次故障受到影響的幾乎是無狀態的服務。
  • 影響範圍廣:17 Media 的服務大部分為無狀態,如果解決了這類服務的單點故障(single point of failure)問題等於解決了大部分的問題。

一般來說無狀態服務前面有一層 load balancer 分散流量,服務之下會有另一層服務或資料庫(database)來儲存或提供狀態。同時因為資料庫的存取延遲較長,前面多半有一層快取(cache)來降低延遲,同時降低資料庫負擔。也有人稱這為 3-tier architecture

一般常見的 3-tier architecture 結構

這一類運維層面的改動有個重點,必須對開發人員無感,也就是不能造成開發人員額外負擔。

  • 對於下層服務的讀寫比例約為 9:1。
  • 資料庫讀寫:較慢,但因為前面放了快取所以對用戶影響較低。
  • 快取讀取:必須要快,因為大量的資料來自於快取。
  • 快取寫入:也需要快,但因為寫入比例低,對用戶影響較小。
  • 快取跟資料庫之間可以是最終一致(eventual consistency),但是誤差時間不能太長(例如不能超過一分鐘)。

基於以上假設,我們計畫做以下架構改動:在 AWS 建立另一組無狀態服務,前面由 weighted DNS 分散流量;在兩個雲服務商各建立一組快取以加速服務讀取速度,但寫入一律透過 GCP;資料庫讀寫依舊透過 GCP 。下圖描述了計畫中的改動。

計畫中的混合雲服務

在開發人員眼中,這個策略是非常合適的,因為開發人員對於資料庫及快取的假設不因這個策略而改變,也就是說工程師可以在不知道底層複雜度的前提下進行開發。原因如下:
GCP 這側的讀寫快取是位於同個雲內,所以快且穩定。

  • AWS 側的快取寫入 GCP,延遲較高。但因為寫入量少所以影響不大。
  • AWS 側的讀取來自同個雲內的快取,延遲低。但會有短暫的資料不一致:資料跨雲寫
  • GCP的快取後,需要一陣子才會同步回AWS的快取,這會造成讀取到錯誤的舊資料。但拿常用的快取服務 Redis 來說,如果兩個資料中心距離很近,兩座 Redis 之間資料差距遠小於一秒,對 17 Media 的應用場景來說可忽略不計。

在 SRE 眼中,這個策略略有風險:17 Media 的 DNS 服務直接面向用戶,切換 DNS weighting 的時候會有 DNS cache poisoning 的問題;但這可以透過後續架構微調解決(例如前面再搭一層 load balancer),所以目前較不擔心。

微服務

在之前提到,這次 17 Media 會成為重災戶,其中一個原因是主要功能集中在少數服務,解決方法就是將單體服務(monolith)分拆成微服務(micro services)。但要怎麼拆就是個大學問,拆分方式需要視團隊組成而決定,後端團隊正在討論不同拆分的可行性。

結語

在這次故障的處理過程中,讓我感到產品團隊的責任越來越重大。目前團隊支撐的已經是個多元的直播產品,平台上包括早期用戶大多來自台灣,系統故障的內部 Slack 訊息只需準備中文;但現在已經跨足許多地區,這次故障時內部更新訊息包含中英日等語言。

以上改進事項正在進行中,有興趣歡迎一起討論。也歡迎你參與進化的過程,17 Media 工程團隊持續徵才中,包括 backend 以及 SRE。在 17 你可以遇到頂尖好手,這是一個多元化 app 的壯大旅程,歡迎加入我們!

職缺列表:http://bit.ly/2qnPLwm

責任編輯:Chris



上雲猶如太空探險之旅,iKala Cloud AIOps Services協助企業輕鬆穿梭多雲環境

人類從上個世紀積極探索外太空,為了將太空人送上天際必須克服各式挑戰,而現代企業要從「地端」飛向「雲端」,困難程度有過之而無不及。iKala Cloud AIOps Services 提供多項關鍵服務,幫助 IT 團隊輕鬆悠遊多雲環境。
評論
評論

探索外太空,曾經是國際間的科技競賽,近年 Tesla 創辦人馬斯克更準備把太空旅行當成商業服務,預計 2026 年要帶著人類登陸火星。完成一趟星際旅行,需仰賴嶄新的科技及跨科學精密計算,但你知道嗎?現代企業要從「地端」飛上「雲端」,其實挑戰程度不亞於飛向太空。

對企業資訊管理者來說,有限的 IT 資源無法應付繁重的維運項目,加上同時管理公私有雲架構更顯困難、資安管理複雜,例如需要人工執行過濾警示,各種大大小小挑戰不勝枚舉。換言之,企業想航行雲端,就像打造火箭需要龐大資源及人力。不過,現在有更輕鬆穿梭雲端的方式,就是使用雲端技術服務商 iKala 所提供的 AIOps Services(自動化雲端託管服務)

火箭升空前的全盤規劃:iKala AIOps 擬定系統架構規劃、教育訓練

完成一趟太空之旅,必須做足各種研究,例如精準計算飛行軌道、降落定位點、燃料耗用數、與地球通訊設定…等。

對沒有雲端架構經驗的企業來說,就如同當時的科學家,必須用土法煉鋼的方式檢查數據是否有誤。換言之,企業 IT 在升級之前,就需要有經驗的「雲端顧問」來釐清需求、協助規劃「升雲」之旅。而 iKala 就是企業的最佳雲端顧問,旗下 iKala Cloud AIOps Services 會搭配一位專責的技術客戶經理,協助企業提供即時的技術服務與專業建議。

究竟 IT 升級之前,iKala Cloud AIOps Services 有哪些服務?首先是「系統設計規劃」,涵蓋系統架構規劃書、系統上線/遷移計畫書,可因應客戶產業需求,提供對應的解決方案以及顧問服務。而越來越多企業會使用到 Google 的雲端資源,iKala 也有提供 Google 雲端平台訓練服務。

GCP 教育訓練課程多元,包含 GCP 基礎架構(網路設定規劃、權限控管、計算資源等)、大數據與機器學習(大數據分析 Pipeline、BigQuery、ML 模型訓練與應用)、軟體開發技術與流程(容器化、CI/CD、DevOps)等。因為 iKala 團隊取得 10 多項 Google 專業技術證照,才能在企業規劃雲端轉型的前期就一步到位,規劃出整體藍圖,提供更全面的解決方案建議。

火箭升空中的精密操作:iKala AIOps 輔助即時技術維運、資安管理

當火箭準備就緒、升空倒數之際便是決定這趟太空之旅能否成功的關鍵時刻。從太空人的行前訓練與身體檢查,到火箭的引擎測試完成,如果有靜電或一點火花都可能引發爆炸事故。光是在升空階段,太空總部就要有結構、熱控、姿態控制、資料處理、電能、遙傳指令、推進以及飛行軟體等龐大的系統工程師在旁待命。

換言之,企業 IT 移轉雲端過程就像火箭發射的當下,需要有專業、經驗足夠的工程師,才能即時協助企業順利上雲,甚至快速排除緊急的狀況。對此,iKala Cloud AIOps Services 提供兩大關鍵的幫助:技術維運、資訊安全管理。

iKala Cloud AIOps Services 的技術維運服務內容,提供 7 x 24 的 Help Desk,像是緊急 GCP 問題報修、產品使用技術諮詢;或是事故管理,如搭建監控系統、設定規劃告警政策、規劃日誌收集與留存。每月也會提供企業維運報告,報告書有營運效率檢討、流程優化、新服務項目、營運系統建議等。

至於資訊安全管理方面,除了基本的 GCP 專案權限控管掃描、應用程式 OWASP(Open Web Application Security Project)前 10 大項目資安弱點掃描,同時也針對近年相當受重視的 DDoS 防護,iKala 可協助企業導入 GCP 平台的 DDOS 防禦機制。iKala 掌握多年軟體開發和雲端管理經驗,可分享給客戶 DevOps、AI 第一手實務的作法與經驗。

火箭升空後啟動自動導航:iKala AIOps 提供 AI 自動化監控、帳務管理

當火箭成功升空後,太空人為了執行下一階段任務,這時候火箭就需要轉換成自動駕駛模式,或在探索其他星球時,出動機器人來協助執行人力無法負荷的任務,讓太空人專心處理更關鍵的工作。換言之,上雲後的 IT 架構就像升空後的火箭,應該減少 IT 人員的負擔,甚至不需浪費例行時間,就能夠快速掌握整體資訊系統的運作狀況。

不過要讓 IT 架構像火箭具備自動駕駛功能,勢必需要相當高的技術門檻,而 iKala Cloud AIOps Services 正好有相對應的服務。如此一來,IT 人員的生產力就能投入在更具商業價值的研發專案,讓 IT 部門轉型成可創造產值的單位,而非單純的後勤支援角色。

盤點 iKala Cloud AIOps Services 在此環節共有三大類服務。其中一項是 AI 自動化監控與通報服務,幫助 IT 成員主動監控系統,掌握是否有異常操作狀況。其二是帳務方面的管理,幫助企業產出雲端服務月用量帳務分析報告,針對軟體授權需求,整合出帳至  Marketplace 與第三方服務商,自動化做到 License 採購管理。

第三項則是針對服務級別協定(SLA)iKala Cloud AIOps Services 提供 24 x 7、5 x 8 兩種模式,在重大 GCP 服務異常中斷服務時,提供電話、e-mail 聯繫。而且每月會舉辦 1 次月會(以 on-site 或遠端視訊會議方式)提交書面報告。目前 iKala 的企業客戶服務超過 400 多家、涵蓋數 10 種產業,可說是企業成功上雲,最能安心託付的合作夥伴。 

事實上,雲端託管服務(CMS)是目前最夯的新趨勢,根據市調公司 MarketsandMarkets Research 報告指出,全球雲端託管服務的市場規模,預計從 2020 年的 624 億美元,到 2025 年成長至 1,162 億美元,複合年增長率(CAGR)為 13.3%。代表未來有大量企業採用 CMS,以降低 IT 基礎設施的投資成本及風險,藉此提升企業營運的競爭力。

由此看來,企業的數位轉型,就像上個世紀的太空軍備競賽一樣。「時間就是決勝點」,越晚起步的公司與其他數位能力領先群的企業相比,差距只會越來越大。現在就攜手 iKala 嘗試 iKala Cloud AIOps Services,打造穩定的 IT 系統、邁向數據驅動的商業模式,讓企業在數位世代站穩腳步,輕鬆穿梭多雲之間。

了解更多 iKala Cloud AIOps Services