自动扩缩器工具具有灵活性,可以适应运营和应用团队之间的现有职责分离。配置 Spanner 实例的自动扩缩功能的职责可以由单个运营团队集中管理,也可以分发给这些 Spanner 实例提供的应用所在的团队。
本文档是系列文章中的一篇,该系列文章还包括:
本系列文章适用于想要降低运营开销和优化 Spanner 部署费用的 IT、运营和站点可靠性工程 (SRE) 团队。
本页介绍了三种根据您的要求将自动扩缩器部署到 Cloud Run 函数的方法:
- 每个项目的部署拓扑。自动扩缩器基础架构与需要自动扩缩的 Spanner 部署在同一项目中。对于希望管理自己的自动扩缩器配置和基础架构的独立团队,我们建议使用此拓扑。此外,每个项目的部署拓扑也是测试自动扩缩器功能的良好起点。
- 集中式部署拓扑。自动扩缩器工具部署在一个项目中,并管理不同项目中的一个或多个 Spanner 实例。对于管理一个或多个 Spanner 实例的配置和基础架构的团队,我们建议使用此拓扑结构,同时保持自动扩缩程序的组件和配置位于中心位置。在集中式拓扑中,除了自动扩缩程序,您还设置了第二个项目,本教程中称为“应用项目”。应用项目包含应用资源,包括 Spanner。
- 分布式部署拓扑。大多数自动扩缩器基础架构部署在一个项目中,但某些基础架构组件通过不同的 Cloud Spanner 实例进行了自动扩缩,这些项目中的不同项目也会进行自动扩缩。对于拥有多个团队的组织,我们建议使用此拓扑结构,其中拥有 Spanner 实例的团队只希望管理其实例的自动扩缩器配置参数,而自动扩缩器基础架构的其余部分由中心团队管理。
无服务器方便部署和管理
在此模型中,自动扩缩器工具仅使用无服务器和低管理 Google Cloud 工具(例如 Cloud Run 函数、Pub/Sub、Cloud Scheduler 和 Firestore)构建。这种方法可最大限度地减少运行自动扩缩器工具的费用和操作开销。
使用内置的 Google Cloud 工具,自动扩缩器工具可充分利用 Identity and Access Management (IAM) 进行身份验证和授权。
配置
自动扩缩器工具通过在 Cloud Scheduler 中定义的配置管理 Spanner 实例。如果您需要以相同的间隔轮询多个 Spanner 实例,我们建议您在相同的 Cloud Scheduler 作业中配置它们。每个实例的配置都以 JSON 对象的形式表示。以下是一个配置示例,在其中,使用一个 Cloud Scheduler 作业管理两个 Spanner 实例:
[
{
"projectId": "my-spanner-project",
"instanceId": "my-spanner",
"scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
"units": "NODES",
"minSize": 1,
"maxSize": 3
},
{
"projectId": "different-project",
"instanceId": "another-spanner",
"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 实例进行自动缩放的项目也具有自己的自动扩缩器组件独立部署。对于希望管理自己的自动扩缩器配置和基础架构的独立团队,我们建议使用此拓扑。这也是测试自动扩缩器工具功能的良好起点。
下图展示了每个项目部署的高度概括的概念视图。
上图中描述的每个项目部署具有以下特征:
- 两个应用(应用 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 实例也是如此。
- 具有额外风险的可能性:集中式团队本身可能会成为单点故障,即使设计自动扩缩器的基础架构在设计时考虑了高可用性。
如需了解如何使用集中式拓扑设置自动扩缩器,请参阅集中式部署分步指南。
分布式拓扑
在分布式拓扑部署中,需要自动扩缩的 Cloud Scheduler 和 Spanner 实例位于同一项目中。自动扩缩器工具的其余组件位于一个集中管理的项目中。此部署是混合部署。拥有 Spanner 实例的团队仅管理其实例的自动扩缩器配置参数,而中心团队负责管理其余的自动扩缩器基础架构。
下图显示分布式项目部署的高度概括的概念视图。
上图中描述的混合部署具有以下特征:
- 两个应用(应用 1 和应用 2)使用各自的 Spanner 实例。
- Spanner 实例 (A) 位于应用 1 和应用 2 项目中。
- 独立的 Cloud Scheduler 组件 (C) 将部署到每个项目中:应用 1 和应用 2。
- 将其余的自动扩缩器组件 (B) 部署到单独的项目中。
- 自动扩缩器工具使用每个项目中独立 Cloud Scheduler 组件发送的配置,自动扩缩应用 1 和 2 项目中的 Spanner 实例。
转发器函数
Cloud Scheduler 只能向同一项目中的主题发布消息,因此,对于分布式拓扑,需要使用一个名为转发器函数的中间组件。
转发器函数将消息从 Cloud Scheduler 中发布到 Pub/Sub,检查其 JSON 语法,然后将其转发到“轮询器 Pub/Sub”主题。该主题可以属于 Cloud Scheduler 的一个单独项目。
下图显示了用于转发机制的组件:
如上图所示,Spanner 实例位于名为应用 1 和应用 2 的项目中:
- Cloud Scheduler 与 Spanner 实例是同一项目。
(2a) Cloud Scheduler 会将其消息发布到应用 1 和应用 2 项目中的转发器主题。
(2b) 转发器函数从转发器主题中读取消息。
(2c) 转发器函数将消息转发到自动扩缩器项目中的轮询主题。
轮询器函数会从轮询主题中读取消息,然后继续执行该过程,如轮询器部分中所述。
分布式部署具有以下优势和缺点。
优点:
- 应用团队可控制配置和时间表:Cloud Scheduler 与要自动扩缩的 Spanner 实例一起部署,让应用团队更好地控制配置和调度。
- 运营团队控制基础架构:自动扩缩器工具的核心组件集中部署,为运营团队提供自动扩缩的基础架构。
- 集中式维护:扩缩器基础架构是集中式的,降低了开销。
缺点:
- 更复杂的配置:应用团队需要提供服务账号才能写入轮询主题。
- 可能会带来额外风险:即使基础架构在设计时考虑了高可用性,共享基础架构也可能成为单点故障。
如需了解如何使用分布式拓扑设置自动扩缩器,请参阅分布式部署分步指南。
后续步骤
- 了解如何将自动扩缩器工具部署到 GKE。
- 详细了解 Spanner 建议阈值。
- 详细了解 Spanner CPU 利用率指标和延迟时间指标。
- 了解 Spanner 架构设计的最佳实践,以避免热点并将数据加载到 Spanner。
- 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud 架构中心。