你是否曾心血來潮,想自己動手做道料理?
曾在網路上搜尋食譜的你,一定對愛料理(iCook)不陌生。它就是提供各種料理作法和相關用品的電商網站,成立10年來不只收錄21萬道食譜,每月造訪人數超過600萬人次,可說是中文界最大的料理網站。
擁抱容器化新技術,一次管理20多個微服務
很難想像,撐起如此龐大使用量網站的團隊,竟是一家只有40多人的小公司。麻雀雖小五臟俱全,40人中一半是負責開發、維運的IT人,還有一位特別敢嘗試新技術的技術長,也就是李致緯。
2010年愛料理一上線後,李致緯回憶:「我們觀察到年輕一代喜歡帶手機進廚房、學做菜,」因此,他用API,將原本的網頁應用擴展至手機端App,隔年也將業務搬上公有雲,來因應成長的流量。
2013年,他帶頭擁抱DevOps流程,愛料理是臺灣很早開始導入基礎架構程式碼化(Infrastructure as Code)等開發理念的本土網路公司,來讓開發流程更有效率。後續幾年,容器化和微服務浪潮逐漸吹到臺灣,李致緯大膽率先嘗試問世不到1年的Docker,以及不久後跟著出現的Kubernetes。甚至有些技術,公雲業者才剛推出,喜歡動手做的李致緯就會躍躍欲試,馬上就拿來試用,例如雲端應用設計模式Sidecar Pattern。「我們常把自己當成技術白老鼠一樣。」他說。
搶搭新技術或新架構浪潮,雖然可以更快感受到新技術的好處,但也可能很容易就會跌一跤。
例如,愛料理採用微服務架構來設計後,曾經一度拆解成20多支微服務,像是基本的會員登入,或是複雜的電商功能,核心的開發票功能等。但他後來發現,轉換到微服務架構後,API管理是一大挑戰。
李致緯解釋,微服務架構的好處是,不同的微服務可以各自擴充,各自有自己的部署周期。但缺點是服務復原(Service Recovery)難度很高,或是內部API控管不易。
比如,愛料理有一支負責開立發票的微服務API,會將結果拋轉給另一支微服務,有次這個發票API無法連線到後續對應的API,他們花了非常多的時間,才找出出錯的環節,讓李致緯開始感受到API維運和除錯的複雜性。
為改善API管理,他們後來也嘗試導入資料查詢API技術GraphQL,將每個關鍵微服務都串聯到GraphQL API的對應端點,再聯合組成一張包含所有微服務和API的表,讓同仁知道有哪些微服務可用。
但這麼做,GraphQL閘道等維護成本很高,甚至在成本有限的情況下,要進一步追蹤分散式的每一支微服務,難度也很高。
技術應與組織並行,改用CDN來保留微服務的好
iCook愛料理技術長李致緯說,技術應該要與組織相符,單體組織就該採用單體技術。(攝影/洪政偉) |
因此,到了2019年,李致緯開始反思,這麼複雜的微服務架構,到底適不適合自家業務?
因為,導入微服務既沒有一套現成的完整工具,也不是一款套裝軟體,對愛料理這樣規模的中小企業來說,就得自己花時間,運用各種工具來建立環境,自建微服務架構和管理機制,「這麼做的門檻就高了,」他認為,除非設置了專門處理內部基礎設施的產品經理(Product Manager)或SRE團隊,才能擁抱微服務。
於是,他回過頭來思考,「技術應與組織一致,組織是單體架構,技術也要單體架構,如此,團隊才能各司其職。」,後來,他決定將這些複雜的微服務,砍掉重練,改按照各團隊業務,開發各自的單體式應用系統,來簡化維運複雜度。
但是,嘗試過微服務彈性擴充的優點,就算重回單體式架構,「不用全面套用,而能不能借鏡這樣的設計思維呢?」李致緯觀察,愛料理還是經常需要執行一些簡單的服務,比如簡繁體轉換、會員登入、驗證和簡訊發送等,如果在每一套業務系統中,都嵌入了這樣的功能,若有功能或程式異動,得一一更新在不同單體程式中的這些簡單功能模組,這些簡單服務在單體環境中的執行和維護,反而變得小複雜。
就在愛料理架構從微服務走回單體架構之際,市場上正好又出現了新興的無伺服器服務型態,也有越來越多種不同功能的無伺服器服務產品出現,喜歡嚐鮮的李致緯再度手癢了起來,興致高昂的研究了起來。
他看上了一種由CDN廠商提供的無伺服器(Serverless)運算型服務,主打「讓程式靠近邊緣」能力,可以在CDN閘道服務上,提供簡單程式化能力的執行環境,就像是一個簡單雲端小主機,可以執行小程式來提供客製化的功能。
李致緯解釋,這也是一種「邊緣運算」的概念,在靠近使用者端的內容傳遞網路(CDN)上,來提供和處理簡單工作,也能用來簡化原本內部IT的運算負載,就像是把運算搬到邊緣處理一樣。
常見的「邊緣運算」概念的實作,是在機房非核心運算環境的網路設備上提供運算,或是在遠端據點的設備上提供運算,來分散核心或機房主要運算的負載。李致緯所用的邊緣運算,則是採用雲端CDN的無伺服器服務,來分散自家IT環境的負載。都是邊緣運算設計思維,但採取的實作架構略有不同。
讓程式往邊緣靠近,分散流量降低運算負荷
比如,以前愛料理遇到高流量時,這些流量會先透過CDN繞到愛料理機房,再由內部的微服務程式來接手處理。但改採用CDN邊緣運算服務後,就能先將流量分散到CDN上,先進行初步的簡單處理,例如快取、邏輯判斷、圖片資訊和第三方驗證等工作,加快將結果送給用戶端的反應速度。
又比如,原本由多個微服務處理的簡繁轉換字典檔,現在可以完全改由CDN上的無伺服器運算服務來接手執行,更不用像過去得在內部串接不同微服務的麻煩。
不只如此,李致緯還有一個特別的應用點子,在CDN邊緣運算服務上進行用戶端API請求的打包。他解釋,因為愛料理有很多種用戶端程式,當使用者的手機App發出請求時,愛料理會透過GraphQL指令來向後端抓取資料,這類的GraphQL請求很多,現在李致緯透過CDN邊緣運算的簡單邏輯處理,可以在用戶端一次打包多個GraphQL請求,一次送到CDN節點後再分散、各自處理這些請求,完成後再將Response整併為一包回傳,如此可以減少用戶手機端發出請求的次數。
或是他們的網站常有許多爬蟲機器人不斷來抓資料,李致緯也在CDN上,透過簡單的程式判斷機制,來分散這些爬蟲機器人的請求,減少後續處理的運算資源浪費。
愛料理用CDN邊緣運算設計來處理的問題,還有驗證工作。例如,收到OAuth發送的驗證資訊時,透過CDN上執行的小程式,直接向第三方服務(如臉書等)來確認身分,再將驗證通過者的資訊打包成JWT檔案,直接交給後續伺服器處理,省下由後端伺服器發起驗證的工作。
不過,李致緯表示,現有CDN邊緣運算服務也並非十全十美,像愛料理所用的Cloudflare Workers服務,會限制程式碼檔案的大小和執行時間,甚至,雖接受JavaScript程式碼,但無法提供Node.js執行環境,因此愛料理慣用的Node.js資源都不能使用。
他認為,透過這個無伺服器邊緣運算的作法,能夠仿造出類似微服務的好處(Good parts),而且也不需要專人來維運。
最好的DevOps就是NoOps,靠無伺服器容器解決底層VM開機斷點問題
不只愛用CDN業者提供的無伺服器服務,在很多網站維運工作上,李致緯也用了不少各廠商提供的無伺服器服務,來降低負擔。
從2013年就導入DevOps流程的他認為,最好的DevOps就是NoOps,然而,主打高擴展性的容器化應用,還是會受限於底層虛擬機器(VM)的管理問題。
比如,他曾在AWS EKS和GCP的GKE上架設管理服務,像是Knative服務,但他認為,這些服務無法徹底做到Kubernetes抽象化,因為AP使用者還是得花時間手動設定Pod叢集的配置,或是仍舊會擔心Host機器是否夠用,還不能完全做到設好參數就完全自動執行。
愛料理就曾遇到流量突然暴增,導致Pod叢集接應不暇,還得靠工程師手動透過Google API來增加底層VM,但是重開VM就得等上一段開機時間,難以順暢分散流量來執行任務。
或像是,過去愛料理要擴展服務時,得先開一臺能支援AP的虛擬機器來執行Docker,以便快速部署容器化應用。李致緯後來就是改用無伺服器容器(Serverless container)服務,來解決過去必須等待底層VM開機的斷點問題。
他也觀察到,今年一些大廠如Google、AWS紛紛意識到容器底層VM管理痛點,開始開放使用者設定開啟機器的數量,來解決問題。愛料理目前已有三分之一的服務採用無伺服器容器,預計今年底,半數服務會改用無伺服器容器。
這種採用CDN邊緣運算和無伺服器容器的混合式架構,就是李致緯用來取代純微服務架構的作法。
倒各種資料到資料湖,讓PM動手用BI、SQL工具找洞察
不只開發和維運大玩新技術和架構,對於時下最熱門的AI和大數據分析應用,李致緯也有一套自己獨特的作法。愛料理建立了一個資料湖,IT團隊每天匯入各種日誌(Log),包括無伺服器資料、Cloud Run資料等,再找來既懂業務又熟程式開發的資料產品經理(Data product manager),從中抽取可用資料,放進資料倉儲或資料市集(Data mart),再讓業務團隊自己動手用BI和SQL工具,比如DBT,客製各自需要的儀表板。
李致緯坦言,愛料理曾試過找研發人員擔任資料篩選的角色,但結果不理想。他解釋,研發人員缺乏商業背景,採取這種像是交報告式的任務導向工作形式,他們更難以理解該從資料湖中抽取哪些資料。最後,愛料理的經驗是找來雙重能力的資料產品經理更能勝任。
靠自助式資料分析打造SEO戰情室
愛料理大力發展內部自助式分析作法,後來,更催生出SEO戰情室的誕生。
李致緯指出,過去1、2年來,愛料理花了許多心力,從文章、HTML架構改造下手,來發展「技術SEO」能力來強化曝光成效,但後來發現行不通。所以,去年開始,愛料理調整方向,直接在能看到SEO表現的平臺上(如Google搜尋、Google Analytics或第三方平臺)抓取關鍵產品的成效表現數據,還包括自家產品與特定競品的排名資料。
每天、每周的定期搜集這些資料,全匯入資料湖,再透過DBT打造出一套SEO戰情室系統,用來每周分析每個關鍵字的廣告成效表現。有別於過去只能從個別平臺,分散地分析關鍵字表現的作法,這個SEO戰情室,有能力彙整同一個關鍵字在各平臺的表現,來進行更完整的分析。
程序化廣告很難?愛料理自製儀表板不只管自己還能賣廣告
愛料理還有一項有意思的資料湖應用,與程序化廣告有關。「很多同行都知道,愛料理做了一個很特別的工具,」李致緯說,愛料理團隊開發了大量爬蟲程式,都利用無伺服器容器來執行,專門爬梳各廣告平臺上的廣告數據,包括Google、臉書、雅虎等。同樣每天將這些資料匯入資料湖,來打造一套廣告儀表板,綜合比較愛料理在Google、臉書、雅虎等不同平臺上的廣告表現。
過去,他們只能在各平臺上個別觀察廣告變化,但有了這套儀表板後,就可以每周觀察整個愛料理網站在不同平臺上的廣告表現。比如,儀表板上可以呈現出,愛料理這100萬人次流量在三大平臺的占比、廣告價格和長期變化。
這個儀表板也成了李致緯每周一必看的工作,「特別是觀察那些數字掉下來。」他笑著說,發現有異常,透過先前打造的自助式BI工具,立刻聚焦數據下滑的平臺,快速分析衰退原因。他透露:「這種快速的分析能力,讓業務人員能夠立即處理問題。」這又是一個是愛料理靠技術來強化業務能力的實例。
不管是開發技術、大數據分析或AI技術,李致緯都樂此不疲的嘗鮮,也玩出了愛料理獨特的技術競爭力。
CTO小檔案
iCook愛料理技術長 李致緯
學歷:政大資訊科學系畢業
經歷:愛料理技術長與共同創辦人,也是Inside網站創辦人之一,熱愛開放原始碼並且關注資料應用發展。他常在GitHub貢獻開放原始碼、或於社群分享開源軟體使用經驗,曾入選為Line API Expert和Google Developer Expert for Firebase。2017年入選為富比世亞洲30位30歲以下傑出青年。
公司檔案
愛料理
● 地址:北市中正區羅斯福路二段9號9樓
● 網址:icook.tw
● 成立時間:2010年8月
● 主要業務:開發、營運食譜社群愛料理,以廣告、電商及付費會員作為主要獲利模式
● 員工數:約40人
● 資本額:3,000萬元
● 年營收:2,000萬元
● 總經理:蕭上農
資訊部門檔案
● 資訊部門名稱:服務開發部
● 資訊部門主管職稱:技術長
● 資訊部門主管姓名:李致緯
● 資訊部門人數:約25人
● IT預算:500~1,000 萬元
IT大事記
● 2011年:愛料理網站上線
● 2012年:因應流量成長轉移到公有雲
● 2013年:導入Infrastructure as Code / CI 等DevOps 流程
● 2017年:導入 Data Lake 為基礎的資料處理架構
● 2019年:導入 Serverless 與邊緣計算,降低伺服器計算量
● 2020年:因應疫情流量成長,導入 Multi CDN 架構
熱門新聞
2024-12-08
2024-12-08
2024-11-29
2024-12-08