選擇 Compute Engine 地區的最佳做法

本文說明應依據哪些準則，來選擇執行 Compute Engine 資源的 Google Cloud區域，通常這由雲端架構師或工程管理部門來決定。本文的重點放在選擇過程中的延遲方面，雖然主要是針對消費者所存取的應用程式，例如行動或網路應用程式或遊戲，但其中許多概念也適用其他用途。

Google 提供位於世界各地的許多地區，可用來部署您的 Compute Engine 資源。有幾個因素會影響您的地區選擇：

  • 地區特有的限制
  • 各地區的使用者延遲時間
  • 應用程式的延遲要求
  • 對延遲時間的控制程度
  • 低延遲與簡易性之間的平衡

術語

地區
執行資源所在的獨立地理區域。每個地區都是由區域所組成，通常至少三個區域。
可用區
地區內 Google Cloud 資源的部署範圍。將資源放在地區中的不同區域可降低基礎架構中斷同時影響所有資源的風險。
Compute Engine 資源
Compute Engine 資源 (例如虛擬機器執行個體) 會部署於地區的區域中。其他產品如 Google Kubernetes Engine 和 Dataflow 等，會使用 Compute Engine 資源，所以可以部署在同一地區或區域中。
封包往返時間 (RTT)
傳送 IP 封包後收到確認所需的時間。

選擇 Compute Engine 區域的時機

在應用程式的架構階段早期，應決定要使用多少及哪些 Compute Engine 地區。您所做的選擇可能會影響到應用程式，例如：

  • 如果在複本之間同步資料，應用程式的架構可能會改變，因為相同的使用者可在不同時間透過不同地區進行連線。
  • 價格會因地區而異。
  • 在地區之間搬移應用程式及其資料的過程很麻煩，有時會因此付出高昂成本，所以應用程式正式上線後，應避免執行這樣的作業。

選擇地區時應考量的因素

選擇部署於使用者所在地區是常見方式，不過這種方式沒有顧及最佳使用者體驗。假設您位於歐洲，在全球各地都有使用者，想要部署在單一地區。多數人會考量部署在歐洲的一個地區，但在美國其中一個地區託管這個應用程式往往是最佳選擇，因為美國最容易連線到其他地區。

有多個因素會影響您對應用程式部署位置的決定。

延遲時間

最主要的考量因素是使用者經歷的延遲。但這個問題很複雜，因為使用者延遲時間受到多種層面的影響，例如快取及負載平衡機制。

在企業應用案例中，連線到內部部署系統的延遲時間，或特定使用者子集或合作夥伴子集的延遲時間會更重要。例如，選擇最接近開發人員的地區，或最接近Google Cloud 互連內部部署資料庫服務的地區，可能會是關鍵決定因素。

定價

Google Cloud 資源費用會因地區而異，以下資源可用於預估費用：

如果您決定部署在多個地區，請注意地區間的資料同步作業將會產生資料移轉費用。

與其他 Google Cloud 服務並置於相同位置

請盡可能將 Compute Engine 資源與其他 Google Cloud服務並置於相同位置。雖然大多數易受延遲時間影響的服務都可以在每個地區中使用，但有些服務只能在特定地點使用。

機器類型可用性

並非所有 CPU 平台和機器類型都可以在每一個地區中使用，特定 CPU 平台或特定執行個體類型的供應情形會因地區、甚至因區域而異。如果您想部署使用特定機器類型的資源，請瞭解這些資源的區域供應情形。

資源配額

能否部署 Compute Engine 資源，受限於地區資源配額，因此請務必針對打算部署的地區申請足夠的配額。如果您打算進行特別龐大的部署作業，請盡早與銷售團隊合作商討地區選擇，以確保有充裕的配額容量可用。

無碳能源百分比

為了為各 Google Cloud 區域供電，Google 會使用該區域所在電網的電力。這類電力產生的碳排放量多寡，取決於為該電網發電的發電廠類型，以及 Google 使用電力時機。Google 最近設定了目標，在 2030 年前，我們將在所有區域 24 小時全天候提供無碳電力，以便在您需要的時間和地點為應用程式供電。 Google Cloud

在達成這個目標之前，每個 Google Cloud 區域都會採用混合型能源，即每小時使用部分碳基和無碳能源。我們稱這項指標為無碳能源百分比 (CFE%)，並發布各區域的 CFE%。 Google Cloud 對於 Google Cloud上的新應用程式，您可以使用這份表格，開始將碳足跡納入架構決策。選擇 CFE % 較高的區域，代表應用程式在運作時，有較高的比例會使用無碳能源，進而減少該應用程式的總碳排放量。

