故障周第二弹：谷歌云平台全局负载均衡服务发生中断

Posted 2021-04-15 架构头条

编辑 | 无明，张婵

本周故障频发，前脚亚马逊Prime Day出了点问题，后脚谷歌云平台发生网络事故。

美国当地时间 7 月 17 日中午 12 点 17 分，谷歌云平台遭遇服务故障，全局负载距衡器 (Global Load Balancer，GLB) 返回 502 状态码，Google Cloud, App Engine 以及 Stackdriver 等依赖云 HTTP 负载均衡的服务均受到影响。Snapchat，Pokemon Go 和 Spotify 等使用谷歌云服务的流行应用程序和站点也受到影响。

在事故发生约 28 分钟，谷歌工程团队找到了事故原因，并开始部署修复程序。在 12:55，服务已经完全恢复。截止 13:05，问题已经解决，所有受影响的用户服务都恢复了正常。

7 月 19 日，谷歌云平台官方发布了事故分析报告，阐述了问题始末和事故原因，用户补偿以及预防措施。以下是谷歌云平台的分析报告：

问题概要

本周二，也就是 2018 年 7 月 17 日，谷歌云应用引擎（Google Cloud App Engine）、谷歌 HTTP(S) 负载均衡器或 TCP/SSL 代理负载均衡器的用户经历了长达 32 分钟的故障，他们分别收到了 33％至 87％不等的错误率。用户可以看到 502 状态码或连接被重置的错误。对于在此次事件中服务或业务受到影响的用户，我们深表歉意。与此同时，我们正在采取措施改善平台的性能和可用性。我们也将为受该事件影响的用户提供 SLA 补偿。

事件细节

太平洋时间 2018 年 7 月 17 日 12 点 17 分到 12 点 49 分，一些发送到谷歌云 HTTP(s) 负载均衡器的请求返回了 502 状态码。在此期间，返回的 502 状态码的比例从 33％到 87％不等。自动监控系统在 12 点 19 分向谷歌工程团队发出告警。12 点 44 分，工程团队找到了可能的根本原因，并部署了修复程序。12 点 49 分，修复生效，502 错误率迅速恢复到正常水平。伴随着流量回升和缓存逐渐起效，服务经历了几分钟的降级延迟。12 点 55 分，服务完全恢复，与云 TCP/SSL 代理负载均衡器的连接被重置。依赖云 HTTP 负载均衡的云服务（如谷歌云应用引擎应用程序服务、谷歌云 Function、Stackdriver Web UI、Dialogflow 和 Cloud Support Portal/API）在事件期间均受到影响。

由于位于云 HTTP(s) 负载均衡器后面的服务对云 CDN URL 的引用减少，以及无法更新过时的缓存条目或在缓存未命中时插入新的内容，云 CDN 缓存的命中率下降了 70％。于是，运行在谷歌 Kubernetes 引擎上并使用 Ingress 资源的服务返回了 502 状态码。通过云负载均衡器提供服务的谷歌云存储的流量也受到了影响。

其他的谷歌云平台服务未受影响。例如，直接使用 VM 或网络负载均衡的应用程序和服务不受影响。

根本原因

谷歌的全局负载均衡器是基于双层架构的谷歌前端（Google Front End，GFE）而构建的。GFE 的第一层负责响应就近用户的请求，以便在建立连接期间最大限度地提高性能。这些 GFE 将请求路由到距离目标服务最近的第二层 GFE。这种架构可以降低客户端的连接延迟，同时可以利用谷歌的全球网络将请求发送给后端，不管它们位于哪个区域。

GFE 开发团队正在为 GFE 添加新的特性，用以提升安全性和性能。这些特性已经被引入到第二层 GFE 的代码库中，但尚未投入使用。其中有一个特性包含了一个会导致 GFE 重启的 bug，这个 bug 在测试和首次部署中未被检测出来。在事件刚发生时，生产环境中的一个配置变更会间歇性地触发这个 bug，导致受影响的 GFE 反复重启。由于重启无法在瞬间完成，第二层 GFE 的可用容量就减少了。虽然一部分请求得到了正确的响应，但也有一部分请求被中断（连接被重置）或由于等待 GFE 重新上线而被拒绝服务。

补救和预防

谷歌工程师在 3 分钟内收到告警，并立即着手调查原因。太平洋夏令时间 12 点 44 分，工程团队发现了根本原因，并迅速回滚了配置变更，受影响的 GFE 停止了重启。随着所有 GFE 恢复服务，流量也恢复到正常水平。

除了修复问题之外，我们还将通过以下几项措施来防止和减少此类故障的影响：

• 我们正在添加额外的安全措施来禁用不在使用中的功能。

• 我们计划加强 GFE 的测试栈，降低二进制文件中可能包含会导致任务重启的 bug 的风险。

• 我们还将对 GFE 池的不同分片进行额外的隔离，以减少故障的影响范围。

• 最后，为了加快诊断速度，我们计划为 GFE 池创建配置变更仪表盘，让工程师可以更轻松、更快地查看、关联和识别有问题的系统变更。

对于此次事件对用户及其业务造成的影响，我们再次深表歉意。对于影响服务可用性和可靠性的事件，我们都非常重视，尤其是跨地区的事故。我们正在对事件进行彻底的调查，并将调查结果作为 GCP 工程的首要参考。

有网友说，谷歌出问题几乎等于互联网瘫痪，这很有趣，也很可怕。的确，在云计算时代，我们能以更低廉的成本更灵活地利用云中的各种资源，但是一旦“云”出了故障，就会牵一发而动全身，造成大范围的影响。对于故障，只能尽量降低发生率，谁又能完全避免出现故障呢？

近期大规模故障回顾：

---

活动推荐

8 月 18 日，InfoQ 将举办一场面向技术人的区块链大会！超过二十个区块链落地案例，区块链前沿技术剖析，区块链生态、服务盘点和解读，尽在 BCCon2018！点击查看原文进入大会官网了解更多信息。