這份Google Cloud Well-Architected Framework：金融服務業觀點文件概述了在Google Cloud中設計、部署及運作可靠金融服務業 (FSI) 工作負載的原則和建議。這份文件探討如何將進階可靠性做法和可觀測性整合到架構藍圖中。本文件中的建議符合 Well-Architected Framework 的可靠性支柱。
對金融機構而言，穩定且具彈性的基礎架構不僅是業務需求，也是法規要求。為確保金融服務業工作負載的可靠性，您必須瞭解並降低潛在的故障點、部署備援資源，以及規劃復原作業。Google Cloud 營運韌性是可靠性的結果。也就是吸收、適應及從中斷中恢復的能力。作業彈性有助於金融服務機構組織滿足嚴格的法規要求。並避免對消費者造成無法容忍的傷害。
可靠性的主要建構區塊 Google Cloud 是區域、可用區，以及雲端資源的各種位置範圍：可用區、區域、多區域和全球。您可以運用受管理服務、分配資源、導入高可用性模式，以及自動化處理程序，進一步提升可用性。
法規要求
金融服務機構須遵守監管機構的嚴格可靠性規定，例如美國的聯邦準備系統、歐盟的歐洲銀行業管理局，以及英國的審慎監理局。全球監管機構都強調營運韌性，這對金融穩定和消費者保護至關重要。營運韌性是指承受服務中斷、有效復原，以及維持重要服務的能力。因此，管理技術風險和對第三方依賴關係時，必須採取一致的做法。
大多數司法管轄區的法規要求都有以下共同主題：
- 網路安全和技術韌性：加強防禦網路威脅，確保 IT 系統的韌性。
- 第三方風險管理：管理與外包服務相關的風險，這些服務是外包給資訊及通訊科技 (ICT) 供應商。
- 營運持續和事件應變：完善的規劃可確保在發生中斷事件時維持重要營運，並有效復原。
- 維護金融穩定：確保整體金融系統的健全和穩定。
本文中的可靠性建議對應至下列核心原則：
優先部署多區域和多地區網路
對於重要的金融服務應用程式，建議您使用多區域拓撲，並將應用程式分散到至少兩個區域，以及每個區域內的三個可用區。這種做法對於防範可用區和區域服務中斷至關重要。法規通常會規定採用這種做法，因為如果某個可用區或區域發生故障，大多數管轄區會認為第二個可用區嚴重中斷是可能發生的後果。理由是當一個位置發生故障時，另一個位置可能會收到異常大量的額外流量。
建議您參考下列做法，防範可用區和區域中斷：
- 盡量選擇涵蓋範圍較廣的資源。盡可能使用區域資源，而非可用區資源；使用多區域或全域資源，而非區域資源。這種方法有助於避免使用備份還原作業。
- 在每個區域中，請使用三個可用區，而非兩個。如要處理容錯移轉，請將容量佈建量設為預估值的 1.33 倍。
- 實作主動-主動部署 (如以下範例)，盡量減少手動復原步驟：
- Spanner 等分散式資料庫提供內建的備援機制，並可在不同地區之間同步處理。
- Cloud SQL 的高可用性功能提供近乎主動-主動的拓撲，並在各個可用區中提供讀取副本。可提供接近 0 的區域間復原點目標 (RPO)。
- 使用 Cloud DNS 將使用者流量分配至各區域，並在每個區域中部署區域負載平衡器。您也可以視需求和重要性，考慮使用全球負載平衡器。詳情請參閱「多區域部署的全域負載平衡優點和風險」。
- 如要儲存資料，請使用多區域服務，例如 Spanner 和 Cloud Storage。
排除單點故障
將資源分配到不同位置，並使用備援資源，避免單一故障點 (SPOF) 影響整個應用程式堆疊。
請參考下列建議，避免出現單點故障：
- 請避免只部署單一應用程式伺服器或資料庫。
- 使用代管執行個體群組 (MIG)，確保系統自動重建故障的 VM。
- 實作負載平衡，在可用資源之間平均分配流量。
- 針對 Cloud SQL 等資料庫使用高可用性設定。
- 使用區域永久磁碟搭配同步複製功能，提升資料可用性。
詳情請參閱「為 Google Cloud中的工作負載設計可靠的基礎架構」。
瞭解及管理匯總供應情形
請注意，系統的整體或匯總可用性會受到系統各層級或元件可用性的影響。應用程式堆疊中的層級數量與堆疊的整體可用性成反比。如要管理匯總供應情形，請參考下列建議：
使用公式 tier1_availability × tier2_availability × tierN_availability，計算多層堆疊的總可用性。
下圖顯示由四項服務組成的多層級系統，其匯總可用性計算方式如下：
在上圖中，每個層級的服務可用性為 99.9%，但系統的總可用性較低，為 99.6% (0.999 × 0.999 × 0.999 × 0.999)。一般來說，多層堆疊的整體可用性會低於可用性最低的層。
如有可能，請選擇「平行化」而非「串鏈」。平行化服務的端對端可用性高於個別服務的可用性。
下圖顯示使用鏈結和平行化方法部署的兩個服務 A 和 B：
在上述範例中，兩項服務的服務水準協議都是 99%，因此根據實作方法，匯總可用性如下：
- 串聯服務的整體可用性僅為 98% (.99 × .99)。
- 平行化服務可提供 99.99% 的更高總可用性，因為每項服務都是獨立運作，個別服務不會受到其他服務可用性的影響。匯總平行化服務的公式為 1 − (1 − A) × (1 − B)。
選擇 Google Cloud 提供正常運作時間服務水準協議的服務，協助應用程式堆疊達到整體正常運作時間的必要等級。
設計架構時，請權衡可用性、作業複雜度、延遲時間和成本。可用性每增加一個 9，通常成本就會提高，但這樣做有助於您符合法規要求。
舉例來說，99.9% 的可用性 (三個 9) 代表一天 24 小時內，可能會有 86 秒的停機時間。相較之下，99% (兩個 9) 代表在同一段時間內停機 864 秒，停機時間是可用性為三個 9 的 10 倍。
對於重要金融服務，架構選項可能有限。不過，找出供應情形需求並準確計算供應情形至關重要。進行這類評估有助於您評估設計決策對架構和預算的影響。
導入完善的 DR 策略
針對不同災害情境 (包括區域和區域性服務中斷) 制定明確的計畫。明確的災難復原 (DR) 策略可協助您從中斷事件中復原，並在影響最小的情況下恢復正常運作。
災難復原和高可用性 (HA) 是不同的概念。在雲端部署中，一般而言，DR 適用於多區域部署，HA 則適用於區域部署。這些部署原型支援不同的複製機制。
- HA：許多代管服務預設會在單一區域內的可用區之間提供同步複製功能。這類服務支援零或接近零的復原時間目標 (RTO) 和復原點目標 (RPO)。這項支援功能可讓您建立沒有 SPOF 的主動/主動部署拓撲。
- DR：如果工作負載部署在兩個以上的區域，且您未使用多區域或全球服務，則必須定義複製策略。複製策略通常為非同步。 請仔細評估這類複製作業對重要應用程式的 RTO 和 RPO 有何影響。找出容錯移轉所需的半自動或手動作業。
對於金融機構，您選擇的容錯移轉區域可能受到資料主權和資料落地相關法規的限制。如果您需要在兩個區域之間使用「作用中-作用中」拓撲，建議您選擇受管理的多區域服務，例如 Spanner 和 Cloud Storage，尤其是在資料複製至關重要時。
請參考下列建議：
- 使用代管的多地區儲存服務儲存資料。
- 為永久磁碟中的資料建立快照，並將快照儲存在多區域位置。
- 使用區域或地區資源時，請設定資料複製到其他地區。
- 定期測試 DR 方案，確保方案有效。
- 請注意，RTO 和 RPO 與您所在管轄區金融法規規定的影響容許度相關。
詳情請參閱「為雲端基礎架構中斷情況設計災難復原機制」。
運用代管服務
請盡可能使用代管服務，充分運用備份、高可用性和擴充性的內建功能。使用代管服務時，請參考下列建議：
- 在 Google Cloud中使用代管服務。提供有服務水準協議保障的高可用性。同時也提供內建備份機制和復原功能。
- 如要管理資料，不妨考慮使用 Cloud SQL、Cloud Storage 和 Spanner 等服務。
- 如要進行運算和應用程式代管，請考慮使用 Compute Engine 代管執行個體群組 (MIG) 和 Google Kubernetes Engine (GKE) 叢集。地區性 MIG 和 GKE 地區叢集可抵禦可用區中斷。
- 如要提高區域中斷的復原能力，請使用代管多區域服務。
- 針對具有獨特特徵的服務，找出退場計畫的需求，並定義必要計畫。FCA、PRA 和 EBA 等金融監管機構要求企業制定資料擷取和營運持續策略與應變計畫，以防與雲端供應商的關係終止。公司必須在簽訂雲端合約前評估退出可行性，且必須維持更換供應商的能力，不得造成作業中斷。
- 確認所選服務支援將資料匯出為開放格式，例如 CSV、Parquet 和 Avro。確認服務是否以開放技術為基礎，例如 GKE 支援開放容器倡議 (OCI) 格式，或以 Apache Airflow 為基礎建構的 Cloud Composer。
自動執行基礎架構佈建和復原程序
自動化有助於減少人為錯誤，並縮短事件回應所需的時間和資源。使用自動化功能可確保更快從失敗中復原，並獲得更一致的結果。請考慮下列建議，自動佈建及復原資源：
- 使用 Terraform 等基礎架構即程式碼 (IaC) 工具，盡量減少人為錯誤。
- 自動執行容錯移轉程序，減少人為介入。自動回覆功能也有助於減少失敗造成的影響。舉例來說，您可以透過 Eventarc 或 Workflows，針對稽核記錄中發現的問題自動觸發補救措施。
- 使用自動調度資源功能，在容錯移轉期間增加雲端資源容量。
- 採用平台工程，在服務部署期間，自動為雲端拓撲套用法規要求適用的政策和防護措施。