给昂贵的云降降本

[cesign]

云 K8s 太贵，来看看用 Karpenter 给其降本一下： https://mp.weixin.qq.com/s/1QANbWZ6Sx7HGzez74rGRw

结合我的实践，大概能降60%左右！

[goodryb]

看起来非常棒的实践，期待早日能支持国内云厂商

[Frankcox]

这个是 aws 的节点弹性扩缩的那个服务吧？

[ounxnpz]

你这个降本不是机型选择带来的，而是 Spot 带来的。对于无状态横向扩缩容，AutoS + Spot 和你这个成本不会差太多。对于很多有状态的，相当一部分不会考虑 Spot 。

总之，相比 AutoS ，有优势但非必须。

[cesign]

@bluicezhen
1.AutoS 没办法选择多种规格的机型(可以配置，但是管理难度会大增)，碎片化程度会更高，浪费资源更多。进而导致成本更高。
2.AutoS 没办法处理 Spot 的异常中断，稳定性会下降很多。
3.文章提到 OD+spot 混合部署，AutoS 没办法做到（要么全 OD ，要么全 SPOT ），如果只有 Spot 稳定性会受影响。
4.有状态服务看底层数据怎么维护的，比如通过多实例主备+NFS ，spot 完全能够 cover 。

[salmon5]

花里胡哨的，没参考价值。一个 AWS RI 就搞定的事情。

[salmon5]

一下子降了 60%，之前用的该有多浪费。ECS 不应该 RI 买起来吗？本来买了 RI 就是 3.5-4 折。

[cesign]

@bluicezhen
5.还有一点是弹性速度，AutoS 弹性一个节点我记得要 1m30 左右，karnepnter 只要 40s 左右

[salmon5]

降本本来就是一件持续的事情，需要花费大量的时间，如果一次降得越多，这个负责人风险其实挺大的，说明之前没有关注过成本，一直在浪费的使用。
这是站在老板的角度，当然老板也是专业的。
合理的降本应该是持续的、没有投入太多技术风险，朴实无华的。

[cesign]

@salmon5

> 花里胡哨的，没参考价值。一个 AWS RI 就搞定的事情。

表示怀疑，以 m5.xlarge 为例(us-east-2)，按需价格为$0.1920/hour ，RI 价格为$0.121/hour ，Spot 价格为 0.0588$/Hour,
简单的购买 RI 只是无脑做法，并不是最优做法。

而且 RI 有个缺陷是，如果我业务改革，导致机器没必要用这么多了，RI 的钱我还是要付（就算我把机器释放），绑定非常严重。

当然，如果有钱，随便造。

[cesign]

@salmon5 这个负责人风险其实挺大的

这个看阶段，增长期的公司，基本不咋关注成本，野蛮生长。

[cesign]

@Frankcox

> 这个是 aws 的节点弹性扩缩的那个服务吧？
指 managed node group 还是 cluster autoscaler? 和着两个区别挺大的。文章里面有描述

[sampeng]

小规模可以。大规模不行。每个行业有每个行业的业务特征。spot 要根据业务特征来定制，包括 spot 的定价都有很多团队基于这个东西来做程序。

其实吧，99%的公司云成本想下降很容易，别浪费就可以下降 50%以上。。看见太多集群 10%的利用率了。看见太多数据库上来就是一个 8c32G 的了。也看见太多不管三七二十一微服务几十个还不如一个单体跑 2-3 台机器。

[cesign]

@sampeng

> spot 要根据业务特征来定制

完全赞同，还是要识别一些东西。

> 看见太多集群 10%的利用率了。看见太多数据库上来就是一个 8c32G 的了。也看见太多不管三七二十一微服务几十个还不如一个单体跑 2-3 台机器

+++100 ，Karpenter 也有根据资源，自动替换更小节点的能力。

[sampeng]

楼主的回答只考虑有利于自己的一方。。。这没法聊。。我也能反过来反驳

