10多年Google ML運維經驗，歸納19種ML宕機場景要注意

來源：十輪網

作者：十輪網

時間：2022-03-15

多年前，Google開始在ML運維中導入SRE的做法，確保系統(tǒng)的服務可靠性，在2年前一場OpML’20技術大會上，Google ML SRE運維負責人Todd Underwood與另一位團隊資深成員Daniel Papasian實際以Google搜索服務運維為例，公開分享他們從搜索服務ML宕機經驗中，發(fā)展出一套應對對策，除了希望改善大型ML系統(tǒng)宕機的問題，還要幫助Google創(chuàng)建更有韌性的ML運維策略，甚至還發(fā)現到，許多ML宕機事故并非真的ML服務出錯，而是系統(tǒng)管理的問題。他們更依據超過10年Google ML運維歸納出19種ML出錯場景的分類，來提供企業(yè)借鑒參考。

從老舊ML系統(tǒng)宕機經驗中找解決方案，成了Google ML運維團隊研究新課題

搜索引擎可說是Google最重要核心服務之一，如今近半數全球人口都在用，平均每秒就要處理高達7萬次用戶搜索查詢的請求，從回答各種生活大小事，到天氣、交通信息都難不倒它。

早在多年以前，Google就已經在搜索引擎中加入各種ML算法，提供更精準的搜索結果，像是分析搜索字詞、搜索比對、網頁實用性排名的算法等，只要依據用戶查詢字詞、網頁的關聯(lián)性和實用性、信息來源的專業(yè)度分析等綜合不同考量，就能從搜索索引中的上萬億個網頁排序里，決定查詢的搜索結果，來貼近用戶搜索查詢。

Google搜索引擎算法核心有個大型排名及推薦系統(tǒng)，這套系統(tǒng)經過多年發(fā)展，其中有套用了超過15年的老舊ML系統(tǒng)，也是Google使用最久且規(guī)模最大一套重要ML系統(tǒng)，但多年下來，這套系統(tǒng)屢屢發(fā)生宕機的事故，無法用ML模型進行推論，來優(yōu)化排名及推薦內容，導致服務品質不穩(wěn)定。這也成了Google所要面對的ML運維大考驗。直到兩年多前，Google ML運維團隊終于找出了對策。

Google最老舊一套大型ML系統(tǒng)，建有上千個模型優(yōu)化排名及推薦服務

以系統(tǒng)規(guī)模來看，這套大型ML系統(tǒng)中，每天同時要執(zhí)行上千個ML模型，來優(yōu)化排名及推薦服務，而且不只ML模型數量眾多，模型訓練更是個大問題，只要新資料進來，就必須不斷更新生產環(huán)境中的ML模型，光是上千個模型同時訓練，需訪問和運算用的模型參數累計就高達1,000億個，才能用于全部模型訓練，加上這套系統(tǒng)歷經多次翻新，系統(tǒng)越來越復雜，就在這樣一個龐大且復雜大型系統(tǒng)架構下，有時只要ML工作流程或環(huán)節(jié)稍有差錯，就可能造成ML系統(tǒng)宕機。

為了探究長期以來造成ML系統(tǒng)宕機的原因，Google ML運維團隊兩年前嘗試進行研究，希望能找出適當的解法，避免相似問題再發(fā)生。他們分析以往所有ML系統(tǒng)宕機事件，要從這些歷史事件中找到問題的根本原因，作為改善ML系統(tǒng)可靠性的參考依據，正好這套ML系統(tǒng)過去10年宕機過程的詳細記錄都有完整保留在數據庫中，提供包含元數據（metadata）在內的完整事后的調查分析，可供團隊研究使用。

這段期間，Google ML運維團隊一共分析近百起ML宕機事故，從這些實際發(fā)生的事件中，自行分析歸納出19種ML出錯場景要注意。其中，最常見的一種就包辦了15起宕機事故。

