AWS白皮书 – 可靠性

本文讲解AWS良好架构框架（AWS Well-Architected Framework）里其中五大支柱之一：可靠性（Reliability）。

可靠性支柱包含系统从基础设施或者服务中断的状态下进行恢复的能力、动态获取资源以满足需求的能力以及缓解错误配置或者瞬间网络问题等故障的能力。

设计原则

以下几个原则可以帮助你有效地提升可靠性水平：

• 测试恢复流程：在云环境中，我们可以通过自动化的手段模拟不同故障或者重现已经发生的故障，以此来验证我们的故障恢复流程。通过这样做，我们可以在实际故障发生之前纠正错误，同时我们可以避免一些还未发生的潜在危险。
  • NetFlix通过在公司生产环境中引入Chaos Monkey这个“捣乱鬼”，在每天的工作时间随机地对Netflix的AWS环境进行破坏，从而不断完善自己的云环境，保证系统越来越健壮，不再因为一部分应用失效而影响整个生产系统。
  • 除了Chaos Monkey，NetFlix还引入了其他的服务来检查错误的配置以及无效的服务，详情可以阅读Simian Army
• 自动实现故障恢复：通过监控系统内的各项性能指标，你可以在触及阈值的时候触发自动响应操作，自动恢复故障。
• 横向扩展以提升系统可用性：利用多种小型资源取代单一大型资源，来降低单点故障（Single Point of Failure）对整体系统的影响。使用横向扩展，即水平增加更多同样的资源（比如增加实例数量）；而不是纵向扩展，增加资源的容量（比如提升实例类型）。
• 不再猜测容量需求：在云环境中，我们不需要因为资源预测过少而担心影响系统的性能，或者资源预测过多造成资源的浪费。我们可以随时调整资源的大小，甚至可以通过自动化的方法来添加或删除资源，以维持资源的最优水平。
• 自动管理变更：基础设施内的变更应都以自动化的方式实现。

定义

定义的内容非常丰富，在这里只截取一部分比较重要的信息，更多信息可以查看文末的链接。

云环境下的可靠性主要由以下三方面组成：

• 基础（Foundations）
  • 在构建系统之前，我们需要确定一些基础性因素，包括服务限制和网络拓扑结构
    • AWS设置了多项服务设置，用来保护我们免收资源过度配置带来的影响。如果我们需要的资源超过了限制，我们可以寻找AWS支持中心提升我们的限制
    • 具体的AWS服务限制可以查看这里
    • 在设计之初我们需要考虑到未来可能的增长和整合需求，一次性来规划网络架构，防止后期出现无法扩容的情况
  • 常见问题：
    • 如何管理AWS账号内的服务限制
    • 如果管理和规划AWS内的网络拓扑
    • 如果找到AWS技术支持，是否有专门的TAM（Technical Account Manger）支持
• 变更管理（Change Management）
  • 在AWS中，我们可以通过API或者AutoScaling来对资源进行弹性地扩展，并且使用CloudWatch来监控一切参数，更快发现容量问题和不良的趋势。
  • 使用CloudTrail来追踪变更
  • 常见问题：
    • 如何让你的系统适应真实的需求？
    • 如何监控你的AWS资源？
    • 如何执行变更管理
• 故障管理（Failure Management）
  • 要对架构中出现故障有一定的预期，我们需要意识到这些故障，了解它们是如何发生的，如何去预防它们再发生。
  • 定义Recovery Point Objective (RPO)和Recovery Time Objective (RTO)
  • 常见问题：
    • 如何备份你的数据？
    • 系统内组件出现故障需要如何处理？
    • 你的故障恢复计划是什么？

更多关于可靠性的资料，请阅读可靠性支柱 – AWS良好架构框架。