行业:娱乐
地点:瑞典
云类型:私有
挑战:效率、扩展、速度
产品类型:安装程序
使用的CNCF项目包括:Envoy、gRPC、Kubernetes
挑战
作为微服务和Docker的早期采用者,Spotify已经将运行在其所有VM上的微服务容器化,并使用了名为Helios的自家制容器编排系统。到2017年底,情况变得很清楚,“让一个小团队来开发这些功能,不如采用由一个大得多的社区支持的东西来得有效。”工程、基础设施和运营主管Jai Chakrabarti说。
解决方案
“我们看到了在Kubernetes周围成长起来的令人惊叹的社区,我们想成为其中的一员。”Chakrabarti表示。与Helios同步运行的迁移可能会进展顺利,因为“Kubernetes非常适合作为Helios的补充,现在是它的替代品。”Chakrabarti说。
影响
“以前,团队必须等一个小时才能创建一个新服务,并让一个运营主机在生产中运行它,但是使用Kubernetes,他们可以在几秒或几分钟内完成这项工作。”网站可靠性工程师James Wen说。此外,使用Kubernetes的封装(bin-packing)和多租户功能,CPU利用率平均提高了两到三倍。
“我们的目标是赋能创作者,为我们今天拥有的所有消费者 - 以及我们将来拥有的消费者 - 提供真正身临其境的聆听体验。”Spotify工程、基础设施和运营主管Jai Chakrabarti说。
自从Spotify于2008年推出音频流媒体平台以来,已经在全球拥有超过2亿的月活跃用户。对于Chakrabarti的团队来说,目标是巩固Spotify的基础设施,以支持所有这些未来的消费者。
Spotify是微服务和Docker的早期采用者,自2014年以来,它已经将运行在其所有VM上的微服务容器化。该公司使用了一个名为Helios的开源、自主开发的容器编制系统,并在2016-17年完成了从内部数据中心到谷歌云的迁移。支持这些决定的是,“我们有一个围绕自主团队的文化,超过200个自主工程团队,他们在不同的领域工作,他们需要能够快速迭代,”Chakrabarti说:“因此,对于我们来说,拥有能够让团队快速行动的开发者速度工具是非常重要的。”
但到2017年底,情况变得很清楚,“一个小团队开发Helios功能的效率,不如采用一个大得多的社区支持的东西,”Chakrabarti说:“我们看到了Kubernetes周围成长起来的神奇社区,我们想成为其中的一员。我们希望从增加的速度和降低的成本中获益,并且在最佳实践和工具方面与行业的其他部门保持一致。”与此同时,该团队希望在蓬勃发展的Kubernetes社区中贡献自己的专业知识和影响力。
另一个好处是:“Kubernetes非常适合作为Helios的补充和替代品,所以我们可以让它与Helios一起运行,以降低风险,”Chakrabarti说:“在迁移过程中,这两种服务都在运行,所以在我们能够在各种负载和压力环境下验证Kubernetes之前,我们不必把所有的鸡蛋放在一个篮子里。”
该团队花了2018年的大部分时间来解决迁移所需的核心技术问题。站点可靠性工程师James Wen说:“我们能够使用Kubernetes的许多API和扩展特性来支持我们的遗留基础设施,并与之进行接口,因此集成非常简单直接。”
迁移始于那年晚些时候,并在2019年加速。“我们的重点实际上是无状态服务,一旦我们解决了最后遗留下来的技术障碍,我们希望加快。”Chakrabarti说:“对于有状态服务,我们需要做更多的工作。”
Spotify拥有150多项服务,其中一小部分已经迁移到Kubernetes。“我们从客户那里听说,他们不太需要专注于手动容量供应,而是有更多时间专注于为Spotify提供功能。”Chakrabarti表示。“目前运行在Kubernetes上的最大的服务是每秒接收超过1000万个请求的聚合服务,并且从自动缩放中获益良多。”Wen说。此外,Wen补充:“以前,团队必须等待一个小时才能创建一个新服务,并让一个可运行的主机在生产中运行它,但是使用Kubernetes,他们可以在几秒或几分钟内完成这项工作。”此外,随着Kubernetes的封装和多租户功能,CPU利用率平均提高了两到三倍。
“我们看到了在Kubernetes周围成长起来的令人惊叹的社区,我们想成为其中的一分子。我们希望从增加的速度和降低的成本中获益,同时在最佳实践和工具方面与业内其他公司保持一致。” - Jai Chakrabarti,Spotify工程、基础设施和运营总监
Chakrabarti指出,Spotify关注的所有四个顶级指标 - 交付时间、部署频率、解决时间和运营负荷 - “都有Kubernetes的影响。”
Kubernetes早期的成功案例是Spotify团队基于Kubernetes开发的一个名为Slingshot的工具。“使用pull请求,它创建了一个临时登台环境,24小时后自毁。”Chakrabarti说:“这一切都是由Kubernetes促成的,所以这是一个令人兴奋的例子,说明一旦技术出现并准备好使用,人们就开始在它的基础上构建自己的解决方案,甚至超出了我们可能预想的最初目的。”
Spotify也开始使用gRPC和Envoy,取代现有的自主开发解决方案,就像它当初使用Kubernetes一样。“我们之所以创造这些东西,是因为我们当时的规模,当时没有其他解决方案。”软件工程师、基础设施和运营部门Dave Zolotusky表示:“但后来,社区有点赶上了我们,甚至超过了我们,即使是在那种规模的工具上。”
“社区帮助我们更快、更容易地使用所有的技术。它帮助我们验证我们所做的一切。” - Dave Zolotusky,Spotify基础设施和运营软件工程师
这两种技术都处于采用的早期阶段,但是“我们有理由相信gRPC将在早期开发中产生更大的影响,因为它将帮助解决许多问题,比如模式管理、API设计、奇怪的向后兼容性问题,诸如此类,”Zolotusky说:“因此,我们在这个领域依重gRPC来帮助。”
随着团队继续填充Spotify的云原生堆栈 - 接下来是跟踪 - 他们使用CNCF景观作为一个有用的指南。Zolotusky说:“我们关注我们需要解决的问题,如果有一堆项目,我们会对它们进行等价的评估,但是作为一个CNCF项目肯定是有价值的。”
Spotify迄今使用Kubernetes的经历证明了这一点。“社区帮助我们更快、更容易地使用所有的技术。”Zolotusky说:“与任何我们想联系的人取得联系,获得我们正在从事的任何事情的专业知识,都是非常容易的。它帮助我们验证我们所做的一切。”