評估延遲要求

延遲時間經常是地區選擇的關鍵考量因素，因為使用者延遲時間越長，使用者體驗便會越差。您可以調整延遲時間的某些層面，但有些層面是您無法控管的。

很多系統架構師在最佳化延遲時，只想到網路延遲或使用者 ISP 與虛擬機器執行個體之間的距離，但這只是眾多影響使用者延遲時間的其中一個因素，您可以參考下圖。

選擇 Compute Engine 地區時評估延遲時間

身為應用程式架構師，您可以最佳化地區選擇和應用程式延遲時間，但無法控制使用者最後一哩路的傳輸，以及連接最近 Google 邊緣服務點 (POP) 的延遲時間。

地區選擇只對連至 Compute Engine 地區的延遲時間有影響，並不影響整體延遲。視用途而定，這可能只佔整體延遲的一小部分而已。例如，如果使用者大多使用行動網路，則設法最佳化地區可能毫無價值，因為這對整個使用者延遲時間幾乎沒有影響。

最後一哩路的網路延遲

這一段的延遲會根據存取網際網路所用的技術而有所不同。舉例來說，在現代網路上，連線到 ISP 的延遲時間通常為 1 至 10 毫秒。反之，使用 3G 行動網路的一般延遲時間為 100 至 500 毫秒。DSL 和有線供應商的延遲時間範圍約為 10 至 60 毫秒。

Google 前端和邊緣 POP 延遲時間

視您的部署模式而定，連接 Google 網路邊緣的延遲時間也很重要。全球負載平衡產品會在這個位置終止 TCP 和 SSL 工作階段，而 Cloud CDN 則從這個位置提供快取結果。根據提供的內容，許多封包往返可能已在此結束，這是因為需要全程擷取的資料只有一小部分。如果您使用標準網路服務級別，延遲時間可能會大幅提高。

Compute Engine 地區延遲時間

使用者要求會在邊緣 POP 進入 Google 的網路。位於 Compute Engine 地區的 Google Cloud 資源會處理要求。這一段就是邊緣 POP 和 Compute Engine 地區之間的延遲時間，全程都在 Google 的全球網路內進行。

應用程式延遲時間

這是指應用程式回應要求所經過的時間，其中包括應用程式處理要求所需的時間。

應用程式不同，延遲要求也不一樣。視應用程式而定，有些使用者對延遲問題並不那麼挑剔。非同步互動的應用程式，或具有高延遲門檻 (100 毫秒或以上) 的行動應用程式，可以部署在單一地區，而不會對使用者體驗造成負面影響。不過，對於即時遊戲之類的應用程式，幾毫秒的延遲也可能對使用者體驗造成很大的負面影響。建議您將這幾類的應用程式部署在接近使用者的多個地區。

全球部署模式

本節說明各種不同的部署模式對延遲因素有何影響。

單一地區部署

下圖說明單一地區部署。

單一前端部署的延遲時間

即使您的應用程式服務全世界的使用者，在許多使用案例中，單一地區仍是最佳選擇。延遲較短的優點，可能不會比多地區部署的複雜度增加更重要。即使採用單一地區部署，您還是可以使用最佳化技術如 Cloud CDN 和全球負載平衡來縮短使用者延遲時間。您可以選擇使用第二個地區作為備份和災難復原之用，但不影響到應用程式的服務路徑，也不因而影響使用者延遲時間。

在多個地區分散配置前端，並在單一地區配置後端

下圖顯示在多個地區分散配置前端，但將後端限制在單一地區的部署模式。這個模式可縮短連接前端伺服器的延遲時間，同時不用在多個地區中同步資料。

分散式前端部署的延遲時間

在一般使用者要求不涉及任何資料要求，或只涉及少數資料要求的情況下，這個部署模式可在應用程式產生結果之前，提供低使用者延遲時間。舉例來說，應用程式會在前端部署智慧快取層，或非同步處理資料寫入作業。如果應用程式提出許多需要完整後端往返的請求，可能就無法從這個模型中受益。

在多個地區分散配置前端與後端

在多個地區分散配置前端和後端的部署模式，可將使用者延遲時間縮至最短，因為應用程式可在本機充分回應所有要求。但是這種模式會使複雜度增加，因為所有資料都必須在本機儲存和存取。為了回應所有的使用者要求，必須在所有地區中完全複製資料。

分散式多重部署的延遲時間

Spanner (即全球一致的代管資料庫服務) 的三大洲、多地區選項，可在美國提供讀取/寫入備用資源，並在歐洲和亞洲提供兩個讀取備用資源。這個選項為美國、歐洲和亞洲的運算執行個體，提供低延遲的讀取存取。如果您的服務以美國為目標，則有搭配在美國複製的多地區選項。

