AWS和Kubernetes上的Scaling嘿

与布雷克·斯托达德(Blake Stoddard)在Basecamp/嘿的高级战略研究人员(SRE)的云对话。为清楚起见，本采访经过编辑和浓缩。

福雷斯特·布拉塞尔：在过去的几周里，Basecamp的新电子邮件应用嘿在科技界掀起了一场风暴。还有很多关于“HEYstack”的讨论--您的云基础设施运行在AWS和Kubernetes上。既然Basecamp以选择“乏味的技术”而闻名，是什么让你考虑在云中运行你的最新应用呢？

Blake Stoddard：Basecamp过去一直在内部数据中心托管我们的SaaS软件，但几年前我们决定尝试一下云计算，以实现我们的一些工作负载。

我们知道我们希望使用容器来更好地协调我们的基础设施部署，因此我们早在2016年就开始使用AWS ECS。在2018年，当我们重新评估我们管理容器编排的方式时，Kubernetes是我们的选择。

我们尝试了一下Google Kubernetes Engine(GKE)--因为他们自然会跳到托管Kubernetes的脑海中--但我们在那里遇到了一些问题，最终决定在2019年初离开GCP。

因为我们在最初的ECS迁移中已经在AWS中拥有了一些其他资源，所以让EKS尝试一下似乎是很自然的。自EKS于2017年首次发布以来，AWS团队在解决我们对该产品的各种担忧方面取得了长足的进步。

快进到今天，嘿主要依靠AWS托管服务--拥有大量Spot实例的EKS，但也有Aurora MySQL、ElastiCache Redis和AWS的托管Elasticsearch。

嘿堆栈：-后端的Vanilla Ruby on Rails，在EDGE上运行-刺激性、Turbolinks、TRIX+前端的新魔术-MySQL for DB(Vitess用于分片)-Redis用于短期数据+缓存-ElasticSearch用于索引-AWS/K8S

-dhh(@dhh)2020年6月24日。

等等，那么您真的将Kubernetes的工作负载从GCP迁移到了AWS？这是“多云”架构带来回报的罕见用例吗？

[笑]我想是的。我们非常重视可移植性，因此我们想知道，如果需要，我们可以在云(和本地)之间迁移工作负载。

不过，我们在这件事上是务实的。Basecamp首次尝试AWS上的容器是使用ECS，我们仍在为多个生产工作负载运行ECS。但是我们发现我们对部署、监控和日志记录的偏好在EKS上比在ECS上工作得更好。

我们还发现，与ECS相比，库伯内斯并不是一个黑匣子。在我们使用ECS的几年中，我们仍然偶尔会遇到任务没有启动等问题。然后，您会花几分钟在UI中查看，试图弄清楚发生了什么，为什么X没有启动，为什么Y处于挂起状态。即使到了那时，你实际上可以做些什么来干预的选择也很少。

有了Kubernetes，我们可以更深入地了解事情是如何安排的，当事情出错时会发生什么，并增强了通过强大的CLI检查正在发生的事情的能力(在我前面提到的部署首选项之上)。

但是，您使用的是托管EK，而不是在EC2实例上托管Kubernetes。您如何在可移植性和减轻管理负担之间划清界限？

不能保证我们会永远呆在EKS上。但是EKS作为一种服务来管理一些低级的事情，比如K8大师，我们根本不愿意处理这些事情。我的意思是，EKS控制机的费用是每小时10美分，相当于每个集群每年820美元。与工程师的时间相比，这是相当便宜的，即使考虑到我们正在运行的集群数量。

如果我们能支付一笔费用来管理它，这样我们就可以把时间集中在对公司有更高价值的工程工作上，我们就会整天接受这笔交易。

Basecamp的创始人兼首席技术官David Heinemeier Hansson说，他“从来没有像过去两周这样开心地呆在云端”。公共云如何帮助您处理出人意料的热门新服务的流量？

如果没有公共云，我们不可能满足嘿的需求。我的意思是，我们计划在几个月内达到5万活跃用户，但我们在两周内就超过了这一目标。

