我们为什么从 Lambda 迁移到了 ECS?

在本文中,我将深入探讨 Lambda 的成功之处,我们面临的挑战,以及为什么我们最终会决定将一些服务从 Lambda 迁移到 AWS 弹性容器服务(Elastic Container Service,ECS)。

我们要解决的问题是什么?

简单介绍一下背景,我们的产品是 B2B 软件公司的一个集成平台,我们帮助软件公司构建集成,并将这些集成部署给他们的客户。一次简单的集成可能如下所示:

  • 步骤一:在 Dropbox 中下拉 XML 文档。
  • 步骤二:使用一些自定义的 JavaScript 代码处理 XML。
  • 步骤三:使用一些存储的凭证,向第三方 API 发布经过处理的数据。

用户可以按计划配置集成以运行,也可以通过 webhook 触发集成,而平台则负责运行、记录和监控集成(以及一大堆其他内容)。

早期情况

Prismatic 的第一个实现使用 LocalStack。我们希望最终把 Prismatic 托管在 AWS 上(根据需要可能会迁移到 Azure、GCP 等),所以需要在本地启动我们的平台来模拟 AWS。类似 AWS Lambda 的 LocalStack 服务易于迭代,并且在运行中不会出现大问题。这为我们提供了一个非常好的开发反馈回路,我们很快进行了原型设计和测试。

在使用 Lambda 执行集成的每一个步骤时,步骤利用 SQS 传递数据并触发下一个步骤。所以,集成的执行情况如下所示:

  • 执行 Dropbox 的“获取文件”动作以抓取 XML 文件。
  • 在 SQS 中保存 XML 文件的内容,触发下一步骤。
  • 运行客户自定义 JavaScript 代码以处理 XML。
  • 在 SQS 中保存生成的转换数据,并触发下一步骤。
  • 执行一个动作,将处理后的数据发布到第三方 API。
  • 保存上一步骤的结果,触发集成结束。

这对于 LocalStack 来说是一个非常快速的过程。我们可以定义一个 6 步集成,运行它,然后在几秒内就能看到结果。

向实际的 AWS Lambda 迁移

当我们的概念被证明可行之后,我们就将 Prismatic 转到实际生产环境中,使用实际的 Lambda、队列、数据库等等。我们还只是一个小团队,不想花太多的时间来解决 DevOps-y 的基础设施问题。我们希望花更多的时间在核心商品上,而 Lambda 能让我们做到这一点。

此外,Lambda 在很多方面都比较有优势。比如,我们无需担心 CPU 或内存分配、服务器监控或自动扩展,因为这些都是内置的。还可以将包含 JavaScript 代码的 .zip 文件放到 Lambda 上,AWS 负责剩下的工作。Lambda 让我们将代码分成一系列服务(一个用于日志记录、一个用于 OAuth 密钥更新、一个用于集成出错时短信 / 邮件提醒等),这样我们就能很好地理解由哪些代码负责哪些任务。成本也很合理:你只需支付计算时间的费用。我们无需全天候运行服务器,只需在我们的原型执行某些任务时付费。

Terraform 上运行几天之后,我们在 AWS 上有了 Prismatic 的第二个实现。集成运行器运行在实际的 Lambda 上,并且被 SQS 触发。此时,我们就要面对集成运行器的性能问题了。

为何 Lambda 无法工作

在 Lambda 中,我们遇到了速度、SQS 大小的限制以及缺少进程隔离等问题。这让我们重新考虑它作为集成运行器的有效性。下面我们依次对这些问题进行讨论:

速度。我在前文提到过,在 LocalStack 内运行 6 步集成只需几秒。但是在实际的 Lambda 和 AWS 中,这花了整整一分钟。实际上,Lambda 调用非常快,通常为几毫秒。但是,在向 SQS 写入步骤结果的过程中,以及在接下来执行下一步骤的过程中,每一步骤都需要几秒钟。对于更为复杂的集成来说,比如那些循环了 500 多个文件的集成,这就成为一个障碍:谁想要花上几分钟(几小时)来完成他们的集成?

为了加快 Lambda 调用的速度,我们尝试了许多方法。根据指导原则,我们为一些 Lambda 实例保留了“热度”,并将驱动 Lambda 的虚拟 CPU 数量增加到了当时能够达到的最高水平(6 个虚拟 CPU/10 GB 内存),但这只会降低我们集成运行时间的个位数百分比。

SQS 的大小限制。SQS 限制消息大小为 256 KB。在集成的各步骤之间传递的数据量通常会超过这个大小(毕竟,集成开发人员现在一个数兆的 JSON 文件进行处理是完全合理的)。要想绕过这个大小限制,推荐的解决方案是向 S3 写入有效载荷,然后通过 SQS 传递对 S3 对象的引用——但是这个对 S3 的 API 调用只会使速度更慢。

