如平台可用性所述，Google Cloud 基礎架構旨在支援在單一可用區部署的工作負載，達到 99.9% 的目標可用性。多可用區部署的目標可用性為 99.99%，多地區部署則為 99.999%。1Google 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 基礎架構的開發運作技術程序和工具
詳情請參閱「影響應用程式可靠性的因素」。
服務中斷的影響，以及復原指南
在單一區域的部署架構中，如果任何元件發生故障，只要每個層級都包含至少一個運作正常且有足夠容量的元件，應用程式就能處理要求。舉例來說，如果網路伺服器執行個體發生故障，負載平衡器會將使用者要求轉送至其他網路伺服器執行個體。如果代管網路伺服器或應用程式伺服器執行個體的 VM 發生當機情形，MIG 會確保自動建立新的 VM。如果資料庫發生當機，您必須手動啟用第二個資料庫，並更新應用程式伺服器執行個體，才能連線至資料庫。
區域或地區停機會影響單一區域部署中的 Compute Engine VM 和 Cloud SQL 資料庫執行個體。區域停機不會影響這個架構中的負載平衡器，因為這是區域資源。不過，負載平衡器無法分配流量，因為沒有可用的後端。如果發生區域服務中斷，您必須等待 Google 解決中斷問題，然後確認應用程式是否正常運作。
下一節將說明您可用來在多個區域中分配資源的架構方法，這有助於提高應用程式在區域停機時的復原能力。
多可用區部署作業
在單一可用區部署中，如果發生可用區中斷，應用程式可能無法在問題解決前提供要求。為提高應用程式在區域服務中斷時的復原能力，您可以在兩個以上區域中佈建多個區域資源 (例如 Compute Engine VM) 執行個體。如果服務支援區域範圍的資源 (例如 Cloud Storage 值區)，您可以部署區域資源。
下圖顯示高可用性的跨區域架構，其中應用程式堆疊的各層元件會分散在兩個區域：
如上圖所示，此範例架構包含下列元件：
- 區域型外部 HTTP/S 負載平衡器會接收並回應使用者要求。
- 區域性 MIG 是 HTTP/S 負載平衡器的後端。MIG 包含位於不同區域的兩個 Compute Engine VM。每個 VM 都會代管網路伺服器的執行個體。
- 內部負載平衡器會處理網路伺服器和應用程式伺服器執行個體之間的通訊。
- 第二個區域 MIG 是 TCP 負載平衡器的後端。這個 MIG 在不同區域中含有兩個 Compute Engine VM。每個 VM 都會代管應用程式伺服器的執行個體。
- 為 HA 設定的 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 基礎架構的開發運作技術程序和工具
詳情請參閱「影響應用程式可靠性的因素」。
服務中斷的影響，以及復原指南
在雙區部署中，如果任何元件發生故障，只要每個層級至少有一個運作正常且容量足夠的元件，應用程式就能處理要求。舉例來說，如果網路伺服器執行個體發生故障，負載平衡器會將使用者要求轉送至其他區域的網路伺服器執行個體。如果代管網路伺服器或應用程式伺服器執行個體的 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 執行個體，並從中讀取資料。這個架構 (
eur5) 中使用的多地區設定包含四個讀寫備用資源。讀寫備援機制會在兩個區域和不同的可用區中平均配置。多區域 Spanner 設定也包含第三個區域中的見證備用資源。
總可用性：多地區部署，搭配地區性負載平衡
在上圖所示的多地區部署中，負載平衡器和 VM 會在兩個地區中備援式地佈建。DNS 區域是 全球資源，而 Spanner 執行個體是多區域資源。
如要計算此架構中顯示的 Google Cloud基礎架構的總可用性，我們必須先計算各區域的資源總可用性，然後再考量跨多個區域的資源。請按照下列程序操作：
- 計算基礎架構資源的總供應情形(按區域劃分)，也就是不含 DNS 和資料庫資源：
資源和服務水準協議 (SLA) 服務水準協議 外部負載平衡器 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 基礎架構的開發運作技術程序和工具
詳情請參閱「影響應用程式可靠性的因素」。
服務中斷的影響，以及復原指南
如果這個多區域部署作業中的任何元件發生故障，但每個層級至少有一個運作正常且有足夠容量的元件，應用程式就會繼續運作。舉例來說，如果網頁伺服器執行個體發生錯誤，區域外部 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 區域提供負載平衡。
- 全域負載平衡器可在區域發生中斷時恢復，並提供自動跨區域容錯移轉功能。
- 全球負載平衡器支援下列功能，有助於提升部署的可靠性：
以下是使用全域負載平衡器的架構可能面臨的風險：
- 全球負載均衡器的設定變更不正確，可能會導致使用者無法使用應用程式。舉例來說，如果您在更新全域負載平衡器的 frontend 時不小心刪除轉送規則，負載平衡器就會停止接收使用者要求。如果採用區域負載平衡器的多地區架構，這類風險的影響會較低，因為即使某個地區的區域負載平衡器受到設定錯誤的影響，其他地區的負載平衡器仍可繼續運作。
- 影響 全球資源的基礎架構中斷可能會導致全域負載平衡器無法使用。
為降低這些風險，您必須謹慎管理全域負載平衡器的變更，並視需要考慮使用多層防護的備用機制。詳情請參閱 管理全域資源停機風險的建議。
匯總可用性：採用全域負載平衡的多區域部署
在上圖所示的多區域部署作業中，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 基礎架構的開發運作技術程序和工具
詳情請參閱「影響應用程式可靠性的因素」。
服務中斷的影響，以及復原指南
如果這個架構中的任何元件發生故障，只要每個層級至少有一個運作正常且容量足夠的元件，應用程式就會繼續運作。舉例來說，如果網頁伺服器執行個體發生錯誤，全域外部 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 測試、事件管理、事件後應用程式狀態驗證，以及執行回顧。