在传统的数据中心世界中，没有好的方法来跟上这种突飞猛进的增长。您要么会预先为大量过度配置买单，要么会一直争先恐后地将新硬件装上机架并堆叠起来。

相反，AWS可以让我们在需要时随时提升新的计算能力。这对于测试来说也很棒--在“嘿”公开发布之前，我们根据我们自己的内部使用模型加载了这款应用程序，这是我们在几个月的时间里对该产品进行测试的结果。云计算非常适合这一点--它使得为这款应用程序试验不同的计算和数据库大小变得非常容易。

最后，考虑到需求，扩展比我预期的要顺利得多。我们已经做了足够的测试，以确定基础设施是可靠的。这只是一个水平扩展我们的集群以处理前端和后端负载的问题。

事实上，我的办公室里挂着一顶帽子，上面写着“云花沙皇”，因为我花了很多时间处理这件事！从原始基础架构成本的角度来看，我们可以更便宜地在本地运行我们的工作负载。我们上云是为了创造更多价值，而不是花更少的钱。

但我在密切关注几件事。我们运行大约90%的Spot实例组合，这降低了我们的计算成本。数据传输一直是一个很大的项目。“如果你相信的话，我们将数据从S3传输到互联网的费用比我们所有的EC2计算机都要高。

另一个问题是：一些服务可能会在你最意想不到的时候堆积账单，比如CloudWatch Logs。它很容易与EKS集成！只需点击一个按钮即可！然后你看着账单，问道：“每天额外的50-60美元是从哪里来的？”

既然你现在已经知道了嘿是如何扩展的，如果你可以从头开始重新设计这款应用，你会做出任何不同的架构选择吗？

一开始我犯了两个错误，这两个错误跳入了我的脑海，当时我正在为嘿规划基础设施。我们使用的是Terraform，我写了一个新的模块来管理我们的私有网络，取代了我们在2016年写的模块。

第一个错误：我没有处理IPv6子网，现在它又让我头疼了(EKS很快就会支持原生IPv6，到那时能解决这个问题就太好了)。

第二个错误是我计划了固定数量的可用区。原来并不是每个AWS地区都有4个AZ--US-EAST-1和US-West-2有，但US-East-2没有！

是的，目前在美国东部1号和美国西部2号。我们希望很快过渡到真正的主动-主动部署，并在区域之间采用基于延迟的路由。我们实际上已经在生产中运行了几次，但是对于需要写入的请求，要在80ms延迟的情况下正确处理主区域，同时确保不会有陈旧的读取，这是很棘手的。

同样，我们花了很多时间来考虑分片和数据局部性。我很想让数据更接近最终用户，但这真的是白日做梦。我们在俄罗斯有客户，即使我们快速地向他们提出我们的要求，往返行程让一切都感觉很慢。

我更喜欢GCP在这里使用全局负载均衡器的方法，在这种方法中，您可以跨多个活动区域进行任播。由于我们在AWS，我们将全球加速器视为实现目标的途径。我们希望这将有助于加快我们的出境流量，因为数据在进入公共互联网之前在AWS网络上停留的时间要长得多，但使用它会产生巨额额外费用，但不能保证它真的能填补我们正在寻找的空白。

有什么最后的智慧要与那些想要在AWS上实施该计划的人分享吗？

密切关注您的DB模式！我们严重依赖关系数据库，借用模式会产生可怕的级联效应。

第二，尽可能多地缓存。嘿，呈现大量电子邮件，我们已经让它变得很快，但从规模上讲，它是计算密集型的。

我想您刚才列出了计算机科学中最难的两个问题，命名和缓存失效。差一错误是另一个最难解决的问题…。还有一件事吗？

您不应该仅仅因为某项技术很时髦就将其与您的堆栈集成。10年前，我们并没有仅仅因为云很酷就跳入云中，感觉我们采用Kubernetes相对较晚，我们不使用服务网。我们已经让这些技术成熟了，现在我们正在获得真正的价值。

我们的故事(和其他许多故事一样！)。表明您不需要经过流血的边缘就可以收获云的好处。