為雲端基礎架構中斷情形建立災難復原架構

Last reviewed 2024-05-10 UTC

本文是探討 Google Cloud中災難復原 (DR) 的系列文章之一。本單元將討論如何使用 Google Cloud 架構工作負載，以及建構可抵禦雲端基礎架構中斷的構成要素。

本系列包含以下單元：

簡介

企業將工作負載遷移至公有雲時，需要將建構彈性內部部署系統的知識，轉移至 Google Cloud等雲端供應商的超大規模基礎架構。本文會將 RTO (復原時間目標) 和 RPO (復原點目標) 等災難復原產業標準概念，對應至 Google Cloud基礎架構。

本文的指引遵循 Google 的一項重要原則，也就是「為失敗做好準備」，以實現極高的服務可用性。雖然Google Cloud 提供極為可靠的服務，但天災、光纖線路中斷和複雜的基礎架構故障等災害仍會發生，並導致服務中斷。規劃中斷事件可讓Google Cloud 客戶利用「內建」DR 機制，建構在這些不可避免的事件中可預測執行的應用程式 Google Cloud 。

災難復原是廣泛的主題，涵蓋的範圍遠不只基礎架構故障，例如軟體錯誤或資料毀損等，因此您應制定完整的端對端計畫。不過，本文著重於整體 DR 計畫的一部分：如何設計應用程式，確保在雲端基礎架構中斷時仍能正常運作。具體來說，本文將逐步說明：

  1. Google Cloud 基礎架構、災害事件如何導致Google Cloud 服務中斷，以及 Google Cloud 如何架構，以盡量減少服務中斷的頻率和範圍。
  2. 架構規劃指南，提供架構，可根據所需的可靠性結果分類及設計應用程式。
  3. 詳細清單：提供內建 DR 功能的精選 Google Cloud 產品，您可能會在應用程式中使用這些產品。

如要進一步瞭解一般 DR 規劃，以及如何在內部部署 DR 策略中使用 Google Cloud 做為元件，請參閱災難復原規劃指南。此外，雖然高可用性與災難復原密切相關，但本文不會涵蓋這項概念。如要進一步瞭解如何設計高可用性架構，請參閱 Well-Architected Framework。

術語說明：本文討論產品在一段時間內可供有意義地存取和使用的能力時，會使用「可用性」一詞，而「可靠性」則是指一組屬性，包括可用性，以及耐用性和正確性等。

如何 Google Cloud 設計成具備韌性

Google 資料中心

傳統資料中心著重於盡可能提高個別元件的可用性，在雲端，Google 等營運商可運用虛擬化技術，將服務分散到許多元件，因此擴充性可超越傳統元件的可靠性。也就是說，您不必再像過去一樣，為內部部署環境的無數細節操心，可以將可靠性架構的思維轉移到其他方面。您不必擔心冷卻和供電等元件的各種故障模式，可以根據 Google Cloud 產品及其聲明的可靠性指標進行規劃。這些指標反映了整個基礎架構的整體中斷風險。這樣您就能專注於應用程式設計、部署和作業，不必費心管理基礎架構。

Google 根據豐富的現代資料中心建構和營運經驗，設計基礎架構來達成嚴格的可用性目標。Google 是資料中心設計領域的全球領導者。從電力、冷卻到網路，每項資料中心技術都有自己的備援和緩解措施，包括 FMEA 計畫。Google 資料中心的建置方式可平衡這些不同風險，並為客戶提供 Google Cloud 產品一致的預期可用性。Google 會運用自身經驗，模擬整體實體和邏輯系統架構的可用性，確保資料中心設計符合預期。Google 工程師會盡力確保這些期望得以實現。實際測得的可用性通常會大幅超過設計目標。

Google 會將所有資料中心風險和緩解措施，整合到使用者可存取的產品中， Google Cloud 讓您不必承擔這些設計和營運責任。您可以專注於Google Cloud 區域和可用區的可靠性設計。

地區與區域

「地區」是獨立的地理區域，由各「區域」組成。可用區和區域是基礎實體資源的邏輯抽象概念。如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。

Google Cloud 產品分為可用區資源、區域資源或多區域資源。

可用區資源託管在單一可用區中。該區域的服務中斷可能會影響該區域中的所有資源。舉例來說，Compute Engine 執行個體會在單一指定區域中執行；如果硬體故障導致該區域的服務中斷，Compute Engine 執行個體就會在服務中斷期間無法使用。

區域資源會部署在區域內的多個可用區，並提供備援機制。因此相較於可用區資源，區域資源的可靠性更高。

多區域資源分布於不同區域內，一般而言，多區域資源的可靠性高於區域資源。不過，在這個層級，產品必須提供最佳可用性、效能與資源效率，因此，請務必瞭解您決定使用的每個多區域產品所做的取捨。我們稍後將在本文件的具體產品說明中，說明這些權衡取捨的內容。

可用區、區域和多區域 Google Cloud 產品範例

如何運用可用區和地區提升可靠性

Google SRE 透過各種技術和方法，順暢運用全球的運算基礎架構，管理及擴充 Gmail 和 Google 搜尋等全球使用者產品，確保這些產品高度可靠。包括使用全域負載平衡將流量從無法使用的位置重新導向、在全球各地多個位置執行多個副本，以及跨位置複製資料。客戶可透過 Cloud Load Balancing、Google Kubernetes Engine (GKE) 和 Spanner 等產品，使用這些功能。 Google Cloud

Google Cloud 通常會設計產品，為區域和地區提供下列可用性等級：

資源 範例 可用性設計目標 隱含停機時間
可用區 Compute Engine、永久磁碟 99.9% 每年 8.75 小時
區域 區域性 Cloud Storage、複製的永久磁碟、區域性 GKE 99.99% 每年 52 分鐘

比較 Google Cloud 可用性設計目標與可接受的停機時間，找出合適的 Google Cloud 資源。傳統設計著重於提升元件層級的可用性，進而提高應用程式的可用性，而雲端模型則著重於元件組合，以達成這個目標。Google Cloud 中的許多產品都使用這項技術。舉例來說，Spanner 提供多區域資料庫，可組合多個區域，以達到 99.999% 的可用性。

組合很重要，因為如果沒有組合，應用程式的可用性就無法超過所用 Google Cloud 產品的可用性；事實上，除非應用程式絕不會失敗，否則可用性會低於基礎Google Cloud 產品。本節的其餘部分會說明如何一般來說，如何使用區域和地區產品的組合，達到比單一區域或地區更高的應用程式可用性。下一節將提供實用指南，說明如何將這些原則套用至應用程式。

規劃區域服務中斷範圍

基礎架構故障通常會導致單一區域的服務中斷。在區域內，可用區的設計宗旨是盡量降低與其他可用區發生相關故障的風險，因此一個可用區的服務中斷通常不會影響同一區域中其他可用區的服務。區域範圍內的中斷不一定代表整個區域都無法使用，只是定義事件的界線。區域中斷可能不會對該區域的特定資源造成實質影響。

這種情況較為罕見，但請務必注意，單一區域內的多個可用區最終仍會發生相關聯的服務中斷。如果兩個以上的可用區發生中斷情形，則適用下列區域性中斷範圍策略。

區域資源的設計宗旨是抵禦可用區中斷情形，因此會透過多個可用區的組合提供服務。如果支援區域資源的其中一個可用區中斷，資源會自動從另一個可用區提供服務。詳情請仔細查看附錄中的產品功能說明。

Google Cloud 只提供少數區域資源，也就是 Compute Engine 虛擬機器 (VM) 和永久磁碟。如果您打算使用區域資源，就必須自行組合資源，方法是設計、建構及測試位於多個區域的區域資源之間的容錯移轉和復原作業。以下列舉部分策略：

  • 當健康狀態檢查判斷某個區域發生問題時，使用 Cloud Load Balancing 將流量快速轉送至其他區域的虛擬機器。
  • 使用 Compute Engine 執行個體範本和/或代管執行個體群組，在多個區域中執行及擴充相同的 VM 執行個體。
  • 使用區域永久磁碟，將資料同步複製到區域中的另一個可用區。詳情請參閱「使用地區 PD 的高可用性選項」。

規劃區域服務中斷範圍

區域性中斷是指單一區域內有多個可用區受到影響，導致服務中斷。這類中斷規模較大，發生頻率較低，可能是自然災害或大規模基礎架構故障所致。

如果區域產品的設計目標是提供 99.99% 的可用性，每年仍可能因停機而導致特定產品無法使用近一小時。因此，如果無法接受這種停機時間，重要應用程式可能需要制定多區域災難復原計畫。

多區域資源的設計宗旨是抵禦區域中斷，因此會從多個區域提供服務。如上所述，多區域產品會在延遲、一致性和成本之間做出取捨。最常見的權衡是同步和非同步資料複製。非同步複製可降低延遲，但停機期間可能會遺失資料。因此，請務必查看附錄中的產品功能說明，瞭解更多詳細資訊。

如要使用區域資源，並確保區域性服務中斷時仍能正常運作，您必須自行組合資源，也就是設計、建構及測試位於多個區域的區域資源之間的容錯移轉和復原作業。除了上述區域策略 (也可跨區域套用) 之外，請考慮：

  • 地區資源應將資料複製到次要地區、Cloud Storage 等多地區儲存選項，或 GKE Enterprise 等混合雲選項。
  • 建立地區性服務中斷緩解措施後，請定期測試。最糟糕的情況莫過於以為自己能抵禦單一區域中斷，但實際發生時才發現並非如此。

Google Cloud 韌性和可用性方法

Google Cloud 經常超出可用性設計目標，但您不應假設這種強勁的過往成效是可設計的最低可用性。請改為選取 Google Cloud 設計目標超出應用程式預期可靠性的依附元件，這樣應用程式停機時間加上 Google Cloud 停機時間，就能達到您期望的結果。

設計完善的系統可以回答以下問題：「如果區域或地區發生 1、5、10 或 30 分鐘的服務中斷，會發生什麼情況？」這項因素應在多個層面納入考量，包括：

  • 服務中斷期間，顧客會遇到什麼情況？
  • 如何偵測服務中斷？
  • 服務中斷時，我的應用程式會發生什麼事？
  • 服務中斷期間，我的資料會受到什麼影響？
  • 如果發生中斷 (因跨依附元件所致)，我的其他應用程式會受到什麼影響？
  • 服務中斷問題解決後，我需要採取哪些行動才能復原？誰會執行這項操作？
  • 我需要在多久內通知誰服務中斷？

逐步指南：在「 Google Cloud」中設計應用程式的災難復原機制

前幾節介紹了 Google 如何建構雲端基礎架構，以及處理可用區和區域中斷問題的一些方法。

本節將協助您根據所需的可靠性結果，開發將組合原則套用至應用程式的架構。

客戶應用程式的架構必須符合災難復原目標 (例如復原時間目標和復原點目標)，確保受復原時間目標/復原點目標限制的業務關鍵作業，只會依附於負責持續處理服務作業的資料平面元件。 Google Cloud 換句話說，這類客戶的關鍵業務作業不得依賴管理層作業，因為管理層作業會管理設定狀態，並將設定推送至控制層和資料層。

舉例來說，如果客戶打算為業務關鍵作業達成 RTO，就不應依賴 VM 建立 API 或 IAM 權限更新。 Google Cloud

步驟 1：收集現有需求

首先，您必須定義應用程式的可用性需求。大多數公司在這個領域都已制定某種程度的設計指南，這些指南可能是內部開發，也可能源自法規或其他法律規定。這項設計指引通常會以兩項重要指標來編碼：復原時間目標 (RTO) 和復原點目標 (RPO)。以業務角度來看，RTO 可解讀為「發生災害後，我需要多久才能恢復運作」。RPO 的意義是「如果發生災害，我最多可以損失多少資料」。

顯示時間的刻度。活動正在進行中。最左側是 RPO，上面寫著「這些寫入作業已遺失」。右側是 RTO，上面寫著「Normal service resumes.」(服務恢復正常)。

過去，企業會針對各種災難事件 (從元件故障到地震) 定義 RTO 和 RPO 需求。在規劃人員必須透過整個軟體和硬體堆疊對應 RTO/RPO 需求的本地端世界中，這項做法是合理的。在雲端中，您不再需要詳細定義需求，因為供應商會負責處理。您可以根據損失範圍 (整個區域或地區) 定義 RTO 和 RPO 需求，而不必具體說明根本原因。 Google Cloud 這可將需求收集作業簡化為 3 種情境：可用區中斷、區域中斷，或極不可能發生多個區域中斷。

瞭解並非所有應用程式都具有同等重要性後，大多數客戶會將應用程式分類為不同重要性層級，並針對這些層級套用特定的 RTO/RPO 要求。綜合來看，RTO/RPO 和應用程式重要性可回答下列問題，簡化特定應用程式的架構設計程序：

  1. 應用程式是否需要在同一區域的多個可用區中執行，還是需要在多個區域的多個可用區中執行？
  2. 應用程式可以依附哪些 Google Cloud 產品？

以下是需求收集作業的輸出範例：

範例機構 Co 的 RTO 和 RPO (依應用程式重要性)：

應用程式重要性 應用程式百分比 應用程式範例 可用區中斷 區域服務中斷
第 1 級

(最重要)

 5% 通常是面向全球或外部客戶的應用程式，例如即時付款和電子商務店面。 RTO Zero

RPO Zero

 RTO Zero

RPO Zero
級別 2 35% 通常是區域應用程式或重要的內部應用程式，例如 CRM 或 ERP。 RTO 15 分鐘

RPO 15 分鐘

 復原時間目標 1 小時

RPO 1hr
第 3 級

(最不重要)

 60% 通常是團隊或部門應用程式，例如後勤辦公室、請假預約、內部旅遊、會計和人資。 復原時間目標 1 小時

RPO 1hr

 RTO 12hrs

RPO 12hrs

步驟 2：將功能對應至可用產品

第二步是瞭解應用程式使用的產品 Google Cloud的復原能力。大多數公司會審查相關產品資訊，然後針對如何修改架構提供指引，以因應產品功能與復原能力需求之間的任何落差。本節將介紹一些常見領域，並提供有關資料和應用程式限制的建議。

如先前所述，Google 的 DR 啟用產品大致可因應兩種範圍的中斷：區域和可用區。就 DR 而言，部分中斷應與全面中斷的規劃方式相同。這會提供初始的高層級矩陣，指出預設適用於各情境的產品：

Google Cloud 產品一般功能
(如需特定產品功能，請參閱附錄)

所有 Google Cloud 產品 區域 Google Cloud 產品，可自動在各可用區之間複製 多區域或全球 Google Cloud 產品，可自動跨區域複製
可用區內的元件故障 涵蓋範圍* 可攜碼轉移 可攜碼轉移
可用區中斷 未涵蓋的內容 可攜碼轉移 可攜碼轉移
區域服務中斷 未涵蓋的內容 未涵蓋的內容 可攜碼轉移

* 所有 Google Cloud 產品都能在元件故障時正常運作，但產品文件註明的特定情況除外。這類情況通常是產品提供直接存取或靜態對應至特定硬體 (例如記憶體或固態硬碟 (SSD)) 的案例。

RPO 如何限制產品選擇

在大多數雲端部署作業中，資料完整性是服務架構方面最重要的考量因素。至少部分應用程式的 RPO 需求為零，也就是說，如果發生中斷事件，不應遺失任何資料。這通常需要將資料同步複製到其他區域或地區。同步複製功能會造成成本和延遲方面的取捨，因此雖然許多 Google Cloud 產品提供跨區域的同步複製功能，但只有少數產品提供跨區域的同步複製功能。這種成本和複雜度之間的取捨，意味著應用程式內不同類型的資料具有不同的 RPO 值，並不罕見。

如果資料的 RPO 大於零，應用程式可以利用非同步複製。如果遺失的資料可以輕鬆重建，或可視需要從黃金資料來源復原，則非同步複製是可接受的做法。如果區域和地區預期中斷時間較短，且可接受少量資料遺失，這也是合理的選擇。此外，在暫時性中斷期間，寫入受影響位置但尚未複製到其他位置的資料，通常會在服務中斷問題解決後恢復可用。也就是說，永久遺失資料的風險，低於服務中斷期間無法存取資料的風險。

重要行動：確認您是否確實需要 RPO 零，如果需要，是否可以針對部分資料執行這項操作，因為這樣一來，您可用的 DR 服務範圍就會大幅增加。在 Google Cloud中，如要達到 RPO 零，表示應用程式主要使用地區性產品，這類產品預設可抵禦區域規模的服務中斷，但無法抵禦地區規模的服務中斷。

RTO 如何限制產品選擇

雲端運算的主要優點之一是能依需求部署基礎架構，但這與即時部署不同。應用程式的 RTO 值必須能配合應用程式使用的產品的 Google Cloud 合併 RTO，以及工程師或 SRE 必須採取的所有動作，才能重新啟動 VM 或應用程式元件。以分鐘為單位的 RTO 代表應用程式的設計可從災害中自動復原，不需人為介入，或只需極少的步驟，例如按下按鈕即可容錯移轉。這類系統的成本和複雜度向來很高，但負載平衡器和執行個體群組等產品，讓這種設計變得更經濟實惠且簡單。 Google Cloud 因此，建議您為大多數應用程式考慮自動容錯移轉和復原。請注意，設計這類跨區域的熱容錯移轉系統既複雜又昂貴，只有極少數的關鍵服務才需要這項功能。

