※ 引述《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 常常是个损人不利己的决策...