【領航觀點】十多年ML系統SRE經驗,Google練出4大ML可靠性戰略


13年前,Google在匹茲堡設立了第一個ML SRE團隊,開始將累積了好幾年的SRE經驗,開始運用到ML系統,先從改善搜尋引擎關鍵字廣告投放精準做起,後來擴大導入到各式各樣的ML服務,甚至要發展成可以支援多模型類型多租戶架構的ML維運平臺。

「不只是為了省錢,或只是減少丟臉時刻,避免影響顧客,更重要的價值是,SRE是確保ML創新速度的關鍵。」Google ML SRE團隊負責人Todd Underwood在去年10月全球SRE年會演講時,他特別強調,這才是Google早在13年前開始將SRE經驗和知識運用到ML系統的關鍵理由。

Google在 2003 年首創了第一個SRE(Site Reliability Engineering,服務可靠性工程)團隊,透過系統架構設計、維運流程改善等各種做法,來確保系統運作的更可靠。2014年,Google公開了這套SRE方法論和經驗,後來也成了許多企業維運自家網站和線上服務可靠性的重要參考。

不只是用來確保網站和線上服務的可靠性,13年前,Google已經將SRE成功運用到搜尋服務,儲存系統、廣告資料儲存系統的可靠性維運上,當時開始思考,是不是能將SRE運用到ML系統上,決定先從匹茲堡辦公室的Google Ads品質團隊開始,運用到仰賴大量機器學習演算法的Google的廣告推薦機制上。

因為Google關鍵字廣告採點擊計費,點擊才會計價,靠ML模型來推薦的廣告越符合搜尋需求,就會能成功吸引瀏覽者來點擊。

Todd Underwood指出,廣告系統越穩定可靠,營收就能越穩定,因此決定開始從這套系統開始導入SRE做法,稱為「ML SRE」。Todd Underwood 就是13年前發起了Ads ML SRE團隊的關鍵人物之一。

Todd Underwood表示,AI跟ML其實很不一樣,AI是從人、應用需求角度來看,但ML則是要讓電腦系統可以運用機器學習技術來解決問題,是一種利用資料來訓練模型的做法,ML是AI的一個子集。

Todd Underwood也公開了Google內部所用ML系統概略架構,跟大多數企業常見的ML訓練流程差異不大。這個ML系統架構包括了5個流程,從資料搜集、資料準備、模型訓練、品質控管到提供推論服務,Google打造了一套模型管理工具和流程調度系統,用來追蹤模型、特徵和資料的後設資料。Google也特別重視資料讀取、資料檢查、特徵資料的分布和變動等資料品質的控管。

Google SRE工程師Mary McGlohon正是過去4年來負責維運和開發這套超大規模ML系統的工程師之一。

Mary McGlohon指出,機器學習系統過於複雜和龐大,必須要打造工具來分析,才能探索問題,對ML SRE來說,就不用知道每一件事的業務邏輯,也可以做事。

因此,Google也自行發展了不少ML SRE工具,從更大的尺度來觀察系統,找出各種可能出錯的狀態,並依據過去的錯誤設計更好的實作方式。

雖然,Google沒有公開這些 ML SRE工具,但Mary McGlohon歸納出四個Google用來提高ML可靠性的SRE戰略,這正是他們過去十多年確保ML系統可靠性的關鍵秘訣。

這四個策略,包括了,第一,要讓失效問題看得見,才能知道為何出錯。其次,也需要盡可能驗證各種異動,才能避免異動帶來的錯誤,並且要釐清對資料完整性的要求,最後則是得妥善管理工作流程的等待任務。

Mary McGlohon指出,若誤以為ML是魔術,這是一個迷思,對在乎系統穩定的工程師來說,今天的偷懶, 可能會帶來明天的技術債,先分析ML系統的特徵,才能知道系統出錯時會有哪些風險,讓我們知道可以如何管理風險。

ML系統的特別之處,第一是大量資料的相依性。因為機器學習演算法非常強大,可以有效辨識訊號和雜訊,這就導致不需要篩選或過濾資料,也能提升預測能力。

