前面幾個章節有介紹了 Google Cloud 中常見的幾個 Compute Service 運算服務，分別是： Compute Engine、Cloud Functions、Cloud Run、Google Kubernetes Engine :

這邊也補充介紹 App Engine，它也是屬於 GCP 運算服務，只要上傳滿足該平台規範的 Code 格式就可以開始運作，會自動做負載平衡且並不需要管理任何硬體機器，聽說當年很紅的遊戲 Angry Birds 就是使用 App Engine 來作為服務平台。以上這五種運算服務應該在什麼情況下選擇呢？ 選擇正確的基礎架構服務來運行 APP 是很重要的，故以下對其做一些廣義的整理和筆記。

App Engine => 抽象級別 : PaaS 運算服務

App Engine 是一個完全託管的無伺服器平臺，用於完整的 Web 應用程式，會負責處理網路、應用擴展和資料庫擴展，更新版本等操作。雖然蠻多介紹都說他是單體式 monolithic server-side 但官網介紹上看起來也可以做很好的微服務化。

App Engine 設計上是由一個或多個 service 組成，service 的行為就類似於微服務，彈性很大可以有多個版本、不同的運行環境 runtime 等等 :

聽說是 App Engine 是整個 GCP 雲端第一個雲端服務，現在已經是很成熟的產品，所以後來也比較少有重大的更新。如果想瞭解 App Engine 的設定，可以使用：

gcloud app describe

注意事項

  • 一個 GCP Project 中只能有一個 App Engine

以下是創建 App Engine 的 UI Console 畫面 :

一開始最主要是要選擇 Location，注意一旦決定 Location 創建完成之後就無法更改了。 所以如果想改變已經設定的 App Engine Location，解決方式只能建立一個新的 Project，並在該新 Project 中，建立一個 App Engine 然後指定新的區域

  • 將 APP 的新版本部署到了 App Engine 但發現了錯誤，需要恢復到上一個版本，應該怎麼做？

App Engine 頁面中，可以將流量分配給已部署的任何版本。故當發現新版本有問題時，將 100% 的流量重新路由到先前的版本，是一個簡單且有效的方法來迅速恢復服務，可以立即將用戶導回到之前的穩定版本。

  • 將 APP 的新版本部署到了 App Engine ，希望能讓 1% 的用戶看到該網站的新測試版本，其他維持一樣舊版本，對於 App Engine Best-Practice 應該怎麼做？
    • A. Deploy the new version in the same application and use the –migrate option.
    • B. Deploy the new version in the same application and use the –splits option to give a weight of 99 to the current version and a weight of 1 to the new version. (O)
    • C. Create a new App Engine application in the same project. Deploy the new version in that application. Use the App Engine library to proxy 1% of the requests to the new version.
    • D. Create a new App Engine application in the same project. Deploy the new version in that application. Configure your network load balancer to send 1% of the traffic to that new application.

因為 App Engine 已經內置了流量拆分功能，可以將流量分配給已部署的任何版本 :

  • 使用 --migrate: 會將所有的流量，從當前版本轉到到新版本
  • 使用 --splits: 可以設定按百分比，將流量分配給不同的版本
# migrate
gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION]=1 --migrate

# splits
gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT]

故選 B. 使用 --splits 是比較好的作法。

補充一下，還有-–no-promote，這是用來在部署新版本時，阻止自動將流量分配到新版本的選項，可以在部署新版本後進行測試 :

gcloud app deploy ~/my_app/app.yaml --no-promote

GCP 運算服務簡介

