Google Cloud 基礎架構服務會在全球各地執行。這些位置分為「地區」和「區域」，這兩者是設計雲端工作負載可靠基礎架構的基礎元件。
故障網域是指資源或一組資源，可在與其他資源無關的情況下發生故障。獨立的 Compute Engine VM 就是資源失敗區域的範例。 Google Cloud 地區或區域是故障網域的範例，由一組資源組成。當應用程式在故障網域中以備援方式分散時，可達到比各故障網域提供的更高總可用性。
Google Cloud 基礎架構可靠性指南的這一部分說明瞭 Google Cloud 中可靠性的構成要素，以及這些要素如何影響雲端資源的可用性。
地區與區域
「地區」是獨立的地理區域，由各「區域」組成。可用區和區域是基礎實體資源的邏輯抽象概念。如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。
平台適用情形
Google Cloud 基礎架構的設計宗旨是容許失敗並從中復原。Google 持續投入創新方法，維持並提升 Google Cloud的可靠性。Google Cloud 基礎架構的以下功能有助於為雲端工作負載提供可靠的平台：
- 地理區域分開，以減輕天災和區域停機對全球服務的影響。
- 硬體備援和複製功能，避免單點故障。
- 在維護事件期間即時遷移資源。舉例來說，在預定的基礎架構維護期間，您可以使用即時遷移功能，將 Compute Engine VM 移至同個區域的其他主機。
- 融入安全考量的基礎架構，可為 Google Cloud 執行的實體基礎架構和軟體提供安全保障，以及作業安全性控制項，用於保護您的資料和工作負載。詳情請參閱 Google 基礎架構安全性設計總覽。
- 高效能骨幹網路採用先進的 軟體定義網路 (SDN) 方法進行網路管理，並提供邊緣快取服務，以便提供可擴充的一致效能。
- 持續監控及回報。您可以使用 Google Cloud Service Health 資訊主頁，查看各個地點的Google Cloud 服務狀態。
- 每年以整個公司為範圍，進行災難復原測試 (DiRT) 活動，確保 Google Cloud 服務和內部業務營運在災難發生時，也能繼續正常運作。
- 變更管理方法：強調軟體開發生命週期所有階段的穩定性，以便對 Google Cloud 平台和服務進行任何變更。
Google Cloud 基礎架構旨在支援下列目標可用性層級，以滿足大多數客戶工作負載的需求：
| 部署位置 | 可用性 (正常運作時間) % | 預估的最大停機時間 |
|---|---|---|
| 單一可用區 | 3 個 9：99.9% | 30 天月份的 43.2 分鐘 |
| 區域中的多個可用區 | 4 個 9：99.99% | 30 天月份的 4.3 分鐘 |
| 多個區域 | 5 個九：99.999% | 30 天月份的 26 秒 |
上表中的可用率百分比為目標值。特定 Google Cloud 服務的服務水準協議 (SLA) 可能與這些可用性目標不同。舉例來說，Bigtable 執行個體的正常運作時間服務水準協議取決於叢集的數量、叢集在各個位置的分布情形，以及您設定的路由政策。
如果設定多叢集轉送政策，橫跨 3 個以上區域且具備叢集的 Bigtable 執行個體，其最低運作時間服務水準協議為 99.999%。不過，如果您設定單一叢集轉送政策，則無論叢集數量和分布為何，最少的服務水準協議運作時間為 99.9%。
本節的圖表顯示不同叢集大小的 Bigtable 例項，以及這些例項的正常運作時間服務水準協議差異。
單一叢集
下圖顯示單一叢集 Bigtable 例項，其最低的服務水準協議為 99.9%：
多個叢集
下圖顯示單一區域內多個可用區的多叢集 Bigtable 執行個體，以及多叢集轉送功能 (最低服務時間服務水準協議：99.99%)：
多個叢集
下圖顯示橫跨三個區域的多叢集 Bigtable 例項，並具備多叢集轉送功能 (最低服務時間 SLA：99.999%)：
匯總基礎架構可用性
如要在 Google Cloud中執行應用程式，您必須使用 VM 和資料庫等基礎架構資源。這些基礎架構資源共同構成應用程式的基礎架構堆疊。
下圖顯示Google Cloud 中基礎架構堆疊的範例，以及堆疊中每項資源的可用性服務水準協議：
此基礎架構堆疊範例包含下列 Google Cloud資源：
- 區域性外部應用程式負載平衡器會接收使用者要求並回應。
- 區域代管執行個體群組 (MIG) 是區域外部應用程式負載平衡器的後端。MIG 包含位於不同區域的兩個 Compute Engine VM。每個 VM 都會代管網路伺服器的執行個體。
- 內部負載平衡器會處理網路伺服器和應用程式伺服器執行個體之間的通訊。
- 第二個區域 MIG 是內部負載平衡器的後端。這個 MIG 有兩個位於不同可用區的 Compute Engine VM。每個 VM 都會代管應用程式伺服器的執行個體。
- 為高可用性而設定的 Cloud SQL 執行個體是應用程式的資料庫。主要資料庫執行個體會同步複製至待命資料庫執行個體。
如前述範例所示，基礎架構堆疊可提供的總可用性取決於下列因素：
Google Cloud 服務水準協議
您在基礎架構堆疊中使用的 Google Cloud 服務的正常運作時間服務水準協議，會影響您對堆疊可預期的最低總可用性。
下表比較部分服務的正常運作時間服務水準協議：
| 運算服務 | 每月正常運作時間服務水準協議 | 預估每月 30 天內的最大停機時間 |
|---|---|---|
| Compute Engine VM | 99.9% | 43.2 分鐘 |
| 多個可用區中的 GKE Autopilot Pod | 99.9% | 43.2 分鐘 |
| Cloud Run 服務 | 99.95% | 21.6 分鐘 |
| 資料庫服務 | 每月正常運作時間服務水準協議 | 預估每月 30 天內的最大停機時間 |
|---|---|---|
| PostgreSQL 適用的 Cloud SQL 執行個體 (企業版) | 99.95% | 21.6 分鐘 |
| PostgreSQL 適用的 AlloyDB 執行個體 | 99.99% | 4.3 分鐘 |
| Spanner 多區域執行個體 | 99.999% | 26 秒 |
如要瞭解其他 Google Cloud 服務的 SLA，請參閱Google Cloud 服務水準協議。
如上述表格所示，您為基礎架構堆疊的各層選擇的 Google Cloud 服務，會直接影響基礎架構堆疊的整體正常運作時間。如要提高在 Google Cloud 資源上部署的工作負載預期可用性，您可以佈建資源的備用執行個體，如下一節所述。
資源備援
資源備援是指為資源設定兩個以上的相同例項，並在群組中的所有資源上部署相同的工作負載。舉例來說，如要代管應用程式的網頁層級，您可以佈建包含多個相同 Compute Engine VM 的 MIG。
如果您將一組資源備援分散到多個失敗網域 (例如兩個 Google Cloud 區域)，該群組的可用資源可用性會高於群組中每個資源的正常運作時間服務水準協議。這項可用性較高，是因為群組中每個資源同時失敗的機率，低於單一失敗網域中資源同時失敗的機率。
舉例來說，如果資源的可用性服務水準協議為 99.9%，則資源失敗的機率為 0.001 (1 減去服務水準協議)。如果您將工作負載分散到兩個在不同故障網域中佈建的此資源例項，兩個資源同時發生故障的機率為 0.000001 (即 0.001 x 0.001)。這個失敗機率會轉換為兩個資源群組的理論可用性 99.9999%。不過，您可以預期的實際可用性僅限於部署位置的目標可用性：如果資源位於單一Google Cloud 區域，可用性為 99.9%；如果是多區域部署，可用性為 99.99%；如果備援資源分散在多個區域，可用性則為 99.999%。
堆疊深度
基礎架構堆疊的深度是指堆疊中不重複的層級 (或層) 數量。基礎架構堆疊中的每個層級都包含為應用程式提供不同功能的資源。舉例來說，三層堆疊中的中間層可能會使用 Compute Engine VM 或 GKE 叢集來代管應用程式伺服器。基礎架構堆疊中的每個層級通常與相鄰層級有著緊密的相互依賴關係。也就是說，如果堆疊的任何層級無法使用，整個堆疊都會無法使用。
您可以使用下列公式計算 N 層基礎架構堆疊的預期總可用性：
舉例來說，如果三層堆疊中的每個層級都設計為提供 99.9% 的可用性，則堆疊的總可用性約為 99.7% (0.999 x 0.999 x 0.999)。也就是說，多層堆疊的總可用性低於提供最少可用性的層級的可用性。
堆疊中相互依賴的層級數量增加時，堆疊的總可用性就會降低，如下表所示。表格中的每個範例堆疊都有不同的層級數量，且每個層級都假設可提供 99.9% 的可用性。
| 級別 | Stack A | Stack B | Stack C |
|---|---|---|---|
| 前端 | 99.9% | 99.9% | 99.9% |
| 應用程式層 | 99.9% | 99.9% | 99.9% |
| 中層 | – | 99.9% | 99.9% |
| 資料級別 | – | – | 99.9% |
| 分疊的總供應情形 | 99.8% | 99.7% | 99.6% |
| 估算的 30 天內堆疊停機時間上限 | 86 分鐘 | 130 分鐘 | 173 分鐘 |
設計注意事項摘要
設計應用程式時，請考量Google Cloud 基礎架構堆疊的總可用性。
- 基礎架構堆疊中每個 Google Cloud 資源的可用性，會影響堆疊的匯總可用性。選擇 Google Cloud 服務來建構基礎架構堆疊時，請考慮服務的可用性 SLA。
- 如要改善資源提供的函式 (例如運算或資料庫) 可用性，您可以佈建資源的備援執行個體。設計含有備援資源的架構時，除了可用性優勢之外，您還必須考量對營運複雜度、延遲時間和成本的潛在影響。
- 基礎架構堆疊中的層級數量 (即堆疊深度) 與堆疊的總可用性呈現反比關係。設計或修改堆疊時，請考量這項關係。
如需匯總可用度的計算範例，請參閱下列章節：
地點範圍
Google Cloud 資源的位置範圍會決定基礎架構失敗對資源的影響程度。您在 Google Cloud 中佈建的大部分資源都會具有下列其中一個位置範圍：區域、區域、多區域或全球。
部分資源類型的地區範圍是固定的，也就是說，您無法選擇或變更地區範圍。舉例來說，虛擬私有雲 (VPC) 網路是全域性資源，而 Compute Engine 虛擬機器 (VM) 是區域性資源。對於某些資源，您可以在配置資源時選擇位置範圍。舉例來說，建立 Google Kubernetes Engine (GKE) 叢集時，您可以選擇建立區域或地區 GKE 叢集。
以下各節會進一步說明位置範圍。
可用區資源
可用區資源會部署在 Google Cloud區域的單一可用區中。以下是區域資源的範例。這份清單僅列出部分示例。
- Compute Engine VM
- 區域代管執行個體群組 (MIG)
- 可用區永久磁碟
- 單一可用區 GKE 叢集
- Filestore Basic 和 Zonal 執行個體
- Dataflow 工作
- Cloud SQL 執行個體
- Compute Engine 上的 Dataproc 叢集
可用區發生故障時，可能會影響該可用區內佈建的可用區資源。區域的設計目的，是盡可能降低與該區域其他區域相關聯的故障風險。一個可用區發生故障時，通常不會影響該區域中其他可用區的資源。此外，區域中的故障不一定會導致該區域的所有基礎架構無法使用。區域只會定義預期的失敗效應邊界。
如要保護使用區域資源的應用程式，避免發生區域事件，您可以在多個區域或地區中分散或複製資源。詳情請參閱「為 Google Cloud的工作負載設計可靠的基礎架構」。
地區資源
區域性資源會在區域內的多個可用區備援部署。以下是區域性資源的範例。這份清單僅列出部分示例。
- 地區性 MIG
- 區域性 Cloud Storage 值區
- 區域性永久磁碟
- 採用預設 (多區) 設定的區域性 GKE 叢集
- 虛擬私人雲端子網路
- 區域性外部應用程式負載平衡器
- 區域 Spanner 執行個體
- Filestore Enterprise 執行個體
- Cloud Run 服務
區域性資源可因應特定可用區發生的事件。區域停機可能會影響該區域內部分或所有區域資源。這類中斷服務的情況可能是由自然災害或大規模基礎架構故障造成。
多區域資源
多區域資源會分散到特定區域。以下是多地區資源的範例。請注意，這份清單僅列出部分示例。
- 雙區域和多區域 Cloud Storage 值區
- 多區域 Spanner 執行個體
- 多叢集 (多區域) Bigtable 執行個體
- Cloud Key Management Service 中的多區域鑰匙圈
如需多區域設定中可用的 Google 服務完整清單，請參閱依地區提供的產品。
多區域資源可在特定區域和可用區發生事件時保持彈性。在多個區域發生基礎架構中斷服務的情況，可能會影響在受影響區域中佈建的部分或所有多區域資源的可用性。
全球性資源
全球資源可供所有 Google Cloud 位置使用。以下是全球資源的範例。請注意，這份清單僅列出部分示例。
專案。如需有關將Google Cloud 資源分類至資料夾和專案的指導方針和最佳做法，請參閱「為 Google Cloud 目標區決定資源階層」。
虛擬私有雲網路 (包括相關路徑和防火牆規則)
Cloud DNS 區域
全域外部應用程式負載平衡器
Cloud Key Management Service 中的全域鑰匙圈
Pub/Sub 主題
Secret Manager 中的密鑰
如需全球適用的 Google 服務完整清單，請參閱全球產品。
全球資源可因應區域和區域性事件。這些資源不依賴任何特定區域的基礎架構。 Google Cloud 擁有系統和程序，有助於將全球基礎架構中斷的風險降至最低。Google 也會持續監控基礎架構，並迅速解決任何全球性中斷問題。
下表概略說明區域、地區、多區域和全球資源，相對於應用程式和基礎架構問題的相對復原能力。並說明設定這些資源所需的努力，以及如何減輕服務中斷的影響。
| 資源範圍 | 營運韌性 | 減少基礎架構中斷影響的最佳做法 |
|---|---|---|
| 可用區 | 低 | 在多個可用區或區域中備援部署資源。 |
| 區域 | 中 | 在多個區域中備援部署資源。 |
| 多地區或全球 | 高 | 請仔細管理變更，並盡可能使用多層防護的備用機制。詳情請參閱「管理全域資源停機風險的建議」。 |
管理全球資源中斷風險的建議
如要利用全域資源對區域和區域中斷的復原能力，建議您在架構中使用特定全域資源。Google 建議您採用下列方法，管理全球資源中斷的風險：
謹慎管理全域資源的變更
全球資源可在實體故障時恢復正常。這類資源的設定屬於全域範圍。因此，設定單一全球資源比操作多個區域資源更容易。不過，全域資源的設定中若出現重大錯誤，可能會導致單一故障點 (SPOF)。舉例來說，您可以將全域負載平衡器用於地理分散應用程式的前端。全球負載平衡器通常是這類應用程式不錯的選擇。不過，負載平衡器的設定錯誤可能會導致其在所有地區都無法使用。為避免這種風險，您必須謹慎管理全域資源的設定變更。詳情請參閱「控制全域資源的變更」。
使用地區資源做為深入防禦備用機制
對於可用性要求極高的應用程式，區域深層防禦備援機制有助於將全球資源中斷的影響降至最低。請考慮以下範例：地理分散的應用程式，其前端設有全域負載平衡器。如要確保即使全域負載平衡器受到全域停機事件影響，應用程式仍可供存取，您可以部署區域負載平衡器。您可以將用戶端設為優先使用全域負載平衡器，但如果全域負載平衡器無法使用，則會改為備援至最近的區域負載平衡器。
包含區域、區域和全域資源的架構範例
雲端拓樸圖可包含區域、區域和全球資源的組合，如下圖所示。下圖顯示在Google Cloud中部署的多層應用程式架構範例。
如上圖所示，全域外部 HTTP/S 負載平衡器會接收用戶端要求。負載平衡器會將要求分配給後端，後端是具有兩個 Compute Engine VM 的地區性 MIG。在 VM 上執行的應用程式會將資料寫入 Cloud SQL 資料庫，並從中讀取資料。資料庫已設定為高可用性。資料庫的主要和待命執行個體會在不同的區域中佈建，並將主要資料庫同步複製到待命資料庫。此外，資料庫會自動備份到 Cloud Storage 中的多區域值區。
下表概述上述架構中的 Google Cloud 資源，以及各項資源在可用區和區域停機時的復原能力：
| 資源 | 停機復原 |
|---|---|
| 虛擬私有雲網路 | 虛擬私有雲網路 (包括相關路徑和防火牆規則) 屬於全球資源，可在可用區和區域停機時持續運作。 |
| 子網路 | VPC 子網路是地區性資源。可在區域服務中斷時恢復運作。 |
| 全域外部 HTTP/S 負載平衡器 | 全域外部 HTTP/S 負載平衡器可在區域和區域發生中斷時維持運作。 |
| 區域性 MIG | 地區性 MIG 不受區域服務中斷影響。 |
| Compute Engine VM | Compute Engine VM 是區域資源。如果發生區域停機，個別 Compute Engine VM 可能會受到影響。不過，由於負載平衡器的後端是地區 MIG，而非獨立 VM，因此應用程式可以繼續提供要求。 |
| Cloud SQL 執行個體 | 這個架構中的 Cloud SQL 部署已設定為高可用性，也就是說，部署作業會包含一組主/備用資料庫執行個體。主要資料庫會使用地區永久磁碟，同步複製至待命資料庫。
|
| 多區域 Cloud Storage 值區 | 儲存在多地區 Cloud Storage 值區中的資料，可在單一地區發生停機時保持運作。 |
| 永久磁碟 | 永久磁碟可以是區域或區域性資源。地區永久磁碟可在區域停機時持續運作。如要準備從區域停機中復原，您可以排定永久磁碟的快照，並將快照儲存在多區域 Cloud Storage 值區中。 |