你是否曾心血來潮，想自己動手做道料理？曾在網路上搜尋食譜的你，一定對愛料理（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邊緣運算服務上進行用户端API請求的打包。他解釋，因為愛料理有很多種用户端程式，當使用者的手機App發出請求時，愛料理會透過GraphQL指令來向後端抓取資料，這類的GraphQL請求很多，現在李致緯透過CDN邊緣運算的簡單邏輯處理，可以在用户端一次打包多個GraphQL請求，一次送到CDN節點後再分散、各自處理這些請求，完成後再將Response整併為一包回傳，如此可以減少用户手機端發出請求的次數。

愛料理用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機器是否夠用。

或像是，過去愛料理要擴展服務時，得先開一台能支援AP的虛擬機器EC2，來執行Docker以便快速部署容器化應用。李致緯後來就是改用無伺服器容器（Serverless container）服務，來解決過去必須等待底層VM開機的斷點問題。

愛料理目前三分之一的服務採用無伺服器容器，預計今年底，半數服務會改用無伺服器容器。這種採用CDN邊緣運算和無伺服器容器的混合式架構，就是李致緯用來取代純微服務架構的作法。

倒各種資料到資料湖，讓PM動手用BI、SQL工具找洞察

不只開發和維運大玩新技術和架構，對於時下最熱門的AI和資料分析應用，李致緯也有一套自己獨特的作法。愛料理建立了一個資料湖，IT團隊每天匯入各種日誌（Log），包括無伺服器資料、Cloud Run資料等，再透過懂業務、也懂程式開發的資料產品經理（Data product manager）從中抽取可用資料，放進資料倉儲或資料市集，接著讓業務團隊動手用BI和SQL工具，比如DBT，來產出所需的儀錶板。

李致緯坦言，愛料理曾試過讓RD人員來擔任撈資料的角色，但結果不理想。因為，「RD沒有商業背景、偏任務導向，就像交報告，難以理解該從資料湖中抽取有用資料；」因此才由有業務背景、懂程式開發的資料產品經理負責。

靠自助式資料分析打造SEO戰情室

這種自助式分析，催生出SEO戰情室。去年開始，愛料理改變原有的技術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 架構