跨 Google Cloud 區域遷移：在 Google Cloud 上設計具備復原能力的單一區域環境

Last reviewed 2024-12-08 UTC

本文件可協助您在Google Cloud上設計具備韌性的單一區域環境。如果您打算遷移單一區域環境，或正在評估日後是否要這麼做，並想瞭解可能的情況，這份文件會很有幫助。

本文件是系列文章的一部分：

本文旨在提供相關指引，說明如何在 Google Cloud上設計具備韌性的單一區域環境，並著重於下列架構元件：

本文件中的指南假設您正在設計及實作單一區域環境。如果您目前使用單一區域環境，日後可以遷移至多區域環境。如果您考慮日後將可用區和單一區域環境遷移及演進至多區域環境，請參閱「跨 Google Cloud 區域遷移：開始使用」。

不同部署原型的屬性

Google Cloud 產品在許多區域和可用區都有提供。

設計 Google Cloud 環境時，您可以選擇下列部署原型，依可靠性和作業負擔遞增順序排列：

  • Zonal：在區域內的單一可用區中佈建 Google Cloud 資源，並在可用區服務可用的情況下使用。如果沒有可用可用區服務，則使用區域性服務。
  • 區域：您在區域內的多個可用區佈建 Google Cloud資源，並盡可能使用區域服務。
  • 多區域：在不同區域的多個可用區中佈建 Google Cloud 資源。可用區資源會在各區域的一或多個可用區中佈建。
  • 全球：您在世界各地不同區域的多個可用區中佈建 Google Cloud 資源。可用區資源會在每個區域的一或多個可用區中佈建。

上述部署原型具有不同的可靠性屬性，您可以使用這些屬性，提供環境所需的可靠性保證。舉例來說，與單一區域或可用區環境相比，多區域環境較有可能在區域性中斷事件中存活。如要進一步瞭解各部署原型架構的可靠性屬性，請參閱「如何運用可用區和區域達成可靠性」和「Google Cloud 基礎架構可靠性指南」。

由於每個部署原型都有不同的成本和複雜度屬性，因此根據這些部署原型設計、實作及操作環境時，所需的工作量也不同。舉例來說，與區域或多區域環境相比，可用區環境可能更便宜，也更容易設計、實作及操作。區域環境的潛在工作量和成本較低，是因為您必須管理額外的負擔，才能協調不同區域的工作負載、資料和程序。

下表摘要說明各個部署原型架構的資源分布、可靠性屬性和複雜度。此外，本指南也說明根據各個模型設計及實作環境所需的工作。

部署原型名稱 資源分配 有助於抵抗 設計複雜度
可用區環境 單一區域 資源失敗 必須在單一可用區內協調
單一區域環境 單一區域內的多個可用區 資源故障、可用區中斷 必須在單一區域內的多個可用區之間進行協調
多區域環境 跨多個可用區、跨多個區域 資源故障、可用區中斷、區域中斷、多區域中斷 需要跨多個可用區和區域進行協調
全域環境 全球多個可用區和區域 資源故障、可用區中斷、區域中斷、多區域中斷 需要跨多個可用區和區域進行協調

如要進一步瞭解這些和其他部署原型，請參閱「Google Cloud 部署原型」。

為環境選擇部署原型

如要選擇最符合需求的部署原型，請執行下列操作：

  1. 定義要防範的失敗模型。
  2. 評估部署原型，判斷最符合您需求的項目。

定義故障模型

