因為公司的專案需求,加上公司有培育員工的意義,所以我們有了一個使用Lambda的專案,只不過,這也是我們踏進陷阱的開始。

Lambda的優點我在前一篇文章也有說過了,

  1. Load Balancer(分流)
  2. Auto Scaling(自動成長)
  3. 被駭客攻擊的處理

可以快速想到的優點至少就有這三個,不過實際使用後,而發現了一些問題。

專案描述

在討論Lambda之前,我先解釋一下我們的專案需求吧;其實這個專案,跟我們一般的專案沒有什麼區別,前端用React,後端用NodeJs,不過因為要放在AWS上,所以前端寫完的東西放在S3上,而後端寫好的東西放在Lambda上,為了解發lambda,所以再使用一個API Gateway,當時,資料需要保存,所以也用了RDS,專案的需求上需要發信,所以使用了SES,大概至此為止,跟一般的專案上並沒有什麼區別。

而當這種一般的專案,放在上述的架構上時,問題就發生了,下面我們來談談我們在專案中到底踏了那些陷阱。

問題1--佈署

當時後台的NodeJS,使用了一套serverless的套件,透過它,下一行指令,就可以將我們寫的程式,丟到S3,並觸發AWS CloudForamtion佈署Lambda,一切都感覺那麼地親切,直到我們後台的API超過33支之後,世界一瞬間就變了樣,它不再是可以利用指令就可以佈署了,原因是AWS CloudFormation的限制;CloudFoamtion的基本算法是Stack,每一個Stack裡面可以包的Resources是200個(參考網址),我忘了serverless到底包了什麼,反正它超過每一個Stack可以包含的Resources限制了,所以抱歉,請自行處理。

解決方法:花人下去瞭解CloudFormation,寫程式解讀我們自己寫的YAML,產生CloudForamtion用的格式,並用Nested Stack的方式解決Limitation的問題。

問題2--對外網路

當時的Lambda本身要能夠連線RDS(內網),也要能連到SES發信,SES給的端點(endpoint)是公開的,像是email-smtp.us-east-1.amazonaws.com之類的,所以Lambda必須要同時能夠存取內網(RDS)與外網(SES),這個問題如果放在EC2上,因為EC2上會配有虛擬IP與對外IP與,所以可以解決這個問題,不過當Lmabda遇到這個問題時...唉。

解決方法:花錢架一台VPC Gateway,24小時開機。

問題3--冷開機 (Clod start)

Lambda本身不像EC2一樣是常常在那裡等待觸發的,而是有人要觸發Lambda時,必須先跑一段不知道什麼的東西(這段時間,我們就先稱為「冷開機」吧),然後將我們寫的程式載入後,再執行我們的程式;當然,為了不要常常去做這冷開機的舉動,AWS很貼心的保持了這個機器一段時間後,真的沒有人使用時,它會回收這個資源,以等待下一次的被使用。而這段時間是15分鐘,也就是說15分鐘後,如果沒有人呼叫你的程式,那麼下一次呼叫的人,必須再等待一次冷開機的時間。因為這個問題,被開了一個Bug是--「使用者等待時間太久」...

解決方法:目前網路上沒有好的解決方法,真的要解決的話,必須定時去觸發Lambda...。

問題4--執行時間

Lambda是依據執行時間來運算的,AWS為了解決因為我們寫的程式造成Lambda無法結束而一直被算錢的問題,所以推出了一個「時間限制」;這個時間限制是使用者可以自行定義的,只要超過這個時間,AWS強制判斷是我們的程式有問題,而很貼心的幫我們把Lambda關掉(誰管你的程式在做什麼),替我們省下額外的開銷...。應該看得懂我在描述什麼吧,沒錯,誰管你的程式在做什麼,時間到了我們就要關店了,明天請早。對了,時間限制的上限是5分鐘喔,就算你故意延長時間限制,了不起到5分鐘,所以你的程式執行時間不能超過5分鐘,超過就...。

解決方法:重新檢視邏輯,如果一定會超過5分鐘的話,Lambda是可以呼叫Lambda的,將資料帶到下一個Lambda處理吧...。

 

雖然還有遇到其他問題,不過這幾個問題是主要的,是可以讓讀者重新確認要不要使用Lambda的問題;如果你是要用Lambda開發程式的,請確認上述的幾個問題,這是過來人的經驗。

arrow
arrow

    JAVA Programmer 發表在 痞客邦 留言(0) 人氣()