10多年Google ML維運經驗，歸納19種ML當機情境要注意

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

從老舊ML系統當機經驗中找解方，成了Google ML維運團隊研究新課題

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

早在多年以前，Google就已經在搜尋引擎中加入各種ML演算法，提供更精準的搜尋結果，像是分析搜尋字詞、搜尋比對、網頁實用性排名的演算法等，只要依據使用者查詢字詞、網頁的關聯性和實用性、資訊來源的專業度分析等綜合不同考量，就能從搜尋索引中的上兆個網頁排序裡，決定查詢的搜尋結果，來貼近使用者搜尋查詢。

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

Google最老舊一套大型ML系統，建有上千個模型優化排名及推薦服務

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

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

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

具體來說，這19種ML出錯情境的分類，有流程調度問題、後端系統過載、預期性資料匯入臨時出錯、CPU 硬體出錯、快取失效問題、模型推論參考的抽樣分配出現改變、組態配置改變導致的混亂、資料結構沒有最佳化、跨叢集分派工作的挑戰、訓練策略執行沒有按照預期順序、過於頻繁調整ML模型超參數、組態變動而沒有妥善試驗或驗證、用戶端對模型的推論做出錯誤臆測、模型推論時間過長、在程式碼中使用不正確assert巨集、誤用標註錯誤的數據來訓練模型、embedding向量空間維度不匹配、測試任務與正式環境的溝通不正確，以及無法調度必要的頻寬、記憶體、CPU資源。

基本上，從系統當機歸納出的原因中，可以看見有些出錯原因較單純，像是快取失效問題，還有一些是不易察覺的錯誤，如跨叢集分派工作的問題。另外有些錯誤則是與ML相關，例如embedding向量空間維度不匹配就是屬於這一類，甚至在複雜大型分散式系統環境下，也有可能因為使用的CPU晶片出錯，導致ML系統當機的情況出現。

當完成近百起ML當機事故調查，歸類成19種ML出錯情境後，還進一步以分組方式加以畫分，並分成兩個組別來進行比較，一組是純ML與非純ML工作流程兩者的比較，另一組則是單一系統或分散式系統間的比較。例如系統調度出錯造成當機，就是屬於分散式系統管理的問題。

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

要維運一套大型ML系統，不能只懂ML，分散式系統管理更重要

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

正因為許多當機事件都與分散式ML系統密切關聯，也讓Google ML維運團隊更加意識到，一套大型系統中，從建置到維運管理，除了必須有專門團隊來負責，對於維運團隊組成，不能只有ML工程師，還必須要有分散式系統的工程師加入，甚至人數比例要比ML工程師都還高，來負責大型系統測試和診斷，透過這樣的系統管理方式，才能提升系統的可靠性，甚至幫助Google建立起更有韌性的ML維運作法。

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

 Google ML維運經驗：19種ML出錯情境 

1. 流程調度問題

2. 後端系統過載

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

4. CPU硬體出錯

5. 快取失效問題

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

7. 組態配置改變導致的混亂

8. 資料結構沒有最佳化

9. 跨叢集分派工作的挑戰

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

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

12. 組態變動而沒有妥善試驗或驗證

13. 用戶端對模型的推論做出錯誤臆測

14. 模型推論時間過長

15. 在程式碼中使用不正確assert巨集

16. 誤用標註錯誤的數據來訓練模型

17. 向量空間維度不匹配

18. 測試任務與正式環境的溝通不正確

19. 無法調度必要的頻寬、記憶體、CPU資源

資料來源：Google，iThome整理，2022年3月