AWS 架构最佳实践概述(十一)

AWS 架构最佳实践

AWS合理架构的框架支柱

  • 安全性 - 保护并监控系统
    • 能够保护信息、系统和资产
    • 通过风险评估和缓解策略
  • 可靠性 - 从故障中恢复并减少中断
    • 从基础设施或服务故障中恢复
    • 动态获取计算资源以满足需求
    • 减少配置错误和暂时性网络问题来减少中断
  • 绩效 - 谨慎使用资源
    • 高效的使用计算资源以满足系统需求
    • 在需求改变和技术发展时依旧保持效率
  • 成本优化 - 消除不必要的费用
    • 减少不必要的成本和次优资源
  • 卓越操作

合理架构设计原则

  • 停止猜想容量需求 - 传统环境存在浪费
  • 在生产层面测试系统 - 传统环境下因为高昂的测试成本,所以通常都无法真实模拟生产环境进行测试
  • 降低架构改变风险 - 传统环境中需要排队等待的测试序列化,在测试过程中的各种改变,可能影响后续测试。
  • 通过自动化让部署更简单 - 低成本通过脚本创建并复制系统,追踪变更和恢复
  • 支持架构的不断发展 - 传统环境受产品生命周期限制,前期决策也可能成为阻碍,无法响应不断变化的业务需求
  • 数据驱动型架构 - 在云环境中,可以通过CloudWatch收集相关数据,来了解架构负载情况。云基础架构以代码的形式存在,因此可以利用这些数据来改善架构。
  • 通过模拟大型流量实现改进 - 通过模拟大型流量,来改进架构中的不足之处,并且积累应对的经验和方案。

高可用和冗余

  • 发现当前架构中的单点故障,引入冗余来消除
  • 选择最适合的备份和恢复方案最高效的冗余
  • 使用不同的可用区实现地域高可用
  • 利用Route53和ELB主动切换来实现主动的冗余机制减少中断时间

弹性设计

  • 弹性系统是随时间推移或响应业务需求突然变化以应对增长的负载,随用户、流量、数据大小的增长而不会影响性能
  • 资源增长应该引入规模经济效益,成本应遵循童谣你给的维度从而使该系统创造商业价值
    • 垂直缩放
      • 通过停止实例调整更多的CPU、RAM、IO、网络等功能实现
      • 垂直缩放有其上限、且不容易实现
    • 水平缩放
    • 无状态应用程序
    • 所有操作不需要知道过去的上下文,会话也不会被存储
    • 可以进行任意的水平扩展且可随意的安全终止,因为系统资源间不会共享会话数据
    • 所有节点不需要意识到其他节点的存在,只需要处理分配给他的工作量即可
  • Autoscaling是最佳实践
    • 无状态组件
      • 大多数应用程序都需要维护某些状态信息,如登录信息等。
      • 方案一:
        • 应用程序可以通过用户会话标识存储在客户端本地(如HTTP Cookie)实现一定程度的无状态, 但是会存在两个问题:
        • 放在客户端本地Cookie的信息容易被篡改,每次都需要传送用户会话状态占用资源增加延迟
      • 方案二:
        • 用户会话信息存储在服务器关联的数据库中, 如DynamoDB,从而实现服务器组件的无状态化
    • 有状态组件
      • 很多应用程序和体系结构都无法转变成无状态的
      • 许多遗留系统设置被设计成必须依靠本地单独计算资源运行的

自动化部署

  • 公有云最大的好处就是能够利用API来自动化部署过程,建议从一开始就进行自动化部署
  • 自动化和可重复部署将有效的减少错误并促使高效的可扩展更新过程
  • Bootstrap 实例
    • 利用自动化动作Bootstrap实例
      • 在初始化过程中用于只是简单的指定如名称、角色信息,其他都有脚本自动完成,对不同的选项提供所有必要的自动化启动资源,包括code、script和configuration等。
    • 重复创建相同环境
    • 对云基础架构保持抽象
    • 减少人工部署错误机会
    • 创建一个自我发现和自我修复的环境

选择合适的存储

  • S3
    • Web需要大规模存储容量和性能
    • 高耐久性数据,以及支持灾难恢复的备份
  • Glacier
    • 数据归档和长期备份
  • Cloudfront
    • 利用内容交付网络在全球边缘位置部署静态、动态、流媒体和交互式内容
  • DynamoDB
    • 快速且灵活的NoSQL数据库,灵活的数据模型和可靠的性能
    • 可以用来解耦有状态应用,将用户状态存储在DynamoDB中使应用程序可以实现无状态组件
  • EBS
    • 可靠地块存储运行关键程序,如Oracle,SAP,Exchange等
  • RDS
    • 高可用的SQL数据库
  • Redshift
    • PB级数据仓库,支持业务分析
  • ElasticCache
    • Redis集群内存缓存
  • EFS (弹性文件系统)
    • 多个EC2实例之间共享应用程序的通用文件系统

AWS 架构最佳实践概述(十一)

