標籤
在 AWS 的 API gateway 上就有一個項目(Authorizer)是支援 Cognito 以及客制認證的方法，好處就是在進我們寫的 API 之前有個可以做身份確認的 Lambda Function 幫我們好前處理，而本篇則會介紹如何在 Serverless framework 上設定 API gateway 的 Authorizer 以及成功讓 API 回應，串接 Cognito 做使用部分就留給之後吧！
最近 LINE 釋出了一個我很喜歡的功能 - Icon Switch🎚，從字面上的意思就是可以切換機器人的 Icon (名稱以及大頭貼)，過往開發者在使用時都只能較死板的使用同一個頭像或暱稱來回應使用者，而現在只要使用這個這個功能就可以很輕易地切換你想要的大頭貼以及暱稱了 😇
據可靠消息指出這以前是需要收費的功能，而現在則是免費推出來給大家使用，讓大家可以有更多的彈性去開發新功能～
之前鐵人賽寫了一篇文章有提到 Cold Start 的問題，不過只有粗略介紹，最近看到大家忽然又開始討論這個話題，這次就來好好的搜尋資料介紹一下。
平常在做 open source 時比較常遇到休眠狀態應該就是 Heroku，而開頭要先澄清一下他是屬於 PaaS 的架構，而 AWS、Google、Azure 裡提供的 Lambda、Cloud Run、Azure Function 這些則屬於 FaaS 架構，而最常討論 Cold start 時最常會在 FaaS 上討論，只是剛好 Heroku 使用起來也是一樣，這次文章就把他一起抓進來討論啦～
有很多各式各樣的服務，SaaS、FaaS、KaaS、IaaS... 等各式各樣的架構，每個都是為了解決某個問題所誕生的，至於好或不好其實就是看使用場景而定，所以大家在選用時要注意一下你使用的場景哦！
一般會有休眠機制是因為這些供應商在提供服務都是提供按次計費的方案，讓開發者在用時可以需要才喚醒使用，也就是說這些服務都是 事件驅動(Event-Driven)導向，意指是當前服務若收到訊息後，會呼叫對應的 Function 來處理對應服務所接收到的資料(Queue、Notify ...)，但相對的就是會有休眠讓服務暫停，進而讓較少使用的服務不會因為掛在線上而一直被收費用，而重新啟動這件事就是本篇要提的Cold start。
在處理資料之後過一段時間若沒有繼續執行，雲端供應商會將模組暫停，此時 function 會處於 inactive 狀態(cold)，而當 function 再度被觸發時(cold start)則會再啟動模組來執行對應 function 來處理事件，在模組與 function 之間的關係可以稱他們為 Function chain。
以 AWS 為例，在喚醒時會到 S3 去取得檔案，接著找到相關的 Lambda 並載入相關模組套件，然後再執行觸發的事件，整理過後的下:
事件處理 ➡️ 過段時間 ➡️ 暫停 function 模組(休眠) ➡️ 觸發 ➡️ 啟動 function 模組 ➡️ 事件處理...
這整個流程就是俗稱的 cold start，因為在這個過程中會花些時間，所以若是拿來處理 api 相關問題的話就會有第一批請求很久，然後之後的請求卻特別快的狀態，請大家莫急莫慌莫害怕呀！
| 平台 | 多少時間後暫停 |
|---|---|
| AWS Lambda | 10 minutes |
| Google Cloud Functions | 介於 3 minutes 之間 5+ hours 都有 |
| Azure Functions | 20 minutes |
| Heroku | 30 minutes |
前三個為
FaaS架構，而 Heroku 則為PaaS架構喔！
下圖則來自 2019/09 的一篇文章，較深色的部分則為啟動時間。
以我熟悉使用 serverless framework 部署到 AWS 來說，他們提供了一個 warm-up 的套件，可以設定排程時間讓這個 function 固定去戳其他 function，避免他們進入休眠的狀態，雖然這樣子就能達到跟一般服務一樣的常駐狀態，不過相對來說就要注意次數的使用問題，若是流量還小的話沒什麼問題，但若有一定的流量就須注意一下帳單，因為這些在互戳的過程中還是有算進費用的喔！使用上還要多注意才行。
另一方面要注意相依套件的問題，引用 google 文件的其中一段:
謹慎使用依附元件，如果您使用動態語言搭配相依的程式庫，例如匯入使用 Node.js 的模型，這些模組的載入時間會增加冷啟動期間的延遲時間。您可以透過以下方式縮短啟動延遲時間：
畢竟在載入模組的時候相依套件也是要一起抓進來，若是程式本身太多依賴的話也是會導致 cold start 的時間變長哦！
最後就在幫大家整理一下三大平台的 warm-up 資源：
為什麼要有 cold start 的機制，以供應商的角度來說他們可以提供一定的量讓使用者免費在平台上先建置服務，但若要免費就是服務會被暫時暫停，畢竟現在流量就是錢嗎 💰，像我常用的 Heroku 就會是這樣，而當你流量大的時候就看你要不要搬家，不過一般應該都懶得搬，就會形成所謂的養、套、殺🤣(離題)。
總而言之，若是需要服務時常活著，就是需要付出點流量的錢 💰，也或許你的作品服務時間可能不用那麼長，只要在服勤時間內長駐活著就可以在省下一些費用，如果有需要的話還是付一些錢給供應商，畢竟人家也幫你保管了服務你說是不是？
礙於最近做事有點手忙腳亂，沒有很有效的管理時間，記錄下來讓往後能有個經驗可循並增加自我管理能力。
我記得上次自己弄 docker container 已經是一年多前，當時還結合 Drone CI 來跑(好久了 👀)，對於 Dockerfile 使用方法依稀有點印象，而最近因為看了許多 open source 後對於 Dockerfile 的內容了解度也提升了許多(實在是個不錯的方法 👍)，會這樣子弄的原因是我認為 Serverless 的架構很容易被 AWS 綁架，我認為 API 這類可拆出來的功能應該要包成 container 增加彈性不讓平台限制，被這個想法 trigger 後就來好好練習 Docker 了 🏋️♂️。
這次使用 Twitch-Bot 做我的練習對象，裡面主要用了 node 以及 mongo 兩個服務，在此同時如果各別起 docker 挺麻煩，因此就需要使用 docker-compose 幫忙啟動，而在這過程中學到了:
network 連接兩個容器的使用方法。接下來就是趁六月 credit 過期前趕快來玩玩 Google Kubernetes 🚀
最近在公司實作 AWS IoT Job 部分的功能(以下稱為 Job)，因為 Job 每次執行收費約 1 塊台幣，之所以會用它是因為在 IoT 執行時不是只會單純發送訊號出來讓後台收訊號做事，而是需要跟後台經過一連串的溝通來達成功能(例如 韌體更新)，當然還有很多更複雜的功能，這邊只列舉一個小部分。
從這段時間的實作上學到的部分:
當後台的 Queue 同時塞進很多工作時要如何管理並通知裝置此時的工作有哪些(All Job)以及要做哪件事(Next Job)，實作這功能時不能只考慮到一個裝置，而是考慮到 N 個裝置時要如何過濾並管理狀態機，限制裝置要依照狀態執行避免系統錯亂。
之前主要功能都是介接 AWS IoT，而這次是要實作一個類似的功能提供給其他使用者，不能只開一個 API 就想要功能都包好，而是將功能明確劃分，讓使用者可以有彈性的去組合，只是在此時我沒有處理得很好，之後的 Task 需要更注意。
參考 Pull Request: Add narrowcast client api #237
功能主要是讓開發者可以透過 API 來做分眾的推播，在實作這個 issue 時讓我原本模糊的工廠模式清晰了許多，主要是 SDK 使用了 Python Class 來擔任 Model 的角色，讓進來資料可以經過 model 去轉換成對應的 key-value，所有的資料都分類進去對應的工廠處理完再回傳出來。
在還沒開始看 code 前只想著要寫什麼邏輯去處理，其實使用 Model 的方法就處理掉大部分資料格式的問題，很多 LINE 文件已經清楚定義的格式只要照著填就解決了，只是在這個 Task 遇到了Python 保留字的問題，而經過各種 google 後只好自己寫邏輯去判斷掉這件事，之後只能繼續看有沒有更好的寫法可以取代掉這個保留字的問題。
官方 Github 有寫要 Contribute 時需要執行的內容(參考)，lint 則是遵照flake8，而執行tox後會對每個版本的 python 去做測試，但像我電腦只有 3.7 版 tox 就只會針對這個版本做測試。
tab 與 空白鍵(space) 的差異，PEP-08 上也告訴建議使用空白鍵，而 python 3 之後也不允許兩個混用，畢盡 python 是很注重縮排，既然官網都寫了哪有不遵守的道理呢？😃Lint 也不會無緣無故來刁難開發者 XD
public、private 的觀念，透過這樣的方法來表示它(Class、Function)是一個內部函式，藉由 Lint 讓開發者可以知道這個功能是內部還外部，只是在 python 只能使用這個 lint 讓大家遵守這規則，如果沒有 CI 要硬上的話其實也管不住，畢竟不像 golang 這類語言會編譯(汗顏)。總之使用 lint 的好處就是開發風格可以統一，能夠盡量避免不必要的 programing 麻煩，在寫任何語言都推薦使用各個語言的 lint，雖然一開始會很討厭它，但它真的是在幫助你 😆。
這時間與家人一起訂閱了一年份的會員，而我的初衷就是想把英文學好，而我也花了時間好好的看完一部全英文影集(發英與字幕)，第一次嘗試這樣看全英文，並且邊看邊 Google 翻譯不懂的單字同時口述跟著念一遍增加記憶力，隨著工作量減輕後下班也可以再安排時間繼續看下個影集學了～
然後迷上了
愛的迫降這個韓劇，推薦喜歡看愛情片的朋友去看 ❤️
最近剛好因為這傳染病盛行，除了防疫之餘，g0v 也提供 API 讓開發者可以拿去介接，隨著大家各種開發前端 web 以及 chatbot ...的應用後本來在想有個什麼想法可以參與這個全民黑客松，只是我認為用途實在重複性太高，而在大家開發應用時我又剛好在寫 LINE SDK，錯失了第一時間發佈口罩相關的服務建立時間，本來想到 LIFF v2 + LINE Notify，但只是在使用上很容易吵到用戶進而封鎖它(LINE Notify)，因此要考慮好功能再來看會不會有比較好的使用情境。
出入公共場所記得戴口罩，有帶隨身瓶酒精的記得消毒！😷
有時候在思考與規劃的過程中如果經驗不夠時真的很難馬上到位，不過任何事情都一樣，若這件事可以輕鬆且又得心應手，代表它可能已經是你熟悉的領域或是過於簡單，就像我一開始處理社群一樣，若是沒有前輩們帶著走的話我跟本無法有效地處理事情，總之凡是起頭難，即早加入即早熟悉各個領域才是王道 😆
Serverless 架構是一個基於 FaaS(Function as a Service) 實作的一個服務，讓開發者可以更專注在開發功能，將 yml 檔設定好其餘維運的問題都交給 AWS、Google、Azure 這些服務商去處理，只要把信用卡準備好就好(?)，讓開發者在寫完程式之後不用煩惱部署得問題，減少的不少的麻煩事。 那因為現任公司的服務都是基於 AWS，如此這般我就接觸到 Serverless(以下簡稱 sls) 這個框架啦 (想更深入了解 FaaS 架構可以參考 AWS) [2019/07/04 更新] 若已經暸解的朋友可以參考我的 python 版本: louis70109/aws-line-echo-bot Ruby 的範例版本: louis70109/aws-ruby-line-echo-bot
[2019/06/29 更新] 以用一個 Ruby on Rails 寫的機器人為例，在寫完個 webhook function 後，設定路由然後部署，一般主機或是虛擬機就很麻煩，要安裝佈署環境以及一安裝堆相關套件，完了之後設定 Domain 什麼的有夠花時間。但若是使用 heroku 部署就很方便，Login — Create-Deploy 馬上就結束，機器人馬上就上線了，實在是俗又大碗呀～ 但我覺得像是 LINE Message 這種 stateless 的服務，且只要一個 function + route 就能實作的程式最適合 Serverless 了，讓專案可以簡潔有力，只要寫一個 function+yml 設定並打個指令就部署了，而且 domain 還附贈 SSL，將服務交給 AWS 也不需要擔心，整個就是超級方便啊！ Cold start time 問題，依照我目前使用的結果下來，在 heroku 以及 AWS Lambda 同時睡著的情況下，AWS 起床的回應速度大概 1 秒左右，而 heroku 則大概落在 10~15 秒(參考)。如下圖所示的免費方案，基本上開發階段應該是不至於到 100 萬/月 個請求吧 😆，所以這部分就別擔新大力地給他用下去～ (感謝 petertc 幫忙找這方面的問題 💪)
AWS Lambda 免費方案
接下來就讓我介紹如何使用 sls + LINE Message API 建立一個 Echo bot 吧！
npm 6.9.0 python 3.7.3 serverless 1.45.1
首先要先有個 AWS 帳號(廢話) ，如果沒有綁定信用卡記得去綁定才能繼續，接下來就可以去就可以去建立鑰匙囉！
如上圖，按下紅色框框的部分，接著按箭頭指的按鈕，就會建立一個我們要的金鑰囉！
如上圖所示，可以下載 key，AWS 不會幫忙保存 Secret key，若這視窗關掉的話 key 就不見了，所以使用者可以自行下載檔案保存，以免哪天要部署的時候找不到 key。 接著就將這兩個參數加入環境變數中：
export AWS_ACCESS_KEY_ID=<your-key-here>
export AWS_SECRET_ACCESS_KEY=<your-secret-key-here>
首先先透過以下指令讓 npm 幫忙安裝 sls 的指令。
npm install serverless -g
安裝完之後就透過 sls 指令來建立專案嚕！
serverless create — template aws-python — path aws-line-echo-bot
severless 指令可以縮寫成 sls template = 想用什麼平台以及語言就在此模板了 (參考) path = 檔案名稱
透過 severless 建立專案指令 依照不同的 template 可能會建立 N 個檔案，但主要還是以下三個檔案
.gitignore
handler.py = 主程式的地方
serverless.yml = 所有設定都在這裡，funtion 參數會對應到指定的路由
在部署前須至 serverless.yml 裡，把 runtime 的 python2.7 改至 3.7，否則會因版本問題導致錯誤。
serverless deploy # sls deploy
接著到 AWS Lambda 以及 S3 就可以看到第一次部署完的程式以及檔案囉！
既然是寫 python，那一定是要用 line-python-sdk 照著官方用法應該是要執行以下指令安裝套件
pip install line-bot-sdk
不過我們是要部署到 AWS 的 Lambda 上，且因為他是無伺服器運算的服務，所以他沒辦法跑 pip 去幫我安裝套件。 此時就要出動 requirements.txt 來管理相依套件 ，但只有加入它 sls 根本不認識，因此我們需要安裝 pulgin 來讓 sls 認得(requirements.txt)。
sls plugin install -n serverless-python-requirements
安裝指令 & package.json 如圖，安裝過程中會自動建立 package.json，且會幫忙在 serverless.yml 裡面加入 pulgin，這樣 sls 在部署時就認得 requirements.txt 囉！ 接著將 LINE SDK 加入 requirements.txt， AWS 就會幫忙安裝套件了。
echo "line-bot-sdk==1.12.1" > requirements.txt
然後新增一個 setup.cfg 並加入以下內容：
[install]
prefix=
由於 AWS Lambda 上都會將套件安裝在本地端(Lambda 上)，因此在執行 pip install -t . -r requirements.txt 時會需要 setup.cfg。
至於詳細原因嘛～還有請各位大大幫小弟解答 🙏
最後就處理 handler.py 以及 serverless.yml 囉！
將上述兩個 gist 分別貼到自己的 handler.py & serverless.yml，在 hanlder.py 裡的 CHANNEL KEY & TOKEN 記得換成自己的機器人 👾 哦！
接著在執行一次 sls deploy，將程式部署上去，如上圖所示，在 endpoints 那行會有一個網址，將那網址放到 LINE Webhook URL 上並 Verify 看看有沒有成功，如下圖所示。
最後對著自己的機器人發個話，看他有沒有回應你一模一樣的文字，若成功了就能往下一步應用層繼續開發囉！若失敗了就要檢查一下是不是有哪個步驟做錯了～
因為公司的緣故讓我能夠接觸到這神奇的 Serverless，經過這次的分享加深我對於 FaaS 的架構更加了熟悉，由於我也是初碰，我認為使用上可以把它當作是一個 Docker 的容器或許概念上會比較好理解，後續還有很多的設定檔都還沒詳細研究，最近讓我先研究研究一下再上來分享。
文章中有任何勘誤歡迎指正
如果覺得這篇文章有幫助的話請給我個掌聲鼓勵我一下 👋 下列是我的這次實作的專案，如果有幫助也來顆星星吧！ louis70109/aws-line-echo-bot
大家好，我是 NiJia
以下是我最近參加 IT 邦幫忙 30 天鐵人賽的文章列表，主要是紀錄從我進入新公司後學到的Serverless，並透過結合 LINE API 實現在 AWS 上，歡迎大家參考取用 😃
其實個家園端平台多少都會有這問題，畢竟大家都是靠流量賺錢，自然會需要個方法限制使用者，不然免費爽爽用他們也不是做慈善的 🤣，像我最常用的 Heroku，只要 30 分鐘沒有使用他就會進入睡眠時間(參考)，叫醒的時間需要 10~15 秒，不過對於我這個免費宅來說測試夠用了 🤣
AWS以我實際測試起來大概 2 秒左右，回應時間看起來不會太差，其實第一天就有提到這部分，需要的話可以參考。
若是需要它隨時都在都活著的話就要搭配 warm-up，抑或是搭配 crontab 去設定特定時間執行 warm-up。
在快速成長的前、中期是很適合這個服務的， 畢竟開發者只要將 serverless.yml 基本設定完之後就可以先好好開發，等到中期之後把設定檔稍微整理一下又是一尾活龍了，且平台大多都擁有 auto-scaling 的功能，在服務快扛不住流量的時候只要錢拿出來平台就幫你解決。
只是說當流量越來越大之後相對錢也會越付越多，或許當流量 > 10K 之後代表你的服務應該也有不少人使用了，自己架主機應該不會是什麼難事(?)
幫忙推廣一下 Backend 大大的 高流量心得雜談
在 FaaS 架構下其實很適合 Chatbot 的服務，以概念來說實作時只需要一個路由**(Function)**即個完成，不需要額外太多的資源去處理 web server 的問題，像是這個系列的只要透過 serverless + WSGI 就可以馬上就可以進行本地測試，部署只要下 sls deploy，實在是超級快又輕鬆，不用像以前一樣還要去處理 Nginx 等等相關的問題 😁。
且 AWS、Google 在使用 python 跟 nodejs 上支援度很高，也不用怕找不到資源使用。
使用 Node JS 的朋友可以參考 C.T Lin 大大的文章，他們家的 bottender 超猛的！
在 Log 這部分我覺得 AWS 有點不太好的地方就是他們的 Cloud Watch 應該是獨立服務，當我的 Lambda 輸出紀錄時大概要過 10 秒才會印出來，不像以前自己架主機時只要進 server 就可以馬上切到目錄看紀錄抓蟲，在使用這雲端服務可能在抓蟲有一半的時間都在等 log 出來，有時候急的時候還真的會被氣死 😭。
像是我前一陣子發的一篇文章，SNS 被觸發事件之後回來的東西是舊的，那時候看到錯誤訊息真的是心很涼，就得用一個 Lambda 排程一直去抓 DB 的 updated_at 欄位有沒有變更時間而去更新狀態，這樣情況就會多浪費一個 Function 去處理這樣的事件，不得不說專門來支援 AWS 服務的 boto3 套件(python)在某些時候做的事不是那麼完善，得使用旁門做到的方法去完成這件事，讓整個開發體驗不是那麼好，若他們可以把一些 error handle 弄更好那就完美了。
其實還有好多服務沒有玩到
但其實使用 AWS 來實作 Serverless 的服務也是這一陣子加入新公司所學到的新技能，過程中總是會用舊的開發思維去想，但常常都因為這樣落坑 😓，但也因此讓我更了解像 AWS 這類的雲服務他們是如何開發每個服務並如何串接，同時也研究了 Serverless 相關的 plugins，看他們是如何支援雲平台讓開發者在開發時可以更像平常時在開發 web，也因為這樣我去貢獻了 example 到了 Serverless 的範例專案上面(參考)，慶祝完成人生第一場鐵三十，跟自己的競賽也告一段落，發現趕著寫文章品質真的會差很多，看來是時候該整理一下，謝謝您的收看 <(_ _)>
在之前的文章都有將 Notify、LINE Login所需要的靜態頁面放在 S3 上面，讓其他使用者去點，雖然把前端放在程式裡面用 render template 比較好，可是在求快的情況下我把靜態頁面寫完就扔上去了(被拖走)，其實也可以透過這個方法去幫忙轉址，不過接下來我會用我的臉書做個範例提供參考～
照著之前的範例來建立一個名為 facebook.nijialin.com 來做 S3 轉址的範例
建立完之後因為我們需要把網址公開給其他使用者點選，在第三個分頁中先把第一個選項的 Block all public access 更換成 off 狀態
到第二個按鈕選項選擇 Public access，暴力一點把所有選項都打開 🤣
前面都已經把權限開完，選擇Static Website hosting這個選項，這個是 S3 提供來讓他有另一種功能，不過我是覺得這功能在這邊有點奇怪 XD
接著就來到 Route 53，點選左欄的 Hosted Zone
點選上面藍色的按鈕，右邊會出現輸入的地方讓你填
這邊我會輸入跟 S3 bucket 的名字一樣，然後 Alias 選擇 Yes，下面輸入框點下去會看到自己剛剛輸入的 S3 website endpoints
建立完之後就可以在瀏覽器上輸入網址，他就會導去你預設的網站囉！向我這邊就是拿我的 facebook 來做示範。
我透過這個方法幫我把 medium 的部落格網址重新導向，因為我想之後若是有獨立建立部落格的話網址會是一樣的，當有點粉絲的話至少他們認得的網址會是一樣的 😁。
首先先建立一個consumer/資料夾，新增__init__.py以及notify_handler.py
在notify_handler.py輸入以下程式碼
import json
import requests
def line_notify_handler(event, context):
print(event)
body = json.loads(event['Records'][0]['body'])
print(body)
headers = {
'Authorization': f"Bearer {body['token']}",
'Content-Type': 'application/x-www-form-urlencoded'
}
r = requests.post('https://notify-api.line.me/api/notify',
headers=headers,
data={'message': body['message']})
print(r)
# AWS record sample
# {'Records': [{'messageId': 'fddc42ba-a122-4581-965e-d0144ac8a5ad', 'receiptHandle': 'AQEBjO32gY5pXOfOrmDR0hD4k1av9KyjbHFpc+rIBPV2Brif7Lo+jqnGevSjfFwlICyGf+BhWwKaxFw8XdB3QTzRbw0vnLURjnQeDSBrJHa/S57SRs9TOLRBq38maycAVg69iZbetg9VhLMBCcLtOtPHTzKkmo+/Sosm51WA5CzXK7A0rteikx6nxS1CUIpq6MAujodupP0Hgr5RjK5nH/nmxA4Db0leWEmLokalZbtlx4W14tp7PZxPOrQOLDaGrH//p4h32tY8IN3MkCqi+gyNT7kCU4KwCGOIrybb07ZWyKBTKw+KOMNr/Ykj4z2N1qxIvTM55UY9d8V29YsH32OjrZTei5P7Nke/51E2tWkmkqoFAlqzxDjQPvpP+Pvvr8aazeeZ6opkr59UefAiiyM71Q==', 'body': 'hi', 'attributes': {'ApproximateReceiveCount': '9', 'SentTimestamp': '1566621263072', 'SenderId': '901588721449', 'ApproximateFirstReceiveTimestamp': '1566621263072'}, 'messageAttributes': {}, 'md5OfBody': '49f68a5c8493ec2c0bf489821c21fc3b', 'eventSource': 'aws:sqs', 'eventSourceARN': 'arn:aws:sqs:us-east-1:901588721449:LINE_notify_consumer', 'awsRegion': 'us-east-1'}]}
接著在requirements.txt加入boto3，他是一個使用 python 介接 AWS 的套件
boto3==1.9.189
加入SQS_URL以及SQS_ARN到.env裡面
SQS_URL=sqs url
SQS_ARN=your sqs arn
add controller/notify_sqs_controller.py
from flask_restful import Resource, reqparse
import json
from lib.db import Database
import psycopg2.extras
import os
import boto3
def send_message(url, attr, body, delay=0):
cli.send_message(
QueueUrl=url,
DelaySeconds=0,
MessageAttributes=attr,
MessageBody=body,
)
class SendNotifyBySQSController(Resource):
cli = boto3.client("sqs", region_name=os.environ("region"))
def post(self):
parser = reqparse.RequestParser()
parser.add_argument(
'message', required=True, help='message can not be blank!')
args = parser.parse_args()
msg = args['message']
with Database() as db, db.connect() as conn:
with conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor) as cur:
cur.execute(
f"SELECT token FROM notify")
fetch = cur.fetchall()
for f in fetch:
body = {
'token': f"Bearer {f['token']}",
'message': f"Hello everyone, {msg}"
}
cli.send_message(
QueueUrl=os.environ("SQS_URL"),
DelaySeconds=0,
MessageAttributes={},
MessageBody=json.dumps(body),
)
return {'result': 'ok'}, 200
程式寫完了就是要加一條路由/notify/sqs
from controller.notify_sqs_controller import SendNotifyBySQSController
api.add_resource(SendNotifyBySQSController, '/notify/sqs')
接著透過wsgi在本地起一個 server
sls wsgi serve
再搭配 postman 來做測試，測試內容如下
{
"message": "test Content"
}
接著透過sls deploy部署上會遇到一個問題，會有 Access Denied，所以要在serverless.yml加入 IAM role 的設定
add iam in provider
iamRoleStatements:
- Effect: Allow
Action:
- sqs:SendMessage
Resource:
- ${env:SQS_ARN}
使用 SQS 這類服務都會需要透過boto3來幫忙串接，最需要注意的就是 IAM role，因為在本地端的 key 通常權限都是最大的，但上到 AWS 上就會有權限的問題，所以要記得加入 IAM 哦！
Code is here
專案也會持續更新，更多詳情可以 follow 我的專案 aws-python-line-api。
以前自己在架伺服器的時候，提到訊息佇列不外乎都是 RabbitMQ 或是 Kafka，只是現在 AWS、GCP 這類的雲端平台都越來越火紅了，手動按一下服務就建好了(信用卡也在哭泣)，省去很多建立服務的時間，只是說一般時候根本找不到項目練習 😓，剛好最近在複習 LINE Notfiy，就趁這個機會順便練習並記錄一下 ✌️
當 Http requests 非常大量到一定程度，database 已經跟不上處理的速度，尤其是 relational database，這時就需要 queue 來緩衝；所以社群網站像 Facebook or LinkedIn 都使用大量的 message queue and cache. By -> Leonard Lee
SQS 就是 managed queue service，主要就是 async, central messaging (對相對應的程式來說，通常處理 api 的會有多個 instances 同時存在，像是 auto-scaling)，像是 fb 通知、寄送 email 認證信這種不用即時處理的情況，只要給訊息給 queue 讓其他服務或程式去處理，可以把原本的邏輯簡化(以及責任區分)，甚至些事件是預期同時會有多個 listener 會需要處理的情況，在一個 api 裡面去處理這些會讓邏輯變很複雜/不好維護。 By -> Bill Chung
還有就是如果負責處理 request 的 host 有問題，message queue 可以用來短暫儲存還未被處理的 requests 使他們不至於丟失，直到 host 回復正常或是換了一個好的 host 後，message queue 裡面的的 requests 就可以繼續被處理 By -> 盧元駿
以上來自我之前寫過的文章 使用 Serverless 讓 AWS SQS 幫你發送 LINE Notify
今天在需要發個請求去呼叫 LINE API(或是其他服務的 API)，都可能會碰到圖片，圖片不管他怎麼壓縮，終究還是比文字肥，在數量多的情況下可能就會發現 API 罷工(就會像被斷詠唱一樣)。雖然平常使用可能不會這麼平凡呼叫，但若在商業用途上使用者多的時候一次呼叫就會有一大筆，這時候用 Queue 讓他們排隊一個一個來就在適合不過了 🎉。
Amazon Simple Queue Service (SQS) 是全受管訊息佇列服務，可讓您分離和擴展微型服務、分散式系統及無伺服器應用程式。SQS 可免除與管理和操作訊息導向中介軟體相關的複雜性及開銷，也可讓開發人員專注在與眾不同的工作上。您可以使用 SQS 在軟體元件之間傳送、存放和接收不限數量的訊息，不會遺失訊息或需要其他服務可用。使用 AWS 主控台、命令列界面或自選的 SDK 以及三個簡單的命令，即可在幾分鐘內開始使用 SQS。(參考 AWS)
SQS 有在免費方案裡面，只要一個月別高於 100 萬個請求就不會被收錢啦 💪
AWS 的免費方案可以參考 -> LINK
接著就要開始引入 SQS 嚕，首先到 AWS 上的 SQS 頁面，如下
接著選左邊的Standard Queue並填入 name 就好
建立完之後就可以看到下面有建立完的資訊
ARN 以及 URL 接下來都會用到哦
接下來會帶各位使用 Notify 接在 SQS 上，這篇就先帶各位介紹並先手動建立一個 Queue，之後會在大家使用 python 的 boto3 的套件來搭配使用 AWS 服務使用 👏
Amazon Simple Storage Service(簡稱 AWS S3)是 AWS 的一個線上儲存服務，用戶能夠輕易把檔案儲存到網路伺服器上，可能有些朋友會把它當成雲端硬碟看待，但其實還能像是傳靜態檔案上去，若有寫前端框架的朋友通常都會需要把程式碼打包成靜態檔案再部署，然而這邊把他打包送上去後，S3 會給一個名為 Object Url 的網址，可以透過這個網址去執行網頁裡面的內容(如 AJAX、Axios...)，並可以透過 cloudfont 去弄成 CDN(扯遠了)，簡單說他還有很多不一樣的功能應用等著大家去用～
因為 serverless 只能放關於 API 的程式碼，因此我們需要把 html 靜態檔案放在 S3 裡，
接下來就來建立一個公開的 S3 容器，這邊就不會提到權限如何控管哦！
建立一個名為2019-it-30-bucket的容器，地區就選與 Lambda 同樣的地區，直接按下左下角的create來建立。
建立完會像這樣
接著點進去後在點到第三個選項會看到 Block of public access 是啟動的狀態，因為我們接下來需要讓我們的頁面可以外部使用
就把 check box 的按掉，在按下 Save
要輸入confirm就修改完成嚕
接著一樣點到第三個個選項，選到Access Control List，看到Access for bucket owner這個選項的Canonical ID，選項都全部打勾之後再來調整，這樣之後的 HTML 檔案外面就看得到了。
接著上傳一個index.html的檔案來測試
<html>
<h1>Hello world</h1>
</html>
上傳後下拉式選單選擇public read的選項，因為一個檔案在 S3 就算是一個 Object，所以一定要讓它能對外，然後按下左下的 Upload
成功後點進這個檔案，並按下方的Object URL，看到 Hello World 的話就代表成功囉，這時可以開個無痕測一次，確認一下沒有錯誤 😃
那因為現任公司的服務都是基於 AWS，如此這般我就接觸到 Serverless(以下簡稱 sls) 這個框架啦 (想更深入了解 FaaS 架構可以參考 AWS)
Serverless 架構是一個基於 FaaS(Function as a Service) 實作的一個服務，讓開發者可以更專注在開發功能，將 yml 檔設定好其餘維運的問題都交給 AWS、Google、Azure 這些服務商去處理，只要把信用卡準備好就好(?)，讓開發者在寫完程式之後不用煩惱部署得問題，減少的不少的麻煩事。
以用一個 Ruby on Rails 寫的機器人為例，在寫完個 webhook function 後，設定路由然後部署，一般主機或是虛擬機就很麻煩，要安裝佈署環境以及一安裝堆相關套件，完了之後設定 Domain 什麼的有夠花時間。但若是使用 heroku 部署就很方便，Login-Create-Deploy 馬上就結束，機器人馬上就上線了，實在是俗又大碗呀～
但我覺得像是 LINE Message 這種 stateless 的服務，且只要一個 function + route 就能實作的程式最適合 Serverless 了，讓專案可以簡潔有力，只要寫一個 function+yml 設定並打個指令就部署了，而且 domain 還附贈 SSL，將服務交給 AWS 也不需要擔心，整個就是超級方便啊！
serverless.yaml 是該專案的設定檔，可以把它想像成是 CloudFormation 的 wrapper，事實上也的確是這樣，serverless 背後會把他轉成 CloudFormation 的 template 去發佈。這個設定檔是 serverless 的精髓所在，一切有關 API Gateway 和 Lambda 的設定都在這邊，而底層所需要的資源，他都幫你配置好了，不需要操心。 ref
依照我目前使用的結果下來，在 heroku 以及 AWS Lambda 同時睡著的情況下，AWS 起床的回應速度大概 1 秒左右，而 heroku 則大概落在 10~15 秒(參考)。
如下圖所示的免費方案，基本上開發階段應該是不至於到 100 萬/月 個請求吧 ?，所以這部分就別擔新大力地給他用下去!
serverless.yaml 的設定參考 serverless.yaml 的變數傳遞
接下來會是使用 Serverless 這個框架去實作的，使用的語言為 Python，至於為什麼會選它呢，最主要原因還是在官網上有很多 plugin 可以用 ( NodeJS & Python )，開發時資源相對多，接著是 AWS Lambda 的 Code-start 最快的就屬於 NodeJS & Python 了，而我原本就是寫 Ruby 來的，自然就選一個寫法相近的語言啦(好像有點牽強)，如果說你想了解 runtimes 相關的問題的話可以參考這篇。