如要定義故障模型，請思考下列問題：

  • 環境中的哪些元件需要故障模型？故障模型可套用至您在Google Cloud上佈建或部署的任何項目。故障模型可套用至個別資源，也可以套用至整個可用區或區域中的所有資源。建議您將故障模型套用至任何能為您提供價值的項目，例如工作負載、資料、程序和任何 Google Cloud資源。
  • 這些元件的高可用性、業務持續性和災難復原需求為何？環境中的每個元件可能都有自己的服務水準目標 (SLO)，可定義該元件可接受的服務水準，以及自己的災難復原需求。舉例來說，Compute Engine 服務水準協議指出，如要達到每月 99.5% 以上的正常運作時間，您必須在單一區域的多個可用區中佈建執行個體。詳情請參閱「災難復原規劃指南」。
  • 需要定義多少個故障模型？在一般環境中，並非所有元件都必須提供相同的可靠性保證。如果提供更高的運作時間和更強大的復原能力保證，通常需要投入更多心力和資源。定義故障模型時，建議您為每個元件定義多個故障模型，而非為所有元件定義一個故障模型。舉例來說，重要業務工作負載通常需要提供更高的可靠性，但對於其他重要性較低的工作負載，或許可以接受較低的可靠性保證。
  • 故障模型需要多少資源才能防範故障？為了防範您定義的故障模型，您需要投入資源，例如人員設計、佈建及設定保護機制和自動化程序所需的時間和成本。建議您評估需要多少資源，才能防範定義的每個故障模型。
  • 如何偵測到故障？能夠偵測到發生或即將發生的故障至關重要，這樣您才能啟動緩解、復原和協調程序。舉例來說，您可以設定 Google Cloud Observability，在效能降低時發出快訊。
  • 如何測試您定義的故障模型？定義故障模型時，建議您思考如何持續測試每個模型，確認模型能有效防範其目標故障。舉例來說，您可以在環境中注入錯誤，或是採用混沌工程，評估環境的容錯能力。
  • 如果發生特定故障模式，您預期會造成多大的影響？ 為瞭解故障對業務的影響，建議您針對每個故障模型，估算模型設計防範的各項故障所造成的後果。瞭解這些資訊有助於確立優先順序和復原順序，讓您和您的程序優先處理最關鍵的元件。
  • 您預期定義的故障模型會持續多久？故障持續時間會大幅影響緩解和復原計畫。因此，定義故障模型時，建議您考量故障可能持續的時間。考量故障可能持續的時間時，也請考量找出故障、解決故障，以及還原故障資源所需的時間。

如要進一步瞭解故障模型，以及如何設計可靠的災難復原計畫，請參閱「為雲端基礎架構服務中斷建立災難復原架構」。

評估部署作業原型

定義要防範的故障模型後，請評估部署原型，判斷哪種最符合需求。評估部署原型時，請考量下列問題：

  • 需要多少部署原型？您不必只選擇一種部署原型，就能適用於所有環境。您可以改採混合式做法，根據所需的可靠性保證，選擇多種部署原型，防範您定義的故障模式。舉例來說，如果您定義了兩種故障模型，一種需要可用區環境，另一種需要區域環境，則可能需要選擇不同的部署原型，防範各種故障模型。如果選擇多種部署原型，建議您評估設計、實作及操作多個環境時，可能增加的複雜度。
  • 您需要多少資源，才能根據部署原型設計及實作環境？設計及實作任何環境都需要資源和心力。建議您評估需要多少資源，才能根據所選原型設計及實作各個環境。充分瞭解所需資源數量後，您就能權衡各部署架構提供的可靠性保證，以及根據這些架構設計、實作及運作環境的成本和複雜度。
  • 您是否打算將以某種部署原型為基礎的環境，遷移至以不同原型為基礎的環境？日後，您可能會將工作負載、資料和程序從一個Google Cloud 環境遷移到另一個 Google Cloud環境。例如，您可能會從可用區環境遷移至區域環境。
  • 您設計及實作的環境對業務有多重要？重要業務環境可能需要更多可靠性保證。舉例來說，您可以選擇為業務關鍵工作負載、資料和程序設計及實作多區域環境，並為較不重要的工作負載、資料和程序設計可用區或區域環境。
  • 您是否需要特定部署原型為某些環境提供的功能？除了每種部署原型提供的可靠性保證外，這些原型也提供不同的擴充性、地理鄰近性、延遲時間和資料位置保證。建議您在選擇環境的部署原型時，考量這些保證。

除了按照上述指引定義的故障模式技術層面，我們建議您也考慮任何非功能性需求，例如法規、地域和主權需求。這些規定可能會限制可用的選項。舉例來說，如果您需要遵守法規要求，強制使用特定區域，就必須設計及實作單一區域環境，或該區域的可用區環境。

選擇環境的 Google Cloud 區域

開始設計單一區域環境時，您必須決定最符合各環境需求的區域。以下各節將說明這兩類選取條件：

  • 功能條件。這些條件包括特定區域提供的產品，以及特定區域是否符合延遲時間和地理位置接近度等條件，以利使用者和其他外部環境Google Cloud Google Cloud。舉例來說，如果工作負載和資料對使用者或其他外部環境有延遲要求 Google Cloud，您可能需要選擇最靠近使用者或其他環境的區域，盡量減少延遲。
  • 非功能性條件。這些條件與特定地區的產品價格、碳足跡規定，以及貴商家必須遵守的強制性規定和法規有關。舉例來說，銀行和公共部門等高度監管的市場，對資料和工作負載的地域性，以及與其他客戶共用雲端服務供應商基礎架構的方式，都有非常嚴格且具體的要求。

