[心得] 實務經驗分享-AWS Lambda & RDS 整合探討
https://youtu.be/NRpLW8QIe5o
這是個互動式的系列教學影片,每個主題將會分成兩部分:
1. 第一部分會跟大家呈現實務上遇到的問題,讓大家一起討論並思考可行的解決方案。
2. 第二部分會跟大家分享當初我選擇的解決方案,可能不是最佳解,但相信也能促進大家不同面向的思考!
這次要來探討的架構圖:
https://imgur.com/yxL4w38
之前工作上為了處理批次作業,且想要盡量減少server維運成本,而有了這次的架構。
但實作之後,發現了一些當初沒有預想到的問題。
我還滿珍惜這些實務上的經驗,就是遇到這些意外狀況,
讓我有機會去思考多種解決方案,這樣的過程都非常有趣。
這次想透過這樣的互動形式,讓大家一起討論看看如果是你/妳會建議怎麼解決!
--
省成本的話不考慮跳gcp?
精美的serverless插入record進資料庫 還沒實作就知道會出
問題 這帳單應該會很精彩
可以講簡單點嗎?還要別人查專有名詞以及了解你的原理
不是複雜就顯得很有學問,批次作業被改善的方式可以
google,不要讓人家以為讀台大的就是待待,謝謝。。。。
某樓看不懂不要看?
去年底發表的RDS Database proxy好像就是要解這個問題
當然多用一層aws服務就是$$$ 不然就自己實作connection pool
更大調整就是就是視data性質與use case不用RDS改DynamoDB
好提議,RDS Proxy看來真的是針對這類架構的官方方案之一 "A surge of connections or a large number of open connections could strain your database server, leading to slower queries and limited application scalability. By pooling and sharing already established database connections, RDS Proxy allows you to efficiently scale to many more connections from your serverless application." documentation:
https://aws.amazon.com/tw/rds/proxy/(still in preview 2020.02.19) a clear overview of this solution:
https://imgur.com/9iyXZzC
batch就做成batch呀..你用S3trigger是async<>bacth
如果你只是要serverless且先不考慮scalable
schedule event->lambda->foreach(listobj)->moveToBK
你等著,我來研究,小弟不才,說話多有得罪抱歉!
可以解釋為什麼要用AMS的嗎?用雲端的比較省成本嗎?
用硬體的sever連接資料庫比較貴嗎?
你的最大連線數為什麼要設成5個 ,10個不行嗎?
應該要有個成本比較分析表,把虛擬的實體的算進去...
批次檔案的上傳個數 不能做時間限制嗎?比如分成兩三次
謝謝影片的教學跟分享,感謝大大!
alan3100大大,->foreach(listobj)->moveToBK能解釋嗎
都是Amazon的service,可混和Amazon跟其他廠商或自寫嗎
架構不大改,我會在中間加一層SQS
看資料型態,會考慮用DynamoDB取代RDS.
樓上接SQS也是一個很好的方式。原PO這範例式設計問題很
多,db con, vpc ip,db io, lambda concurrent..每個都
要講一小段,懶得打那麼多。另外DB的選用是只要OLTP且要
salable再考慮dynamo,不然再上去的設計規模你會做到死
Dynamo的成本是unbounded , 而且schemaless , 有duplicate
就精彩了. access pattern也未知,詳細的設計還是要看需求
是什麼,沒有需求之前都是做好玩的
意思是不同資料庫類型嗎?現在有關聯式跟NoSQL資料庫
8
你把 scalable service 跟 unscalable service 混在一起,所以才會煩惱疊了 那麼多東西是不是怪怪的。 一般系統設計上的邏輯是,scalable service 接到 unscalable service 需要用 queue 做緩衝,在 AWS 上面比較常見的是 SQS (MQ 服務與 Kafka 服務依照情況 也可以考慮)。1
serverless 的開發只有在處理很簡單的事情時會簡單 (好繞口),開發稍大一點的 應用時用 monolith application 的開發方式會簡單很多。 (再更大會拆,不過那是另外一個階段) : → gg142000: 也不用特別去維護server 02/21 09:37 如果團隊沒有人可以弄底層架構,你應該用 Heroku 這類平台趕快把產品寫出來,
64
Re: [請益]高流量網站和資料結構首先很高興看到原PO發問 能夠這樣追逐更深入的技術,先恭喜你,離高手又更近一步了 我寫程式要飯也好一陣子了,分享一下我從聽說大流量很屌,想玩大流量, 到現在可以真正碰觸到大流量一路的心得 在開始之前,先回應原PO的 搶票網站 例子16
Re: [請益]高流量網站和資料結構這是常用場景,已知問題,所以有很多解決方案。 其中一種就是類似Twtiiter的Push架構,每次新增一個員工就把資料寫進cache&DB 然後API打進來先去問cache要資料,然後cache多設幾個組成一個cluster, 避免單點失效...這些知識都可以從下面推薦的網站中學到,不用做過也略知一二 : 還是說這可能跟資料結構比較無關,我要去補充其他知識才會知道16
[火影] 終極風暴新商標《終極風暴CONNECTIONS》火影忍者終極風暴系列新商標《火影忍者終極風暴CONNECTIONS》 萬代南夢宮於2022年11月14日申請註冊 應該是遊戲新作 會不會是做慕留人傳的部份?7
[心得] 一個月取得Udacity雲端架構師證書不久前Udacity推出了任選Nanodegree第一個月免費的優惠, 筆者趁這次活動選讀了AWS Cloud Architect Nanodegree, 並且在一個月內完成專案拿到證書,在此跟大家分享心得。 網頁好讀板 這幾年雲端運算蓬勃發展(如AWS, Azure, GCP),7
Re: [請益] 免費仔想自己架站該如何把成本降到最低一個AWS based的方案給你參考 我沒用過Azure,但應該都有對應的服務可以用 後端 API Gateway + Lambda 前端 S3 serve static website + Route 53 Custom Domain,講究點可以再接CloudFront(CDN) 都是滿基本也滿popular的service,官方教學很完整應該沒啥難度4
[情報] 12/04 Daily HoroscopeCapricorn horoscope for Dec 04 2021 當你有重要的事要做, 擁有一個位居高處的朋友會非常有幫助。 作為一個精明的魔魔, 你知道建立好連結與網絡的價值,1
[情報] 21/12/2020 Daily HoroscopeYou aren't someone who likes to rely on "connections" to get ahead. You are a very independent person, Cancer, and you like to rely on yourself. You only seek out others when there is no other way. But don't let that stop you from making an intriguing connection today. No, you don't absolutely need someone to make a success out of a current endeavor. But