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

Cloud Run 自動調度資源功能會調整各服務修訂版本的容器執行個體數量，以因應傳入要求、事件和 CPU 使用率。視需求調度執行個體資源，可協助服務處理流量高峰，並在閒置時將資源調度率降至零，降低成本。

您可以設定自訂 CPU 和並行目標，以及設定執行個體數量下限和上限，藉此調整自動調度資源門檻。如果服務在處理要求以外的時間使用 CPU，請將執行個體數量下限設為至少 1。如要執行固定數量的執行個體，請參閱「手動調度資源」。

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

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 週期性尖峰的背景工作，也可能干擾這種調度資源方式。

您可以在 Google Cloud 控制台中查看 scaling_driver 欄位，監控 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 要求一樣接收推送訊息，因此會觸發相同的自動調度資源行為。

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

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

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

後續步驟