如「平台可用性」一文所述，Google Cloud 基礎架構的設計目標是，在單一可用區部署工作負載時，可用性可達 99.9%。多可用區部署的目標可用性為 99.99% 1，多區域部署則為 99.999%。本節的Google Cloud 基礎架構可靠性指南提供部署指引、範例架構和設計技術，有助於保護工作負載，避免資源、可用區和區域層級發生故障。
避免單點故障
應用程式通常由多個相互依附的元件組成，每個元件都設計用於執行特定功能。這些元件通常會根據執行的功能和與其他元件的關係，分組為不同層級。舉例來說，提供內容的應用程式可能會有三個層級：包含負載平衡器和網路伺服器的網路層級；包含應用程式伺服器叢集的應用程式層級；以及用於保存資料的資料層級。如果這個應用程式堆疊的任何元件都依附於單一基礎架構資源，該資源發生故障時，整個堆疊的可用性都會受到影響。舉例來說，如果應用程式層在單一 VM 上執行，而 VM 當機，整個堆疊就會無法使用。這類元件就是單點故障 (SPOF)。
應用程式堆疊可能有多個 SPOF。請參考下圖所示的多層應用程式堆疊：
如上圖所示，這個範例架構包含單一負載平衡器、兩部網頁伺服器、單一應用程式伺服器和單一資料庫。在本範例中，負載平衡器、應用程式伺服器和資料庫都是 SPOF。如果其中任何一個元件發生故障，使用者對應用程式的要求就會失敗。
如要移除應用程式堆疊中的 SPOF，請將資源分散到各個位置，並部署備援資源。
分配資源並建立備援機制
您可以根據應用程式的可靠性需求，選擇下列部署架構：
| 架構 | 工作負載建議 |
|---|---|
| 多區域 | 重要業務工作負載，且高可用性 (HA) 至關重要，例如零售和社群媒體應用程式。 |
| 多可用區 | 工作負載需要具備可用區服務中斷時的復原能力，但可容忍區域服務中斷造成的停機時間。 |
| 單一可用區 | 可容許停機時間，或必要時可輕鬆部署至其他位置的工作負載。 |
費用、延遲時間和作業注意事項
使用備援資源設計分散式架構時，除了應用程式的可用性需求，您也必須考量對作業複雜度、延遲和成本的影響。
在分散式架構中，您需要佈建及管理更多資源。跨地區網路流量較高。您也可以儲存及複製更多資料。因此，分散式架構中的雲端資源成本較高，且這類部署作業的複雜度也較高。對於重要業務應用程式而言，分散式架構的可用性優勢可能大於成本增加和作業複雜度提高的缺點。
對於非業務關鍵的應用程式，分散式架構提供的高可用性可能不是必要條件。某些應用程式有其他比可用性更重要的需求。舉例來說，批次運算應用程式需要 VM 之間有低延遲和高頻寬的網路連線。單一區域架構可能很適合這類應用程式，也有助於降低資料移轉費用。
部署作業架構
本節將介紹下列架構選項，協助您在 Google Cloud中為工作負載建構基礎架構：
單一可用區部署作業
下圖顯示單一區域應用程式架構，每個層級都有備援機制，可提高各元件執行函式的可用性：
如上圖所示，這個範例架構包含下列元件：
- 區域性外部應用程式負載平衡器，用於接收及回應使用者要求。
- 區域外部應用程式負載平衡器的後端為區域代管執行個體群組 (MIG)。MIG 有兩個 Compute Engine VM。每個 VM 都代管一個網路伺服器執行個體。
- 區域性內部直通式網路負載平衡器，用於處理網頁伺服器和應用程式伺服器之間的通訊。
- 第二個區域性 MIG，做為內部負載平衡器的後端。這個 MIG 包含兩個 Compute Engine VM。每個 VM 都代管應用程式伺服器執行個體。
- 應用程式用來寫入及讀取資料的 Cloud SQL 資料庫執行個體 (Enterprise 版)。資料庫會手動複製到同一可用區的第二個 Cloud SQL 資料庫執行個體。
匯總可用性：單一可用區部署作業
下表顯示前述單一可用區架構圖中各層的可用性：
| 資源 | 服務水準協議 |
|---|---|
| 外部負載平衡器 | 99.99% |
| 網頁層：單一可用區中的 Compute Engine VM | 99.9% |
| 內部負載平衡器 | 99.99% |
| 應用程式層：單一可用區中的 Compute Engine VM | 99.9% |
| Cloud SQL 執行個體 (Enterprise 版，高可用性設定) | 99.95% |
預期前表 Google Cloud 列出的基礎架構資源可提供下列匯總可用性和預估每月最長停機時間：
- 總可用性：0.9999 x 0.999 x 0.9999 x 0.999 x 0.9995 = 99.73%
- 每月預估最長停機時間：約 1 小時 57 分鐘
這項計算只會考量前述架構圖中顯示的基礎架構資源。如要評估應用程式在 Google Cloud的可用性，您也必須考量其他因素，例如：
- 應用程式的內部設計
- 用於建構、部署及維護應用程式、應用程式依附元件和 Google Cloud 基礎架構的 DevOps 程序和工具
詳情請參閱「影響應用程式穩定性的因素」。
服務中斷的影響，以及復原指南
在單一區域部署架構中，如果任何元件發生故障，只要每個層級都包含至少一個運作正常的元件，且容量充足，應用程式就能處理要求。舉例來說，如果網路伺服器執行個體發生故障，負載平衡器會將使用者要求轉送至其他網路伺服器執行個體。如果代管網路伺服器或應用程式伺服器的 VM 發生當機情形，MIG 會確保系統自動建立新的 VM。如果資料庫當機，您必須手動啟動第二個資料庫，並更新應用程式伺服器執行個體，以連線至資料庫。
如果可用區或區域發生中斷，單一可用區部署中的 Compute Engine VM 和 Cloud SQL 資料庫執行個體都會受到影響。在這個架構中，區域性資源不會受到可用區中斷的影響。不過，由於沒有可用的後端，負載平衡器無法分配流量。如果發生區域中斷，您必須等待 Google 解決問題，然後確認應用程式是否正常運作。
下一節將說明一種架構方法，可用於在多個可用區中分配資源，有助於提升應用程式的可用區中斷復原能力。
多可用區部署作業
在單一可用區部署中，如果發生可用區中斷，應用程式可能無法處理要求，直到問題解決為止。為協助提高應用程式的可用區中斷韌性，您可以跨兩個以上的可用區，佈建多個可用區資源執行個體 (例如 Compute Engine VM)。對於支援區域範圍資源的服務 (例如 Cloud Storage bucket)，您可以部署區域資源。
下圖顯示高可用性跨區域架構，應用程式堆疊各層的元件分布於兩個區域：
如上圖所示，這個範例架構包含下列元件：
- 區域性外部應用程式負載平衡器會接收及回應使用者要求。
- 區域性 MIG 是區域性外部應用程式負載平衡器的後端。MIG 包含不同可用區中的兩個 Compute Engine VM。每個 VM 都代管一個網路伺服器執行個體。
- 區域性內部直通式網路負載平衡器會處理網頁伺服器和應用程式伺服器之間的通訊。
- 第二個區域性 MIG 是內部負載平衡器的後端。這個 MIG 有兩個位於不同可用區的 Compute Engine VM。每個 VM 都會代管應用程式伺服器執行個體。
- 設定為高可用性的 Cloud SQL 執行個體 (Enterprise 版) 是應用程式的資料庫。主要資料庫執行個體會同步複製到待命資料庫執行個體。
匯總可用性：多可用區部署作業
下表顯示前述雙可用區架構圖中各層的可用性：
| 資源 | 服務水準協議 |
|---|---|
| 外部負載平衡器 | 99.99% |
| 網頁層：位於不同可用區的 Compute Engine VM | 99.99% |
| 內部負載平衡器 | 99.99% |
| 應用程式層：不同可用區的 Compute Engine VM | 99.99% |
| Cloud SQL 執行個體 (Enterprise 版，高可用性設定) | 99.95% |
預期前表列出的 Google Cloud 基礎架構資源可提供下列匯總可用性和估計每月最長停機時間：
- 總可用性：0.9999 x 0.9999 x 0.9999 x 0.9999 x 0.9995 = 99.91%
- 預估每月最長停機時間：約 39 分鐘
這項計算只會考量前述架構圖中顯示的基礎架構資源。如要評估應用程式在 Google Cloud的可用性，您也必須考量其他因素，例如：
- 應用程式的內部設計
- 用於建構、部署及維護應用程式、應用程式依附元件和 Google Cloud 基礎架構的 DevOps 程序和工具
詳情請參閱「影響應用程式穩定性的因素」。
服務中斷的影響，以及復原指南
在雙區域部署中，如果任何元件發生故障，只要每個層級至少有一個運作正常的元件具備足夠容量，應用程式就能處理要求。舉例來說，如果網路伺服器執行個體發生故障，負載平衡器會將使用者要求轉送至其他區域的網路伺服器執行個體。如果代管網路伺服器或應用程式伺服器執行個體的 VM 發生當機情形，MIG 會確保系統自動建立新的 VM。如果主要 Cloud SQL 資料庫當機，Cloud SQL 會自動容錯移轉至待命資料庫執行個體。
下圖顯示與上圖相同的架構，以及區域中斷對應用程式可用性的影響：
如上圖所示，如果其中一個可用區發生中斷，這個架構中的負載平衡器不會受到影響，因為它是區域資源。可用區中斷可能會影響個別 Compute Engine VM 和其中一個 Cloud SQL 資料庫執行個體。但由於 VM 位於區域 MIG 中，且 Cloud SQL 資料庫已設定為高可用性，因此應用程式仍可正常運作並回應要求。MIG 會自動建立新的 VM，確保 VM 數量維持在設定的下限。如果主要 Cloud SQL 資料庫執行個體受到可用區中斷影響，Cloud SQL 會自動容錯移轉至其他可用區的待命執行個體。Google 解決中斷問題後，請務必確認應用程式在所有部署區域都能正常運作。
如果這個架構中的兩個可用區都發生中斷，應用程式就會無法使用。除非發生區域性中斷，否則負載平衡器會持續提供服務。不過，由於沒有可用的後端，負載平衡器無法分配流量。如果發生多區域或區域中斷，您必須等待 Google 解決中斷問題，然後確認應用程式是否正常運作。
接下來的章節將介紹架構選項，協助您防範多可用區和區域服務中斷問題。
透過區域性負載平衡進行多區域部署
在單一可用區或多可用區部署中，如果發生區域服務中斷，應用程式就無法處理要求，直到問題解決為止。如要保護應用程式免於區域性服務中斷的影響，您可以將 Google Cloud資源分散到兩個以上的區域。
下圖顯示高可用性的跨區域架構，應用程式堆疊各層的元件分散在多個區域：
如上圖所示，這個範例架構包含下列元件：
- 具有轉送政策的公開 Cloud DNS 區域，可將流量導向兩個 Google Cloud 區域。
- 每個區域都有區域性外部應用程式負載平衡器，可接收及回應使用者要求。
- 每個區域性外部應用程式負載平衡器的後端都是區域性 MIG。每個 MIG 包含不同可用區中的兩個 Compute Engine VM。每個 VM 都代管一個網路伺服器執行個體。
- 每個區域的區域性內部直通式網路負載平衡器，負責處理網頁伺服器和應用程式伺服器之間的通訊。
- 第二組區域性 MIG 是內部負載平衡器的後端。每個 MIG 都包含不同可用區中的兩個 Compute Engine VM。每個 VM 都代管應用程式伺服器執行個體。
- 應用程式會將資料寫入多區域 Spanner 執行個體，並從該執行個體讀取資料。這個架構 (
eur6) 使用的多區域設定包含四個讀寫備用資源。讀寫副本會平均佈建在兩個區域，且位於不同可用區。多區域 Spanner 設定也會在第三個區域中包含見證備用資源。
匯總可用性：透過區域負載平衡進行多區域部署
在上圖所示的多區域部署中，負載平衡器和 VM 會在兩個區域中以冗餘方式佈建。DNS 區域是 全域性資源，而 Spanner 執行個體是多區域資源。
如要計算這個架構中顯示的基礎架構總可用性，我們必須先計算每個區域中資源的總可用性，然後考量跨越多個區域的資源。 Google Cloud請按照下列程序操作：
- 計算每個區域的基礎架構資源總可用性，也就是排除 DNS 和資料庫資源：
資源和服務水準協議 服務水準協議 外部負載平衡器 99.99% 網頁層：位於不同可用區的 Compute Engine VM 99.99% 內部負載平衡器 99.99% 應用程式層：不同可用區的 Compute Engine VM 99.99% 每個區域的總可用性：0.9999 x 0.9999 x 0.9999 x 0.9999 = 99.96%
計算基礎架構資源的總可用性，並考量負載平衡器和 Compute Engine VM 的雙區域備援。
理論可用性為 1-(1-0.9996)(1-0.9996) = 99.999984%。 不過，您實際可達成的可用性，會受限於多區域部署的目標可用性，也就是 99.999%。
計算所有基礎架構資源的總體可用性，包括 Cloud DNS 和 Spanner 資源：
- 總可用性：0.99999 x 1 x 0.99999 = 99.998%
- 預估每月最長停機時間：約 52 秒
這項計算只會考量前述架構圖中顯示的基礎架構資源。如要評估應用程式在 Google Cloud的可用性，您也必須考量其他因素，例如：
- 應用程式的內部設計
- 用於建構、部署及維護應用程式、應用程式依附元件和 Google Cloud 基礎架構的 DevOps 程序和工具
詳情請參閱「影響應用程式穩定性的因素」。
服務中斷的影響，以及復原指南
如果這個多區域部署中的任何元件發生故障，但每個層級至少有一個運作正常的元件，且容量充足，應用程式就會繼續運作。舉例來說，如果網路伺服器執行個體發生故障，區域外部應用程式負載平衡器會將使用者要求轉送至該區域的其他網路伺服器執行個體。同樣地，如果其中一個應用程式伺服器執行個體當機，內部負載平衡器會將要求傳送至其他應用程式伺服器執行個體。如果任何 VM 發生當機情形，MIG 會確保自動建立新的 VM，以維持設定的 VM 數量下限。
單一可用區發生中斷不會影響負載平衡器，因為負載平衡器是區域資源，可抵禦可用區中斷。可用區中斷可能會影響個別 Compute Engine VM。但由於 VM 屬於區域 MIG，因此網路伺服器和應用程式伺服器執行個體仍可使用。MIG 可確保系統自動建立新的 VM，以維持設定的 VM 數量下限。這個架構中的 Spanner 執行個體使用多區域設定，可抵禦可用區中斷。
如要瞭解 Spanner 中的多區域複寫功能運作方式，請參閱「 區域和多區域設定」和「 解密 Spanner 多區域設定」。
下圖顯示與上圖相同的多區域架構，以及單一區域中斷對應用程式可用性的影響：
如上圖所示，即使任何區域的兩個可用區都發生中斷，應用程式仍可正常運作，因為每個區域都部署了獨立的應用程式堆疊。DNS 區域會將使用者要求導向未受中斷影響的區域。多區域 Spanner 執行個體可應對區域服務中斷。Google 解決中斷問題後，請務必確認應用程式在發生中斷的區域中正常運作。
如果這個架構中的任兩個區域發生中斷，應用程式就會無法使用。請等待 Google 解決服務中斷問題。然後，確認應用程式在所有部署區域都能正常運作。
如果是多區域部署作業，建議使用全域負載平衡器，而非區域負載平衡器。下一節將介紹使用全域負載平衡器的多區域部署架構，並說明該方法的優點和風險。
如要瞭解如何設計及設定 Cloud DNS 路由政策，搭配區域性外部負載平衡器，實現多區域韌性，請參閱「 區域性外部應用程式負載平衡器的高可用性」。
透過全域負載平衡進行多區域部署
下圖顯示替代的多區域部署作業，使用全域負載平衡器而非區域負載平衡器：
如上圖所示，這項架構使用全域外部應用程式負載平衡器 (已啟用 Cloud CDN)，接收及回應使用者要求。負載平衡器的每條轉送規則都會使用單一外部 IP 位址，因此您不需要為每個區域設定個別的 DNS 記錄。全域外部應用程式負載平衡器的後端是兩個區域性 MIG。負載平衡器會將要求轉送至距離使用者最近的區域。
這個架構中的所有其他元件，都與 使用區域負載平衡進行多區域部署中顯示的架構相同。
多區域部署的全球性負載平衡優點和風險
如要將外部流量負載平衡至分散在多個區域的應用程式，可以使用全域負載平衡器或多個區域負載平衡器。
使用全域負載平衡器的架構具有下列優點：
- 您只需要管理單一負載平衡器。
- 全域負載平衡器使用單一 Anycast IP 位址，在 Google Cloud 區域之間提供負載平衡。
- 全域負載平衡器可因應區域性服務中斷，並提供自動跨區域容錯移轉功能。
- 全域負載平衡器支援下列功能，可協助提升部署作業的可靠性：
使用全域負載平衡器的架構有下列風險：
- 如果全域負載平衡器設定變更錯誤，使用者可能無法存取應用程式。舉例來說，更新全域負載平衡器的前端時，如果意外刪除轉送規則，負載平衡器就會停止接收使用者要求。如果多區域架構使用區域負載平衡器，這項風險的影響就會降低，因為即使其中一個區域的區域負載平衡器受到設定錯誤影響，其他區域的負載平衡器仍會繼續運作。
- 如果基礎架構發生中斷，影響 全球資源，全域負載平衡器可能無法使用。
如要降低這些風險，您必須謹慎管理全域負載平衡器的變更，並盡可能使用縱深防禦備援。詳情請參閱「 建議：管理全球資源中斷風險」。
匯總可用性：多區域部署搭配全域負載平衡
在上圖所示的多區域部署中，VM 和內部負載平衡器會跨兩個區域部署，以確保備援。外部負載平衡器是 全域性資源，而 Spanner 執行個體是多區域資源。
如要計算這項部署作業的整體可用性，請先計算每個區域中資源的整體可用性，然後考量跨多個區域的資源。
- 計算每個區域的基礎架構資源總可用性，但不包括外部負載平衡器和資料庫：
資源 服務水準協議 網頁層：位於不同可用區的 Compute Engine VM 99.99% 內部負載平衡器 99.99% 應用程式層：不同可用區的 Compute Engine VM 99.99% 每個區域的匯總可用性：0.9999 x 0.9999 x 0.9999 = 99.97%
考量內部負載平衡器和 Compute Engine VM 的雙區域備援，計算基礎架構資源的總可用性。
理論可用性為 1-(1-0.9997)(1-0.9997) = 99.999991%。 不過，您實際可達到的可用性，會受限於多區域部署的目標可用性，也就是 99.999%。
計算所有基礎架構資源的匯總可用性，包括全域負載平衡器和 Spanner 資源：
- 總可用性：0.99999 x 0.9999 x 0.99999 = 99.988%
- 每月預估最長停機時間：約 5 分 11 秒
這項計算只會考量前述架構圖中顯示的基礎架構資源。如要評估應用程式在 Google Cloud的可用性，您也必須考量其他因素，例如：
- 應用程式的內部設計
- 用於建構、部署及維護應用程式、應用程式依附元件和 Google Cloud 基礎架構的 DevOps 程序和工具
詳情請參閱「影響應用程式穩定性的因素」。
服務中斷的影響，以及復原指南
如果這個架構中的任何元件發生故障，只要每個層級至少有一個運作正常的元件且容量充足，應用程式就能繼續運作。舉例來說，如果網路伺服器執行個體發生故障，全域外部應用程式負載平衡器會將使用者要求轉送至其他網路伺服器執行個體。如果應用程式伺服器執行個體當機，內部負載平衡器會將要求傳送至其他應用程式伺服器執行個體。如果任何 VM 發生當機情形，MIG 會確保系統自動建立新的 VM，以維持設定的 VM 數量下限。
如果任何區域的其中一個可用區發生服務中斷，負載平衡器不會受到影響。全域外部應用程式負載平衡器可抵禦區域和地區中斷。內部負載平衡器屬於區域資源，因此可因應可用區中斷。可用區中斷可能會影響個別 Compute Engine VM。但由於 VM 屬於區域性 MIG，因此網路伺服器和應用程式伺服器仍可正常運作。MIG 會確保自動建立新的 VM，以維持設定的 VM 數量下限。這個架構中的 Spanner 執行個體使用多區域設定，可靈活應對可用區中斷。
下圖顯示與上圖相同的多區域架構，以及單一區域中斷對應用程式可用性的影響：
如上圖所示，即使任何區域的兩個可用區都發生中斷，應用程式仍可正常運作，因為每個區域都部署了獨立的應用程式堆疊。全域外部應用程式負載平衡器會將使用者要求，轉送至未受中斷影響的區域中的應用程式。多區域 Spanner 執行個體可應對區域服務中斷。Google 解決中斷問題後，請務必確認應用程式在發生中斷的區域中正常運作。
如要瞭解 Spanner 中的多區域複製功能運作方式，請參閱「 單一區域和多區域設定」和「 解密 Spanner 多區域設定」。
如果這個架構中的任兩個區域發生中斷，應用程式就會無法使用。全域外部應用程式負載平衡器可用，但沒有可用的後端，因此無法分配流量。請等待 Google 解決服務中斷問題。然後，確認應用程式在所有部署區域都能正常運作。
多區域部署可確保最重要業務應用程式的高可用性。如要確保在發生故障事件時業務能持續運作，除了在多個區域部署應用程式，您還必須採取某些額外步驟。舉例來說，您必須執行容量規劃，確保所有區域都保留足夠的容量，或緊急自動調度資源相關風險可接受。您也必須實作 DR 測試的作業實務、管理事件、在事件後驗證應用程式狀態，以及執行回顧。
如要防範全域負載平衡器中斷和設定錯誤，您可以透過 Cloud DNS 和區域備份負載平衡器，實作自動容錯移轉或略過策略。詳情請參閱「 全域外部應用程式負載平衡器的容錯移轉策略」。