Google Cloud的架構設計概念

在設計GCP的架構與其使用的服務時，我們第一個一定需要先瞭解的是業務需求。倒底為什麼要用雲端服務?

例如，許多人的第一反應就是使用雲端可以節省成本。哪麼如果是這方面的業務需求 — 從地端到雲端(從Capital Expenditure到Operational Expenditure)。哪麼我們可能會使用的服務與功能可能有:

• Managed Services
• Autoscaling
• Spot VMs

又或者是加速開發的步伐，哪我們可能會評估並採用 DevOps (CI/CD) 和 SRE 等新興流程與微服務等新興架構。又或是縮短平均恢復時間、提高法規合規性、更深入地了解應用程式和基礎設施（指標）與從可用數據中獲取更多情報等等。

計算TCO(Total Cost of Ownership)

這個時候老闆就需要算一筆帳了。到底是在地端還是上雲的成本低，我們通常會計算整個資料中心的TCO。計算的項目可能有:

• Licensing Costs (Soft ware + Hardware)
• Computing Costs
• Storage Costs
• Networking Costs (Connection cost + Data Ingress + Data Egress)
• Personnel Costs (Dev + Test + Ops + Business + ..)
• 其他有的沒的成本
  如:SLA沒達標的罰金或合規成本或第三方API等

以上這些在設計整個架構時都要考量進去。哪麼接下來就是根據業務需求來設立相關的指標，也就是KPI。

企業在實現目標上表現如何？
專案關鍵績效指標
例如：一週內的新客戶數量或在雲端中運行的VM的百分比
營運關鍵績效指標
例如：每個客戶的營運成本

這些KPI都有了之後，我們就可以產生相關的技術面需求了。這可分為功能性與非功能性。

功能性的需求，例如:

• 必須使用容器
• 必須使用強化的Linux作業系統
• 需要容器編排
• 必須是自動縮放
• 必須是具有靈活架構的 NoSQL 資料庫
• 能夠以極低的成本儲存大量檔案
• 必須使用專用網路（流量不應透過網際網路）

非功能性的需求，例如:

• Availability
• Scalability
• Durability
• Security

高可用度的規劃

我們根據可用度的要求，在GCP的可用度範圍進行設計。從Global到Zonal。每一種服務的支援能力都有些不同(如下表)。

擴充性的規劃

關於GCP各種資源的擴充性可使用以下各資源的特性

運算資源

GCE:高度可擴展的運算引擎架構：MIG 中的VM，由instance template配置（並透過LB進行負載平衡）。PS: Unmanaged Instance Groups不支援 Auto Scaling。使用 GKE 的 Pod 和叢集自動擴展。另外Cloud Storage, App Engine 與Cloud Functions這一類的serverless服務都支援 Auto Scaling功能。

Local SSD 的可擴充性最差（每個VM最多只能掛 8 個），資料在重新啟動和即時遷移後仍然存在。但是當VM停止或終止時資料就會消失。

Persistent Disks的水平和垂直縮放
垂直: 可以在附加到 VM 時增加 PD 的大小
水平:可以在VM運作時附加新的 PD（最多 128 個）

儲存資源

有些資源是無法快速擴展的，例如Cloud SQL 不能水平擴展（只能垂直擴展）。Stateful Application的擴展又比Stateless Application更困難，通常建議修改程式，將state 存放於memory store這一類的服務。

關於DataBase的部分，Pub/Sub, BigQuery 與Cloud Datastore也是serverless 的服務(支援Auto Scaling)。但BigTable, Cloud Spanner, Cloud SQL, Dataproc這些都需要我們對其Cluster進行管理。

安全的規劃

關於安全的C.I.A目標，我們在本部落格的一堆文章已經不厭其煩的提過很多次了。有興趣的人可以去參閱相關文章。在實作的部分:

Confidentiality:
遵循IAM的最佳實踐，還有對資料進行加密。

Integrity:
遵循IAM的最佳實踐 — Role Based Access/Separation of duties。加上Hash verifications 與digital signatures的功能。

的Availability:
可以用Firewalls, Redundancy, Automatic Failover等等，還有針對DoS/DDoS的防護。

DDoS Protection and Mitigation

DDoS攻擊是一種將服務癱瘓的攻擊手法。在這種攻擊中，使用者(也就是我們)與GCP是一種Shared responsibility。有各自的任務去要去完成才可以減緩這種攻擊。

GCP會提供以下基本功能:

• 在VPC裡有"Anti-spoofing protection"
• VPC之間的隔離
• 如果最前端有使用GFE(Google Front End)，則有免費的L4 DDoS防禦，如:SYN floods, IP fragment floods, port exhaustion等。

哪我們需要在GCP裡做些甚麼來減緩攻擊與減低發生的可能性呢?

