案例研究：为什么我将 AWS 云基础设施用于我的产品

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

本文将介绍一个这样的 AWS 云基础架构架构，它是为 LEVELS 提出和实施的，这是一个具有集成面部支付功能的社交网络，它发现并应用用户可能从他们所在的卡程序、他们拥有的东西或地方获得的所有好处他们住在。

要求

客户提出的解决方案必须满足两个主要要求：

1. 安全
2. 可扩展性

安全要求是关于保护用户的数据免受来自外部和内部的未经授权的访问。 可扩展性要求是关于基础设施支持产品增长的能力，自动适应不断增加的流量和偶尔的峰值，以及在服务器发生故障时自动故障转移和恢复，最大限度地减少潜在的停机时间。

AWS 安全概念概述

设置您自己的 AWS 云基础设施的主要好处之一是完全的网络隔离和对您的云的完全控制。 这就是您选择基础架构即服务 (IaaS) 路线的主要原因，而不是运行更简单的平台即服务 (PaaS) 环境，后者提供可靠的安全默认设置，但缺乏完整、细粒度的控制。使用 AWS 设置您自己的云。

尽管 LEVELS 在向 Toptal 寻求 AWS 咨询服务时还是一个年轻的产品，但他们愿意承诺使用 AWS，并且知道他们希望通过其基础设施获得最先进的安全性，因为他们非常关心用户数据和隐私。 最重要的是，他们计划在未来支持信用卡处理，因此他们知道他们需要在某个时候确保 PCI-DSS 合规性。

虚拟私有云 (VPC)

AWS 上的安全性始于创建您自己的Amazon Virtual Private Cloud (VPC) - 一个专用的虚拟网络，用于托管您的 AWS 资源，并在逻辑上与 AWS 云中的其他虚拟网络隔离。 VPC 拥有自己的 IP 地址范围、完全可配置的子网、路由表、网络访问控制列表和安全组（实际上是防火墙）。

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

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

VPC 级别的访问隔离

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

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

Assets Store 安全模型

资产存储在Amazon Simple Storage Service (S3)对象存储中。 S3 存储基础设施完全独立于 VPC，其安全模型也不同。 针对每个环境和/或资产类别，存储被组织在单独的 S3 存储桶中，以适当的访问权限保护每个存储桶。

使用 LEVELS，确定了几类资产：用户上传、LEVELS 制作的内容（宣传视频和类似内容）、Web 应用程序和 UI 资产（JS 代码、图标、字体）、应用程序和基础架构配置以及服务器端部署包。

其中每一个都有一个单独的 S3 存储桶。

应用程序秘密管理

借助 AWS，有一个加密的AWS Systems Manager Parameter Store或AWS Secrets Manager ，它们是旨在保护机密安全的托管键值服务（您可以在 Linux Academy 和 1Strategy 了解更多信息）。

AWS 管理底层加密密钥并处理加密/解密。 Secret 本身可以根据密钥前缀为基础设施和用户（分别为服务器和开发人员）应用读取和写入权限策略。

服务器 SSH 访问

完全不需要在完全自动化且不可变的环境中对服务器进行 SSH 访问。 可以提取日志并将其发送到专用的日志记录服务，监控也可以卸载到专用的监控服务。 尽管如此，可能仍需要偶尔进行 SSH 访问以进行配置检查和调试。

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

数据库访问

上面概述的相同原则适用于数据库服务器。 有时可能还需要直接连接和操作数据库中的数据，尽管这绝对不是推荐的做法，并且这种访问需要以与服务器 SSH 访问受到保护的方式相同的方式进行保护。

可以使用类似的方法，将相同的堡垒主机基础设施与 SSH 隧道结合使用。 需要一个双 SSH 隧道，一个到堡垒主机，通过那个，另一个到可以访问数据库的服务器（堡垒主机没有数据库服务器访问权限）。 通过第二条隧道，从用户的客户端机器到数据库服务器的连接现在可用。

AWS 可扩展性概念概述

