个性化阅读
专注于IT技术分析

案例研究:为什么我将AWS Cloud Infrastructure用于我的产品

本文概述

作为运行复杂而苛刻的软件产品的平台, AWS通过在需要时以所需规模利用资源来提供灵活性。它是随需应变的, 可以对运行环境进行完全控制。向客户提出这样的云架构解决方案时, 预配置的基础架构及其价格在很大程度上取决于需要预先设置的要求。

本文将介绍一种针对LEVELS提出并实施的AWS云基础架构架构, LEVELS是一种具有集成面部支付功能的社交网络, 可发现并应用用户可能会从其所使用的卡程序, 所拥有的东西或地方获得的所有收益。他们住在。

要求

客户对拟议解决方案有两个主要要求:

  1. 安全
  2. 可扩展性
AWS云安全性和可扩展性

安全要求全部是为了保护用户的数据免受来自外部的未经授权的访问, 也包括来自内部的未经授权的访问。可伸缩性要求涉及基础架构支持产品增长, 自动适应不断增长的流量和偶发高峰的能力, 以及在服务器发生故障时自动进行故障转移和恢复, 以最大程度地减少潜在的停机时间。

AWS安全概念概述

设置自己的AWS云基础设施的主要好处之一是完全的网络隔离和对云的完全控制。这就是为什么你选择基础架构即服务(IaaS)路由而不是运行更简单的平台即服务(PaaS)环境的主要原因, 该环境提供可靠的安全性默认值, 但缺乏你所获得的完整, 细粒度的控制使用AWS设置自己的云。

尽管LEVELS在向srcmini寻求AWS咨询服务时是一个年轻产品, 但他们愿意致力于AWS, 并知道他们希望其基础架构具有最新的安全性, 因为他们非常关注用户数据和隐私。最重要的是, 他们计划在将来支持信用卡处理, 因此他们知道他们需要在某些时候确保PCI-DSS的合规性。

虚拟私有云(VPC)

AWS的安全性始于创建你自己的亚马逊虚拟私有云(VPC)-专用虚拟网络, 该虚拟网络托管你的AWS资源, 并且在逻辑上与AWS Cloud中的其他虚拟网络隔离。 VPC拥有自己的IP地址范围, 完全可配置的子网, 路由表, 网络访问控制列表和安全组(实际上是防火墙)。

使用LEVELS, 我们首先将生产环境与开发, 测试和QA环境隔离开来。第一个想法是将它们中的每个作为它们自己的完全隔离的VPC运行, 每个VPC根据应用程序的要求运行所有服务。经过一番考虑, 事实证明, 我们可以允许在三个非生产环境中共享一些资源, 从而在一定程度上降低了成本。

因此, 我们将生产环境定为一个VPC, 将开发, 测试和QA环境定为另一个VPC。

VPC级别的访问隔离

两个VPC设置将生产环境与网络级别上的其余三个环境隔离开, 以确保意外的应用程序错误配置无法跨越该边界。即使非生产环境配置应错误地指向生产环境资源(如数据库或消息队列), 也无法获得对它们的访问权。

VPC网络访问隔离

VPC网络访问隔离

通过共享同一VPC的开发, 测试和QA环境, 可以在配置错误的情况下进行跨边界访问, 但是由于这些环境使用测试数据, 因此不存在真正的安全问题, 因为那里缺乏隔离。

资产商店安全模型

资产将存储在Amazon Simple Storage Service(S3)对象存储中。 S3存储基础架构完全独立于VPC, 并且其安全模型有所不同。存储针对每个环境和/或资产类别在单独的S3存储桶中进行组织, 并通过适当的访问权限保护每个存储桶。

使用LEVELS, 可以识别出几类资产:用户上载, LEVELS产生的内容(促销视频和类似内容), Web应用程序和UI资产(JS代码, 图标, 字体), 应用程序和基础结构配置以及服务器端部署捆绑包。

它们每个都有一个单独的S3存储桶。

应用机密管理