如果您現在選擇特定 Google Cloud 區域，日後可以遷移至其他區域或多區域環境。如果您考慮日後遷移至其他區域，請參閱「跨區域遷移：開始使用 Google Cloud 」。

評估功能條件

如要評估功能條件，請思考下列問題：

  • 您對地理位置鄰近性有何要求？選擇 Google Cloud 區域時，您可能需要將工作負載、資料和程序，放在使用者或Google Cloud以外環境 (例如地端部署環境) 附近。舉例來說，如果目標使用者族群集中在特定地理區域，建議您選擇最接近該地理區域的 Google Cloud 區域。選擇最符合地理位置鄰近性需求的 Google Cloud 區域，可確保環境能縮短延遲時間，並縮短對使用者和 Google Cloud外部環境要求的反應時間。效能資訊主頁等工具可用於查看 Google Cloud 延遲時間，而Google Cloud 區域挑選器等非官方工具則可讓您大致瞭解Google Cloud 區域的延遲時間特性。不過，建議您進行全面評估，確認延遲時間屬性是否符合您的需求、工作負載、資料和程序。
  • 您想使用的區域中，有哪些提供您需要的產品？建議您評估各 Google Cloud 區域提供的產品，以及哪些區域提供您設計及實作環境所需的服務。如要進一步瞭解各區域提供的產品和推出時程，請參閱「Cloud 據點」。此外，部分產品可能無法在所有適用地區提供完整功能。舉例來說，Compute Engine 的可用區域和可用區會在特定Google Cloud 區域提供特定機型。如要進一步瞭解各項產品在各區域提供的功能，請參閱產品說明文件。
  • 每個 Google Cloud 區域的必要資源是否在區域配額限制內？ Google Cloud 會使用配額來限制您可使用的共用 Google Cloud 資源數量。有些配額是全域配額，適用於您在Google Cloud任何地方使用資源的情況，有些則是區域或可用區配額，適用於您在特定 Google Cloud 區域使用資源的情況。舉例來說，大多數 Compute Engine 資源用量配額 (例如可建立的虛擬機器數量) 都是區域性的。如要進一步瞭解配額和調整方式，請參閱 Cloud Quotas 說明文件。

評估非功能性條件

如要評估非功能性條件，請思考下列問題：

  • 您是否偏好低碳足跡？ Google Cloud持續投資永續發展，並為 Google Cloud 區域提供無碳能源，致力於為所有雲端區域提供無碳能源。Google Cloud 區域的碳足跡各不相同。如要瞭解各 Google Cloud 區域的碳足跡，以及如何在位置策略中納入無碳能源，請參閱「區域無碳能源 Google Cloud 」一文。
  • 您的環境是否需要符合特定法規？政府、國家和超國家實體通常會嚴格監管特定市場和業務領域，例如銀行和公部門。這些法規可能規定工作負載、資料和程序只能位於特定地理區域。舉例來說，您的環境可能需要遵守資料、作業和軟體主權要求，確保雲端中執行的敏感性資料和工作負載達到特定程度的控管和透明度。建議您在選擇環境Google Cloud 區域時，評估目前和未來的法規遵循要求，並選取最符合法規遵循要求的Google Cloud 區域。

設計及建構單一區域環境

如要設計單一區域環境，請執行下列步驟：

  1. 在 Google Cloud奠定基礎。
  2. 佈建及設定運算資源。
  3. 佈建及設定資料儲存資源。
  4. 佈建及設定資料分析資源。

設計環境時，請考量下列一般設計原則：

  • 佈建區域性資源。許多 Google Cloud 產品都支援在區域內的多個可用區佈建資源。建議您盡可能佈建區域資源，而非可用區資源。理論上，您可以在區域內的多個可用區佈建可用區資源，並自行管理這些資源，以提高可靠性。不過，這項設定無法充分發揮 Google 基礎架構的所有可靠性功能，而這些功能是 Google Cloud 服務的基礎。
  • 確認環境是否正常運作，並符合失敗模型假設。設計及實作單一區域環境時，建議您先確認這些環境是否符合相關需求，以防範您考慮的故障模型，再將這些環境升級為正式環境的一部分。舉例來說，您可以模擬區域中斷，確認單一區域環境能否在干擾極小的情況下繼續運作。

如要進一步瞭解設計可靠單一和多區域環境的一般設計原則，以及 Google 如何透過區域和多區域服務提高可靠性，請參閱「針對雲端基礎架構中斷情形設計災難復原架構：常見主題」。

