關於 Cloud Run 服務中的執行個體自動調度

本頁說明 Cloud Run 的預設自動調度資源行為。如要使用其他資源調度選項，設定特定執行個體數量，請參閱「手動調整資源配置」。

根據預設，每個 Cloud Run 修訂版本都會自動調整為所需的執行個體數量，以處理傳入要求、事件或 CPU 使用率。您也可以設定自訂 CPU 和使用率目標，微調這項調度行為。

如果修訂版本未收到任何流量，預設會縮減為零個執行個體。您可以變更這項預設值，使用最少執行個體設定指定要保持閒置或「暖機」的執行個體。如果服務在未處理要求時仍會使用 CPU，請將最小執行個體數設為 1。

Cloud Run 自動調度器會定期評估下列指標，判斷處理流量所需的執行個體數量：

  • CPU 和並行使用率：Cloud Run 會調整執行個體數量，將平均 CPU 和並行控制在目標門檻內。

  • 執行個體限制：Cloud Run 會將執行個體數量限制在您設定的上限和下限之間。

服務自動水平調度資源行為

Cloud Run 有兩種自動調度資源機制：以指標為準的資源調度和隨選資源調度，可判斷服務流量所需的執行個體數量。

以指標為準的資源調度

系統會根據平均 CPU 使用率和平均要求並行數調度資源，自動調整執行個體數量，為 Cloud Run 服務提供穩定的服務容量。

自動調度器會根據下列各項調度資源驅動程式獨立計算出的執行個體數量上限，決定建議的執行個體數量：

  • CPU 使用率：計算執行個體數量時，會先計算 1 分鐘內每秒的平均 CPU 使用率，然後除以每個執行個體的 CPU 數量。這個結果會再除以 CPU 目標。計算公式如下：

\[ \text{Instances} = \dfrac{\left( \frac{\text{Average CPU usage per second over the past minute}}{\text{Number of CPUs per instance}} \right)}{\text{CPU target}} \]

  • 要求並行：計算執行個體數量時，會先計算 1 分鐘和 10 分鐘內每秒的要求並行數平均值，然後除以並行數上限。這項結果會再除以要求並行目標。計算公式如下：

\[ \text{Instances} = \dfrac{\left( \frac{\max(\text{average concurrent requests over 1 minute, 10 minutes})}{\text{Maximum concurrency}} \right)}{\text{Concurrency target}} \]

您可以為每個服務修訂版本設定每個執行個體的 CPU 數量和並行上限。

Cloud Run 不支援根據記憶體使用率進行資源調度。

根據預設，以指標為準的資源調度會將 CPU 使用率和要求並行目標的門檻設為 60%。您可以選擇啟用資源調度控制項 (搶先版)，指定自訂 CPU 或並行目標。

Cloud Run 根據 CPU 使用率調整規模時，會考量分配給執行個體的所有 CPU 平均使用率。如果應用程式是單一執行緒，但部署在多 CPU 執行個體上，可能會導致平均使用率讀取值偏低，進而影響 CPU 基礎的擴縮決策。如要進一步瞭解如何為應用程式架構調整 CPU 設定，請參閱「設定 CPU 限制」和「為每個執行個體設定並行要求上限」。

向上擴充

Cloud Run 會根據需要更多執行個體的調度驅動程式，增加執行個體數量。

Cloud Run 會將修訂版本的目標使用率設為 60%，但如果執行個體數量較少，自動配置器可能會等待較長時間才進行調度。

您可以選擇啟用調度控制項 (搶先版)，改用更高精度的自動調度資源模型，讓 Cloud Run 根據您設定的目標，密切回應以指標為準的自動調度資源，即使服務的執行個體數量較少也適用。如果服務與自訂目標設定的差異超過 10% 的容許閾值，Cloud Run 會建議所需執行個體數量，以將觸發自動調度的調度驅動程式降至目標以下。

縮減

Cloud Run 的自動調度資源功能會在不再需要執行個體處理連入流量時，減少執行個體數量。以指標為準的資源調度功能會根據使用率，持續調整建議的執行個體數量。

當平均 CPU 使用率或平均有效要求減少時，自動調度演算法會減少建議的執行個體數量。Cloud Run 要求負載平衡器會優先將傳入要求轉送至建議的執行個體，藉此考量這些建議。這會讓建議的執行個體更忙碌，其他執行個體則會閒置。Cloud Run 會降低這些不建議使用的執行個體數量，方法是降低優先順序，因此只有在所有建議的執行個體都忙碌時，這些執行個體才會接收流量。為維持穩定性，Cloud Run 會依下列順序關閉優先順序較低的執行個體：

  1. 如果執行個體群組在 1 分鐘內的用量低於 10%，Cloud Run 就會關閉該群組。
  2. 第二組執行個體會持續運作，直到閒置逾時 15 分鐘為止，確保在流量突然暴增時仍有可用容量。