• Reduce the attack surface — 確保我們使用GCP各項可以達成此目標的服務，如subnetworks/networks/firewall rules/IAM等
• Isolate internal traffic — 各項運算資源盡量不要掛載Public IP，而是用LB來代替。各子網段之間也使用LB或security applianc來防禦
• 對外盡量使用Proxy-based LB，並啟用Cloud Armor(GCP的WAF)。Cloud Armor的功能有:
  1.)IP-based and geo-based access control
  2.)可以過濾 Layer 7 security policies，不管是要把流量導去哪裡(其他雲端或地端)
  3.)已經設定好可以防護 OWASP Top 10WAF rules

使用Cloud KMS進行數位簽章(Digital Signatures)

進行數位簽章的目的通常有以下兩種:

1. 驗證經過簽章資料的完整性
2. 不可否認性: 簽署者無法否認其簽章

一般的流程是發送者對資料進行私鑰操作以建立數位簽章，而接收者使用公鑰來驗證數位簽章，如果驗證不成功，則資料有被修改過。我們可以用來驗證code build的流程。

Secret Manger

一般傳統的系統運作中，我們是如何儲存我們系統的各種密碼或API key呢?傳統的方式可能放在一個資料夾裡，做一些存取的限制。但是這會增加Management overhead，GCP提供這一類的託管服務來協我們這一類的管理。它的主要功能有:

• secrets可以有個版本
• 用Cloud Functions來自動rotation
• 用Cloud Audit Logs來進行稽核
• 預設會對其裡面的資料進行加密

最最重要的是 — 不要把"credentials/passwords"放在代碼中。

利害關係人管理

至於利害關係人管理可參考本部落格"TOGAF的架構視圖、觀點與利害關係人"一文。

變更管理

而變更管理可參考本部落格"運用TOGAF ADM 的架構變更管理"一文。

而在GCP上的BC/DR/IR等各項管理則可參考可參考本部落格"ISC2- CC-Domain 2 -BC/DR/IR"一文。

Google Cloud Architecture Framework

這是GCP對要使用GCP服務的客戶的"最佳實踐與實作建議"的集合。這個況價聚焦於設計一個具robust, secure與scalable特性的系統。 並且有以下四種的原則:

• Operational excellence
• Security, privacy, and compliance
• Reliability
• Performance and cost optimization

關於這一類的其他雲端平台的框架可以參閱本部落格的其他文章。

卓越維運(Operational excellence)

高效運作、管理和監控可產生"業務價值"的系統。在這個原則中，我們的策略應該有:

• Automate build, test, and deploy
• Monitor business objectives metrics
• Conduct disaster recovery testing

這裡的最佳實踐應該是

1.)提高軟體開發和發布速度。

1.1)Release Engineering — 頻繁且小量的發布。

1.2)自動化作業:

• Static code analysis與security scans
• Automate Testing (Unit, Integration, System, Load, Security Testing etc..)
• Automate build and release pipeline
• A/B or canary testing

1.3)可對應的GCP服務有:

• Cloud Source Repositories
• Container Registry
• Cloud Build: Build deployable artifacts

2.)監控系統與業務指標的健康度

2.1)理解指標中的四種重要訊號

• Latency — 系統多快回應使用者?
• Traffic —系統的負載是甚麼狀況?
• Errors — 有任何request沒處裡到嗎?
• Saturation —資源利用率如何？

2.2)Logging — 根據需求使用 Cloud Logging 並匯出到 Cloud Storage、BigQuery 和 Pub/Sub

2.3)Metric — 定義和擷取 SLI、SLO 等指標

2.4)Monitoring — Cloud Monitoring可以聚合metric、logs和event

• 定義告警和自訂指標以識別問題並快速解決它們
• 建立視覺化儀表板
• 產生可進行下一步動作的告警

以上的這些都可以使用Cloud Monitoring、Cloud Logging、Cloud Debugger、Error Reporting、Cloud Trace與Cloud Profiler來對應。

3.)設計DR(disaster recovery)

3.1)建立一個良好的DR Plan

• 定義出RTO/RPO
• DR Plan中需要把於系統跟服務有關的組件(運算、儲存、網路)都要考量進去
• 這可以使用GCP的全球網路產生Redundancy，使用託管式服務可以產生可擴充性

3.2)定期測試我們的DR Plan，例如:

• 為VM排程Persistent Disk snapshots照並跨Region複製它們
• 啟用Live Migration，即使在進行軟體或硬體維護時也能保持VM運行
• 使用 Cloud DNS 從主要站點切換到備用站點

Security, privacy, and compliance

規劃安全控制、隱私並滿足合規性需求。在這一部分我們的策略應該有:

• 透過身分和授權控制實現最小權限控管
• 建構分層安全方法(Defense-in-Depth)
• 自動部署敏感作業
• 實施安全監控

最佳實踐有:

1.)Authentication與Authorization的管理(遵循IAM最佳實踐)

1.)授予適當的角色

• 了解何時使用Service Account
• 將每個應用程式元件視為單獨的信任邊界(零信任原則)
• 為每個元件/服務建立單獨的service account，並具有所需的最低權限

1.2)使用Organization Policy Service（組織允許什麼？）

1.3)使用Cloud Asset Inventory（追蹤資產狀況）

1.4)使用 Cloud Audit Logs 集合IAM Policy的變動和Service Account

2.)實行Compute Security Controls

