MLaaS平臺是玉山銀行發展嵌入式金融服務的重要技術平臺,有別於2019年上線的1.0版本,2.0採用容器管理平臺K8s和流量分配工具Ingress,可更彈性調度運算資源。【圖片來源 /玉山銀行】

玉山嵌入式金融服務背後的技術力,是一套捲起袖子自建的機器學習即服務(MLaaS)平臺。它是執行各種AI應用不可或缺的工具,舉凡0.1秒就能揪出異常的信用卡盜刷偵測、解放人力的千萬張票據手寫辨識功能,甚至是疫情間加速紓困專案申請的RPA應用,都靠MLaaS驅動。

這個平臺,在去年中從1.0蛻變為2.0,第二代不只擁抱Kubernetes(簡稱K8s)、容器等主流開源工具,還引進多項自動化機制,來提供99.9%可用性的API服務,實現玉山7x24小時金融服務目標。他們如何做到?

MLaaS平臺:執行AI推論的重要引擎

在玉山,AI已深化至各營運層面,光是執行中的專案,就超過半百個。玉山AI力靠兩大平臺支撐,一是AI研發雲,是一個供資料科學家嘗試創新的「遊樂園」,另一則是MLaaS平臺,是一個講求快狠準的服務平臺,營運著各式各樣的AI應用,更具備1秒內給出預測結果的能力。

這2大平臺關係緊密,當資料科學家在AI研發雲完成模型開發後,會將成熟穩定的模型部署到MLaaS平臺上,來執行實際任務。此時,MLaaS有3個重要工作要做,也就是資料ETL、模型訓練、以及部署API執行AI推論。可以說,MLaaS是實現AI解決業務問題的重要橋樑,必須又快又準,但隨著玉山AI應用的擴大與深化,MLaaS更多了資源彈性調度和維運穩定的需求。

面對這個要求,從零打造MLaaS平臺的玉山銀行智能金融處(簡稱智金處)曾透露,2019年MLaaS 1.0上線後,團隊就開始思考下一代架構。因為,從平臺上線第一天起,他們就知道,未來平臺的使用複雜度只會越來越大,不只得落實AI上線後的監控維運,面對大量資料處理和推論需求,資源調度還得更細緻、更有彈性才行。

2.0用微服務拆分3大功能,採K8s更彈性調度資源

這是因為,MLaaS 1.0採裸機(Bare Metal)架構的設計,執行AI推論用的運算資源以虛擬機器(VM)為主,比如,可以很方便的指派3臺VM來執行一個AI推論工作。但是,在1.0的平臺中,無法根據尖峰、離峰用量自動調整用於執行AI推論的運算資源,因此得一開始就以尖峰用量來配置,缺乏了調度彈性。

再來,MLaaS 1.0採取了「一條龍式」的部署管線設計,只靠相同的一條部署管線從頭執行到尾,涵蓋了從資料ETL處理、模型訓練到部署推論API的程式碼,將3項工作整合到一條部署管線的做法。想要修改其中一項工作的程式碼,比如要調整推論API,就得從第一步的資料ETL開始,全數執行部署一次,才能重新部署新的模型推論API。這對模型重新訓練或更新推論API來說,就產生許多時間成本。

MLaaS 2.0改善了這些缺點。智金處改用了微服務架構開發,拆分原本綁在一起的3種功能,各自以輕量級容器打包,部署在K8s上。這麼做的好處是,使用者可直接修改其中一個功能,比如直接重新部署API,或是更新資料,而不必跑完所有流程。

再來,採用容器和K8s,就能善用K8s平臺的自動擴充機制,能根據當下流量需求,即時調度運算資源,比起裸機架構綁死VM資源的做法,更有彈性。同理,這個資源調度還能依需求量調整,比如,有些AI專案的資料量大,但模型訓練工作相對簡單,就能將額外運算資源調度給ETL處理,若模型資料量不大、但模型訓練需大量運算,也能將動態將運算資源分配到模型訓練上。玉山的影像和語音辨識模型,就以這個方式來操作。

開始搬遷舊專案,還要整合影像辨識模型

去年7月,MLaaS 2.0正式上線,此後新加入的AI專案,就都部署在MLaaS 2.0上,而1.0的舊專案,則陸續搬遷至2.0,特別是所有影像相關專案,將在今年全數搬遷至新平臺。

