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 秒 |
上表中的可用性百分比是目標。特定服務的正常運作時間服務水準協議 (SLA) 可能與這些可用性目標不同。 Google Cloud 舉例來說，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 都代管一個網路伺服器執行個體。
- 內部負載平衡器會處理 Web 伺服器和應用程式伺服器之間的通訊。
- 第二個區域性 MIG 是內部負載平衡器的後端。 這個 MIG 有兩個位於不同可用區的 Compute Engine VM。每個 VM 都代管應用程式伺服器的執行個體。
- 設定為高可用性的 Cloud SQL 執行個體是應用程式的資料庫。主要資料庫執行個體會同步複製到待機資料庫執行個體。
上述範例等基礎架構堆疊的匯總可用性取決於下列因素：
Google Cloud 服務水準協議
基礎架構堆疊中使用的 Google Cloud 服務正常運作時間 SLA，會影響堆疊可達到的最低總可用性。
下表比較部分服務的運作時間服務水準協議：
| 運算服務 | 每月正常運作時間服務水準協議 | 30 天內預估最長停機時間 |
|---|---|---|
| Compute Engine VM | 99.9% | 43.2 分鐘 |
| 多個區域中的 Google Kubernetes Engine (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) 則是區域資源。對於特定資源，您可以在佈建資源時選擇位置範圍。舉例來說，建立 GKE 叢集時，您可以選擇建立可用區或區域 GKE 叢集。
以下各節將詳細說明位置範圍。
可用區資源
可用區資源會部署在區域的單一可用區中。 Google Cloud 以下是區域資源的範例。請注意，這份清單僅列出部分示例。
- Compute Engine VM
- 區域性 MIG
- Google Cloud Hyperdisk 磁碟區
- 單一可用區 GKE 叢集
- Filestore Basic 和 Zonal 執行個體
- Dataflow 工作
- Cloud SQL 執行個體
- Compute Engine 上的 Managed Service for Apache Spark 叢集
如果可用區發生故障，可能會影響在該可用區內佈建的可用區資源。可用區的設計宗旨是盡量降低區域內其他可用區發生相關故障的風險。一個可用區發生故障時，通常不會影響該區域其他可用區的資源。此外，可用區發生故障時，不一定會導致該可用區的所有基礎架構無法使用。這個區域只是定義失敗影響的預期範圍。
如要保護使用可用區資源的應用程式，避免發生可用區事件，您可以將資源分散或複製到多個可用區或區域。詳情請參閱「為 Google Cloud中的工作負載設計可靠的基礎架構」。
地區資源
區域性資源會在區域內的多個可用區備援部署。以下是區域資源的範例。請注意，這份清單僅列出部分示例。
- 地區性 MIG
- 區域型 Cloud Storage bucket
- Hyperdisk Balanced High Availability 磁碟區
- 採用預設 (多區域) 設定的區域性 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)。舉例來說，您可能會使用全域負載平衡器，做為地理位置分散式應用程式的前端。這類應用程式通常很適合使用全域負載平衡器。不過，如果負載平衡器設定有誤，可能會導致所有地理區域都無法使用。為避免這種風險，您必須謹慎管理全域資源的設定變更。詳情請參閱「控管全域資源的變更」。
使用區域資源做為深入防禦的回溯機制
對於可用性要求極高的應用程式，區域縱深防禦備援機制有助於盡量減少全球資源中斷的影響。以地理位置分散式應用程式為例，這類應用程式的前端是全域負載平衡器。為確保應用程式在全域負載平衡器受到全球性服務中斷影響時仍可存取，您可以部署區域負載平衡器。您可以將用戶端設定為偏好使用全域負載平衡器，但如果全域負載平衡器無法使用，則會容錯移轉至最接近的區域負載平衡器。
如要防範全域負載平衡器服務中斷和設定錯誤，可以使用 Cloud DNS 和區域備份負載平衡器，實作自動容錯移轉或略過策略。詳情請參閱「全域外部應用程式負載平衡器的容錯移轉策略」。
包含可用區、區域和全域資源的架構範例
如以下圖表所示，您的雲端拓撲可包含區域、區域和全域資源的組合。下圖顯示在Google Cloud中部署的多層應用程式範例架構。
如上圖所示，全域外部應用程式負載平衡器會接收用戶端要求。負載平衡器會將要求分配至後端，也就是具有兩個 Compute Engine VM 的區域性 MIG。在 VM 上執行的應用程式會將資料寫入 Cloud SQL 資料庫，並從中讀取資料。資料庫已設定為高可用性。資料庫的主要和待命執行個體會佈建在不同區域，且主要資料庫會同步複製到待命資料庫。此外，資料庫會自動備份到 Cloud Storage 中的多區域 bucket。
下表摘要說明上述架構中的 Google Cloud 資源，以及各資源在區域和可用區中斷時的復原能力：
| 資源 | 服務中斷的韌性 |
|---|---|
| 虛擬私有雲網路 | 虛擬私有雲網路 (包括相關聯的路徑和防火牆規則) 屬於全域資源。可避免區域和可用區中斷服務。 |
| 子網路 | 虛擬私有雲子網路是區域資源。可用區中斷時，系統仍可正常運作。 |
| 全域外部應用程式負載平衡器 | 全域外部應用程式負載平衡器可抵禦可用區和區域中斷。 |
| 區域 MIG | 區域性 MIG 可在可用區服務中斷時正常運作。 |
| Compute Engine VM | Compute Engine VM 是區域資源。如果發生可用區中斷事件，個別 Compute Engine VM 可能會受到影響。不過，應用程式可以繼續處理要求，因為負載平衡器的後端是區域性 MIG，而不是獨立 VM。 |
| Cloud SQL 執行個體 | 這個架構中的 Cloud SQL 部署作業已設定為高可用性，也就是說，部署作業包含一對主要/待命資料庫執行個體。主要資料庫會使用 Hyperdisk Balanced High Availability 磁碟區，以同步方式複製到待機資料庫。
|
| 多區域 Cloud Storage bucket | 儲存在多區域 Cloud Storage bucket 中的資料，可避免單一區域發生中斷。 |
| Hyperdisk 磁碟區 | Hyperdisk 磁碟區是可用區資源。如要使用高可用性，可以採用 Hyperdisk Balanced High Availability 磁碟區。資料會在同一區域的兩個可用區之間同步複製。如要準備從區域服務中斷事件復原，您可以排定 Hyperdisk 磁碟區的快照，並將快照儲存在多區域 Cloud Storage 值區中。 |