在每一层建立安全

  • 传统的安全审计是定期和审计的,但是在云端可以提供持续监控和治理,同事利用代码将安全策略嵌入基础设施设计
  • 最佳实践
    • 对数据进行清点和优先级排序,在传输和存储时应用适当的加密级别
    • AWS功能实现多级防御
      • 网络层面: VPC 、 子网、安全组、路由控制
      • 主机层面: WAF、 IAM
    • 将安全交给AWS
      • 使用AWS 托管服务,由AWS进行补丁和安全管理
      • 减少特权访问
      • 应用程序使用临时安全令牌在EC2上运行
    • 使用IAM进行账户和权限管理
      • 使用临时令牌提供联合访问
      • 对凭据进行自动分发和轮换
      • 授予最小权限的标准安全惯例
    • 利用代码实现安全
      • 利用CloudFormation脚本进行可靠地安全部署 称为"Golden Environment"
      • 最佳安全实践将会被很容易的在不同环境中重用并且集成到CICD pipeline中
      • 可以利用安全测试自动发现与安全策略基线的偏差
      • CloudFormation 可以作为产品导入AWS Service Catalog 中进行一致性治理
    • 实时审计
      • AWS实现持续监控和控制自动化,最大限度降低安全风险
      • 借助Config Rules 可以知道某个组件是否在短时间内不合规
      • CloudWatch提供广泛的日志记录、
      • CloudTrail 实现实际的API调用
      • 所有日志可以备Lambda、EMR等自动处理

并行化处理思维

  • 云中可以轻松实现并行处理
  • 如检索和存储数据时,云被设计成处理大规模并行操作,所以为了提高性能和吞吐率,应该尽可能使用并行请求设计
  • Web应用程序,应该设计成支持ELB负载均衡的传入请求分布的并行处理
  • 批处理场景下更多的使用拥有多从属节点的hadoop架构

松耦合设计

  • 将系统设计成多个独立组建的系统体系,组件越松散,相互依赖性越低,系统规模就能更大
  • Amazon API Gateway提供了公开定义接口的方法,是完全托管的服务
  • 支持开发人员创建、发布、维护和监控以及保护各种规模API
  • 可以处理所涉及的数十万并发的API调用,包括流量管理、授权和访问控制
  • 异步集成是松耦合的常用模式,利用SQS或者Kinesis进行松耦合集成
  • 利用异步集成耦合可以引入额外的弹性,可以对处理失败的消息进行再次处理

AWS最佳实践

  • 实现扩展架构 - 以应对需求变化
  • 自动部署环境 - 消除手工操作提高系统的稳定性和一致性,并提高组织效率
  • 使用一次性资源 - 将服务器和其他组件视为临时资源
  • 松耦合组件 - 降低相互依赖,当一个组件变化或出故障时,其他组件不受影响,ELB和SQS是主要解耦解决方案
  • 设计服务而不是设计服务器 - 托管方案和无服务架构让环境实现更高的可靠性和环境 ,如Lambda, SQS,SNS,DynamoDB
  • 更合适的数据库解决方案 - 技术与工作负载相匹配,选择关系型数据库,NoSQL数据库,数据仓库以及针对搜索优化过的数据存储
  • 避免单点故障 - 实施冗余以避免单点故障破坏整个系统,可以选择停机启动的自动化解决方案或者托管服务在故障时自动对底层进行替换
  • 优化成本 - 确保资源规模适当、可以根据需求进行自动缩减和扩展,充分利用不同的定价方案. 将资本性支出转变为可变支出。
  • 使用缓存 - 尽可能减少冗余数据检索操作
  • 在各个位置保护基础设施安全 - 可以在外围和资源内部或资源之间实现安全性

事件驱动架构

概述

  • 云计算的优势就是快速对资源需求方面的变化作出响应,以应对变化。
  • 传统模式下,即便是在云计算平台中,当服务器满负荷也会导致无法响应访问,虽然手工扩展只需要几分钟时间,但是也是不能接受的

基于事件驱动的架构

  • 监控解决方案CloudWatch
    • 利用CloudWatch监控服务器队列,通过设置多样的阈值来触发扩展,阈值规则设置可以设定到特定的应用程序自定义指标。
  • AutoScaling
    • 通过收到CloudWatch的告警进行实例扩展,在应用服务达到全容量前就准备就绪来提供无缝体验
    • 垂直扩展
      • 对实例规格进行变化,如CPU、内存等
      • 垂直扩展始终有其天花板,而且可能会存在更多的性能问题, 如Java堆栈过大造成的回收时长,而且可能需要重启服务器
    • 水平扩展
      • 对实例数量进行变化,添加和删除实例
      • 几乎没有任何能力限制,只是应用程序设计的过程中需要考虑对水平扩展的支持

AWS 架构最佳实践概述(十一)

  • EC2 Auto Recovery
    • 当EC2出现问题时,对受损的实例自动恢复功能或自动替换
    • 通过CloudWatch 检测可能因为网络连接丢失、系统电源损耗、主机软硬件问题导致的EC2受损
    • 替换实例是可以保持相同的实例ID,元数据、IP地址,但是内存数据将会丢失
    • 在中国区尚不支持
    • 不能使用实例存储必须是EBS支持的存储

Web应用设计

Web应用的业务价值

AWS 架构最佳实践概述(十一)

基于云架构的Web托管架构实践

AWS 架构最佳实践概述(十一)

  • Route53 提供DNS服务
  • Cloudfront 为高容量内容提供边缘缓存
  • 前端ELB将流量分不到Web服务器的AutoScaling组
  • Web服务器安全组 实现外部防火墙的安全策略
  • 后端服务器安全组实现后端防火墙的安全策略
  • 后端ELB将流量分布到后端应用程序集群中
  • ElastiCache 为应用程序提供缓存服务,从而减少数据库层的负载
  • 通过S3存储和提供静态资产

猜你喜欢

转载自blog.51cto.com/wzlinux/2431244
AWS