自动扩缩器工具概览

本页面介绍了适用于 Spanner 的自动扩缩器工具（自动扩缩器）， 开源工具 可用作 Spanner 的配套工具。此工具 让您可以在一个或多个可用区自动增加或减少计算容量 根据正在使用的容量确定 Spanner 实例。

如需详细了解如何在 Spanner 中进行伸缩，请参阅 自动扩缩 Spanner。对于 有关部署自动扩缩器工具的信息，请参阅以下内容：

本页面介绍了功能、架构、配置和部署 以及自动扩缩器的拓扑结构本系列后续主题将引导您 通过在每个不同拓扑中部署自动扩缩器来实现。

自动扩缩器

自动扩缩器工具可用于管理 Spanner 部署。有助于您在费用控制 自动扩缩器工具会监控您的实例，并自动 添加或移除节点或处理单元，以帮助确保 以下参数：

自动扩缩 Spanner 部署，让您的基础架构可以 可自动进行调整和扩缩以满足负载要求， 进行干预。自动扩缩功能还可为预配的基础架构设置适当的容量，从而帮助您降低费用。

架构

本部分详细介绍了自动扩缩器的各个组件及其各自的用途。

自动扩缩器工具架构包括 Cloud Scheduler ，两个 Pub/Sub 主题， Cloud Run 函数 和 Firestore ，了解所有最新动态。通过 Cloud Monitoring API 用于获取 Spanner 的 CPU 利用率和存储指标 实例。

Cloud Scheduler

使用 Cloud Scheduler ，您可以定义自动扩缩器工具验证 Spanner 的频率 实例伸缩指标阈值。Cloud Scheduler 作业可以同时检查一个或多个实例。您可以根据需要定义任意数量的作业时间表。

轮询器 Cloud Run 函数

Poller Cloud Run 函数 负责收集和处理一个或多个 更多 Spanner 实例。轮询器会预处理 每个 Spanner 实例，以便系统仅存储最相关的数据点 评估并发送到 Scaler Cloud Run 函数。预处理 Poller Cloud Run 函数可以简化 评估单区域、双区域和多区域位置的阈值 Spanner 实例。

Scaler Cloud Run 函数

扩展器 Cloud Run 函数 用于评估从 Poller Cloud Run 函数收到的数据点，以及 确定是否需要调整节点数量或处理单元数 如果是，具体增加了多少Cloud Run 函数 将指标值与阈值进行比较，然后加上或减去允许的 利润率 并根据配置的 伸缩方法如需详细了解伸缩方法，请参阅自动伸缩器功能 ，了解所有最新动态。

操作流程

本部分详细介绍了自动扩缩器工具的操作模式，如 如下架构图所示

自动扩缩器操作模型。

  1. 您可以在 Google Cloud 控制台 Cloud Scheduler
  2. Cloud Scheduler 根据您定义的时间表推送消息 包含带自动扩缩器工具配置参数的 JSON 载荷 一个或多个 Spanner 实例进入轮询 Pub/Sub 主题。
  3. 当消息发布到轮询主题时， 系统会创建轮询器 Cloud Run 函数来处理消息。
  4. Poller Cloud Run 函数 读取消息载荷并查询 Cloud Monitoring API 以检索 利用率指标
  5. 对于消息中枚举的每个 Spanner 实例， 轮询器函数将一条消息推送到扩缩 Pub/Sub 主题，包含用于评估 特定 Spanner 实例。

  6. 对于推送到扩缩器主题的每条消息，扩缩器都会 Cloud Run 函数会执行以下操作：

    1. 将 Spanner 实例指标与 配置阈值，加上或减去一个可配置的 margin（外边距）。

    您可以自行配置外边距，也可以使用默认值。 1. 决定是否应对实例进行扩缩。 1. 计算实例的节点数或处理单元数 应根据所选的伸缩方法进行缩放

  7. Scaler Cloud Run 函数会检索实例的 上次从 Firestore 扩缩而来，并将其与当前的 用于根据冷却期确定是否允许纵向扩容或缩容 。

  8. 如果配置的冷却期已过，则扩缩器 Cloud Run 函数向 Spanner 发送请求 要扩容或缩容的实例。

在整个流程中，自动扩缩器工具会编写其建议的摘要。 和操作 Cloud Logging 以便进行跟踪和审核

无论部署拓扑如何 自动扩缩器工具的整体操作将保持不变。

自动扩缩器功能

本部分介绍自动扩缩器工具的主要功能。

管理多个实例

自动扩缩器工具能够跨多个 Spanner 实例 多个项目多区域实例、双区域实例和区域实例 伸缩时使用的不同利用率阈值例如： 多区域和双区域部署按照 45% 的高优先级 CPU 进行扩缩 而区域级部署的扩容能力为 65% 高优先级 CPU （加上或减去允许的 margin（外边距）。 如需详细了解不同的伸缩阈值，请参阅 CPU 利用率高的提醒。