具體來說，這19種ML出錯場景的分類，有流程調度問題、后端系統(tǒng)重載、預期性資料導入臨時出錯、CPU硬件出錯、緩存失效問題、模型推論參考的抽樣分配出現改變、組態(tài)配置改變導致的混亂、數據結構沒有優(yōu)化、跨集群分派工作的挑戰(zhàn)、訓練策略執(zhí)行沒有按照預期順序、過于頻繁調整ML模型超參數、組態(tài)變動而沒有妥善試驗或驗證、用戶端對模型的推論做出錯誤推測、模型推論時間過長、在程序代碼中使用不正確assert宏、誤用標注錯誤的數據來訓練模型、embedding矢量空間維度不匹配、測試任務與正式環(huán)境的溝通不正確，以及無法調度必要的帶寬、內存、CPU資源。

基本上，從系統(tǒng)宕機歸納出的原因中，可以看見有些出錯原因較單純，像是緩存失效問題，還有一些是不易發(fā)現的錯誤，如跨集群分派工作的問題。另外有些錯誤則是與ML相關，例如embedding矢量空間維度不匹配就是屬于這一類，甚至在復雜大型分布式系統(tǒng)環(huán)境下，也有可能因為使用的CPU芯片出錯，導致ML系統(tǒng)宕機的情況出現。

當完成近百起ML宕機事故調查，歸類成19種ML出錯場景后，還進一步以分組方式加以劃分，并分成兩個組別來進行比較，一組是純ML與非純ML工作流程兩者的比較，另一組則是單一系統(tǒng)或分布式系統(tǒng)間的比較。例如系統(tǒng)調度出錯造成宕機，就是屬于分布式系統(tǒng)管理的問題。

運維團隊經過比較后發(fā)現，許多ML系統(tǒng)宕機事故和其出錯原因，并非歸因于ML本身的問題，大多是系統(tǒng)管理所造的錯誤，才有后面宕機的結果。從系統(tǒng)架構角度來看，他們則發(fā)現，若是ML系統(tǒng)有采取分布式架構設計，發(fā)生宕機事故比例會比單一系統(tǒng)時更高，甚至多達6成出錯都跟分布式ML系統(tǒng)處理有關，這也可以用來說明，ML宕機和其系統(tǒng)采用單一或分布式架構，彼此之間有一定的關聯(lián)性。

要運維一套大型ML系統(tǒng)，不能只懂ML，分布式系統(tǒng)管理更重要

從這些研究結果，Google ML運維團隊也找到一些方法，來改善ML系統(tǒng)可靠性，像是要求對ML工作流程進行全面監(jiān)控及關注，包含監(jiān)測資料吞吐量、ML系統(tǒng)執(zhí)行率，以及結合各種診斷測試等。對于不同源頭的訓練數據、ML模型及文件，也要創(chuàng)建系統(tǒng)化版本管控機制，以便發(fā)生宕機事故時，團隊馬上能修正。重新訓練的ML模型部署前，也要確保能正常執(zhí)行沒問題才能放行，避免影響到整體系統(tǒng)性能與利用率。

正因為許多宕機事件都與分布式ML系統(tǒng)密切關聯(lián)，也讓Google ML運維團隊更加意識到，一套大型系統(tǒng)中，從構建到運維管理，除了必須有專門團隊來負責，對于運維團隊組成，不能只有ML工程師，還必需要有分布式系統(tǒng)的工程師加入，甚至人數比例要比ML工程師都還高，來負責大型系統(tǒng)測試和診斷，通過這樣的系統(tǒng)管理方式，才能提升系統(tǒng)的可靠性，甚至幫助Google創(chuàng)建起更有韌性的ML運維行法。

盡管，Google ML運維經驗不一定適用每一家企業(yè)，但從這家公司多年ML運維和思考策略，也能提供企業(yè)借鑒來參考。Todd Underwood就建議，企業(yè)可以根據歷史ML宕機事件，按影響程度、對公司沖擊、事故持續(xù)時間和原因來進行分類，創(chuàng)建自己一套ML運維行法，除了經由分析找出根本原因，每年可以定期重新審視，持續(xù)改進內部ML工作流程。

Google ML運維經驗：19種ML出錯場景

1.流程調度問題

2.后端系統(tǒng)重載

3.預期性資料導入臨時出錯

4.CPU硬件出錯

5.緩存失效問題

6.模型推論參考的抽樣分配出現改變

7.組態(tài)配置改變導致的混亂

8.數據結構沒有優(yōu)化

9.跨集群分派工作的挑戰(zhàn)

10.訓練策略執(zhí)行沒有按照預期順序

11.過于頻繁調整ML模型超參數