弃用 AWS 后，我们服务器的年成本降低了 80%

Posted 2022-10-10 AI科技大本营

摘要：云时代，在面对云厂商高额的成本时，放弃云服务采用内部基础设施进行替换是否是更合适的选择？

原文链接：

https://levelup.gitconnected.com/how-we-reduced-our-annual-server-costs-by-80-from-1m-to-200k-by-moving-away-from-aws-2b98cbd21b46

声明：本文为 CSDN 翻译，未经允许禁止转载。

作者 | Trey Huffine

译者 | 弯月       责编 | 辛晓亮

在本文中，我们采访了 Prerender.io 的首席工程师兼经理 Zsot Varga。他跟我们分享了一个真实的小故事：他们放弃了AWS，并构建了内部基础设施来处理流量和缓存数据，从而将服务器每年的费用从100万美元降低到了20万美元。

“我们的目标是降低成本，同时保持渲染速度和服务质量不变。这类的迁移需要仔细计划和认真执行，配置不正确或执行不给力就会导致客户网页和社交媒体宕机，影响他们的网络搜索排名，也会导致我们的客户流失。”

需要解决的技术问题

简单来说，我们的产品Prerender会缓存和预渲染javascript页面，这样搜索引擎就可以抓取和索引一个纯html文件，你只需要在网站上安装适当的中间件，就可以避免使用昂贵且冗长的JavaScript解决方案。

但是，所有这些数据和流程都需要在服务器上处理，为此以前我们使用的是AWS。经过几年的发展，如今我们每分钟需要处理的页面超过了7万，存储的页面高达5.6 亿，因此而产生的AWS费用也高达一百万美元。

继续使用AWS，我们就需要持续承担如此高昂的费用。相反，我们花了三个月的时间，通过一些现成的思路和一个清晰的计划，削减了80%的成本。

迁移计划

之前，我们使用的是托管在亚马逊的AWS之上的服务器，用于存储客户缓存和呈现的页面。众所周知，AWS是目前最大的云提供商之一，提供虚拟服务器和托管服务。

我们利用AWS来存储缓存页面，然后供Google、Facebook以及其他搜索引擎查询或抓取。我们的产品Prerender的主要功能就是向Google以及其他搜索引擎提供静态的HTML页面，向人类用户提供动态的交互式 JavaScript。

我们所面临的问题是，将大量（TB级）的预渲染网页存储到第三方服务器上产生了巨额的费用。通过这种方式存储缓存页面，导致我们所需承担的维护和托管费接近天文数字。

此外还有一个问题，很多初创公司都没有考虑到，也没有太多相关的话题引发讨论，那就是流量成本。

将数据导入 AWS 是免费的，但对于大多数软件来说，静态数据并没有什么用。但移动这些数据会产生巨额成本，而这将成为我们前进道路上的瓶颈。

那么，该怎么解决呢？我们的计划是，将缓存的页面和流量迁移到自己内部的服务器上，并尽快减少对AWS的依赖。

我们预估了一下成本，发现可以将托管费用降低 40%，而且此次服务器迁移不仅可以节省我们的成本，也可以为客户省钱。

我们的目标是降低成本，同时保持渲染速度和服务质量不变。这类的迁移需要仔细计划和认真执行，配置不正确或执行不给力就会导致客户网页和社交媒体宕机，影响他们的网络搜索排名，也会导致我们的客户流失。

为了避免可能出现的问题，我们的计划包含三个阶段。如果出现任何问题，我们可以轻松地退回到前一个阶段。如果由于某种原因导致新服务器无法工作，我们也可以轻松地回滚，而不会出现任何停机或影响到客户的服务降级。

我们需要谨慎地执行系统测试，而且这是一个持续的过程，可能需要数周或数月的时间。

迁移过程

第一阶段：测试（4～6周）

第一阶段的主要工作是设置裸机服务器，在小规模且易于管理的机器上测试迁移，然后再扩大规模。这个阶段没有太多修改软件的需求，我们决定在Linux的KVM虚拟机上运行服务器。

5 月初，我们的第一批服务器开始运行，1%的流量被定向到新服务器。迁移两周后，我们每天的费用节省了800美元。5月底，我们已将大部分流量工作负载从 AWS 迁移出去，渲染工作负载的成本降低了 45%。

服务器每月的成本降到了13,000 美元，与AWS相比，开支已经削减了 22%。

测试阶段对于确保今后流程的顺利运行至关重要。我们付出了巨大努力，设法通过更多的监控和更好的错误处理来提高系统的稳健性。除了已有的服务器监控仪表板外，我们还设置了一个新的渲染监控仪表板，以便发现错误或性能问题。

