# Cloud Run vs App Engine 喚醒時間差異

在雲端運算技術快速演進的時代，企業面臨著如何有效運用雲端資源的重要課題。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 在冷啟動時間上的差異，提供選擇依據。

冷啟動時間指的是當新的容器實例被創建並首次處理請求所需的時間，包括以下幾個階段：

1. 網路處理（如 DNS 和 TLS handshake）
2. 冷啟動時間
3. 伺服器處理時間

接著稍微幫大家過一下GCP的 App Engine 和 Cloud Run Serverless服務。

### App Engine 與 Cloud Run

App Engine 是 GCP 的全託管無伺服器平台即服務（PaaS），讓開發者專注於程式開發，無需管理底層基礎設施。具有一下特性

- 全託管無伺服器 PaaS：App Engine 自動處理伺服器配置、負載平衡和安全性，開發人員只需專注於部署應用程式。
- 自動擴展：根據流量和需求，自動調整資源配置，以確保應用程式在高負載時仍能順暢運行，並在低負載時節省資源成本。
- 版本控制：支援同時部署多個應用版本，可以設定流量分配到不同版本，以便進行金絲雀部署（Canary Deployment）或 A/B 測試。
- 執行模式：分為標準環境和彈性環境，標準環境適合輕量級和短時間執行的應用程式，彈性環境則適合需要更多系統資源及長時間執行的應用。

Cloud Run 是 GCP 提供的無伺服器平台，專為容器化應用設計，適用於高靈活性需求的工作負載。

- 支援容器化工作流程：Cloud Run 支援任何符合開放容器標準（OCI）的容器映像，開發者可以使用熟悉的編程語言和工具將應用程式容器化後部署。

- 高靈活性：根據實際需求自動調整資源，適合多種場景，如處理 HTTP 請求、事件驅動應用程式和批次處理作業等。

- 計費方式：依照實際使用的 CPU 和記憶體資源計費，並且只有在應用程式處理請求時才會產生費用，非常具有成本效益。

兩者都屬於無伺服器（Serverless）解決方案，但針對使用情境和靈活性有所差異：

1. 開發模式：App Engine 適合不想花時間管理基礎設施的開發者，提供完整的 PaaS 體驗；Cloud Run 更靈活，支援所有可容器化的應用程式。

2. 支援語言：App Engine 對支援的語言和框架有一定限制，Cloud Run 則可以支援任何容器化的語言或技術棧。

3. 擴展能力：兩者都能自動擴展，但 Cloud Run 更適合快速啟動和停止的應用場景。

4. 計費模式：App Engine 是基於應用的資源使用情況計費，而 Cloud Run 則根據實際資源消耗計費，通常在處理間歇性工作負載時更具成本效益。

以上稍微對實驗背景與服務有一個基礎認知後，接著進入實驗設置

## 實驗設置與測試方法

為了有效比較 Google Cloud Run 和 Google App Engine 在冷啟動時間上的差異，我們設計了以下具體的實驗流程與測試方法，並確保實驗環境和變數的可控性，以提高結果的可靠性和可重現性。

### 設計與準備階段

我們選擇使用 .NET API Service 作為測試應用，主要因為它能夠滿足以下條件：

- 常見且易於容器化
- 支援 AOT 和 JIT 編譯方式，以便比較不同編譯策略對冷啟動時間的影響

開發了一個簡單的 API，能夠接收 HTTP 請求並回傳簡單的訊息（如 "Hello, World!" 或時間戳記），以便輕鬆測量每次請求的反應時間。

### 映像檔建構與優化

1. 映像類型與差異

實驗使用了多個不同類型的容器映像，以評估基底映像對冷啟動時間的影響：

- SDK 映像：包含完整的 .NET 開發工具和運行環境，適合開發階段，能執行編譯與測試工作。
- Runtime 映像：僅包含運行 .NET 應用程序所需的基礎環境，去除了開發工具，適合正式運行應用。
- Runtime-deps 映像：最精簡的映像，僅保留應用程序的最低依賴項，旨在最小化映像大小和冷啟動時間。

### 編譯策略

編譯部分使用兩種不同的編譯方式來建構映像，以進一步探討編譯方式對啟動時間的影響：

