因為公司的專案需求，加上公司有培育員工的意義，所以我們有了一個使用Lambda的專案，只不過，這也是我們踏進陷阱的開始。
Lambda的優點我在前一篇文章也有說過了，
- Load Balancer（分流）
- Auto Scaling（自動成長）
- 被駭客攻擊的處理
可以快速想到的優點至少就有這三個，不過實際使用後，而發現了一些問題。
專案描述
在討論Lambda之前，我先解釋一下我們的專案需求吧；其實這個專案，跟我們一般的專案沒有什麼區別，前端用React，後端用NodeJs，不過因為要放在AWS上，所以前端寫完的東西放在S3上，而後端寫好的東西放在Lambda上，為了解發lambda，所以再使用一個API Gateway，當時，資料需要保存，所以也用了RDS，專案的需求上需要發信，所以使用了SES，大概至此為止，跟一般的專案上並沒有什麼區別。
而當這種一般的專案，放在上述的架構上時，問題就發生了，下面我們來談談我們在專案中到底踏了那些陷阱。
問題１－－佈署
當時後台的NodeJS，使用了一套serverless的套件，透過它，下一行指令，就可以將我們寫的程式，丟到S3，並觸發AWS CloudForamtion佈署Lambda，一切都感覺那麼地親切，直到我們後台的API超過33支之後，世界一瞬間就變了樣，它不再是可以利用指令就可以佈署了，原因是AWS CloudFormation的限制；CloudFoamtion的基本算法是Stack，每一個Stack裡面可以包的Resources是200個（參考網址），我忘了serverless到底包了什麼，反正它超過每一個Stack可以包含的Resources限制了，所以抱歉，請自行處理。
解決方法：花人下去瞭解CloudFormation，寫程式解讀我們自己寫的YAML，產生CloudForamtion用的格式，並用Nested Stack的方式解決Limitation的問題。
問題２－－對外網路
當時的Lambda本身要能夠連線RDS（內網），也要能連到SES發信，SES給的端點（endpoint）是公開的，像是email-smtp.us-east-1.amazonaws.com之類的，所以Lambda必須要同時能夠存取內網（RDS）與外網（SES），這個問題如果放在EC2上，因為EC2上會配有虛擬IP與對外IP與，所以可以解決這個問題，不過當Lmabda遇到這個問題時...唉。
解決方法：花錢架一台VPC Gateway，24小時開機。
問題３－－冷開機 (Clod start)
Lambda本身不像EC2一樣是常常在那裡等待觸發的，而是有人要觸發Lambda時，必須先跑一段不知道什麼的東西（這段時間，我們就先稱為「冷開機」吧），然後將我們寫的程式載入後，再執行我們的程式；當然，為了不要常常去做這冷開機的舉動，AWS很貼心的保持了這個機器一段時間後，真的沒有人使用時，它會回收這個資源，以等待下一次的被使用。而這段時間是15分鐘，也就是說15分鐘後，如果沒有人呼叫你的程式，那麼下一次呼叫的人，必須再等待一次冷開機的時間。因為這個問題，被開了一個Bug是－－「使用者等待時間太久」...
解決方法：目前網路上沒有好的解決方法，真的要解決的話，必須定時去觸發Lambda...。
問題４－－執行時間
Lambda是依據執行時間來運算的，AWS為了解決因為我們寫的程式造成Lambda無法結束而一直被算錢的問題，所以推出了一個「時間限制」；這個時間限制是使用者可以自行定義的，只要超過這個時間，AWS強制判斷是我們的程式有問題，而很貼心的幫我們把Lambda關掉（誰管你的程式在做什麼），替我們省下額外的開銷...。應該看得懂我在描述什麼吧，沒錯，誰管你的程式在做什麼，時間到了我們就要關店了，明天請早。對了，時間限制的上限是５分鐘喔，就算你故意延長時間限制，了不起到５分鐘，所以你的程式執行時間不能超過５分鐘，超過就...。
解決方法：重新檢視邏輯，如果一定會超過5分鐘的話，Lambda是可以呼叫Lambda的，將資料帶到下一個Lambda處理吧...。
雖然還有遇到其他問題，不過這幾個問題是主要的，是可以讓讀者重新確認要不要使用Lambda的問題；如果你是要用Lambda開發程式的，請確認上述的幾個問題，這是過來人的經驗。
留言列表
工具 (1)
