本頁說明 Cloud Run 的預設自動調度資源行為。如要進一步控管資源調度行為,請瞭解替代的資源調度選項:手動資源調度。
根據預設,每個 Cloud Run 修訂版本都會自動調整所需執行個體數量,以處理所有傳入要求、事件或 CPU 使用率。
如果修訂版本未收到任何流量,預設會縮減為零個執行個體。不過,如有需要,您可以變更這項預設值,使用「最少量執行個體」設定指定要保持閒置或「暖機」狀態的執行個體。如果您在要求以外使用 CPU,應將最低執行個體數設為 1
。
除了傳入要求、事件或 CPU 使用率之外,排定的執行個體數量也會受到下列因素影響:
- 現有執行個體在一分鐘時間範圍內的平均 CPU 使用率,目標是將排程執行個體的 CPU 使用率維持在 60%。
- 目前的要求並行數,目標是在一分鐘的時間範圍內,將執行個體並行數維持在並行數上限的 60%。
- 執行個體數量上限設定
- 執行個體數量下限設定
Cloud Run 自動調整程式會定期評估這些指標。
以執行個體為準的計費和自動調度資源
如果您為 Cloud Run 服務設定以例項為準的計費方式,請注意擴充至和從零開始的行為。
從零開始擴展。只有要求才能觸發從零開始的擴充作業,因此如果服務未處理要求,就無法從零開始擴充。對於這類工作負載,您可以將執行個體下限設為大於 0,或在設計中加入「喚醒要求」,以便在縮減至零個執行個體後重新啟動處理程序。
將資源調度率降至零。由於執行個體的 CPU 使用率永遠不會是 0%,因此查看所有 CPU 使用率會導致系統永遠不會縮減至零。也就是說,只有在檢查執行個體是否正在處理要求時,才能決定是否要將執行個體數從一縮減為零。
關於執行個體數量上限
在某些情況下,您可能會基於成本控管考量,或為了與服務使用的其他資源更相容,而限制可啟動的執行個體總數。舉例來說,Cloud Run 服務可能與資料庫互動,而該資料庫只能處理特定數量的並行開放連線。
如要限制可並行啟動的執行個體總數,請使用執行個體數量上限設定,詳情請參閱「設定執行個體數量上限」。
超過執行個體數量上限
在正常情況下,修訂版本會建立新的執行個體進行擴充,以處理外來流量負載。不過,如果您設定了執行個體數量上限,在某些情況下,執行個體數量可能不足以因應流量負載。在這種情況下,傳入的要求會排入佇列 (待處理),如下所示:
要求會暫緩處理,時間最多為這項服務容器執行個體平均啟動時間的 3.5 倍,或 10 秒 (以較長者為準)。
在這段時間內,如果執行個體完成處理要求,就會可用於處理佇列中的待處理要求。如果期間內沒有執行個體可用,要求就會失敗,並傳回 429
錯誤代碼。
資源調度保證
上限執行個體限制是每個修訂版本的上限,表示這個修訂版本的執行個體數量不得超過上限。
在一般情況下,Cloud Run 能夠非常快速地擴充至執行個體上限,以便處理所有傳入要求或事件。不過,設定高限制並不代表修訂版本在任何時刻都能擴充至指定的執行個體數量。在特殊情況下,Cloud Run 可能會限制擴充作業,確保所有客戶都能享有優質服務。
因流量暴增而超出執行個體數量上限
在某些情況下 (例如流量迅速增加或系統維護),Cloud Run 可能會在短暫期間內,建立超出上限執行個體設定的執行個體。啟動的新執行個體數量可以超過上限設定,用來取代現有執行個體,並為處理中的要求提供緩衝期。
在正常運作情況下,每週可能會幾次超過執行個體數量上限。寬限期通常最長為 15 分鐘,或最長為要求逾時設定中指定的值。這些額外執行個體會在閒置 15 分鐘後遭到終止。
如果需要大量替換,更新作業通常會持續數分鐘或數小時,但每個替換作業只會在寬限期內有額外執行個體。超出執行個體上限的值通常不會超過設定的執行個體上限限制兩倍,但如果流量突然大幅暴增,則可能超出許多。
負載測試時,更多執行個體會超出執行個體上限設定,因為系統可能會變更流量尖峰的服務位置,以保留現有工作負載的容量,這些工作負載具有持續的負載模式。
如果服務無法承受這樣的臨時行為,可以考慮採用安全餘裕,設定較低的上限執行個體值。
流量分配
由於上限執行個體限制是針對各個修訂版本設定,如果服務將流量分配給多個修訂版本,服務的執行個體總數可能會超過每個修訂版本的上限執行個體數。您可以在「Instance Count」(執行個體計數) 指標中觀察這個情形。
部署作業
部署新的修訂版本來處理 100% 的流量時,Cloud Run 會先啟動足夠的新修訂版本執行個體,再將流量導向這些執行個體。這項功能可減少新修訂版本部署作業對要求延遲的影響,特別是在處理大量流量時。由於執行個體數量上限是針對每個修訂版本設定,因此在部署期間,服務的執行個體總數可能會超過每個修訂版本的執行個體數量上限。您可以在「Instance Count」(執行個體計數) 指標中觀察這個情形。
閒置執行個體及盡可能減少冷啟動
Cloud Run 不會在處理完所有要求後立即關閉執行個體。為盡可能降低冷啟動的影響,Cloud Run 最多會讓部分執行個體閒置 15 分鐘。啟用 GPU 的 Cloud Run 資源最多會讓部分執行個體閒置 10 分鐘。這類執行個體可在流量突然激增時處理要求。
例如執行個體完成處理要求,可能會維持閒置狀態一段時間,以免需要處理其他要求。閒置執行個體可能會持續佔用資源,例如開放資料庫連線。請注意,除非您明確將服務設定為以執行個體為依據的計費模式,否則預設的計費模式為以要求為依據的計費模式。
如要永久保留閒置執行個體,請使用 min-instance
設定。請注意,即使服務未主動處理要求,使用這項功能仍會產生費用。
自動調度資源和待處理要求
要求會暫緩處理,時間最多為這項服務容器執行個體平均啟動時間的 3.5 倍,或 10 秒 (以較長者為準)。
自動調度資源對後端服務的影響
隨著執行個體數量自動增加,Cloud Run 服務可能會遇到後端服務的限制。舉例來說,Cloud SQL 有 API 配額限制。 請確保這些後端服務有足夠的配額,且能處理來自 Cloud Run 服務所有執行個體的連線。建議設定執行個體數量上限,以免後端服務過載。
自動調度資源和 Pub/Sub
Google 建議使用推播訂閱,從 Cloud Run 的 Pub/Sub 主題取用訊息。容器會像接收 HTTP 要求一樣接收推送訊息,因此會觸發相同的自動調度行為。
自動調度資源和多個容器 (Sidecar)
Cloud Run 會考量執行個體的 CPU 使用率來自動調度資源,其中執行個體的 CPU 使用率是指已用 CPU 占已分配 CPU 的百分比。
請注意,在容器層級設定 CPU 限制時,您會分配 CPU。如果您在每個執行個體中使用多個容器,該執行個體的實際 CPU 分配量就是您為每個容器設定的 CPU 限制總和。
後續步驟
- 如要瞭解其他調度選項,請參閱手動調度。
- 如要管理 Cloud Run 服務的執行個體數量上限,請參閱設定執行個體數量上限。
- 如要管理每個執行個體處理的並行要求數量上限,請參閱設定並行。
- 如要最佳化並行設定,請參閱調整並行的開發提示。
- 如要指定要保持執行的閒置執行個體,盡量縮短延遲時間或減少首次要求時的冷啟動次數,請參閱使用
min-instance
啟用閒置執行個體。