配置無伺服器環境

GCP 無伺服器運算簡介

對於 Professional Cloud Architect (PCA) 而言，「無伺服器 (Serverless)」不僅僅是「沒有伺服器」。它是一種抽象化基礎架構的哲學，旨在讓開發者專注於代碼，實現自動擴展，並採用按需付費 (Pay-as-you-go) 的成本模型。

Google Cloud 的無伺服器生態系統以 Cloud Run（用於容器）和 Cloud Functions（用於程式碼片段）為核心，並透過 Eventarc 進行事件驅動的編排。

白話文解釋 Serverless Compute

無伺服器就像是擁有自己的廚房與從高級外送服務點餐之間的區別。

類比 1 — 雲端廚房 (Cloud Run)

在傳統餐廳（Compute Engine）中，即使沒有客人，你也必須支付租金、爐灶費用和員工工資。Cloud Run 就像是一個雲端廚房 (Ghost Kitchen)。你自備專用的鍋碗瓢盆（容器映像檔 Container Image）。當訂單（網頁請求）進來時，廚房燈光亮起，廚師開始烹飪；訂單完成後，燈光熄滅，你也停止付費。如果同時進來 1,000 個訂單，1,000 個廚房會瞬間出現。

類比 2 — 自動門感應器 (Cloud Functions & Eventarc)

Cloud Functions 就像是自動門感應器。在有人走過（事件發生）之前，它什麼都不做。當感應器偵測到人（例如：檔案上傳到 GCS），它會觸發一個特定的微小動作：「開門」。你不需要一個全職警衛（一台 VM）24 小時站在那裡只為了開門。

類比 3 — 精準水錶 (按需付費)

傳統伺服器就像是支付固定費用來使用無限的水，即使你只喝一杯。Serverless 就像裝了精準水錶。你只需為實際流過水龍頭的每一毫升水（每毫秒的 CPU/記憶體）付費。如果水龍頭關閉，你的帳單就是零。

部署至 Cloud Run

Cloud Run 是目前無伺服器的現代標準。

• 基於容器： 只要能跑在容器裡，就能跑在 Cloud Run。
• 並發量 (Concurrency)： 與 Cloud Functions 不同，單個 Cloud Run 執行個體可以同時處理多個請求（最高 250 個），這對網頁應用程式更具效率。
• Knative 兼容： 基於開放標準，避免供應商鎖定。

流量拆分與修訂版本 (Revisions)

每次部署到 Cloud Run 時，都會建立一個新的修訂版本 (Revision)。

• 藍綠部署 (Blue-Green Deployment)： 部署新版本，測試後，將 100% 流量切換過去。
• 金絲雀測試 (Canary Testing)： 將 5% 流量發送到新版本，95% 留給舊版本，以確保穩定性。
• 快速回滾 (Rollback)： 如果新版本有錯誤，可以瞬間將流量導回前一個健康的修訂版本。

Cloud Functions (第 1 代 vs. 第 2 代)

• 第 1 代： 原始版本，執行時間有限（9 分鐘），且並發量受限（每個執行個體一次處理一個請求）。
• 第 2 代：（強烈建議）構建在 Cloud Run 之上。支援更長的執行時間（最高 60 分鐘）、更大的執行個體規格（最高 32GB RAM）以及更好的事件整合。

透過 Eventarc 實現事件驅動觸發

Eventarc 允許您透過將來自 90 多個 Google Cloud 來源的事件路由到 Cloud Run、Cloud Functions 或 GKE，來構建事件驅動架構。

• 來源： Cloud Storage（檔案上傳）、Pub/Sub（訊息）、Cloud Audit Logs（任何 API 調用）。
• 架構建議： 使用 Eventarc 解耦您的服務。與其讓服務 A 直接調用服務 B，不如讓服務 A 發出一個 Eventarc 能接收到的事件。

無伺服器 VPC 存取連接器 (Serverless VPC Access Connectors)