如果服務在未處理要求時也會執行其他工作 (例如執行背景執行緒或處理非同步工作)，您應將最低執行個體數設為至少 1，確保 CPU 仍會分配給背景處理作業。

視需求調度資源

如果找不到可處理傳入要求的可用執行個體，Cloud Run 就會使用隨選資源調度。當 Cloud Run 修訂版本上的傳入流量或修訂版本的延遲時間發生變化時，系統會即時做出回應，這項調度機制會盡量確保每個傳入要求都能在短時間內轉送至執行個體。只有視需求調度資源，才能從零開始調度資源。不過，從 N 個執行個體調度資源時，系統會根據先觸發的條件，透過指標或隨選調度資源來處理流量。

由於隨選調整功能會即時因應流量的突然變化，Cloud Run 會管理冷啟動延遲時間 (啟動新執行個體所需的時間) 與待處理佇列延遲時間 (要求等待現有執行個體開啟時段的時間) 之間的取捨。對於每項要求，系統會先判斷排入即將推出的執行個體或現有執行個體佇列是否較快 (依此順序)，再嘗試啟動新的隨需執行個體。要求在待處理佇列中最多會停留 10 秒，或預測冷啟動時間的 3.5 倍 (以較長者為準)，之後系統就會觸發新的隨選執行個體。

自動調整並行工作數量上限 (ACT)

Cloud Run 會使用適應性並行調整 (ACT)，防止 CPU 節流導致要求延遲時間過長。這個方法會測量每個執行個體在特定要求數量的 CPU 使用率，並動態調整執行個體的並行要求數量上限值，讓 CPU 使用率維持在 90% 以下。ACT 會根據下列情境調整並行作業：

  • 如果過去 1 秒的 CPU 使用率超過 90%，ACT 就會將執行個體的並行要求上限調降 1。

  • 如果執行個體達到並行要求上限，且 CPU 使用率在 1 秒內維持在 70% 以下，ACT 會將執行個體的並行要求上限增加 1。

  • 如果擴充指標顯示並行數從未達到設定上限，可能是因為 ACT 動態降低實際上限，以保護執行個體效能。

Cloud Run 會計算每個部署作業的 ACT 值。這些指標不會在部署作業之間保留。如果 ACT 將並行數降至偏好層級以下，請增加每個並行要求上限分配的 CPU。如果背景工作會導致 CPU 定期飆升，也可能會干擾這種擴充方法。無法觀察 ACT 指標。

以執行個體為依據的計費和自動調度資源

如果為 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 可能會在執行個體處理完要求後，讓執行個體閒置一段時間 (最多 15 分鐘，GPU 則為 10 分鐘)。

閒置執行個體可能會持續佔用資源，例如開放資料庫連線。請注意，除非您明確將服務設定為以執行個體為依據的計費模式，否則預設的計費模式為以要求為依據的計費模式。

如要永久保留閒置執行個體，請使用 min-instance 設定。請注意，即使服務未主動處理要求，使用這項功能仍會產生費用。

自動調度資源和待處理要求

要求最多會等待這項服務的容器執行個體平均啟動時間的 3.5 倍，或 10 秒 (以較長者為準)。

自動調度資源對後端服務的影響

隨著執行個體數量自動增加，Cloud Run 服務可能會遇到後端服務的限制。舉例來說，Cloud SQL 有 API 配額限制。 請確保這些後端服務有足夠的配額，且能處理來自 Cloud Run 服務所有執行個體的連線。建議設定執行個體數量上限，以免後端服務過載。

自動調度資源與 Pub/Sub

Google 建議使用推播訂閱，從 Cloud Run 的 Pub/Sub 主題取用訊息。容器會像接收 HTTP 要求一樣接收推送訊息，因此會觸發相同的自動調度行為。

自動調度資源和多個容器 (側車)

Cloud Run 會考量執行個體的 CPU 使用率來自動調度資源，其中執行個體的 CPU 使用率是指已使用的 CPU 占已分配 CPU 的百分比。

請注意，在容器層級設定 CPU 限制時，您會分配 CPU。如果您在每個執行個體中使用多個容器，該執行個體的實際 CPU 分配量就是您為每個容器設定的 CPU 限制總和。

後續步驟