甚至,不需要知道哪些資料來源更有價值直接全部匯入,這會帶來一個後果,累積越久,就會有越多資料相依性(data dependencies)問題,這也是Google ML系統的一大特質。其次,ML系統其實是一套龐大交互作用的流程系統,必須知道如何安排這些流程,才能管理風險。

最後一點,ML是一種超大規模的非典型工作負載,不同的ML批次運算,會有不一樣的運算和資料I/O需求,這對資源調度工作帶來很大的挑戰。

Google也曾從分析了過去15年ML系統上百起當機事件的檢討報告後歸納,出19種ML系統當機問題,Mary McGlohon指出,其中只有30%的問題,是來自ML系統內部的問題,像是標記錯誤,模型配置設定錯誤,但高達40%的問題是來自分散式系統的內部問題,例如負載平衡出錯,資料結構沒有最佳化,工作排程安排錯誤等。

「從這個結果告訴我們,ML系統的維運可以借鏡其他分散式系統的維運和最佳實務做法。」Mary McGlohon指出,Google的ML系統是一種分散式系統,資料密集,流程化的系統,我們挑選了分散式系統最佳實務,資料完整性最佳實務,和工作流程最佳化實務來緩解風險。


ML SRE關鍵策略1:讓失效問題看得見


「要知道如何解決故障之前,得先知道何時會故障,看得見故障是一件重要的事。」Mary McGlohon表示。

Google內部有一套協調調度平臺,可以用來設計模型開發流程,可以設定模型配置,並提供儀表板來檢查模型效能,可以用來觀察模型如何運作。

不過,Mary McGlohony則是建議,SRE團隊最好可以建立一些模型品質預警通知,通知模型開發者以及系統維運人員,一但模型品質開始下滑,可以在更多使用者發現之前,讓模型開發者可以展開行動,退回前一版,或趕快開始調查原因。

「儀表板是一種降低事故風險的好方法,發生事故時,要確保開發這個模型的核心人員也能觀察到系統的資訊,他們可以成為解決問題的幫手。」Mary McGlohon說。


ML SRE 關鍵策略2:盡可能驗證各種異動


但只靠預警機制還不夠,更主動的SRE方法是進一步驗證各種系統上線的變動,可以從二進位檔和資料的變動來追蹤。

如何最有效追蹤系統的變動,Mary McGlohon建議,任何系統都會有帶有業務邏輯的二進位檔案,不管是,特徵處理,模型訓練,或推論服務等,都會用到二進位檔,因此,可以驗證這些二進位檔來確保是否順利運作,另一個可以追蹤變動的地方是系統配置檔的變動。例如像是資料Schema配置, 不同階段的各種配置。

追蹤二進位檔和配置檔的變動,最好的做法就是建立一個上線前的Staging(準備)階段和環境,在這個環境中,複製一份正式系統,進行測試,驗證效能,來確保異動的影響符合預期,確定沒有問題才正式上線。

在Staging階段較容易發現可能導致當機的錯誤,但不容易發現效能問題的影響,例如I/O用量,CPU用量,一條工作流程跟大量工作流程同時執行的影響不一樣,後者可能導致很多等待的任務,而影響了系統運作。

Google還會追蹤另外一種變動,就是資料變動,可以從原始資料變動,特徵資料更新的脧中,模型表徵的變動,推論資料的產生等。「偵測資料本身的異動,是一種防止事故的做法。」Mary McGlohon表示。


ML SRE 關鍵策略3:更清楚掌握對資料完整性的要求


另外,建立模型後,在正式上線之前,Google會先用測試資料來了解模型的效能,或是在準備好特徵資料後,先篩選出異常資料,避免對模型訓練產生影響。Mary McGlohon表示,對特徵資料越熟悉,就越能這樣事先過濾,而且不能單靠資料異常檢查,還是需要搭配對配置檔和二進位檔異動檢查,來確保ML環境準備正常,也才能避免壞資料產生問題。

