前言

在以前開發 LINE Bot 的過程中，我們常常面臨一個問題：用戶輸入的文字千變萬化，可能包含錯字、口語化表達等。這使得我們需要設計非常複雜的判斷邏輯，才能確保 Bot 能正確地辨識並回應用戶的輸入。這不僅需要投入大量時間和精力，還需要不斷調整和維護這些判斷規則。這種方式不僅效率低下，而且容易出現錯誤。

• 前言
• LINE Bot & Gemini Pro 設定細節請參考: 旅行小幫手 LINE Bot 文章
  • 事前準備
  • 關於 Gemini API Price
  • 流程圖
• 介紹
  • 試題：範例為列出五個項目，修改 prompt 找出群組的大家最近關注的事項
• 增加天氣 Open Data 功能
• 衛星雲圖 - 是否有雲層
• 活動小結

前言

此篇文章為延續與政治大學 & 臺北大學 GDSC 工作坊的文章，如果對於整合 LINE 官方帳號的相關資訊，可以參考本篇喔！

前言

這兩天在寫之後工作坊需要用到的範例 linebot-gemini-summarize，結果遇到部屬上去有問題，以下快速筆記這次遇到的一些蠢事，往後需要更細心點才行🤣

背景介紹

過年改寫了我自己的在台北常使用的路上攝影機截圖工具，一開始求方便在每次請求來時會在容器當中開啟 chrome 去截圖，但由於是 MVP 以及沒有放 queue 在前面讓請求排隊，因此這樣的做法就無法提供給別人使用。

因此為了可用性，需要把截圖功能透過排程(cronjob)去實作，所以這次就將截圖功能改搬到 Cloud Function 並搭配 Cloud Scheduler 排程抓取。

前言

此篇文章為 2023/12/09 DevFest Taichung Serverless workshop 步驟文章，如果有需要透過 GCP Pub/Sub 將訊息轉打給訂閱的 Cloud Run endpoint，可以參考看看這篇文章喔！

前言

大家好，我是 LINE Taiwan 的技術傳教士 Nijia (a.k.a 忍者)，這次很榮幸可以來 COSCUP 2023 分享業餘時間作 Side project 的一些心得，這次透過文章跟大家分享經驗談！

簡報：https://speakerdeck.com/line_developers_tw/how-to-develop-side-project-to-public-cloud

為什麼要使用 Knative(KN)

Knative 是一個開源的 Kubernetes 原生 Serverless 平台，它使開發者更容易地建立、佈署和管理應用程式。而 Knative 的好處它提供了統一的方法來佈署和管理基於事件驅動的服務，這使得開發者可以專注於賺寫應用程式，而不必擔心基礎設施的細節。

冷啟動(Cold start) & Cloud Run 如何處理？

Serverless 架構的冷啟動（cold start）是指當一個沒有被使用的函式需要被調用時，需要先啟動一個新的容器或虛擬機器來執行該函式，這個啟動的期間被稱為冷啟動時間。

但我們在寫應用的時候通常都會帶有一些 cronjob 在背景跑(備份、爬蟲...)，但在 Serverless 上都會遇到 Cold Start 的問題，在這種情況下因為資源都會被釋放掉，如果這些 cronjob 是比較重的且 Severless RAM&CPU 又放比較少， cronjob 時邊爬蟲邊異地備份又讀寫資料庫(~~ 誇張了點 ~~)，這情況下可能會因為資源瞬間不夠導致功能異常。

前言

近年來，隨著雲端計算的普及和發展，越來越多的企業和開發者正在尋找一種更簡單、更高效的方式來佈署和運營應用程式。而 Severless 技術正是一種流行的解決方案。Google Cloud Run 是一個強大的 Severless 平台，可以幫助開發人員快速地佈署和運營。接著，本文將介紹 Google Cloud Run 的優點和如何在其中佈署。

前言

從以前使用雲端硬碟，如 Dropbox, Google Drive, Box...我們都很習慣可以手動拉照片、影片上去放，而在開始寫程式之後理所當然就會想用 API 丟，但這些雲端硬碟一般來說除非用模擬器，不然理論上應該是不好用程式跑，而在公有雲出來後，就有像是 AWS S3, Google Cloud Storage 等等的服務陸續出來，讓大家可以使用他們的服務建立自己的硬碟空間，也不用自己架伺服器弄硬碟空間，權限管控都幫你弄好好，也可以用 API 訪問，實在是很方便呢！

隨著程式越寫越多，除了在 LINE Bot 上需要圖片網址才可以發送圖片外，像是 video.js 以及許多很多服務、工具越來越依靠　 https 相關的網址來找圖片，接下來就讓筆者就帶大家認識一下近期使用的一些範例以及我發現的另一種上傳方法。

前言

上次參加外部活動時大概是四月多了，因為疫情關係讓這幾個月沒辦法參加實體活動，這次參加了 Google I/O 2022 extended 的線下活動，透過這次文章快速記下一些現場有聽到的內容～

活動連結：https://gdg.community.dev/events/details/google-gdg-cloud-taipei-presents-gdgcloud-taipei-meetup-io-2022-extended-cloud-edition/

為什麼寫這篇

• 失誤把 private key 推到 GitHub 上
  • 明明有加到 .gitignore 中
  • 但在剛建立 .git 時就一起 add 進去導致 key 都上去了
• 想要同一份 git 推到不同的 git 倉庫上(ex. GitHub + Heroku)
  • GitHub 不放 key
  • Heroku 需要 key 去訪問服務
  • 存檔案在 Heroku 中休眠後會移除，因此要動態寫在記憶體中

本次範例專案: https://github.com/louis70109/Python-import-env-json-string

前言

原因是這樣的，我在去年 12/13 參加了 GDG 週年 Hackathon Party，當時主辦社群很有心的提供 GCP Credit 半年份，雖然當時我是 AWS 派系但我還是很開心的使用它，但我就在這幾天收到了一筆兩千塊的帳單，造就了這篇文章分享...😭

前言

之前鐵人賽寫了一篇文章有提到 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。

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 的模型，這些模組的載入時間會增加冷啟動期間的延遲時間。您可以透過以下方式縮短啟動延遲時間：

• 儘可能減少相依元件的數量和大小以建置精簡的服務。
• 只有在必要時才載入不常用的程式碼 (如果您使用的語言支援)。
• 使用程式碼載入的最佳化，例如 PHP 的 composer 自動載入器最佳化。

畢竟在載入模組的時候相依套件也是要一起抓進來，若是程式本身太多依賴的話也是會導致 cold start 的時間變長哦！

最後就在幫大家整理一下三大平台的 warm-up 資源：

• warm-up
• Google App Engine warm up
• Google Schedule
• Scheduling with Azure Functions

結論

為什麼要有 cold start 的機制，以供應商的角度來說他們可以提供一定的量讓使用者免費在平台上先建置服務，但若要免費就是服務會被暫時暫停，畢竟現在流量就是錢嗎 💰，像我常用的 Heroku 就會是這樣，而當你流量大的時候就看你要不要搬家，不過一般應該都懶得搬，就會形成所謂的養、套、殺🤣(離題)。

總而言之，若是需要服務時常活著，就是需要付出點流量的錢 💰，也或許你的作品服務時間可能不用那麼長，只要在服勤時間內長駐活著就可以在省下一些費用，如果有需要的話還是付一些錢給供應商，畢竟人家也幫你保管了服務你說是不是？

參考

• On the Serverless cold start problem
• Lambda Warm-up
• Heroku cold start
• serverless 啟動流程
• Function Chain 來源
• cloud run cold start