多亏了持续的监控和清晰的沟通，我们的测试成功了，最终能节省的成本已超出了预期。一切准备就绪，我们开始向第二阶段迈进。

第二阶段：技术迁移（4周）

6月～7月初，我们以第一阶段的迁移作为概念验证，在此基础之上进行技术方面的迁移。第二阶段的主要工作是将缓存存储移动到裸机服务器。

6 月中旬，我们搭建了300台服务器，并开始顺畅运行，缓存页面总数达到 2 亿。我们的每台服务器上都使用了 Apache Cassandra 节点（与AWS S3兼容）。

我们将在线迁移分为四个步骤，每个步骤相隔1～2周。在测试了页面是否可以同时缓存在 S3 和 minio 中之后，我们慢慢地将流量从 AWS S3 切换到minio。在向S3的写入完全停止后，我们每天省下了200美元的成本（使用S3 API的费用）。也就是说，我们现在可以删除缓存在 Cassandra 集群中的数据了。

6月24日，第二阶段的工作暂告一段落，这时我们的成本骤降。在这之前的四个星期里，我们将大部分缓存工作负载从 AWS S3 转移到了我们自己的 Cassandra 集群。随之而来的是，AWS每天的开销降至1,100美元，预计每月3.5万美元，而新服务器的每月经常性成本约为1.4万美元。

当时，S3仍留有一些数据，每天的开销约为60美元，而且会在接下来的几周内逐渐消失。尽管我们本可以将所有数据移出，将成本立即削减成零，但将数据移出 AWS 需要一次性支出5000美元，这笔钱花得有点冤。

移动数据是我们遇到的巨大瓶颈，我们的新CTO Zsolt Varga表示：

“ASW真正的坑在于流量成本，他们的存储费用非常合理，甚至可以免费上传。但是当你将数据拿出来的时候，就需要付出巨大的代价。”

“小型创业公司通常不会计算流量成本，尽管这笔费用有可能占到总成本的90%。”

举个例子，假设你在美国西部地区（比如俄勒冈），那么必须支付的流量成本为0.080 美元/GB，而在亚太地区（比如首尔）则需要支付0.135 美元/GB。

而对于我们，每月的流量成本轻轻松松就能达到3万～5万美元。在第二阶段结束时，我们的服务器每月的总成本降低了 41.2%。

第三阶段：实现和扩展（4～6周）

到这一阶段，迁移工作进行得很顺利，而且我们已经节省了大量资金。剩下的工作是将所有其他数据迁移到本地的服务器上。

这个阶段我们需要移动所有的亚马逊RDS示例。这是整个过程中最容易出错的部分，但是由于很大一部分数据已经迁移完了，因此任何故障或瓶颈都不会导致整个迁移崩溃。

以下是我们在迁移过程的最后阶段所需完成的工作：

• 将存储cached_urls表的PostgreSQL分片镜像到Cassandra；

• 将 service.prerender.io 切换到 Cloudflare 负载均衡器，以允许动态流量分配；

• 建立新的欧盟私人缓存服务器；

• 反复进行压力测试，解决任何性能问题。

最终结果证明，此次迁移取得了巨大的成功。当所有缓存页面都被重定向后，我们每月的服务器费用下降到最初预估的40%～80%。

我们获取的经验教训

如果在此过程中遇到任何问题或实际的工作进展落后于计划，服务器迁移都将面临很多风险。因此，我们在迁移的每个阶段都设计了故障保险，以确保出现问题时我们可以回到上一步。这也是我们在全面迁移之前，实施了一系列小规模测试的原因。

为了规避风险，我们仔细规划了迁移的每个阶段，在扩展之前测试了每个实施阶段，并在出现问题时及时修复。这样，我们不仅大幅降低了服务器的费用，而且将所有潜在风险降至最低。

迁移服务器的动力

如你所见，客户可以利用我们的产品推出以用户体验为中心的网站，他们的工作重心是为客户提供最好的服务，而不是设法优化SEO。在过去的几年里，每当建立一个新页面，我们都需要利用Wordpress，仅仅是为了获得最好的 SEO，而只把管理界面等需要SPA的功能留给未索引的页面。但如今，我们可以帮助客户解决过去的这些难题。

技术栈的选择

Javascript的使用范围非常广泛，由于我们解决了Javascript 渲染引起的“问题”，因此我们希望在这个领域积累尽可能多的专业知识。我们利用CloudFlare的分布式系统，实现了快速响应和全球扩展。在Digital Ocean云平台的支持下，我们可以保障正常的运行时间。此外，我们还使用了很多其他 SaaS 提供商来最大限度地提高我们的效率。