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 個 9：99.999% | 在 30 天的月份中，26 秒 |
上表中的可用性百分比為目標值。特定 Google Cloud 服務的正常運作時間服務水準協議 (SLA)可能與這些可用性目標不同。舉例來說，Bigtable 執行個體的正常運作時間服務水準協議取決於叢集數量、叢集在各個位置的分布情形，以及您設定的路由政策。
如果設定多叢集轉送政策，Bigtable 執行個體在三個以上區域中具有叢集時，最低運作時間服務水準協議為 99.999%。不過，如果設定單一叢集轉送政策，無論叢集數量和分布情形為何，最低運作時間服務水準協議都是 99.9%。
本節的圖表顯示叢集大小不同的 Bigtable 執行個體，以及這些差異對正常運作時間服務水準協議造成的影響。
單一叢集
下圖顯示單一叢集 Bigtable 執行個體，最低運作時間服務水準協議為 99.9%：
多個叢集
下圖顯示單一地區內多個可用區中的多叢集 Bigtable 執行個體，以及多叢集轉送 (最低正常運作時間服務水準協議：99.99%)：
多個叢集
下圖顯示位於三個區域的多叢集 Bigtable 執行個體，並設有多叢集轉送 (最低正常運作時間服務水準協議：99.999%)：
匯總基礎架構可用性
本節說明如何在 Google Cloud中計算基礎架構堆疊的匯總可用性。本文說明影響匯總可用性的因素，並提供計算範例。
如要在 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 服務運作時間 SLA，會影響堆疊的最低總可用性。
下表比較部分服務的正常運作時間服務水準協議：
| 運算服務 | 每月正常運作時間服務水準協議 | 預估 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 分鐘 |
| AlloyDB for PostgreSQL 執行個體 | 99.99% | 4.3 分鐘 |
| Spanner 多區域執行個體 | 99.999% | 26 秒 |
如要查看其他 Google Cloud 服務的服務水準協議，請參閱「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% 的可用性。
| 級別 | 堆疊 A | 堆疊 B | 堆疊 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 服務來建構基礎架構堆疊時，請考慮服務的可用性服務等級協議。
- 如要提高資源提供的函式 (例如運算或資料庫) 可用性，可以佈建資源的備援執行個體。使用備援資源設計架構時，除了可用性優勢之外，您也必須考量對作業複雜度、延遲時間和成本的潛在影響。
- 基礎架構堆疊中的層級數量 (即堆疊的深度) 與堆疊的整體可用性成反比。設計或修改堆疊時，請考量這項關係。
如需更多匯總可用性計算範例，請參閱下列章節：
位置範圍
資源的位置範圍決定了基礎架構故障對資源的影響程度。 Google Cloud 您在 Google Cloud 中佈建的大多數資源都具有下列其中一個位置範圍：可用區、區域、多區域或全球。
部分資源類型的地點範圍是固定的，也就是說，您無法選擇或變更地點範圍。舉例來說，虛擬私有雲 (VPC) 網路是全域資源，而 Compute Engine 虛擬機器 (VM) 則是區域資源。對於特定資源，您可以在佈建資源時選擇位置範圍。舉例來說，建立 Google Kubernetes Engine (GKE) 叢集時，您可以選擇建立區域或地區 GKE 叢集。
下列各節將詳細說明位置範圍。
可用區資源
可用區資源會部署在「區域」的單一可用區中。 Google Cloud以下是區域資源的範例。請注意，這份清單僅列出部分示例。
- Compute Engine VM
- 區域代管執行個體群組 (MIG)
- 可用區永久磁碟
- 單一可用區 GKE 叢集
- Filestore Basic 和可用區執行個體
- Dataflow 工作
- Cloud SQL 執行個體
- Compute Engine 上的 Dataproc 叢集
可用區發生故障時，可能會影響在該可用區內佈建的可用區資源。可用區的設計宗旨是盡量降低與同一區域中其他可用區發生相關故障的風險。一個可用區發生故障時，通常不會影響該區域其他可用區的資源。此外，某個區域發生故障時，不一定會導致該區域的所有基礎架構無法使用。區域只會定義故障影響的預期邊界。
如要保護使用區域資源的應用程式，避免發生區域事件，您可以將資源分散或複製到多個區域或地區。詳情請參閱為 Google Cloud中的工作負載設計可靠的基礎架構。
地區資源
區域性資源會部署在區域內的多個可用區，並提供備援機制。以下是區域資源的範例。請注意，這份清單僅列出部分示例。
- 地區性 MIG
- 區域型 Cloud Storage bucket
- 區域性永久磁碟
- 預設 (多區域) 設定的區域性 GKE 叢集
- 虛擬私人雲端子網路
- 區域性外部應用程式負載平衡器
- 區域 Spanner 執行個體
- Filestore Enterprise 執行個體
- Cloud Run 服務
區域資源可抵禦特定可用區的事件。區域中斷可能會影響該區域內的部分或所有區域資源。這類中斷可能是天災或大規模基礎架構故障所致。
多區域資源
多區域資源會分散到特定區域。以下是多區域資源的範例。請注意，這份清單僅列出部分示例。
- 雙區域和多區域 Cloud Storage bucket
- 多區域 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 資源，以及各資源在可用區和區域中斷時的復原能力：
| 資源 | 避免服務中斷 |
|---|---|
| 虛擬私有雲網路 | 虛擬私有雲網路 (包括相關聯的路徑和防火牆規則) 屬於全域資源。可避免可用區和區域中斷。 |
| 子網路 | 虛擬私有雲子網路是區域性資源。可避免區域中斷。 |
| 全域外部 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 值區中。 |