關於 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} = \left\lceil \dfrac{\left( \frac{\text{Average CPU usage per second over the past minute}}{\text{Number of CPUs per instance}} \right)}{\text{CPU target}} \right\rceil \]

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

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

  • 自動調整並行數 (ACT)：計算 1 分鐘平均要求並行數的建議執行個體數量。這個方法會使用每個執行個體的 ACT 值做為執行個體的要求並行容量，而不是設定的並行要求數量上限。當 CPU 使用率超過 90% 時，ACT 會以 1 秒為間隔，動態減少 1 個並行數。詳情請參閱「自動調整並行 (ACT)」。

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

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

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

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

向上擴充

Cloud Run 會根據需要更多執行個體的擴展驅動程式，增加執行個體數量。在執行個體數量較少時，以指標為準的自動調度機制會根據您的用量目標做出回應。

以指標為準的自動調度功能會維持目前的執行個體數量，同時讓使用率與目標值之間的差異在 10% 容許範圍內。舉例來說，如果目標為預設的 60%，當使用率維持在 54% 到 66% 之間時，執行個體數量不會變更。

當使用率超出該範圍時，以指標為準的自動調整功能會根據測得的使用量和目標重新計算執行個體數量，而非根據執行中的執行個體數量，並將結果向上取整至下一個完整執行個體。由於這項捨入作業，即使使用率仍低於目標，服務仍可向上擴充。舉例來說，如果服務需要 4.1 個執行個體才能達到目標，則會執行 5 個執行個體。

縮減

Cloud Run 的自動調度資源功能會在不再需要執行個體處理連入流量時，減少執行個體數量。以指標為準的調度機制 會根據使用率，持續調整建議的執行個體數量。只有在用量低於目標 10% 以上時，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 何時主動調度資源，請在 Google Cloud 控制台中查看 scaling_driver 欄位。如要瞭解如何查看這項指標，請參閱「設定服務的自訂調整規模控制項」。

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

如果為 Cloud Run 服務設定以執行個體為準的計費方式，請注意擴充至和從零開始的行為。

從零開始擴展。只有要求才能觸發從零開始擴充，因此如果服務未處理要求，就無法從零開始擴充。對於這類工作負載，您可以將執行個體下限設為大於 0，或在設計中加入「喚醒要求」，以便在縮減至零個執行個體後重新啟動處理程序。

將資源調度率降至零。由於執行個體的 CPU 使用率絕不會是 0%，因此查看所有 CPU 使用率會導致永遠無法縮減至零。也就是說，只有在檢查執行個體是否正在處理要求時，才能決定從一縮減為零。

服務的執行個體數量上限簡介

有時您可能會想限制可啟動的執行個體總數，以控管成本，或確保與服務使用的其他資源有更好的相容性。舉例來說，Cloud Run 服務可能與資料庫互動，但資料庫只能處理一定數量的並行開放連線。

即使您未指定上限，所有服務預設都會有執行個體數量上限。設定及監控這項限制，即可判斷服務的擴充行為和相關費用。詳情請參閱「執行個體數量上限」。

如要限制可並行啟動的執行個體總數，請使用執行個體數量上限設定，詳情請參閱「設定執行個體數量上限」。

超過執行個體數量上限

正常情況下，系統會建立新的執行個體來為修訂版本擴充資源，以處理傳入的流量負載。不過若已設定執行個體數量上限，在某些情況下，執行個體數量可能不足以應付流量負載。在這種情況下，傳入的要求會依下列方式排入佇列 (待處理)：

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

在這段時間內，如果執行個體完成處理要求，就會開始處理佇列中的待處理要求。如果在時間範圍內沒有可用的執行個體，要求就會失敗，並顯示 429 錯誤代碼。

資源調度保證

執行個體數量上限是每個修訂版本的上限，表示這個修訂版本的執行個體數量不得超過上限。

在正常情況下，Cloud Run 能夠以極快的速度水平擴展至執行個體數量上限，處理所有傳入要求或事件。不過，設定高上限並不代表修訂版本在任何時間點都能水平擴展至指定的執行個體數量。在特殊情況下，Cloud Run 可能會限制擴充作業，確保所有客戶都能享有優質服務。

因流量暴增而超出執行個體數量上限

某些情況下 (例如流量暴增或系統維護)，Cloud Run 可能會在短暫期間內，建立超過執行個體數量上限設定的執行個體。啟動的新執行個體數量可能會超過上限設定，用來取代現有執行個體，並為處理中的要求提供緩衝期。

在正常運作情況下，每週可能會幾次超過執行個體數量上限。寬限期通常最長為 15 分鐘，或最長為要求逾時設定中指定的值。這些額外執行個體會在閒置 15 分鐘後遭到終止。

如果需要大量替換，更新作業通常會分散在數分鐘或數小時內完成，但每個替換作業的額外執行個體只會在寬限期內存在。超出執行個體數量上限的執行個體通常不會超過設定上限的兩倍，但如果流量突然大幅增加，執行個體數量可能會遠遠超出上限。

負載測試時，更多執行個體會超出執行個體數量上限設定，因為系統可能會變更流量尖峰的服務位置，以保留現有工作負載的容量，這些工作負載具有持續的負載模式。

如果服務無法容許這樣的暫時行為，建議預留安全餘裕，設定較低的執行個體數量上限值。

流量分配

由於執行個體數量上限是針對各個修訂版本設定，如果服務將流量分配給多個修訂版本，服務的執行個體總數可能會超過每個修訂版本的執行個體數量上限。您可以透過「執行個體計數」指標觀察這項資訊。

部署作業

部署新修訂版本以處理 100% 的流量時，Cloud Run 會先啟動足夠的新修訂版本執行個體，再將流量導向該版本。這可減少新修訂版本部署作業對要求延遲的影響，尤其是在處理大量流量時。由於執行個體數量上限是針對各個修訂版本設定，因此在部署期間，服務的執行個體總數可能會超過每個修訂版本的執行個體數量上限。您可以透過「執行個體計數」指標觀察這項資訊。

閒置執行個體及盡可能減少冷啟動

為盡量減少冷啟動，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 限制總和。

後續步驟