1.AutoS 没办法选择多种规格的机型(可以配置，但是管理难度会大增)。没明白管理难度为何会大增。一般业务的特征是固定的，配好了基本就不动了。哪来的管理难度？再不济弄个 terraform 来创建，就是一个数组的事。
2.处理 Spot 的异常中断是业务要做的事，不是 autoS 做的事。
3.我就不能建 N 个 AuotoS ？谁规定 k8s 集群只能有一个 AutoS
4.有状态的含义是要有磁盘，NFS 那点 IOPS 能干啥？ nfs 里面跑个数据库看看？跑个 rabbitmq 看看？很多业务要求高 IO 。NFS 是共享网络存储，不是本地存储。还多实例主备，你知道复杂度会爆炸么？本来只要挂个硬盘进去就可以了。结果因为要降成本，所以不能有状态？怕是会被研发砍死。


下面有人提 RI 你也能反驳。。。谁说 RI 是最无脑的。最无脑的是三年全付的 savings plans 。如果你一年有 400 万人民币以上再谈一个年包大概在 10 个点左右。

[sampeng]

@cesign 这个我好像是试用过。。我自己 1 天就能搞定的事硬是被套进来一系列的概念。要精细化运维，最好的方式是自己做。缺什么工具做什么。。这种所谓的大一统的工具，用不了。。用不了。。。关键还要大量的团队学习成本。本来只要会 k8s 。我什么大家都知道，结果用了一个非主流的工具。活都成我的了

[cesign]

> 楼主的回答只考虑有利于自己的一方。。。这没法聊。。我也能反过来反驳

当然，根据我们的业务场景，这解决方案也有局限性。

关于第 2 点：spot 中断后，正在处理的请求会失败，需要一个机制去提前驱逐节点。这个 autoS 是肯定没有的
关于第 4 点：确实没考虑到。

RI 在我们场景下，并不能省多少，还有很强的绑定，后续我没用这么多资源了，也要求付钱。

[naoying]

弹性最大的问题是，云厂商没机器就很炸裂了。Karpenter 根据资源自动切换小节点很赞

[hwcloudnative]

@sampeng 我有个问题啊，云的优势本身就是弹性，大晚上没流量的时候，这些空闲机器按道理应该是要关掉的，这种情况下买了 RI 不就是白白浪费钱吗？不就是把公有云当成物理机房在用吗？公有云的成本可比物理机贵太多了

还有个问题，美国有家公司 ticketmaster ，做在线电影票业务的，疫情前跟 AWS 签了三年的 RI ，结果疫情来了，电影院全部关停，业务量一下腰斩，整个公司的收入还不够付 RI 的钱，还不能毁约，这种突发情况不能说完全能避免吧？

RI 存在肯定有他的价值，但是作为公有云长期使用者，我不建议上来就买 RI ，看似简单申请，实际上被云厂商套进去了，云的价值就是弹性伸缩，RI 或者包年包月本质上就是把云当成物理机器在用啊。。。

还有就是心态问题，大家都是打工的，当然是越少折腾越好，而且公司花多少钱跟我有啥关系，个人开发者当然应该更加关注每一分钱成本，这年头经济这么差，老板们心态都变了很多，如果 infra 工程师不能证明自己的价值，被裁是迟早的事情，我觉得 po 主的文章挺好的，把成本优化的经验分享给大家

[fredcc]

@cesign
1 、看业务需求了，有不同的场景自然可以用不同的规格实例建节点组
2 、spot 实例的中断管理本来也不应该 asg 管啊
3 、同 1 ，有需求可以按需和 spot 混合使用，ec2 时代就可以的事情 eks 不能做么
4 、有状态服务用不用 spot 看怎么衡量业务稳定性运维成本和云计算成本了

[perfectlife]

@goodryb 国内直接就支持啊，阿里云的 axk 好早就支持抢占实例作为 ack 节点，还支持节点被释放前自动拉起一个新抢占实例补上，抢占实例池没资源还能申请按量付费的。

[perfectlife]

@perfectlife ack

[salmon5]

这个场景是跨境电商场景，是业务最简单的场景，可以 spot 搞来搞去，复杂的业务场景，这样 spot 搞来搞去，直接被 KO 了。
技术都是相对简单的，业务才是最费劲的。

[salmon5]

RI 、SP 确实用起来很糟糕，这也是用 AWS 无奈之举。

[salmon5]

所以我一向不主张用 AWS ，挣美元、发（工资）美元的公司，才适合用 AWS 。
国内的云阿里云也有 alibabacloud.com ，对比 AWS ，你这个根本不需要优化成本。

[salmon5]

人民币换成美元，用 AWS ，那肯定是相当不划算的。