借助AWS, 有一个加密的AWS Systems Manager参数存储或AWS Secrets Manager, 它们是旨在保护机密安全的托管键值服务(你可以在Linux Academy和1Strategy中了解更多信息)。

AWS管理基础加密密钥并处理加密/解密。秘密本身可以基于基础结构和用户(分别是服务器和开发人员)的键前缀应用读取和写入权限策略。

服务器SSH访问

完全不需要通过SSH访问完全自动化且不可变的环境中的服务器。可以提取日志并将其发送到专用的日志服务, 还可以将监视卸载到专用的监视服务。不过, 可能仍需要偶尔进行SSH访问以进行配置检查和调试。

为了限制服务器的攻击面, SSH端口不会暴露在公共网络中。通过堡垒主机访问服务器, 堡垒主机是一台允许外部SSH访问的专用计算机, 并通过仅将防火墙允许的IP地址范围列入白名单而受到保护。通过将用户的公共SSH密钥部署到适当的框中来控制访问(禁用密码登录)。这样的设置为恶意攻击者提供了一个相当有弹性的大门。

数据库访问

上面概述的相同原理适用于数据库服务器。偶尔也可能需要直接在数据库中连接和操作数据, 尽管绝对不建议这样做, 并且需要以与保护服务器SSH访问相同的方式来保护这种访问。

可以使用类似的方法, 将相同的堡垒主机基础结构与SSH隧道一起使用。需要一条双SSH隧道, 一个到堡垒主机, 另一个通过它, 另一个到有权访问数据库的服务器(堡垒主机没有数据库服务器访问权限)。通过第二条隧道, 现在可以使用从用户的客户端计算机到数据库服务器的连接。

AWS可伸缩性概念概述

当我们纯粹谈论服务器时, 使用比AWS更简单的平台很容易实现可伸缩性。主要缺点是平台的外部服务可能需要满足某些要求, 这意味着数据跨公共网络传输并突破了安全边界。坚持使用AWS, 所有数据都将保持私有状态, 同时需要对可伸缩性进行设计以实现可伸缩, 弹性和容错的基础架构。

借助AWS, 最佳的可扩展性方法是利用托管的AWS服务以及在使用该平台的数千个客户端上经过严格测试和监控的自动化。将数据备份和恢复机制添加到组合中, 仅依靠平台本身就可以解决很多问题。

卸载所有这些组件后, 可以组成一个更小的运营团队, 从而在一定程度上抵消了平台管理服务的较高成本。 LEVELS团队很乐意选择该路径。

Amazon Elastic Compute Cloud(EC2)

与运行容器的额外开销和复杂性或仍然非常年轻且快速变化的无服务器计算架构概念相比, 依靠运行EC2实例的可靠环境仍然是一种相当合理的方法。

EC2实例设置需要完全自动化。通过针对不同类服务器的自定义AMI来实现自动化, 并且Auto Scaling组通过根据当前流量在机群中保留适当数量的正在运行的服务器实例来照顾正在运行的动态服务器机群。

此外, 自动缩放功能允许设置要运行的EC2实例数的下限和上限。下限有助于提高容错能力, 从而可以在实例故障的情况下消除停机时间。上限使成本得到控制, 从而在意外的极端情况下有一定的停机风险。然后, 自动缩放会动态缩放这些限制内的实例数量。

亚马逊关系数据库服务(RDS)

该团队已经在MySQL的Amazon RDS上运行, 但是尚未开发适当的备份, 容错和安全策略。在第一次迭代中, 数据库实例被升级到每个VPC中的两个实例的群集, 配置为主实例和只读副本, 支持自动故障转移。

在下一次迭代中, 随着MySQL 5.7版引擎的推出, 基础架构已升级到Amazon Aurora MySQL服务。尽管受到完全管理, 但Aurora并非自动缩放的解决方案。它提供自动存储扩展, 避免了容量规划的问题。但是解决方案架构师仍然需要选择计算实例的大小。