当我们纯粹谈论服务器时，使用比 AWS 更简单的平台很容易实现可扩展性。 主要缺点是平台的外部服务可能需要满足某些要求，这意味着数据通过公共网络传输并打破安全边界。 坚持使用 AWS，所有数据都保持私有，同时需要设计可扩展性以实现可扩展、有弹性和容错的基础设施。

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

卸载所有这些可以让运营团队更小，在一定程度上抵消了平台托管服务的更高成本。 LEVELS 团队很乐意尽可能选择这条路。

亚马逊弹性计算云 (EC2)

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

EC2 实例供应需要完全自动化。 自动化是通过针对不同类别的服务器的自定义 AMI 实现的，Auto Scaling 组通过根据当前流量在队列中保留适当数量的正在运行的服务器实例来负责运行动态服务器队列。

此外，自动扩展功能允许设置要运行的 EC2 实例数量的下限和上限。 下限有助于容错，可能在实例失败的情况下消除停机时间。 上限可以控制成本，在意外的极端条件下允许一些停机风险。 然后，自动缩放会在这些限制内动态缩放实例数量。

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

该团队已经在Amazon RDS for MySQL上运行，但尚未开发出适当的备份、容错和安全策略。 在第一次迭代中，将数据库实例升级为每个 VPC 中的双实例集群，配置为 master 和 read-replica，支持自动故障转移。

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

由于缩放导致的停机时间无法避免，但可以借助自动修复功能将其减少到最低限度。 由于更好的复制功能，Aurora 提供了无缝的故障转移功能。 通过创建具有所需计算能力的只读副本，然后执行到该实例的故障转移来执行扩展。 然后，所有其他只读副本也会从集群中取出、调整大小并带回集群。 它需要一些手动杂耍，但不仅仅是可行的。

新的 Aurora Serverless 产品还支持某种程度的计算资源自动扩展，这是未来绝对值得研究的功能。

托管 AWS 服务

除了这两个组件之外，系统的其余部分还受益于完全托管的 AWS 服务的自动扩展机制。 它们是 Elastic Load Balancing (ELB)、Amazon Simple Queue Service (SQS)、Amazon S3 对象存储、AWS Lambda 函数和 Amazon Simple Notification Service (SNS)，架构师不需要进行特别的扩展工作。

可变与不可变基础设施

我们认识到处理服务器基础架构的两种方法 - 一种可变的基础架构，其中安装了服务器并不断更新和修改就地； 以及不可变的基础架构，其中服务器在配置后永远不会修改，并且任何配置修改或服务器更新都通过从通用映像或安装脚本配置新服务器来处理，替换旧服务器。

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

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

架构概述

从技术上讲，LEVELS 是一个移动应用程序和一个具有 REST API 后端和一些后台服务的 Web 应用程序 - 现在是一个相当典型的应用程序。 对此，提出并配置了以下基础设施：

虚拟网络隔离 - Amazon VPC

该图可视化了其 VPC 中一个环境的结构。 其他环境遵循相同的结构（在其 VPC 中的非生产环境之间共享 Application Load Balancer (ALB) 和 Amazon Aurora 集群，但网络设置完全相同）。

VPC 跨 AWS 区域内的四个可用区进行配置，以实现容错。 具有网络访问控制列表的子网和安全组可以满足安全和访问控制要求。

在业务及其产品的早期阶段，跨越多个 AWS 区域的基础设施以获得额外的容错能力过于复杂和不必要，但在未来是一种选择。

计算

LEVELS 运行一个传统的 REST API，其中包含一些后台工作程序，用于在后台发生的应用程序逻辑。 这两者都作为普通 EC2 实例的动态队列运行，通过 Auto Scaling 组完全自动化。 Amazon SQS托管服务用于后台任务（作业）分发，无需运行、维护和扩展您自己的 MQ 服务器。

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

负载平衡、自动扩展和容错

负载平衡可以通过 Nginx 或 HAProxy 手动实现，但选择Amazon Elastic Load Balancing (ELB)可以增加负载平衡基础设施本质上自动可扩展、高可用性和容错的优势。

