工作室所接客户及项目在国外AWS区比较多，到目前在7个AWS地区部署上线，运行维护将近8年的时间，这里着重就常见问题这几个方面来展开：

1. AWS的故障
2. 自动伸缩规则
3. DDoS防护小建议

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暂时不可用外，另一个可用区的网络并没有受到影响，对外服务也没有受到干扰。

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

1. 保持多可用区部署且无状态，避免单点服务，增加更细的监控点（比如对所使用的AWS服务本身）。
2. ELB要打开Cross-Zone Balancing功能，按实际机器数量来均分流量，默认是按可用区均分流量。
3. 增加Fault Tolerance测试，类似Netflix Chaos Monkey的做法，评估我们所使用的每个AWS服务故障时，对服务可能产生的影响。
4. 跨地区的切换，比如：东京不可用，就把用户流量切到新加坡。
5. 购买AWS Support Plan，解决AWS故障时信息不透明且无人可帮忙的困境。

零星小故障总结：

1. 定 时事件，虽然官方不叫故障，属于我个人意见。有些底层的硬件存在故障或者需要更新，AWS会提前通知，到时间，通常情况下机器会被停掉重启。比较烦人的点 就是冷不丁就冒出来了，通常都必须要去关注，当然不同的事件级别不同，出现时还是小心为好，找好维护时间窗，早点解决。
2. 有时候机器会被意外关掉，重启或者短暂网络故障，通常都不会有通知，而此时AutoScaling健康检查也相应失效。这种问题现在变得越来越少，主要靠监控发现，然后找AWS Support一起跟踪确认原因。
3. 如果使用DNS来帮助服务发现，就要小心Route53的API调用限制，因为Route53是全局服务，API调用数量的计算按一定时间内，所有地区调用的总和。这个本质上不算故障。

自动伸缩

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

1. 可用性和稳定性是通过定时健康状况检查和自动替换机器来做到的，包括EC2本身的健壮检查、使用ELB的健康监控，甚至自定义的监控通过API反馈给AutoScaling服务。
2. 伸缩规则分为两种：简单规则和步进规则。
   a. 简单规则，只根据一条规则增减容量，比如当平均CPU超过70%，增加两台机器。Cloud Watch会去自动监控这个指标，达到时就会告警，触发伸缩行为。这边要注意的是伸缩行为的发生必须等待其他伸缩行为完成，再响应告警。其中，增减的数量 可以是定值也可以是百分比，同样Cloud Watch中监控到的数据，也可是通过API自定义灌入的。
   b. 步进规则，早先AWS并不支持，它包含一组规则。比如CPU在40%-50%时加一台机器，50%-70%加两台，70%以上加四台等等。此时，若已有伸 缩行为发生，该规则还会继续响应告警，中间会有一个预热时间，时间不到，这个机器的指标都不会计入。和简单规则相比，这种规则的伸缩行为无锁，且持续统计 指标，及时触发，推荐使用。
   
3. 关掉的机器不能做特定选择，但会有一些模糊的规则：运行时间最久的，隶属的伸缩规则最老的，接近一个小时的开机时间等等。
4. 对于是事先准备预编译好的AMI还是通过配置管理工具现场安装，对预热时间比较敏感的服务，推荐是前者。
   介绍完AWS中的自动伸缩服务，引出一个关键问题就是如何设置一个合理的规则，来比较精细地平衡成本和负载。这些都需要通过大量的测试来做权衡判断。

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

1. 这是一整个系统的调优过程，涉及到的参数，可能不仅仅是规则本身，比如，使用ELB的，还要考虑到相关的性能参数。
2. 这个规则可能会随程序的变革而变化，最好做到自动化。
3. 加 机器要早，减机器要慢。负载开始增加时早作打算，因为中间有可能会产生新机器启动失败等问题，另外算上机器启动时间和服务到位的时间，早打算可以避免容量 跟不上的问题；减机器时，要慢慢来，稳稳地进行。否则，一方面避免连接被硬生生掐断，另一方面由于减机器过快，而负载仍在，导致又要增加机器，这使得伸缩 行为太过频繁，成本和稳定性会受到影响。
4. 采集机器的CPU数据，尽量使用Cloud Watch的，本机采集的数据不一定准确。
5. 应用本身需要记录足够的性能数据，写入日志，方便后期数据整理。
6. 如果有条件，可以尝试建立一个简单的数据模型来实际分析。

DDoS防护小建议

这张图描述的是2015年第二季度AWS上有关DDoS的情况。

一个DDoS攻击大小是1.04Gbps，大于10Gbps的攻击持续时间大约39分钟。

