地理位置與區域

Google Cloud 產品是從特定區域的故障網域提供服務，並完全符合服務水準協議的規定，確保您在 Google Cloud架構內設計應用程式架構。

Google Cloud 基礎架構服務據點遍布北美洲、南美洲、歐洲、亞洲、中東和澳洲各地。這些位置分為「地區」和「區域」。您可以選擇應用程式的部署位置，以符合延遲時間、可用性和耐用性方面的需求。

歡迎試用

如果您未曾使用過 Google Cloud，歡迎建立帳戶來評估我們的產品在實際工作環境中的成效。新客戶還能獲得價值 $300 美元的免費抵免額，可用於執行、測試及部署工作負載。

免費試用

地區與區域

「地區」是獨立的地理區域，由各「區域」組成。可用區和區域是基礎實體資源的邏輯抽象概念。區域由三個以上的可用區組成，這些可用區位於三個以上的實體資料中心。斯德哥爾摩、墨西哥、大阪和蒙特婁區域有三個可用區，分別位於一或兩個實體資料中心。這些區域正在擴展，達到至少三個實體資料中心。在Google Cloud中設計解決方案架構時，請參考「雲端位置」、「Google Cloud 平台服務等級協議」和適當的Google Cloud 產品說明文件。

這些資料中心可能由 Google 擁有，並列於Google Cloud 位置資訊頁面，也可能向第三方資料中心供應商租用。如要查看 Google Cloud的完整資料中心位置清單，請參閱我們的 ISO/IEC 27001 認證。無論資料中心是自有或租用， Google Cloud 都會選擇資料中心並設計基礎架構，確保效能、安全性及可靠性達到一致水準。

「區域」是地區內 Google Cloud 資源的部署區域。您應將區域視為地區內的單一故障網域。如要部署具有高可用性的容錯應用程式，並預防應用程式發生非預期失敗的情形，請將應用程式部署到地區內的多個區域。

如要避免因天災導致整個地區都無法使用應用程式，請建立一套災難復原計畫，並瞭解如何在主要地區發生服務中斷的罕見情況下提供應用程式服務。詳情請參閱應用程式部署作業注意事項。

如要進一步瞭解可在每個位置選項內使用的特定資源，請參閱我們的雲端服務據點。

Google Cloud的服務與資源可以是區域性、地區性，或是由 Google 跨多個地區代管。如要進一步瞭解這些選項對您的資料而言有何意義，請參閱資料的地理區域管理一文。

Google Cloud 打算在每個一般用途區域中，至少提供三個可用區 (實體和邏輯上不同的區域)。

相關位置文件

區域資源

區域資源在單一區域中運作。可用區中斷可能會影響該可用區的部分或所有資源。位於特定區域中的 Compute Engine 虛擬機器 (VM) 執行個體就屬於這樣的區域資源。

地區資源

地區資源是跨某地區內多個區域進行備援部署的資源，例如 App Engine 應用程式或地區代管執行個體群組。 因此相較於可用區資源，區域資源的可用性更高。

多區域資源

Google 會管理多項 Google Cloud 服務，確保服務在地區內及跨地區達到備援的目的並進行發布。這些服務可最佳化可用性、效能與資源效率，因此需要在延遲時間或一致性模型方面有所妥協，我們會根據具體產品說明這些妥協內容。

下列服務除了任何地區性位置以外，還擁有一或多個多地區位置：

  • Artifact Registry
  • Bigtable
  • Sensitive Data Protection
  • Cloud Healthcare API
  • Cloud KMS
  • Container Registry
  • Spanner
  • Cloud Storage
  • 資料庫移轉服務
  • Datastore
  • Firestore

這些多區域服務的設計宗旨，是在單一區域發生故障時仍能正常運作。

詳情請參閱「各個地區適用的產品」和各項產品的說明文件。

全球服務

Google Cloud 從一開始就以全球營運為目標設計，並持續進行維護和升級，全年無休，不會造成您的不便。我們的全球骨幹網路提供極大的負載平衡彈性，並透過靠近您的互連點，減少使用者延遲。我們的全球雲端管理層可簡化多區域開發作業的管理。

內部服務

許多面向消費者的 Google Cloud 服務 都以一組經過驗證的內部服務為基礎，例如 Spanner、Colossus、Borg 和 Chubby。

這些內部服務會跨多個區域進行全域負載平衡，或專用於服務所在的每個區域。如果服務的負載平衡橫跨多個區域，我們會逐一更新各個區域，以便在不影響服務使用的情況下偵測及解決問題。這些內部服務都不會限制在單一邏輯資料中心或單一區域。

全球內部服務可在下列雲端區域中執行或複製：

美洲

  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-west1
  • us-west4

歐洲

  • europe-north1
  • europe-west1
  • europe-west4

亞洲

  • asia-east1
  • asia-southeast1

服務依附元件

一般來說，如果單一區域發生故障，只有位於該區域的客戶會受到影響；如果客戶使用多區域產品，則不會受到影響。 Google Cloud 已建立完善的架構，目標是防止區域間發生相關故障。 Google Cloud

所有 Google Cloud 服務都依賴核心內部工具提供基本服務，例如網路 (資料中心內外)、資料中心存取權和身分授權系統。這些工具可因應區域性中斷，目標是確保一個區域無法使用時，其他區域不會受到影響。

Google Cloud 在公開網站上，針對客戶如何建構應用程式，以達到所需的復原能力等級，提供明確的指引，特別是針對 Compute Engine、BigQuery、Pub/Sub 等常用 Google Cloud 產品和其他服務。

以下列出主要依附元件，首先是所有服務共用的依附元件，但請注意，低層級的實作細節可能會變更。