结果表明,如果客户在其集成中编写了像 global.XMLHttpRequest = null; 这样不好的代码,依赖 XMLHttpRequest 库的集成随后将在同一个 Lambda 上运行,这将导致错误。这个问题很大,因为一个客户可能会破坏其他客户的 axios。有些客户甚至可能会恶意执行 global.console.log = (msg) => { nefariousCode(); } 之类的操作,同时,当调用 console.log() 时,同一 Lambda 上执行的其他集成将运行 nefariousCode()。

为了解决共享执行空间的问题,我们做了一些尝试。我们曾强迫 Lambda 每次都冷启动(这是一个坏主意,原因显而易见),也曾试过在 chroot jail 中启动不同的 Node 进程。这两种方法都不起作用:在 Lambda 中启动子 Node 进程需要 3~5 秒的时间,并且在一定程度上与 Lambda 的初衷背道而驰。

向 ECS 迁移

在开发方面,Lambda 为我们提供了很好的服务:我们可以快速迭代,并获得一个原型,但是由于 Lambda 面临的各种问题,我们决定咬紧牙关,花一些开发时间在云基础设施上。

为了扩展已有的 Terraform 脚本,并将集成运行器迁移到 AWS 弹性容器服务(ECS),我们的团队已经开始了工作。使用 ECS 容器,我们可以轻松地、快速地使用 chroot,并将 Node 进程彼此隔离,从而解决了 Lambda 中出现的进程隔离问题。为解决 SQS 的大小限制问题,我们改用了 Redis 支持的队列服务。虽然我们重新发明一些 Lambda 免费提供的“轮子”,比如日志、自动扩展和健康检查,但是最终,我们的 6 步测试集成将在 2 秒内恢复运行。

但是,ECS 也并不完美,有些东西需要进行取舍。比如,ECS 的自动扩展似乎没有 Lambda 快。“扩展”似乎要花费一分钟时间,从 API 调用到 AWS Fargate 获取并初始化一个准备好接受工作的容器。我们不得不让一名开发者从产品开发中抽调出来,参与云基础设施的工作,同时在 CPU 和内存使用、自动扩展规则和监控方面也有许多问题需要解决,但在产品开发的这一阶段,这种痛苦是值得的,因为它能让我们为客户提供一个快速的集成运行器。

Lambda 还有什么?

在 Lambda 中,我们并没有移出所有的微服务:许多微服务仍然保留在无服务器的生态系统中,并且在可预见的将来也是如此。集成运行器并不适用于 Lambda,但是对于其他任务,它似乎是一个明确的选择。在 Lambda 中,我们保留了所有重要的集成服务,而这些服务对 Lambda 的实际执行并不重要。其中包括:

  • 从 ECS 中提取日志并将其发送到 DataDog 的记录器服务。
  • 向 PostgreSQL 数据库写入关于集成执行的元数据的服务。
  • 跟踪和排队调度的集成服务。
  • 如果用户的集成出错,就会向用户发送短信或电子邮件通知的警报服务。
  • 针对第三方服务的 OAuth 2.0 密钥更新授权服务。

我们不希望让这些服务妨碍集成的运行,如果它们需要更多的一两秒钟来运行也没有问题,因为对于 Lambda 来说,这样做是很合适的。

总结

当然,随着时间的流逝,我们的基础设施肯定会发生变化,但是我认为我们一直在做正确的决定。通过 LocalStack 的“Lambda”服务,我们可以进行快速地开发和迭代,我们的 AWS 首次部署非常简单,我们的小型开发团队可以更改我们的基础设施,而无需花费大量的开发时间。

Lambda 看起来是一个很有吸引力的解决方案,可以用于托管和扩展我们的微服务,而且对于许多这样的服务,尤其是那些可能需要一到两秒才能运行的一步服务,仍然是正确的选择。但是,对于我们的集成运行器,我们了解到 Lambda 的规模、速度和进程隔离限制使得 ECS 成为更好的选择,并且值得为这个特定服务创建 ECS 部署所需的开发时间。

Lambda 让我们在早期关注产品开发,当时机成熟时,向 ECS 迁移将会非常顺利。尽管我们在 Lambda 遇到了很多困难,但我很高兴我们走上了正规。

作者介绍:

Taylor Reece,Prismatic 开发技术推广工程师,具有 DevOps/ 云的背景。

原文链接:

https://dzone.com/articles/why-we-moved-from-lambda-to-ecs

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/A73fcOBEa2A6PFj4bqqZ
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券