GitLab.com怎么了?这是关于它稳定性的最新数据


这篇文章的灵感来自于this comment on Reddit,感谢我们提高了GitLab.com的稳定性。谢谢,铁石心肠!让GitLab.com为您的任务关键型工作负载做好准备已经有一段时间了,很高兴听到用户注意到了不同之处。

请注意,此帖子中的数字与Reddit帖子中的数字略有不同,因为自那篇帖子以来数据发生了变化。

我们将继续努力提高平台的可用性和稳定性。我们目前的目标是在GitLab.com上达到99.95%的可用性--关注即将发布的关于我们计划如何实现这一目标的帖子。

GitLab.com迁移前后的稳定性

根据Pingdom,GitLab.com今年到目前为止的可用性,直到迁移99.68 percent,这相当于平均每周约32分钟的停机时间。

自从迁移以来,我们的可用性有了很大的提高,尽管我们需要比较的数据比Azure少得多。

使用从Pingdom公开获得的数据,以下是今年到目前为止我们的可用性的一些统计数据:

这是个好消息:我们的停机次数减少了。这对我们的可用性意味着什么,我们是否正在实现99.95%的目标?

平均停机时间从每周32分钟下降到每周13分钟,这意味着我们在迁移到Google Cloud平台后,可用性提高了61%。

性能

迁移后GitLab.com的性能如何?

业绩可能很难衡量。特别值得一提的是,平均数是衡量业绩的糟糕方式,因为它们忽略了异常值。测量性能的较好方法之一是使用延迟直方图。为此,我们将7月(Azure)和9月(Google Cloud Platform)的GitLab.com访问日志导入到Google BigQuery,然后选择每月最受欢迎的100个端点,并将其归类为api、web、git、长轮询或静电端点。通过并排比较这些直方图,我们可以研究迁移以来GitLab.com的性能发生了怎样的变化。

在此直方图中,左侧的值越高表示性能越好。图形的右侧是“尾巴,和把尾巴弄胖一点“,用户体验就越差。

Kubernetes

然而,还有许多其他原因与我们云提供商的变化无关,因为这些对稳定性和性能的改进。

“我们之所以选择谷歌云平台,是因为我们相信谷歌为我们的工作负载提供了最可靠的云平台。”

与任何大型SaaS站点一样,GitLab.com是一个庞大而复杂的系统,很难将可用性更改归因于单个更改,但以下几个因素可能会影响我们的可用性和性能:

原因1:我们的吉塔利舰队在GCP上比以前强大得多

Gitaly负责GitLab应用程序中的所有Git访问。在Gitaly之前,Git访问是直接从Rails工作人员内部进行的。由于我们的规模,我们需要许多服务器为Web应用程序提供服务,因此,为了在所有工作人员之间共享GIT数据,我们依赖NFS卷。不幸的是,这种方法没有很好的伸缩性,这导致我们构建了Gitaly,一个专门的Git服务。

“我们已经选择对我们的24台Gitaly服务器进行认真升级。”

我们升级后的吉塔利舰队

作为迁移的一部分,我们选择将我们的24人机队Gitaly服务器进行了一次重大升级。如果旧的车队相当于一辆漂亮的家庭轿车,那么新的车队就像一群咆哮的军车,随时准备为你的Git物品服务。

我们新的吉塔利舰队要强大得多。这意味着Gitaly可以更快地响应请求,更好地处理意外流量激增。

IO性能

正如你可能想象的那样,服务于225TB of Git data对于每周大约50万活跃用户而言,这是一项相当繁重的IO操作。我们对此所做的任何性能改进都将对GitLab.com的整体性能产生重大影响。

出于这个原因,我们也将重点放在了提高性能上。

这如何转化为现实世界的表现呢?以下是我们的Gitaly机队的平均读写时间:

以下是我们来自蔚蓝和GCP的吉塔利舰队的一些比较数字。在每种情况下,GCP的性能都比Azure好得多,尽管这是我们在考虑到更强大的舰队时所期望的。

注意:供参考:对于Azure,它使用故障转移前一周的平均时间。对于GCP,这是截至2018年10月2日的一周的平均水平。

这些统计数据清楚地表明,我们的新群集比我们的旧群集具有更好的IO性能。Gitaly的性能高度依赖于IO性能,所以这是个好消息,对解释我们看到的性能改进有很大帮助。

原因2:较少的“独角兽工作进程饱和”错误

独角兽员工饱和听起来像是一件好事,但事实并非如此!

我们(currently)依赖于unicorn,Ruby/Rack http服务器,用于服务大部分应用程序。独角兽使用单线程模型,该模型使用固定的工作进程池。每个工作者一次只能处理一个请求。如果工作进程在60秒内没有响应,它将被终止,并产生另一个进程来替换它。

“独角兽员工饱和听起来像是一件好事,但事实并非如此!”

此外,当我们遇到高负载量时,缺乏自动缩放技术来提升机队,这意味着gilab.com拥有相对静电大小的员工池来处理传入的请求。

RPCs这通常只需要几毫秒,可能需要几秒钟的时间才能做出反应-比平时慢数千倍。向独角兽车队发出的与速度较慢的服务器通信的请求所需的时间将比预期的长数百倍。最终,大多数机群都在处理对受影响的后端服务器的请求。这会导致影响所有传入交通的队列,这有点像繁忙高速公路上的尾随,因为单个下匝道上的交通堵塞造成的。

