大膽試新技術不怕砍掉重來， 愛料理玩出不一樣的邊緣運算新模式

你是否曾心血來潮，想自己動手做道料理？

曾在網路上搜尋食譜的你，一定對愛料理（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 架構