AWS云服务踩坑记

Posted 2023-03-09 北亮bl

之前写过一篇阿里云的踩坑吐槽文：踩坑记：C#访问阿里云的API小结，阿里云的文档有待改善
最近2年开始使用AWS云服务，也记录一下跟阿里云不一样的踩坑历史吧。

---

1、AWS特有的CPU积分机制

这个机制没有认真的去研究，
比如CPU积分，大意就是 aws允许你超出标准，使用额外的CPU性能，但是这个超额时长是有限制的，这个限制，就是CPU积分机制：官网规则参考。
举个例子，你的程序特别耗CPU，但是你买的EC2的CPU达不到程序要求，那么你的程序在运行时，就会消耗积分，在积分消耗完毕后，你的程序就会被强制降频使用，从而导致程序出现卡顿或停止响应。
要注意的是，AWS不仅仅有CPU积分，还有流量积分等。
之前使用阿里云，并没有这个积分的概念，不过还不确定阿里云对程序超限时，是怎么处理的。

我被坑的经历：
新项目，在测试环境测试跑大任务（还不是压测，只是数据量大一些），经常出现mysql卡顿，正常的主键查询SQL都会出现耗时1秒的情况，关键还会上午正常，下午故障。
因为大部分时间正常，小部分时间故障，也没怀疑到资源问题
花了一周排查各种问题，各种慢查询优化都没有解决问题，才怀疑到是资源问题，认真排查了一下监控，发现出故障前CPU是高低波动，出故障时，MySQL的CPU直接下降到一个点，然后呈近乎一条直线。
运维后面给AWS提工单，AWS回复建议之所以正常是积分生效，积分用完就出问题了，建议升配。
如果没有积分机制，那么早就发现问题了，就是资源不足……

事实上，在后续的生产环境，也出现过类似的问题，在突发流量时，触发积分不足的问题。
解决？自然就是把积分不足的情况，也纳入监控和告警了。

---

2、DNS有qps限制

这个是生产环境出现的，巡查生产错误日志，发现每天的高峰期，都会出现几条DNS解析错误日志。
找运维排查还是没发现问题，
又是下工单找AWS协助，答复是：
K8S里的CoreDNS，有qps访问上限要求，而且是跟宿主机相关，跟pod数无关；
如果请求量大了，必须扩容购买宿主机。
也就是说，即使你的宿主机资源足够，但是只要出现这个DNS的访问限制问题，也还是必须购买新的宿主机才能解决。

---

3、强制升级要求

AWS的很多服务：kafka、k8s、mysql，都会定期升级，而且是强制升级，并且有时间期限，
到截止时间，AWS会强制自动升级。
关键升级的频率还很高，几乎隔1，2个月就会来一次，原因就是修补各种bug或安全隐患。

但是正常情况下，生产服务基本都是部署在内网，并且有IP白名单限制，
对外一般只开放80和443的Web端口，即使存在安全隐患，一般也不会有什么问题，
这样，升级这个事情，对我们几乎没有收益，反而可能出现服务中断。
比如在Kafka的实际升级过程中，

• 有些系统消费者程序没做幂等，或幂等做的不好导致垃圾数据；
• 有些系统生产者没做ack保障，导致消息丢失；
• 还有些系统没对kafka异常做捕获，导致后续流程中断。

当然，这些都是我们系统健壮性、可用性不够，对异常处理不完善的问题，需要安排修复。
但是在创业团队的实际工作中，一般不会给你太多时间去做SLA的质量保证工作；
所以能不升级，业务团队还是希望不升级，稳定为主。