选择 Compute Engine 地区时的最佳做法

本文介绍了在选择要用于 Compute Engine 资源的 Google Cloud区域时需要考虑的条件，这一决策通常由云架构师或工程管理人员制定。本文档着眼于选择过程中的延迟因素，虽然主要关注面向消费者的应用（如移动应用、Web 应用或游戏），但许多概念也适用于其他使用场景。

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 年，我们在每个区域全天提供无碳电力来随时随地支持您的应用。 Google Cloud

在实现此目标之前，每个 Google Cloud 区域每小时都会提供有碳和无碳的混合能源。我们将此指标称为无碳能源百分比 (CFE%)，并且我们发布了 Google Cloud 区域的 CFE%。对于 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 代理负载平衡）允许您自动将用户重定向到具有可用容量后端的最近地区。

即使您的应用仅位于单个区域，使用 Cloud Load Balancing 仍可实现较低的用户延迟，因为 TCP 和 SSL 会话在网络边缘终止。使用 HTTP/2 和快速 UDP 互联网连接 (QUIC) 可轻松终止用户流量。 您还可以将 Cloud CDN 与 HTTP (S) 负载均衡相集成，以直接从网络边缘传送静态资源，从而进一步减少用户延迟。

在本地缓存

当您的前端位置与后端位置不同时，请确保尽可能缓存来自后端服务的响应。当前端和后端位于同一地区时，应用延迟会降低，因为耗时的查询也会减少。Memorystore for Redis 是可供您使用的全代管式内存中数据存储服务。

优化应用客户端或 Web 前端

您可以在客户端（移动应用或网络前端）使用技术来优化用户延迟。例如，在应用中预加载一些资产或缓存数据。

您还可以通过尽可能减少请求数量并并行检索信息来优化应用获取信息的方式。

衡量用户延迟

确定延迟要求的基准后，请查看您的用户群，以确定 Google Cloud 资源的最佳位置。根据这是新应用还是现有应用，可以采用不同的策略。

使用以下策略可以衡量您在应用提供服务期间访问的合作伙伴的延迟，也可以衡量可能使用 Cloud VPN 或专用互连与您的 Google Cloud 项目互连的本地网络的延迟。

估算新工作负载的延迟

如果您的现有应用没有类似新应用的用户群，您可以根据预期用户群的粗略位置分布估算各个 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 全球网络的拓扑。

  • POP：用户流量进入网络的位置。
  • Cloud CDN 节点：缓存流量的位置。
  • 地区：您的资源所处的位置。
  • 连接：POP 和区域之间的连接。

在 PeeringDB 中查找 Google 与其他 ISP 互连的位置列表。

在选择要部署的地区时，请务必考虑地区间拓扑。例如，如果您要在单个地区中部署具有全球用户群的应用，通常最好将此应用托管在某个美国地区中，因为美国与大多数其他地区连接。尽管许多大陆之间存在直接连接，但也有例外情况，例如欧洲和亚洲之间缺少这种连接，因此欧洲和亚洲之间的流量会流经美国。

如果您的应用托管在多个地区，并且您需要同步数据，请注意这些地区之间的延迟。虽然这种延迟会随着时间而改变，但通常是稳定的。您可以通过在所有潜在地区中启动测试实例来自行衡量延迟，或者使用第三方网站了解各地区之间的当前延迟。

综合应用

现在您已经考虑了延迟要求、潜在部署模型以及用户群的地理分布，也就了解了这些因素如何影响某些地区的延迟。下一步就是确定启动应用的地区。

虽然没有万全的方法来权衡不同的因素，但下面的分步方法可能会帮助您做出决定：

  1. 看看是否存在阻止您在特定地区部署的非延迟相关因素（例如价格或共置）。从地区列表中移除这些地区。
  2. 根据延迟要求和应用的总体架构选择部署模型。对于大多数移动应用和其他非延迟关键应用，最理想的选择可能是通过 Cloud CDN 传送可缓存内容和在网络边缘终止 SSL 的单地区部署。

  3. 根据您的部署模型，根据用户群的地理分布和延迟水平选择地区：

    • 对于单地区部署：

      • 如果您需要对公司场所进行低延迟访问，请在距离此位置最近的地区进行部署。
      • 如果您的用户主要来自同一国家或地区，请在距离您的代表用户最近的地区进行部署。
      • 如果您的用户群遍布全球，请在美国的某个地区部署。

    • 对于多地区部署：

      • 根据用户的地理分布和应用的延迟时间要求，选择靠近您的用户的地区。 根据您的应用，针对特定的延迟时间中间值进行优化，或确保 95-99％ 的用户延迟时间达到特定的目标值。由于基础设施的限制，某些地理位置的用户通常对延迟时间具有更高的容忍度。

  4. 如果多个地区的用户延迟时间相似，则价格可能是决定因素。

选择 Compute Engine 地区时，延迟时间是需要考虑的最大因素之一。评估和衡量延迟要求，以提供高质量的用户体验，并在用户群的地理分布发生变化时重复此过程。

后续步骤