GitHub、自动缩放和组件替换谬误

在昨天关于最近 GitHub 宕机的文章中，文中有一个细节我没有提及：Istio sidecar 饱和的服务的自动缩放策略。最初，这是由于 Istio sidecar pod 达到其并发限制并且无法正确自动缩放而导致的，因为配置错误的策略监视主机服务而不是 sidecar 限制。我怀疑本博客的读者熟悉自动缩放是什么及其工作原理，但这里有一个简短的摘要，以防您不熟悉。服务所需的计算和内存资源量取决于该服务的负载。这里的相关负载源是针对服务的外部请求，也称为流量。交通量随时间变化。例如，对于像 GitHub 这样的公司，我的猜测是他们在工作时间的流量比晚上和周末更多。鉴于负载动态变化，并且服务所需的计算和内存资源是负载的函数，因此有两种通用策略。一种策略是为峰值负载配置服务。另一种策略是根据服务的当前负载动态调整分配给服务的资源；这就是所谓的自动缩放。如果您希望服务使用自动缩放，则需要定义自动缩放策略。特别是，您需要选择要使用哪些指标来表示负载，然后需要根据该指标的变化指定如何添加或删除资源。 CPU 利用率是用于自动缩放的常用指标。但请注意，即使 CPU 较低，服务也可能会饱和。例如，想象一个场景，您在线程池中使用每个请求线程，并且下游请求的延迟增加，并且池中的所有线程最终都被阻塞。这里的服务已经饱和，你可以从启动新的 pod 中受益，但 CPU 实际上很低，因为线程在等待 I/O 时被阻塞（这种情况早在 2021 年就发生在 Slack 上）。现在，您可以向自动缩放策略添加额外的规则来处理此类情况（这就是 Slack 所做的，它们根据线程数量快速扩展）。或者，如果您的服务不受 CPU 限制，您可以根据传入请求量而不是 CPU 进行扩展。根据 GitHub 的文章，听起来受影响服务的自动缩放策略使用的负载指标仅考虑了服务本身的负载，而不考虑 Istio sidecar 上的负载。一般来说，每个服务在负载下的行为都不同，这意味着每个自动缩放策略都是有效定制的。这意味着拥有服务的团队不仅负责业务逻辑，还负责具有自定义参数的操作控制系统，而这些参数实际上只能通过负载测试来检查。 （您是否对所有服务进行负载测试？）服务所有者几乎肯定也不是自动扩展专家。因此，配置错误的自动扩展策略是造成这种情况的原因，我并不感到惊讶。但是，虽然我认为值得讨论该政策的特定缺陷，因为人们意识到自动扩展的风险是有好处的，但我也认为太容易关注它而排除与此事件有关的其他因素。这就是 David Woods 所说的元件替代谬误——提高可靠性的方法是集中精力识别和修复有缺陷的元件。是的，虽然您应该识别并修复事件中发现的缺陷，但您还应该认识到：这意味着组件缺陷不足以使您的系统瘫痪，否则您的系统现在就会瘫痪。不要只关注单个组件：将交互视为一流的。在 GitHub 中断中，我们看到了对各种因素之间相互作用的讨论，例如：更改流量模式（包括抓取工具）、自动缩放策略、Istio sidecar 饱和度、重试逻辑、HAProxy 节点饱和度和身份验证流量。还有很多细节我们不知道，因为这是一篇快速传播的公开文章，好的内容只能在内部文章中找到。我在这篇文章中推测了服务所有者和自动缩放策略之间的关系，但我很想了解更多有关这里的历史的信息（例如，该策略是否早于 Istio sidecar 的使用？）。我也想更多地了解有问题的交通。 （他们是什么类型的请求？是突然增加还是逐渐增加？我们知道流量增加的原因吗？）。您无法在公共事件报道中获得此类问题的答案，但您可以在自己组织的内部问题中获得答案。由你来提出问题。