如果您決定在 Compute Engine 執行自己的資料庫服務，請自行複製資料。複製很重要，因為要保持資料在全球一致同步是件困難的工作。如果只在一個地區藉由非同步寫入作業來寫入資料庫，而其他地區則託管唯讀資料庫備用資源，則管理可能會容易些。

跨地區複製資料庫非常困難，我們建議您跟有這方面經驗的強大合作夥伴合作，如適合 Cassandra 複製的 Datastax。

多個平行應用程式

您可以根據應用程式的性質，調整一下前述的方法，在確保使用者低延遲的同時，降低經常複製資料的必要性。如下圖所示，多個平行應用程式都由一個前端和後端所組成，而使用者會被導向到適當的應用程式。網站之間共用的資料只有一小部分。

平行應用程式的延遲時間

例如，當您經營零售生意時，可能會在不同的地區透過不同的國家/地區網域提供使用者服務，並在所有這些地區架設平行網站，只在需要時，才同步處理產品和使用者資料。當地的網站會維持其當地的庫存量，而使用者會透過選擇國家/地區網域，連線到當地託管網站。當使用者造訪不同的國家/地區網域時，會被重新導向到正確的網域。

另一個例子是即時遊戲。您可能只有一個全球大廳服務，使用者會在此選擇其位置附近的遊戲室或遊戲世界，這些遊戲室或遊戲世界不會彼此共用資料。

第三個例子是在不同地區提供軟體式服務 (SaaS)，其中資料位置會在建立帳戶時選取，可能是依據使用者位置或由使用者選擇。使用者登入後，會被重新導向到位置專屬子網域，並依地區使用服務。

最佳化使用者與地區間的延遲時間

不管您選擇哪一種部署模式，都可以結合使用最佳化方法，來縮短使用者明顯感受到的延遲。其中一些方法也是Google Cloud 功能，另外有些方法則會要求您變更應用程式。

使用進階級網路

Google 提供進階級 (預設) 和標準級的網路服務級別。標準級流量會從 Google Cloud地區經由轉訊 ISP 傳遞，進階級則透過 Google 的全球私人網路傳遞流量，實現更低的延遲。進階級網路可以縮短使用者延遲時間，適用於服務路徑中的應用程式所有層面。進階級網路還需要搭配 Google 的全球負載平衡產品使用。

使用 Cloud Load Balancing 和 Cloud CDN

Cloud Load Balancing 包括 HTTP(S) 負載平衡、TCP 和 SSL Proxy 負載平衡等，可讓您自動將使用者重新導向到有後端且具有可用容量的最近地區。

即使您的應用程式只在單一地區，使用 Cloud Load Balancing 依然可以提供更低的使用者延遲，因為 TCP 和 SSL 工作階段會在網路邊緣終止。使用 HTTP/2 和快速 UDP 網際網路連線 (QUIC) 可輕鬆終止使用者流量。您也可以整合 Cloud CDN 與 HTTP(S) 負載平衡，以直接從網路邊緣提供靜態資產，進而縮短使用者延遲時間。

在本機快取

前端位置與後端位置不同時，請務必盡量從後端服務快取回應。當前端和後端位於同一地區，會縮短應用程式延遲時間，因為耗時的查詢量也減少了。Memorystore for Redis 是您可以使用的全代管記憶體內資料存放區。

最佳化應用程式用戶端或網路前端

您可以在用戶端 (行動應用程式或網路前端) 運用技術，來獲致最佳的使用者延遲時間。例如，預先載入部分資產，或快取應用程式中的資料。

您也可以盡量減少要求數量並且平行擷取資訊，將應用程式擷取資訊的方式最佳化。

測量使用者延遲時間

建立延遲要求的基準後，請查看使用者的分佈來決定 Google Cloud 資源的最佳放置方式。視應用程式是新的還是現有的而定，運用的策略也會所有不同。

請使用以下策略，來測量在應用程式服務期間存取合作夥伴的延遲時間，或是測量連接內部部署網路的延遲時間，該內部部署網路可能使用 Cloud VPN 或專屬互連網路與 Google Cloud 專案互連。

估算新工作負載的延遲時間

如果現有應用程式沒有類似新應用程式的使用者，那您可以根據預期使用者的粗略位置分佈，估算不同 GCP 地區的延遲時間。 Google Cloud