独立的配置参数

每个自动扩缩的 Spanner 实例可以有一个或多个轮询 时间表。每个轮询时间表都有自己的一组配置参数。

这些参数确定以下因素：

  • 节点或处理单元的最小和最大数量，用于控制 实例规模大小，可帮助您控制费用。
  • 伸缩方法 来根据工作负载调整 Spanner 实例。
  • 冷却期 让 Spanner 来管理数据拆分。

针对不同的工作负载采用不同的扩缩方法

自动伸缩器工具提供三种不同的伸缩方法，用于实现自动伸缩 您的 Spanner 实例进行伸缩：分步、线性和直接。每个 设计用于支持不同类型的工作负载。您可以应用其中一个或 您创建自动扩缩的每个 Spanner 实例 独立的轮询时间表

阶梯

分步伸缩对于具有较小或多个峰值的工作负载非常有用。它 预配容量，通过单个自动扩缩事件来顺利完成所有任务。

下图显示了具有多个负载水平或阶梯的负载模式，其中每个阶梯有多个小峰值。此模式非常适合阶梯方法。

加载模式包含多个阶梯。

当超过负载阈值时，此方法会预配和移除节点或 处理单元数。例如，三个节点 添加或移除通过更改此配置 以便随时添加或移除更大的容量

线性

线性扩缩最适合负载逐步变化或具有一些大峰值的负载模式。该方法会计算节点数下限或 将利用率保持在伸缩阈值以下所需的处理单元数。通过 每个伸缩事件中添加或移除的节点或处理单元的数量 不限于固定步数。

下图中的示例负载模式显示了负载较大的突然增加和减少。这些波动不会像在上一张图表中的阶梯一样明显。使用线性扩缩可以更轻松地处理此模式。

具有波动的负载模式。

自动扩缩器工具使用观察到的利用率与 用于计算是增加还是减少节点或 处理单元数。

计算新节点或处理单元数的公式如下所示：

newSize = currentSize * currentUtilization / utilizationThreshold

直接

直接扩缩功能可以即时提升容量。此方法旨在支持批处理工作负载，在其中，需要定期按已知的开始时间调度预先定义的较高节点计数。此方法可扩缩 节点或处理单元数的上限 此时间表旨在与线性或分步展示 方法。

下图描述了负载计划的计划大幅增加，而自动扩缩器为使用直接方法提前预配了容量。

预配置直接扩缩的负载模式。

当批量工作负载完成并且利用率达到正常水平（具体取决于您的配置）后，系统将应用线性或阶梯扩缩功能来自动缩减实例。

部署方法

自动扩缩器工具可以在单个项目中部署，也可以与 Spanner 实例。自动扩缩器工具旨在 既能实现灵活性，又能适应 您的运营团队和应用团队之间的职责。通过 负责配置 Spanner 实例的自动扩缩 可以集中在单个运营团队中，也可以分发至 使他们更紧密地 实例。

本专精课程更详细地介绍了 部署拓扑。

无服务器方便部署和管理

自动扩缩器工具仅使用无服务器和低管理 Google Cloud 服务构建 例如 Cloud Run 函数、Pub/Sub Cloud Scheduler 和 Firestore。这种方法可最大限度地减少 降低运行自动扩缩器工具的费用和运营开销。

通过使用内置的 Google Cloud 工具，自动扩缩器工具可以充分利用 充分利用 IAM (IAM) 进行身份验证和授权

配置

自动扩缩器工具具有不同的配置选项，可用于 来管理 Spanner 部署的伸缩。后续部分 介绍基本配置选项和更多高级配置选项。

基本配置

自动扩缩器工具通过 Cloud Scheduler 中的定义。如果多个 Spanner 实例需要 以相同的时间间隔进行轮询，我们建议您在 同一个 Cloud Scheduler 作业每个实例的配置 以 JSON 对象的形式表示以下是一个配置示例 其中两个 Spanner 实例都通过一个 Cloud Scheduler 作业：

   [
    {
        "projectId": "my-spanner-project", "instanceId": "spanner1",
        "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
        "units": "NODES", "minSize": 1, "maxSize": 3
     },
     {
        "projectId":
        "different-project", "instanceId": "another-spanner1", "scalerPubSubTopic":
        "projects/my-spanner-project/topics/spanner-scaling", "units":
        "PROCESSING_UNITS", "minSize": 500, "maxSize": 3000, "scalingMethod": "DIRECT"
    }
   ]

Spanner 实例可以在不同的 Cloud Scheduler 作业。例如，一个实例可以有一个包含用于正常操作的线性方法的自动扩缩器配置，但还有另一个包含用于计划批量工作负载的直接方法的自动扩缩器配置。

