比較 App Engine 和 Cloud Run

本指南為熟悉 App Engine 的使用者介紹 Cloud Run。本文將說明無伺服器平台的主要相似之處和差異，協助您從 App Engine 標準環境或彈性環境進行遷移。

總覽

Cloud Run 是 Google Cloud 無伺服器技術的最新演進，以十多年來執行 App Engine 的經驗為基礎。Cloud Run 與 App Engine 標準環境的基礎架構大致相同，因此這兩個平台有許多相似之處。

Cloud Run 結合了 App Engine 標準環境和 App Engine 彈性環境的多項優質功能，可以改良 App Engine 服務。Cloud Run 服務能夠處理的工作負載與 App Engine 服務相同，不過 Cloud Run 在實作這些服務時，可以為客戶提供更多彈性。這項彈性以及與 Google Cloud 和第三方服務的整合功能，也讓 Cloud Run 能夠處理 App Engine 無法執行的工作負載。

比較摘要

App Engine 和 Cloud Run 有許多相似之處，也有許多不同之處。本總覽著重於與 App Engine 客戶最相關的領域，協助他們開始使用 Cloud Run。

資源模型

Cloud Run 資源模型與 App Engine 非常相似，但有幾個主要差異：

• Cloud Run 沒有頂層的「應用程式」資源，也沒有對應的 default 服務。
• 相同專案中的 Cloud Run 服務可部署至不同區域。在 App Engine 中，專案中的所有服務都位於相同區域。
• Cloud Run 使用「修訂版本」一詞，而非「版本」，這是為了與 Knative 資源模型保持一致。
• Cloud Run 修訂版本名稱的格式為：SERVICE_NAME-REVISION_SUFFIX，其中 REVISION_SUFFIX 是自動產生，或是使用 --revision-suffix=REVISION_SUFFIX 部署旗標設定。
• Cloud Run 修訂版本是不可變動的，也就是說，您無法像使用 App Engine 版本一樣重複使用名稱 (使用 --version=VERSION_ID 部署旗標)。
• Cloud Run 服務網址是以服務 ID 為基礎，該 ID 會在首次部署服務時自動產生。服務 ID 的格式為：SERVICE_NAME-<auto-generated identifier>。服務 ID 不得重複，且在服務的整個生命週期中都不會變更。
• 在 Cloud Run 中，預設只會公開服務網址 (SERVICE_IDENTIFIER.run.app 和 https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app)。如要指定特定修訂版本，請設定流量標記。在 App Engine 中，服務和版本網址都會自動公開。

部署和設定

在 App Engine 中，大部分的設定都是在每次部署時包含的 app.yaml 中完成。這種簡化做法的代價是，雖然可以使用 Admin API 更新少數設定，但大多數變更都需要重新部署服務。

雖然 Cloud Run 有 service.yaml 設定檔，但使用方式與 app.yaml 不同。從來源部署時，無法使用 Cloud Run service.yaml，因為其中一個必要元素是最終容器映像檔的路徑。此外，service.yaml 符合 Knative 規格，對於不熟悉 Kubernetes 樣式設定檔的使用者來說，可能難以閱讀。如要進一步瞭解如何使用 service.yaml 管理設定，請參閱 Cloud Run 說明文件。

對於剛開始使用 Cloud Run 的 App Engine 客戶來說，使用 gcloud CLI 部署旗標，與 App Engine 部署時的設定管理方式更為一致。

如要在 Cloud Run 中部署新程式碼時設定設定，請使用 gcloud run deploy 旗標：

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

雖然不一定要在每次部署時使用設定標記 (請參閱「管理設定」)，但這麼做有助於簡化設定管理作業。

在 Cloud Run 中，您也可以使用 gcloud run services update 更新設定，不必重新部署原始碼：

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

由於 Cloud Run 修訂版本不可變更，這項指令會使用更新後的設定建立新修訂版本，但會使用與現有修訂版本相同的容器映像檔。

管理設定

如果是 App Engine 部署作業，所有部署作業都必須提供設定，未提供的設定會指派預設值。舉例來說，請參考下表中的 App Engine service-a，其中各版本使用 app.yaml 檔案：

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 設定為 instance_class: F4，而未提供 instance_class 值的 version2 則設定為預設的 instance_class: F1。

如果是 Cloud Run，系統會套用您提供的所有設定，但未提供的設定會保留現有值。你只需要為要變更的設定提供值。例如：

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

在 App Engine 中，如果部署時沒有設定任何配置，系統會使用所有預設設定建立版本。在 Cloud Run 中，如果部署時沒有設定，系統會使用與上一個修訂版本相同的設定建立修訂版本。如果是 Cloud Run 服務的第一個修訂版本，部署時若未設定任何設定，系統會使用所有預設設定建立修訂版本。

設定預設值

進入點