奠定穩固基礎 Google Cloud

如要建構單一區域環境的基礎，請參閱「遷移至 Google Cloud：規劃及建構基礎」。該文件中的指南旨在為將工作負載、資料和程序遷移至 Google Cloud奠定基礎，但也適用於為單一區域環境奠定基礎。閱讀完該文件後，請繼續閱讀本文。

在 Google Cloud上建立基礎後，您會設計及實作安全控管機制和邊界。這些安全措施有助於確保工作負載、資料和程序都留在各自的區域內。此外，這些安全措施也有助於確保資源不會因錯誤、設定錯誤或惡意攻擊，而將任何內容洩漏至其他區域。

佈建及設定運算資源

單一區域環境的基礎建構完成後，您就可以佈建及設定運算資源。以下各節說明支援區域性部署的Google Cloud 運算產品。

Compute Engine

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

Compute Engine 資源可為可用區資源 (例如虛擬機器或可用區永久磁碟)、區域資源 (例如靜態外部 IP 位址) 或全域資源 (例如永久磁碟快照)。如要進一步瞭解 Compute Engine 支援的可用區、區域和全域資源，請參閱「全域、區域和可用區資源」。

為了提高實體資源的彈性和資源管理能力，Compute Engine 會將可用區與實體資源分離。如要進一步瞭解這個抽象概念及其可能對您造成的影響，請參閱「可用區和叢集」。

如要提高使用 Compute Engine 的環境可靠性，請考慮下列事項：

  • 區域代管執行個體群組 (MIG)。Compute Engine 虛擬機器是可用區資源，因此在可用區中斷時無法使用。為解決這個問題，Compute Engine 可讓您建立區域性 MIG，根據需求和區域可用性，自動在區域內的多個可用區中佈建虛擬機器。

    如果工作負載為有狀態，您也可以建立區域性有狀態 MIG，保留有狀態資料和設定。區域性 MIG 支援模擬可用區故障。如要瞭解如何在使用區域 MIG 時模擬可用區故障，請參閱「模擬區域 MIG 的可用區中斷情形」。如要瞭解區域性 MIG 與其他部署選項的比較，請參閱「根據工作負載選擇 Compute Engine 部署策略」。

  • 目標分配型態：區域性 MIG 會根據目標分配型態分配虛擬機器。為確保區域中任意兩個可用區的虛擬機器分配差異不超過一個單位，建議您在建立區域性 MIG 時選擇 EVEN 分配型態。如要瞭解目標分布形狀之間的差異，請參閱「形狀比較」。

  • 執行個體範本。如要定義要佈建的虛擬機器，MIG 會使用名為執行個體範本的全球資源類型。雖然執行個體範本是全域資源，但可能會參照可用區或區域資源。建立執行個體範本時，建議您盡可能參照區域性資源，而非可用區資源。如果您使用可用區資源，建議您評估使用這些資源的影響。舉例來說，如果您建立的執行個體範本參照的永久磁碟區僅適用於特定可用區，就無法在任何其他可用區使用該範本，因為永久磁碟區不適用於這些其他可用區。

  • 設定負載平衡和資源調度。Compute Engine 支援 Compute Engine 執行個體之間的負載平衡流量，並支援自動調度資源，可根據需求自動從 MIG 新增或移除虛擬機器。為提高環境的可靠性和彈性，並避免自行管理解決方案的管理負擔，建議您設定負載平衡和自動調度資源。如要進一步瞭解如何設定 Compute Engine 的負載平衡和資源調度功能，請參閱「負載平衡和資源調度」。

  • 設定資源預留項目。為確保環境在需要時有足夠的資源，建議您設定資源預留項目，確保能取得可用區 Compute Engine 資源的容量。舉例來說，如果可用區發生中斷，您可能需要在其他可用區中佈建虛擬機器，以提供必要的容量，補足因中斷而無法使用的機器。預留資源可確保您有足夠的資源來佈建額外的虛擬機器。

  • 使用區域性 DNS 名稱。為降低跨區域服務中斷的風險，建議您使用可用區 DNS 名稱，在環境中以不重複的方式識別使用 DNS 名稱的虛擬機器。 Google Cloud 預設會為 Compute Engine 虛擬機器使用可用區 DNS 名稱。如要進一步瞭解 Compute Engine 內部 DNS 的運作方式，請參閱「內部 DNS」。為方便日後跨區域遷移，並提高設定的可維護性，建議您將可用區 DNS 名稱視為設定參數，以便日後變更。

  • 選擇合適的儲存空間選項。Compute Engine 支援虛擬機器的多種儲存空間選項，例如 Persistent Disk 磁碟區和本機固態硬碟 (SSD)：

    • Persistent Disk 磁碟區分散於數個實體磁碟，且獨立於虛擬機器。永久磁碟可以是可用區或區域性資源。區域性永久磁碟會在單一可用區中儲存資料，而區域永久磁碟則會在兩個不同的可用區之間複製資料。為單一區域環境選擇儲存空間選項時，建議您選擇區域性永久磁碟，因為這類磁碟可在可用區故障時提供容錯移轉選項。如要進一步瞭解使用區域性永久磁碟時，如何因應可用區故障，請參閱「使用區域性永久磁碟的高可用性選項」和「區域性永久磁碟容錯移轉」。
    • 本機 SSD 的處理量很高，但只會儲存資料到執行個體停止或刪除為止。因此，本機 SSD 非常適合儲存臨時資料、快取，以及可透過其他方式重建的資料。永久磁碟是耐用的儲存裝置，可供虛擬機器存取，就像實體磁碟一樣。

  • 設計及實施資料保護機制。設計單一區域環境時，建議您採用自動化機制，在發生不利事件 (例如可用區、區域或多區域故障，或惡意第三方蓄意攻擊) 時保護資料。Compute Engine 提供多種資料保護選項。您可以將這些資料選項功能當做建構區塊，設計及實作資料保護程序。