[sampeng]

除非费用特别高。。我个人不太倾向业务在 spot 上跑。不管你感知多牛逼。AWS 免责说的明明白白，尽可能通知你，但有可能不通知你，自己负责。不过 spot 的回收率我根 BD 聊，大概 93%以上是没触发过回收。我实际在阿里云用也差不多，半年回收一次。所以策略自己搞个脚本其实很容易。不过吧，因为整体费用并不高，投入人力物力实在是不划算。维护成本也是成本。本来 2 个人就搞完的，因为又要高大上又要省钱，很容易一顿操作猛如虎，一看就省 2 毛五。


@hwcloudnative

第一个问题，这是一个综合成本考虑。买 RI 也没人逼着你全买 RI 啊。RI+Savings plans 是一个比较好的组合。RI 负责 24 小时都要开机的常驻机器。Savings plans 负责每小时的最小用量不限定机器类型。我一般组合着错开买，RI 的折扣力度大，SavingsPlans 折扣力度小但是非常灵活，而且支持 fargate 。

而且还要分业务和环境。我做过两种方案，第一种方案呢，开发测试环境白天开 spot ，晚上关机。第二种方案就是直接 RI 覆盖 50%。晚上自动把多余的机器关了，再自动根据流量伸缩一些 spot 机器出来临时用用。看着是前者省钱了，但是一顿操作猛如虎，一看就省 2 毛五。总得招个人来干吧，总得有第二个人维护和懂吧。第二个方案反而是本来就省钱了，多少而已，但是整体维护成本极低。

现在 fargate 其实是个不错的节省成本方案，如果无状态的，临时调度的扔 fargate 里面，跑完就关了。比开机器舒服多了。比如 CI/CD 。以前总是要一个一直在的集群，还有大小限制，死鬼死鬼。现在有 fargate/ask 的加持，就开一个宿主机跑调度就好了。其他都是 eci 。以前 github 跑 runner 要小 3000 美金一个月。现在。。3000 人民币就够了。

[tabliu]

最妥还是 RI 和购买 saving plan ，spot 不可预测风险和运维成本很高的，遇到过一个 region 突然回收几百台 spot 机器的，如果没有预先购买 RI 和 SP 用 OD 代替跑几天成本就哭死。购买 SP ，怎么买，怎么知道云上 spot 的库存，回收率都是未知的。

[cesign]

@fredcc
> spot 实例的中断管理本来也不应该 asg 管啊

那什么来管 spot 上用例的稳定性呢？依靠应用不显示，毕竟正在处理的请求，中断后就丢失了

> eks 不能做么

当然可以，主要是细粒度的应用调度级别的控制

[cesign]

@sampeng

> 尽可能通知你，但有可能不通知你，自己负责。

还是看你怎么用，我们目前用下来，提前通知都受到了。没有遗失的。

> 而且还要分业务和环境。我做过两种方案，第一种方案呢，开发测试环境白天开 spot ，晚上关机。第二种方案就是直接 RI 覆盖 50%。晚上自动把多余的机器关了，再自动根据流量伸缩一些 spot 机器出来临时用用。看着是前者省钱了，但是一顿操作猛如虎，一看就省 2 毛五。

算算，假设 100 台 m5.xlarge ，弹性的为 50 台
所以第二方案的成本为：(50*0.121+50*0.0588)*1 个月=6562.7$
第一方案成本：(50*0.121+50*0.0588)*1 个月=4292.4$

所以 1 年 2w$属于 2 毛 5 的范畴？如果识别出来业务适合 spot ，为啥不用？


> 现在 fargate 其实是个不错的节省成本方案，如果无状态的，临时调度的扔 fargate 里面，跑完就关了。比开机器舒服多了。

给你看看 farget 成本：以一个程序(2Core/2GiB)运行一小时为例：
EKS Fargate=0.0896$
EKS/EC2=0.077$，使用 c5a.large(2Core/4GiB)，还有 2GiB 的剩余

如果有一种手段既能享受到 farget 弹性，还能稳定使用 spot ，为啥不用？

[cesign]

@sampeng
而且我不觉得你方案一和方案二维护成本差多少，接近一样。都需要更具 AWS 的 spot 通知，迁移 spot 节点的业务

[cesign]

@tabliu

