选择无服务器：Babbel 的迁移故事

Babbel 是什么？

Babbel 是一个完整的语言学习产品生态系统，囊括了世界上最畅销的语言学习应用程序。我们已售出超过 1000 万份订阅和超过 60,000 门涵盖 14 种语言的课程，创造了全球第一语言学习目的地。自 2007 年推出产品的第一天起，我们就一直在 Amazon Web Services（ Amazon）上运行我们的平台，并且经常是 AWS 新服务产品的早期采用者。由于我们的 Babbel 学习生态系统是纯数字化的，因此它严重依赖于底层技术，这些技术不仅需要可靠稳定，而且需要能够在任何时间点都具有可扩展性。这会带来挑战和机遇，尤其是随着产品供应的增加和服务格局的变化。

Babbel 一直在不断扩大我们的学员基础，从 2007 年到 2020 年，我们的访问量随之增加。2020 年，Babbel 的学员群体大幅增长，来自美国和我们主要欧洲市场的流量增长了两到三倍。随着疫情导致全球出现各种不同的法规政策，许多人选择学习一门新语言或提高他们的语言技能。这使传入流量出现更多峰值，从未有过如此规模。在此期间，我们没有担心我们的基础设施是否会受到用户需求不断变化所带来的挑战。

但是，在 2020 年之前，我们在 Babbel 构建的用于托管 Babbel 服务的平台并未利用所有 Amazon 无服务器服务。它依赖于在 Amazon OpsWorks 上运行的旧堆栈，这无法再满足需求。在本文中，我们描述了促使 Babbel 考虑做出改变的原因、我们考虑的选项以及我们最终如何将生产工作负载迁移到 Amazon Fargate 上的 Amazon ECS 和 Amazon Lambda。

为什么要改变我们的架构？

在一个不断增长和动态变化的环境中，我们有动力去改变和改进事物。我们努力寻找改进机会，以便为我们的学员提供更好的学习体验。可以想象，优先考虑技术层面并不一定会轻松实现学习体验的改进，但我们会将一些支柱作为路标：

• 加快开发速度并缩短发布时间
• 减少维护工作
• 拥有并维护最新的环境
• 缩短功能交付时间

在开始该项目之前，我们运行的是旧版本的 OpsWorks，这要求我们使用过时的 Chef 版本来管理 OpsWorks EC2 实例的配置。这些实例基于较旧的实例类型，并使用其生命周期即将结束的 Ubuntu 版本，因此绝对需要采取行动。将 Chef Cookbook 升级到新 Chef 版本、升级 Ubuntu 版本以及升级旧的 OpsWorks EC2 实例将花费大量时间。此外，我们的部署、回滚和升级占用了开发人员大量的维护工作时间，而我们希望减少这些时间。在流量快速激增的情况下，我们的扩缩时间比我们预期的要长，而且自动扩缩不可靠。某些情况下，将额外的 EC2 实例添加到 OpsWorks 集群需要长达 25 分钟。对于负载均衡，我们只能使用 Classic ELB，它不具备我们想要使用的全部功能，例如通过 Cognito 进行身份验证及路由。这些功能在应用程序负载均衡器（ALB）中可用，但 OpsWorks 当时不支持 ALB。鉴于这些情况，我们得出结论，理想的解决方案应解决这些问题，这意味着我们必须放弃 OpsWorks EC2 设置。

考虑迁移选项

在分析潜在的技术解决方案之前，我们从功能角度讨论了最适合我们的解决方案。我们一致认为，理想情况下，解决方案应该

• 与我们现有的 Amazon 架构以及 Terraform 投资和结构完美集成

• 通过专门的服务和支持团队积极开发并保持最新状态

• 腾出运营和维护时间，使我们专注于能为学员或 Babbel 工程团队带来更多价值的事情 我们很清楚，正确的解决方案是实现无服务器。我们接着研究了可用的解决方案，以摆脱 OpsWorks 并取代整个计算和托管层。我们考虑的选择是：