GKE

GKE 可協助您在 Kubernetes 上部署、管理及擴充容器化工作負載。GKE 是以 Compute Engine 為基礎建構而成，因此上一節中關於 Compute Engine 的建議，部分也適用於 GKE。

如要提高使用 GKE 的環境可靠性，請考慮下列設計要點和 GKE 功能：

  • 使用區域性 GKE 叢集提高可用性。GKE 支援不同可用性類型的叢集，具體取決於您需要的叢集類型。GKE 叢集可以有可用區或區域控制層，節點則可在單一可用區或區域內的多個可用區中執行。不同叢集類型提供的服務水準協議 (SLA) 也不同。為提高環境的可靠性，建議您選擇區域叢集。

    如果您使用 GKE Autopilot 功能，只能佈建區域叢集。

  • 考慮使用多叢集環境。部署多個 GKE 叢集可提高環境的彈性和可用性，但也會增加複雜度。舉例來說，如果您需要使用新的 GKE 功能，但該功能只能在建立 GKE 叢集時啟用，則可將新的 GKE 叢集新增至多叢集環境、在新叢集中部署工作負載，並刪除舊叢集，藉此避免停機並降低遷移作業的複雜度。如要進一步瞭解多叢集 GKE 環境的優點，請參閱多叢集用途。為協助您管理複雜的遷移作業， Google Cloud提供機群管理功能，可管理一組 GKE 叢集、其基礎架構，以及部署在這些叢集中的工作負載。

  • 設定 GKE 備份。GKE 備份服務是區域服務，可備份來源 GKE 叢集中的工作負載設定和磁碟區，並還原至目標 GKE 叢集。為避免工作負載設定和資料遺失，建議您啟用並設定 GKE 備份。詳情請參閱「GKE 備份總覽」。

Cloud Run

Cloud Run 是代管運算平台，可執行容器化工作負載。Cloud Run 會使用服務，為您提供執行工作負載的基礎架構。Cloud Run 服務是區域資源，且服務會複製到所在區域的多個可用區。部署 Cloud Run 服務時，您可以選擇區域。接著，Cloud Run 會自動選擇該區域內的可用區，在其中部署服務執行個體。Cloud Run 會自動平衡服務執行個體之間的流量，大幅降低可用區中斷的影響。

VMware Engine

VMware Engine 是全代管服務，可讓您在 Google Cloud 中執行 VMware 平台。 Google Cloud如要提高使用 VMware Engine 的環境可靠性，建議採取下列做法：

  • 佈建多節點 VMware Engine 私有雲。VMware Engine 支援佈建稱為「私有雲」的獨立 VMware 堆疊，且構成私有雲的所有節點都位於同一區域。私有雲節點會在專屬、獨立的裸機硬體節點上運作，並經過設定，可消除單點故障。VMware Engine 支援單一節點私有雲，但我們建議僅將單一節點私有雲用於概念驗證和測試。如果是正式環境，建議使用預設的多節點私有雲。
  • 佈建 VMware Engine 延伸私有雲。延展的私有雲是多節點私有雲，節點分布在區域中的各個可用區。延展的私有雲可保護環境，避免區域性中斷。