> 遇到过一个 region 突然回收几百台 spot 机器的，如果没有预先购买 RI 和 SP 用 OD 代替跑几天成本就哭死

确实是这样的。不过拉长时间看，比如 3 个月，大部分时间还是 spot 在跑，少部分时间使用 od 在跑

[cesign]

@perfectlife

> 国内直接就支持啊，阿里云的 axk 好早就支持抢占实例作为 ack 节点，还支持节点被释放前自动拉起一个新抢占实例补上，抢占实例池没资源还能申请按量付费的

知识盲区，感谢提醒，这个很有用。

[ytmsdy]

生产环境往 spot 上部署，这个对运维的要求太高了。大部分人估计都不敢这么干。

[cesign]

@ytmsdy 当然，逐步来，我们也是搞了好久。

[gkuchan]

04 部分，和纯 Serverless 的比较我觉得不够全面。大多数应用的纯运算时间都很少，更想了解一下如果采用纯 Serverless 架构，价格上会差多少。

[bthulu]

可以先上云降低成本, 再下云降低成本, 再次上云降低成本, 再次下云降低成本, 多来几次, 就没有成本了.

[br9852000]

业务高峰期节点迁移导致的业务损失估计比你省的钱要多吧。尤其是广告投放

[cesign]

@br9852000 看业务类型，我们这种业务加上 od+spot 混合调度，没有端服过。

[sampeng]

@cesign

运维很多事情不光是技术层面，还有很多其他要考虑的。
spot 回收哪怕你 3 年没出问题，出一次问题。就是一个锅。
甚至说锅这个东西因人而异。大部分公司，线上是一点问题都别出的。出了就要扯皮。哪怕没业务损失。
那么问题来了，为啥要去踩这个雷呢。很多领导，你要是跟他说 0.00001%的概率可能会业务出故障或者订单丢失，逻辑丢失，数据丢失之类的。。很多领导直接就会否了方案。

前面你说的第一和第二没有维护成本区别：一个是要做一个程序去控制，如果 spot 回收还要想办法加回来。这个程序要不要维护？有 bug 怎么办？ api 升级了怎么办？集群升级了怎么办？是不是都是运维管理成本？第二种，哪有什么成本，年初买个 RI ，云平台设置一下定时关机。几年都不用去管他。甚至忘了的存在。

fargate 就不是这么节省成本的，你这个算法就跟我入现在这个公司发现所有服务都跑在 eci 上一样。fargate 哪能这么用，fargate 不能当长期服务用的，贵死人。他的定位是毫秒级可以分配 pod 。秒级拉起新 pod 。应对流量的高低变化。比如白天我就要 2 台常驻的就够了。晚上随着 cpu 的水位自动增加到 10 台。然后某些核心业务服务群用 fargate 自动横向伸缩，比如最高峰要从 2 个 pod 调度出 20-30 个 pod 。fargate 瞬间就能拉起来。这个高峰最多半个小时。缩回去就没成本了。这才是 fargate 的核心使用场景。而且 aws 的 fargate 不清楚有没有 spot 类型。阿里云的 eci 都有 spot 类型。你拿普通的机器 spot 当宿主机打死都不可能比我就运行 1 个小时就出 1 个小时的钱便宜（正常价格的 1/24 ，spot 顶天了 1/10 ，为了稳定可能是 50%上下的定价范围）。

[cesign]

@sampeng

> spot 回收哪怕你 3 年没出问题，出一次问题。就是一个锅。

K8s 节点都有挂的可能性，照你这么说，用啥 K8s ，用回物理机算了，spot 确实会回收，但是做好回收后的业务连续性问题（提前回滚）就行。

就算是 on-demand ec2 的可用性保证也只有 99.99%，那按你意思，用啥用。

> 一个是要做一个程序去控制，如果 spot 回收还要想办法加回来。这个程序要不要维护？有 bug 怎么办？ api 升级了怎么办？集群升级了怎么办？是不是都是运维管理成本？第二种，哪有什么成本，年初买个 RI ，云平台设置一下定时关机。几年都不用去管他。甚至忘了的存在。

这个程序就是相关产品的价值。RI 没有弹性，我阐述好多遍了，白天要 100U ，晚上 10U ，我得买 100U RI 的钱，那如果我买 10U RI ，90U 的 OD ，这难道不贵吗？