每 100 公里的傳輸距離估算有 1 毫秒的往返延遲。由於網路不會按照來源到目標的理想路徑走，所以通常可以推算實際距離約為地圖上測得距離的 1.5 到 2 倍。當然，在人口不密集的地區，網路的走線路徑甚至更不盡理想。就跨地區距離而言，在 ISP 網路中經過主動設備而增加的延遲時間，通常微乎其微。

這些數字可以幫助您估算抵達邊緣 POP 和 Cloud CDN 節點，還有世界各地 Compute Engine 地區 (如網路分佈圖所列) 的延遲時間。

測量連接現有使用者的延遲時間

如果現有的應用程式已有類似的使用者數量，那您可以使用幾個工具來更準確地評估延遲時間。

  • 代表性使用者：如果您的使用者或合作夥伴具地理分布代表性，並且有意願跟您合作，或是您在這些國家/地區有員工，可請他們測量連接各種不同 Google Cloud 地區的延遲時間。第三方網站如 Google Cloud ping 也可以協助您進行這類測量。
  • 存取記錄：如果您在Google Cloud之外託管可用的應用程式，可使用存取記錄的資料來粗略剖析使用者。您的記錄可能會提供國家/地區或城市資訊，您也可以利用這類資訊來估算延遲時間。
  • IP 位址：如果您可以存取使用者的 IP 位址，則可建立指令碼來測試各個不同 Google Cloud區域的可連性和延遲時間。如果使用者的防火牆封鎖了探測，請試著隨機挑選最後的 IP 八位元，以從另一個裝置 (該裝置連接您的應用程式時有類似的延遲時間) 取得回應。

  • Google Cloud提供的延遲時間資訊：如果您在 Google Cloud中已有應用程式，則有幾種方式可以收集延遲時間資訊。 Google Cloud

全球連線

估算延遲時間時，請記住 Google 全球網路的拓撲。

  • POP：使用者流量進入網路的位置。
  • Cloud CDN 節點：快取流量的位置。
  • 地區：可以放置資源的位置。
  • 連線：POP 與地區之間。

PeeringDB 提供 Google 與其他 ISP 互連所在的位置清單。

決定要部署在哪個地區時，請務必考量地區間拓樸。舉例來說，如果您想在單一地區部署使用者遍布全球的應用程式，最好將這個應用程式置於美國其中一個地區託管，因為美國連線到其他最多的地區。雖然許多大洲之間可以直接連線，但譬如歐洲和亞洲之間無法連線時，歐亞之間的流量即會經由美國傳輸。

如果在多個地區中託管您的應用程式，而且您必須同步資料時，請注意這些地區之間的延遲時間。雖然延遲時間會隨時間而改變，但通常是穩定的。您可在所有潛在地區建立測試執行個體來自行測量延遲時間，或使用第三方網站來瞭解地區間的目前延遲時間。

完整的實作範例

現在，您思考過延遲要求、可能的部署模式，以及使用者的地理分佈，應該已瞭解哪些因素會影響連接某些地區的延遲時間。這時可以決定要在哪些地區啟動您的應用程式。

雖然沒有可正確權衡各種因素的方式，但下列的逐步方法也許可以幫助您做決定：

  1. 查看是否有與延遲時間無關的其他因素會阻礙您在特定地區進行部署，例如價格或主機代管服務。將這些地區從您的地區清單中移除。
  2. 根據應用程式的延遲要求和一般架構來選擇部署模式。對於大多數行動應用程式和其他不受延遲影響的關鍵應用程式，單一地區部署搭配 Cloud CDN 交付可快取的內容，以及在邊緣執行 SSL 終止，可能是最佳選擇。

  3. 視部署模式而定，依據使用者的地理分布和延遲測量值選擇地區：

    • 單一地區部署：

      • 如果您需要低延遲存取公司據點，請在最接近這個位置的地區部署。
      • 如果使用者主要來自同一國家/地區，請在最接近代表性使用者的地區部署。
      • 如果使用者遍布全球，請部署在其中一個美國地區。

    • 多地區部署：

      • 根據使用者的地理分布和應用程式的延遲要求，選擇使用者附近的地區。視您的應用程式而定，對延遲時間中位數最佳化，或確保 95-99% 的使用者能在指定的目標延遲時間內獲得服務。某些地理位置的使用者會因為基礎架構的限制，對延遲時間的容忍度較高。

  4. 如果有多個地區的使用者延遲時間差距不大，則價格可能會是決定因素。

選擇 Compute Engine 地區時，延遲時間是其中一個最重要的考量因素。評估及測量可提供優質使用者體驗的延遲要求；如果使用者的地理分佈變動，可重複執行這個程序。

後續步驟