如何分辨哪些資料是異常資料,就得對資料完整性的要求,清楚了解送入ML系統的資料是否符合訓練所需,而且能準時送達。

尤其,很多外部問題會影響資料品質,例如標記出錯,資料來源在不同時間來自不同地方,資料處理流程在第三方,甚至可能無法監控資料來發生了什麼事。Google SRE會要求,組織內部資料負責窗口,有任何資料需求的調整,也得通知SRE。

另一個做法是簡化ML,避免壞資料帶來長期的影響,也可以建立系統回復機制。例如遇到資料錯誤,或不完整的資料,訓練出了有問題的模型,若有回復機制,就可以回到一個安全不容易出錯的模型快照版本


ML SRE 關鍵策略4:妥善管理工作流程的等待任務


Google ML SRE最後一項關鍵策略是ML工作流程最佳化,因為經常有大量工作流程同時進行,過載會是常見問題,一但流程當機,或者資料晚到,就得有彈性來因應,因此,Mary McGlohon表示,需要建立流程退回機制,另外要有工作量優先順序機制,才知道哪一項任務可以延後,最後要讓調度機制更聰明,例如可以針對系統備援來進行資源調度,一但遇到當機時就可以採用。


ML SRE和SRE有兩大挑戰不一樣


Todd Underwood指出,ML SRE特別跟其他SRE做法,有兩件事不一樣。第一是,新模型和新團隊需要很大的彈性,可能有各種技術考量,業務需求,或資料限制,必須調整模型。

因為需要可以客製化的模型架構,容易增加新功能,超快速部署,負責團隊能快速修改問題直接執行模型來更新,也就是說,Todd Underwood表示,ML系統,希望能夠盡快正式上線,這意味著,機器學習訓練要高可用,容量分派自動化,調度自動化,SRE自動支援等。但是,要具備高度彈性,也代表了不容易標準化,這是第一個挑戰。

第二個不一樣之處是,ML SRE的另一個挑戰是「模型品質」,Todd Underwood指出,尤其要思考該如何對模型品質負責。Google常見做法是由模型開發者來確保模型品質,但在ML模型上線之後,很多問題是來自系統性問題,而非模型的問題,只靠模型開發者解決不了問題。

「如何對模型品質負責,這是一個還沒有答案的ML SRE大問題,這真的是一個非常難解的問題。」Todd Underwood強調。

為了解決這個模型品質問題,Google正在思考的做法是,建立升級檢查清單,也就是可以檢查一個ML模型是否能從實驗狀態,進入到正式上線狀態的檢查清單。這個挑戰也就是要定義一個模型的服務水準目標(SLO),關鍵是「如何判斷,一個模型可以正常運作。」Todd Underwood說。

目前,Google有幾項定義「模型正常運作」的角度,例如資料是否不完整,過大,過小,或者會出現不同版本。訓練速度太慢,或容易卡住。或是訓練過程太消耗資源、模型品質突然改變(準確度下滑)、服務無法載入模型、模型載入服務後變慢等。

Todd Underwood說:「這些就是我們會設立指標的地方,來量測數據和效能,來判斷什麼樣的模型品質夠好,可以升級到正式環境。還會搭配其他指標如Model後設資料是否完整,和其他模型的相依性檢查等。

下一步,Google ML SRE想要做到5件事,Todd Underwood分享,一方面說服組織使用稍舊的ML技術但搭配可以自動化建模的做法,夠用就好的ML,不是用最新技術。

其次,要打造一個兼顧各種功能和穩定性的端到端平臺,但要把這些功能盡量背景化,希望做到,一個按鈕就可以完成。

Todd Underwood也希望大幅降低訓練成本,並且把各種ML服務變成API,可以穩定且方便整合到各種應用中,讓ML無所不在,最後則是要建立ML品質評量機制,適用各處而且值得信任。


文章來源:iThome

服務專線:02-25622880 #3622 開小姐 ( 週一至週五,上午 10:30 ~ 12:00,下午 1:30 ~ 5:30 )