筆記。 翻譯。：8月初，紅帽公開談論解決其服務用戶在前幾個月遇到的無障礙問題 （它基於容器鏡像註冊表，該公司在購買 CoreOS 時收到了該鏡像）。無論您對這項服務本身感興趣如何，該公司的 SRE 工程師診斷和消除事故原因所採取的路徑都是有啟發性的。
19 月 XNUMX 日凌晨（東部夏令時間，EDT），quay.io 服務崩潰。這次事故影響了 quay.io 消費者和使用 quay.io 作為建構和分發軟體平台的開源專案。紅帽非常重視雙方的信任。
SRE工程師團隊立即介入，試圖盡快穩定Quay服務。然而，當他們這樣做時，客戶失去了推送新映像的能力，並且只有偶爾才能拉取現有映像。由於某種未知原因，quay.io 資料庫在將服務擴展到滿容量後被阻止。
«發生了什麼變化？「 - 這是在這種情況下通常會問的第一個問題。我們注意到，在問題發生前不久，OpenShift Dedicated 叢集（運行 quay.io）開始更新到版本 4.3.19。由於 quay.io 在 Red Hat OpenShift Dedicated (OSD) 上運行，因此定期更新是例行公事，從來不會造成問題。此外，在過去的六個月裡，我們對 Quay 叢集進行了多次升級，沒有出現任何服務中斷。
當我們嘗試復原服務時，其他工程師開始使用先前版本的軟體準備一個新的 OSD 集群，以便在出現問題時可以在其上部署所有內容。
根本原因分析
故障的主要症狀是數以萬計的資料庫連線雪崩，導致 MySQL 執行個體實際上無法運作。這使得診斷問題變得困難。我們對客戶端的最大連線數設定了限制，以幫助 SRE 團隊評估問題。我們沒有註意到資料庫有任何異常流量：事實上，大多數請求都是讀取的，只有少數請求是寫入的。
我們也嘗試識別資料庫流量中可能導致這種雪崩的模式。但是，我們在日誌中找不到任何模式。在等待 OSD 4.3.18 的新叢集準備就緒時，我們繼續嘗試啟動 quay.io pod。每次叢集達到滿載時，資料庫就會凍結。這意味著除了所有 quay.io Pod 之外，還需要重新啟動 RDS 執行個體。
到了晚上，我們將服務穩定在唯讀模式，並禁用了盡可能多的非必要功能（例如命名空間垃圾收集），以減少資料庫的負載。凍結已經停止 但一直沒有找到原因。新的 OSD 叢集已準備就緒，我們遷移了服務、連接了流量並繼續進行監控。
Quay.io 在新的 OSD 叢集上穩定工作，因此我們返回資料庫日誌，但找不到可以解釋阻塞的相關性。 OpenShift 工程師與我們合作，了解 Red Hat OpenShift 4.3.19 中的變更是否會導致 Quay 出現問題。然而什麼也沒發現，而且 在實驗室條件下無法重現問題.
第二次失敗
28 月 XNUMX 日，美國東部時間中午前不久，quay.io 再次崩潰，症狀相同：資料庫被阻止。我們再次全力投入調查。首先，需要恢復服務。然而 這次重新啟動 RDS 並重新啟動 quay.io pod 沒有執行任何操作：另一場雪崩般的連結已經壓垮了基地。但為什麼？
Quay 是用 Python 編寫的，每個 Pod 都作為一個整體容器運作。容器運行時同時運行許多並行任務。我們使用圖書館 gevent 下 gunicorn 處理網路請求。當請求進入 Quay（透過我們自己的 API，或透過 Docker 的 API）時，它會被指派一個 gevent Worker。通常，該工作人員應該聯絡資料庫。第一次失敗後，我們發現 gevent 工作人員正在使用預設設定連接到資料庫。
鑑於 Quay Pod 數量龐大且每秒有數千個傳入請求，理論上，大量資料庫連線可能會壓垮 MySQL 執行個體。透過監控，Quay 平均每秒處理 5 個請求。資料庫連線數大致相同。 5 個連線完全在我們的 RDS 實例的能力範圍內（不能說是數萬個）。 由於某種原因，連接數出現意外峰值但是，我們沒有註意到與傳入請求有任何關聯。
這次我們決心找到並消除問題的根源，而不是局限於重啟。到 Quay 程式碼庫 進行了更改以限制每個工作人員與資料庫的連接數量 事件。這個數字成為配置中的一個參數：可以動態更改它，而無需建立新的容器映像。為了找出實際上可以處理多少連接，我們在臨時環境中運行了多次測試，設定不同的值以了解這將如何影響負載測試場景。結果發現 當連線數超過 502 時，Quay 開始拋出 10 錯誤。
我們立即將這個新版本部署到生產中，並開始監控資料庫連線計畫。過去，基地在大約20分鐘後就被封鎖。經過 30 分鐘的無憂無慮後，我們有了希望，一個小時後，我們有了信心。我們恢復了網站的流量並開始事後分析。
設法繞過導致阻塞的問題， 我們還沒有找到其真正原因。經確認，這與 OpenShift 4.3.19 中的任何更改無關，因為版本 4.3.18 上也發生了相同的情況，該版本之前與 Quay 配合使用沒有任何問題。
顯然，集群中還潛藏著其他東西。
詳細研究
Quay.io 使用預設設定連接資料庫六年沒有出現任何問題。發生了什麼變化？很明顯，quay.io 上的流量一直在穩定成長。在我們的例子中，看起來好像已經達到了某個閾值，這會觸發大量連接。第二次失敗後，我們繼續研究資料庫日誌，但沒有發現任何模式或明顯的關係。
同時，SRE 團隊一直致力於改善 Quay 的請求可觀察性和整體服務運作。 已部署新的指標和儀表板，顯示碼頭的哪些部分最受顧客歡迎。
Quay.io 在 9 月 XNUMX 日之前運作良好。今天早上（美國東部時間），我們再次看到資料庫連線數量顯著增加。 這次沒有停機，因為新參數限制了它們的數量並且不允許它們超過 MySQL 的吞吐量。然而，在大約半小時的時間裡，許多用戶注意到 quay.io 的效能緩慢。我們使用新增的監控工具快速收集了所有可能的數據。突然出現了一種模式。
就在連線激增之前，向 AppRegistry API 發出了大量請求。應用程式註冊表是 quay.io 的一個鮮為人知的功能。它允許您儲存諸如 Helm 圖表和具有豐富元資料的容器之類的內容。大多數 quay.io 用戶不使用此功能，但 Red Hat OpenShift 積極使用它。 OperatorHub 作為 OpenShift 的一部分，將所有運算子儲存在應用程式登錄中。這些操作員構成了 OpenShift 工作負載生態系統和以合作夥伴為中心的操作模型（第 2 天操作）的基礎。
每個 OpenShift 4 叢集都使用內建 OperatorHub 中的 Operator 來發布可供安裝的 Operator 目錄，並為已安裝的 Operator 提供更新。隨著OpenShift 4的日益普及，全球其上的群集數量也隨之增加。每個叢集都會下載 Operator 內容來執行內建的 OperatorHub，並使用 quay.io 內的應用程式登錄檔作為後端。 在尋找問題根源的過程中，我們忽略了一個事實：隨著 OpenShift 逐漸流行，很少使用的 quay.io 功能之一的負載也隨之增加。.
我們對應用程式註冊表請求流量進行了一些分析，並查看了註冊表代碼。缺點立即暴露出來，因為資料庫的查詢沒有以最佳方式形成。當負載較低時，它們不會造成任何麻煩，但當負載增加時，它們就會成為問題的根源。應用程式註冊表結果有兩個有問題的端點，它們不能很好地響應不斷增加的負載：第一個端點提供了存儲庫中所有包的列表，第二個端點返回了包的所有 blob。
消除原因
在接下來的一周裡，我們花了很多時間優化應用程式註冊表本身的程式碼及其環境。明顯無效的 SQL 查詢被重新設計，不必要的命令呼叫被消除 tar （每次檢索 blob 時都會運行），盡可能新增快取。然後，我們進行了廣泛的效能測試，並比較了更改前後應用程式註冊表的速度。
以前需要半分鐘的 API 請求現在只需幾毫秒即可完成。下週我們將更改部署到生產中，從那時起 quay.io 一直穩定運行。在此期間，應用程式註冊表端點上的流量出現了幾次急劇峰值，但所做的改進避免了資料庫中斷。
我們學到了什麼？
顯然，任何服務都試圖避免停機。就我們而言，我們相信最近的中斷有助於使 quay.io 變得更好。我們吸取了一些重要的經驗教訓並願意與大家分享：
- 有關誰使用您的服務以及如何使用您的服務的數據永遠不會是多餘的。因為 Quay“正常工作”，所以我們無需花時間優化流量和管理負載。所有這些都造成了一種錯誤的安全感，認為服務可以無限擴展。
- 當服務故障時， 讓它恢復並運行是當務之急。。由於 Quay 在第一次中斷期間繼續遭受資料庫鎖定的困擾，因此我們的標準程序沒有達到預期效果，我們無法使用它們恢復服務。這導致了這樣一種情況：必須花時間分析和收集數據，以期找到根本原因，而不是集中精力恢復功能。
- 評估每個服務功能的影響。客戶很少使用應用程式註冊表，因此這不是我們團隊的優先事項。當某些產品功能很少被使用時，它們的錯誤很少出現，開發人員就會停止監控程式碼。人們很容易陷入這樣的誤解，認為事情本來就該如此——直到突然間，該功能發現自己成為了重大事件的中心。
接下來是什麼？
確保服務穩定性的工作從未停止，我們也不斷改進。隨著 quay.io 上的流量持續成長，我們認識到我們有責任盡一切努力不辜負客戶的信任。因此，目前我們正在進行以下工作：
- 部署唯讀資料庫副本，以協助服務在主 RDS 執行個體出現問題時處理適當的流量。
- 更新RDS實例。目前版本本身不是問題。相反，我們只是想刪除錯誤的痕跡（我們在失敗期間遵循的痕跡）；保持軟體最新將消除未來發生中斷時的另一個因素。
- 整個叢集的額外快取。我們繼續尋找快取可以減少資料庫負載的領域。
- 新增 Web 應用程式防火牆 (WAF) 以查看誰連接到 quay.io 以及原因。
- 從下一個版本開始，紅帽 OpenShift 叢集將放棄應用程式註冊表，轉而使用基於 quay.io 上提供的容器映像的操作員目錄。
- 應用程式註冊表的長期替代可能是對開放容器計劃 (OCI) 工件規範的支援。它目前作為本機 Quay 功能實現，並將在規範本身最終確定後提供給使用者。
上述所有內容都是紅帽對 quay.io 持續投資的一部分，因為我們正在從小型「新創」團隊轉變為成熟的 SRE 驅動平台。我們知道，我們的許多客戶在日常工作中都依賴 quay.io（包括紅帽！），我們會盡力對最近的中斷和持續的改進工作保持透明。
譯者PS
另請閱讀我們的博客：
- «“;
- «“;
- «“。
來源： www.habr.com