无法避免因缩放而导致的停机时间, 但借助自动修复功能可以将停机时间降至最低。由于具有更好的复制功能, Aurora提供了无缝的故障转移功能。通过创建具有所需计算能力的只读副本, 然后执行到该实例的故障转移来执行缩放。然后, 所有其他只读副本也将从集群中取出, 调整大小, 然后带回集群中。它需要一些手动操作, 但还不可行。

新的Aurora Serverless产品还可以实现一定程度的自动缩放计算资源, 这一功能绝对值得在将来研究。

托管AWS服务

除了这两个组件之外, 系统的其余部分都受益于完全托管的AWS服务的自动扩展机制。这些是弹性负载平衡(ELB), Amazon Simple Queue Service(SQS), Amazon S3对象存储, AWS Lambda函数和Amazon Simple Notification Service(SNS), 其中, 架构师不需要特别的扩展工作。

可变与不可变基础架构

我们认识到两种处理服务器基础结构的方法-一种可变的基础结构, 在该基础结构中安装服务器并进行就地连续更新和修改;以及不可变的基础架构, 在配置之后永远不会修改服务器, 并且任何配置修改或服务器更新都可以通过使用公共映像或安装脚本来配置新服务器来代替旧服务器来进行处理。

使用LEVELS, 选择是运行不变的基础架构, 而无需就地升级, 配置更改或管理操作。唯一的例外是应用程序部署, 它确实就地进行。

在HashiCorp的博客中可以找到有关可变基础架构和不变基础架构的更多信息。

架构概述

从技术上讲, LEVELS是一个具有REST API后端和一些后台服务的移动应用程序和Web应用程序, 这是当今相当典型的应用程序。为此, 提出并配置了以下基础架构:

LEVELS云基础架构概述

LEVELS云基础架构概述

虚拟网络隔离-Amazon VPC

该图显示了其VPC中一个环境的结构。其他环境采用相同的结构(在其VPC中的非生产环境之间共享应用程序负载平衡器(ALB)和Amazon Aurora群集, 但网络设置完全相同)。

在AWS区域内的四个可用性区域中配置了VPC, 以实现容错功能。具有网络访问控制列表的子网和安全组可满足安全性和访问控制要求。

在业务及其产品的早期阶段, 跨多个AWS区域跨越基础架构以实现更高的容错性可能过于复杂且不必要, 但是在将来是一个选择。

电脑运算

LEVELS运行带有某些后台工作程序的传统REST API, 以处理后台发生的应用程序逻辑。这两个都是作为纯EC2实例的动态队列运行, 并通过Auto Scaling组实现了完全自动化。 Amazon SQS托管服务用于后台任务(作业)分发, 从而无需运行, 维护和扩展自己的MQ服务器。

级别后台作业分配

级别后台作业分配

还有一些实用程序任务没有与应用程序的其余部分共享业务逻辑, 例如图像处理。此类任务在AWS Lambda上运行得非常好, 因为Lambdas可以无限地水平扩展, 并且与服务器工作人员相比提供了无与伦比的并行处理能力。

负载平衡, 自动缩放和容错

可以通过Nginx或HAProxy手动实现负载平衡, 但是选择Amazon Elastic Load Balancing(ELB)带来的好处是, 负载平衡基础架构本质上可以自动扩展, 高可用性和容错性。

使用了ELB的应用程序负载平衡器(ALB)风格, 从而利用了负载平衡器上可用的HTTP层路由。通过AWS平台的机制, 添加到舰队的新实例将自动向ALB注册。 ALB还始终监视实例的可用性。它具有注销和终止不正常实例的功能, 可以触发Auto Scaling用新实例替换它们。通过两者之间的这种相互作用, 实现了EC2车队的自动修复。

应用数据存储

该应用程序数据存储是一个Amazon Aurora MySQL集群, 由一个主实例和多个只读副本实例组成。在主实例发生故障的情况下, 其中一个只读副本会自动提升为新的主实例。这样配置, 可以满足要求的容错要求。

自动Amazon Aurora实例故障转移模型

自动Amazon Aurora实例故障转移模型

顾名思义, 只读副本还可以用于为数据读取操作分配数据库集群负载。

