Canva 工程团队最近发布了对去年 11 月宕机事件的事后分析报告，详细说明了 API 网关故障的情况以及在这次事件中汲取的教训。Canva 的首席技术官 Brendan Humphreys 承认：

Canva 的编辑器是一个单页应用程序，每天会多次部署。客户端设备通过 Cloudflare 的分层缓存系统获取新资源。然而，CDN 提供商内部的一个路由问题扰乱了两个区域之间的流量。因此，当资源在 CDN 上可用时，所有客户端同时开始下载。这导致了流量的突然激增，超过 27 万个待处理请求同时进行。Humphreys 解释道：

“通常情况下，错误数量增加会使我们的金丝雀测试系统中止部署。但在这次事件中，由于请求没有完成，所以没有记录到错误。结果，超过 27 万用户对 JavaScript 文件的请求都在同一缓存流中等待。”

图注：Canva API 网关架构，来源：Canva 工程博客

爱彼迎（Airbnb）的软件工程师 Lorin Hochstein，同时也是《冲浪复杂性》（Surfing Complexity）博客的作者，将这次宕机事件描述为一个关于负载饱和和系统弹性的故事。Hochstein 强调：

突然间，所有等待中的设备同时加载新的对象面板，导致 API 网关每秒收到超过 150 万个请求，流量激增幅度约为典型峰值负载的三倍。这股巨大的流量浪潮使负载均衡器变成了 “过载均衡器”，将原本健康的节点拖垮。Hochstein 补充道：

由于自动缩放机制未能跟上流量变化，API 网关任务因内存耗尽开始出现故障，最终导致整个系统完全崩溃。为解决这一问题，Canva 团队试图手动增加容量，同时降低节点负载，但效果参差不齐。当在 CDN 层完全阻断流量后，情况才终于得到缓解。Humphreys 详细说道：

接着 Canva 的工程师们逐步增加流量，大约 20 分钟后完全恢复了服务。在 HackerNews 热门讨论帖中，John Nagle 评论道：

虽然系统最初满足了所有功能需求，但自动化系统却加剧了问题的严重性。Hochstein 指出：

Humphreys 在领英（LinkedIn）上总结道：

为最大程度降低未来发生类似事件的可能性，该团队着重改进了事故响应流程，包括制定流量阻断和恢复的操作手册，以及增强 API 网关的弹性。

Renato Losio，Renato 作为云架构师、技术主管和云服务专家，拥有丰富的经验。目前，他居住在柏林，担任首席云架构师开展远程工作。他主要感兴趣的领域包括云服务和关系型数据库。他是 InfoQ 的编辑，也是经过认证的 AWS Data Hero。

https://www.infoq.com/news/2025/02/canva-incident-report/