弃用 AWS 后，我们每年减少了 80% 服务器成本
作者 | Trey Huffine
译者 | 弯月 责编 | 辛晓亮
出品 | CSDN（ID：CSDNnews）
在本文中，我们采访了 Prerender.io 的首席工程师兼经理 Zsot Varga。他跟我们分享了一个真实的小故事：他们放弃了AWS，并构建了内部基础设施来处理流量和缓存数据，从而将服务器每年的费用从100万美元降低到了20万美元。
“我们的目标是降低成本，同时保持渲染速度和服务质量不变。这类的迁移需要仔细计划和认真执行，配置不正确或执行不给力就会导致客户网页和社交媒体宕机，影响他们的网络搜索排名，也会导致我们的客户流失。”
01.
需要解决的技术问题
简单来说，我们的产品Prerender会缓存和预渲染JavaScript页面，这样搜索引擎就可以抓取和索引一个纯HTML文件，你只需要在网站上安装适当的中间件，就可以避免使用昂贵且冗长的JavaScript解决方案。
但是，所有这些数据和流程都需要在服务器上处理，为此以前我们使用的是AWS。经过几年的发展，如今我们每分钟需要处理的页面超过了7万，存储的页面高达5.6 亿，因此而产生的AWS费用也高达一百万美元。
继续使用AWS，我们就需要持续承担如此高昂的费用。相反，我们花了三个月的时间，通过一些现成的思路和一个清晰的计划，削减了80%的成本。
02.
迁移计划
之前，我们使用的是托管在亚马逊的AWS之上的服务器，用于存储客户缓存和呈现的页面。众所周知，AWS是目前最大的云提供商之一，提供虚拟服务器和托管服务。
我们利用AWS来存储缓存页面，然后供Google、Facebook以及其他搜索引擎查询或抓取。我们的产品Prerender的主要功能就是向Google以及其他搜索引擎提供静态的HTML页面，向人类用户提供动态的交互式 JavaScript。
我们所面临的问题是，将大量（TB级）的预渲染网页存储到第三方服务器上产生了巨额的费用。通过这种方式存储缓存页面，导致我们所需承担的维护和托管费接近天文数字。
此外还有一个问题，很多初创公司都没有考虑到，也没有太多相关的话题引发讨论，那就是流量成本。
将数据导入 AWS 是免费的，但对于大多数软件来说，静态数据并没有什么用。但移动这些数据会产生巨额成本，而这将成为我们前进道路上的瓶颈。
那么，该怎么解决呢？我们的计划是，将缓存的页面和流量迁移到自己内部的服务器上，并尽快减少对AWS的依赖。
我们预估了一下成本，发现可以将托管费用降低 40%，而且此次服务器迁移不仅可以节省我们的成本，也可以为客户省钱。
我们的目标是降低成本，同时保持渲染速度和服务质量不变。这类的迁移需要仔细计划和认真执行，配置不正确或执行不给力就会导致客户网页和社交媒体宕机，影响他们的网络搜索排名，也会导致我们的客户流失。
为了避免可能出现的问题，我们的计划包含三个阶段。如果出现任何问题，我们可以轻松地退回到前一个阶段。如果由于某种原因导致新服务器无法工作，我们也可以轻松地回滚，而不会出现任何停机或影响到客户的服务降级。
我们需要谨慎地执行系统测试，而且这是一个持续的过程，可能需要数周或数月的时间。
03.
迁移过程
第一阶段：测试（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%。
04.
我们获取的经验教训
如果在此过程中遇到任何问题或实际的工作进展落后于计划，服务器迁移都将面临很多风险。因此，我们在迁移的每个阶段都设计了故障保险，以确保出现问题时我们可以回到上一步。这也是我们在全面迁移之前，实施了一系列小规模测试的原因。
为了规避风险，我们仔细规划了迁移的每个阶段，在扩展之前测试了每个实施阶段，并在出现问题时及时修复。这样，我们不仅大幅降低了服务器的费用，而且将所有潜在风险降至最低。
05.
迁移服务器的动力
如你所见，客户可以利用我们的产品推出以用户体验为中心的网站，他们的工作重心是为客户提供最好的服务，而不是设法优化SEO。在过去的几年里，每当建立一个新页面，我们都需要利用Wordpress，仅仅是为了获得最好的 SEO，而只把管理界面等需要SPA的功能留给未索引的页面。但如今，我们可以帮助客户解决过去的这些难题。
06.
技术栈的选择
Javascript的使用范围非常广泛，由于我们解决了Javascript 渲染引起的“问题”，因此我们希望在这个领域积累尽可能多的专业知识。我们利用CloudFlare的分布式系统，实现了快速响应和全球扩展。在Digital Ocean云平台的支持下，我们可以保障正常的运行时间。此外，我们还使用了很多其他 SaaS 提供商来最大限度地提高我们的效率。
往期推荐
☞ 中国云计算第一股关停 IoT云服务
☞ 国内 IoT 物联网平台终局的思考
☞ 2022年IoT平台趋势：私有化部署
☞ 5个值得分享的物联网创业失败教训
☞ 国内 4 大 IoT物联网平台选型对比
☞ 云厂商的 [IoT物联网平台] 不香了吗？