大多數應用程式的 RTO 介於一小時到一天之間，因此在發生災難時，可以進行暖容錯移轉，讓應用程式的部分元件 (例如資料庫) 持續以待命模式運作，而其他元件 (例如網路伺服器) 則會在實際發生災難時擴大。對於這類應用程式，強烈建議您自動化執行擴充事件。RTO 超過一天的服務屬於最低重要性，通常可從備份還原，或從頭重新建立。

重要行動：判斷是否確實需要 (接近) 零的 RTO，以進行區域容錯移轉，如果需要，是否可以為部分服務執行這項操作。這會影響服務的執行和維護成本。

步驟 3：開發自己的參考架構和指南

最後一個建議步驟是建立公司專屬的架構模式，協助團隊標準化災難復原方法。大多數 Google Cloud 客戶會為開發團隊製作指南，根據個別業務復原能力期望，將中斷情境歸類為 Google Cloud兩大類。這項功能可讓團隊輕鬆分類，判斷哪些啟用 DR 的產品適合各個重要性層級。

建立產品指南

再次查看上方的 RTO/RPO 範例表格，您會看到假設性指南，列出每個重要性層級預設允許的產品。請注意，如果系統預設將特定產品判定為不適用，您隨時可以加入自己的複製和容錯移轉機制，啟用跨區域或跨區域同步，但這項練習超出本文範圍。表格也會連結至各項產品的詳細資訊，協助您瞭解這些產品在管理區域或地區中斷方面的功能。

範例機構 Co 的範例架構模式 - 區域中斷 復原能力

Google Cloud 產品 產品是否符合「Example Organization」的區域性中斷規定(須具備適當的產品設定)
級別 1 級別 2 第 3 級
Compute Engine 否 否 否
Dataflow 否 否 否
BigQuery 否 否 是
GKE 是 是 是
Cloud Storage 是 是 是
Cloud SQL 否 是 是
Spanner 是 是 是
Cloud Load Balancing 是 是 是

這個表格僅為範例，是根據上方假設的等級所列。

範例機構 Co 的架構模式範例 - 區域服務中斷 復原能力

Google Cloud 產品 產品是否符合 Example Organization 的區域中斷規定(具備適當的產品設定)
級別 1 級別 2 第 3 級
Compute Engine 是 是 是
Dataflow 否 否 否
BigQuery 否 否 是
GKE 是 是 是
Cloud Storage 否 否 否
Cloud SQL 否 是 是
Spanner 是 是 是
Cloud Load Balancing 是 是 是

這個表格僅為範例，是根據上方假設的等級所列。

為說明如何使用這些產品，以下各節將逐步介紹各個假設應用程式重要性層級的參考架構。這些是刻意提供的高層級說明，旨在說明重要的架構決策，並非完整的解決方案設計。

第 3 層架構範例

應用程式重要性 可用區中斷 區域服務中斷
第 3 級
(最不重要)		 RTO 12 小時
RPO 24 小時		 復原時間目標 28 天
復原點目標 24 小時

使用 Google Cloud 產品的第 3 層架構範例

(灰色圖示表示要啟用基礎架構才能進行復原)

這個架構說明傳統的用戶端/伺服器應用程式：內部使用者連線至運算執行個體上執行的應用程式，該執行個體由資料庫支援，用於永久儲存。

請務必注意，這個架構支援的 RTO 和 RPO 值比必要值更低。不過，如果額外的手動步驟可能造成高昂成本或不可靠，您也應考慮消除這些步驟。舉例來說，從夜間備份還原資料庫可支援 24 小時的 RPO，但通常需要資料庫管理員等專業人員操作，如果多項服務同時受到影響，可能無法立即還原。有了 Google Cloud隨選基礎架構，您就能建構這項功能，不必在成本方面做出重大取捨。因此，這個架構採用 Cloud SQL HA，而非手動備份/還原區域性中斷。

區域中斷的重大架構決策 - 復原時間目標為 12 小時，復原點目標為 24 小時：

  • 內部負載平衡器可用於提供可擴充的使用者存取點，並自動容錯移轉至其他可用區。雖然 RTO 為 12 小時，但手動變更 IP 位址或更新 DNS 可能會比預期時間更長。
  • 地區代管執行個體群組會設定多個區域，但資源最少。這項設定會盡量降低成本，但仍允許虛擬機器在備份區域中快速擴充。
  • 高可用性 Cloud SQL 設定可自動容錯移轉至其他可用區。與 Compute Engine 虛擬機器相比，資料庫的重建和還原難度高出許多。

區域性服務中斷的重大架構決策 - 復原時間目標為 28 天，復原點目標為 24 小時：

  • 只有在區域 1 發生中斷時，才會在區域 2 中建構負載平衡器。Cloud DNS 用於提供協調式但手動的區域容錯移轉功能，因為只有在區域中斷時，區域 2 的基礎架構才會可用。
  • 只有在區域發生中斷時，才會建構新的代管執行個體群組。這項設定會盡量降低成本，且由於大多數區域性中斷時間不長，因此不太可能叫用。請注意，為簡化說明，圖中未顯示重新部署所需的相關工具，或複製 Compute Engine 映像檔的必要步驟。
  • 系統會重新建立新的 Cloud SQL 執行個體，並從備份還原資料。同樣地，區域發生長時間中斷的風險極低，因此這也是另一項成本最佳化取捨。
  • 多區域 Cloud Storage 用於儲存這些備份。這可在 RTO 和 RPO 內提供自動區域和區域復原能力。

第 2 層架構範例

應用程式重要性 可用區中斷 區域服務中斷
級別 2 復原時間目標 4 小時
復原點目標為零		 RTO 24 小時
RPO 4 小時

使用 Google Cloud 產品的第 2 層架構範例

這個架構說明資料倉儲，其中內部使用者會連線至運算執行個體視覺化層，而資料擷取和轉換層則會填入後端資料倉儲。

這個架構的部分個別元件不直接支援其層級所需的 RPO。不過，由於兩者搭配使用，整體服務確實符合 RPO。在本例中，由於 Dataflow 是區域產品，請按照高可用性設計的建議操作，避免在服務中斷期間遺失資料。不過，Cloud Storage 層是這項資料的黃金來源，支援 RPO 為零。因此，如果區域 a 發生中斷，您可以使用區域 b 將任何遺失的資料重新擷取至 BigQuery。

區域中斷的重大架構決策 - 復原時間目標為 4 小時，復原點目標為零：

  • 負載平衡器可為使用者提供可擴充的存取點，並自動容錯移轉至其他可用區。雖然 RTO 為 4 小時，但手動變更 IP 位址或更新 DNS 可能會比預期時間更長。
  • 資料視覺化運算層的地區代管執行個體群組會設定多個區域，但資源最少。這種做法可節省成本，同時仍允許快速擴充虛擬機器。
  • 區域型 Cloud Storage 可做為初始資料擷取的暫存層，並提供自動可用區復原能力。
  • Dataflow 用於從 Cloud Storage 擷取資料並轉換，然後載入至 BigQuery。如果發生區域中斷情形，這項無狀態程序可以在其他區域重新啟動。
  • BigQuery 提供資料倉儲後端，供資料視覺化前端使用。如果發生區域中斷事件，系統會從 Cloud Storage 重新擷取所有遺失的資料。

區域中斷的重大架構決策 - 復原時間目標為 24 小時，復原點目標為 4 小時：

  • 每個區域中的負載平衡器可用來為使用者提供可擴充的存取點。Cloud DNS 用於提供協調式但手動的區域容錯移轉功能，因為只有在區域 2 發生中斷時，才會提供區域 2 的基礎架構。
  • 資料視覺化運算層的地區代管執行個體群組會設定多個區域，但資源最少。重新設定負載平衡器後，您才能存取這項功能，否則不需要手動介入。
  • 區域 Cloud Storage 可做為初始資料擷取的暫存層。這會同時載入兩個區域，以符合 RPO 需求。
  • Dataflow 用於從 Cloud Storage 擷取資料並轉換，然後載入至 BigQuery。如果發生區域中斷事件，這項作業會將 Cloud Storage 中的最新資料填入 BigQuery。
  • BigQuery 提供資料倉儲後端。在正常運作情況下，這項資料會間歇性重新整理。如果發生區域中斷事件，系統會透過 Dataflow 從 Cloud Storage 重新擷取最新資料。

第 1 層架構範例

應用程式重要性 可用區中斷 區域服務中斷
第 1 層
(最重要)		 復原時間目標為零
復原點目標為零		 RTO 4 小時
RPO 1 小時

使用 Google Cloud 產品的第 1 層架構範例

這個架構說明行動應用程式後端基礎架構，外部使用者會連線至 GKE 中執行的一組微服務。Spanner 提供即時資料的後端資料儲存層，而每個區域的歷史資料都會串流至 BigQuery 資料湖。

同樣地，這個架構的某些個別元件並未直接支援其層級所需的 RPO，但由於這些元件的搭配使用方式，整體服務確實支援 RPO。在本例中，BigQuery 用於分析查詢。每個區域都會同時從 Spanner 接收資料。

區域中斷的重大架構決策 - RTO 為零，RPO 為零：

  • 負載平衡器可為使用者提供可擴充的存取點，並自動容錯移轉至其他可用區。
  • 應用程式層使用區域 GKE 叢集，並設定多個可用區。這樣一來，每個區域的 RTO 就能達到零。
  • 多區域 Spanner 可做為資料持久層，提供自動區域資料復原能力和交易一致性。
  • BigQuery 可為應用程式提供分析功能。每個區域都會獨立從 Spanner 接收資料，且應用程式會獨立存取每個區域。

區域中斷的主要架構決策 - 復原時間目標為 4 小時，復原點目標為 1 小時：

  • 負載平衡器可為使用者提供可擴充的存取點，並自動容錯移轉至其他區域。
  • 應用程式層使用區域 GKE 叢集，並設定多個可用區。如果某個地區發生服務中斷，備用地區的叢集會自動擴充，以承擔額外的處理負載。
  • 多區域 Spanner 可做為資料持久層，提供自動區域資料復原能力和交易一致性。這是達成 1 小時跨區域 RPO 的關鍵元件。
  • BigQuery 可為應用程式提供分析功能。每個區域都會獨立從 Spanner 接收資料，且應用程式會獨立存取每個區域。這個架構可補償 BigQuery 元件，讓元件符合整體應用程式需求。

附錄：產品參考資料

本節說明客戶應用程式最常使用的 Google Cloud產品架構和 DR 功能，這些產品可輕鬆用於達成 DR 需求。

常見主題

許多 Google Cloud 產品提供區域或多區域設定。區域產品可因應可用區中斷情形，多區域和全球產品則可因應區域中斷情形。一般來說，這表示應用程式在服務中斷期間，受到的影響會降到最低。Google 採用幾種常見的架構方法，實現上述成果，這些方法與上述架構指引相符。

  • 備援部署：應用程式後端和資料儲存空間會部署在區域內的多個可用區，以及多區域位置內的多個區域。如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。

  • 資料複製：產品會在備援位置之間使用同步或非同步複製。

    • 同步複製是指應用程式發出 API 呼叫來建立或修改產品儲存的資料時，只有在產品將資料寫入多個位置後，才會收到成功回應。同步複製可確保您在 Google Cloud 基礎架構中斷期間不會失去任何資料的存取權，因為所有資料都會儲存在可用的後端位置。

      雖然這項技術可提供最高等級的資料防護，但可能會導致延遲和效能有所取捨。使用同步複製作業的多區域產品最明顯會受到這種取捨影響，通常會增加 10 毫秒或 100 毫秒的延遲時間。

    • 非同步複製是指應用程式發出 API 呼叫來建立或修改產品儲存的資料時，產品將資料寫入單一位置後，應用程式就會收到成功回應。寫入要求後，產品會將資料複製到其他位置。

      與同步複製相比，這項技術在 API 層級的延遲時間較短，總處理量較高，但會犧牲資料保護。如果您寫入資料的位置在複製完成前發生中斷，您將無法存取該資料，直到位置中斷問題解決為止。

  • 透過負載平衡處理服務中斷問題： Google Cloud 使用軟體負載平衡，將要求轉送至適當的應用程式後端。相較於 DNS 負載平衡等其他方法，這種做法可縮短系統對服務中斷的回應時間。發生 Google Cloud 區域中斷 時，負載平衡器會快速偵測到部署在該區域的後端已「不正常」，並將所有要求導向替代區域的後端。這樣一來，產品就能在位置資訊中斷期間，繼續處理應用程式的要求。解決位置中斷問題後，負載平衡器會偵測該位置的產品後端可用性，並恢復傳送流量。

Access Context Manager

企業可透過 Access Context Manager 設定存取層級，對應至要求屬性定義的政策。政策會反映區域情況。

如果發生可用區服務中斷，系統會自動從該區域的其他可用區，以透明方式處理傳送至無法使用可用區的要求。

如果發生區域性服務中斷，受影響區域的政策計算將無法使用，直到該區域恢復運作為止。

資料存取透明化控管機制

資料存取透明化控管機制可讓 Google Cloud 機構管理員為 Google Cloud中的專案和資源，定義以屬性為基礎的精細存取控管機制。有時 Google 必須存取顧客資料，以進行管理。當我們存取客戶資料時，資料存取透明化控管機制會向受影響的 Google Cloud客戶提供存取記錄。這些資料存取透明化控管機制記錄有助於確保 Google 遵守資料安全和資料處理透明化的承諾。

資料存取透明化控管機制可有效防範區域和可用區服務中斷。如果發生區域或地區服務中斷，資料存取透明化控管機制會繼續在其他區域或地區處理管理員存取記錄。

AlloyDB for PostgreSQL

PostgreSQL 適用的 AlloyDB 是與 PostgreSQL 相容的全代管資料庫服務。PostgreSQL 適用的 AlloyDB 會在區域中提供高可用性，方法是在該區域的兩個不同可用區中，放置主要執行個體的備援節點。如果使用中的可用區發生問題，主要執行個體會觸發自動容錯移轉至待命可用區，維持區域可用性。如果單一可用區發生故障，區域儲存空間可確保資料的耐久性。

為了進一步提供災難復原機制，AlloyDB for PostgreSQL 會使用跨區域複製功能，將主要叢集的資料非同步複製到位於不同 Google Cloud 區域的次要叢集，藉此提供災難復原功能。

區域性中斷：在正常運作期間，高可用性主要執行個體的兩個節點中，只有一個會處於啟用狀態，並負責處理所有資料寫入作業。這個作用中節點會將資料儲存在叢集獨立的區域儲存層。

PostgreSQL 適用的 AlloyDB 會自動偵測區域層級的故障，並觸發容錯移轉，以還原資料庫可用性。在容錯移轉期間，PostgreSQL 適用的 AlloyDB 會在備用節點上啟動資料庫，該節點已在不同區域中佈建。新的資料庫連線會自動導向這個區域。

從用戶端應用程式的角度來看，區域性中斷就像是網路連線暫時中斷。容錯移轉完成後，用戶端可以使用相同的位址和憑證重新連線至執行個體，且不會遺失任何資料。

區域中斷：跨區域複製功能使用非同步複製，因此主要執行個體可以在副本修訂交易前修訂交易。交易在主要執行個體上提交的時間，與在副本上提交的時間差，稱為「複製延遲」。主要執行個體產生預先寫入記錄 (WAL) 的時間，與 WAL 傳送至副本的時間差，稱為「排清延遲」。複寫延遲和排清延遲取決於資料庫執行個體設定和使用者產生的工作負載。

如果發生區域服務中斷事件，您可以將不同區域的次要叢集升級為可寫入的獨立主要叢集。升級後的叢集不會再從先前關聯的原始主要叢集複製資料。由於清除延遲，原始主要叢集上可能會有未傳播至次要叢集的交易，因此可能會遺失部分資料。

跨區域複製 RPO 會受到主要叢集的 CPU 使用率，以及主要叢集區域與次要叢集區域之間的實際距離影響。為盡量縮短 RPO，建議您使用包含副本的設定測試工作負載，建立安全的每秒交易數 (TPS) 上限，也就是不會累積清除延遲的最高持續 TPS。如果工作負載超過安全 TPS 上限，就會累積延遲，進而影響 RPO。如要減少網路延遲，請選擇同一個大洲內的區域配對。

如要進一步瞭解如何監控網路延遲和其他 PostgreSQL 適用的 AlloyDB 指標，請參閱「監控執行個體」。

Anti Money Laundering AI

Anti Money Laundering AI (簡稱 AML AI) 提供 API，協助全球金融機構更有效率地偵測洗錢行為。反洗錢 AI 是區域性產品，因此客戶可以選擇區域，但無法選擇構成區域的可用區。系統會自動在區域內的各個可用區之間，進行資料和流量的負載平衡。系統會在背景自動調度作業 (例如建立管道或執行預測)，並視需要跨區域進行負載平衡。

可用區中斷：AML AI 會將資源資料儲存在區域中，並以同步方式複製。長時間執行的作業順利完成後，無論可用區發生故障與否，資源都能正常運作。處理作業也會在各個可用區之間複製，但這項複製作業的目的是負載平衡，而非高可用性，因此作業期間若發生可用區故障，作業可能會失敗。如果發生這種情況，重新嘗試作業即可解決問題。區域性中斷期間，處理時間可能會受到影響。

