AWS 运维

AWS的故障

从我们2011年接触AWS至今，比较大一点的故障多集中于2012年，小故障每年零零星星还会有一些，总的来说AWS的稳定性和可靠性是越来越好。

这边先简单介绍一下，AWS每一个区域（Region）都会有多个可用区（Availability Zone，简称AZ），可用区之间互相独立，不受其他可用区故障的影响。

我们遇到过一个可用区（AZ）故障，最初的表象是网络时断时续，API Error Rate增加，AWS论坛里面也很有很多人报这个问题，当时没有回应。接下来，网络开始大面积中断，直到整个可用区的EC2服务处于几乎不可用的状态，AWS网站开始告知可用区故障的信息。

再往下，该地区的AWS Management Console也基本刷不出内容。我们自己的监控系统，产生大量的告警，且持续了一个多小时，当时也吓出一身冷汗。因为无法进行直接的人工干预--AWS API直接返回503服务不可用.

另外，AWS文档中提到的关于可用区挂掉后，新的机器会在另一个区自动创建的功能，似乎当时也没有起效。不过，好在我们的机器都是多可用区部署，除个别非关键组件单点，以及AWS API暂时不可用外，另一个可用区的网络并没有受到影响，对外服务也没有受到干扰。

这个事件过后，我们开始反省，如果再发生要怎么办？（后来还真发生了）

保持多可用区部署且无状态，避免单点服务，增加更细的监控点（比如对所使用的AWS服务本身）。

ELB要打开Cross-Zone Balancing功能，按实际机器数量来均分流量，默认是按可用区均分流量。

增加Fault Tolerance测试，类似Netflix Chaos Monkey的做法，评估我们所使用的每个AWS服务故障时，对服务可能产生的影响。

跨地区的切换，比如：东京不可用，就把用户流量切到新加坡。

购买AWS Support Plan，解决AWS故障时信息不透明且无人可帮忙的困境。

零星小故障总结：

定时事件，虽然官方不叫故障，属于我个人意见。有些底层的硬件存在故障或者需要更新，AWS会提前通知，到时间，通常情况下机器会被停掉重启。比较烦人的点就是冷不丁就冒出来了，通常都必须要去关注，当然不同的事件级别不同，出现时还是小心为好，找好维护时间窗，早点解决。

有时候机器会被意外关掉，重启或者短暂网络故障，通常都不会有通知，而此时AutoScaling健康检查也相应失效。这种问题现在变得越来越少，主要靠监控发现，然后找AWS Support一起跟踪确认原因。

如果使用DNS来帮助服务发现，就要小心Route53的API调用限制，因为Route53是全局服务，API调用数量的计算按一定时间内，所有地区调用的总和。这个本质上不算故障。

自动伸缩

自动伸缩（AutoScaling）可以认为是AWS的核心功能，可根据用户的业务需求和策略，自动调整其弹性计算资源。

可用性和稳定性是通过定时健康状况检查和自动替换机器来做到的，包括EC2本身的健壮检查、使用ELB的健康监控，甚至自定义的监控通过API反馈给AutoScaling服务。

伸缩规则分为两种：简单规则和步进规则。

a. 简单规则，只根据一条规则增减容量，比如当平均CPU超过70%，增加两台机器。Cloud Watch会去自动监控这个指标，达到时就会告警，触发伸缩行为。这边要注意的是伸缩行为的发生必须等待其他伸缩行为完成，再响应告警。其中，增减的数量可以是定值也可以是百分比，同样Cloud Watch中监控到的数据，也可是通过API自定义灌入的。

b. 步进规则，早先AWS并不支持，它包含一组规则。比如CPU在40%-50%时加一台机器，50%-70%加两台，70%以上加四台等等。此时，若已有伸缩行为发生，该规则还会继续响应告警，中间会有一个预热时间，时间不到，这个机器的指标都不会计入。和简单规则相比，这种规则的伸缩行为无锁，且持续统计指标，及时触发，推荐使用。

关掉的机器不能做特定选择，但会有一些模糊的规则：运行时间最久的，隶属的伸缩规则最老的，接近一个小时的开机时间等等。

对于是事先准备预编译好的AMI还是通过配置管理工具现场安装，对预热时间比较敏感的服务，推荐是前者。

介绍完AWS中的自动伸缩服务，引出一个关键问题就是如何设置一个合理的规则，来比较精细地平衡成本和负载。这些都需要通过大量的测试来做权衡判断。

设计伸缩规则，需要注意的地方是：

这是一整个系统的调优过程，涉及到的参数，可能不仅仅是规则本身，比如，使用ELB的，还要考虑到相关的性能参数。

这个规则可能会随程序的变革而变化，最好做到自动化。

加机器要早，减机器要慢。负载开始增加时早作打算，因为中间有可能会产生新机器启动失败等问题，另外算上机器启动时间和服务到位的时间，早打算可以避免容量跟不上的问题；减机器时，要慢慢来，稳稳地进行。否则，一方面避免连接被硬生生掐断，另一方面由于减机器过快，而负载仍在，导致又要增加机器，这使得伸缩行为太过频繁，成本和稳定性会受到影响。

采集机器的CPU数据，尽量使用Cloud Watch的，本机采集的数据不一定准确。

应用本身需要记录足够的性能数据，写入日志，方便后期数据整理。

如果有条件，可以尝试建立一个简单的数据模型来实际分析。