摘要:云时代,在面对云厂商高额的成本时,放弃云服务采用内部基础设施进行替换是否是更合适的选择? 原文链接: https://levelup.gitconnected.com/how-we-reduced-our-annual-server-costs-by-80-from-1m-to-200k-by-moving-away-from-aws-2b98cbd21b46
在本文中,我们采访了 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%,而且此次服务器迁移不仅可以节省我们的成本,也可以为客户省钱。
我们的目标是降低成本,同时保持渲染速度和服务质量不变。这类的迁移需要仔细计划和认真执行,配置不正确或执行不给力就会导致客户网页和社交媒体宕机,影响他们的网络搜索排名,也会导致我们的客户流失。
为了避免可能出现的问题,我们的计划包含三个阶段。如果出现任何问题,我们可以轻松地退回到前一个阶段。如果由于某种原因导致新服务器无法工作,我们也可以轻松地回滚,而不会出现任何停机或影响到客户的服务降级。
我们需要谨慎地执行系统测试,而且这是一个持续的过程,可能需要数周或数月的时间。
迁移过程
第一阶段的主要工作是设置裸机服务器,在小规模且易于管理的机器上测试迁移,然后再扩大规模。这个阶段没有太多修改软件的需求,我们决定在Linux的KVM虚拟机上运行服务器。
5 月初,我们的第一批服务器开始运行,1%的流量被定向到新服务器。迁移两周后,我们每天的费用节省了800美元。5月底,我们已将大部分流量工作负载从 AWS 迁移出去,渲染工作负载的成本降低了 45%。
服务器每月的成本降到了13,000 美元,与AWS相比,开支已经削减了 22%。
测试阶段对于确保今后流程的顺利运行至关重要。我们付出了巨大努力,设法通过更多的监控和更好的错误处理来提高系统的稳健性。除了已有的服务器监控仪表板外,我们还设置了一个新的渲染监控仪表板,以便发现错误或性能问题。
多亏了持续的监控和清晰的沟通,我们的测试成功了,最终能节省的成本已超出了预期。一切准备就绪,我们开始向第二阶段迈进。
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 提供商来最大限度地提高我们的效率。
联系客服