從來源部署時，App Engine 會從 app.yaml 的 entrypoint 屬性讀取進入點指令。如果未提供進入點，系統會使用執行階段專屬的預設值。從來源部署時，Cloud Run 會使用 Google Cloud 的建構包，但部分語言沒有預設進入點，因此您必須提供進入點，否則建構作業會失敗。舉例來說，Python 建構套件需要 Procfile 或指定 GOOGLE_ENTRYPOINT 建構環境變數。

如要瞭解特定語言的設定需求，請參閱建構套件說明文件。

健康狀態檢查

在 App Engine 中，健康狀態檢查作業大多由平台自動執行及管理。App Engine 會執行有效性和完備性檢查，判斷執行個體是否正常運作，以及是否準備好處理流量。如果執行個體持續未通過自動檢查，App Engine 會終止該執行個體，並換成新的執行個體，確保服務不中斷。

Cloud Run 提供更精細的控制選項，可設定啟動和有效性探測。您可以透過這些探測定義健康狀態良好的執行個體，這對複雜的微服務至關重要。

在 Cloud Run 中，您可以設定下列探查：

• 啟動探測作業可定義容器何時啟動並準備好處理流量。設定啟動探測時，系統會停用 liveness 檢查，直到啟動成功為止，確保 liveness 探測不會干擾應用程式啟動。

• 有效性探測作業會判斷何時應重新啟動容器。舉例來說，應用程式執行時若發生死結，但無法繼續運作，有效性探測就能偵測到這個問題。在這種情況下重新啟動容器，可確保應用程式在發生錯誤時仍可使用。

詳情請參閱「為服務設定容器健康狀態檢查」。

資源調度

雖然 Cloud Run 和 App Engine 標準環境共用類似的資源調度基礎架構，但 Cloud Run 經過簡化，可加快資源調度速度，並提供將資源調度率降至零的功能。因此可設定的選項較少。這項簡化作業會將可設定的項目限制為：

• 並行上限
• 執行個體數量上限和下限
• 自訂調度控制項，可設定 CPU 和並行目標使用率

根據預設，Cloud Run 執行個體的目標 CPU 使用率為 60%，但您可以自訂這個值，以達到最佳成本效益或效能。詳情請參閱「為服務設定自訂的縮放控制項」。

App Engine 彈性環境使用 Compute Engine 自動調度器，因此與 App Engine 標準環境和 Cloud Run 相比，資源調度特性差異極大。

將縮放控制項從 App Engine 遷移至 Cloud Run

本節說明如何將現有的 App Engine 縮放設定對應至 Cloud Run。

執行個體數量下限 (暖身)

將特定數量的執行個體維持在暖機狀態，以處理基準流量並避免冷啟動。

遷移策略：在服務層級設定執行個體數量下限以進行暖身。如果將流量導向特定修訂版本，修訂版本層級設定會覆寫服務層級預設值。您可以使用這項設定，先以不同的最低執行個體計數測試新修訂版本，再將其升級至正式版。

執行個體數量上限

設定執行個體總數的硬性限制，以控管費用並保護下游依附元件。

遷移策略：在服務層級設定全域限制。Cloud Run 會強制執行服務層級和修訂版本層級的較低設定。詳情請參閱「為服務設定執行個體數量上限」。

並行

定義單一執行個體的要求容量。

遷移策略：請採用下列其中一種遷移策略：

• 首先，請將 Cloud Run 執行個體容量預設值設為 80，然後執行負載測試，找出 Cloud Run 應用程式的穩定並行限制。調整這個值是在 Cloud Run 上獲得最佳效能和成本效益的有效方法。根據測試結果，將值調低至 80 以下。詳情請參閱「設定每個執行個體的並行要求數量上限」。

• 在 App Engine 標準環境中使用現有的設定值，每個執行個體預設為 10 個並行要求。這是安全的選項，因為這是應用程式已知的有效設定。不過，由於自動調度器建立的執行個體數超過處理負載所需數量，這可能會導致 Cloud Run 執行個體的使用率大幅降低，進而產生較高的費用。

CPU 使用率

在 CPU 負載超過特定門檻時進行擴充。

遷移策略：使用 --scaling-cpu-target 標記設定自訂 CPU 使用率門檻。根據預設，Cloud Run 的自動調整程式會將有效執行個體的 CPU 使用率維持在約 60%。

與 App Engine 不同，Cloud Run 只會在處理要求時分配 CPU，否則會將 CPU 節流至零。在 App Engine 標準環境中，無論您設定的資源調度類型為何，App Engine 都會確保執行個體持續有 CPU 可用。

如果應用程式會在要求之間執行任何背景工作，例如在基本或手動資源調度中使用背景執行緒，請在 Cloud Run 中設定以執行個體為準的計費方式，避免背景處理工作遭到暫停。

並行作業使用率