這是因為,玉山打算藉這個機會,將所有影像模型整合為一個完整的大模型,來支援跨業務需求。比如,智金處過去開發了票據影像辨識應用、財力證明影像辨識等影像辨識應用,這些應用包含多種辨識模型,如所得稅清單辨識模型、存摺辨識模型、薪資證明辨識模型等。

這些模型,都得按個別業務需求來執行辨識,但現在,玉山要整合這些模型,重新設計API,讓前端呼叫時,不必先區分上傳的是何種文件,而是直接辨識、產出結果。

這麼做的好處是,一套模型就可支援不同業務。比如,信用卡處辦理信用卡申請時,可使用財力證明辨識,其他消金業務如信貸申辦、房屋貸款等,也可使用財力證明辨識模型。

MLaaS 2.0亮點:比較不同版本模型更簡單了

這個引進新工具的MLaaS 2.0平臺,最讓團隊有感的是,比較不同版本的模型更容易了。因為,在1.0時代,若要比較不同版本模型,部署在不同環境的成效,就得費一番功夫調整流量資源,很難進行比較。

而在2.0平臺,團隊可將不同版本的模型,打包為不同的容器,再將模型推論包裝成API,就可利用K8s的流量分配工具Ingress來分配流量到不同的版本的API來試驗。比如要比較3個模型版本,版本1分配10份流量,版本2分配30份,版本3則是15份,或是,3個版本都可分配相同的流量,來進行測試。

接著,為了評估實驗結果,團隊先是收集日誌(Log),彙整到搜尋引擎Elasticsearch中比較,再將結果回饋到MLaaS平臺的模型訓練工作來比較,作為判斷是否需要重新訓練的參考。

這是MLaaS 2.0利用K8s特性,實現的里程碑之一。

MLaaS 2.0實例1:內部Chatbot

不只資源調度更有彈性,搭配微服務架構還大幅縮短模型訓練時間。像是,智金處在MLaaS 1.0時代開發一套內部專用Chatbot,能回答內部員工的各種人資相關問題。但這也意味著,這套Chatbot需要大量語料來訓練,並隨著法令、公司制度調整,得不定時以新資料重新訓練模型。比如,去年下半年規定,2022年陪產假改為7天,而這只是答案,使用者還會有各種問法,因此,智金處得利用相關語料訓練模型,再重新部署。

由於MLaaS 1.0平臺將資料ETL、模型訓練、推論API部署這3個工作流程集中到單一程式,光是重新訓練,就花了2周時間,執行完所有流程才算大功告成。但MLaaS 2.0平臺,將這3項工作流程拆開,個別在容器中處理。因此,當模型需要重新訓練時,直接在模型訓練執行特定一項流程的容器即可,不必走過所有流程。

MLaaS 2.0利用K8s彈性調度資源,重新訓練這套Chatbot,1天就能完成。

MLaaS 2.0實例2:Smart Channel

另一個例子是推薦系統Smart Channel。這個系統會根據使用者檔案、瀏覽紀錄和交易資料,在使用者登入行動銀行App時,推薦相應的金融產品。

Smart Channel是MLaaS 2.0原生專案,直接部署在2.0平臺上。透過K8s自動擴充機制,可在上午11點至下午1點的尖峰時段,當大量請求湧入時,自動開啟更多Pod叢集來因應需求。

若是MLaaS 1.0平臺裸機架構,缺乏運算資源彈性調度機制,一開始就得配置尖峰規模的資源來因應,往往會造成資源浪費。

MLaaS 2.0實例3:數存秒開

另一方面,MLaaS 2.0還有一個數存秒開的原生專案。數存秒開是玉山近期上線的金融服務,用於即時開設數位存款帳戶。這個專案是跨部門、多流程的專案,比如開戶過程中,需要判斷各種資料,像是身份證件、駕照、健保卡等,前端資料審核流程採用RPA進行,並部署在2.0上。

團隊建立了不少AI模型來判斷各種資料,也用來判斷顧客風險,最後再利用RPA技術來串接整個流程,成為數存秒開服務。

用Airflow工具拆分工作流程,調整更有彈性

既然玉山將MLaaS平臺定調為服務平臺,從服務角度來看,MLaaS 2.0的可用性就得非常高,玉山智金處訂出的目標是「得達到99.9%」。為此,他們不只將MLaaS 2.0改用資源調度更彈性的容器工具,也引進不少自動化機制,來維護服務品質。