• 盡可能使用Private IP
• 建立安全強化後的VM Image（作業系統 + 最低程度的軟體）
• 使用Shielded VMs來防止遠端攻擊、權限升級和內賊
• 為 GKE 叢集啟用節點自動升級
• 使用 GKE Sandbox 在執行不受信任的代碼時提供額外的安全層

3.0)保護網路

• 使用經過設計的 VPC（而不是使用Default VPC）
• 透過為每個Project建立一個 VPC，將工作負載隔離到各個Project中
• 使用防火牆規則控制Ingress和Egress網路流量
• 運行先進的安全和流量檢查工具
• 使用 Security Command Center 分析基礎設施的安全性
• 使用 Network Intelligence Center 評估網路拓撲和架構

4.)實行Data security controls

4.1)對靜態資料進行加密。跟據需求使用customer managed或customer supplied keys

4.2)對Cloud Storage中，對敏感資料啟用Object Versioning

• 使用Object Lifecycle Management來降低成本
• 使用 Bucket Lock 實現對其資料保留的合規性
• 使用Signed URL 提供對Object有時間性的read/write權限

4.3)實行Data Security —
使用Cloud DLP API 對敏感資料進行分類、屏蔽、標記化和轉換（確保信用卡號、姓名、身分證字號、電話號碼等敏感資料元素的資料隱私。）

5.)使用audit logs稽核基礎設施

5.1)使用Cloud Audit，並依需求將資料匯出到Cloud Storage, BigQuery或Pub/Sub

5.2)啟用Access Transparency logs

可靠度(Reliability)

任何應用程式/服務最重要的主要能力：

• 可衡量的可靠度目標
• 可擴展性、高可用性和自動化變更管理的架構
• 自我修復和可觀察性很重要
• 盡可能使用自動化從故障中快速恢復

在這一部分我們的策略應該有:

• 定義出KPI、 SLO 與SLI
• 建立 redundancy (最好能水平式的擴充)
• 增量式的變動
• 要有rollback的能力
• 可觀測性儀器系統
• 自動偵測故障
• 記錄並自動化緊急回變
• 測試故障復原
• 減少勞累（消除手動作業）

在這一部分的最佳實踐有:

1.)定義可靠度目標 — Service Level Objectives與Error Budgets
清楚的定出SLIs, SLOs, SLAs 與Error budgets

2.)在Infra與Application中建立可觀測性(observability)
使用Monitoring, logging, tracing, profiling, debugging這一類的GCP服務

3.)設計高擴充性與高可用度

• 設計具有Failover功能的Multi-region架構
• 消除可擴充性瓶頸(最好能水平式的擴充)
• 逐步地降低服務等級別。例如動態網站關閉時的靜態網頁或暫時停用資料更新
• 實施帶Jitter的exponential backoff，例如retry前的等待時間呈指數增加
• 預測高流量事件並為其製定計劃

4.)建構靈活自動化的部署能力

• 確保每個變更都可以rollback
• 分散流量以進行定時更版和發布
• 透過金絲雀測試實施漸進式部署
• 自動化建置、測試和部署

5.)建立具效能的告警

6.)針對事故管理建立協作流程

• 縮短MTTD(Mean Time to Detect)：在正確的時間向團隊發出告警
• 縮短MTTM(Mean Time to Mitigate)和MTTR(Mean Time to Recovery)：正確記錄並能良好執行的事故管理計劃
• 增加MTBF(Mean Time Between Failures)：建立可靠的系統
• 建立不找戰犯的事後文化

效能與成本優化(Performance & Cost Optimization)

有關雲端成本優化的深入知識，可參閱本部落格關於FinOps相關文章。而在這一部分我們的策略應該是:

• 評估效能要求
• 使用可擴展式的設計模式
• 確定並實施節省成本的方法

最佳實踐則是:

1.)使用autoscaling與data processing

• 使用MIG來 自動縮放 GCE VM— 運用instance template
• 在GKE Cluster上啟用Cluster autoscaler與Pod autoscaling（Horizontal Pod Autoscaler）
• 嘗試無伺服器選項：Cloud Run、App Engine、Cloud Functions、Dataproc 和 Dataflow
• 使用 Google Cloud Load Balancer 提供全球端點

2.)使用GPU與TPU來增強效能

• 使用 GPU 加速機器學習和資料處理的工作負載
• 使用 TPU 在機器學習的工作負載中執行大規模矩陣運算

3.)識別要調整的應用程式

• 使用 Cloud Trace、Cloud Debugger 和 Cloud Profiler 深入了解應用程式
• 偵測應用程式以識別服務間通訊延遲或識別瓶頸

4.)成本分析與優化

• 將帳單匯出至 BigQuery 以分析帳單資料。使用 Google Data Studio 進行視覺化
• 理解甚麼是SUD(Sustained use discounts)
• 利用CUD(Committed use discounts)來實現可預測的長期工作負載
• 用Spot VM來運行非關鍵工作負載(fault tolerant)
• 在 Cloud Storage中啟用Object Lifecycle Management降低儲存成本