區域性服務中斷：客戶可選擇要建立 AML AI 資源的 Google Cloud 區域。資料絕不會跨區域複製。AML AI 絕不會將客戶流量導向其他區域。如果發生區域性故障，只要服務中斷問題解決，AML AI 就會恢復運作。

API 金鑰

API 金鑰可為專案提供可擴充的 API 金鑰資源管理功能。 API 金鑰是全球服務，也就是說，金鑰可從任何 Google Cloud 位置查看及存取。資料和中繼資料會備份到多個可用區和區域。

API 金鑰可抵禦可用區和區域性服務中斷。如果發生可用區或區域中斷情形，API 金鑰會繼續處理來自相同或不同區域中其他可用區的要求。

如要進一步瞭解 API 金鑰，請參閱 API 金鑰 API 總覽。

Apigee

Apigee 提供安全、可擴充且可靠的平台，方便您開發及管理 API。Apigee 提供單一區域和多區域部署作業。

區域中斷：客戶執行階段資料會複製到多個可用區。因此，單一可用區服務中斷不會影響 Apigee。

區域服務中斷：如果是單一區域 Apigee 執行個體，如果區域服務中斷，該區域的 Apigee 執行個體就無法使用，也無法還原至其他區域。如果是多區域 Apigee 執行個體，資料會非同步複製到所有區域。因此，一個區域發生故障不會完全減少流量。不過，您可能無法存取失敗區域中未提交的資料。您可以將流量從健康狀態不良的區域轉移。如要實現自動流量容錯移轉，可以使用代管執行個體群組 (MIG) 設定網路路由。

AutoML Translation

AutoML Translation 是一項機器翻譯服務，可讓您匯入自己的資料 (語句組合)，訓練自訂模型，滿足特定領域的需求。

區域中斷：AutoML Translation 在多個區域和地區都有運算伺服器，此外，這項服務也支援區域內跨可用區的資料同步複製功能。這些功能可協助 AutoML Translation 達成即時容錯移轉，避免區域故障造成任何資料遺失，且不需要任何客戶輸入或調整。

區域服務中斷：如果區域發生故障，AutoML Translation 就無法使用。

AutoML Vision

AutoML Vision 是 Vertex AI 的一部分。這個架構提供統一的架構，可建立資料集、匯入資料、訓練模型，以及提供模型以進行線上預測和批次預測。

AutoML Vision 是區域服務，客戶可以選擇要從哪個區域啟動作業，但無法選擇該區域內的特定可用區。這項服務會自動在區域內的不同可用區之間，平衡工作負載。

區域性中斷：AutoML Vision 會在區域中儲存工作的中繼資料，並在區域內的可用區之間同步寫入資料。工作會在 Cloud Load Balancing 選取的特定區域中啟動。

  • AutoML Vision 訓練工作：區域性服務中斷會導致所有執行中的工作失敗，且工作狀態會更新為失敗。如果工作失敗，請立即重試。新工作會轉送至可用區。

  • AutoML Vision 批次預測工作：批次預測功能是以 Vertex AI 批次預測為基礎建構而成。如果發生區域性服務中斷，服務會自動將工作路徑導向可用區域，藉此重試工作。如果多次重試都失敗，工作狀態就會更新為失敗。使用者後續執行作業的要求會轉送至可用區域。

區域性服務中斷：客戶可選擇要執行工作的 Google Cloud 區域。資料絕不會跨區域複製。如果發生區域性故障，該區域就無法使用 AutoML Vision 服務。服務中斷問題解決後，即可再次使用。為執行工作，我們建議客戶使用多個區域。如果發生區域服務中斷，請將工作導向至其他可用區域。

批次

Batch 是一項全代管服務，可在 Google Cloud中將批次工作排入佇列、排定時間並加以執行。批次設定是在區域層級定義。客戶必須選擇區域來提交批次工作，而非區域中的可用區。提交工作時，Batch 會將客戶資料同步寫入多個可用區。不過，客戶可以指定 Batch VM 執行工作的區域。

區域故障：如果單一區域發生故障，該區域中執行的工作也會失敗。如果工作有重試設定，Batch 會自動將這些工作容錯移轉至同一區域中的其他可用區。自動容錯移轉功能取決於同一區域中作用中可用區的資源可用性。如果工作需要可用區資源 (例如 VM、GPU 或可用區永久磁碟)，但這些資源只在失敗的可用區提供，則工作會排入佇列，直到失敗的可用區恢復運作，或工作達到佇列逾時時間為止。建議客戶盡可能讓 Batch 選擇區域資源來執行工作。這麼做有助於確保作業能抵禦區域性中斷。

區域故障：如果發生區域故障，該區域的服務控制層將無法使用。這項服務不會跨區域複製資料或重新導向要求。我們建議客戶使用多個區域執行工作，並在某個區域發生故障時，將工作重新導向至其他區域。

Chrome Enterprise Premium 威脅與資料保護

Chrome Enterprise 進階版威脅與資料保護功能是 Chrome Enterprise 進階版解決方案的一部分。這項擴充功能為 Chrome 增添多種安全防護功能，包括惡意軟體和網路釣魚防護、資料遺失防護 (DLP)、網址篩選規則和安全性報表。

Chrome Enterprise Premium 管理員可以選擇將違反 DLP 或惡意軟體政策的客戶核心內容，儲存到 Google Workspace 規則記錄事件和/或 Cloud Storage，以供日後調查。Google Workspace 規則記錄事件是由多區域 Spanner 資料庫提供支援。Chrome Enterprise Premium 最多可能需要數小時才能偵測到違規行為。在此期間，任何未處理的資料都可能因可用區或區域中斷而遺失。系統偵測到違規內容後，會將違反政策的內容寫入 Google Workspace 規則記錄事件和/或 Cloud Storage。

區域和地區性服務中斷： 由於 Chrome Enterprise Premium 威脅和資料防護功能涵蓋多個區域和地區，因此即使某個區域或地區發生完全非預期的服務中斷，也不會影響可用性。這項服務會將流量重新導向至其他有效區域或地區的服務，藉此提供這種可靠程度。不過，Chrome Enterprise Premium 威脅和資料防護功能可能需要數小時才能偵測到 DLP 和惡意軟體違規行為，因此特定區域或地區中任何未處理的資料，都可能因區域或地區服務中斷而遺失。

BigQuery

BigQuery 是兼具高擴充性與成本效益的無伺服器雲端資料倉儲系統，專為增進企業靈活性而設計。BigQuery 支援下列使用者資料集位置類型：

  • 區域：特定地理位置，例如愛荷華州 (us-central1) 或蒙特婁 (northamerica-northeast1)。
  • 多地區：包含兩個以上地理位置的大型地理區域，例如美國 (US) 或歐洲 (EU)。

無論是哪種情況，資料都會在所選位置的單一區域內，以備援方式儲存在兩個可用區。寫入 BigQuery 的資料會同步寫入主要和次要區域。這項功能可避免區域內單一可用區發生服務中斷，但無法防範區域服務中斷。

二進位授權

二進位授權是軟體供應鏈安全產品，適用於 GKE 和 Cloud Run。

所有二進位授權政策都會在每個區域內的多個可用區中複製。複製作業有助於二進位授權政策讀取作業，從其他區域的失敗中復原。複製功能也能讓讀取作業容許每個區域內的可用區故障。

二進位授權強制執行作業可應對區域服務中斷，但無法應對區域服務中斷。強制執行作業會在與發出要求的 GKE 叢集或 Cloud Run 工作相同的區域中執行。因此，如果發生區域性服務中斷，就沒有任何執行中的項目會提出二進位授權強制執行要求。

Certificate Manager

您可以使用 Certificate Manager 取得及管理傳輸層安全標準 (TLS) 憑證，以便搭配不同類型的 Cloud Load Balancing 使用。

如果發生可用區中斷情形，區域和全域 Certificate Manager 服務可因應可用區故障，因為工作和資料庫會在區域內的多個可用區中備援。如果發生區域性服務中斷，全域 Certificate Manager 仍可正常運作，因為作業和資料庫在多個區域中都有備援。區域憑證管理員是區域性產品，因此無法應對區域故障。

雲端入侵偵測系統

Cloud 入侵偵測系統 (Cloud IDS) 是區域服務，提供區域範圍的 IDS 端點，可處理特定區域中 VM 的流量，因此無法容忍區域或區域性中斷。

區域性中斷：Cloud IDS 與 VM 執行個體相關聯。如果客戶打算在多個區域部署 VM (手動或透過地區代管執行個體群組)，以減輕區域中斷的影響，則也需要在這些區域部署 Cloud IDS 端點。

區域性服務中斷：Cloud IDS 是區域性產品。不提供任何跨區域功能。如果發生區域性故障，該區域所有可用區的 Cloud IDS 功能都會停止運作。

Google Security Operations SIEM

Google Security Operations SIEM (Google Security Operations 的一部分) 是全代管服務，可協助資安團隊偵測、調查及因應威脅。

Google Security Operations SIEM 提供單一區域和多區域服務。

  • 在區域型服務中，系統會自動在所選區域內的可用區之間，對資料和流量進行負載平衡，並在區域內的可用區之間，以備援方式儲存資料。

  • 多區域提供異地備援機制。 相較於區域儲存空間，這項備援機制可提供更廣泛的保護。 即使整個區域都失去連線，這項功能也能確保服務持續運作。

  • 大多數資料擷取路徑都會在多個位置同步複製顧客資料。以非同步方式複製資料時，資料尚未複製到多個位置的這段時間，就是復原點目標 (RPO)。在多區域部署中，使用動態饋給擷取資料時，就會發生這種情況。RPO 結束後，資料就會在多個位置提供。

可用區中斷：

  • 區域部署：系統會從區域內的任何可用區處理要求。資料會同步複製到多個可用區。如果整個可用區發生服務中斷，其餘可用區會繼續處理流量和資料。Google Security Operations SIEM 的備援佈建和自動調整功能，有助於確保服務在這些負載轉移期間，仍可在其餘區域運作。

  • 多區域部署作業：區域性服務中斷等同於區域性服務中斷。

區域性服務中斷：

  • 區域部署：Google Security Operations SIEM 會將所有客戶資料儲存在單一區域，且流量絕不會跨區域傳輸。如果發生區域性服務中斷，Google Security Operations SIEM 在該區域將無法使用，直到服務中斷問題解決為止。

  • 多區域部署 (不含動態饋給)：系統會從多區域部署的任何區域提供要求。資料會同步複製到多個區域。如果整個區域發生中斷，其餘區域會繼續提供流量並處理資料。Google Security Operations SIEM 的備援佈建和自動調度機制，有助於確保服務在這些負載轉移期間，仍可在其餘區域運作。

  • 多區域部署 (含動態饋給)：系統會從多區域部署的任何區域提供要求。資料會以非同步方式複製到多個區域，並提供 RPO。如果整個區域發生中斷，只有在 RPO 之後儲存的資料，才能在其他區域使用。RPO 期間內的資料可能不會複製。

Cloud Asset Inventory

Cloud Asset Inventory 是一項高效能的彈性全域服務，可維護 Google Cloud 資源和政策中繼資料的存放區。Cloud Asset Inventory 提供搜尋和分析工具，可協助您追蹤組織、資料夾和專案中部署的資產。

如果區域發生中斷情形，Cloud Asset Inventory 會繼續從相同或不同區域的其他區域處理要求。

如果發生區域性服務中斷，Cloud Asset Inventory 會繼續處理其他區域的要求。

Bigtable

Bigtable 是全代管的高效能 NoSQL 資料庫服務，適合用來處理大型分析和作業工作負載。

Bigtable 複製功能總覽

Bigtable 提供彈性且完全可設定的複製功能，可將資料複製到多個區域的叢集，或同一個區域內的多個可用區，藉此提高資料的可用性和耐用性。使用複寫功能時，Bigtable 也能為您的要求提供自動容錯移轉。

使用多叢集轉送搭配多區域或多地區設定時，如果發生區域或地區中斷，Bigtable 會自動重新轉送流量，並從最近的可用叢集處理要求。由於 Bigtable 複製作業是非同步且最終一致，如果資料尚未複製到其他位置，中斷位置的資料最近變更可能無法使用。

效能注意事項

當 CPU 資源需求超過可用節點容量時，Bigtable 一律會優先處理傳入的要求，再處理複製流量。

如要進一步瞭解如何搭配工作負載使用 Bigtable 複製功能，請參閱 Cloud Bigtable 複製功能總覽和複製功能設定範例。

Bigtable 節點可用於處理傳入的要求，以及執行其他叢集的資料複製作業。除了為每個叢集維持足夠的節點數量，您也必須確保應用程式使用適當的結構定義設計，避免熱點，否則可能會導致 CPU 使用率過高或不平衡，並增加複製延遲。

如要進一步瞭解如何設計應用程式結構定義，盡可能提升 Bigtable 效能和效率，請參閱結構定義設計最佳做法。

監控

Bigtable 提供多種方式，可透過 Google Cloud console中提供的複製作業圖表，以視覺化方式監控執行個體和叢集的複製作業延遲時間。

您也可以使用 Cloud Monitoring API，以程式輔助方式監控 Bigtable 複寫指標。

憑證授權單位服務

憑證授權單位服務 (CA 服務) 可讓客戶簡化、自動化及自訂私人憑證授權單位 (CA) 的部署、管理與安全防護作業，並大規模核發憑證，確保系統穩定運作。

可用區中斷：CA Service 可靈活應對可用區故障，因為控制層在區域內的多個可用區中具有備援機制。如果發生可用區服務中斷，CA Service 會繼續從同一區域的其他可用區提供服務，不會中斷要求。由於資料是同步複製，因此不會遺失或損毀。

區域性服務中斷：CA Service 是區域性產品，因此無法承受區域性故障。如要避免區域故障，請在兩個不同區域中建立簽發 CA。在需要憑證的區域中，建立主要核發 CA。在不同區域建立備援 CA。如果主要下層 CA 的區域發生中斷，請使用備用 CA。 如有需要，這兩個 CA 可以鏈結至同一個根 CA。

Cloud Billing

開發人員可透過 Cloud Billing API，以程式設計的方式管理Google Cloud 專案的帳單。Cloud Billing API 採用全球系統設計，可將更新內容同步寫入多個區域和地區。

區域或地區性故障：Cloud Billing API 會自動容錯移轉至其他區域或地區。個別要求可能會失敗，但重試政策應允許後續嘗試成功。

Cloud Build

Cloud Build 是一項服務，可在 Google Cloud上執行建構作業。

Cloud Build 由區域隔離的執行個體組成，這些執行個體會在區域內的各個可用區之間同步複製資料。建議您使用特定 Google Cloud 區域，而非全域區域，並確保建構作業使用的資源 (包括記錄檔儲存空間、構件登錄存放區等) 與建構作業執行的區域一致。

如果可用區發生中斷，控制層作業不會受到影響。不過，在發生故障的區域中，目前執行的建構作業會延遲或永久遺失。新觸發的建構作業會自動分配到其餘正常運作的區域。

如果發生區域性故障，控制層會離線，目前執行的建構作業會延遲或永久遺失。觸發程序、工作人員集區和建構資料絕不會跨區域複製。建議您在多個區域中準備觸發程序和工作站集區，以便更輕鬆地減輕中斷的影響。

Cloud CDN

Cloud CDN 會在 Google 網路的許多位置發布及快取內容，以縮短用戶端的放送延遲時間。系統會盡可能提供快取內容，如果 Cloud CDN 快取無法處理要求，要求就會轉送至原始伺服器，例如後端 VM 或 Cloud Storage 值區，這些位置會儲存原始內容。

如果區域或地區發生故障，受影響位置的快取就會無法使用。傳入要求會轉送至可用的 Google 邊緣位置和快取。如果這些替代快取無法處理要求，就會將要求轉送至可用的原始伺服器。只要伺服器能以最新資料處理要求，就不會遺失內容。快取未命中率提高時，快取會填補資料，導致原始伺服器的流量高於正常值。後續要求會從不受區域或地區服務中斷影響的快取提供服務。

如要進一步瞭解 Cloud CDN 和快取行為，請參閱 Cloud CDN 說明文件。

Cloud Composer

Cloud Composer 是一項代管工作流程自動化調度管理服務，可讓您建立、排程、監控及管理散布於不同雲端和內部部署資料中心的工作流程。Cloud Composer 環境是以 Apache Airflow 開放原始碼專案為基礎。

區域無法使用不會影響 Cloud Composer API 的可用性。在區域中斷期間，您仍可存取 Cloud Composer API，包括建立新的 Cloud Composer 環境。

Cloud Composer 環境的架構包含 GKE 叢集。區域中斷期間，叢集上的工作流程可能會中斷：

  • 在 Cloud Composer 1 中，環境的叢集是可用區資源，因此可用區中斷可能會導致叢集無法使用。如果工作流程在服務中斷時正在執行，可能會在完成前停止。
  • 在 Cloud Composer 2 中，環境的叢集是區域資源。不過，如果工作流程是在受可用區中斷影響的節點上執行，可能會在完成前停止。