所有服務的常見依附元件

  • 用於驗證和授權的身分資料平面
  • 提供記錄、中繼資料儲存空間和工作流程管理功能的內部服務
  • API 存取權取決於 DNS、全球分散式負載平衡器和服務點 (PoP)。 Google Cloud
  • 全域資源的設定：舉例來說，IAM 政策、全域防火牆規則、全域負載平衡器設定和 Pub/Sub 主題會儲存在複製的資料庫中。
  • 當 Google Cloud 服務向客戶控管的端點提出要求時 (例如 Cloud EKM 擷取客戶金鑰，或 Pub/Sub 傳送訊息)，這些要求會透過我們的全球網路基礎架構存取客戶控管的端點。

具有其他依附元件的服務

  • Compute Engine 服務
    • Google Cloud VM 和永久磁碟資料平面依附於較低層級的 Compute Engine 和 Cloud Storage 服務，例如 Borg 和 Colossus。
  • Google Cloud 和 Spanner、Bigtable 和 Cloud Storage 等基礎架構儲存服務取決於：
    • 客戶的加密和金鑰管理基礎架構 (Cloud KMS / Cloud EKM)，以及 Google 自有金鑰的內部基礎架構
    • 提供資料存取記錄和稽核的內部服務
    • 內部資料複寫服務，資料應可在多個區域使用
    • 明確設定備份和複製到其他區域的作業，取決於跨區域網路
  • 訊息服務
    • Pub/Sub 服務需要透過全球網路基礎架構，才能存取客戶控管的端點
  • 網路服務
    • 全球負載平衡、DNS 和區域間的容錯移轉，全都取決於實體網路基礎架構。
    • 防範分散式阻斷服務攻擊等行為，取決於較低層級的 Compute Engine 基礎架構。
  • GKE 和 Cloud SQL 等代管及託管服務
    • 依賴 Compute Engine 和 Container Registry 或 Artifact Registry (VM 映像檔)。
  • 自給自足的低階基礎架構
    • 我們的內部叢集層級控制層，包括 Borg 和網路結構
    • 叢集層級儲存空間，例如 Colossus
    • 加密和金鑰管理基礎架構

維持及提升可用性和復原能力

網站可靠性工程 (SRE) 是 Google 內部專責機構，致力於提升可用性、縮短延遲時間、改善效能及承載力。中斷和服務無法使用的情況，與新程式碼的部署或環境變更有關。SRE 會採用業界最佳做法，在瞭解必要變更可能會導致停機的情況下，兼顧發布新軟體的需求，並確保環境安全。

與客戶合作建構彈性服務

如果您有業務關鍵需求，需要建構彈性和災害復原架構，我們的 SRE/CRE 和 PSO 團隊可與您合作，建構應用程式來橋接多個區域和可用區，並進一步協助您設計高可用性 (HA) 系統。

如果您在特定日期 (例如黑色星期五和網購星期一) 有更高的可用性需求， Google Cloud 設有合作夥伴計畫，可協助您檢查及驗證在Google Cloud 上執行的特定應用程式，並找出應用程式與 Google 服務之間任何非預期的服務依附元件。

服務據點 (POP)

Google 經營全球網路連結點，因此客戶流量可以在 Google 網路中傳輸，直到接近目的地為止，為使用者提供更優質的體驗和安全性。詳情請參閱網路邊緣位置。

資料的地理區域管理

Google Cloud 服務的資料在地性必須遵守服務條款 (含服務專屬條款)。Google 瞭解每位客戶都可能擁有獨特的安全性與法規遵循需求。Google Cloud 銷售團隊可協助您滿足需求。

使用地區或區域儲存資源時，強烈建議您將資料複製到其他地區，或以快照形式將資料記錄到多地區儲存資源，做為災難復原之用。

應用程式部署作業注意事項

如要建構可承受區域服務中斷的高可用服務與應用程式

使用下列設定：

如要建構可承受整個地區服務中斷的損失，從災難復原的應用程式

針對資料，執行下列一或多個策略：

  • 使用多區域代管儲存服務，例如 Cloud Storage、Datastore、Firestore 或 Spanner。
  • 使用區域或地區資源，但以快照形式將資料儲存到 Cloud Storage、Datastore、Firestore 或 Spanner 等多區域資源。
  • 使用區域或地區資源，但管理您自己的資料，將資料複製到一或多個其他地區。

針對運算，使用下列策略：

  • 使用區域或地區資源 (例如 Compute Engine 或 App Engine)，但如果您的主要資料尚未處於代管的多地區資源中，則在參照該資料複本的其他地區 (發生地區失敗時) 手動或自動提供應用程式服務。

如要進一步瞭解服務的依附元件，請與銷售人員聯絡。

其他解決方案與教學課程

下列解決方案與教學課程提供指引，確保您的應用程式具有高可用性，且可承受服務中斷的影響：

可擴充及具有彈性的應用程式模式

瞭解如何使用 Google Cloud ，運用廣泛適用於任何網路應用程式的模式和做法，打造可擴充且有彈性的應用程式架構。

建立 HTTPS 負載平衡器

在不同地區設定 Compute Engine 執行個體，然後使用 HTTP 負載平衡功能跨地區分散流量，以提高各地區的可用性並在服務中斷時進行容錯移轉。

設計完善可靠的系統

在 Compute Engine 服務上設計應用程式時，請考慮足以防範失敗、網路中斷和非預期災難等各種問題的方案。

使用 Cloud Storage 進行 Cassandra 備份與還原

瞭解如何藉由將資料備份到 Cloud Storage 以及從 Cloud Storage 復原資料，為 Cassandra 安裝加入基本災難復原能力。

災難復原規劃指南

使用 Google Cloud設計及測試災難復原計畫的一般原則。