公司VSCO 位置奥克兰 行业照片手机应用程序

挑战

后从RackspaceAWS在2015年,VSCO开始建造node . js微服务除了运行它PHP庞然大物.该团队使用容器化了微服务码头工人,但“他们都在不同的组。EC2机器学习团队工程经理Melinda Lu表示。社区团队的高级软件工程师Naveen Gattu补充道:“这产生了大量浪费的资源。我们开始寻找一种方法来整合AWS EC2实例,并提高效率。”

解决方案

该团队开始探索调度系统的想法,并在决定采用之前研究了包括Mesos和Swarm在内的几种解决方案Kubernetes.VSCO也使用gRPC特使在他们的云原生堆栈中。

影响

在此之前,部署需要“大量的手动调整,我们编写的内部脚本,而且由于我们完全不同的EC2实例,运营部门不得不从头到尾照看整个事情,”高级软件工程师Brendan Ryan说。“我们并没有以系统的方式进行测试,也没有以标准化的方式使用可重复使用的容器或建筑。”现在有一个更快的入职流程。在此之前,首次部署需要两天的实际安装时间;现在是两个小时。通过转向持续集成、容器化和Kubernetes,速度得到了显著提高。对于一个典型的服务,从完成代码到在实际基础设施上部署到生产环境的时间从一到两周到两到四个小时。Gattu补充道:“在工时上,这是一个人与一个开发人员和一个DevOps个人同时进行。”在生产中,单次部署的时间减少了80%,部署的数量也从每年1200次增加到每年3200次。这也确实节省了一些钱:有了Kubernetes, VSCO的EC2效率提高了2 - 20倍,这取决于服务,总计节省了约70%的EC2账单。 Ryan points to the company's ability to go from managing one large monolithic application to 50+ microservices with "the same size developer team, more or less. And we've only been able to do that because we have increased trust in our tooling and a lot more flexibility, so we don't need to employ a DevOps engineer to tune every service." With Kubernetes, gRPC, and Envoy in place, VSCO has seen an 88% reduction in total minutes of outage time, mainly due to the elimination of JSON-schema errors and service-specific infrastructure provisioning errors, and an increased speed in fixing outages.

VSCO是一款手机摄影应用,于2011年诞生于云端。一开始,“我们使用Rackspace,使用一个单独的PHP应用程序与MySQL数据库通信,使用FTP部署,没有容器化,没有编排,”软件工程师Brendan Ryan说,“这在当时就足够了。”

2015年,VSCO进入AWS,其用户基础超过3000万,该团队很快意识到这种设置将不再有效。开发人员已经开始构建一些Node和Go微服务,团队尝试用Docker进行容器化。但是机器学习团队的工程经理Melinda Lu说:“它们都是单独的EC2实例组,每个服务都有专用的EC2实例。”社区团队的高级软件工程师Naveen Gattu补充道:“这产生了大量浪费的资源。我们开始寻找一种在EC2实例中巩固和提高效率的方法。”

在决定使用Kubernetes之前,这个团队评估了一些调度解决方案,包括Mesos和Swarm。“Kubernetes似乎拥有最强大的开源社区,”Lu说。此外,“我们已经开始标准化很多谷歌栈,以Go作为语言,gRPC用于数据中心内我们自己的服务之间的几乎所有通信。所以我们很自然地选择了Kubernetes。”

当时,在生态系统中很少有可管理的Kubernetes产品,可用的工具也很少,因此该团队建立了自己的集群,并构建了一些定制组件来满足其特定的部署需求,比如用于canary部署的自动进入控制器和策略构造。“我们已经开始拆分这个庞然大物,所以我们一个一个地转移业务,从非常小的、低风险的服务开始,”Lu说。“每一项新服务都部署在那里。”第一个服务是在2016年底迁移的,一年后,整个堆栈的80%都在Kubernetes上,包括其他的整体。

影响是巨大的。部署过去需要“大量的手动调整和我们编写的内部脚本,而且由于我们不同的EC2实例,运营部门不得不从头到尾照看整个事情,”Ryan说。“我们并没有以系统的方式进行测试,也没有以标准化的方式使用可重复使用的容器或建筑。”现在有一个更快的入职流程。在此之前,首次部署需要两天的实际安装时间;现在是两个小时。

通过转向持续集成、容器化和Kubernetes,速度得到了显著提高。对于一个典型的服务,从完成代码到在实际基础设施上部署到生产环境的时间从一到两周到两到四个小时。另外,Gattu说,“在工时上,这是一个人与一个开发人员和一个DevOps个人同时进行。”在生产中,单次部署的时间减少了80%,部署的数量也从每年1200次增加到每年3200次。

这也确实节省了一些钱:有了Kubernetes, VSCO的EC2效率提高了2 - 20倍,这取决于服务,总计节省了约70%的EC2账单。

Ryan指出,该公司有能力在“差不多相同规模的开发团队”下,从管理一个大型单片应用程序到管理50多个微服务。我们之所以能够做到这一点,是因为我们增加了对工具的信任,当系统中有压力点时,我们有了更多的灵活性。你可以增加一个服务的CPU内存需求,而不需要打开和关闭实例,也不需要阅读AWS页面来熟悉很多术语,这对我们这样的规模的公司来说是行不通的。”

特使和gRPC也对VSCO产生了积极影响。“我们从gRPC中获得了很多开箱式的好处:跨多种语言的类型安全,gRPC IDL中定义服务的便捷性,内置的架构如拦截器,以及HTTP/1.1和JSON的性能改进,”Lu说。

VSCO是“特使”的首批用户之一,它在开源5天后就投入生产。“我们希望通过边缘负载均衡器将gRPC和HTTP/2直接提供给移动客户端,而Envoy是我们唯一合理的解决方案,”Lu说。“在所有服务中默认发送一致和详细的统计数据的能力使得仪表板的可观察性和标准化变得容易得多。”特使内置的指标也“极大地帮助了调试,”DevOps工程师Ryan Nguyen说。

随着Kubernetes、gRPC和Envoy的到位,VSCO的总停机时间减少了88%,这主要是由于消除了json模式错误和特定于服务的基础设施配置错误,并提高了修复停机的速度。

鉴于在CNCF项目上取得的成功,VSCO开始与其他公司进行试验,其中包括CNI经过和普罗米修斯。Nguyen说:“为了有一个支持这些技术的大型组织,我们更有信心尝试这种软件并将其部署到生产中。”

这个团队为gRPC和Envoy做出了贡献,并希望在CNCF社区中更加活跃。“看到我们的工程师通过结合大量Kubernetes的原始设计,想出了真正有创意的解决方案,我真的很感动,”Lu说。“将Kubernetes结构作为一种服务公开给我们的工程师,而不是公开更高阶的结构,这对我们来说很有效。它让你熟悉这项技术,用它做更多有趣的事情。”