無伺服器服務運行在 Google 託管的租戶專案中。若要存取您的私有 VPC 資源（如使用私有 IP 的 Cloud SQL 或 Filestore 共享），必須使用 VPC 存取連接器。

• 運作原理： 它充當無伺服器環境與您 VPC 之間的橋樑。
• 考試重點： 這是連接私有資料庫的唯一標準做法。

無伺服器環境中的秘密管理 (Secrets Management)

切勿在容器或程式碼中硬編碼 API 金鑰或密碼。

• Secret Manager： 集中存儲您的秘密。
• 整合： Cloud Run 和 Cloud Functions 可以在運行時將秘密掛載為環境變數或磁碟卷中的檔案。

並發量與冷啟動優化 (Cold Start Optimization)

• 冷啟動： 當無伺服器平台必須從零開始啟動新執行個體以處理請求時產生的延遲。
• 優化方式：
  • 最小執行個體數 (Min Instances)： 保持一定數量的執行個體處於「預熱」狀態（但需為此付費）。
  • 語言選擇： Go 和 Node.js 的啟動速度通常快於 Java 或 Python。
  • 提高並發量： 較高的並發量設定可以減少冷啟動頻率，因為單個執行個體能處理更多流量。

自定義網域與 SSL

• 自動 SSL： Cloud Run 開箱即提供帶有託管 SSL 的 *.a.run.app URL。
• 自定義網域： 您可以使用 全域 HTTP(S) 負載平衡 (Global Load Balancing) 作為 Cloud Run 的前端，來映射您自己的網域（例如 api.example.com）。

無伺服器可觀測性 (Observability)

• Cloud Logging： 自動捕獲容器的所有 stdout 和 stderr。
• Cloud Monitoring： 追蹤請求數量、延遲和執行個體數量。
• Cloud Trace： 使用分佈式追蹤查看請求在無伺服器服務中移動時的耗時。

無伺服器服務的 IAM 角色

• 服務身分 (Service Identity)： 每個 Cloud Run/Function 服務都應擁有其專屬的服務帳戶 (Service Account)。
• 權限控制： 遵循最小權限原則。例如，僅從 GCS 讀取的服務應僅擁有 roles/storage.objectViewer 角色。

常見問題 (FAQ) — 無伺服器運算配置

Q1. 我該何時選擇 Cloud Run 而非 Cloud Functions？

大多數網頁應用程式、API，或當您需要標準 Cloud Functions 執行環境中沒有的特定函式庫時，請選擇 Cloud Run。對於簡單、單一目的的事件處理程序或小型程式碼片段，請選擇 Cloud Functions。

Q2. Cloud Run 可以縮減到零嗎？

是的。預設情況下，如果沒有流量，Cloud Run 將停止所有執行個體，這意味著您的應用程式在不使用時費用為 $0。

Q3. Cloud Run 中的「並發量 (Concurrency)」設定是什麼？

它是單個容器執行個體可以同時處理的最大請求數。正確調整此項設定是最小化冷啟動和優化成本的關鍵。

Q4. 如何將 Cloud Run 連接到私有資料庫？

使用 無伺服器 VPC 存取連接器，並確保您的資料庫在 VPC 內配置了私有 IP。

Q5. 無伺服器總是比 VM 便宜嗎？

不一定。對於持續性、高流量的應用程式，使用 Compute Engine 的預留執行個體或託管執行個體群組 (MIG) 可能更具成本效益。無伺服器對於突發性或低至中等流量最為划算。

最終架構師建議

在 PCA 考試中，請記住 Cloud Run 實際上就是「無伺服器 GKE」。它使用相同的 Knative 標準。如果問題涉及「將容器化應用程式遷移到無伺服器平台」，Cloud Run 幾乎總是預期答案。此外，請務必關注 VPC 存取 — 這是架構情境中的常見陷阱。