图片中展示了AWS防范DDoS的方式，目前是Traffic Shaping，然后通过优先级来标识，如果判断是可能的攻击，就减慢它的速度。

所以这边的建议是：

1. 利用ELB、Route53、Cloudfront（CDN）等已经具有防范DDoS功能的服务。
2. 将机器置于VPC中，设置合理的security group（防火墙），避免直接对外服务。
3. 针对应用层的攻击，则需要WAF来帮忙。

这是一种AWS推荐的保护方式。最外层Cloudfront（CDN）和ELB，中间设置WAF，内层ELB，最后到应用部分。

4

Q&A

Q：请问您觉得AWS和国内的云厂商相比，最大的优势是什么？

A：从全球的角度来看，根据Gartner Report，是最领先的云服务。对于功能而言，AWS的服务多，质量上乘。对于业务需求在海外的，AWS更为重要。有些国内的云服务，基本上都是模仿着AWS起来的。

Q： 防DDoS架构都需要自己搭建，AWS没有提供外层包装好的服务么？

A：AWS内置的服务中已经提供了防范DDoS的能力，大多数情况下都够用，只是针对应用层的攻击，需要额外的服务。另外有很多安全厂商和AWS有合作，在AWS Market可以得到相应的安全服务。

Q：你们用过ECS服务吗，功能上能否满足你们的应用需求？

A：我们目前正在尝试采用ECS的方式来部署我们的服务，10月份的reInvent大会发布了Private Registry还有ecs-cli等一些工具，会使ECS更易使用。

Q：前端放不同az还好说，后端数据库不同az怎么搞？

A：数据库如果是自己在EC2上部署的话，比如我们使用的Cassandra，多台同样可以采用不同AZ，至于AWS本身的数据库服务RDS、Aurora、DynamoDB，里面有一个multi-AZ的功能。

Q： 另外目前很多公司都采用了云服务，很多运维同学比较关注的一个问题是会对运维成员带来了一定的影响，因为很多工作使用云服务就可以解决。一种观点是，上 云，是运维人员的一个机会，因为使用云服务在某个方面来说，对运维人员的要求又提高了。目前熟悉AWS的运维人员并不好招。请问，您是怎么想的？

A：这个问题，我自己也深有体会，Docker会这么火，里面也有这一层关系。

Q：自动伸缩服务对于用户这边需要做哪些准备，如何保证代码持续更新，自动伸缩也是可用的，就是我怎样信任自动扩容出的机器？

A：主要还得要求机器中的服务实现无状态，信任是建立在测试和监控的基础上。代码持续更新是另一个问题，持续发布的问题，这个现有的解决方案也蛮多的，可以线下讨论。

Q：亚马逊云的故障率大概有多少，企业级应用的价格是否可以接受？

A：目前根据我们使用的服务来看，故障率不高，稳定性和质量都蛮高的，剩下的都是一些小问题，2012年的时候曾有5个大问题（AWS专门解释原因的）。对于价格可能要具体问题具体看，对于我们而言，也做企业级应用，7个地区的部署，还是能接受的。

Q：请问有没有部署将企业自己数据中心和AWS上服务互联，推荐方式是？

A：公司里其他部门是有的，通过VPN的方式更安全。

Q：请问ECS是否只有提供CD、CO、CI部分是否只能是用户自己定制和对接，还有预计ECS什么时候会在中国站点发布呢？

A：AWS本身有提供code deploy、code pipeline、code commit持续发布的服务，可以和ECS一起使用，新发布的Private Registry也会对ECS的CI/CD带来帮助。中国站点的情况，不了解。

Q：请问老师是否知道目前亚马逊在国内数据中心部署进展怎样？

A：我们没有使用，所以具体的细节不太了解。似乎是有限开放，之前去reInvent开会，有一个中国专场，很多国内的公司都在使用了。

Q：你们有考虑过灰度发布吗，AWS上对此是否有相应支持？

A：有在使用，粒度现在还比较粗一点。一方面需要依靠应用程序本身，可以做到配置管理。AWS的支持，还是需要通过架构设计来做到，比如Router53支持带权值的DNS，另外还有今年发布的API Gateway也可以拿来帮忙。

Q：目前AWS的一个趋势是推广基于事件的服务，就是逐步弱化服务器的概念，根据事件进行相关服务，这也是领先其它云厂商的一个方面，请问针对这一点，您是怎么想的？

A：本来我也想聊聊lambda这个服务，考虑到时间的问题，没有讨论到。这确实是一个蛮好的想法。我了解的信息是，欧洲、北美有蛮多的公司采用了这种无服务器的方式，基本上不用自己来管理EC2机器，做好监控就可以。好处就是快，坏处就是和AWS耦合太紧。