如果请求排队时间过长(大约60秒后),请求将被取消,从而导致503错误。这是不加区别的-所有请求,无论它们是否与受影响的服务器交互,都将被取消。这就是我所说的独角兽员工饱和,这是一件非常糟糕的事情。

在今年2月至8月期间,我们经常经历这种现象。

我们采取了几种方法来处理这个问题:

  • 通过激进的超时和断路器快速失败:超时意味着当Gitaly请求预计需要几毫秒时,它们会在一秒后超时,而不是等待请求在60秒后超时。虽然某些请求仍将受到影响,但群集总体上仍将保持健康状态。Gitaly目前不使用断路器,但我们计划添加此功能,可能使用Istio一旦我们搬到库伯内斯。
  • 更好的滥用检测和限制:通常情况下,服务器负载高峰是由违反我们的公平使用策略的用户推动的。我们建立了更好的工具来更好地检测这一点,在过去的几个月里,已经成立了一个虐待小组来处理这一问题。有时,负载是通过巨大的存储库驱动的,我们正在努力恢复公平使用限制,以防止100 GB的Git存储库影响我们的整个团队。
  • 并发控制和速率限制:为了限制爆炸半径,速率限制器(主要在HAProxy中)和并发限制器(在Gitaly中)降低过度热心的用户的速度,以保护整个车队。

原因#3:GitLab.com不再使用NFS进行任何Git访问

9月初,我们在整个员工群中禁用了Git NFS挂载。这是可能的,因为Gitaly已经达到了1.0版:在这一点上,它已经足够完整了。您可以在我们的Road to Gitaly blog post

原因4:移民是减少债务的机会

这次迁移对我们来说是一个极好的机会,可以改善我们的基础设施,简化一些组件,或者让GitLab.com更稳定、更容易观察,例如,我们已经推出了新的结构化日志记录基础设施。

作为迁移的一部分,我们利用这个机会将大部分日志记录转移到结构化日志。我们使用fluentd,Google Pub/Sub,Pubsubbeat,将我们的日志存储在Elastic CloudGoogle Stackdriver Logging。有了可靠的索引日志,我们可以缩短检测事件的平均时间,特别是检测滥用情况的平均时间。这一新的日志记录基础设施在检测和解决几个安全事件方面也发挥了不可估量的作用。

“这一新的日志记录基础设施在检测和解决几个安全事件方面也发挥了无价的作用。”

我们还专注于使我们的试运行环境与我们的生产环境更加相似。这允许我们在将更改投入生产之前,更准确地在试运行中测试更多更改。以前,该团队维护的是一个有限的缩减试运行环境,许多更改在推出之前没有经过充分测试。我们的环境现在共享一个通用配置,我们正在努力实现所有环境的自动化TerraformChef卷展栏。

原因#5:流程更改

不幸的是,我们在过去几年中经历的许多最严重的停机都是自己造成的。我们在这些问题上一直是透明的--并将继续如此--但随着我们的快速发展,我们的流程必须与我们的系统和团队一起进行扩展,这一点很重要。

为了解决这个问题,在过去的几个月里,我们已经将我们的变更和事件管理流程正规化。这些流程分别帮助我们避免停机,并在确实发生停机时更快地解决它们。

如果您有兴趣了解更多关于我们对这两个重要学科采取的方法,请参阅我们的手册:

原因6:应用程序改进

每个GitLab版本都包括performance and stability improvements;其中一些对GitLab的稳定性和性能产生了很大影响,特别是n+1问题。

“n”)来满足单个请求。

假设有一个虚构的端点,它向Gitaly查询存储库上的所有标签,然后为每个标签发出额外的查询以获取更多信息。这将导致n+1个Gitaly查询:一个用于初始标记,然后n用于标记。这种方法对于有10个标签的项目很有效-发出11个请求,但是对于有1000个标签的项目,这将导致1001个Gitaly调用,每个调用都有一个往返时间,并按顺序发出。

使用来自Pingdom的数据,此图表显示了自今年年初以来的长期业绩趋势。很明显,在2018年5月7日,延迟有了很大的改善。这一日期恰好与GitLab 10.8的RC1发布以及其在GitLab.com上的部署一致。

事实证明,这是由于single fix on n+1 on the merge request page being resolved

在开发或测试模式下运行时,GitLab现在可以检测n+1种情况,我们已经编译a list of known n+1s。随着这些问题的解决,我们预计会有更多的性能改进。

原因#7:基础设施团队的成长和重组

2018年5月初,负责GitLab.com的基础设施团队由五名工程师组成。

从那以后,我们有一位新主管加入了基础架构团队,两位新经理,一位专家Postgres DBRESREs。数据库团队已经重组,成为基础设施组的嵌入部分。我们还请来了Ongres,一家专业的Postgres咨询公司,与团队一起工作。

团队中有足够的人员,使我们能够将时间分配给随叫随到、战术改进和长期战略工作。

哦,我们还在招人呢!如果您感兴趣,请查看our open positions并选择基础设施团队!

  1. GitLab.com更加稳定:自从我们迁移到GCP以来,可用性提高了61%
  2. GitLab.com速度更快:迁移后延迟有所改善
  3. 我们完全专注于继续这些改进,我们正在组建一支伟大的团队来做到这一点

最后一件事:我们的Grafana仪表板是开放的,所以如果您有兴趣更详细地了解我们的指标,请访问dashboards.gitlab.com去探索吧!