> fargate 就不是这么节省成本的，你这个算法就跟我入现在这个公司发现所有服务都跑在 eci 上一样。fargate 哪能这么用，

那你知不知到有相关 eks+ec2 的解决方案，也可以做极致弹性，有 pod 就扩，没 Pod 就缩，这个和 farget 体验是一样的，而且还便宜。谁跟你说 eks+ec2 不能做到类似 farget 的极致弹性。

[sampeng]

@cesign 第一个点：spot 最大问题是有可能不通知回收机器，最常见的是 60 秒前才通知。普通伸缩是可以优雅关机优雅降级。spot 就是看 aws 通知了，还是那个点，业务要能忍受和鲁棒。如果全靠通知自动伸缩，锅从天上来。

fargate 相信你没用过，所以你才说和 ec2 一个体验。第一，ec2 的 as 有延迟，默认时间是 300s 。可以改，但有问题，他缩回去也有延迟，也可以改。我一开始也用过这个方案，但是 k8s 的 as 的逻辑极其诡异，很容易一会弹出 10 个机器，一会全缩完了。来回蹦跶。如果是 java 业务就更蛋疼了，在默认情况下，如果集群很大，在刚起来的时候所有 pod 的 cpu 巨高，就会弹出一堆机器。然后缩回去的时候又集群平衡。pod 一直处于不稳定状态，需要几分钟的稳定时间。所有值都需要经验去增加 buf 时间，我们高峰期就十分钟，你扛不住今天就损失几十万…

[sampeng]

哦，补充一句，你一直计算 spot 都是按最低计算的。这样的机器也是要看库存的。拿最低的 spot 申请的机器容易被回收。然后申请不到新的请问阁下如何应对…
一半拿 spot 做一定业务机，顶天了按 50%的折扣也就是 ri 的折扣水平去申请，而且要为没有机器做好准备的一些防御措施。因为…我就碰到过好几次 spot 不给我机器了，还是在高峰期。我当场脑子就炸了，后来一看哦，是开发测试环境，那没事了。

[cesign]

@sampeng

> spot 最大问题是有可能不通知回收机器，最常见的是 60 秒前才通知

是你瞎猜的还是什么？
近期 2 个月，我们这边会记录中断数据，数百个节点，通知都是>=2min, 有的甚至能到 5min(rebalance recommendation)。

如果一个业务的 grace termination seconds < 1min ，并且没有严苛的 PDB ，完全能优雅关闭。

而且谁让一个业务只用 spot ，10%部分调度到 od,50%部分调度到 spot 不行吗，就算 spot 中断也有兜底（如客户端重试）。


> 所以你才说和 ec2 一个体验。第一，ec2 的 as 有延迟，默认时间是 300s 。可以改，但有问题，他缩回去也有延迟，也可以改。我一开始也用过这个方案，但是 k8s 的 as 的逻辑极其诡异，很容易一会弹出 10 个机器，一会全缩完了。

谁跟你说用 as(如果指 asg)。我通过程序直接调用的 ec2 fleet 接口，，弹性速度是 40s 左右一个节点，如果结合预热(从 shutdown 的机器拉起)可以达到更短，虽然可能没有 fargate 那么快，但是应该非常接近。

对于 java 应用，弹机器是根据 pod request 弹的，不是 usage ，这点你似乎没明白。所以也就不会有“缩回去的时候又集群平衡，pod 一直处于不稳定状态” ，能不能专业点。

[sampeng]

哦。你刚说的有问题…谁说白天 100u ，晚上 10u 我就要买 100u 了。我就不能买 10u ，然后补个 saves plan 么？我就这一个集群啊？运维是一个系统工程，那 90u 可以在其他的成本里面均摊。通常我是直接一个 savesplan 的。也没浪费多少。楼上有小伙伴说的对，优化成本是一个动态变化的，如果白天 90u 是必须的，晚上不需要 90u ，我为啥机器一定要开着呢？弹性伸缩嘛。还有其他的集群均摊成本，各种不同业务特征均摊成本。