如要進一步瞭解 VMware Engine 的高可用性和備援功能，請參閱「可用性和備援」。

佈建及設定資料儲存資源

為單一區域環境佈建及設定運算資源後，請佈建及設定資源，以便儲存及管理資料。以下各節說明支援區域和多區域設定的 Google Cloud 資料儲存和管理產品。

Cloud Storage

Cloud Storage 服務可將物件 (不可變更的資料片段) 儲存在值區 (保存資料的基本容器) 中。建立 bucket 時，請選取最符合可用性、法規和其他需求的bucket 位置類型。位置類型有不同的可用性保證。為保護資料不受故障和中斷影響，Cloud Storage 會在至少兩個可用區 (適用於位置類型為區域的 bucket)、兩個區域 (適用於位置類型為雙區域的 bucket) 或兩個以上區域 (適用於位置類型為多區域的 bucket) 備援資料。舉例來說，如果 Cloud Storage bucket 必須在可用區中斷時仍可使用，您可以使用區域位置類型佈建。

如要進一步瞭解如何為儲存在 Cloud Storage 中的資料設計災難機制，以及 Cloud Storage 如何因應可用區和區域性服務中斷，請參閱「為雲端基礎架構服務中斷設計災難復原機制：Cloud Storage」。

Filestore

Filestore 可在 Google Cloud 上提供全代管的檔案伺服器，並連線至 Compute Engine 執行個體、GKE 叢集和地端部署機器。Filestore 提供多種服務級別。每個層級都提供獨特的可用性、擴充性、效能、容量和資料復原功能。佈建 Filestore 執行個體時，建議您選擇企業級，因為該級別支援高可用性，以及區域內多個可用區的資料備援；其他級別的執行個體則屬於可用區資源。

Bigtable

Bigtable 是全代管、高效能且高擴充性的資料庫服務，適合處理大型分析和作業工作負載。Bigtable 執行個體是可用區資源。如要提高執行個體的可靠性，您可以設定 Bigtable，在同一區域內的多個可用區，或多個區域之間複製資料。

啟用複製功能後，如果發生服務中斷，Bigtable 會自動將要求容錯移轉至其他可用的執行個體，也就是您複製資料的執行個體。

如要進一步瞭解 Bigtable 的複製作業運作方式，請參閱「關於複製作業」和「為雲端基礎架構服務中斷建立災難復原架構：Bigtable」。

Firestore

Firestore 是 Firebase 和 Google Cloud提供的資料庫，具備彈性與擴充性，適用於行動裝置、網頁和伺服器開發。佈建 Firestore 資料庫時，您需要選取其位置。位置可以是多區域或區域，並提供不同的可靠性保證。如果資料庫位於區域位置，則會在區域內的不同可用區複製資料。多區域資料庫會在多個區域複製資料。

如要瞭解 Firestore 的複製作業運作方式，以及 Firestore 如何因應可用區和區域性服務中斷，請參閱「Firestore 位置」和「針對雲端基礎架構服務中斷設計災難復原架構：Firestore」。

Memorystore

您可以使用 Memorystore 設定可擴充、安全且可用性高的記憶體內資料儲存服務。支援 Redis、Memcached 和 Valkey 的資料後端。RedisValkey

佈建 Memorystore for Redis 執行個體時，請為該執行個體選取服務層級。Memorystore for Redis 支援多種執行個體服務級別，每個級別都提供獨特的可用性、節點大小和頻寬功能。佈建 Memorystore for Redis 執行個體時，建議您選擇標準級或含唯讀副本的標準級。這兩個級別的 Memorystore 執行個體會自動在區域內的多個可用區複製資料。

如要進一步瞭解 Memorystore for Redis 如何達到高可用性，請參閱「Memorystore for Redis 的高可用性」。

佈建 Memorystore for Memcached 執行個體時，請考量下列事項：

  • 選取可用區。佈建 Memorystore for Memcached 執行個體時，請選取要部署執行個體的區域。接著，您可以選取該區域中要部署該執行個體節點的可用區，也可以讓 Memorystore for Memcached 自動將節點分配到各個可用區。為盡可能妥善放置執行個體，並避免佈建問題 (例如將所有節點放在同一區域內)，建議您讓 Memorystore for Memcached 自動將節點分配到區域內的各個可用區。
  • 跨可用區的資料複寫。Memorystore for Memcached 執行個體不會跨可用區或區域複製資料。如要進一步瞭解 Memorystore for Memcached 執行個體在可用區或區域服務中斷時的運作方式，請參閱「針對雲端基礎架構服務中斷設計災難復原架構：Memorystore for Memcached」。