Cloud Scheduler 作业运行时，它将向 Polling Pub/Sub 主题发送 Pub/Sub 消息。此消息的载荷是在同一作业中配置的所有实例的配置对象的 JSON 数组。如需查看配置选项的完整列表，请参阅轮询器 README 文件。

高级配置

自动扩缩器工具提供高级配置选项 控制何时以及如何管理 Spanner 实例。以下 部分介绍了一系列控件。

自定义阈值

自动扩缩器工具决定了 使用 建议的 Spanner 阈值 选择以下加载指标：

  • 高优先级 CPU
  • CPU 24 小时滚动平均值
  • 存储空间利用率

我们建议您使用默认阈值，如 为 Spanner 指标创建提醒 ，了解所有最新动态。但在某些情况下，您可能需要修改 自动扩缩器工具例如，您可以使用较低的阈值 与使用更高阈值相比，自动扩缩工具的反应速度更快。此修改 有助于防止在达到较高阈值时触发提醒。

自定义指标

虽然自动扩缩器工具中的默认指标可解决大多数性能问题和 伸缩在某些情况下，您可能需要指定 用于确定何时进行扩缩的自有指标。对于这些情况 您可以使用 metrics 属性。

边际

边际定义了阈值的上限和下限。自动扩缩器 仅当指标值大于 上限或小于下限。

此参数的目标是避免自动扩缩事件围绕阈值附近的小工作负载波动触发，从而减少自动扩缩器操作中的波动量。阈值和边际共同根据指标值您想要定义以下范围：

[threshold - margin, threshold + margin]
。 利润率越小，范围就越小 触发自动扩缩事件的概率。

指定指标的边际参数是可选的，并且默认为该参数前后的 5 个百分点。

部署拓扑

要部署自动扩缩器工具，请确定以下哪种拓扑最佳 以满足您的技术和运营需求：

  • 每个项目的拓扑：自动扩缩器基础架构部署在 与需要自动扩缩的 Spanner 项目相同。
  • 集中式拓扑：自动扩缩器工具部署在一个项目中， 管理不同项目中的一个或多个 Spanner 实例。
  • 分布式拓扑：大部分自动扩缩器基础架构都已部署 但有些基础设施组件是使用 在不同项目中自动扩缩的 Spanner 实例。

每个项目的拓扑

在每个项目的拓扑部署中，每个需要 Spanner 实例进行自动缩放的项目也具有自己的自动扩缩器组件独立部署。对于希望管理自己的自动扩缩器配置和基础架构的独立团队，我们建议使用此拓扑。它也是一种 测试自动扩缩器工具功能的理想起点。

下图展示了每个项目部署的高度概括的概念视图。

概念性的每个项目部署。

上图中描述的每个项目的部署包括 特征：

  • 两个应用（应用 1 和应用 2）各自使用 Spanner 实例。
  • Spanner 实例 (A) 位于相应的应用 1 和 应用 2 项目。
  • 每个项目中都部署了一个独立的自动扩缩器 (B)，以控制 自动扩缩。

有关每个项目部署的更详细图表，请参阅 架构 部分。

每个项目部署具有以下优点和缺点。

优点：

  • 最简单的设计：每个项目的拓扑是最简单的 由于所有自动扩缩器组件都与 自动扩缩的 Spanner 实例。
  • 配置：由团队控制调度器参数 这使得团队拥有更多 可以根据需要，自由地调整自动扩缩器工具，而不是集中式或 分布式拓扑
  • 明确承担基础架构责任：每个项目的拓扑设计可以为自动扩缩器基础架构建立明确的责任与安全性，因为 Spanner 实例的团队所有者也是自动扩缩器基础架构的所有者。

缺点：

  • 更多整体维护：每个团队都负责自动扩缩器 因此可能很难确保 公司所有的自动扩缩工具工具都遵循相同的更新 指南。
  • 更复杂的审核：由于每个团队都具有更高级别的控制，因此集中式审核可能会更复杂。

如需了解如何使用每个项目拓扑设置自动扩缩器，请参阅 为 Spanner 部署基于项目或集中式自动扩缩器工具。

集中式拓扑

与在每个项目拓扑中一样，在集中式拓扑部署中，所有 自动扩缩器工具的各个组件位于同一项目中。但是，Spanner 实例位于不同的项目中。这个 适合管理集群内配置和基础架构的团队， 自动扩缩器的单个部署中的多个 Spanner 实例 工具。

下图显示集中式项目部署的高度概括的概念视图：

概念性的集中式项目部署。

上图中显示的集中式部署具有以下特征：

  • 两个应用（应用 1 和应用 2）各自使用 Spanner 实例。
  • Spanner 实例 (A) 分别位于应用 1 和 应用 2 项目。
  • 自动扩缩器 (B) 部署到单独的项目中，以控制 自动扩缩应用 1 和 应用 2 项目。