跟你掰扯半天就是因为看过这个东西，如果用一个东西你节省了 60%成本。要么本来是 1000 节省到 400 每月。这也是节省 60%。要么就是之前浪费太多了，集群平均利用率水位压根不达标。我见过不少集群常年利用率水位在 10%上下的，还美其名曰留空间。这种就是你稍微关注一下就是一大笔钱省下来。工具只是提高管理效率，用一个工具就省钱就是本末倒置了。是因为省钱我需要用某个功能，正巧这个工具可以帮我做到这个功能而不用我自己开发。而不是因为这个工具可以省 60%成本，所以我要用这个工具……

[cesign]

> 我就不能买 10u ，然后补个 saves plan 么

你知道 sp 的计费逻辑吗？ sp 是按小时承诺的。1 天 10 小时只有需要 10u ，那你这 sp 覆盖了啥，咋覆盖，只要 1 小时内没用超过 10u ，这个 sp 就是白白浪费的钱。他不是算你每天平均值去覆盖的。

> 要么就是之前浪费太多了，集群平均利用率水位压根不达标。

我承认之前浪费非常严重，

> 工具只是提高管理效率，用一个工具就省钱就是本末倒置了

首先，我没强推这个工具，友好交流。降本和提升利用率，本质是一个事物的一体两面。提升钱的利用率难道不是提升利用率吗？

[sampeng]

@cesign 继续和你掰扯，第一个，我自己碰到过突然机器没了没通知，或者一分钟内就会回收了。场景是大数据的 job 机。一天一分钟回收八百次得气死。。其实 k8s 的场景下 asg 已经解决了 spot 的优雅关机问题，他本来就是会自动平衡集群。收到事件后 asg 也会 callback 机器关闭调度。所有过程都非常优雅。唯独机器突然没了这种他自己都处理不了。其他场景 asg 足够了。所有间隔时间都可以调，你猜一个每天要赚钱的项目是相信云平台自己的还是一个不那么出名的开源项目？

第二个…按 pod request 啊。我猜你的意思是 hpa 的计算是按 pod request 计算的？不然自动伸缩自动伸缩，啥值会变呢？也只有 cpu 超过了我的阈值或者我需要按其他指标来扩容啊。没明白你说的按 pod request 咋扩容。不专业了。。我说的场景你没碰到过，没办法。野生运维。伸出来的时候所有 pod 刚启动都是 cpu100 。就一直加到最大值。等完事了发现太多了，又缩回去了。得，不够负载的，又加上起来。所谓集群再次重平衡是机器伸缩出来就涉及到 pod 会调度上来。也会有 node 的驱逐。这个过程又涉及到驱逐后的 pod 再次启动可能会挤到原先机器里面去。

k8 集群千奇百怪的…没有银弹

[sampeng]

@cesign 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。sp 是每小时承诺不假啊，但他覆盖所有的机型和 fagrate 。你猜我是不是业务集群在白天，晚上业务集群是不忙了但大数据集群是不是可以干活了呢？

[sampeng]

另外文章底下有这么一句：

Karpenter 开源版本目前只能根据 Pod 的资源 request ，负责节点的选择、创建和删除，未对业务稳定性做深入设计

你犟什么呢？我一直在说 spot 会有稳定性影响。虽然不致命。但要起命来最少我是承担不起这个责任。

[cesign]

@sampeng

> 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。sp 是每小时承诺不假啊，但他覆盖所有的机型和 fagrate 。你猜我是不是业务集群在白天，


你这场景没问题，那你为啥一定要否定我的解决方案呢？为啥一定要证明你的比我好呢？如果我不跑大数据呢？

而且大数据都是 job 类，大多数大数据 job 都有断点重续，跑 spot 完全没问题。


> 其实 k8s 的场景下 asg 已经解决了 spot 的优雅关机问题

我还是没懂你指 cluster autoscaler 还是 aws 的 autoscaling group 。


> 伸出来的时候所有 pod 刚启动都是 cpu100 。就一直加到最大值。等完事了发现太多了，又缩回去了。得，不够负载的，又加上起来。所谓集群再次重平衡是机器伸缩出来就涉及到 pod 会调度上来。


那你有没有想过这种场景不适合用 cpu 作为 HPA 的伸缩指标？这么用，按推理可能会一直扩容。

[cesign]

@sampeng

> 你犟什么呢？我一直在说 spot 会有稳定性影响。虽然不致命。但要起命来最少我是承担不起这个责任。


那不能想办法增强吗？懒得思考？

[cesign]

@sampeng

> 不那么出名的开源项目？

by the way ，AWS 开源的。