• Amazon Lambda

• Amazon Elastic Container Service（Amazon ECS）

• Amazon Elastic Kubernetes Service（Amazon EKS） 关于这些选项，我们得出了以下结论：

Amazon Lambda

理想情况下，我们将在 Lambda 上运行几乎所有内容。默认情况下，扩缩是自动进行的，无需配置，无需维护实例，无需在操作系统层自己进行操作系统和安全更新，并且部署/回滚是即时的。对于某些服务，这是可能的，我们决定为它们使用 Lambda。但是，我们发现 Lambda 并非适合所有服务的解决方案。我们有一些需要 Docker 的多用途服务，在 2020 年初进行评估时，Lambda 尚不支持容器映像格式。

Amazon ECS

由于 Lambda 不适合此类服务，因此我们必须决定在哪个平台上运行我们的（Docker）容器。我们评估了 Amazon EKS 和 Amazon ECS，有以下四个选项可供选择：

• EC2 上的 ECS
• Fargate 上的 ECS
• EC2 上的 EKS
• Fargate 上的 EKS

由于使用 Fargate 上的 ECS 和 EC2 上的 ECS 非常相似，与 Kubernetes 和 EKS（在 EC2 或 Fargate 上）相比，它们对于整个生态系统而言，属于同一种替代解决方案，因此我们权衡了使用这两种技术堆栈的利弊。2019 年，我们开始在 Fargate 上运行 ECS，最初缺少我们当时需要的一些功能（例如容器的成本分配标签）。我们的 AWS 客户经理帮助我们处理了功能请求，这些功能随后得以实施。这些功能发布后，我们就顺利地将所有新的 Docker 化的服务迁移到 Fargate 上的 ECS 了。对于我们的架构而言，在 EC2 和 Fargate 之间，Fargate 是更好的选择，因为它消除了底层 EC2 机器的维护工作。该技术堆栈还很容易与其余的 AWS 服务和 Terraform 代码库集成，在这方面我们已经有管理经验。

Amazon EKS

在权衡运行 EKS 的利弊时，我们认为这不是我们的用例和基础设施设置所必需的。我们的主要目标是建立一个平台，以最少的工作量扩展我们的 Docker 容器，同时对环境的其余部分和 Amazon 服务集成进行最少的更改。此外，我们希望确保尽可能减少运维工作量，因为这不会给我们的学员带来任何价值。使用 Kubernetes，我们认为学习难度更大，需要对现有环境进行更多更改，并需要更多的运营和维护工作。我们认为，我们可以使用更加以 Amazon 为中心的基础设施即代码，更好地分离开发和基础设施，我们正在通过 Terraform 管理这种基础设施即代码（例如，使用 Amazon IAM）。简而言之，我们希望改变我们的计算/托管环境，而不必对我们的系统和服务，以及我们运行部署、管理网络和安全组的方式等进行更大的调整。

2019/2020 年初，EKS 仍然是一项较新的服务。当时，我们决定不采用 EKS（或 Kubernetes）是担忧不能很好地支持在 Amazon 上运行的 Kubernetes 功能。虽然 EKS 使用上游 Kubernetes 代码（不加修改），但我们担心 Kubernetes 最新版本与 EKS 可用版本之间存在差异。当时，我们不确定能否立即访问所有最新的 Kubernetes 功能。在这种情况下，特定功能并没有成为障碍，但我们决定使用 Amazon 优先的服务，而不是 Amazon 托管的开源服务。当然，使用 Kubernetes 有很多好处，比如在运行混合云环境时能够进行更精细的控制，但这对我们来说并不重要。总而言之，由于上述原因，我们决定使用 ECS 而不是 EKS（因此我们没有比较应该在 EC2 还是 Fargate 上运行 EKS）。

迁移工作负载