如需查看集中式项目部署的详细图表，请参阅 为 Spanner 部署基于项目或集中式自动扩缩器工具。

集中式部署具有以下优势和缺点。

优点：

  • 集中的配置和基础架构：一个团队负责控制 调度器参数和自动扩缩器基础架构。这种方法可以 适用于受严格监管的行业。
  • 整体维护工作量减少：维护和设置工作通常较少 与按项目部署相比
  • 集中式政策和审核：跨团队的最佳做法可能更易于指定和强制执行。审核可能更容易执行。

缺点：

  • 集中式配置：对自动扩缩器参数的任何更改都需要 需要通过集中式团队处理，即使请求的是 拥有 Spanner 实例。
  • 潜在额外风险：集中式团队本身可能会变为 即使将自动扩缩器基础架构设计为单点故障， 兼顾高可用性

有关使用此选项设置自动扩缩器工具的分步教程，请参阅 为 Spanner 部署每个项目或集中式自动扩缩器工具。

分布式拓扑

在分布式拓扑部署中，Cloud Scheduler 和 需要自动扩缩的 Spanner 实例位于同一 项目。自动扩缩器工具的其余组件集中位于 托管项目此部署是混合部署。拥有 Spanner 实例仅管理自动扩缩器配置 其实例参数，而由中央团队管理其余的 自动扩缩器基础架构。

下图简要展示了 分布式项目部署

概念性的分布式项目部署。

上图中描述的混合部署具有以下特征：

  • 两个应用（应用 1 和应用 2）使用自己的 Spanner 实例。
  • Spanner 实例 (A) 位于应用 1 和应用 2 项目中。
  • 每个独立的 Cloud Scheduler 组件 (C) 中 项目：应用 1 和应用 2。
  • 将其余的自动扩缩器组件 (B) 部署到单独的项目中。
  • 自动扩缩器工具可自动扩缩 使用由以下应用发送的配置的应用 1 和应用 2 项目 每个项目中独立的 Cloud Scheduler 组件

如需查看集中式项目部署的更详细图表，请参阅 为 Spanner 部署分布式自动扩缩器工具。

分布式部署具有以下优势和缺点。

优点：

  • 应用团队控制配置和时间表： Cloud Scheduler 与 Spanner 一起部署 自动扩缩的实例，让应用团队拥有更多控制权
  • 运营团队控制基础架构： 自动扩缩器工具集中部署，让运营团队可以控制 自动扩缩器基础架构
  • 集中维护：扩缩器基础架构是集中式的，可减少 开销。

缺点：

  • 更复杂的配置：应用团队需要提供服务 可向轮询主题写入数据。
  • 可能会带来额外风险：共享基础设施可能会 单点故障，即使基础设施的设计 确保它们的可用性

如需了解如何在分布式部署中设置自动扩缩器工具，请参阅 为 Spanner 部署分布式自动扩缩器工具。

数据拆分

Spanner 将称为“分片”的数据范围分配给节点或细分 称为“处理单元”的节点节点或处理单元 在拆分的分块中管理和传送数据。创建数据拆分 根据数据量和访问模式等多种因素进行对比。有关 请参阅 Spanner - 架构和数据模型 ，了解所有最新动态。

数据会被整理成多个分块，Spanner 会自动管理 分块。因此，在自动扩缩器工具添加或移除节点或处理单元时 则需要给 Spanner 后端留出足够的时间来重新分配和 在实例中添加或移除新容量时，重新组织分块。

自动扩缩器工具对纵向扩容和纵向缩容事件使用冷却期 以控制在集群内添加或移除节点或处理单元的速度， 实例。此方法为实例留出必要的时间来重新整理 计算备注或处理单元与数据拆分之间的关系。修改者 默认情况下，扩容和缩容冷却期设置为以下 最小值：

  • 扩容值：5 分钟
  • 缩减值：30 分钟

如需详细了解伸缩建议和冷却期，请参阅 扩缩 Spanner 实例。

费用

自动扩缩器工具的资源消耗极少，因此对于大多数使用场景， 可以忽略不计。在 Google Cloud 上使用自动扩缩器不会产生任何费用。 例如 ，运行一个自动扩缩器工具来管理 3 个具有 轮询间隔设置为 5 分钟是免费的。这个 估算值包括：

  • 3 个 Cloud Scheduler 作业
  • 0.15 GB 的 Pub/Sub 消息
  • 51840 次 Cloud Run 函数调用（500 毫秒）
  • Firestore 中的数据不到 10 MB

此估算值不包括 Spanner 数据库操作费用。使用 价格计算器 根据您的预计使用情况来估算费用。

后续步骤