雖然一直以來用 AWS 的服務都過得很舒服，但也對 GCP 的環境很有興趣。正好這次參加了 iKala Cloud 的 GCP 雲端基礎架構介紹課程，發一篇文簡單記錄一下筆記，也算是自己對雲架構的小複習。
權限控管
Credit : https://wideops.com/mapping-your-organization-with-the-google-cloud-platform-resource-hierarchy/
在 GCP 的世界裡，可以由公司帳戶成立一個 Organization，並透過不同的 Folder 做分類，例如可以在公司 Organization 下的第一層建立 Engineering Department 的部門，其中再可能再根據產品細分不同的 Folder。
完成分類後就可以在裡面建立 Projects ，作為特定專案管理的所需雲資源的入口。在每個 Project 中，擁有者都能設定該專案所需的資源與每個 User 對專案的存取權限，例如對資料庫的讀取權或雲端硬碟的寫入權。
目前 GCP 也提供了 IAM ( Identity and Access Management)的權限管理規則，可以細分到每個 User (或 Service)在不同專案中的讀取/寫入權限，這也是目前 GCP 建議用戶遵循的權限管理方法。相對來說，在引入 IAM 前提供的基本角色(Owner, Editor, Viewer)控管方法，則提供了一個顆粒度很較粗的解法，容易造成權限過大的管理問題，官方表示不建議使用。
基礎雲架構
VPC(虛擬) — Region(實體) — Subnet(虛擬) — Zone(實體)
GCP 的雲架構，是由虛擬層包裝實體建設，由一個全球性的私有虛擬網路 (Virtual Private Cloud, VPC) 為基礎開始。
VPC 作為網路圍牆的功能，除了讓專案與外面的網路世界隔離外，也能利用統一的入口管制 Requests 的流入，並利用 Load Balancer 做基於 Http 或 SSL 規則的Proxy，讓符合轉發規則的伺服器處理請求。
一個 VPC 可以覆蓋多個 Region。Region 就是雲廠商所劃分的機房行政區，屬於實體層，像台灣就是 GCP 的 asia-east1 region。同一個 Region 中的連線速度理論上會比較快，而且也可以免付跨區的資料傳遞費用。
一個 Region 裡面可以擁有許多虛擬的 Subnet，其功能最主要是分配 VPC 內的 IP 位置給我們的各項 Service 互相連線使用，也可以用來劃分不同環境 Dev 或 Prod 環境。
一個 Subnet 可以覆蓋多個 Zone。Zone 是實體機房的所在地，也就是 Data Center，台灣有彰化資料中心和規劃中的台南資料中心。GCP 會確保 Zone 之間相隔足夠遠的距離(100+ km)，避免發生災害一次把同一個 Region 的資料都損壞。
此外，GCP 還有提供 Shared VPC 的功能，可以由一個專案提供 Host VPC，供其他專案作為 Service VPC 接在其中，實現跨 VPC 連線與 IP 管理的功能。
運算資源
(IaaS) — GCE — GKE — GAE — (PaaS)
搞定了基本的權限管理與基礎雲架構，來討論運算資源的部分。這次課程介紹了幾種 GCP 提供的計算資源管理方式，由開發者由自己管理基礎設施的 InfraStructure as a Service (IaaS)到託管基礎設施的資源應用 Platform as a Service(PaaS)的光譜，分別對應到 Google Compute Engine(GCE)、Google Kubernetes Engine(GKE) 和 Google App Engine(GAE) 三種管理運算資源的服務。
首先，Google Compute Engine (GCE) 是使用者管理自由度最高的雲運算配置，就像是請 Google 直接借一批雲端的電腦給你一樣，相對的也要付出更多心力管理系統。
GCE 允許使用者可以自己決定想要租用的 CPU 、Memory 和 OS 系統等機器層面的配置，並根據使用情況決定自己租用運算資源的方案。同時，也給予用戶最大的機器操作權限，包括伺服器的 OS 系統，讓資深的開發者能根據需求量身打造所需的伺服器，並根據自己的需求將效能極大化。
使用 GCE 的開發者，除了對硬體必須要有一定程度的了解外，也必須自己處理硬體層以上的所有設定，包括安裝第三方套件時的各種複雜設定。
其次，Google Kubernetes Engine (GKE) 則是管理容器的好選擇。GKE 讓開發者不用處理機器端安裝與運行 Kubernetes 的細節，可以在 GCP console 中快速生成與管理集群，且仍保有使用 Kubernetes 指令配置容器的自由度。
使用者只要確保自己的程式碼和 Docker File 可以順利打包為可運行的 Docker Images，就能利用 GCP 提供的 Container 相關服務，將專案部屬到 GKE 的環境。
使用 GKE 的使用者，雖然可以省去硬體層的管理，以及 Kubernetes 本身運行的一些細節，但仍然需具備 Container 與 Kubernetes 的知識與實作經驗，才能充分利用 GKE 的服務。
最後，Google App Engine (GAE) 則是更進一步，由 GCP 自動管理擴展等事務，讓開發者無需關注部署的細節，同時也整合常用的 Log、Monitoring、Cron 等服務，讓開發者能快速建立基本的產品雛型。
開發者只需要專注在軟體功能的開發，並配合 GAE 建立各種 yaml 檔，在程式碼中置入 app engine 的 SDK，隨後把程式碼置入 GAE 內即可執行。
個人認為 GAE 適合對部屬掌握度要求度較低的專案，但仍需具備基本的 Container 知識與 High Level 的部屬概念，才能有效地運用 GAE 開發專案。
資料儲存
最後討論的是資料存儲，分別有三個服務對應到三種存取需求。
Cloud Storage 可以儲存圖片、影片或任何可以被轉成 binary 的檔案，也就是所謂 BLOB (Binary Large Object) 的儲存。雖然 Cloud Storage 和 AWS S3 一樣，提供用戶定義不常讀取的資料，以節省費用的方案，但 Cloud Storage 並不像 S3 需要一段較長的檔案解凍時間，只是會收取比較貴的讀取費用而已。
Big Table 通常用於高寫入需求(1000+ QOS )的情景，對應到 Wide Column 類型的儲存，這種資料庫利用 Row-Column-Timestamp 的三維座標儲存檔案，很適合結構不固定又頻繁更新的資料儲存需求。像是 IoT 裝置的 Sensor 回報、或是廣告業的各種 Event 湧入，很適合作為 Big Data 的數據資料庫。
Datastore 和 Fire Store 則較適合一般 APP 或後端的資料存取使用，是基於 Big Table 為基礎實現的 NoSQL 資料庫。資料基於開發者自訂的 Kind 分類，並利用自動生成的 ID 查找資料。就我個人來說，雖然 Datastore 底層的實作和我常用的基於 Document Store 的 MongoDB 不同，但在 Golang 裡面存取資料的方法基本上大同小異，轉換起來成本不高。