GCP 官方取名為 <運算服務> ，我一開始也覺得有點抽象，不如直接使用 virtual-machine 這種關鍵字眼來的直觀。但不管是哪個雲端供應商，都會有一些產品服務名稱讓人疑惑一下，只能多看官方文件來了解產品呢。

  • Compute Engine => 抽象級別 : IaaS

    也稱 Virtual machines 虛擬機，需要自行配置 CPU、Memory、Disk 或者 GPUs 等等，並自己決定要運行的作業系統和安裝其他軟體，還可以做其他設定來支持 Autoscale 功能。如果需求可能要對底層硬體基礎架構進行更多控制，那就建議使用 Compute Engine。

  • Google Kubernetes Engine => 抽象級別 : IaaS 或 PaaS

    Kubernetes 本來就是一個 Open-Source Container Orchestration，用於自動化容器化應用程式的部署、擴展和管理 ; 而 GCP 雲端託管的 Kubernetes Clusters 更無縫整合 GCP 自身其他服務。如果本身就對 K8S 有一定熟悉度，且已經有使用很多 GCP 其他雲端服務想做整合，那可以嘗試使用 GKE。

  • Cloud Run => 抽象級別 : FaaS 或 PaaS

    一個完全託管的容器化無伺服器平臺，運行單個容器，面對大流量也可自動擴展以回應 Web Request 或其他事件，由於只要能打包成容器即可運作，支援的語言情境更加廣泛。 關鍵字是容器化，如果不需要像 Kubernetes 那樣對硬體資源複雜的操作，且需求是比較起 Cloud Functions 更加複雜一些的容器化微服務，可考慮使用 Cloud Run。

  • Cloud Functions => 抽象級別 : 標準 FaaS

    事件驅動 Event-driven serverless functions，上傳程式碼即可運作。由於概念上是使用才付費的，所以 Cloud Functions 不會一直運行著，當事件發生時 Cloud Functions 才會調用函數方法，請求結束之後就 shutdown。為較強烈的微服務導向化設計，如果是 Event-Driven 導向或 ETL Pipeline 流程設計需求，可以使用 Cloud Functions 。

承前知道在 Google Cloud 中，有兩種運算服務同為 FaaS 架構也同為 Serverless 服務，若更加細分的話，一個是

  • Cloud Run 定義為 Serverless platform
  • Cloud Functions 定義為 Serveless logic

其他整理比較

  • Infra 可控性

    • 如果只是一個小型開發團隊，並且希望專注在 code 上，那麼 Cloud Run 或 App Engine 等無伺服器選項是一個不錯的選擇
    • 如果擁有更大的團隊，有自己的工具和流程，可以使用 Compute Engine 或 GKE 自己控制更多底層架構設計

  • 計費模式

    • Compute Engine 和 GKE 計費模式偏向基於資源，需要為預置的實例付費
    • Cloud Run、App Engine 和 Cloud Functions 偏向按請求計費

  • 「VM Image」 V.S 「Cloud Run」 V.S 「GKE」

    在 GCP 中想使用運行容器的解決方案：

    • 其中一種方法是使用 GKE。 GKE Cluster 是整合 GCP 雲端 IAM 安全及監控服務、可設定高可用，且對於節點 Node 可雲端自動擴充、自動修復功能 ; 借助 GKE for Anthos，還可以混合多雲和地端平台，自由移動 workload
    • 如果不想像 GKE 那樣寫許多 YAML 檔並管理 Infra，只想專注於建立無狀態容器化應用，可以考慮 Cloud Run，同樣地也可以借助 Cloud Run for Anthos ，混合自己的私人託管環境並部署容器
    • 最後是使用 GCE，其概念就類似在本地電腦內啟動 docker，並在其上面運行各式容器。對於此情景有建議的虛擬機器作業系統 <容器最佳化作業系統> 稱 Container-Optimized OS，它針對運行容器進行了最佳化，並由 Google 官方維護

  • 「Cloud Run」V.S「App Engine」

    依靠 App Engine 上多年的經驗，現在 Cloud Run 是 GCP Serverless 最新的推薦工具，Cloud Run 改進了 App Engine 體驗，主要是與 Google Cloud 其他雲端服務的集成

  • 「Cloud Run」V.S「Cloud Functions」

    • Cloud Functions 代表了 Google Cloud 的事件驅動型無伺服器計算服務，關鍵是「輕量級事件驅動」
    • loud Run 偏向做為一個完全託管的計算平臺，提供容器化 Web 應用程式的自動擴展，關鍵字是「容器化靈活性」

  • 可移植性和開源需求

    基於「可移植性和開源支援」可考慮 GKE 和 Cloud Run ，因為他們都基於開源框架： GKE 集群由 Kubernetes 開源集群管理系統提供支援 ; 而 Cloud Run 遵照 Knative 開源專案提供支援。若真的有轉移雲供應商的考量，以可移植性來考慮的話，GKE 可能比 Cloud Run 更容易遷移，因為 k8s 有比較多獨立的配置檔，可控性更高。

    簡單查一下 Knative 是建構在 Kubernetes 之上，將 Deployment、Service 和 Ingress 等 k8s 資源簡化成 Knative Service

參考資料