在兩個版本的 Cloud Composer 中，區域中斷可能會導致部分執行的工作流程停止執行，包括您設定工作流程完成的任何外部動作。視工作流程而定，這可能會導致外部不一致，例如工作流程在多步驟執行期間停止，以修改外部資料存放區。因此，設計 Airflow 工作流程時，請務必考量復原程序，包括如何偵測部分未執行的工作流程狀態，以及修復任何部分資料變更。

在 Cloud Composer 1 中，如果發生區域中斷，您可以選擇在其他區域啟動新的 Cloud Composer 環境。由於 Airflow 會將工作流程的狀態保留在其中繼資料庫中，因此將這項資訊轉移至新的 Cloud Composer 環境時，可能需要額外步驟和準備工作。

在 Cloud Composer 2 中，您可以預先設定環境快照的災難復原機制，解決區域性中斷問題。如果可用區發生中斷，您可以透過環境快照轉移工作流程的狀態，切換至其他環境。只有 Cloud Composer 2 支援使用環境快照進行災害復原。

Cloud Data Fusion

Cloud Data Fusion 是全代管的企業級資料整合服務，可讓使用者快速建立及管理資料管道。提供三種版本。

  • 區域性中斷會影響 Developer 版例項。

  • 區域性服務中斷會影響 Basic 和 Enterprise 版本的執行個體。

如要控管資源存取權，您可以在不同環境中設計及執行管道。 這種分離方式可讓您設計一次管線，然後在多個環境中執行。您可以在這兩個環境中復原管道。 詳情請參閱「備份及還原執行個體資料」。

下列建議適用於區域和可用區中斷。

管道設計環境中的中斷

在設計環境中，請儲存管道草稿，以防發生中斷。 視具體 RTO 和 RPO 需求而定，您可以在服務中斷期間，使用已儲存的草稿在其他 Cloud Data Fusion 執行個體中還原管道。

管道執行環境中斷

在執行環境中，您可以透過 Cloud Data Fusion 觸發條件或排程，在內部啟動管道，也可以透過 Cloud Composer 等協調工具，在外部啟動管道。如要復原管道的執行階段設定，請備份管道和設定，例如外掛程式和排程。發生服務中斷時，您可以使用備份在不受影響的區域或地帶複製執行個體。

準備應對中斷的另一種方法，是在各個區域中設定多個執行個體，並使用相同的設定和管道集。如果您使用外部協調程序，系統會自動在執行個體之間進行負載平衡，以執行管道。請特別注意，確保沒有任何資源 (例如資料來源或協調工具) 與單一區域繫結，且由所有執行個體使用，因為這可能會在發生中斷時成為中央故障點。舉例來說，您可以在不同區域中有多個執行個體，並使用 Cloud Load Balancing 和 Cloud DNS，將管道執行要求導向未受中斷影響的執行個體 (請參閱第一層和第三層架構的範例)。

管道中其他 Google Cloud 資料服務的中斷情形

您的執行個體可能會使用其他 Google Cloud 服務做為資料來源或管道執行環境，例如 Dataproc、Cloud Storage 或 BigQuery。這些服務可以位於不同區域。如果需要跨區域執行，任一區域發生故障都會導致服務中斷。在這種情況下，請按照標準災難復原步驟操作，但請注意，在不同區域中設定重要服務的跨區域設定，復原能力較差。

Cloud Deploy

Cloud Deploy 可將工作負載持續推送至執行階段服務，例如 GKE 和 Cloud Run。這項服務是由區域執行個體組成，可在區域內的各個可用區之間同步複製資料。

區域服務中斷：控制層作業不受影響。不過，如果區域發生故障，Cloud Build 建構作業 (例如算繪或部署作業) 會延遲或永久遺失。發生中斷時，觸發建構作業的 Cloud Deploy 資源 (發布或推出) 會顯示失敗狀態，指出基礎作業失敗。您可以重新建立資源，在剩餘的正常運作區域啟動新的建構作業。舉例來說，您可以將版本重新部署至目標，藉此建立新的推出作業。

區域服務中斷：控制層作業和 Cloud Deploy 資料都會無法使用，直到區域服務恢復正常為止。為協助您在區域中斷時更輕鬆地還原服務，建議您將傳送管道和目標定義儲存在來源控制項中。您可以使用這些設定檔，在運作中的區域重新建立 Cloud Deploy 管道。服務中斷期間，現有發行內容的資料會遺失。建立新版本，繼續將軟體部署至目標。

Cloud DNS

Cloud DNS 是一種彈性絕佳的高效能通用網域名稱系統 (DNS) 服務，會以符合成本效益的方式，將您的網域名稱發布到全域 DNS。

如果發生可用區中斷情形，Cloud DNS 會繼續從相同或不同區域的其他可用區提供要求，不會中斷服務。系統會在收到 Cloud DNS 記錄更新後，同步複製到該區域的各個可用區。因此不會遺失資料。

如果發生區域性中斷，Cloud DNS 會繼續處理來自其他區域的要求。Cloud DNS 記錄的最新更新可能無法使用，因為系統會先在單一區域處理更新，再以非同步方式複製到其他區域。

Cloud Healthcare API

Cloud Healthcare API 是一項用於儲存及管理醫療保健資料的服務，可提供高可用性，並視所選設定提供區域和地區故障防護。

區域設定：在預設設定中，Cloud Healthcare API 可防範區域故障。服務部署在一個區域的三個可用區，資料也會在該區域的不同可用區中複製三份。如果可用區發生故障，影響服務層或資料層，其餘可用區會接管作業，不會中斷。如果採用區域設定，當服務所在的整個區域發生中斷時，服務將無法使用，直到該區域恢復連線為止。如果發生無法預料的狀況，導致整個地區遭到實體破壞，儲存在該地區的資料就會遺失。

多區域設定：在多區域設定中，Cloud Healthcare API 會部署在三個不同區域的三個可用區。資料也會複製到三個區域。這樣一來，萬一整個地區發生服務中斷，其餘地區就會自動接管，避免服務中斷。系統會跨多個區域同步複製 FHIR 等結構化資料，因此即使整個區域發生中斷情形，資料也不會遺失。儲存在 Cloud Storage 值區中的資料 (例如 DICOM 和聽寫內容，或大型 HL7v2/FHIR 物件) 會以非同步方式跨多個區域複製。

Cloud Identity

Cloud Identity 服務分布於多個區域，並使用動態負載平衡。Cloud Identity 不允許使用者選取資源範圍。如果特定可用區或區域發生服務中斷，流量會自動分配至其他可用區或區域。

永久資料會備份到多個區域，且在大多數情況下會同步複製。基於效能考量，部分系統 (例如快取或影響大量實體的變更) 會跨區域非同步複製。如果儲存最新資料的主要區域發生中斷，Cloud Identity 會從其他位置提供過時資料，直到主要區域恢復運作。

Cloud Interconnect

Cloud Interconnect 可讓客戶透過連至 Google 對等互連邊緣的實體纜線，從內部部署資料中心RFC 1918 存取 Google Cloud 網路。

如果客戶在都會區中佈建連線至兩個 EAD (邊緣可用性網域)，Cloud Interconnect 會提供 99.9% 的服務水準協議。如果客戶在兩個都會區的兩個 EAD 中，為兩個區域佈建連線並啟用全域轉送，即可享有 99.99% 的服務水準協議。詳情請參閱「一般應用程式的拓撲總覽」和「正式版等級應用程式的拓撲總覽」。

Cloud Interconnect 與運算區域無關，並以 EAD 的形式提供高可用性。如果 EAD 發生故障，該 EAD 的 BGP 工作階段就會中斷，流量會容錯移轉至其他 EAD。

如果區域發生故障，該區域的 BGP 工作階段就會中斷，流量也會容錯移轉至正常運作區域的資源。啟用全域路由時適用。

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) 提供可擴充且高度耐用的加密金鑰資源管理服務。Cloud KMS 會將所有資料和中繼資料儲存在 Spanner 資料庫中，透過同步複製功能提供高資料耐久性和可用性。

Cloud KMS 資源可在單一區域、多個區域或全球建立。

如果發生可用區中斷情形，Cloud KMS 會繼續從相同或不同區域的其他可用區提供服務，不會中斷。由於資料是同步複製，因此不會遺失或損毀。區域中斷問題解決後，系統就會還原完整備援。

如果發生區域性服務中斷，該區域的區域資源會離線，直到該區域恢復運作為止。請注意，即使在同一區域內，系統也會在不同可用區中維護至少 3 個副本。如要提高可用性，資源應儲存在多區域或全域設定中。多地區和全球設定的設計宗旨，是透過異地備援的方式，在多個地區儲存及提供資料，確保服務在區域性中斷期間仍可使用。

Cloud External Key Manager (Cloud EKM)

Cloud External Key Manager 與 Cloud Key Management Service 整合，可讓您透過支援的第三方合作夥伴控制及存取外部金鑰。您可以使用這些外部金鑰加密靜態資料，以便用於其他支援客戶自行管理的加密金鑰 (CMEK) 整合的 Google Cloud 服務。

  • 可用區中斷：Cloud External Key Manager 可抵禦可用區中斷情形，因為區域中的多個可用區提供備援功能。如果可用區發生服務中斷，流量會重新轉送至該區域內的其他可用區。重新導向流量時，您可能會看到錯誤增加，但服務仍可使用。

  • 區域性服務中斷：如果受影響區域發生區域性服務中斷，您就無法使用 Cloud External Key Manager。沒有容錯移轉機制可將要求重新導向至其他區域。建議客戶使用多個區域執行作業。

Cloud External Key Manager 不會永久儲存任何客戶資料。因此，Cloud External Key Manager 系統發生區域性中斷時，不會遺失任何資料。不過，Cloud External Key Manager 必須仰賴其他服務 (例如 Cloud Key Management Service 和外部第三方供應商) 的可用性。如果這些系統在區域服務中斷期間發生故障，您可能會遺失資料。這些系統的 RPO/RTO 不在 Cloud External Key Manager 承諾的範圍內。

Cloud Load Balancing

Cloud Load Balancing 是完全分散式的軟體定義型代管服務。Cloud Load Balancing 服務會使用單一 Anycast IP 位址，做為全球各區域後端的前端。這項服務並非以硬體為基礎，因此您不必管理實體負載平衡基礎架構。負載平衡器是大多數高可用性應用程式的重要元件。

Cloud Load Balancing 提供區域和全域負載平衡器。這項服務也能提供跨地區的負載平衡，包括自動多地區容錯移轉功能。如果主要後端健康狀態不佳，這項功能就會將流量移至容錯移轉後端。

全域負載平衡器可抵禦可用區和區域中斷。區域負載平衡器可因應區域服務中斷，但會受到所在區域中斷的影響。不過，無論是哪種情況，請務必瞭解整體應用程式的復原能力，不僅取決於您部署的負載平衡器類型，也取決於後端的備援機制。

如要進一步瞭解 Cloud Load Balancing 及其功能，請參閱「Cloud Load Balancing 總覽」。

Cloud Logging

Cloud Logging 主要由兩部分組成：記錄檔路由器和 Cloud Logging 儲存空間。

記錄檔路由器會處理串流記錄事件，並將記錄檔導向至 Cloud Storage、Pub/Sub、BigQuery 或 Cloud Logging 儲存空間。

Cloud Logging 儲存空間服務可儲存、查詢及管理記錄檔的法規遵循情形。這項服務支援許多使用者和工作流程，包括開發、法規遵循、疑難排解和主動式警報。

記錄檔路由器和傳入的記錄：在區域中斷期間，Cloud Logging API 會將記錄轉送至該區域的其他可用區。一般來說，記錄檔路由器會盡快將記錄檔轉送至 Cloud Logging、BigQuery 或 Pub/Sub，並寫入最終目的地，而傳送至 Cloud Storage 的記錄檔則會緩衝處理，並以每小時批次作業的方式寫入。

記錄檔項目：如果發生區域或地區性服務中斷，受影響區域或地區中已緩衝但未寫入匯出目的地的記錄檔項目將無法存取。記錄指標也是在記錄檔路由器中計算，並受相同限制。記錄匯出至所選位置後，系統會根據目標服務複製記錄。匯出至 Cloud Logging 儲存空間的記錄檔，會在區域內的兩個可用區中同步複製。如要瞭解其他目的地類型的複製行為，請參閱本文的相關章節。請注意，匯出至 Cloud Storage 的記錄檔會以批次處理的方式每小時寫入。因此，建議您使用 Cloud Logging 儲存空間、BigQuery 或 Pub/Sub，盡量減少服務中斷對資料造成的影響。

記錄中繼資料：水槽和排除設定等中繼資料會儲存在全域，但會快取在區域中，因此如果發生中斷，區域記錄路由器執行個體仍可運作。單一區域中斷不會影響該區域以外的服務。

Cloud Monitoring

Cloud Monitoring 包含各種相互連結的功能，例如資訊主頁 (內建和使用者定義)、快訊和正常運作時間監控。

所有 Cloud Monitoring 設定 (包括資訊主頁、運作時間檢查和快訊政策) 都是全域定義。所有變更都會同步複製到多個區域。因此，在可用區和區域中斷期間，成功的設定變更都會保持不變。此外，雖然區域或地區發生故障時，可能會出現暫時性的讀取和寫入失敗情形，但 Cloud Monitoring 會將要求重新導向至可用的區域和地區。在這種情況下，您可以透過指數輪詢重試設定變更。

為特定資源寫入指標時，Cloud Monitoring 會先找出資源所在的區域。然後在該區域內寫入三份獨立的指標資料副本。只要其中一個寫入作業成功，系統就會將整體區域指標寫入作業回報為成功。這三個副本不一定位於區域內的不同可用區。

  • 區域：發生區域中斷時，受影響區域中的資源完全無法寫入及讀取指標。實際上，Cloud Monitoring 會將受影響的區域視為不存在。

  • 區域性：如果發生區域性中斷，受影響區域中的資源將完全無法寫入及讀取指標。實際上，Cloud Monitoring 會將受影響的區域視為不存在。

Cloud NAT

Cloud NAT (網路位址轉譯) 是一種分散式軟體定義代管服務，可讓沒有外部 IP 位址的特定資源建立連至網際網路的傳出連線。這項服務並非以 Proxy VM 或設備為依據。Cloud NAT 會改為設定Andromeda 軟體，為沒有外部 IP 位址的 VM 提供來源網路位址轉譯 (來源 NAT 或 SNAT)，藉此支援虛擬私有雲網路。Cloud NAT 也會針對已建立的傳入回應封包，提供目的地網路位址轉譯 (目的地 NAT 或 DNAT)。

如要進一步瞭解 Cloud NAT 的功能，請參閱說明文件。

可用區中斷：Cloud NAT 可抵禦可用區故障，因為控制層和網路資料層在區域內的多個可用區中都是多餘的。

區域性中斷：Cloud NAT 是區域性產品，因此無法承受區域性故障。

Cloud Router

Cloud Router 是一項全分散式和代管的 Google Cloud 服務，可使用邊界閘道通訊協定 (BGP) 公告 IP 位址範圍。並根據從對等互連接收的 BGP 通告，設定動態路徑。每個 Cloud Router 都包含軟體工作，可做為 BGP 揚聲器和回應器，而非實體裝置或設備。

如果區域服務中斷，具有高可用性 (HA) 設定的 Cloud Router 就能抵禦區域故障。在這種情況下，其中一個介面可能會失去連線能力，但流量會透過使用 BGP 的動態轉送功能，重新導向至另一個介面。

如果發生區域性中斷，Cloud Router 是區域性產品，因此無法抵禦區域性故障。如果客戶已啟用全域轉送模式，失敗區域與其他區域之間的轉送可能會受到影響。

Cloud Run

Cloud Run 是無狀態運算環境，客戶可在 Google 基礎架構上執行容器化程式碼。Cloud Run 是區域服務，因此客戶可以選擇區域，但無法選擇構成區域的可用區。系統會自動在區域內的各個可用區之間，進行資料和流量的負載平衡。系統會自動調度容器執行個體，以因應傳入流量，並視需要跨區域進行負載平衡。每個區域都會維護排程器，提供每個區域的自動調度功能。此外，系統也會瞭解其他可用區接收的負載，並在可用區內佈建額外容量，以因應任何可用區故障。

如果您使用 Cloud Run GPU，可以選擇關閉服務的可用區備援機制，改為在可用區中斷時盡可能維持穩定運作，以降低成本。詳情請參閱 GPU 可用區備援機制選項。

區域性服務中斷：Cloud Run 會儲存中繼資料和已部署的容器。這項資料會儲存在區域中，並以同步方式寫入。 只有在資料已提交至區域內的法定人數後，Cloud Run Admin API 才會傳回 API 呼叫。由於資料是儲存在區域中，資料平面作業也不會受到可用區故障影響。如果可用區故障，流量會轉送至其他可用區。

區域性中斷：客戶選擇要建立 Cloud Run 服務的 Google Cloud 區域。資料絕不會跨區域複製。Cloud Run 絕不會將客戶流量導向其他區域。如果發生區域性故障，只要問題解決，Cloud Run 就能恢復運作。建議客戶部署至多個區域，並使用 Cloud Load Balancing 提高可用性。

Cloud Shell

Cloud Shell 可讓使用者存取單一使用者 Compute Engine 執行個體，這些執行個體已預先設定，可用於新手入門、教育、開發和運算子工作。 Google Cloud