使用 ELB 的 Application Load Balancer (ALB) 风格，利用负载均衡器上可用的 HTTP 层路由。 添加到队列的新实例通过 AWS 平台的机制自动注册到 ALB。 ALB 还始终监控实例的可用性。 它具有注销和终止不健康实例的能力，触发 Auto Scaling 以用新实例替换它们。 通过两者之间的相互作用，实现了 EC2 队列自动修复。

应用程序数据存储

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

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

使用 Aurora 以 10GB 的增量自动扩展数据库存储，备份也完全由 AWS 管理，默认情况下提供时间点恢复。 除了在需要时扩展数据库计算能力之外，所有这一切都将数据库管理负担减少到几乎没有——这项服务非常值得付费以无忧运行。

存储和服务资产

LEVELS 接受用户上传的需要存储的内容。 可以预见的是， Amazon S3对象存储是负责该任务的服务。 还有一些应用程序资产（UI 元素 - 图像、图标、字体）需要提供给客户端应用程序，因此它们也被存储到 S3 中。 S3 通过其内部存储复制提供上传数据的自动备份，默认提供数据持久性。

用户上传的图片大小和重量各不相同，通常对于直接提供服务来说太大而且超重，给移动连接带来负担。 生成不同大小的多个变体将能够为每个用例提供更优化的内容。 AWS Lambda用于该任务，以及将上传的图像原件复制到单独的备份存储桶中，以防万一。

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

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

基础设施供应和管理

预置 AWS 基础设施是网络、AWS 托管资源和服务以及裸 EC2 计算资源的组合。 托管 AWS 服务是托管的。 除了预置和应用适当的安全性之外，与它们没有太多关系，而使用 EC2 计算资源，我们需要自己处理配置和自动化。

工装

基于 Web 的 AWS 控制台使管理“乐高积木式”AWS 基础设施绝非易事，而且与任何手动工作一样，也很容易出错。 这就是为什么非常需要使用专用工具来自动化该工作的原因。

一种这样的工具是AWS CloudFormation ，由 AWS 开发和维护。 另一个是 HashiCorp 的Terraform - 通过提供多个平台提供者提供了一个稍微灵活的选择，但这里很有趣，主要是由于 Terraform 的不可变基础设施方法理念。 与 LEVELS 基础设施的运行方式保持一致，Terraform 与提供基础 AMI 图像的 Packer 一起被证明是非常合适的。

基础设施文档

自动化工具的另一个好处是它不需要详细的基础架构文档，这些文档迟早会过时。 供应工具的“基础设施即代码”(IaC) 范例配音为文档，其优点是始终与实际基础设施保持同步。 有一个高层次的概述，不太可能被改变，并且随着最终的改变相对容易维护，在旁边记录就足够了。

最后的想法

提议的 AWS 云基础设施是一种可扩展的解决方案，能够自动适应未来的产品增长。 近两年后，它依靠云自动化，无需专门的系统运营团队 24/7 值班，就设法将运营成本保持在较低水平。

在安全性方面，AWS Cloud 将所有数据和所有资源保存在同一云中的私有网络中。 无需任何机密数据通过公共网络传输。 外部访问被授予对受信任的支持系统（CI/CD、外部监控或警报）的精细权限，将访问范围仅限于其在整个系统中的角色所需的资源。

这样的系统经过正确的架构和设置，具有灵活性、弹性、安全性，并且可以满足未来所有关于扩展产品增长或实施高级安全性（如 PCI-DSS 合规性）的要求。

它不一定比 Heroku 或类似平台的产品化产品便宜，只要您符合其产品所涵盖的常见使用模式，这些产品就可以很好地工作。 通过选择 AWS，您可以获得对基础设施的更多控制权、提供的 AWS 服务范围的额外灵活性以及具有整个基础设施微调能力的自定义配置。

进一步阅读 Toptal 工程博客：

• 做好功课：7 个 AWS 认证解决方案架构师考试技巧
• Terraform 与 CloudFormation：权威指南
• 使用 AWS SSM 的 SSH 日志记录和会话管理
• 使用 TypeScript 和 Jest 支持：AWS SAM 教程