※ 引述《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 上的 [email protected]，這可以在全
世界的 CloudFront 節點上執行，有反應時間上的優勢，其他的目前還沒看到...
總之，我覺得現階段用 Lambda 常常是個損人不利己的決策...