由于我们以前有过运行 Amazon Lambda 的经验，从 Amazon OpsWorks 到 Amazon Lambda 的初始服务迁移进展迅速，没有出现任何不可预见的问题。由于我们没有任何使用 Amazon Fargate 的经验，因此在开始迁移到 Amazon Fargate 之前，我们必须将所有剩余服务 Doker 化。除了由于缺乏此类迁移经验而不得不克服的技术难题外，还需要进行大量的团队间协调，因为迁移涉及 10 多种服务，包括面向客户的服务和内部服务。当然，前几项服务花费的时间最多，因为我们必须找出最好的方法来进行部署、微调我们的自动扩缩，并确保将服务迁移到 Docker 的过程正常进行。我们首先开始迁移对产品没有影响的内部服务，然后迁移对客户有影响的内部服务，最后是面向客户的服务。现在，最终设置会有所不同，因为我们的服务具有不同的集成和环境（例如，有时我们会将 Amazon Cognito 与 ALB 一起使用，或者在 ALB 前面使用 CDN 等）。以下是简化的之前/之后比较，如下所示：

结论

一旦我们完成了项目的技术变更，就该评估我们是否实现了目标。总而言之，最初的痛点是：

• OpsWorks/Chef/EC2 的维护工作量很大，大量开发时间花在维护上，而不是为客户改进应用程序

• 由于底层的 OpsWorks 和 Chef 堆栈，扩缩不可靠，预热时间长达 20 分钟以上

• 使用 OpsWorks 的设置无法使用应用程序负载均衡器，后者具有我们想要使用的功能 通过切换到 Amazon Fargate 上的 Amazon ECS，以及 Amazon Lambda，我们获得了以下好处：

• 更快的发布和回滚速度，更少的维护时间，使我们能够专注于为学员构建新功能。使用 Amazon Lambda 以及 Amazon Fargate 上的 Amazon ECS，我们从每个 OpsWorks 集群 25-30 分钟的部署时间，变为几乎即时部署/回滚。

• 与我们之前的设置相比，可实现快速的自动可扩展性。2020 年 3 月，我们的流量出人意料地快速增长，产生来自世界各地的全天候需求高峰，事实证明这样做很有用。

• 将特定 Amazon 服务与其他 Amazon 服务集成在一起，以实现不同的目的，例如通过使用 Amazon ECR 映像扫描或通过 ALB 直接身份验证，将安全扫描作为发布流程的一部分进行集成

• 降低成本，这是以更高效的方式利用我们的计算工作负载的附带结果。我们已经在 https://www.babbel.com/en/magazine/how-to-do-more-with-fewer-servers 中详细描述了这一点

关于 Babbel

Babbel 的使命是：让所有人都能学习语言。这意味着要开发能够帮助人们跨文化联系和交流的产品。Babbel、Babbel Live 和 Babbel for Business 致力于在真实情境下、在真人之间运用语言。并且行之有效：耶鲁大学、纽约城市大学和密歇根州立大学的研究证明了它的有效性。关键是人文与技术的融合。150 多名语言学家精心制作了超过 6 万节课，涵盖 14 种语言，不断分析用户行为，以塑造和调整学员的体验。柏林和纽约总部共有来自 60 多个国家/地区的 750 名员工，正是他们之间的个体差异塑造了独一无二的人类。Babbel 是全球最赚钱的语言学习应用程序，已售出超过 1000 万份订阅。欲了解更多信息，请访问 www.babbel.com 或在 App Store 或 Play Store 中下载应用程序。

本篇作者

Gyorgi Stoykov

Gyorgi Stoykov MSc. 是 Babbel 基础设施团队的高级经理，目前位于柏林。他在财富 500 强公司、初创企业和学术界等各种环境中的云计算和基础设施方面拥有丰富的经验。他对 DevOps、Amazon 以及通过应用敏捷和 DevOps 最佳实践帮助组织构建云原生产品充满热情。

文章来源：

https://dev.amazoncloud.cn/column/article/6309a3fa0c9a20404da79140?sc_medium=regulartraffic&sc_campaign=crossplatform&sc_channel=bokey