佈建 Memorystore for Valkey 執行個體時，您可以選擇可用性和可靠性選項。Memorystore for Valkey 支援多種設定，例如單一可用區和多個可用區執行個體。如要進一步瞭解 Memorystore for Valkey 的可用性和可靠性，請參閱「Memorystore for Valkey：高可用性和副本」。

Spanner

Spanner 是全代管關聯式資料庫，具備無限擴充、同步一致性及可用性高達 99.999% 等特色。如要使用 Spanner，請佈建 Spanner 執行個體。佈建 Spanner 執行個體時，請考量下列事項：

  • 執行個體設定。執行個體設定會定義 Spanner 執行個體中資料庫的地理位置和複製作業。建立 Spanner 執行個體時，您可以將其設定為單一區域或多區域。
  • 複製。Spanner 支援自動、位元組層級的複製，並可根據可用性、可靠性和擴充性需求建立副本。您可以跨區域和環境分配副本。採用區域設定的 Spanner 執行個體，會為區域內的每個可用區維護一個讀寫副本。多區域設定的執行個體會在多個區域的多個可用區中複製資料。
  • 移動執行個體。Spanner 可讓您移動執行個體，從任何執行個體設定移至其他執行個體設定，不會造成任何停機時間，也不會中斷移動期間的交易保證。

如要進一步瞭解 Spanner 複製功能，以及 Spanner 如何因應可用區和區域性服務中斷，請參閱「Spanner 複製功能」和「針對雲端基礎架構服務中斷設計災難復原架構：Spanner」。

佈建及設定資料分析資源

為單一區域環境佈建及設定資料儲存庫資源後，請佈建及設定資料分析資源。以下各節說明支援區域設定的 Google Cloud 資料分析產品。

BigQuery

BigQuery 是全代管企業資料倉儲，內建機器學習、地理空間分析和商業智慧等功能，有助於管理及分析資料。

如要整理及控管 BigQuery 中的資料存取權，請佈建名為「資料集」的頂層容器。佈建 BigQuery 資料集時，請注意下列事項：

  • 資料集位置。如要選取要儲存資料的 BigQuery 位置，請設定資料集位置。位置可以是區域或多區域。無論是哪種位置類型，BigQuery 都會在所選位置的兩個不同可用區中儲存資料副本。資料集建立後即無法變更位置。
  • 災難規劃。BigQuery 是區域服務，可自動處理區域性故障，包括運算和資料。不過，您必須自行規劃某些情境，例如區域性服務中斷。建議您在設計環境時，將這些情境納入考量。

如要進一步瞭解 BigQuery 災難復原計畫和功能，請參閱 BigQuery 說明文件中的「瞭解可靠性：擬定災難復原計畫」，以及「為雲端基礎架構中斷情形設計災難復原架構：BigQuery」。

Managed Service for Apache Spark

Managed Service for Apache Spark 是一項代管服務，可讓您運用開放原始碼資料工具，執行批次處理、查詢、串流和機器學習工作。Managed Service for Apache Spark 建構於 Compute Engine 之上，因此上一節關於 Compute Engine 的建議，部分也適用於 Managed Service for Apache Spark。

如要使用 Managed Service for Apache Spark，請建立 Managed Service for Apache Spark 叢集。Managed Service for Apache Spark 叢集是可用區資源。建立 Managed Service for Apache Spark 叢集時，請注意下列事項：

  • 自動選擇可用區位置。建立叢集時，您可以指定要在區域中的哪個可用區佈建叢集節點，或讓 Managed Service for Apache Spark 自動選擇可用區位置。除非需要微調區域內叢集節點的可用區位置，否則建議使用自動選擇可用區位置。
  • 高可用性模式。建立叢集時，您可以啟用高可用性模式。叢集建立後，就無法啟用高可用性模式。如果叢集需要具備復原能力，能因應單一協調器節點故障或部分可用區中斷的情況，建議您啟用高可用性模式。高可用性 Managed Service for Apache Spark 叢集是區域資源。

如要進一步瞭解 Managed Service for Apache Spark 如何因應可用區和區域性中斷，以及如何在發生故障時提高 Managed Service for Apache Spark 叢集的可靠性，請參閱「針對雲端基礎架構中斷情形設計災難復原架構：Managed Service for Apache Spark」。

Dataflow

