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

本文可協助您在Google Cloud上設計具備復原能力的單一區域環境。如果您打算遷移單一區域環境，或是正在評估日後遷移的可能性，並想瞭解遷移的預期情況，本文件都能提供實用的參考資料。

本文件是系列文章之一：

• 開始使用
• 在 Google Cloud 上建構單一區域環境(本文件)
• 設計工作負載架構
• 準備要跨區域遷移的資料和批次工作負載

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

• 網路服務，例如 Cloud Load Balancing。
• 運算服務，例如 Compute Engine、 Google Kubernetes Engine (GKE)、 Google Cloud VMware Engine， 以及 Cloud Run。
• 資料儲存服務，例如 Cloud Storage、 Filestore、 Bigtable、 Firestore、 Memorystore， 以及 Spanner。
• 資料分析服務，例如 BigQuery、 Pub/Sub、 Dataproc、 和 Dataflow。
• 您在環境中部署的工作負載。

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

不同部署原型的屬性

Google Cloud 產品涵蓋許多區域和可用區。

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

• 可用區：在區域內的單一可用區中佈建 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 延遲時間資訊主頁、GCPing 和Google Cloud 區域挑選工具等工具，可讓您大致瞭解Google Cloud 區域的延遲時間特性。不過，我們建議您進行全面評估，判斷延遲時間屬性是否符合您的需求、工作負載、資料和程序。
• 您想使用的區域中，有哪些提供您需要的產品？建議您評估各 Google Cloud 區域提供的產品，以及哪些區域提供您設計及實作環境所需的服務。如要進一步瞭解各區域提供的產品，以及產品的推出時間表，請參閱「Cloud 據點」。此外，部分產品可能無法在所有適用地區提供完整功能。舉例來說，Compute Engine 的可用地區和區域會在特定Google Cloud 地區提供特定機型。如要進一步瞭解各項產品在各個區域提供的功能，請參閱產品說明文件。
• 每個 Google Cloud 區域的資源是否符合區域配額限制？ Google Cloud 會使用配額來限制您可使用的共用 Google Cloud 資源數量。部分配額為全域配額，適用於您在Google Cloud中任何位置使用資源的情況，其他配額則為區域或可用區配額，適用於您在特定 Google Cloud 區域使用資源的情況。舉例來說，大多數的Compute Engine 資源用量配額 (例如可建立的虛擬機器數量) 都是區域配額。如要進一步瞭解配額及如何提高配額，請參閱「處理配額」。

評估非功能性條件

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

• 您是否偏好低碳足跡？ 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 如何透過區域和多區域服務提升可靠性，請參閱「Architecting disaster recovery for cloud infrastructure outages: Common themes」(為雲端基礎架構中斷事件設計災難復原機制：常見主題)。

在 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 備份。詳情請參閱「Backup for GKE 總覽」。

Cloud Run

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

VMware Engine

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

• 佈建多節點 VMware Engine 私有雲。 VMware Engine 支援佈建稱為私有雲的獨立 VMware 堆疊，且構成私有雲的所有節點都位於同一區域。私有雲節點會在專屬的獨立裸機硬體節點上執行，並經過設定，可避免單點故障。VMware Engine 支援單一節點私有雲，但我們建議僅將單一節點私有雲用於概念驗證和測試。在實際工作環境中，建議您使用預設的多節點私有雲。
• 佈建 VMware Engine 延展式私人雲端。延展私有雲是多節點私有雲，節點分布在區域中的可用區。延展型私有雲可保護您的環境，避免區域性中斷。

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

佈建及設定資料儲存資源

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

Cloud Storage

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

如要進一步瞭解如何為儲存在 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 的資料後端。

佈建 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」。

Dataproc

Dataproc 是一項代管服務，可讓您妥善運用開放原始碼資料工具，進行批次處理、查詢、串流及機器學習作業。Dataproc 是以 Compute Engine 為基礎建構而成，因此上一節中關於 Compute Engine 的建議，也部分適用於 Dataproc。

如要使用 Dataproc，請建立 Dataproc 叢集。Dataproc 叢集是區域資源。建立 Dataproc 叢集時，請注意下列事項：

• 自動放置區域。建立叢集時，您可以指定要在地區內的哪個區域佈建叢集節點，也可以讓 Dataproc 自動選擇區域位置自動選取區域。除非您需要微調區域內叢集節點的區域位置，否則建議使用自動選擇區域位置。
• 高可用性模式。建立叢集時，您可以啟用高可用性模式。叢集建立後，就無法啟用高可用性模式。如果需要叢集在單一協調器節點故障或部分區域中斷時保持運作，建議啟用高可用性模式。高可用性 Dataproc 叢集是區域資源。

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

Dataflow

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

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

如要進一步瞭解 Dataproc 如何因應區域和地區中斷情形，以及如何在發生故障時提高 Dataproc 叢集的可靠性，請參閱「為雲端基礎架構中斷情形設計災難復原機制：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 執行個體設定主機維護政策。
• 採用測試驅動開發方法。設計工作負載時，建議採用以測試為依據的開發方法，確保工作負載從各個角度來看都能正常運作。舉例來說，您可以測試工作負載和雲端基礎架構是否符合您要求的功能、非功能和安全性需求。

後續步驟

• 瞭解如何設計可擴充且有彈性的應用程式。
• 請參閱Google Cloud 基礎架構可靠性。
• 如要提升環境的可靠性和復原能力，請參閱網站可靠性工程 (SRE) 相關資訊。
• 瞭解如何設計雲端基礎架構中斷的災難復原機制。
• 如要瞭解遷移架構，請參閱「遷移至 Google Cloud：開始使用」。
• 瞭解何時應尋求遷移作業的相關協助。
• 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。

貢獻者

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

其他貢獻者：

• Henry Bell | 雲端解決方案架構師
• Elliot Eaton | 雲端解決方案架構師
• Grace Mollison | 解決方案主管
• Ido Flatow | 雲端解決方案架構師