- AOT (Ahead-of-Time) 編譯：將代碼在構建過程中編譯成機器代碼，這樣可以減少執行時的編譯時間，有利於加快啟動速度。
- JIT (Just-in-Time) 編譯：在應用執行時進行動態編譯，這種方法較為靈活，但冷啟動時間通常較長。

### 測試方法

為了精確比較 Cloud Run 和 App Engine 的冷啟動時間，我們設計了多層次的自動化測試流程，使用常見的工具和腳本來獲取並分析數據。以下是具體的測試方法：

1. 使用 curl 獲取回應時間

- 測試流程：使用 curl 發送 HTTP 請求到部署在 Cloud Run 和 App Engine 的 API，並記錄每個請求的回應時間。

- 資料點：每個請求都包含發送時間和接收回應的時間，curl 內建的計時功能能夠提供詳細的 DNS、TCP 連接、TLS 握手和整體回應時間。

2. 撰寫 Bash 腳本自動收集數據

- 編寫一個 Bash 腳本 來自動化請求過程，具體功能如下
- 循環發送多次 curl 請求到目標 API，以便收集冷啟動與重複請求的數據。
- 將每次測試的回應時間和相關細節（如時間戳和回應狀態碼）保存到一個 CSV 文件中，以方便後續分析。

腳本範例

    #!/bin/bash
    URL="https://your-api-url"
    OUTPUT_FILE="response_times.csv"
    echo "Timestamp,ResponseTime" > $OUTPUT_FILE

    for i in {1..100}; do
        START_TIME=$(date +%s%3N)
        RESPONSE=$(curl -o /dev/null -s -w "%{time_total}" $URL)
        END_TIME=$(date +%s%3N)
        TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
        echo "$TIMESTAMP,$RESPONSE" >> $OUTPUT_FILE
        sleep 10  # 每隔10秒發送一次請求，模擬不同的冷啟動情境
    done

3. 使用 crontab 排程定時測試，進行定時測試，模擬不同時段的冷啟動情況，確保測試涵蓋多種情境（如高負載與低負載時段）。

## 實驗結果 (請貼圖)

### Cloud Run 測試結果
- **樣本數**：200次
- **平均回應時間**：約1秒
- **數據統計圖**：箱形圖顯示不同映像類型的冷啟動時間變化。

### App Engine 測試結果（彈性模式）
- **樣本數**：200次
- **平均回應時間**：約0.2秒
- **數據統計圖**：顯示在不同映像類型下冷啟動時間的差異。

### 費用比較
- Cloud Run：$0.3 USD/天
- App Engine：$7.8 USD/天

Cloud Run 表現出穩定的冷啟動時間，但相較於 App Engine 數值略高，適合彈性需求高且對啟動時間不那麼敏感的應用。 Runtime-deps 映像的啟動時間普遍較短，而 SDK 映像的時間則略有延長。

## 喚醒時間優化方法

### App Engine 喚醒優化

針對 App Engine 的冷啟動問題，可透過 Warmup Requests 和最小實例設定來優化效能，在 app.yaml 中配置 warmup 設定，提前預熱實例，減少冷啟動帶來的延遲。並調整 min_instances 參數確保一定數量的實例持續運行，並使用 max_concurrent_requests 來平衡資源分配和響應速度。

或是可以使用排程喚醒，使用 Cloud Scheduler 定期喚醒 API 是簡單且有效的優化方法，特別適合低流量應用，能顯著降低冷啟動時間。定期向 API 發送請求，保持應用程序活躍，尤其適用於低流量但啟動時間敏感的應用場景。

## 結論

1. 實驗結果表明，Cloud Run 和 App Engine 各有優勢，企業需根據應用場景選擇最佳方案，權衡效能與成本。

2. App Engine 的冷啟動時間顯著短於 Cloud Run，適合對延遲敏感的應用。

3. Cloud Run 的計費模式更加靈活，對於處理間歇性工作負載來說更具經濟性，特別適合短時間內啟停的應用程序。

選擇 App Engine：如果應用需要穩定的性能且對啟動時間極為敏感，App Engine 的預熱設置與最小實例管理將是合適的選擇。若應用流量波動較大，且需要具備高度靈活性，Cloud Run 能提供更低的運行成本，尤其在間歇性負載中更具優勢。

這樣的選擇策略能夠讓企業在效能與成本之間取得良好平衡，並提升系統的總體效率。