Dataflow 是全代管服務，可用於執行串流和批次資料處理管道。如要使用 Dataflow，請建立 Dataflow 管道，然後 Dataflow 會在 worker 節點上執行工作，也就是這些管道的執行個體。由於工作是可用區資源，因此使用 Dataflow 資源時，請考量下列事項：

  • 區域端點。建立工作時，Dataflow 會要求您設定區域端點。為工作設定區域端點，即可將運算和資料資源限制在特定區域。
  • 區域刊登位置。Dataflow 會根據工作類型，自動將 worker 節點分配至區域內的所有可用區，或區域內最合適的可用區。Dataflow 可讓您將區域內的所有 worker 節點放在同一個可用區，藉此覆寫 worker 節點的可用區位置。為減輕可用區中斷造成的影響，除非您需要將 worker 節點放在特定可用區，否則建議讓 Dataflow 自動選取最佳可用區。

如要進一步瞭解 Managed Service for Apache Spark 如何因應可用區和區域性中斷，以及如何在發生故障時提高 Managed Service for Apache Spark 叢集的可靠性，請參閱「為雲端基礎架構中斷設計災難復原架構：Dataflow」。

Pub/Sub

Pub/Sub 是可擴充的非同步訊息服務，會分離產生訊息的服務與處理訊息的服務。Pub/Sub 會依主題整理訊息。發布者 (產生訊息的服務) 會將訊息傳送至主題，訂閱者則會從主題接收訊息。Pub/Sub 會將每則訊息儲存在單一區域，並在該區域內至少兩個可用區複製訊息。詳情請參閱「Pub/Sub 架構總覽」。

設定 Pub/Sub 環境時，請考量下列事項：

  • 全域和區域端點。Pub/Sub 支援全域和區域端點，可用於發布訊息。發布者將訊息傳送至全球端點時，Pub/Sub 會自動選取最靠近的區域來處理該訊息。生產者將訊息傳送至區域端點時，Pub/Sub 會在該區域處理訊息。
  • 訊息儲存政策。Pub/Sub 可讓您設定訊息儲存政策，限制 Pub/Sub 處理及儲存訊息的位置，無論要求來源和發布者用於發布訊息的端點為何。建議您設定訊息儲存政策，確保訊息不會離開單一區域環境。

如要進一步瞭解 Pub/Sub 如何處理可用區和區域性中斷，請參閱「為雲端基礎架構中斷建構災難復原架構：Pub/Sub」。

調整工作負載，以適應單一區域環境

完成環境佈建和設定後，您需要考量如何提高工作負載的彈性，以因應可用區和區域故障。每個工作負載都有自己的可用性和可靠性要求與屬性，但您可以套用一些設計原則，並採用相關策略，在不太可能發生的區域和區域性故障事件中，提升整體復原能力。設計及實作工作負載時，請考量下列事項：

  • 導入網站可靠性工程 (SRE) 做法和原則。自動化和廣泛監控是 SRE 的核心原則之一。Google Cloud 提供相關工具和專業服務，協助您導入 SRE，提升環境的韌性和可靠性，並減少手動作業。
  • 設計時考慮擴充性和韌性。設計雲端環境的工作負載時，建議您將擴充性和韌性視為工作負載必須遵守的固有需求。如要進一步瞭解這類設計，請參閱「可擴充且彈性的應用程式模式」。
  • 設計雲端基礎架構服務中斷的復原機制。 Google Cloud 可用性保證由Google Cloud 服務水準協議定義。 萬一發生可用區或區域故障，建議您設計工作負載，確保工作負載能因應可用區和區域故障。
  • 實作負載卸除和優雅降級。 如果雲端基礎架構或其他工作負載依附元件發生故障，建議您設計具有彈性的工作負載。即使發生故障，工作負載仍應維持特定且明確定義的功能等級 (優雅降級)，且在接近超載狀態時，應能降低部分負載 (卸載)。
  • 規劃定期維護作業。設計部署程序和作業程序時，建議您一併考量環境定期維護作業的所有活動。定期維護應包含對工作負載及其依附元件套用更新和設定變更等活動，以及這些活動可能對環境可用性造成的影響。舉例來說，您可以為 Compute Engine 執行個體設定主機維護政策。
  • 採用測試推動開發方法。設計工作負載時，建議您採用測試導向開發方法，確保工作負載在各方面都能正常運作。舉例來說，您可以測試工作負載和雲端基礎架構是否符合您要求的功能、非功能和安全性需求。

後續步驟

貢獻者

作者：Marco Ferrari | 雲端解決方案架構師

其他貢獻者：