※ 引述《uopsdod (pcman)》之銘言： : https://youtu.be/NRpLW8QIe5o : 這是個互動式的系列教學影片，每個主題將會分成兩部分： : 1. 第一部分會跟大家呈現實務上遇到的問題，讓大家一起討論並思考可行的解決方案。 : 2. 第二部分會跟大家分享當初我選擇的解決方案，可能不是最佳解，但相信也能促進大 : 家不同面向的思考！ : 這次要來探討的架構圖： : https://imgur.com/yxL4w38 : 之前工作上為了處理批次作業，且想要盡量減少server維運成本，而有了這次的架構。 : 但實作之後，發現了一些當初沒有預想到的問題。 : 我還滿珍惜這些實務上的經驗，就是遇到這些意外狀況， : 讓我有機會去思考多種解決方案，這樣的過程都非常有趣。 : 這次想透過這樣的互動形式，讓大家一起討論看看如果是你/妳會建議怎麼解決！ 你把 scalable service 跟 unscalable service 混在一起，所以才會煩惱疊了 那麼多東西是不是怪怪的。 一般系統設計上的邏輯是，scalable service 接到 unscalable service 需要用 queue 做緩衝，在 AWS 上面比較常見的是 SQS (MQ 服務與 Kafka 服務依照情況 也可以考慮)。 全部都是 scalable service 就不太會有你提到的問題： S3 -> Lambda -> DynamoDB (w/ auto scaling) 如果最後面一定是 RDS，那麼可以這樣疊： S3 -> SNS -> SQS -> EC2 instances (workers) -> RDS 跑固定數量的 worker 就不怕 RDS 的連線數量被撐爆，反正慢慢消化，原文的推 文裡面好像有人提過了。 (我之前貼在這邊的成本公式是錯的，我深夜邊弄東西邊算把 RAM-GB 的部份多乘 了 60，原文我放到 Web Archive 上的 https://bit.ly/2vQ117p 這邊，錯的部 份我這邊刪掉了) 開發的人只要透過 loop 去吃 SQS 的內容，不需要在 serverless 受限環境裡開 發，還有 swap 可以惡搞讓你可以平行跑更多的 worker。 量很大的時候還可以看情況挑 c5/m5/r5 的機器搭配 auto scaling 機制把 spot instance 與一般機器混在一起用... 補一下我對 Lambda 的想法。現在這個階段用 Lambda 其實不是很划算： * 開發成本因為需要考慮 serverless 的關係偏高，工程師是稀缺資源，爽爽 無腦寫標準的 loop 搭配 systemd 的 Restart 參數其實就可以解決很多問 題。 * 量少的時候，如果你老闆會很在意 $6.768/month 跟 $0.x/month 的差異， 也許要考慮快跑啊... 目前 Lambda 比較合理的情境應該是 CloudFront 上的 Lambda@Edge，這可以在全 世界的 CloudFront 節點上執行，有反應時間上的優勢，其他的目前還沒看到... 總之，我覺得現階段用 Lambda 常常是個損人不利己的決策... -- Resistance is futile. https://blog.gslin.org/ & <[email protected]> --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.104.21 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1582226963.A.9D0.html ※ 編輯: DarkKiller (122.116.104.21 臺灣), 02/21/2020 11:36:15 ※ 編輯: DarkKiller (122.116.104.21 臺灣), 02/21/2020 11:36:47 ※ 編輯: DarkKiller (122.116.104.21 臺灣), 02/21/2020 13:06:30