Cloud Shell 不適合執行應用程式工作負載，而是專為互動式開發和教育用途設計。這項服務設有每位使用者的執行階段配額限制，閒置一段時間後會自動關閉，且執行個體只能由指派的使用者存取。

支援服務的 Compute Engine 執行個體是區域資源，因此如果區域中斷，使用者就無法使用 Cloud Shell。

Cloud Source Repositories

Cloud Source Repositories 可讓使用者建立及管理私人原始碼存放區。這項產品採用全球模型設計，因此您不需要為區域或可用區復原能力進行設定。

反之，針對 Cloud Source Repositories 執行的 git push 作業會同步將來源存放區更新複製到多個區域的多個地區。也就是說，服務可抵禦任何單一區域的服務中斷。

如果特定可用區或區域發生服務中斷，流量會自動分配至其他可用區或區域。

自動從 GitHub 或 Bitbucket 鏡像存放區的功能，可能會受到這些產品的問題影響。舉例來說，如果 GitHub 或 Bitbucket 無法將新修訂版本通知 Cloud Source Repositories，或是 Cloud Source Repositories 無法從更新後的存放區擷取內容，鏡像作業就會受到影響。

Spanner

Spanner 是可擴充、高可用性、多版本、同步複製且具同步一致性的資料庫，並採用關聯式語意。

區域 Spanner 執行個體會在單一區域的三個可用區之間同步複製資料。寫入區域 Spanner 執行個體的作業會同步傳送至所有 3 個副本，且至少有 2 個副本 (2/3 的多數仲裁) 提交寫入作業後，系統才會向用戶端確認。這樣一來，即使某個區域發生故障，Spanner 仍可提供所有資料的存取權，因為最新的寫入作業已保存，且 2 個副本仍可達成多數決的寫入作業。

Spanner 多區域執行個體包含寫入仲裁，可跨三個區域的 5 個可用區同步複製資料 (預設主要區域和另一個區域各兩個讀寫備用資源，見證區域則有一個備用資源)。寫入多區域 Spanner 執行個體後，至少有 3 個備用資源 (3/5 的多數仲裁) 確認寫入，系統才會確認寫入作業。如果可用區或區域發生故障，Spanner 仍可存取所有資料 (包括最新寫入的資料)，並處理讀取/寫入要求，因為在向用戶端確認寫入作業時，資料至少會保留在 2 個區域的 3 個可用區中。

如要進一步瞭解這些設定，請參閱 Spanner 執行個體說明文件；如要進一步瞭解 Spanner 複製功能的運作方式，請參閱複製功能說明文件。

Cloud SQL

Cloud SQL 是適用於 MySQL、PostgreSQL 和 SQL Server 的全代管關聯資料庫服務。Cloud SQL 會使用代管式 Compute Engine 虛擬機器執行資料庫軟體。這項功能提供區域備援的高可用性設定，可保護資料庫免於可用區服務中斷的影響。您可以佈建跨區域副本，保護資料庫免於區域服務中斷。由於產品也提供區域選項，但這類選項無法因應區域或地區中斷，因此請務必選取高可用性設定、跨區域副本，或兩者皆選。

區域服務中斷：高可用性選項會在一個區域內的兩個不同區域中，建立主要和待命 VM 執行個體。在正常運作期間，主要 VM 執行個體會處理所有要求，並將資料庫檔案寫入地區永久磁碟，然後同步複製到主要和待命區域。如果可用區中斷影響主要執行個體，Cloud SQL 會啟動容錯移轉，將永久磁碟附加至待命 VM，並重新導向流量。

在此過程中，資料庫必須初始化，包括處理寫入交易記錄但未套用至資料庫的任何交易。未處理的交易數量和類型可能會增加 RTO 時間。近期寫入次數過多可能會導致未處理的交易積壓。RTO 時間最容易受到以下因素影響：(a) 近期寫入活動頻繁，以及 (b) 資料庫結構定義近期有變更。

最後，可用區服務中斷問題解決後，您可以手動觸發容錯回復作業，在主要可用區恢復服務。

如要進一步瞭解高可用性選項，請參閱 Cloud SQL 高可用性說明文件。

區域性服務中斷：跨區域副本選項會在其他區域建立主要執行個體的唯讀副本，保護資料庫免於區域性服務中斷。跨區域複製功能使用非同步複製，可讓主要執行個體在副本修訂交易前先修訂交易。交易在主要執行個體上提交的時間，與在副本上提交的時間之間的時間差，稱為「複製延遲」(可監控)。這項指標反映的交易包括：尚未從主要資料庫傳送至備用資源的交易，以及備用資源已接收但尚未處理的交易。如果發生區域性服務中斷，未傳送至副本的交易將無法使用。如果副本收到交易但未處理，就會影響復原時間，詳情如下。

Cloud SQL 建議您使用包含副本的設定測試工作負載，建立「安全每秒交易數 (TPS)」上限，也就是不會累積複製延遲的最高持續 TPS。如果工作負載超過安全 TPS 上限，就會累積複寫延遲，對 RPO 和 RTO 值造成負面影響。一般來說，請避免使用小型執行個體設定 (少於 2 個 vCPU 核心、少於 100 GB 的磁碟或 PD-HDD)，因為這類設定容易發生複寫延遲。

如果發生區域性服務中斷，您必須決定是否要手動升級唯讀副本。這是手動作業，因為升級可能會導致腦裂情況，也就是升級後的備用資源在升級時落後主要執行個體，但仍接受新交易。如果區域性中斷問題已解決，但您必須調解從主要執行個體傳播至備用執行個體的交易，這可能會導致問題。如果這對您的需求來說是個問題，不妨考慮使用 Spanner 等跨區域同步複製資料庫產品。

使用者觸發升級程序後，升級程序會按照與高可用性設定中待命執行個體啟動程序類似的步驟執行。在該程序中，讀取副本必須處理交易記錄，這會影響總復原時間。由於副本升級作業不涉及內建負載平衡器，請手動將應用程式重新導向至升級後的主要執行個體。

如要進一步瞭解跨區域備用資源選項，請參閱 Cloud SQL 跨區域備用資源說明文件。

如要進一步瞭解 Cloud SQL DR，請參閱下列文章：

Cloud Storage

Cloud Storage 提供全域整合型、可擴充且高度耐用的物件儲存空間。您可以在三種不同的位置類型中建立 Cloud Storage 值區：單一區域、雙區域或洲內多區域。使用區域值區時，物件會備援儲存在單一區域的可用區中。另一方面，雙區域和多區域 bucket 則提供異地備援機制。也就是說，新寫入的資料複製到至少一個遠端區域後，物件就會備援儲存在各個區域。與區域儲存空間相比，這種做法可為雙區域和多區域值區中的資料提供更廣泛的保護。

區域值區的設計宗旨是，即使單一可用區發生中斷，也能維持運作。如果某個可用區發生服務中斷，系統會自動從該地區的其他位置，以透明方式提供無法使用的可用區中的物件。資料和中繼資料會從初始寫入作業開始，跨可用區備援儲存。如果可用區無法使用，寫入作業不會遺失。如果發生區域性服務中斷，該區域的區域值區會離線，直到該區域恢復運作。

如需更高的可用性，您可以將資料儲存在雙區域或多區域設定中。雙區域和多區域值區是單一值區 (沒有個別的主要和次要位置)，但會跨區域以備援形式儲存資料和中繼資料。如果發生區域性服務中斷，服務不會受到影響。您可以將雙區域和多區域值區視為雙主動式，因為您可以在多個區域同時讀取和寫入工作負載，而值區仍保持強烈一致性。對於想要將工作負載分散到這兩個區域的客戶來說，這項功能特別有吸引力，因為這是災難復原架構的一部分。

雙區域和多區域會同步寫入中繼資料，因此具有強烈一致性。這種做法可讓服務隨時判斷物件的最新版本，以及可提供服務的位置 (包括遠端區域)。

資料會以非同步方式複製。也就是說，在 RPO 時間範圍內，新寫入的物件會先受到保護，成為區域物件，並在單一區域內的可用區之間提供備援機制。服務接著會在該 RPO 期間內，將物件複製到一或多個遠端地區，確保物件具有異地備援能力。複寫完成後，如果發生區域性中斷，系統會自動從另一個區域提供資料，使用者不會察覺。強化型複製功能是雙區域值區提供的進階功能，可縮短 RPO 窗口，目標是在 15 分鐘內複製完所有新寫入的物件，並確保這些物件具備異地備援能力。

RPO 是重要的考量因素，因為在區域性服務中斷期間，RPO 期間內寫入受影響區域的資料可能尚未複製到其他區域。因此，服務中斷期間可能無法存取該資料，如果受影響區域的資料遭到實體破壞，資料可能會遺失。

Cloud Translation

Cloud Translation 在多個可用區和區域都有運算伺服器。此外，這項服務也支援區域內跨可用區的資料同步複製功能。這些功能可協助 Translation 達成即時容錯移轉，避免區域故障造成任何資料遺失，且不需要客戶輸入或調整任何內容。如果發生區域性故障，Cloud Translation 就無法使用。

Compute Engine

Compute Engine 是 Google Cloud的基礎架構即服務選項之一。並運用 Google 的全球基礎架構，為客戶提供虛擬機器 (和相關服務)。

Compute Engine 執行個體是區域資源，因此如果區域發生中斷，執行個體預設會無法使用。Compute Engine 提供代管執行個體群組 (MIG)，可從預先設定的執行個體範本自動調度資源，增加 VM 數量，無論是在單一區域內，還是跨地區的多個區域，都能滿足需求。MIG 非常適合需要抵禦區域中斷的無狀態應用程式，但需要設定和資源規劃。您可以運用多個區域性 MIG，為無狀態應用程式提供區域服務中斷復原能力。

有狀態工作負載的應用程式仍可使用有狀態 MIG，但由於這類應用程式不會水平擴充，因此容量規劃時需要格外謹慎。無論是哪種情況，請務必預先正確設定及測試 Compute Engine 執行個體範本和 MIG，確保能順利容錯移轉至其他區域。詳情請參閱上方的「開發專屬參考架構和指南」一節。

單一用戶群

單一用戶群可讓您專屬存取單一用戶群節點，這是實體的 Compute Engine 伺服器，專門用於託管專案的 VM。

單一租戶節點與 Compute Engine 執行個體一樣，都是可用區資源。萬一發生可用區服務中斷，這些執行個體就無法使用。如要減輕區域故障的影響，您可以在其他區域中建立專屬節點。由於某些工作負載可能會基於授權或資本支出會計目的，而受益於單一租戶節點，因此您應事先規劃容錯移轉策略。

在不同位置重新建立這些資源可能會產生額外的授權費用，或違反資本支出會計規定。如需一般指引，請參閱「開發專屬的參考架構和指南」。

單一租戶節點是可用區資源，無法承受區域故障。 如要跨可用區調整規模，請使用區域性 MIG。

Compute Engine 網路

如要瞭解互連網路連線的高可用性設定，請參閱下列文件：

您可以全域或區域模式佈建外部 IP 位址，這會影響區域發生故障時的可用性。

Cloud Load Balancing 復原能力

負載平衡器是大多數高可用性應用程式的關鍵元件。請務必瞭解，整體應用程式的復原能力不僅取決於您選擇的負載平衡器範圍 (全域或區域)，也取決於後端服務的備援機制。

下表根據負載平衡器的分配或範圍，摘要說明負載平衡器的復原能力。

負載平衡器範圍 架構 可從區域中斷情況復原 可因應區域服務中斷
全球 將每個負載平衡器分散在所有區域中
跨區域 將每個負載平衡器分散在多個區域中
區域 將每個負載平衡器分散在區域中的多個可用區 特定區域發生中斷時，該區域的區域負載平衡器會受到影響

如要進一步瞭解如何選擇負載平衡器，請參閱 Cloud Load Balancing 說明文件。

連線能力測試

Connectivity Tests 是一項診斷工具，可檢查網路端點之間的連線。系統會分析設定，有時還會在端點間執行即時資料層分析。端點是網路流量的來源或目的地，例如 VM、Google Kubernetes Engine (GKE) 叢集、負載平衡器轉送規則或 IP 位址。Connectivity Tests 是一種診斷工具，不含資料層元件。不會處理或產生使用者流量。

區域中斷：連線能力測試資源是全域資源。如果發生區域性中斷，您可以管理及查看這些資源。連線測試資源是設定測試的結果。這些結果可能包括受影響區域中區域資源 (例如 VM 執行個體) 的設定資料。如果發生中斷，分析結果就不會準確，因為分析是根據中斷前的舊資料進行。請勿依賴這項功能。

區域性服務中斷：如果發生區域性服務中斷，您仍可管理及查看連線測試資源。連線測試資源可能包含受影響區域中區域資源的設定資料，例如子網路。如果發生中斷，分析結果就不會準確，因為分析是根據中斷前的舊資料進行。請勿依賴這項功能。

Container Registry

Container Registry 提供可擴充的 Docker Registry 託管實作項目，可安全且私密地儲存 Docker 容器映像檔。Container Registry 實作了 HTTP Docker Registry API。

Container Registry 是全域服務，預設會跨多個可用區和區域同步儲存映像檔中繼資料，容器映像檔會儲存在 Cloud Storage 多區域值區中。採用這項儲存策略後，Container Registry 在任何情況下都能提供可用區服務中斷復原能力，並為 Cloud Storage 非同步複製到多個區域的任何資料，提供區域服務中斷復原能力。

資料庫移轉服務

資料庫遷移服務是全代管的 Google Cloud 服務，可將其他雲端服務供應商或地端部署資料中心的資料庫遷移至 Google Cloud。

資料庫移轉服務的架構為區域控制層。控制層不會依附於特定區域中的個別可用區。在區域性中斷期間，您仍可存取 Database Migration Service API，包括建立及管理遷移作業。發生區域性中斷時，您將無法存取屬於該區域的資料庫移轉服務資源，直到中斷問題解決為止。

資料庫移轉服務取決於用於移轉程序的來源和目的地資料庫是否可用。如果資料庫遷移服務的來源或目的地資料庫無法使用，遷移作業會停止進行，但不會遺失任何客戶核心資料或工作資料。來源和目的地資料庫恢復運作後，遷移工作就會繼續執行。

舉例來說，您可以設定啟用高可用性 (HA) 的目的地 Cloud SQL 資料庫，取得可抵禦區域性中斷的目標資料庫。

資料庫移轉服務的遷移作業分為兩個階段：

  • 完整傾印：根據遷移工作規格，將來源資料完整複製到目的地。
  • 變更資料擷取 (CDC)：將來源的增量變更複製到目的地。

區域中斷：如果在上述任一階段發生區域故障，您仍可存取及管理資料庫移轉服務中的資源。資料遷移作業會受到下列影響：

  • 完整傾印：資料遷移作業失敗，您需要在目的地資料庫完成容錯移轉作業後，重新啟動遷移工作。
  • CDC：資料遷移作業已暫停。目的地資料庫完成容錯移轉作業後，遷移工作就會自動繼續。

區域性服務中斷：資料庫遷移服務不支援跨區域資源，因此無法因應區域性故障。

Dataflow

Dataflow 是 Google Cloud's 全代管無伺服器資料處理服務，適用於串流和批次管道。根據預設，地區端點會將 Dataflow 工作站集區設定為使用該地區內的所有可用區域。系統會在建立工作站時，為每個工作站計算可用區選取項目，盡量取得資源並使用未使用的預訂。在 Dataflow 工作的預設設定中，中繼資料會由 Dataflow 服務儲存，工作狀態則會儲存在後端。如果某個區域發生故障，Dataflow 工作仍可繼續執行，因為系統會在其他區域重新建立工作站。

限制如下：

  • 只有使用 Streaming Engine 或 Dataflow Shuffle 的工作，才支援區域放置。選擇不使用 Streaming Engine 或 Dataflow Shuffle 的工作無法使用區域性放置位置。
  • 區域刊登位置僅適用於 VM。不適用於 Streaming Engine 和 Dataflow Shuffle 相關資源。
  • VM 不會跨多個可用區複製。如果 VM 無法使用，系統會將其工作項目視為遺失，並由其他 VM 重新處理。
  • 如果整個區域都缺貨，Dataflow 服務就無法再建立任何 VM。

設計高可用性的 Dataflow 管道

您可以並行執行多個串流管道，以處理高可用性資料。舉例來說，您可以在不同區域執行兩項並行的串流作業。執行平行管道可為資料處理提供異地備援和容錯能力。考量資料來源和接收端的地理位置可用性，您就能在多地區高可用性設定中運作端對端管道。詳情請參閱「設計 Dataflow 管道工作流程」一文中的高可用性和地理位置冗餘。

如果區域或地區發生服務中斷情形，您可以重複使用 Pub/Sub 主題的相同訂閱項目，避免資料遺失。為確保資料重組期間不會遺失記錄，Dataflow 會使用上游備份，也就是傳送記錄的工作站會重試 RPC，直到收到記錄已接收的正面確認訊息，且處理記錄的副作用已提交至下游的永久儲存空間為止。如果傳送記錄的工作站無法使用，Dataflow 也會繼續重試 RPC。重試 RPC 可確保每筆記錄只會傳送一次。如要進一步瞭解 Dataflow 的「僅需處理一次」保證，請參閱「Dataflow 中的『僅需處理一次』」。

