弃用 AWS 后，咱们办事器的年本钱升高了 80%

肩膀

摘要：云时期，在面对云厂商高额的本钱时，保持云办事采取外部根底设施进行交换是不是是更适合的选择？
http://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
译者 | 弯月 责编 | 辛晓亮
出品 | CSDN（ID：CSDNnews）
在本文中，咱们采访了 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 提供商来最大限制地进步咱们的效力。