Canva 工程團隊最近釋出了對去年 11 月宕機事件的事後分析報告，詳細說明了 API 閘道器故障的情況以及在這次事件中汲取的教訓。Canva 的首席技術官 Brendan Humphreys 承認：
“2024 年 11 月 12 日，Canva 遭遇了一次嚴重的宕機事故，影響了 canva.com 的正常訪問。從 UTC 時間上午 9 點 08 分至大約 10 點，canva.com 都無法訪問。此次事故是由我們的 API 閘道器叢集故障導致的，多個因素共同作用引發了這一故障，包括 Canva 編輯器的一次軟體部署、鎖機制問題，以及我們的內容分發網路（CDN）提供商 Cloudflare 的網路問題。”
Canva 的編輯器是一個單頁應用程式，每天會多次部署。客戶端裝置透過 Cloudflare 的分層快取系統獲取新資源。然而，CDN 提供商內部的一個路由問題擾亂了兩個區域之間的流量。因此，當資源在 CDN 上可用時，所有客戶端同時開始下載。這導致了流量的突然激增，超過 27 萬個待處理請求同時進行。Humphreys 解釋道：
“通常情況下，錯誤數量增加會使我們的金絲雀測試系統中止部署。但在這次事件中，由於請求沒有完成，所以沒有記錄到錯誤。結果，超過 27 萬用戶對 JavaScript 檔案的請求都在同一快取流中等待。”
圖注：Canva API 閘道器架構，來源：Canva 工程部落格
愛彼迎（Airbnb）的軟體工程師 Lorin Hochstein，同時也是《衝浪複雜性》（Surfing Complexity）部落格的作者，將這次宕機事件描述為一個關於負載飽和和系統彈性的故事。Hochstein 強調：
“這次事件並非由新版本程式碼中的漏洞引發，甚至也不是由該版本程式碼中某些意外的突發行為導致的。雖然這次事件是由一次部署引發的，但與前一版本的程式碼變更並無關聯。實際上，是客戶端下載新版本後出現的系統行為導致了宕機。”
突然間，所有等待中的裝置同時載入新的物件面板，導致 API 閘道器每秒收到超過 150 萬個請求，流量激增幅度約為典型峰值負載的三倍。這股巨大的流量浪潮使負載均衡器變成了 “過載均衡器”，將原本健康的節點拖垮。Hochstein 補充道：
“這是一個典型的正反饋迴圈例子：出現故障的任務越多，健康節點接收的流量就越大，這些任務也就越有可能出現故障。”
由於自動縮放機制未能跟上流量變化，API 閘道器任務因記憶體耗盡開始出現故障，最終導致整個系統完全崩潰。為解決這一問題，Canva 團隊試圖手動增加容量，同時降低節點負載，但效果參差不齊。當在 CDN 層完全阻斷流量後，情況才終於得到緩解。Humphreys 詳細說道：
“UTC 時間上午 9 點 29 分，我們在 Cloudflare 上添加了一條臨時防火牆規則，在 CDN 層阻斷了所有流量。這阻止了任何流量到達 API 閘道器，使新任務能夠啟動，而不會被湧入的請求壓垮。隨後，我們將 canva.com 重定向到狀態頁面，以便讓使用者清楚地瞭解我們正在遭遇故障。”
接著 Canva 的工程師們逐步增加流量，大約 20 分鐘後完全恢復了服務。在 HackerNews 熱門討論帖中，John Nagle 評論道：
“這個問題類似於電力公司所說的‘負載吸收’。停電後恢復供電時，許多裝置在啟動時會消耗更多電力。（……）因此，恢復電網供電要分割槽進行，而不是一次性全部恢復。”
雖然系統最初滿足了所有功能需求，但自動化系統卻加劇了問題的嚴重性。Hochstein 指出：
“這就需要事故響應人員調整系統行為，改變其執行方式，使系統恢復到正常狀態。（……）這是系統彈性的一個經典案例，即在系統進入非設計執行狀態時，採取行動重新配置其行為。”
Humphreys 在領英（LinkedIn）上總結道：
“在 Cloudflare 能力出眾且樂於助人的合作伙伴協作下，我們花了一些時間才弄清楚事件全貌。（……）這是一個引人入勝的故事，涉及資料包丟失、快取動態變化、流量激增、執行緒爭用和任務餘量等問題。”
為最大程度降低未來發生類似事件的可能性，該團隊著重改進了事故響應流程，包括制定流量阻斷和恢復的操作手冊，以及增強 API 閘道器的彈性。
Renato Losio，Renato 作為雲架構師、技術主管和雲服務專家，擁有豐富的經驗。目前，他居住在柏林，擔任首席雲架構師開展遠端工作。他主要感興趣的領域包括雲服務和關係型資料庫。他是 InfoQ 的編輯，也是經過認證的 AWS Data Hero。
原文連結：
https://www.infoq.com/news/2025/02/canva-incident-report/
本文由 InfoQ 獨家翻譯，未經授權不得轉載。