像是導入熱門的開源流程工具Airflow,將原本龐大的資料ETL工作流程和AI專案,拆分為多個小工作來執行,更彈性管理。

以Smart Channel推薦系統專案來說,這個專案用途是,當使用者登入行動銀行App時,自動推薦相應的金融產品。而Smart Channel推薦所參考的資料,包括了使用者個人檔案、瀏覽記錄(點擊資料)、交易記錄。

在MLaaS 1.0時代,所有工作流程都是一條龍式進行,要是其中一個環節出問題,就得從頭來過。比如,MLaaS平臺要進行Smart Channel的資料ETL,就得先處理瀏覽資料,再處理交易資料,最後才是個人檔案資料。要是交易資料出問題,就得重新從瀏覽資料處理開始,再執行一次。

但,採用Airflow提供了用流程圖來安排工作組合的機制,可以將不同的工作拆開成更小單位的工作,並且畫出一張流程圖,稱為DAG(Directed Acyclic Graph),來組合這個流程中的多項任務的程式,比如,可以將瀏覽資料的過程,製作出一張DAG,涵蓋了瀏覽資料的多項任務,以及跟這些任務之間的執行順序或關聯,而交易資料又可以製作成另一個DAG流程。如此,其中一個環節出問題,直接修改該張DAG流程圖即可,不必按照順序重新來過。最後在按照這些DAG上安排的任務先後順序和關係來執行每一個任務的程式。

特別的是,Airflow採事件驅動(Event-driven)機制,當新資料出現,就會自動觸發特定的DAG流程,隨後展開一系列的資料或模型更新。比如,Smart Channel的部分交易資料會採用行銷部門資料,這些資料與行銷活動相關,是季節性的。不過,只要這部分資料更新,就會觸發專門處理行銷資料的DAG,隨後進行模型訓練,自動更新運算結果。要是行銷資料未更新,模型就延用舊資料來運算。

這種將龐大的工作切分為小任務的處理方式,讓資料處理不被一條產線綁住,各種任務組合可彈性調度,就算其中一個出問題,也能跳過由另一個替代任務接手,這就像是故障自動切換機制一樣。而且,將工作流程設計成一個個DAG流程圖,還能重複利用,當其他業務有需要,可取用現有的DAG來運算,比如前述的行銷資料。

不只如此,Airflow還有一個特性,能讓智金處將工作管理權限,下放給分析團隊。分析團隊不只是查詢運算工作的執行狀態,還能自行直接處理故障問題,不需如MLaaS 1.0時代般,還得自己請系統管理員查明原因。這個管理權限下放,讓團隊工作更有效率。

用FastAPI快速開發API,自建API型錄讓平臺標準化

不只用Airflow彈性管理工作流程,玉山還在MLaaS 2.0中,導入了FastAPI開發框架。這個API開發框架,可根據程式快速產生符合OpenAPI標準的規格文件,並生成API。這些API文件,詳述了請求參數數量、參數型態,以及回應的內容說明等規格。可供前端開發者,來理解這一支API的規格要求。

就算程式碼有所變動,前端開發者也能馬上得知。比如,原本請求參數有5個,現在新增了第6個,FastAPI框架就會根據變動,自動產生新的規格文件,再加上玉山搭配Git版本控制系統來管理程式碼,因此FastAPI產出文件後,直接儲存到內部共用的網站上,讓開發者查詢新版文件,也能先做簡單的測試。

這種將API規格文件和程式碼結合的做法,讓開發者更容易聚焦在邏輯討論上。再來,以往智金處都以Email傳送規格文件,收件者的版本未必是最新版本,改用FastAPI,可以解決版本同步的需求。

除了自動產生規格文件,FastAPI還有型別檢查的功能。假設前端系統呼叫出錯,傳送錯誤的參數型別資料,FastAPI就會自動告知前端系統,傳送錯誤資料了。可以說,FastAPI框架統一處理錯誤管理,讓開發者更專注於程式開發。

為了有效管理API,智金處也在內部網站,打造一個API型錄中心:API Document Hub,開發者可從中找到智金處出品的所有API,包括上百支API的詳細規格。這種管理機制,減少了開發者之間的溝通成本,讓專案開發更有效率。搭配FastAPI這個標準化工具,MLaaS平臺更像是一個具備通用、標準規範的產品,來服務玉山內部使用者。