如果管道使用分組或時間區間設定，在區域或地區發生中斷後，您可以使用 Pub/Sub 的 Seek 功能或 Kafka 的 Replay 功能，重新處理資料元素，以得出相同的計算結果。如果管道使用的商業邏輯不依賴中斷前的資料，管道輸出內容的資料遺失量可降至 0 個元素。如果管道的商業邏輯依賴中斷前處理的資料 (例如使用長時間的滑動時間區間，或全域時間區間儲存不斷增加的計數器)，請使用 Dataflow 快照儲存串流管道的狀態，並啟動新版工作，而不會失去狀態。

Dataproc

Dataproc 提供串流和批次資料處理功能。 Dataproc 的架構是區域控制層，可讓使用者管理 Dataproc 叢集。控制層不會依附於特定區域中的個別可用區。因此，在可用區中斷期間，您仍可存取 Dataproc API，包括建立新叢集。

您可以在下列位置建立 Dataproc 叢集：

Compute Engine 上的 Dataproc 叢集

由於 Compute Engine 上的 Dataproc 叢集是區域資源，因此區域中斷會導致叢集無法使用，或毀損叢集。Dataproc 不會自動建立叢集狀態快照，因此區域中斷可能會導致正在處理的資料遺失。Dataproc 不會在服務中保留使用者資料。使用者可以設定管道，將結果寫入多個資料儲存庫；您應考量資料儲存庫的架構，並選擇可提供必要災害復原能力的產品。

如果某個區域發生服務中斷，您可以選擇在其他區域重新建立叢集的新執行個體，方法是選取其他區域，或使用 Dataproc 的自動放置功能，自動選取可用的區域。叢集可用後，資料處理作業就會繼續。您也可以啟用高可用性模式來執行叢集，降低部分區域中斷對主要節點的影響，進而降低對整個叢集的影響。

GKE 上的 Dataproc 叢集

GKE 上的 Dataproc 叢集可以是可用區或區域叢集。

如要進一步瞭解區域和地區 GKE 叢集的架構和 DR 功能，請參閱本文稍後的「Google Kubernetes Engine」一節。

Datastream

Datastream 是無伺服器變更資料擷取 (CDC) 和複製服務，能以最短的延遲時間穩定同步處理資料。並能將作業資料庫中的內容複製到 BigQuery 和 Cloud Storage、此外，您也可以使用 Dataflow 範本輕鬆整合 Dataflow，建立自訂工作流程，將資料載入 Cloud SQL 和 Spanner 等多個目的地。

可用區中斷：Datastream 是多可用區服務。即使發生完全非預期的區域服務中斷，也不會遺失任何資料或影響可用性。如果發生可用區故障，您仍可存取及管理 Datastream 中的資源。

區域性服務中斷：如果發生區域性服務中斷情形，Datastream 會在問題解決後恢復運作。

Document AI

Document AI 是一項文件解讀平台，可將文件中的非結構化資料轉為結構化資料，方便您解讀、分析及使用。Document AI 是區域性服務。客戶可以選擇區域，但無法選擇該區域內的可用區。 系統會自動在區域內的各個可用區之間，進行資料和流量的負載平衡。伺服器會自動調度資源以符合連入流量，並視需要跨區域取得負載平衡。每個區域都會維護排程器，提供每個區域的自動調整功能。排程器也會瞭解其他區域接收的負載，並在區域內佈建額外容量，以因應任何區域故障。

區域性服務中斷：Document AI 會儲存使用者文件和處理器版本資料。這項資料會儲存在區域中，並以同步方式寫入。由於資料是依區域儲存，資料平面作業不會受到區域故障影響。如果可用區發生故障，流量會自動轉送至其他可用區，但延遲時間取決於 Vertex AI 等相依服務的復原時間。

區域中斷：資料絕不會跨區域複製。如果發生區域性服務中斷，Document AI 不會執行容錯移轉。客戶可選擇要使用 Document AI 的 Google Cloud 區域。不過，該客戶流量絕不會轉送至其他區域。

端點驗證

管理員和安全營運專業人員可透過端點驗證功能，建立存取機構資料的裝置清單。端點驗證也是 Chrome Enterprise 進階版解決方案的一部分，可提供重要的裝置信任和安全防護存取控管功能。

如要概覽貴機構筆電和桌機的安全防護機制，請使用端點驗證。搭配 Chrome Enterprise Premium 方案使用端點驗證功能時，端點驗證有助於對資源強制執行精細的存取控制。 Google Cloud

端點驗證適用於 Google Cloud、Cloud Identity、Google Workspace Business 和 Google Workspace Enterprise。

Eventarc

Eventarc 會透過依狀態變更做出反應的鬆耦合服務，以非同步方式傳送來自 Google 供應商 (第一方)、使用者應用程式 (第二方) 和軟體即服務 (第三方) 的事件。客戶可設定目的地 (例如 Cloud Run 執行個體或第 2 代 Cloud Run 函式)，在事件供應商服務或客戶的程式碼中發生事件時觸發。

可用區中斷：Eventarc 會儲存與觸發條件相關的中繼資料。這項資料會儲存在區域中，並以同步方式寫入。Eventarc API 會建立及管理觸發條件和管道，但只會在資料已提交至區域內的仲裁時，傳回 API 呼叫。由於資料是儲存在區域中，因此資料平面作業不會受到可用區故障影響。如果可用區發生故障，流量會自動轉送至其他可用區。Eventarc 服務會跨區域複製，以接收及傳送第二方和第三方事件。這些服務會分散在各個區域。系統會自動從該地區的可用區域，處理對無法使用區域的要求。

區域性中斷：客戶選擇要建立 Eventarc 觸發程序的 Google Cloud 區域。資料絕不會跨區域複製。Eventarc 絕不會將客戶流量轉送至其他區域。如果發生區域性故障，只要解決停機問題，Eventarc 就能再次使用。如要提高可用性，建議客戶視需要將觸發程序部署至多個區域。

注意事項：

  • Eventarc 服務會盡力接收及傳送第一方事件，但不適用於 RTO/RPO。
  • Eventarc 會盡力為 Google Kubernetes Engine 服務傳送事件，但這項服務不適用於 RTO/RPO。

Filestore

「基本」和「可用區」層級是可用區資源。無法容許部署的可用區或區域發生故障。

區域層級 Filestore 執行個體是區域資源。Filestore 採用 NFS 要求的嚴格一致性政策。 用戶端寫入資料時，Filestore 會等到變更內容保留在兩個區域並完成複製後，才會傳回確認訊息，確保後續讀取作業會傳回正確資料。

如果區域發生故障，區域層級執行個體會繼續從其他區域提供資料，同時接受新的寫入作業。讀取和寫入作業的效能可能會降低，寫入作業也可能無法複製。金鑰會從其他區域提供，因此加密不會受到影響。

我們建議客戶建立外部備份，以防同一區域的其他可用區發生進一步的服務中斷。您可以使用備份資料，將執行個體還原至其他區域。

Firestore

Firestore 是 Firebase 和 Google Cloud提供的資料庫，具備彈性與擴充性，適用於行動、網頁和伺服器開發。Firestore 提供自動多區域資料複寫、同步一致性保證、完整批次作業和 ACID 交易。

Firestore 提供單一區域和多區域位置供客戶選擇。系統會自動在區域中的可用區之間進行負載平衡。

區域 Firestore 執行個體會在至少三個區域之間同步複製資料。如果可用區發生故障，其餘兩個 (或更多) 副本仍可提交寫入作業，且提交的資料會持續保留。流量會自動轉送至其他可用區。單一區域位置的成本和寫入延遲時間較短，且可與其他資源共置 Google Cloud。

Firestore 多區域執行個體會在三個區域的五個可用區 (兩個服務區域和一個見證區域) 中同步複製資料，可有效防範可用區和區域故障。如果發生可用區或區域故障，已提交的資料仍會保留。流量會自動導向服務區域/地區，且至少有兩個地區的三個區域會繼續提供提交內容。多地區可盡可能提高資料庫的可用性和耐用性。

防火牆深入分析

防火牆深入分析能讓您瞭解並最佳化防火牆規則。這項功能會提供防火牆規則使用情形的深入分析、建議和指標。防火牆洞察也會使用機器學習技術，預測未來防火牆規則的使用情形。防火牆深入分析可協助您在最佳化防火牆規則時做出更明智的決策。舉例來說，防火牆深入分析會找出分類為過於寬鬆的規則。您可以根據這項資訊，進一步嚴格控管防火牆設定。

區域性中斷：由於防火牆洞察資料會跨區域複製，因此不會受到區域性中斷影響，客戶流量也會自動轉送至其他區域。

區域性服務中斷：由於防火牆洞察資料會跨區域複製，因此不會受到區域性服務中斷影響，客戶流量也會自動轉送至其他區域。

機群

機群可讓客戶以群組形式管理多個 Kubernetes 叢集，並允許平台管理員使用多叢集服務。舉例來說，管理員可以透過機群，在所有叢集中套用一致的政策，或設定多叢集 Ingress。

將 GKE 叢集註冊至機群時，叢集預設會在同一區域中成為區域成員。向機群註冊非Google Cloud 叢集時，您可以選擇任何區域或全球位置。最佳做法是選擇靠近叢集實體位置的區域。使用 Connect Gateway 存取叢集時，這可提供最佳延遲時間。

如果可用區中斷，除非基礎叢集位於該可用區且無法使用，否則機群功能不會受到影響。

如果發生區域服務中斷，區域內成員叢集的機群功能會靜態失敗。如要減輕區域性服務中斷的影響，必須跨多個區域部署，如「為雲端基礎架構服務中斷設計災難復原機制」一文所述。

Google Cloud Armor

Google Cloud Armor 可協助您保護部署項目和應用程式，防範多種威脅，包括大量 DDoS 攻擊，以及跨網站指令碼和 SQL 注入等應用程式攻擊。Google Cloud Armor 會在 Google Cloud 負載平衡器中篩除不必要的流量，防止這類流量進入 VPC 並消耗資源。部分保護措施會自動啟用。部分服務需要您設定安全性政策，並將政策附加至後端服務或區域。全域範圍的 Google Cloud Armor 安全性政策會套用至全域負載平衡器。區域範圍的安全性政策會套用至區域負載平衡器。

區域服務中斷：如果區域服務中斷，Google Cloud 負載平衡器會將流量重新導向至其他區域，這些區域有可用的正常後端執行個體。Google Cloud Armor 安全性政策會同步複製到區域中的所有可用區，因此流量容錯移轉後，Google Cloud Armor 防護功能會立即生效。

區域性服務中斷：如果發生區域性服務中斷，全域 Google Cloud 負載平衡器會將流量重新導向至其他區域，這些區域有可用的正常後端執行個體。流量容錯移轉後，Google Cloud Armor 防護功能會立即生效，因為全域 Google Cloud Armor 安全性政策會同步複製到所有區域。如要防範區域性故障，請務必為所有區域設定 Google Cloud Armor 區域安全性政策。

Google Kubernetes Engine

Google Kubernetes Engine (GKE) 提供代管 Kubernetes 服務，可簡化在 Google Cloud上部署容器化應用程式的程序。您可以選擇區域或可用區叢集拓撲。

  • 建立區域叢集時，GKE 會在所選區域中佈建一個控制層機器，以及相同區域內的工作站機器 (節點)。
  • 如果是區域叢集，GKE 會在所選區域內的三個不同可用區，佈建三部控制層機器。根據預設，節點也會跨三個區域，但您可以選擇建立地區叢集，只在一個區域中佈建節點。
  • 多區域叢集與區域叢集類似，都包含一部主要機器，但多區域叢集還能將節點分散到多個區域。

可用區中斷：如要避免可用區中斷，請使用地區叢集。控制層和節點會分散在同一區域內的三個不同可用區中。可用區中斷不會影響部署在其他兩個可用區的控制層和工作站節點。

區域性服務中斷：如要減輕區域性服務中斷的影響，必須跨多個區域部署。雖然目前未以內建產品功能的形式提供，但多區域拓撲是許多 GKE 客戶目前採用的方法，可以手動實作。您可以建立多個地區叢集，在多個地區複製工作負載，並使用多叢集 Ingress 控制這些叢集的流量。

高可用性 VPN

高可用性 VPN (高可用性) 是彈性的 Cloud VPN 服務，可安全地加密從地端部署私有雲、其他虛擬私有雲或其他雲端服務供應商網路到 Google Cloud 虛擬私有雲 (VPC) 的流量。

高可用性 VPN 閘道有兩個介面，每個介面都有來自不同 IP 位址集區的 IP 位址，且在不同的 PoP 和叢集之間進行邏輯和實體分割，確保達到最佳備援效果。

區域中斷：如果發生區域中斷，其中一個介面可能會失去連線，但流量會透過動態轉送 (使用邊界閘道通訊協定 (BGP)) 重新導向至另一個介面。

區域性服務中斷：如果發生區域性服務中斷，兩個介面可能會短暫失去連線。

Identity and Access Management

身分與存取權管理 (IAM) 負責雲端資源所有動作的授權決策。IAM 會確認政策是否授予每項動作 (在資料層中) 的權限，並透過 SetPolicy 呼叫 (在控制層中) 處理這些政策的更新。

所有 IAM 政策都會在每個區域內的多個可用區中複製，協助 IAM 資料平面作業從其他區域的故障中復原，並容許每個區域內的可用區故障。IAM 資料平面可防範可用區和區域故障，因此能為高可用性提供多區域和多可用區架構。

IAM 控制層作業可能需要跨區域複製。SetPolicy 呼叫成功時，資料已寫入多個區域，但傳播至其他區域的作業最終會保持一致。IAM 控制層可抵禦單一區域故障。

Identity-Aware Proxy

Identity-Aware Proxy 可提供在 Google Cloud、其他雲端和地端部署環境中託管的應用程式存取權。IAP 會分散在各個區域，如果某個區域無法使用，系統會自動從該區域的其他可用區處理要求。

IAP 區域性中斷會影響對應用程式的存取權，這些應用程式託管於受影響的區域。建議您部署至多個區域，並使用 Cloud Load Balancing 提高可用性，防範區域中斷。

Identity Platform

客戶可透過 Identity Platform，在應用程式中加入可自訂的 Google 級身分與存取權管理功能。Identity Platform 是全球服務，客戶無法選擇資料儲存的區域或地帶。

區域性服務中斷：發生區域性服務中斷時，Identity Platform 會將要求容錯移轉至下一個最接近的儲存格。所有資料都會儲存在全球各地，因此不會遺失。

區域性服務中斷：發生區域性服務中斷時，Identity Platform 會暫時移除受影響區域的流量，因此對該區域發出的要求會失敗。當受影響區域不再有流量時，全域伺服器負載平衡服務會將要求轉送至最近的可用健康區域。所有資料都會儲存在全球各地，因此不會遺失。

Knative serving

Knative serving 是一項全球服務，可讓客戶在客戶叢集上執行無伺服器工作負載。目的是確保 Knative 服務工作負載正確部署在客戶叢集上，且 Knative 服務的安裝狀態會反映在 GKE Fleet API 功能資源中。這項服務只會在客戶叢集上安裝或升級 Knative serving 資源時參與運作。不參與執行叢集工作負載。啟用 Knative Serving 的專案所屬客戶叢集，會分散在多個區域和可用區的副本之間，每個叢集由一個副本監控。

區域和地區服務中斷：如果叢集是由服務中斷位置代管的副本監控，系統會自動在其他區域和地區的正常副本之間重新分配叢集。重新指派期間，Knative 服務可能會短暫無法監控部分叢集。如果使用者在這段期間決定在叢集上啟用 Knative serving 功能，叢集重新連線至正常的 Knative serving 服務副本後，就會開始在叢集上安裝 Knative serving 資源。

Looker (Google Cloud Core)

Looker (Google Cloud Core) 是一套商業智慧平台，可讓您透過 Google Cloud 控制台，輕鬆佈建、設定及管理 Looker 執行個體，過程簡便又順暢。使用者可以透過 Looker (Google Cloud Core) 探索資料、建立資訊主頁、設定快訊及共用報表。此外，Looker (Google Cloud Core) 還提供資料模型師適用的 IDE，以及開發人員適用的豐富嵌入和 API 功能。

Looker (Google Cloud Core) 由區域隔離的執行個體組成，可在區域內的可用區之間同步複製資料。請確認執行個體使用的資源 (例如 Looker (Google Cloud Core) 連線的資料來源) 與執行個體執行的區域相同。

區域性服務中斷：Looker (Google Cloud Core) 執行個體會儲存中繼資料和自行部署的容器。資料會同步寫入複製的執行個體。如果發生可用區中斷情形，Looker (Google Cloud Core) 執行個體會繼續從同一區域的其他可用區提供服務。資料提交至區域內的仲裁後，任何交易或 API 呼叫都會傳回。如果複製失敗，交易就不會提交，且使用者會收到失敗通知。如果多個區域發生故障，交易也會失敗，使用者會收到通知。Looker (Google Cloud Core) 會停止目前執行的任何時間表或查詢。解決失敗問題後，您必須重新排定或將這些工作加入佇列。

