自动扩缩器工具概览

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

如需详细了解如何在 Spanner 中伸缩，请参阅自动伸缩 Spanner。如需了解如何部署自动扩缩器工具，请参阅以下内容：

本页面介绍了自动扩缩器的功能、架构、配置和部署拓扑。本系列文章的后续主题将指导您在每个不同的拓扑中部署自动扩缩器。

自动扩缩器

自动扩缩器工具用于管理 Spanner 部署的利用率和性能。为了帮助您在费用控制与性能需求之间取得平衡，自动扩缩器工具会监控您的实例并自动添加或移除节点或处理单元，以确保它们保持在以下参数范围内：

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

架构

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

自动扩缩器工具架构由 Cloud Scheduler、两个 Pub/Sub 主题、两个 Cloud Functions 和 Firestore 组成。Cloud Monitoring API 用于获取 Spanner 实例的 CPU 利用率和存储指标。

Cloud Scheduler

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

轮询器 Cloud Functions 函数

Poller Cloud Functions 函数负责收集和处理一个或多个 Spanner 实例的时间序列指标。轮询器会对每个 Spanner 实例的指标数据进行预处理，以便只评估最相关的数据点并将其发送到 Scaler Cloud Functions 函数。Poller Cloud Functions 函数执行的预处理还简化了评估单区域和多区域 Spanner 实例阈值的过程。

扩缩器 Cloud Functions 函数

Scaler Cloud Functions 函数会评估从 Poller Cloud Functions 函数收到的数据点，并确定您是否需要调整节点数或处理单元数，如果需要调整多少。Cloud Functions 函数将指标值与阈值进行比较（加上或减去允许的利润率），并根据配置的伸缩方法调整节点或处理单元的数量。如需详细了解伸缩方法，请参阅自动伸缩器功能。

操作流程

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

自动扩缩器操作模型。

  1. 您可以在 Cloud Scheduler 中定义自动扩缩作业的时间表、时间和频率。
  2. Cloud Scheduler 按照您定义的时间表，将包含 JSON 载荷的消息和一个或多个 Spanner 实例的自动扩缩器工具配置参数推送至“轮询 Pub/Sub”主题。
  3. 当消息发布到轮询主题时，会创建一个轮询器 Cloud Functions 函数实例来处理该消息。
  4. Poller Cloud Functions 函数会读取消息载荷并查询 Cloud Monitoring API 以检索每个 Spanner 实例的利用率指标。
  5. 对于消息中枚举的每个 Spanner 实例，Poller 函数会将一条消息推送到扩缩 Pub/Sub 主题，其中包含要为特定 Spanner 实例评估的指标和配置参数。

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

    1. 将 Spanner 实例指标与配置的阈值进行比较，加上或减去可配置的利润率。

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

  7. Scaler Cloud Functions 函数会从 Firestore 中检索上次伸缩实例的时间，并将其与当前时间进行比较，从而根据冷却期确定是否允许纵向扩容或缩容。

  8. 如果配置的冷却期已结束，则扩缩器 Cloud Function 会向 Spanner 实例发送请求以扩缩。

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

无论您选择哪种部署拓扑，自动扩缩器工具的整体操作都将保持不变。

自动扩缩器功能

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

管理多个实例

自动扩缩器工具可以跨多个项目管理多个 Spanner 实例。多区域实例和区域实例在扩缩时使用的利用率阈值也不同。例如，多区域部署会以 45% 的高优先级 CPU 利用率扩缩，而区域部署会以 65% 的高优先级 CPU 利用率扩缩（均衡允许的利润率）。如需详细了解不同的伸缩阈值，请参阅高 CPU 利用率提醒。

独立的配置参数

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

这些参数确定以下因素：

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

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

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

阶梯

分步伸缩对于具有较小或多个峰值的工作负载非常有用。它通过单个自动扩缩事件来预配容量，从而消除这些工作负载。

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

加载模式包含多个阶梯。

当超过负载阈值时，此方法会使用固定但可配置的数值来预配和移除节点或处理单元。例如，对于每项伸缩操作，系统会添加或移除三个节点。通过更改配置，您可以允许随时添加或移除更大的容量增量。