圖片來源/FastAPI
玉山智金處在MLaaS 2.0中,導入FastAPI框架,可根據程式碼自動產出符合OpenAPI標準的API規格文件,一旦程式有所修改,也會自動更新文件,還能處理錯誤管理。

以普羅米修斯監控每天百萬筆Log,下一步要打造全自動監控

有了Airflow和FastAPI加速開發管理工作,接下來,在維運部分,玉山也採用開源監控工具普羅米修斯(Prometheus)搭配Grafana介面,來檢查系統產生的日誌,而機器學習服務所產生的日誌,則由搜尋引擎Elasticsearch搭配Kibana介面來處理。

對玉山來說,採用監控工具並不是一句話那麼簡單。要監控系統,系統首先得有日誌,智金處成員花了大量時間,來學習如何更有效率地產生日誌,來反應系統現況,才能讓開發者用工具查找狀況。他們也建立一套日誌撰寫指南,來確保日誌品質。

智金處透露,一個系統1天就會產出100萬筆日誌,雖然有這些工具輔助監控,但系統管理者還是需要花5分鐘,人工監看系統狀況。他們把這個工作稱為「巡田水」,雖然檢視工作並不耗時耗力,但他們正研究,如何將系統產生的日誌和機器學習服務產生的日誌集中起來,並利用這些日誌,訓練一套模型,來自動化監控系統。這是為了讓MLOps機制更完善,也是智金處團隊接下來的目標。

讓維運更完善,實行SRE的事後分析作法

機器學習維運除了採用平臺工具,還得有套維運機制。智金處早在2、3年前,就開始實行「Postmortem」(事故後分析)的做法,這是SRE維運的方法論,就像是進行驗屍報告般,來展開事後分析。

玉山導入Postmortem有2個目的,一是專案上線後,召集專案開發團隊、業管單位和系統部同仁,像是收集日誌的團隊和負責MLaaS平臺CI/CD的團隊等,每次約10至20人,由專案團隊攤開程式碼,來分享設計重點及原因,以及好處和可再精進之處。

另一個用意則是異常事件發生、問題解決後,透過Postmortem來回顧異常事件的發生近因及根本原因(Root cause)。這時,一樣會召集所有相關團隊,但智金處會要求負責團隊,要鉅細靡遺的執行Postmortem,不只要分析系統日誌、對比程式碼,還得走訪使用者單位當時的系統經歷,藉此來思考改善方案,避免下次踩雷。

比如,去年一次資料庫當機,團隊展開Postmortem分析,才發現根因是RedHat的Linux OS光纖網路卡有問題,這是平時難以察覺的問題,但過度使用資料庫的近因,才暴露了這個問題。在那次Postmortem之後,團隊開始改善系統架構,像是落實讀寫分離、調整AP程式存取資料庫的模式,來預防再次出現異常。Postmortem對維運很重要,不只能找出長期發展的痛點,還能讓團隊工作透明化。而且,它不只是玉山用來分析事件的方法,更是相關人員互動的場合,藉由互相問答,來讓業管單位了解,技術團隊種種技術背後的考量。

對玉山而言,這是成員學習的歷程,而非究責的歷程。

今年目標:朝7x24小時維運不中斷邁進

隨著玉山銀行董事長黃男州在年初法說會上宣示,接下來10年要成為亞洲的玉山,玉山也對打造關鍵技術的智金處,寄予更高的要求,維運要達到7x24小時不中斷。

為因應這個要求,智金處除了導入工具來強化ML監控,去年開始也打造一套模型維運平臺,來管理模型生命周期,目標是要建立一致、標準化的模型監控作業。

為了加快開發,他們採用商用模型效能管理應用程式,透過內建的模型量測評估指標,像是準確率、F1分數、靈敏性、特異性等,來追蹤模型是否偏移。蒐集到模型效能數據後,智金處再客製出視覺化儀表板,來追蹤上線模型的異常狀態,並自動發送通知,還能在數分鐘內產出監控報表。

不只引進各種工具,玉山對技術人才的尋求,也從未停止過。不論是系統開發、ML專家,還是今年所聚焦的MLOps、SRE維運好手,都是規模百人的智金處所渴求的。對他們來說,今年的目標是深化各項ML服務的開發、部署和維運,來支援玉山嵌入式金融服務。


熱門新聞

Advertisement