區域性服務中斷：受影響區域內的 Looker (Google Cloud Core) 執行個體無法使用。Looker (Google Cloud Core) 會停止目前執行的任何排程或查詢。解決失敗問題後，您必須重新安排或將查詢加入佇列。您可以在其他區域手動建立新執行個體。您也可以使用「從 Looker (Google Cloud Core) 執行個體匯入或匯出資料」一文定義的程序，復原執行個體。建議您設定定期匯出資料的程序，預先複製資產，以防發生區域性服務中斷的罕見情況。

Looker Studio

Looker Studio 是資料視覺化和商業智慧產品，客戶可以連結儲存在其他系統中的資料、使用這些資料建立報表和資訊主頁，並在整個機構中分享報表和資訊主頁。Looker Studio 是全球服務，不允許使用者選取資源範圍。

如果發生可用區服務中斷，Looker Studio 會繼續處理同地區或不同地區的請求，不會中斷服務。使用者資產會在各個區域同步複製。因此不會遺失資料。

如果發生區域性服務中斷，Looker Studio 會繼續從其他區域處理要求，不會中斷服務。使用者資產會在各區域同步複製。因此不會遺失資料。

Memorystore for Memcached

Memorystore for Memcached 是 Google Cloud's 代管的 Memcached 服務。 客戶可使用 Memorystore for Memcached 建立 Memcached 叢集，做為應用程式的高輸送量鍵值資料庫。

Memcached 叢集是區域型，節點會分布在客戶指定的所有區域。不過，Memcached 不會在節點間複製任何資料。因此，可用區故障可能會導致資料遺失，也就是部分快取清除。Memcached 執行個體會繼續運作，但節點數量會減少，因為服務不會在區域故障期間啟動任何新節點。不受影響的可用區中的 Memcached 節點會繼續處理流量，但可用區故障會導致快取命中率降低，直到該可用區恢復運作為止。

如果發生區域性故障，Memcached 節點不會處理流量。在這種情況下，資料會遺失，導致快取完全清除。如要減輕區域性服務中斷的影響，您可以實作架構，在多個區域中部署應用程式和 Memorystore for Memcached。

Memorystore for Redis

Memorystore for Redis 是適用於 Google Cloud 的全代管 Redis 服務，可減輕管理複雜 Redis 部署作業的負擔。目前提供 2 個級別：基本級和標準級。如果是基本級，區域或地區性服務中斷會導致資料遺失，也就是快取全數遭到清除。如果是標準層級，區域性服務中斷會導致資料遺失。由於標準級執行個體採用非同步複製，可用區中斷可能會導致部分資料遺失。

區域性中斷：標準級執行個體會將主要節點中資料集的作業，非同步複製到副本節點。如果主要節點所在區域發生中斷，系統會將副本節點升級為主要節點。促銷活動期間發生容錯移轉，Redis 用戶端必須重新連線至執行個體。重新連線後，作業就會繼續。如要進一步瞭解標準級 Memorystore for Redis 執行個體的高可用性，請參閱「Memorystore for Redis 高可用性」。

如果您在標準級執行個體中啟用唯讀備用資源，且只有一個備用資源，區域中斷期間就無法使用讀取端點。如要進一步瞭解唯讀備用資源的災難復原功能，請參閱「唯讀備用資源的故障模式」。

區域性中斷：Memorystore for Redis 是區域性產品，因此單一執行個體無法承受區域性故障。您可以排定定期工作，將 Redis 執行個體匯出至不同區域的 Cloud Storage 值區。發生區域性中斷時，您可以從匯出的資料集，在其他區域還原 Redis 執行個體。

多叢集服務探索和多叢集 Ingress

GKE 多叢集服務 (MCS) 包含多個元件。這些元件包括 Google Kubernetes Engine Hub (透過成員資格協調多個 Google Kubernetes Engine 叢集)、叢集本身，以及 GKE Hub 控制器 (多叢集 Ingress、多叢集服務探索)。中樞控制器會使用多個叢集上的後端，協調 Compute Engine 負載平衡器設定。

如果發生可用區中斷情形，多叢集服務探索會繼續處理來自其他可用區或區域的要求。如果發生區域性服務中斷，多叢集服務探索不會進行容錯移轉。

如果多叢集 Ingress 發生區域服務中斷，且設定叢集位於故障範圍內，使用者必須手動容錯移轉。資料平面會處於靜態故障狀態，並持續處理流量，直到使用者完成容錯移轉為止。為避免手動容錯移轉，請為設定叢集使用區域叢集。

如果區域發生中斷，多叢集 Ingress 不會容錯移轉。使用者必須制定 DR 計畫，手動將設定叢集容錯移轉。詳情請參閱「設定多叢集 Ingress」和「設定多叢集服務」。

如要進一步瞭解 GKE，請參閱「為雲端基礎架構中斷事件設計災難復原機制」一文的「Google Kubernetes Engine」一節。

Network Analyzer

Network Analyzer 會自動監控虛擬私有雲網路設定，並偵測錯誤和不盡理想的設定。這項功能可提供網路拓撲、防火牆規則、路徑、設定依附元件，以及服務和應用程式連線的深入分析資訊。識別網路故障、提供根本原因資訊，並建議可能的解決方法。

網路分析器會持續運作，並根據網路中近乎即時的設定更新，觸發相關分析。如果網路分析器偵測到網路故障，會嘗試將故障與最近的設定變更建立關聯，找出根本原因。並盡可能提供建議，詳細說明如何修正問題。

網路分析器是診斷工具，沒有資料層元件。不會處理或產生使用者流量。

可用區中斷：網路分析器服務會在全球各地複製，因此可用區中斷不會影響這項服務的可用性。

如果網路分析器的深入分析資訊包含發生中斷的區域設定，就會影響資料品質。該區域的設定相關網路洞察資料會過時。發生中斷時，請勿依賴網路分析器提供的任何深入分析資訊。

區域性服務中斷：網路分析器服務會在全球複製，因此不會受到區域性服務中斷影響。

如果網路分析器的深入分析資訊包含發生中斷的區域設定，就會影響資料品質。該區域的網路洞察資料會過時。發生中斷時，請勿依賴網路分析器提供的任何深入分析資訊。

Network Topology

Network Topology 是一種視覺化工具，可顯示網路基礎架構的拓撲。基礎架構檢視畫面會顯示虛擬私有雲 (VPC) 網路、與地端部署網路的混合連線、與 Google 代管服務的連線，以及相關指標。

可用區中斷：如果發生可用區中斷情形，該可用區的資料就不會顯示在網路拓撲中。其他區域的資料不會受到影響。

區域中斷：如果發生區域中斷，該區域的資料就不會顯示在網路拓撲中。其他區域的資料不會受到影響。

效能資訊主頁

效能資訊主頁可讓您深入瞭解整個 Google Cloud 網路的效能，以及專案資源的效能。

有了這些效能監控功能，您就能區分應用程式問題和基礎 Google Cloud 網路問題。您也可以調查過往的網路效能問題。效能資訊主頁也會將資料匯出至 Cloud Monitoring。您可以使用監控功能查詢資料，並取得其他資訊。

可用區中斷：

如果可用區服務中斷，受影響可用區的流量延遲和封包遺失資料不會顯示在效能資訊主頁。來自其他區域的流量延遲和封包遺失率資料不受影響。服務中斷結束後，延遲時間和封包遺失率資料就會恢復。

區域性服務中斷：

如果發生區域性服務中斷，受影響區域的流量延遲和封包遺失資料不會顯示在效能資訊主頁中。來自其他區域的流量延遲和封包遺失率資料不受影響。服務中斷結束後，延遲時間和封包遺失率資料就會恢復。

Network Connectivity Center

Network Connectivity Center 是一項網路連線管理產品，採用軸輻式架構。在這個架構中，中央管理資源會做為中樞，而每個連線資源則會做為輪輻。混合式輪輻目前支援高可用性 VPN、專屬和合作夥伴互連網路，以及主要第三方供應商的 SD-WAN 路由器設備。企業可透過 Network Connectivity Center 混合式 Spoke，將工作負載和服務連線至地端資料中心、其他雲端和分公司， Google Cloud Google Cloud 享有全球網路的涵蓋範圍。

可用區中斷：如果 Network Connectivity Center 混合式 Spoke 採用高可用性設定，即使可用區發生故障，也能正常運作，因為控制層和網路資料層會在區域內的多個可用區中備援。

區域性中斷：Network Connectivity Center 混合式輪輻是區域性資源，因此無法承受區域性故障。

網路服務級別

網路服務級別可讓您最佳化網際網路上系統與執行個體之間的連線。 Google Cloud 這項服務提供兩種不同的服務級別：進階級和標準級。在進階級中，全域通告的任播進階級 IP 位址可做為地區或全域後端的前端。使用標準級時，地區性發布的標準級 IP 位址可做為地區性後端的前端。應用程式的整體韌性會受到網路服務層級和相關聯後端冗餘的影響。

可用區中斷：與區域備援後端相關聯時，進階級和標準級都能提供可用區中斷的復原能力。發生區域性中斷時，使用區域性備援後端的案例會根據相關聯的後端本身，決定容錯移轉行為。如果與區域後端相關聯，服務會在停機問題解決後恢復運作。

區域服務中斷：進階級別與全球備援後端建立關聯時，可提供區域服務中斷的復原能力。在 Standard 級中，前往受影響區域的所有流量都會失敗。其他地區的流量不受影響。如果發生區域性服務中斷，使用進階級層和全域備援後端的案例，其容錯移轉行為取決於相關聯的後端本身。使用 Premium 級搭配區域後端或 Standard 級時，服務會在停機問題解決後立即恢復運作。

機構政策服務

機構政策服務可讓您透過程式以集中方式控管機構的 Google Cloud 資源。身為機構政策管理員，您可以設定整個資源階層的限制。

可用區中斷：機構政策服務建立的所有機構政策，都會在每個區域內的多個可用區中非同步複製。每個區域內的可用區故障不會影響機構政策資料和控制層作業。

區域性服務中斷：機構政策服務建立的所有機構政策，都會非同步複製到多個區域。機構政策控制層作業會寫入多個區域，並在幾分鐘內傳播至其他區域。機構政策控制層可抵禦單一區域故障。組織政策資料平面作業可從其他區域的故障中復原，且組織政策資料平面可抵禦可用區和區域故障，因此能為高可用性提供多區域和多可用區架構。

封包鏡像

封包鏡像功能可複製虛擬私有雲 (VPC) 網路中指定執行個體的流量，並將複製的資料轉送至區域內部負載平衡器後方的執行個體，以供檢查。封包鏡像作業會擷取所有流量和封包資料，包括酬載和標頭。

如要進一步瞭解 Packet Mirroring 的功能，請參閱 Packet Mirroring 總覽頁面。

區域中斷：設定內部負載平衡器，確保多個區域都有執行個體。如果發生區域性中斷，封包鏡像會將複製的封包轉送到健康狀態良好的區域。

區域性服務中斷：封包鏡像為區域性產品。如果發生區域性服務中斷，受影響區域中的封包就不會複製。

Persistent Disk

永久磁碟提供區域和地區設定。

區域永久磁碟會託管在單一區域中。如果磁碟的區域無法使用，永久磁碟也會無法使用，直到區域中斷問題解決為止。

地區永久磁碟可在同一地區內的兩個區域之間提供資料同步複製功能。如果虛擬機器的可用區發生中斷情形，您可以將地區永久磁碟強制連接至磁碟次要可用區的 VM 執行個體。如要執行這項工作，您必須在該區域中啟動另一個 VM 執行個體，或維護該區域中的熱待命 VM 執行個體。

如要跨區域非同步複製永久磁碟中的資料，可以使用永久磁碟非同步複製 (PD 非同步複製)，這項功能提供低 RTO 和 RPO 的區塊儲存空間複製功能，適用於跨區域主動/被動式災難復原。萬一發生區域性服務中斷情形，PD 非同步複製功能可讓您將資料容錯移轉至次要區域，並在該區域重新啟動工作負載。

Personalized Service Health

Personalized Service Health 會通知您與 Google Cloud 專案相關的服務中斷情形。這項服務提供多種管道和程序，可查看或整合中斷事件 (事件、預定維護) 到事件應變程序中，包括：

  • Google Cloud 控制台中的資訊主頁
  • 服務 API
  • 可自行設定的快訊
  • 產生記錄並傳送至 Cloud Logging

區域性服務中斷：資料是從全球資料庫提供，不限於特定地點。如果發生可用區中斷情形，服務健康狀態仍可處理要求，並自動將流量重新導向至同一區域內仍在運作的可用區。如果 Service Health 可以從 Service Health 資料庫擷取事件資料，就能順利傳回 API 呼叫。

區域性服務中斷：資料來自全球資料庫，不限於特定地點。如果發生區域性中斷，服務健康狀態仍可處理要求，但容量可能會減少。記錄位置發生區域性故障時，可能會影響使用記錄或 Cloud 警報通知的 Service Health 使用者。

Private Service Connect

Private Service Connect 是 Google Cloud網路功能，可讓使用者從虛擬私有雲網路內部，以私密方式存取代管服務。同樣地，代管服務供應商也能在自己的獨立 VPC 網路中代管這些服務，並為消費者提供私人連線。

已發布服務的 Private Service Connect 端點

Private Service Connect 端點會使用 Private Service Connect 轉送規則，連線至服務供應商虛擬私有雲網路中的服務。服務供應商會透過私人連線向服務用戶提供服務，方法是公開單一服務連結。服務消費者就能從虛擬私有雲指派虛擬 IP 位址給這類服務。

區域性中斷：來自消費者虛擬私有雲端用戶端端點所產生 VM 流量的 Private Service Connect 流量，仍可存取服務供應商內部虛擬私有雲網路中公開的代管服務。這是因為 Private Service Connect 流量會容錯移轉至其他區域中較健康的服務後端。

區域性服務中斷：Private Service Connect 是區域性產品。無法因應區域服務中斷。多區域代管服務可透過在多個區域設定 Private Service Connect 端點，在區域中斷期間維持高可用性。

Google API 的 Private Service Connect 端點

Private Service Connect 端點會使用 Private Service Connect 轉送規則連線至 Google API。這項轉送規則可讓客戶使用自訂端點名稱和內部 IP 位址。

可用區中斷：來自消費者虛擬私有雲用戶端端點的 Private Service Connect 流量仍可存取 Google API，因為 VM 與端點之間的連線會自動容錯移轉至同一區域中的其他正常運作可用區。如果服務中斷時已有要求正在傳輸，系統會根據用戶端的 TCP 超時和重試行為進行復原。

詳情請參閱 Compute Engine 復原一文。

區域性服務中斷：Private Service Connect 是區域性產品。無法因應區域服務中斷。多區域代管服務可透過在多個區域設定 Private Service Connect 端點，在區域中斷期間維持高可用性。

如要進一步瞭解 Private Service Connect，請參閱「Private Service Connect 類型」一文中的「端點」一節。

Pub/Sub

Pub/Sub 是一項訊息服務，可用於整合應用程式和進行串流分析。Pub/Sub 主題是全域資源，因此可從任何 Google Cloud 位置檢視及存取。不過，任何指定訊息都會儲存在單一「 Google Cloud 」區域，該區域會是距離發布商最近，且符合資源位置政策的區域。因此，主題的訊息可能會儲存在不同區域 Google Cloud。Pub/Sub 訊息儲存政策可限制訊息儲存的區域。

可用區中斷：發布 Pub/Sub 訊息時，系統會將訊息同步寫入區域內至少兩個可用區的儲存空間。因此，如果單一可用區無法使用，對客戶不會造成任何影響。

區域服務中斷：區域服務中斷時，您無法存取儲存在受影響區域的訊息。發布者和訂閱者無法透過區域端點或全域端點，連線至受影響的區域。連線至其他地區的發布者和訂閱者仍可連線，且其他地區的可用訊息會傳送至網路中最近且有容量的訂閱者。

如果應用程式依賴訊息排序，請參閱 Pub/Sub 團隊提供的詳細建議。系統會依區域提供訊息排序保證，如果您使用全域端點，這項保證可能會中斷。

reCAPTCHA

reCAPTCHA 是一項全球服務，可偵測詐欺活動、垃圾內容和濫用行為。不需要或允許設定區域或可用區復原能力。設定中繼資料的更新會非同步複製到 reCAPTCHA 執行的每個區域。

如果發生區域服務中斷，reCAPTCHA 會繼續從相同或不同區域的其他區域處理要求，不會中斷服務。

如果發生地區性服務中斷，reCAPTCHA 會繼續從其他地區處理要求，不會中斷服務。

Secret Manager

Secret Manager 是Google Cloud的密鑰和憑證管理產品。透過 Secret Manager，您可以輕鬆稽核及限制密鑰存取權、加密靜態密鑰，並確保機密資訊受到 Google Cloud保護。

Secret Manager 資源通常會使用自動複製政策 (建議)，因此會在全球各地複製。如果貴機構的政策不允許密鑰資料進行全域複製，則可使用使用者管理的複製政策建立 Secret Manager 資源，並選擇要將密鑰複製到一或多個區域。

區域服務中斷：如果發生區域服務中斷，Secret Manager 會繼續從相同或不同區域的其他區域提供服務，不會中斷。在每個區域中，Secret Manager 一律會在不同區域中維護至少 2 個副本 (大多數區域為 3 個副本)。區域中斷問題解決後，系統就會還原完整備援。

