如「平台可用性」一文所述，Google Cloud 基礎架構的設計目標是，在單一可用區部署工作負載時，可用性可達 99.9%。多可用區部署的目標可用性為 99.99% 1，多地區部署的目標可用性則為 99.999%。本節的Google Cloud 基礎架構可靠性指南提供部署指引、範例架構和設計技術，協助您防範資源、可用區和區域層級的故障，保護工作負載。
避免單點故障
應用程式通常由多個相互依存的元件組成，每個元件都設計用於執行特定功能。這些元件通常會根據執行的功能和與其他元件的關係，分組為不同層級。舉例來說，提供內容的應用程式可能會有三個層級：包含負載平衡器和網路伺服器的網路層級；包含應用程式伺服器叢集的應用程式層級；以及用於保存資料的資料層級。如果這個應用程式堆疊的任何元件依附於單一基礎架構資源，該資源發生故障可能會影響整個堆疊的可用性。舉例來說，如果應用程式層在單一 VM 上執行，而該 VM 當機，則整個堆疊都會無法使用。這類元件是單點故障 (SPOF)。
應用程式堆疊可能有多個 SPOF。請參考下圖所示的多層應用程式堆疊：
如上圖所示，這個架構範例包含單一負載平衡器、兩個網頁伺服器、單一應用程式伺服器和單一資料庫。這個範例中的負載平衡器、應用程式伺服器和資料庫都是 SPOF。如果任何元件發生故障，使用者對應用程式的要求就會失敗。
如要移除應用程式堆疊中的 SPOF，請將資源分散到各個位置，並部署備援資源。
分配資源並建立備援機制
您可以根據應用程式的可靠性需求，選擇下列部署架構：
| 架構 | 工作負載建議 |
|---|---|
| 多區域 | 重要業務工作負載，且必須具備高可用性，例如零售和社群媒體應用程式。 |
| 多可用區 | 工作負載需要防範可用區中斷，但可容忍區域中斷造成的停機時間。 |
| 單一可用區 | 可容許停機，或必要時可輕鬆部署至其他位置的工作負載。 |
成本、延遲時間和作業注意事項
設計具有備援資源的分散式架構時，除了應用程式的可用性需求外，您也必須考量對作業複雜度、延遲和成本的影響。
在分散式架構中，您會佈建及管理更多資源。跨地區網路流量較高。您也會儲存及複製更多資料。因此，分散式架構中的雲端資源成本較高，且這類部署作業的複雜度也較高。對於重要業務應用程式，分散式架構的可用性優勢可能大於成本增加和運作複雜度。
對於非重要業務的應用程式，分散式架構提供的高可用性可能不是必要條件。某些應用程式有比可用性更重要的其他需求。舉例來說，批次運算應用程式需要 VM 之間的低延遲和高頻寬網路連線。單一區域架構可能很適合這類應用程式，也有助於降低資料傳輸費用。
部署作業架構
本節將介紹下列架構選項，協助您在 Google Cloud中為工作負載建構基礎架構：
單一可用區部署作業
下圖顯示單一區域應用程式架構，每個層級都有備援機制，可提高每個元件執行功能的可用性：
如上圖所示，這個範例架構包含下列元件：
- 區域型外部 HTTP/S 負載平衡器，用於接收及回應使用者要求。
- 區域代管執行個體群組 (MIG)，做為 HTTP/S 負載平衡器的後端。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)，您可以部署區域資源。
下圖顯示高可用性的跨區域架構，應用程式堆疊各層的元件分布在兩個區域：
如上圖所示，這個範例架構包含下列元件：
- 區域型外部 HTTP/S 負載平衡器會接收及回應使用者要求。
- 區域性 MIG 是 HTTP/S 負載平衡器的後端。MIG 包含不同可用區中的兩個 Compute Engine VM。每個 VM 都代管一個網路伺服器執行個體。
- 內部負載平衡器會處理網路伺服器與應用程式伺服器執行個體之間的通訊。
- 第二個區域性 MIG 是 TCP 負載平衡器的後端。這個 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 區域。
- 每個區域都有區域型外部 HTTP/S 負載平衡器，可接收及回應使用者要求。
- 每個區域性 HTTP/S 負載平衡器的後端都是區域性 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 程序和工具
詳情請參閱「影響應用程式穩定性的因素」。
服務中斷的影響，以及復原指南
如果這個多區域部署中的任何元件發生故障，但每個層級至少有一個運作正常的元件，且容量充足，應用程式就會繼續運作。舉例來說，如果網頁伺服器執行個體發生故障，區域外部 HTTP/S 負載平衡器會將使用者要求轉送至該區域的其他網頁伺服器執行個體。同樣地，如果其中一個應用程式伺服器執行個體當機，內部負載平衡器會將要求傳送至其他應用程式伺服器執行個體。如果任何 VM 發生當機情形，MIG 會確保自動建立新的 VM，以維持設定的 VM 數量下限。
單一可用區發生中斷不會影響負載平衡器，因為負載平衡器是區域資源，可因應可用區中斷。可用區中斷可能會影響個別 Compute Engine VM。但由於 VM 屬於區域 MIG，因此網路伺服器和應用程式伺服器執行個體仍可使用。MIG 可確保系統自動建立新的 VM，以維持設定的 VM 最少數量。這個架構中的 Spanner 執行個體採用多區域設定，可靈活應對區域中斷。
如要瞭解 Spanner 中的多區域複製功能，請參閱「 區域和多區域設定」和「 解密 Spanner 多區域設定」。
下圖與上圖顯示相同的多區域架構，以及單一區域中斷對應用程式可用性的影響：
如上圖所示，即使任何區域的兩個可用區都發生中斷，應用程式仍可正常運作，因為每個區域都部署了獨立的應用程式堆疊。DNS 區域會將使用者要求導向至不受服務中斷影響的區域。多區域 Spanner 執行個體可應對區域服務中斷。Google 解決中斷問題後，請務必確認應用程式在發生中斷的區域中正常運作。
如果這個架構中的任兩個區域發生中斷，應用程式就會無法使用。請等待 Google 解決服務中斷問題。然後，確認應用程式在部署的所有區域中都能如預期運作。
如果是多區域部署，建議使用全域負載平衡器，而非區域負載平衡器。下一節將介紹使用全域負載平衡器的多區域部署架構，並說明該方法的優點和風險。
使用全域負載平衡進行多區域部署
下圖顯示替代的多區域部署方式，使用全域負載平衡器而非區域負載平衡器：
如上圖所示，此架構會使用全域外部 HTTP/S 負載平衡器 (已啟用 Cloud CDN)，接收及回應使用者要求。負載平衡器的每個轉送規則都會使用單一外部 IP 位址，因此您不必為每個區域設定個別的 DNS 記錄。全域外部 HTTP/S 負載平衡器的後端是兩個區域 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 程序和工具
詳情請參閱「影響應用程式穩定性的因素」。
服務中斷的影響，以及復原指南
如果這個架構中的任何元件發生故障，只要每個層級中至少有一個運作正常的元件，且容量充足，應用程式就能繼續運作。舉例來說，如果網頁伺服器執行個體發生故障，全域外部 HTTP/S 負載平衡器會將使用者要求轉送至其他網頁伺服器執行個體。如果應用程式伺服器執行個體當機，內部負載平衡器會將要求傳送至其他應用程式伺服器執行個體。如果任何 VM 發生當機情形，MIG 會確保自動建立新的 VM，以維持設定的 VM 數量下限。
如果任何區域的其中一個可用區發生服務中斷，負載平衡器不會受到影響。全域外部 HTTP/S 負載平衡器可抵禦可用區和區域中斷。內部負載平衡器屬於區域性資源，因此可抵禦可用區中斷。可用區中斷可能會影響個別 Compute Engine VM。但由於 VM 屬於區域性 MIG，因此網路伺服器和應用程式伺服器執行個體仍可使用。MIG 可確保系統自動建立新的 VM，以維持設定的 VM 數量下限。這個架構中的 Spanner 執行個體使用多區域設定，可靈活應對區域中斷。
下圖與上圖顯示相同的多區域架構，以及單一區域中斷對應用程式可用性的影響：
如上圖所示，即使任何區域的兩個可用區都發生中斷，應用程式仍可正常運作，因為每個區域都部署了獨立的應用程式堆疊。全域外部 HTTP/S 負載平衡器會將使用者要求轉送至未受中斷影響的區域。多區域 Spanner 執行個體可應付區域服務中斷問題。Google 解決中斷問題後，請務必確認應用程式在發生中斷的區域中正常運作。
如要瞭解 Spanner 中的多區域複製功能，請參閱「 區域和多區域設定」和「 解密 Spanner 多區域設定」。
如果這個架構中的任兩個區域發生中斷，應用程式就會無法使用。全域外部 HTTP/S 負載平衡器可用，但沒有可用的後端，因此無法分配流量。請等待 Google 解決服務中斷問題。然後，確認應用程式在部署的所有區域中都能正常運作。
多區域部署作業可確保最重要的商務應用程式維持高可用性。為確保發生故障事件時業務不中斷，除了在多個區域部署應用程式，您還必須採取某些額外步驟。舉例來說，您必須執行 容量規劃，確保所有區域都保留足夠的容量，或緊急自動調度資源的相關風險可接受。您也必須實作 DR 測試的作業實務、管理事件、在事件後驗證應用程式狀態，以及執行回顧。