在雲端運算技術快速演進的時代,企業面臨著如何有效運用雲端資源的重要課題。Google Cloud Platform (GCP) 作為全球主要的雲端服務供應商之一,提供了多樣化的無伺服器運算服務(Serverless Computing Services)選項。其中,Cloud Run 和 App Engine 是兩個被廣泛採用的服務,各自具有不同的特性和應用場景。
而在微服務架構(Microservices Architecture)盛行的現今,系統往往需要部署數十個甚至上百個微服務,而每個服務的啟動時間(Cold Start Time)都會直接影響整體系統的反應速度。因此服務啟動效能的優劣會影響使用者體驗(UX)及系統可用性(Availability)。
因此,針對此部分我們花時間去研究 Cloud Run 與 App Engine 喚醒時間差異。此篇文章會具體描述我們如何做這個POC實驗以及會有一個初步的結論。
當開發Web應用時,選擇 Cloud Run 或 App Engine 作為服務部署平台時,冷啟動時間是評估效能的一個關鍵指標。本實驗旨在比較 Cloud Run 與 App Engine 在冷啟動時間上的差異,提供選擇依據。
冷啟動時間指的是當新的容器實例被創建並首次處理請求所需的時間,包括以下幾個階段:
接著稍微幫大家過一下GCP的 App Engine 和 Cloud Run Serverless服務。
App Engine 是 GCP 的全託管無伺服器平台即服務(PaaS),讓開發者專注於程式開發,無需管理底層基礎設施。具有一下特性
Cloud Run 是 GCP 提供的無伺服器平台,專為容器化應用設計,適用於高靈活性需求的工作負載。
支援容器化工作流程:Cloud Run 支援任何符合開放容器標準(OCI)的容器映像,開發者可以使用熟悉的編程語言和工具將應用程式容器化後部署。
高靈活性:根據實際需求自動調整資源,適合多種場景,如處理 HTTP 請求、事件驅動應用程式和批次處理作業等。
計費方式:依照實際使用的 CPU 和記憶體資源計費,並且只有在應用程式處理請求時才會產生費用,非常具有成本效益。
兩者都屬於無伺服器(Serverless)解決方案,但針對使用情境和靈活性有所差異:
開發模式:App Engine 適合不想花時間管理基礎設施的開發者,提供完整的 PaaS 體驗;Cloud Run 更靈活,支援所有可容器化的應用程式。
支援語言:App Engine 對支援的語言和框架有一定限制,Cloud Run 則可以支援任何容器化的語言或技術棧。
擴展能力:兩者都能自動擴展,但 Cloud Run 更適合快速啟動和停止的應用場景。
計費模式:App Engine 是基於應用的資源使用情況計費,而 Cloud Run 則根據實際資源消耗計費,通常在處理間歇性工作負載時更具成本效益。
以上稍微對實驗背景與服務有一個基礎認知後,接著進入實驗設置
為了有效比較 Google Cloud Run 和 Google App Engine 在冷啟動時間上的差異,我們設計了以下具體的實驗流程與測試方法,並確保實驗環境和變數的可控性,以提高結果的可靠性和可重現性。
我們選擇使用 .NET API Service 作為測試應用,主要因為它能夠滿足以下條件:
開發了一個簡單的 API,能夠接收 HTTP 請求並回傳簡單的訊息(如 "Hello, World!" 或時間戳記),以便輕鬆測量每次請求的反應時間。
實驗使用了多個不同類型的容器映像,以評估基底映像對冷啟動時間的影響:
編譯部分使用兩種不同的編譯方式來建構映像,以進一步探討編譯方式對啟動時間的影響:
為了精確比較 Cloud Run 和 App Engine 的冷啟動時間,我們設計了多層次的自動化測試流程,使用常見的工具和腳本來獲取並分析數據。以下是具體的測試方法:
測試流程:使用 curl 發送 HTTP 請求到部署在 Cloud Run 和 App Engine 的 API,並記錄每個請求的回應時間。
資料點:每個請求都包含發送時間和接收回應的時間,curl 內建的計時功能能夠提供詳細的 DNS、TCP 連接、TLS 握手和整體回應時間。
編寫一個 Bash 腳本 來自動化請求過程,具體功能如下
腳本範例
Cloud Run 表現出穩定的冷啟動時間,但相較於 App Engine 數值略高,適合彈性需求高且對啟動時間不那麼敏感的應用。 Runtime-deps 映像的啟動時間普遍較短,而 SDK 映像的時間則略有延長。
針對 App Engine 的冷啟動問題,可透過 Warmup Requests 和最小實例設定來優化效能,在 app.yaml 中配置 warmup 設定,提前預熱實例,減少冷啟動帶來的延遲。並調整 min_instances 參數確保一定數量的實例持續運行,並使用 max_concurrent_requests 來平衡資源分配和響應速度。
或是可以使用排程喚醒,使用 Cloud Scheduler 定期喚醒 API 是簡單且有效的優化方法,特別適合低流量應用,能顯著降低冷啟動時間。定期向 API 發送請求,保持應用程序活躍,尤其適用於低流量但啟動時間敏感的應用場景。
實驗結果表明,Cloud Run 和 App Engine 各有優勢,企業需根據應用場景選擇最佳方案,權衡效能與成本。
App Engine 的冷啟動時間顯著短於 Cloud Run,適合對延遲敏感的應用。
Cloud Run 的計費模式更加靈活,對於處理間歇性工作負載來說更具經濟性,特別適合短時間內啟停的應用程序。
選擇 App Engine:如果應用需要穩定的性能且對啟動時間極為敏感,App Engine 的預熱設置與最小實例管理將是合適的選擇。若應用流量波動較大,且需要具備高度靈活性,Cloud Run 能提供更低的運行成本,尤其在間歇性負載中更具優勢。
這樣的選擇策略能夠讓企業在效能與成本之間取得良好平衡,並提升系統的總體效率。