Aurora会自动以10GB的增量自动扩展数据库存储, 并且备份也完全由AWS管理, 默认情况下会提供时间点还原。除了在需要时扩大数据库的计算能力之外, 所有这些几乎减轻了数据库管理的负担-值得为运行无忧而付出的服务。

储存和服务资产

LEVELS接受用户需要存储的上载内容。可以预见, Amazon S3对象存储将负责该任务。还需要使客户端应用程序可以使用应用程序资产(UI元素-图像, 图标, 字体), 因此它们也将存储到S3中。通过内部存储复制提供上载数据的自动备份, S3默认提供数据持久性。

用户上传的图像大小和重量各异, 对于直接投放和超重而言通常不必要大, 给移动连接带来负担。生产不同大小的几种变体将使你能够为每个用例提供更多优化的内容。为了以防万一, 将AWS Lambda用于该任务, 以及将上传的图像原件复制到单独的备份存储桶中。

最后, 运行浏览器的Web应用程序也是一组静态资产-持续集成构建基础结构会编译JavaScript代码, 并将每个构建也存储到S3中。

一旦将所有这些资产安全地存储在S3中, 就可以直接使用它们, 因为S3提供了公共HTTP接口, 也可以通过Amazon CloudFront CDN对其进行服务。 CloudFront使资产按地理分布, 从而减少了对最终用户的延迟, 并且还启用了HTTPS支持以服务静态资产。

LEVELS S3存储桶和CloudFront CDN组织概述

LEVELS S3存储桶和CloudFront CDN组织概述

基础架构配置和管理

供应AWS基础设施是网络, AWS受管资源和服务以及裸EC2计算资源的组合。托管的AWS服务很好。除了提供和应用适当的安全性外, 它们没有太多关系, 而使用EC2计算资源时, 我们需要自己进行配置和自动化。

工装

基于Web的AWS控制台使管理”类似乐高积木”的AWS基础设施变得非常简单, 并且在任何手动工作中都易于出错。因此, 非常需要使用专用工具来自动完成这项工作。

一种这样的工具是由AWS开发和维护的AWS CloudFormation。另一个是HashiCorp的Terraform, 它是通过提供多个平台提供商而提供的一种稍微灵活的选择, 但在这里有趣的主要原因是Terraform的不变基础架构方法理念。与运行LEVELS基础架构的方式保持一致, Terraform以及与Packer一起提供基本AMI图像的结果非常适合。

基础架构文档

自动化工具的另一个好处是, 它不需要详细的基础结构文档, 而该文档迟早会过时。调配工具的”基础结构即代码”(IaC)范例被复制为文档, 其好处是始终与实际基础架构保持最新。具有高层次的概述, 不太可能被更改, 并且相对容易保存最终更改, 而在侧面记录下来就足够了。

最后的想法

拟议的AWS Cloud基础设施是一种可扩展的解决方案, 能够自动适应未来产品的增长。在将近两年后, 它依靠云自动化设法保持较低的运营成本, 而没有专门的24/7系统运营团队。

关于安全性, AWS Cloud将所有数据和所有资源保留在同一云内的专用网络中。遍历公共网络不需要保密数据。外部访问被授予对受信任支持系统的精细粒度权限(CI / CD, 外部监视或警报), 仅将访问范围限制为它们在整个系统中的角色所需的资源。

这样的系统经过正确的架构和设置, 具有灵活性, 弹性, 安全性, 并可以满足将来有关扩展产品规模或实施高级安全性(如PCI-DSS兼容性)的所有要求。

它不一定比Heroku或类似平台之类的产品提供的价格便宜, 只要你适合其产品所涵盖的常见使用模式, 它们就可以很好地工作。通过选择AWS, 你可以更好地控制基础架构, 通过提供的一系列AWS服务获得更高的灵活性, 并通过整个基础架构的微调功能进行自定义配置。

相关:做功课:7个AWS认证解决方案架构师考试技巧

赞(0)
未经允许不得转载:srcmini » 案例研究:为什么我将AWS Cloud Infrastructure用于我的产品

评论 抢沙发

评论前必须登录!