线性

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

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

具有波动的负载模式。

自动扩缩器工具使用观察到的利用率与利用率阈值的比率，计算当前总数中是否增减节点或处理单元数。

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

newSize = currentSize * currentUtilization / utilizationThreshold

直接

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

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

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

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

部署方法

自动扩缩器工具可以部署在单个项目中，也可以与其管理的 Spanner 实例一起部署。自动扩缩器工具旨在实现灵活性，并且可以适应运营团队和应用团队之间现有的职责分离。配置 Spanner 实例的自动扩缩的责任可以集中在单个运营团队中，也可以分散给距离这些 Spanner 实例所提供服务的应用较近的团队。

部署拓扑中更详细地讨论了不同的部署模型。

无服务器方便部署和管理

自动扩缩器工具仅使用无服务器的低管理 Google Cloud 工具（例如 Cloud Functions、Pub/Sub、Cloud Scheduler 和 Firestore）构建而成。此方法可最大限度地减少运行自动扩缩器工具的费用和运营开销。

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

配置

自动伸缩器工具具有不同的配置选项，您可以使用这些选项来管理 Spanner 部署的伸缩。以下部分将介绍基本配置选项和更多高级配置选项。

基本配置

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

   [
    {
        "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 实例位于不同的项目中。此部署适用于通过自动扩缩器工具的单个部署集中管理多个 Spanner 实例的配置和基础架构的团队。

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

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

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

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

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

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

优点：

  • 集中式配置和基础架构：由单个团队控制调度器参数和自动扩缩器基础架构。在受严格监管的行业中，此方法非常有用。
  • 整体维护较少：与每个项目的部署相比，维护和设置通常所需的维护工作量更少。
  • 集中式政策和审核：跨团队的最佳做法可能更易于指定和强制执行。审核可能更容易执行。

缺点：

  • 集中配置：对自动扩缩器参数所做的任何更改都需要交由集中式团队处理，即使请求更改的团队拥有 Spanner 实例也是如此。
  • 潜在的额外风险：即使自动扩缩器基础架构在设计时考虑了高可用性，集中式团队本身也可能会成为单点故障。

如需了解使用此选项设置自动扩缩器工具的分步教程，请参阅为 Spanner 部署按项目或集中式自动扩缩器工具。

分布式拓扑

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

下图显示了分布式项目部署的概要概念视图。

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

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

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

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

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

优点：

  • 应用团队控制配置和时间表：Cloud Scheduler 与自动扩缩的 Spanner 实例一起部署，使应用团队能够更好地控制配置和调度。
  • 运维团队控制基础架构：自动扩缩器工具的核心组件集中部署，使运维团队能够控制自动扩缩器基础架构。
  • 集中维护：扩缩器基础架构集中进行，可减少开销。

缺点：

  • 更复杂的配置：应用团队需要提供服务帐号才能写入轮询主题。
  • 潜在的额外风险：共享基础架构可能成为单点故障，即使基础架构在设计时考虑了高可用性也是如此。

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

数据拆分

Spanner 将称为“分块”的数据范围分配给称为“处理单元”的节点或细分。这些节点或处理单元独立管理和传送经过分摊的分块中的数据。数据拆分基于多种因素（包括数据量和访问模式）创建。如需了解详情，请参阅 Spanner - 架构和数据模型。

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

自动扩缩器工具会针对纵向扩容和纵向缩容事件使用冷却期，以控制其在实例中添加或移除节点或处理单元的速度。这种方法可让实例有必要的时间重新组织计算备注或处理单元与数据拆分之间的关系。默认情况下，纵向扩容和纵向缩容冷却期设置为以下最小值：

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

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

费用

自动扩缩器工具的资源消耗量极少，因此在大多数情况下，相关费用几乎可以忽略不计。在 Google Cloud 上使用自动扩缩器时不会产生任何费用。例如，您可以免费运行一个自动扩缩器工具来管理 3 个 Spanner 实例，且每个实例的轮询间隔为 5 分钟。估算数据包括以下各项：

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

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

后续步骤