區域服務中斷：如果發生區域服務中斷，假設資料已複製到多個區域 (透過自動複製或使用者管理複製到多個區域)，Secret Manager 會繼續從其他區域提供服務，不會中斷。區域中斷問題解決後，系統就會還原完整備援。

Security Command Center

Security Command Center 是 Google Cloud 的全球即時風險管理平台。當中包含兩個主要元件：偵測器和發現項目。

偵測器會受到區域和地區性中斷的影響，但影響方式不同。 發生區域性服務中斷時，偵測器無法為區域資源產生新的發現項目，因為偵測器應掃描的資源無法使用。

區域中斷期間，偵測器可能需要幾分鐘到幾小時的時間才能恢復正常運作。Security Command Center 不會遺失發現項目資料。 此外，系統也不會為無法使用的資源產生新的發現資料。最糟的情況是，Container Threat Detection 代理程式在連線至正常運作的儲存格時，可能會耗盡緩衝區空間，導致偵測結果遺失。

由於調查結果會跨區域同步複製，因此不會受到區域和可用區中斷的影響。

Sensitive Data Protection (包括 DLP API)

Sensitive Data Protection 提供機密資料分類、剖析、去識別化、權杖化和隱私權風險分析服務。這項服務會同步處理要求主體中傳送的資料，或非同步處理雲端儲存系統中已有的資料。您可以透過全域或區域專屬端點叫用 Sensitive Data Protection。

全域端點：這項服務的設計宗旨是靈活應對區域和可用區故障。如果服務在發生故障時超載，傳送至服務 hybridInspect 方法的資料可能會遺失。

如要建立可避免故障的架構，請加入邏輯，檢查 hybridInspect 方法產生的最新故障前發現項目。如果發生中斷情形，傳送至該方法中的資料可能會遺失，但不會超過失敗事件發生前 10 分鐘的資料量。如果發現結果的時間距離中斷開始時間不到 10 分鐘，表示導致該發現結果的資料並未遺失。在這種情況下，即使資料位於 10 分鐘間隔內，也不需要重播發現時間戳記之前的資料。

區域端點：區域端點無法因應區域故障。如要防範區域故障，請考慮容錯移轉至其他區域。區域故障特徵與上述相同。

服務使用情形

Service Usage API 是 Google Cloud 的基礎架構服務，可讓您列出及管理 Google Cloud 專案中的 API 與服務。您可以列出及管理 Google Google Cloud和第三方生產者提供的 API 和服務。Service Usage API 是全球服務，可抵禦可用區和區域中斷。如果發生可用區或區域中斷情形，Service Usage API 會繼續處理來自其他區域不同可用區的要求。

如要進一步瞭解服務使用情形，請參閱服務使用情形說明文件。

Speech-to-Text

語音轉文字功能可運用類神經網路模型等機器學習技術，將語音音訊轉換為文字。音訊可從應用程式的麥克風即時傳送，也可以批次處理音訊檔案。

可用區中斷：

  • Speech-to-Text API v1：在區域中斷期間，Speech-to-Text API 第 1 版會繼續處理同一區域中其他區域的要求，不會中斷服務。不過，在失敗區域中執行的任何工作都會遺失。使用者必須重試失敗的作業，系統會自動將作業轉送至可用的區域。

  • Speech-to-Text API 第 2 版：在可用區中斷期間，Speech-to-Text API 第 2 版會繼續處理同一區域中其他可用區的要求。不過，在發生故障的區域中執行的任何工作都會遺失。使用者必須重試失敗的作業，系統會自動將作業轉送至可用的區域。只有在資料已提交至區域內的法定人數後，Speech-to-Text API 才會傳回 API 呼叫。在部分地區，AI 加速器 (TPU) 僅在一個區域提供。在這種情況下，該區域發生服務中斷時，語音辨識會失敗，但不會遺失資料。

區域性服務中斷：

  • Speech-to-Text API v1：Speech-to-Text API 第 1 版是全球多區域服務，因此不會受到區域性故障影響。服務會繼續處理來自其他區域的要求，不會中斷。不過，目前在失敗區域內執行的工作會遺失。使用者必須重試失敗的作業，系統會自動將作業轉送至可用區域。

  • Speech-to-Text API v2：

    • 多區域 Speech-to-Text API 第 2 版，服務會繼續從同一區域的其他區域處理要求，不會中斷。

    • 單一區域 Speech-to-Text API 第 2 版：服務會將工作執行範圍限制在要求的區域。Speech-to-Text API 第 2 版不會將流量轉送至其他區域，也不會將資料複製到其他區域。發生區域性故障時，Speech-to-Text API 第 2 版將無法在該區域使用。不過，服務中斷問題解決後，你就能再次使用。

Storage 移轉服務

Storage Transfer Service 可管理從各種雲端來源到 Cloud Storage 的資料移轉作業，以及檔案系統之間的資料移轉作業。

Storage 移轉服務 API 是全球資源。

Storage 移轉服務取決於移轉作業來源和目的地的可用性。如果轉移來源或目的地無法使用，轉移作業就會停止。不過，客戶核心資料或工作資料不會遺失。來源和目的地恢復運作後，系統會繼續轉移資料。

您可以使用 Storage 移轉服務，無論是否搭配代理程式，做法如下：

  • 無代理程式轉移會使用區域工作站來調度轉移工作。

  • 代理程式式移轉作業會使用安裝在基礎架構上的軟體代理程式。代理程式式轉移作業取決於轉移代理程式是否可用，以及代理程式是否能連線至檔案系統。決定要安裝轉移代理程式的位置時，請考量檔案系統的可用性。舉例來說，如果您在多個 Compute Engine VM 上執行轉移代理程式，將資料轉移至 Enterprise 級 Filestore 執行個體 (區域資源)，請考慮將 VM 放在 Filestore 執行個體所在區域的不同可用區。

    如果代理程式無法使用，或與檔案系統的連線中斷，傳輸作業就會停止，但不會遺失任何資料。如果所有代理程式程序都終止，轉移工作就會暫停，直到將新代理程式新增至轉移作業的代理程式集區為止。

服務中斷期間，Storage 移轉服務的行為如下：

  • 可用區服務中斷：可用區服務中斷時，Storage Transfer Service API 仍可使用，您也可以繼續建立移轉工作。資料會繼續轉移。

  • 區域服務中斷：區域服務中斷期間，Storage 移轉服務 API 仍可使用，您也可以繼續建立移轉工作。如果移轉作業人員位於受影響的區域，資料移轉作業會停止，直到該區域恢復運作，移轉作業才會自動繼續。

Vertex 機器學習中繼資料

Vertex 機器學習中繼資料可讓您記錄機器學習系統產生的中繼資料和構件，並查詢該中繼資料，以利分析、偵錯及稽核機器學習系統的效能，或其產生的構件。

可用區中斷：在預設設定中，Vertex 機器學習中繼資料可防範可用區故障。這項服務會部署在每個區域的多個可用區，且資料會在每個區域的不同可用區之間同步複製。如果可用區故障，其餘區域會接管作業，盡量減少中斷時間。

區域性服務中斷：Vertex 機器學習中繼資料是區域化服務。如果發生區域性服務中斷，Vertex 機器學習中繼資料不會容錯移轉至其他區域。

Vertex AI 批次預測

使用者可透過批次預測，在 Google 基礎架構上對 AI/ML 模型執行批次預測。批次預測是區域性服務。客戶可以選擇執行作業的區域，但無法選擇該區域內的特定可用區。批次預測服務會自動在所選區域內的不同可用區之間，平衡工作負載。

區域中斷：批次預測會在區域內儲存批次預測工作的中繼資料。資料會同步寫入該區域內的多個可用區。如果可用區發生服務中斷，批次預測會部分失去執行工作的工作人員，但系統會自動在其他可用區新增工作人員。如果多次重試批次預測都失敗，使用者介面和 API 呼叫要求都會將工作狀態列為「失敗」。後續使用者執行作業的要求會轉送至可用區域。

區域性服務中斷：客戶選擇要執行批次預測工作的 Google Cloud 區域。資料絕不會跨區域複製。批次預測會將工作執行範圍限定在所要求的區域，絕不會將預測要求轉送至其他區域。發生區域性故障時，該區域無法使用批次預測功能。服務中斷問題解決後，即可再次使用。 建議客戶使用多個區域執行作業。如果發生區域服務中斷，請將工作導向其他可用區域。

Vertex AI Model Registry

Vertex AI Model Registry 可讓使用者在中央存放區中，簡化模型管理、控管及機器學習模型的部署作業。Vertex AI Model Registry 是區域性服務，具備高可用性，可防範可用區服務中斷。

區域性服務中斷：Vertex AI Model Registry 可防範區域性服務中斷。這項服務會部署在每個區域的三個可用區，並在區域內的不同可用區之間同步複製資料。如果某個可用區發生故障，其餘可用區會接管作業，確保資料不會遺失，並將服務中斷時間降到最低。

區域性服務中斷：Vertex AI Model Registry 是區域性服務。 如果某個區域發生故障，模型登錄服務不會進行容錯移轉。

Vertex AI 線上預測

使用者可透過線上預測功能，在 Google Cloud 上部署 AI/機器學習模型。線上預測是區域性服務。客戶可以選擇部署模型的區域，但無法選擇該區域內的特定可用區。預測服務會自動在所選區域內的不同區域之間，進行工作負載的負載平衡。

區域性服務中斷：線上預測不會儲存任何客戶內容。區域中斷會導致目前的預測要求執行失敗。線上預測可能會或可能不會自動重試預測要求，視使用的端點類型而定。具體來說，公開端點會自動重試，但私人端點不會。為協助處理失敗情況並提升復原能力，請在程式碼中加入指數輪詢策略的重試邏輯。

區域性服務中斷：客戶選擇要執行 AI/ML 模型和線上預測服務的 Google Cloud 區域。資料絕不會跨區域複製。線上預測會將 AI/ML 模型執行作業範圍限定在所要求的地區，絕不會將預測要求傳送至其他地區。發生區域性故障時，該區域的線上預測服務會無法使用。服務中斷問題解決後，你就能再次使用。建議客戶使用多個區域執行 AI/ML 模型。如果發生區域性服務中斷，請將流量導向其他可用的區域。

Vertex AI Pipelines

Vertex AI Pipelines 是 Vertex AI 服務，可讓您以無伺服器的方式，自動化處理、監控及管理機器學習 (ML) 工作流程。Vertex AI Pipelines 的設計宗旨是提供高可用性，並防範區域性故障。

區域性中斷：在預設設定中，Vertex AI Pipelines 可防止區域性故障。這項服務會部署在每個區域的多個可用區，並在區域內的不同可用區之間同步複製資料。如果可用區故障，其餘區域會接管作業，盡量減少中斷時間。

區域性服務中斷：Vertex AI Pipelines 是區域性服務。如果發生區域性服務中斷，Vertex AI Pipelines 不會容錯移轉至其他區域。如果發生區域性中斷，建議您在備份區域執行管道作業。

Vertex AI Search 是可自訂的搜尋解決方案，具備生成式 AI 功能和原生企業法規遵循功能。Vertex AI Search 會自動部署及複製到 Google Cloud內的多個區域。您可以選擇支援的多區域 (例如全球、美國或歐盟)，設定資料的儲存位置。

區域和地區性服務中斷： UserEvents上傳至 Vertex AI Search 的資料可能無法復原，因為非同步複製作業會延遲。由於自動容錯移轉和同步資料複製功能，Vertex AI Search 提供的其他資料和服務仍可使用。

Vertex AI 訓練

Vertex AI Training 可讓使用者在 Google 基礎架構上執行自訂訓練工作。Vertex AI Training 是區域服務，也就是說，客戶可以選擇要執行訓練工作的區域。不過，客戶無法選擇該區域內的特定可用區。訓練服務可能會自動在地區內的不同區域之間，進行工作執行負載平衡。

區域性服務中斷：Vertex AI Training 會儲存自訂訓練工作的這項資料會儲存在區域中，並以同步方式寫入。只有在將這項中繼資料提交至區域內的仲裁後，Vertex AI Training API 呼叫才會傳回。訓練工作可能會在特定區域執行。區域性中斷會導致目前的工作執行失敗。如果發生這種情況，服務會將工作重新導向至其他可用區域，自動重試工作。如果多次重試都失敗，工作狀態會更新為失敗。後續使用者執行作業的要求會轉送至可用區。

區域性服務中斷：客戶可選擇要執行訓練工作的 Google Cloud 區域。資料絕不會跨區域複製。 Vertex AI Training 會將工作執行範圍限定在所要求的區域，絕不會將訓練工作轉送至其他區域。如果發生區域性故障，Vertex AI Training 服務在該區域會無法使用，故障排除後即可恢復。建議客戶使用多個區域執行作業，並在區域發生中斷時，將作業導向其他可用的區域。

虛擬私人雲端 (VPC)

VPC 是全球服務，可為資源 (例如 VM) 提供網路連線。不過，失敗是區域性的。如果可用區發生故障，該可用區中的資源就無法使用。同樣地，如果某個區域發生故障，只有往返該區域的流量會受到影響。健康區域的連線不受影響。

區域中斷：如果 VPC 網路涵蓋多個區域，且其中一個區域發生故障，VPC 網路在正常運作的區域中仍可正常運作。在故障期間，健康區域中的資源之間仍可正常傳輸網路流量。區域故障只會影響進出故障區域資源的網路流量。為降低可用區故障的影響，建議您不要在單一可用區中建立所有資源。請改為在建立資源時，將資源分散到各個區域。

區域中斷：如果虛擬私有雲網路涵蓋多個區域，且其中一個區域發生故障，虛擬私有雲網路在正常運作的區域中仍會保持正常。在故障期間，正常區域中的資源之間仍可正常傳輸網路流量。區域故障只會影響故障區域中資源的網路流量。為減輕區域故障的影響，建議您將資源分散至多個區域。

VPC Service Controls

VPC Service Controls 是區域服務，企業資安團隊可使用 VPC Service Controls 定義精細的範圍控管機制，並將這些安全防護設定套用於多個 Google Cloud 服務與專案。客戶政策會反映區域情況。

區域中斷：VPC Service Controls 會繼續從同一區域的其他區域提供服務，不會中斷。

區域性服務中斷：在受影響區域中，設定為強制執行 VPC Service Controls 政策的 API 將無法使用，直到該區域恢復運作為止。如果希望提高可用性，建議客戶將 VPC Service Controls 強制執行的服務部署至多個區域。

工作流程

Workflows 是一項自動化調度管理產品，可讓 Google Cloud客戶：

  • 部署及執行工作流程，透過 HTTP 連接其他現有服務，
  • 自動化處理程序，包括等待 HTTP 回應，並自動重試長達一年，以及
  • 以低延遲的事件導向執行作業實作即時處理。

Workflows 客戶可以部署工作流程，說明要執行的業務邏輯，然後直接透過 API 或事件導向觸發條件 (目前僅限 Pub/Sub 或 Eventarc) 執行工作流程。執行的工作流程可以操控變數、發出 HTTP 呼叫並儲存結果，或是定義回呼並等待其他服務繼續執行。

區域性服務中斷：工作流程原始碼不會受到區域性服務中斷影響。Workflows 會儲存工作流程的原始碼，以及正在執行的工作流程收到的變數值和 HTTP 回應。原始碼會儲存在區域中，並以同步方式寫入：只有在元資料已提交至區域內的仲裁後，控制平面 API 才會傳回。變數和 HTTP 結果也會儲存在區域中，並以同步方式寫入，至少每五秒一次。

如果可用區發生故障，系統會根據上次儲存的資料自動繼續執行工作流程。不過，系統不會自動重試尚未收到回應的 HTTP 要求。如要安全地重試要求，請按照說明文件所述使用重試政策。

區域性服務中斷：工作流程是區域化服務，如果發生區域性服務中斷，工作流程不會容錯移轉。如果需要更高的可用性，建議客戶將 Workflows 部署至多個區域。

Cloud Service Mesh

Cloud Service Mesh 可讓您設定跨多個 GKE 叢集的代管服務網格。這份文件僅適用於代管 Cloud Service Mesh，叢集內變體為自行代管，因此應遵循一般平台指南。

區域中斷：由於網格設定儲存在 GKE 叢集中，只要叢集是區域叢集，就能抵禦區域中斷。產品用於內部記帳的資料會儲存在區域或全球，如果單一區域停止服務，不會受到影響。控制層與支援的 GKE 叢集位於相同區域 (如果是區域叢集，則位於所屬區域)，因此不會受到單一區域中斷的影響。

區域性服務中斷：Cloud Service Mesh 為區域或可用區 GKE 叢集提供服務。如果發生區域性中斷，Cloud Service Mesh 不會執行容錯移轉。GKE 也不會。建議客戶部署由涵蓋不同地區的 GKE 叢集組成的網格。

Service Directory

Service Directory 是可讓您探索、發布及連結服務的平台。並在單一位置提供所有服務的即時資訊。無論您只有幾個或是擁有數千個服務端點，Service Directory 都能協助您大規模管理服務資產。

服務目錄資源會根據使用者指定的位置參數，在相應區域中建立。

區域中斷：發生區域中斷時，服務目錄會繼續處理來自相同或不同區域中其他區域的要求，不會中斷。在每個區域中，服務目錄一律會維護多個副本。區域性中斷問題解決後，系統就會恢復完整備援。

區域性服務中斷：Service Directory 無法因應區域性服務中斷。