應用程式達到並行限制時，請根據並行使用率進行調度。

遷移策略：使用 --scaling-concurrency-target 標記定義並行作業的目標使用率門檻。根據預設，Cloud Run 自動調度器會盡量將每個執行個體的並行要求數維持在「每個執行個體的並行要求數上限」值的 60%。

設定這個值時，您會定義觸發擴充資源事件的目標處理量。

延遲時間

定義觸發擴充作業的使用者等待時間範圍。App Engine 會部分回應要求排隊。

遷移策略：Cloud Run 會在要求開始排隊和延遲時間飆升前，自動調度資源。如果發生延遲尖峰，請考慮調整每個執行個體的並行要求數量上限值，確保能更快向外擴充。

閒置執行個體

用途：在 App Engine 中，閒置執行個體設定會控管預先暖機的閒置執行個體集區，以吸收流量尖峰並控管費用。

遷移策略：您無法在 Cloud Run 中設定個別的閒置執行個體數量下限或上限。如要讓執行個體保持暖機狀態，隨時準備好處理流量，並減少 Cloud Run 中的冷啟動情形，請使用scaling.min_instance_count設定，確保系統一律會執行指定最低數量的容器。詳情請參閱「關於 Cloud Run 服務中的執行個體自動調度資源」。

閒置執行個體逾時

在 App Engine 中，閒置執行個體會在最後一個要求後，保持運作約 15 分鐘。Cloud Run 會使用帳單設定控制這項行為。

如要達到與 App Engine 類似的計費行為 (即在要求處理程序外分配 CPU)，請在 Cloud Run 中使用以執行個體為準的計費方式。

或者，您也可以使用以要求為依據的計費模式，只在要求處理期間分配 CPU。採用這項設定時，執行個體在收到最後一個要求後，仍會保持運作最多 15 分鐘，但 CPU 會在這段閒置時間內受到節流。

基本資源調度

在 App Engine 標準環境中設定 basic_scaling 設定時，系統會在收到要求時建立執行個體，並在一段時間沒有活動後將執行個體數調度為零。您可以在 Cloud Run 中使用自動調整資源配置，將 min-instances 設為 0，即可複製這項行為。

手動調整資源配置

執行固定數量的執行個體，並停用自動調度資源。

遷移策略：Cloud Run 中有手動調整規模的直接對應項目。在 Cloud Run 中，將服務層級的資源調度模式設為 MANUAL，並使用 manualInstanceCount 指定要執行的確切執行個體數量。這與完全停用自動調整功能的效果相同。詳情請參閱 Cloud Run 中的手動調整規模。

等待期

設定擴充事件發生後的等待期，之後才會發生其他事件。

遷移策略：不需要。Cloud Run 會根據需求和用量自動調度資源，並有效率地做出反應，不必手動設定冷卻期。

暖機要求

Cloud Run 會使用容器進入點指令自動預熱執行個體，因此您不需要手動啟用預熱要求或設定 /_ah/warmup 處理常式。如果您有要在執行個體啟動時執行，且在處理任何要求之前的程式碼，可以採取下列任一做法：

• 設定應用程式，以便接聽要求
• 設定自訂啟動探針

靜態內容

在 App Engine 標準環境中，您可以從 Cloud Storage 提供靜態內容，或設定處理常式，不必使用運算資源。Cloud Run 沒有提供處理常式選項，因此您只能從 Cloud Run 服務 (與動態內容相同) 或 Cloud Storage 提供內容。

Cloud Run Invoker 角色

Cloud Run 也提供使用 Identity and Access Management (IAM) 控制服務存取權的功能。服務的 IAM 政策繫結可使用 gcloud CLI、控制台或 Terraform 設定。

如要複製 App Engine 行為，您可以允許未經驗證的要求，公開服務。您可以在部署時設定，或更新現有服務的身分與存取權管理政策繫結。

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

或者，您也可以授予 Cloud Run 叫用者 IAM 角色，控管服務存取權，這項角色可針對各項服務設定。

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

環境變數和中繼資料

App Engine 和 Cloud Run 都會自動設定特定環境變數。下表列出 App Engine 環境變數，以及對應的 Cloud Run 變數。與 App Engine 相比，Cloud Run 僅實作少數環境變數，但中繼資料伺服器提供的資料大致相同。

預設環境變數

常見的中繼資料伺服器路徑

後續步驟

• 快速入門導覽課程：使用 Cloud Run 部署網路服務
• 我的應用程式是否適合 Cloud Run？
• 將 App Engine 自訂網域遷移至 Cloud Load Balancing
• 其他資源：
  • 使用 Docker 從 App Engine 遷移至 Cloud Run (Python：程式碼研究室、影片；Java：程式碼研究室)
  • 使用建構套件將 App Engine 遷移至 Cloud Run (Python：程式碼研究室、影片；Java：程式碼研究室)