Google Cloud 架构框架提供了建议并介绍了最佳实践,以帮助架构师、开发者、管理员和其他云从业人员设计和运营安全、高效、弹性佳、高性能且经济实惠的云拓扑。 Google Cloud 架构框架是我们精心设计的框架版本。
Google 的跨职能专家团队会验证构成架构框架的设计建议和最佳实践。该团队精选架构框架,以反映 Google Cloud 的扩展技能、行业最佳实践、社区知识以及您提供的反馈。有关重大更改的摘要,请参阅新功能。
架构框架中的设计指导适用于专为云以及从本地迁移到 Google Cloud、混合云部署和多云环境的工作负载打造的应用。
Google Cloud 架构框架分为六类(也称为核心),如下图所示:
- 系统设计
- 此类别是 Google Cloud 架构框架的基础。定义满足云系统要求所需的架构、组件、模块、界面和数据,并了解支持系统设计的 Google Cloud 产品和功能。
- 卓越运营
- 高效地部署、运营、监控和管理您的云工作负载。
- 安全性、隐私权和合规性
- 最大限度地确保云数据和工作负载的安全性,在设计时确保隐私权,并遵守法规要求和行业标准。
- 可靠性
- 在云中设计和运行弹性佳且可用性高的工作负载。
- 费用优化
- 使您对 Google Cloud 的投资发挥最大业务价值。
- 性能优化
- 设计和调整云资源以获得最优性能。
如需查看 Google Cloud 产品摘要以及它们之间的关系,请参阅不超过四个词的 Google Cloud 产品、功能和服务简介。
Google Cloud 架构框架:系统设计
系统设计是 Google Cloud 架构框架的基础类别。此类别提供设计建议并描述最佳实践及相关原则,可帮助您定义云平台上的架构、组件、模块、接口和数据以满足系统要求。此外,您还将了解支持系统设计的 Google Cloud 产品和功能。
系统设计类别中的文档假定您了解基本的系统设计原则;不假定您熟悉云概念和 Google Cloud 产品。
对于复杂的云迁移和部署场景,建议您使用 Google Cloud 咨询服务。我们的顾问提供最佳实践和指导原则方面的专业知识,可帮助您在云之旅中取得成功。Google Cloud 还拥有强大的合作伙伴生态系统,从大型全球系统集成商到在机器学习等特定领域深度专业化的合作伙伴。我们建议您与 Google Cloud 合作伙伴合作,以加速数字化转型并改善业务成果。
在架构框架的系统设计类别中,您将了解如何执行以下操作:
- 应用系统设计的核心原则。
- 选择地理区域来支持您的业务应用。
- 管理云资源。
- 选择和管理计算。
- 设计网络基础架构。
- 选择和实现存储策略.
- 优化数据库。
- 分析您的数据。
- 实现机器学习。
- 设计云工作负载以实现可持续发展。
系统设计的核心原则
Google Cloud 架构框架中的文档介绍了系统设计的核心原则。强大的系统设计安全、可靠、可伸缩且独立。它可让您在不中断系统的情况下进行迭代和可撤消的更改,最大限度地降低潜在风险,并提高运营效率。为了实现强大的系统设计,我们建议您遵循四个核心原则。
记录所有要素
当您开始将工作负载迁移到云或构建应用时,取得成功的主要阻碍是缺少有关系统的文档。文档对于正确直观呈现当前部署的架构尤为重要。
适当进行文档说明的云架构可以设定通用语言和标准,使跨职能团队能够有效沟通和协作。此外,它还提供确定和指导未来设计决策所需的信息。文档应该根据您的用例编写,以便为设计决策提供具体情境。
设计决策会随着时间的推移而不断改进和变化。更改历史记录可提供您的团队调整计划、避免重复以及有效衡量性能随时间变化所需的情境。如果您是新入职的云架构师,尚不熟悉当前系统设计、策略或历史记录,则更新日志尤为有用。
简化设计并使用全代管式服务
简洁性对系统设计至关重要。如果您的架构过于复杂,难以理解,则随着时间的推移,将很难实现和管理设计。在可行的情况下,使用全代管式服务来最大限度地减少与管理和维护基准系统相关的风险、时间和工作量。
如果您已经在生产环境中运行工作负载,则使用代管式服务进行测试,以了解这些服务如何帮助降低运营复杂性。如果您要开发新的工作负载,请先从简单开始,开发最简可行产品 (MVP),并抵御过度工程的冲动。您可以确定异常的用例,反复迭代并随着时间的推移逐步改进系统。
分离您的架构
分离是一种用于将应用和服务组件分成可以独立运行的较小组件的技术。例如,您可以将单体式应用栈拆分为单独的服务组件。在分离式架构中,应用可以独立运行其功能,而无需考虑各种依赖项。
分离式架构可让您更加灵活地执行以下操作:
- 应用独立的升级。
- 实施特定的安全控制措施。
- 为每个子系统设定可靠性目标。
- 监控健康状况。
- 精细地控制性能和费用参数。
您可以在设计阶段的早期开始分离,或者在扩容时将其纳入系统升级。
使用无状态架构
无状态架构可以提高应用的可靠性和可伸缩性。
有状态应用依赖各种依赖项来执行任务,例如本地缓存的数据。有状态应用通常需要额外的机制来捕获进度并正常重启。无状态应用可以使用共享存储空间或缓存服务来执行任务,而无需大量本地依赖项。无状态架构使您的应用能够以最少的启动依赖项快速扩容。应用可以承受住硬重启,缩短停机时间,并为最终用户提供更好的性能。
系统设计类别介绍了使应用无状态或利用云原生功能来改善有状态应用的捕获机器状态的相关建议。
后续步骤
选择 Google Cloud 部署原型
Google Cloud 架构框架中的这篇文档介绍了六种部署原型1(可用区级、单区域级、多区域级、全球、混合和多云),您可以使用它们根据可用性、费用、性能和运营效率要求为您的云工作负载构建架构。
什么是部署原型?
部署原型是独立于提供商的抽象模型,您可以基于该模型构建可满足业务和技术要求的特定于应用的部署架构。每种部署原型都指定了可在其中运行应用的故障域的组合。这些故障域可以是一个或多个 Google Cloud 可用区或区域,并且可以进行扩展,以包含您的本地数据中心或其他云服务提供商中的故障域。
下图展示了在 Google Cloud 中部署的六个应用。每个应用都使用满足其特定要求的部署原型。
如上图所示,在使用混合或多云部署原型的架构中,云拓扑基于基本原型之一:可用区级、区域级、多区域级或全球。从这一点上讲,可以将混合和多云部署原型视为包含其中一种基本原型的复合部署原型。
选择部署原型有助于简化有关您应该使用的 Google Cloud 产品和功能的后续决策。例如,对于高可用性容器化应用,如果您选择区域级部署原型,则区域级 Google Kubernetes Engine (GKE) 集群比可用区级 GKE 集群更适合。
为应用选择部署原型时,您需要考虑可用性、费用和运营复杂性等因素之间的权衡取舍。例如,如果应用为多个国家/地区的用户提供服务并且需要高可用性,则您可以选择多区域级部署原型。但是,对于单个地理区域中的员工使用的内部应用,您可能会优先考虑费用而非可用性,因此选择区域级部署原型。
部署原型概览
以下标签页提供了部署原型的定义,并汇总了每种原型的应用场景和设计注意事项。
可用区级
您的应用在单个 Google Cloud 可用区中运行,如下图所示:
使用场景 |
|
---|---|
设计考虑事项 |
|
更多信息 | 请参阅以下各部分: |
单区域
您的应用在单个 Google Cloud 区域内的两个或多个可用区中独立运行,如下图所示:
使用场景 |
|
---|---|
设计考虑事项 |
|
更多信息 | 请参阅以下各部分: |
多区域级
您的应用在两个或多个 Google Cloud 区域之间的多个可用区中独立运行。您可以使用 DNS 路由政策将传入的流量路由到区域级负载均衡器。然后,区域级负载均衡器将流量分配到应用的可用区级副本,如下图所示:
使用场景 |
|
---|---|
设计考虑事项 |
|
更多信息 | 请参阅以下各部分: |
Global
您的应用以全球分布式(位置未知)栈或区域隔离式栈的形式在全球范围的 Google Cloud 区域中运行。全球任播负载均衡器会将流量分配到离用户最近的区域。应用栈的其他组件也可以是全球组件,例如数据库、缓存和对象存储。
下图展示了全球部署原型的全球分布式变体。全球任播负载均衡器会将请求转发到分布在多个区域并使用全球复制的数据库的应用栈。
下图展示了使用区域隔离式应用栈的全球部署原型的变体。全球任播负载均衡器会将请求转发到一个区域中的应用栈。所有应用栈都使用单个全球复制的数据库。
使用场景 |
|
---|---|
设计考虑事项 | 跨区域数据传输和数据复制的费用。 |
更多信息 | 请参阅以下各部分: |
混合
应用的某些部分部署在 Google Cloud 中,而其他部分在本地运行,如下图所示。Google Cloud 中的拓扑可以使用可用区级、区域级、多区域级或全球部署原型。
使用场景 |
|
---|---|
设计考虑事项 |
|
更多信息 | 请参阅以下各部分: |
多云端
应用的某些部分部署在 Google Cloud 中,其他部分部署在其他云平台中,如下图所示。每个云平台中的拓扑都可以使用可用区级、区域级、多区域级或全球部署原型。
使用场景 |
|
---|---|
设计考虑事项 |
|
更多信息 | 请参阅以下各部分: |
选择地理可用区和区域
Google Cloud 架构框架中的本文档提供了根据地理位置要求部署系统的最佳实践。您将了解如何根据可用性和邻近程度选择最佳的地理可用区和区域,以支持合规性、优化费用以及实施负载均衡。
为业务应用选择一个或多个区域时,请考虑服务可用性、最终用户延迟时间、应用延迟时间、费用以及监管或可持续要求等标准。为支持您的业务优先级和政策,请平衡这些要求并确定最佳权衡。例如,最合规的区域可能不是最具成本效益的区域,或者可能没有最低碳足迹。
部署到多个区域
地区是独立的地理位置,由多个区域组成。可用区是区域中 Google Cloud 资源的部署地区;每个可用区表示区域内的单个故障域。
为了防范预期的停机时间(包括维护)以及突发事件等意外停机时间,我们建议您部署具备高可用性的容错应用,然后跨一个或多个区域中的多个可用区部署应用。如需了解详情,请参阅地理位置和区域、应用部署考虑因素以及 Compute Engine 区域选择的最佳实践。
如果多区域部署因费用或其他考虑因素而受到限制,则多可用区部署可以提供弹性。此方法对于防止可用区或区域服务中断并解决灾难恢复和业务连续性问题尤其有用。如需了解详情,请参阅在设计时确保可伸缩性和高可用性。
根据地理邻近度选择区域
延迟会影响用户体验,还会影响向外部用户提供服务的相关费用。在向外部用户传送流量时,为了最大限度地缩短延迟时间,请选择与用户地理位置靠近并且服务能在其中以合规方式运行的一个或一组区域。如需了解详情,请参阅 Cloud 位置和合规性资源中心。
根据可用服务选择区域
根据您的业务所需的可用服务选择区域。大多数服务在所有区域中都提供。一些特定于企业的服务可能在提供其初始版本的部分区域中提供。如需验证区域选择,请参阅 Cloud 位置。
选择区域以支持合规性
选择一个或一组特定的区域来符合需要使用特定地理位置的地理法规或合规性法规,例如一般数据保护条例 (GDPR) 或数据驻留。如需详细了解如何设计安全系统,请参阅合规性产品以及 Google Cloud 欧洲客户的数据驻留、运维透明度和隐私权。
比较主要资源的价格
同一种服务在不同区域的费率有所不同。请比较您计划使用的主要资源在各个区域的价格,从而找出性价比最高的区域。费用考虑因素会因备份要求和资源(例如计算、网络和数据存储)而异。如需了解详情,请参阅费用优化类别。
使用 Cloud Load Balancing 为全球用户提供服务
如需在为全球用户提供服务时改善用户体验,请使用 Cloud Load Balancing 来帮助提供路由到应用的单个 IP 地址。如需详细了解如何设计可靠的系统,请参阅《Google Cloud 架构框架:可靠性》。
使用 Cloud 区域选择器支持可持续发展
Google 自 2007 年起一直符合碳中和标准,并承诺在 2030 年实现无碳目标。如需按碳足迹选择区域,请使用 Google Cloud 区域选择器。如需详细了解如何针对可持续发展进行设计,请参阅云可持续发展。
后续步骤
了解如何使用 Resource Manager、Google Cloud 资源层次结构和组织政策服务管理云资源。
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
管理云资源
本文档是 Google Cloud 架构框架的一部分,介绍了在 Google Cloud 中整理和管理资源的最佳实践。
资源层次结构
Google Cloud 资源以分层方式整理到组织、文件夹和项目中。这种层次结构让您能够管理资源的常见方面,例如访问权限控制、配置设置和政策。如需了解设计云资源层次结构的最佳实践,请参阅确定 Google Cloud 着陆区的资源层次结构。
资源标签和标记
本部分提供了使用标签和标记组织 Google Cloud 资源的最佳实践。
使用简单的文件夹结构
文件夹可让您在分组时随意组合项目和子文件夹。创建一个简单的文件夹结构来整理 Google Cloud 资源。您可以根据需要添加更多层级,以便定义能够满足业务需求的资源层次结构。文件夹结构灵活且可扩展。如需了解详情,请参阅创建和管理文件夹。
使用文件夹和项目来体现数据治理政策
使用文件夹、子文件夹和项目将各种资源分隔开来,以反映组织内的数据治理策略。例如,您可以使用文件夹和项目的组合来分隔财务、人力资源和工程领域的资源。
使用项目对共享相同信任边界的资源进行分组。例如,同一产品或微服务的资源可以属于同一个项目。如需了解详情,请参阅确定 Google Cloud 着陆区的资源层次结构。
在项目开始时使用标记和标签
当您开始使用 Google Cloud 产品时,请使用标签和标记,即使您不立即需要它们。之后添加标签和标记可能需要手动操作,而此操作可能容易出错且难以完成。
标记提供了一种有条件地允许或拒绝政策的方法,具体取决于资源是否具有特定的标记。标签是一种键值对,可帮助您组织 Google Cloud 实例。如需详细了解标签,请参阅标签要求、支持标签的服务列表和标签格式。
Resource Manager 可提供标签和标记,以帮助您管理资源、分配和报告费用,以及向不同资源分配政策,构建精细的访问权限控制机制。例如,您可以使用标签和标记将精细的访问权限和管理原则应用于不同的租户资源和服务。如需了解虚拟机标签和网络标记,请参阅虚拟机标签和网络标记之间的关系。
您可以将标签用于多种用途,包括:
- 管理资源结算:标签在结算系统中可用,可让您按标签划分费用。例如,您可以为不同的成本中心或预算添加标签。
- 按类似特征或关系对资源进行分组:您可以使用标签来分离不同的应用生命周期阶段或环境。例如,您可以为生产、开发和测试环境添加标签。
分配标签以支持费用和结算报告
如需基于集成的报告结构之外的特性(例如按项目或按产品的类型)支持精细费用和结算报告,请为资源分配标签。标签可帮助您将使用量分配给成本中心、部门、特定项目或内部充值机制。如需了解详情,请参阅费用优化类别。
避免创建大量标签
避免创建大量标签。我们建议您主要在项目级层创建标签,并避免在子团队级层创建标签。如果您创建的标签过于精细,可能会给分析增加噪声。如需了解标签的常见使用场景,请参阅标签的常见用途。
避免在标签中添加敏感信息
标签设计不宜用于处理敏感信息。请勿在标签中添加敏感信息,包括个人身份信息,例如个人姓名或头衔。
对项目名称中的信息进行匿名处理
遵循项目命名模式(例如 COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME
),其中占位符是唯一的,并且不会显示公司或应用名称。请勿包含将来可能会更改的特性,例如团队名称或技术。
应用标记以构建业务维度模型
您可以使用标记来为更多业务维度构建模型,例如组织结构、区域、工作负载类型或成本中心。如需详细了解标记,请参阅标记概览、标记继承和创建和管理标记。如需了解如何在政策中使用标记,请参阅政策和标记。如需了解如何使用标记来管理访问权限控制,请参阅标记和访问权限控制。
组织政策
本部分介绍了在云资源层次结构中配置 Google Cloud 资源治理规则的最佳实践。
建立项目命名惯例
建立标准化项目命名惯例,例如 SYSTEM_NAME-ENVIRONMENT
(dev
, test
, uat
, stage
, prod
)。
项目名称长度不得超过 30 个字符。
虽然您可以应用类似 COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG
的前缀,但公司进行重组时,项目名称可能会过期。请考虑将可识别的名称从项目名称移至项目标签。
自动创建项目
如需为生产环境或大型企业创建项目,请使用自动化流程,例如 Deployment Manager 或 Google Cloud 项目工厂 Terraform 模块。这些工具会执行以下操作:
- 自动创建具有适当权限的开发、测试和生产环境或者项目。
- 配置日志记录和监控。
Google Cloud 项目工厂 Terraform 模块可帮助您自动创建 Google Cloud 项目。在大型企业中,我们建议您先审核和批准项目,然后再在 Google Cloud 中创建项目。此过程有助于确保实现以下目标:
- 费用可以归因。如需了解详情,请参阅费用优化类别。
- 对数据上传进行审批。
- 满足监管或合规性要求。
如果您自动创建和管理 Google Cloud 项目和资源,您将获得一致性、可再现性和可测试性等好处。通过将配置视为代码,您可以将配置和软件工件的生命周期一起进行版本控制和管理。借助自动化功能,您可以支持诸如一致的命名惯例以及为资源添加标签等最佳实践。随着需求的变化,自动化功能可以简化项目重构。
定期审核系统
为确保可以审核和批准新项目的请求,请与企业的工单系统或提供审核的独立系统集成。
采用一致的方式配置项目
配置项目以采用一致的方式满足组织的需求。设置项目时,请包含以下内容:
- 项目 ID 和命名惯例
- 结算账号关联
- 网络配置
- 已启用的 API 和服务
- Compute Engine 访问权限配置
- 日志导出和使用情况报告
- 项目移除安全锁
分离和隔离工作负载或环境
在项目层级实施配额和限制。如需管理配额和限制,请在项目层级分离和隔离工作负载或环境。如需了解详情,请参阅处理配额。
分离环境与数据分类要求不同。将数据与基础架构分离可能费用高昂且实施起来很复杂,因此我们建议您根据数据敏感性和合规性要求实现数据分类。
实施结算隔离
实施结算隔离,以支持不同的结算账号以及每个工作负载和环境的费用可见性。如需了解详情,请参阅创建、修改或关闭自助 Cloud Billing 账号,以及启用、停用或更改项目的结算功能。
为了最大限度地降低管理复杂性,请为项目级层的关键环境或分布在多个项目中的工作负载使用精细的访问权限管理控制。在为关键生产应用精选访问权限控制时,请确保工作负载得到有效保护和管理。
使用组织政策服务来控制资源
组织政策服务让政策管理员可通过程序化方式对组织的云资源进行集中控制,这样他们就能跨资源层次结构配置约束。如需了解详情,请参阅添加组织政策管理员。
使用组织政策服务以遵守监管政策
为满足法规遵从要求,可以使用组织政策服务来实施资源共享和访问方面的合规性要求。例如,您可以限制与外部各方的共享,或确定在哪个地理位置部署云资源。其他合规性场景包括:
- 集中控制以配置定义组织资源的使用方式的限制。
- 定义和制定政策以帮助开发团队保持在合规性边界内。
- 帮助项目所有者及其团队更改系统,同时保持合规性,以及最大限度地减少违反合规性要求的问题。
根据网域限制资源共享
受限共享组织政策可帮助您防止与组织外部的身份共享 Google Cloud 资源。如需了解详情,请参阅按网域限制身份和组织政策限制条件。
停用服务账号和密钥创建功能
为了帮助提高安全性,请限制 Identity and Access Management (IAM) 服务账号和相应密钥的使用。如需了解详情,请参阅限制服务账号的使用。
限制新资源的物理位置
通过限制资源位置来限制新创建的资源的物理位置。如需查看让您能够控制组织资源的限制条件的列表,请参阅组织政策服务限制条件。
后续步骤
了解如何选择和管理计算,其中包括:
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
选择和管理计算
Google Cloud 架构框架中的本文档提供了根据计算要求部署系统的最佳实践。您将了解如何选择计算平台和迁移方法、设计和扩缩工作负载,以及管理运营和虚拟机迁移。
计算无论是指执行自定义业务逻辑还是针对数据集应用复杂的计算算法,它都是许多工作负载的核心。大多数解决方案都会以某种形式使用计算资源,因此您可以根据应用的需求选择合适的计算资源。
Google Cloud 提供了多种在 CPU 上使用时间的选项。具体选项取决于 CPU 类型、性能以及代码的计划运行方式,包括用量结算。
Google Cloud 计算选项包括:
- 可提供云独有优势(例如实时迁移)的虚拟机。
- 对可以共享 CPU 的集群机器上的容器进行装箱。
- 函数和无服务器方法,可让您为单个 HTTP 请求期间执行的工作计量 CPU 使用时间。
选择计算
本部分提供了选择和迁移到计算平台的最佳实践。
选择计算平台
为工作负载选择计算平台时,请考虑工作负载的技术要求、生命周期自动化过程、区域化和安全性。
评估您的应用和整个支持系统的 CPU 使用量性质,包括如何打包、部署、分发和调用代码。虽然某些使用场景可能与多个平台选项兼容,但可移植的工作负载应该能够利用一系列计算选项且性能出色。
下表简要介绍了推荐用于各种应用场景的 Google Cloud 计算服务:
计算平台 | 使用场景 | 推荐产品 |
---|---|---|
无服务器 |
|
|
Kubernetes | 构建需要额外服务(例如 Istio)来管理服务网格控制的复杂微服务架构。 |
|
虚拟机 | 根据支持您的应用和工作负载要求以及第三方软件和服务的预定义和可自定义的虚拟机系列来创建和运行虚拟机。 |
如需根据您的要求选择合适的机器类型,请参阅机器系列的建议。 |
如需了解详情,请参阅选择计算选项。
选择计算迁移方法
如果要从其他云或本地迁移现有应用,请使用以下某个 Google Cloud 产品来优化性能、规模、费用和安全。
迁移目标 | 使用场景 | 推荐产品 |
---|---|---|
直接原样迁移 | 只需几分钟即可将 VMware 工作负载迁移或扩展到 Google Cloud。 | Google Cloud VMware Engine |
直接原样迁移 | 将基于虚拟机的应用迁移到 Compute Engine。 | Migrate to Virtual Machines |
升级为容器 | 将传统应用进行现代化改造,以改造为 Google Kubernetes Engine 的内置容器。 | Migrate to Containers |
如需了解如何迁移工作负载并协调内部团队,请参阅 VM Migration 生命周期和使用 Google Cloud 构建大规模迁移项目。
设计工作负载
本部分提供了设计工作负载以支持您的系统的最佳实践。
评估无服务器方案是否适用于简单逻辑
简单逻辑是一种计算类型,不需要专业化硬件或 CPU 经过优化的机器等机器类型。在对 Google Kubernetes Engine (GKE) 或 Compute Engine 实现进行投资以抽象化运营开销并针对费用和性能进行优化之前,请先评估无服务器方案是否适用于轻量级逻辑。
将应用分离为无状态应用
尽可能将应用分离为无状态应用,以便充分利用无服务器计算选项。此方法可让您使用代管式计算产品、根据需求扩缩应用,以及针对费用和性能进行优化。如需详细了解如何分离应用以便在设计时确保可扩缩性和高可用性,请参阅在设计时确保可扩缩性和高可用性。
在分离架构时使用缓存逻辑
如果您的应用旨在成为有状态应用,请使用缓存逻辑进行分离并确保工作负载可以扩缩。如需了解详情,请参阅数据库最佳实践。
使用实时迁移推动升级
为方便 Google 维护升级,请设置实例可用性政策以使用实时迁移。如需了解详情,请参阅设置虚拟机主机维护政策。
扩缩工作负载
本部分提供了扩缩工作负载以支持您的系统的最佳实践。
使用启动和关停脚本
对于有状态应用,请尽可能使用启动和关停脚本安全启动和停止应用状态。安全启动是指通过软件功能启用计算机,并且操作系统可以执行其安全启动过程和打开连接的任务。
安全启动和关停非常重要,因为有状态应用依赖于靠近计算(通常位于本地磁盘或永久性磁盘上,或者位于 RAM 中)的即时可用的数据。为避免每次启动时都要从头开始运行应用数据,请使用启动脚本重新加载上次保存的数据,并从关停时停止的位置运行流程。如需保存应用内存状态以避免因关停而导致进度丢失,请使用关停脚本。例如,因缩减或 Google 维护事件而计划关停虚拟机时,请使用关停脚本。
使用 MIG 支持虚拟机管理
当您使用 Compute Engine 虚拟机时,代管式实例组 (MIG) 支持自动修复、负载均衡、自动扩缩、自动更新和有状态工作负载等功能。您可以根据可用性目标创建可用区级或区域级 MIG。您可以对无状态服务工作负载或批量工作负载以及需要保留每个虚拟机独有状态的有状态应用使用 MIG。
使用 Pod 自动扩缩器扩缩 GKE 工作负载
使用 Pod 横向自动扩缩器和 Pod 纵向自动扩缩器来扩缩工作负载,并使用节点自动预配功能来扩缩底层计算资源。
分发应用流量
如需在全球范围内扩缩您的应用,请使用 Cloud Load Balancing 跨多个区域或可用区分发应用实例。负载均衡器可优化从 Google Cloud 边缘网络到最近可用区的数据包路由,从而提高流量传送效率并将传送费用降至最低。如需对最终用户延迟时间进行优化,请尽可能使用 Cloud CDN 来缓存静态内容。
实现计算创建和管理自动化
通过自动执行计算创建和管理,最大限度地减少生产环境中发生的人为错误。
管理运营
本部分提供管理运营以支持您的系统的最佳实践。
使用 Google 提供的公共映像
使用 Google Cloud 提供的公共映像。Google Cloud 公共映像会定期更新。如需了解详情,请参阅 Compute Engine 上的可用公共映像列表。
您还可以使用特定配置和设置创建自己的映像。请尽可能在您可以与组织中已获授权的用户共享的单独项目中自动执行和集中管理映像创建。通过在单独的项目中创建并精选自定义映像,您可以使用自己的配置更新、修补和创建虚拟机。然后,您可以与相关项目共享精选虚拟机映像。
使用快照进行实例备份
您可以通过快照为实例创建备份。快照特别适合用于有状态应用,有状态应用不够灵活,在遭受突然关停时无法保留状态或保存进度。如果您经常使用快照创建新实例,则可以通过该快照创建基础映像来优化备份过程。
使用机器映像可创建虚拟机实例
虽然快照只会捕获机器内部的数据映像,但机器映像除了捕获数据之外,还会捕获机器配置和设置。使用机器映像可以存储创建虚拟机实例所需的一个或多个磁盘的所有配置、元数据、权限和数据。
通过快照创建机器时,您必须在新的虚拟机实例上配置实例设置,这需要付出大量努力。使用机器映像可让您将这些已知设置复制到新机器,从而减少开销。如需了解详情,请参阅何时使用机器映像。
容量、预留和隔离
本部分介绍管理容量、预留和隔离以支持您的系统的最佳实践。
使用承诺使用折扣减少费用
您可以使用承诺使用折扣,降低始终处于开启状态的工作负载的运营支出 (OPEX) 费用。如需了解详情,请参阅费用优化类别。
选择机器类型以支持费用和性能
Google Cloud 提供多种机器类型,可让您根据费用和性能参数选择计算。您可以选择性能不佳的产品以针对费用进行优化,也可以选择费用更高的高性能计算选项。如需了解详情,请参阅费用优化类别。
使用单租户节点以满足合规性需求
单租户节点是专门用于仅托管您的项目虚拟机实例的物理 Compute Engine 服务器。单租户节点可帮助您满足物理隔离的合规性要求,包括:
- 将您的虚拟机与其他项目中的虚拟机进行物理隔离。
- 将您的虚拟机汇集到同一主机硬件上。
- 隔离付款处理工作负载。
如需了解详情,请参阅单租户节点。
使用预留确保资源可用性
Google Cloud 允许您为工作负载定义预留,以确保这些资源始终可用。创建预留不会产生额外费用,但即使不使用预留资源,您也需要支付费用。如需了解详情,请参阅使用和管理预留。
虚拟机迁移
本部分提供了迁移虚拟机以支持您的系统的最佳实践。
评估内置迁移工具
评估内置的迁移工具,以便将工作负载从其他云平台或本地环境迁移。如需了解详情,请参阅迁移到 Google Cloud。Google Cloud 提供了多种工具和服务来帮助您迁移工作负载并优化费用和性能。如需获得基于您当前的 IT 环境的免费迁移费用评估,请参阅 Google Cloud Rapid Assessment & Migration Program。
使用导入虚拟磁盘以导入自定义的操作系统
如需导入自定义的受支持操作系统,请参阅导入虚拟磁盘。单租户节点可帮助您满足按核心许可或按处理器许可的硬件自带许可要求。如需了解详情,请参阅自带许可。
建议
如需将架构框架中的指导应用到您自己的环境,建议您执行以下操作:
查看 Google Cloud Marketplace 产品,以评估您的应用是否列在受支持的供应商下。Google Cloud 支持运行各种开源系统和各种第三方软件。
请考虑使用 Migrate to Containers and GKE 来提取基于虚拟机的应用并其封装为 GKE 上运行的容器化应用。
使用 Compute Engine 在 Google Cloud 上运行应用。如果您有旧版依赖项在基于虚拟机的应用中运行,请验证它们是否满足供应商要求。
对使用 Google Cloud 内部直通式网络负载均衡器来扩缩分离式架构进行评估。如需了解详情,请参阅内部直通式网络负载均衡器概览。
评估用于从传统本地使用场景(例如 HA-Proxy 使用情况)切换的选项。如需了解详细信息,请参阅浮动 IP 地址的最佳实践。
使用虚拟机管理器管理 Compute Engine 上运行 Windows 或 Linux 的大型虚拟机机群的操作系统,并应用一致的配置政策。
请考虑使用 GKE Autopilot,并让 Google SRE 完全代管您的集群。
使用 Policy Controller 和 Config Sync 在 GKE 集群中进行政策和配置管理。
确保机器在特定区域和可用域的可用性和可扩缩性。Google Cloud 可以扩缩以满足您的计算需求。但是,如果您需要某个特定区域或可用区具有大量特定机器类型,请与您的客户支持团队合作以确保可用性。如需了解详情,请参阅 Compute Engine 的预留。
后续步骤
了解网络设计原则,包括以下各项:
设计工作负载 VPC 架构。
设计 VPC 间的连接。
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
设计网络基础架构
本文档是Google Cloud 架构框架的一部分,提供了根据网络设计部署系统的最佳实践。您将了解如何选择和实现 Virtual Private Cloud (VPC),以及如何测试和管理网络安全。
核心原则
网络设计对成功的系统设计至关重要,因为它可以帮助您优化性能,并确保应用与内部和外部服务通信的安全。当您选择网络服务时,请务必评估应用需求并评估应用之间的通信方式。例如,某些组件需要全球服务,而其他组件可能需要位于特定区域。
Google 的专用网络将区域位置连接到 100 多个全球网络接入点。Google Cloud 采用了软件定义网络和分布式系统技术在全球范围内托管和提供服务。Google Cloud 中的 Google 网络核心元素是全球 VPC。VPC 使用 Google 的全球高速网络跨区域连接您的应用,同时支持隐私性和可靠性。Google 可通过使用瓶颈带宽和往返传播时间 (BBR) 等技术来确保内容以高吞吐量传送。
部署云网络设计包括以下步骤:
- 设计工作负载 VPC 架构。首先确定需要多少 Google Cloud 项目和 VPC 网络。
- 添加 VPC 间连接。 设计如何将您的工作负载连接到不同 VPC 网络中的其他工作负载。
- 设计混合网络连接。 设计如何将您的工作负载 VPC 连接到本地和其他云环境。
设计您的 Google Cloud 网络时,请考虑以下事项:
- VPC 可在云中提供私有网络环境,用于将基于 Compute Engine、Google Kubernetes Engine (GKE) 和无服务器计算解决方案构建的服务相互连接起来。您还可以使用 VPC 以私密方式访问 Google 管理的服务,例如 Cloud Storage、BigQuery 和 Cloud SQL。
- VPC 网络(包括其关联的路由和防火墙规则)属于全球性资源;它们与任何特定区域或可用区均无关联。
- 子网属于区域级资源。在同一云区域中的不同可用区部署的 Compute Engine 虚拟机实例可以使用同一子网中的 IP 地址。
- 进出实例的流量可以通过 VPC 防火墙规则来控制。
- 可以使用 Identity and Access Management (IAM) 角色来保护网络管理。
- 可以使用 Cloud VPN 或 Cloud Interconnect 在混合环境中安全连接 VPC 网络。
如需查看 VPC 规范的完整列表,请参阅规范。
工作负载 VPC 架构
本部分提供了设计工作负载 VPC 架构以支持您的系统的最佳实践。
提早考虑 VPC 网络设计事宜
在 Google Cloud 中设计组织设置时,提早进行 VPC 网络设计。组织级层的设计选择在流程后期无法轻易撤消。如需了解详情,请参阅 VPC 设计的最佳实践和参考架构以及确定 Google Cloud 着陆区的网络设计。
从单个 VPC 网络开始
如果有许多用例包含具有相同要求的资源,那么可以使用单个 VPC 网络提供所需的功能。单个 VPC 网络易于创建、维护和理解。如需了解详情,请参阅 VPC 网络规范。
简化 VPC 网络拓扑
为了确保架构可靠而且易于管理和理解,请使用简单易行的 VPC 网络拓扑设计。
在自定义模式下使用 VPC 网络
为确保 Google Cloud 网络能与您现有的网络系统无缝集成,我们建议您使用自定义模式来创建 VPC 网络。使用自定义模式有助于您将 Google Cloud 网络集成到现有 IP 地址管理方案中,让您能够控制 VPC 中包含哪些云区域。如需了解详情,请参阅 VPC。
VPC 间连接
本部分提供设计 VPC 间连接以支持您的系统的最佳实践。
选择 VPC 连接方法
如果您决定实现多个 VPC 网络,那么您需要将这些网络连接起来。VPC 网络是 Google Andromeda 软件定义网络 (SDN) 内的独立租户空间。不同 VPC 网络可通过多种方式相互通信。请根据您的带宽、延迟和服务等级协议 (SLA) 要求选择网络的连接方式。如需详细了解连接选项,请参阅选择满足您的费用、性能和安全性需求的 VPC 连接方法。
使用共享 VPC 来管理多个工作组
对具有多个团队的组织来说,共享 VPC 可以有效简化单个 VPC 网络在多个工作组之间的架构。
使用简单的命名惯例
选用简单、直观且一致的命名惯例。这样做有助于管理员和用户了解各个资源的用途、位置以及与其他资源的区别。
使用 Connectivity Tests 验证网络安全性
在网络安全性方面,您可以使用 Connectivity Tests 来验证两个端点之间的流量是否按照您的预期被阻止。要验证流量是否被阻止并了解被阻止的原因,请在两个端点之间定义一个测试并评估结果。例如,您可以测试一个 VPC 功能,该功能使您可以定义支持阻止流量的规则。如需了解详情,请参阅 Connectivity Tests 概览。
使用 Private Service Connect 创建专用端点
如需创建可让您使用自己的 IP 地址方案访问 Google 服务的专用端点,请使用 Private Service Connect。您可以从 VPC 内部以及通过在 VPC 中终止的混合连接来访问专用端点。
保护和限制外部连接
将互联网访问权限仅授予那些需要该权限的资源。仅具有专用内部 IP 地址的资源仍然可以通过专用 Google 访问通道来访问多个 Google API 和服务。
使用 Network Intelligence Center 监控云网络
Network Intelligence Center 可让您全面了解所有区域中的 Google Cloud 网络。它可以帮助您识别可能导致运营或安全风险的流量和访问模式。
后续步骤
了解存储空间管理的最佳实践,包括:
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
选择并实施存储策略
Google Cloud 架构框架中的本文档提供了基于存储空间部署系统的最佳实践。您将了解如何选择存储策略以及如何管理存储空间、访问模式和工作负载。
为促进数据交换并以安全方式备份和存储数据,组织需要根据工作负载(即每秒输入/输出操作次数 (IOPS))、延迟时间、检索频率、位置、容量和格式(块、文件和对象)选择存储方案。
Cloud Storage 提供安全可靠的对象存储服务,具体包括:
- 内置冗余选项,可保护您的数据免受设备故障的影响,并确保在数据中心维护期间的数据可用性。
- 数据转移选项,具体包括:
- 存储类别,可支持您的工作负载。
- 针对所有可让 Google 验证读取和写入的 Cloud Storage 操作计算得出的校验和。
在 Google Cloud 中,IOPS 会根据您预配的存储空间进行扩缩。Persistent Disk 等存储类型需要手动进行复制和备份,因为它们是区域级或可用区级的存储类型。相比之下,对象存储具备高可用性,并且会自动跨单个区域或多个区域复制数据。
存储类型
本部分提供了选择存储类型以支持您的系统的最佳实践。
评估高性能存储需求的选项
评估永久性磁盘或本地固态硬盘 (SSD) 是否适用于需要高性能存储的计算应用。Cloud Storage 是启用了版本控制的不可变对象存储。将 Cloud Storage 与 Cloud CDN 搭配使用有助于针对费用进行优化,尤其是对于经常访问的静态对象而言。
Filestore 支持需要高性能共享空间的多写入应用。Filestore 还支持需要通过网络文件系统 (NFS) 装载执行类似 POSIX 的文件操作的旧版和现代化应用。
Cloud Storage 可为创建数据湖和满足归档要求等使用场景提供支持。由于存在访问费用和检索费用,请根据您选择 Cloud Storage 类别的方式来制定权衡决策,尤其是在配置保留政策时。如需了解详情,请参阅为云工作负载设计最佳存储策略。
默认情况下,所有存储选项都使用 Google 管理的密钥进行静态加密和传输中加密。对于 Persistent Disk 和 Cloud Storage 等存储类型,您可以提供自己的密钥或通过 Cloud Key Management Service (Cloud KMS) 进行管理。请先制定处理此类密钥的策略,再将其运用于生产数据。
选择 Google Cloud 服务以支持存储设计
如需了解支持存储设计的 Google Cloud 服务,请参阅下表:
Google Cloud 服务 | 说明 |
---|---|
Cloud Storage | 可以在全球范围内随时存储和检索任意数量的数据。您可以在多个场景中使用 Cloud Storage,包括传送网站内容、存储数据以用于归档和灾难恢复,或者通过直接下载向用户分发大型数据对象。 如需了解详情,请参阅以下内容: |
Persistent Disk | 用于 Google Cloud 的高性能块存储。Persistent Disk 提供 SSD 和硬盘 (HDD) 存储设备,您可以将其挂接到 Compute Engine 或 Google Kubernetes Engine (GKE) 中运行的实例。 |
Filestore | 一项代管式文件存储服务,适合那些需要使用文件系统接口和共享文件系统来存储数据的应用。Filestore 为用户带来了无缝体验,让用户能够为其 Compute Engine 和 Kubernetes Engine 实例建立代管式网络附加存储 (NAS) 空间。 |
Cloud Storage for Firebase | 专为需要存储和提供用户生成的内容(如照片或视频)的应用开发者而打造的。您的所有文件都存储在 Cloud Storage 存储桶中,因此可从 Firebase 和 Google Cloud 进行访问。 |
选择存储策略
如需选择符合您的应用要求的存储策略,请参阅下表:
使用场景 | 建议 |
---|---|
您希望以最低费用大规模存储数据,而不考虑访问性能。 | Cloud Storage |
您正在运行需要短期存储的计算应用。 如需了解详情,请参阅优化 Persistent Disk 和本地 SSD 性能。 |
Persistent Disk 或本地 SSD |
您正在运行需要共享空间的读写权限的高性能工作负载。 | Filestore |
您拥有高性能计算 (HPC) 或高吞吐量计算 (HTC) 使用场景。 | 使用集群在云中进行大规模技术计算 |
根据存储访问需求选择活跃存储或归档存储
存储类别是每个对象使用的一段元数据。对于按照高速率和高可用性标准传送的数据,请使用 Standard Storage 存储类别。对于不经常访问且接受略低可用性的数据,请使用 Nearline Storage、Coldline Storage 或 Archive Storage 存储类别。如需详细了解选择存储类别的费用注意事项,请参阅 Cloud Storage 价格。
评估 Cloud Storage 的存储位置和数据保护需求
对于位于某个区域的 Cloud Storage 存储桶,其中包含的数据会自动在该区域内的各可用区中复制。跨可用区的数据复制功能可在区域内出现可用区性故障时保护数据。
Cloud Storage 还提供跨区域冗余的位置,这意味着数据会复制到分布在多个地理位置不同的数据中心。如需了解详情,请参阅存储桶位置。
使用 Cloud CDN 改进静态对象传送
如需优化检索对象的费用并将访问延迟时间缩至最短,请使用 Cloud CDN。Cloud CDN 使用 Cloud Load Balancing 外部应用负载均衡器来提供路由、健康检查和任播 IP 地址支持。如需了解详情,请参阅使用云存储桶设置 Cloud CDN。
存储访问模式和工作负载类型
本部分提供了选择存储访问模式和工作负载类型以支持您的系统的最佳实践。
使用 Persistent Disk 以支持高性能存储访问
数据访问模式取决于您设计系统性能的方式。Cloud Storage 提供可扩缩的存储空间,但是,当您运行需要以高吞吐量方式访问大量数据的繁重计算工作负载时,这并不是理想的选择。如需实现高性能存储访问,请使用 Persistent Disk。
在实现重试逻辑时使用指数退避算法
在实现重试逻辑时使用指数退避算法来处理 5XX、408 和 429 错误。每个 Cloud Storage 存储桶都预配了初始 I/O 容量。如需了解详情,请参阅请求率和访问权限分配准则。规划重试请求的渐增模式。
存储管理
本部分提供了用于存储管理以支持您的系统的最佳实践。
为每个存储桶分配唯一名称
使每个存储桶名称在整个 Cloud Storage 命名空间中保持唯一。请勿在存储桶名称中包含敏感信息。选择难以猜测的存储桶和对象名称。如需了解详情,请参阅存储桶命名准则和对象命名准则。
不公开 Cloud Storage 存储桶
除非存在与业务相关的理由,否则请确保您的 Cloud Storage 存储桶不能以匿名方式访问或公开访问。如需了解详情,请参阅访问权限控制概览。
分配随机对象名称以均匀分配负载
分配随机对象名称以提高性能并避免出现 hotspotting 问题。尽可能针对各对象使用随机前缀。如需了解详情,请参阅借助命名惯例将负载均匀分配到多个键范围中。
使用禁止公开访问功能
如需阻止在组织级层、文件夹级层、项目级层或存储桶级层访问,请使用禁止公开访问功能。如需了解详情,请参阅使用禁止公开访问功能。
后续步骤
了解 Google Cloud 数据库服务和最佳实践,包括:
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
优化数据库
Google Cloud 架构框架中的本文档提供了根据数据库设计部署系统的最佳实践。您将学习如何设计、迁移和扩缩数据库、加密数据库信息、管理许可以及监控数据库中的事件。
关键服务
本文档在架构框架系统设计类别中提供了包含各种 Google Cloud 数据库服务的最佳实践。下表简要介绍了这些服务:
Google Cloud 服务 | 说明 |
---|---|
Cloud SQL | 一项全代管式数据库服务,可让您设置、维护、管理和控制使用 Cloud SQL for PostgreSQL、Cloud SQL for MySQL 和 Cloud SQL for SQL Server 的关系型数据库。Cloud SQL 可提供出色的性能和扩容潜力。它托管在 Google Cloud 上,能为在任何地方运行的应用提供数据库基础架构。 |
Bigtable | 可以扩展到数十亿行和数千列的表,让您能够存储 TB 级甚至是 PB 级的数据。每行中都会有一个被编入索引的值;这个值称为行键。使用 Bigtable 以极短的延迟时间存储大量单键数据。它可以低延迟地支持高读写吞吐量,是 MapReduce 操作的数据源。 |
Spanner | 专为云端打造的一款可扩缩的全球分布式企业数据库服务,融合了关系型数据库结构与非关系型数据库横向扩容能力的优势。这种优势上的融合可以跨行、跨区域、跨洲实现高性能事务和强一致性。Spanner 提供可用性高达 99.999% 的服务等级协议 (SLA),它没有计划内停机时间,同时拥有企业级安全性。 |
Memorystore | 一项适用于 Google Cloud 的全代管式 Redis 服务。在 Google Cloud 上运行的应用可以使用高度可用、可扩缩的安全 Redis 服务来提高性能,而无需管理复杂的 Redis 部署。 |
Firestore | 一个 NoSQL 文档数据库,能够自动扩缩、具备出色的性能,并且易于进行应用开发。虽然 Firestore 界面具有许多与传统数据库相同的功能,但它是 NoSQL 数据库,它与传统数据库在描述数据对象间关系的方式方面有所不同。 |
Firebase Realtime Database | 托管在云中的数据库。Firebase 以 JSON 格式存储数据,并实时同步到每个连接的客户端。当您使用 Google、iOS、Android 和 JavaScript SDK 构建跨平台应用时,所有的客户端共享一个实时数据库实例,并自动接收包含最新数据的更新。 |
开源数据库 | Google 合作伙伴提供不同的开源数据库,其中包括 MongoDB、MariaDB 和 Redis。 |
AlloyDB for PostgreSQL | 与 PostgreSQL 兼容的全代管式数据库服务,适用于要求苛刻的企业工作负载。与标准 PostgreSQL 相比,处理事务性工作负载的速度快至 4 倍,运行分析型查询的速度快至 100 倍。AlloyDB for PostgreSQL 利用支持机器学习的 Autopilot 系统简化了管理。 |
选择数据库
本部分提供选择数据库以支持您的系统的最佳实践。
考虑使用代管式数据库服务
在安装您自己的数据库或数据库集群之前,请先评估 Google Cloud 代管式数据库服务。安装自己的数据库涉及维护开销,包括安装补丁程序和更新以及管理每日运营活动,例如监控和执行备份。
使用正常运行和无法正常运行的应用要求来推动数据库选择。考虑短延迟时间访问、时间序列数据处理、灾难恢复和移动客户端同步。
如需迁移数据库,请使用下表中描述的某款产品:
数据库迁移产品 | 说明 |
---|---|
Cloud SQL | 一项区域服务,支持远程区域中的读取副本、短延迟时间读取和灾难恢复。 |
Spanner | 一款多区域产品,提供外部一致性、全球复制和可用性高达 99.999% 的服务等级协议 (SLA)。 |
Bigtable | 一项全代管式可扩缩的 NoSQL 数据库服务,用于处理大规模分析和运营工作负载,可用性达 99.999%。 |
Memorystore | 一项全代管式数据库服务,提供了两种常用的代管版开源缓存解决方案:Redis 和 Memcached。 |
Firebase Realtime Database | Firebase Realtime Database 是一种托管在云中的 NoSQL 数据库,可让您实时存储和同步用户数据。 |
Firestore | 一个 NoSQL 文档数据库,能够自动扩缩、具备出色的性能,并且易于进行应用开发。 |
开源 | 替代数据库选项,包括 MongoDB 和 MariaDB。 |
数据库迁移
当您将现有工作负载迁移到 Google Cloud 时,为确保用户的应用不发生停机,请务必选择支持您的要求的数据库技术。如需了解数据库迁移方案和最佳实践,请参阅数据库迁移解决方案和同构数据库迁移最佳实践。
规划数据库迁移包括以下操作:
- 评估和发现当前数据库。
- 定义迁移成功标准。
- 设置适用于迁移和目标数据库的环境。
- 在目标数据库中创建架构。
- 将数据迁移到目标数据库。
- 验证迁移,以验证所有数据都已正确迁移并且位于数据库中。
- 创建回滚策略。
选择迁移策略
选择适当的目标数据库是成功迁移的关键因素之一。下表提供了一些使用场景的迁移方案:
使用场景 | 建议 |
---|---|
Google Cloud 中的新开发项。 | 选择专为云构建的某个代管式数据库(Cloud SQL、Spanner、Bigtable 或 Firestore),以满足您的使用场景要求。 |
直接原样迁移。 | 选择兼容的代管式数据库服务,例如 Cloud SQL、MYSQL、PostgreSQL 或 SQLServer。 |
您的应用需要对 CloudSQL 不支持的数据库进行精细化访问。 | 在 Compute Engine 虚拟机上运行数据库。 |
使用 Memorystore 支持缓存数据库层
Memorystore 是支持亚毫秒级延迟的全代管式 Redis 和 Memcached 数据库。Memorystore 与开源 Redis 和 Memcached 完全兼容。如果您在应用中使用这些缓存数据库,则无需在代码中进行应用级更改即可使用 Memorystore。
使用 Bare Metal 服务器运行 Oracle 数据库
如果您的工作负载需要 Oracle 数据库,请使用 Google Cloud 提供的 Bare Metal 服务器。此方法适用于直接原样迁移迁移策略。
如果需要将工作负载迁移到 Google Cloud 并在基准工作负载正常运行后进行现代化改造,请考虑使用 Spanner、Bigtable 和 Firestore 等代管式数据库选项。
专为云构建的数据库是在云基础架构上自下而上构建的现代化代管式数据库。这些数据库提供了独特的默认功能,如可扩缩性和高可用性,如果您运行自己的数据库,则很难实现这些功能。
对数据库进行现代化改造
无论您是在云中设计新应用,还是要将现有数据库迁移到云中,请在系统设计过程中尽早规划您的数据库策略。Google Cloud 为开源数据库(例如 Cloud SQL for MySQL 和 Cloud SQL for PostgreSQL)提供代管式数据库选项。我们建议您在迁移过程中对数据库进行现代化改造,并将其准备它以支持未来的业务需求。
将固定数据库与现成的应用配合使用
现成商业 (COTS) 应用需要固定类型的数据库和固定配置。直接原样迁移通常是最适合 COTS 应用的迁移方法。
验证团队的数据库迁移技能组合
根据团队的数据库迁移功能和技能组合选择云数据库迁移方法。使用 Google Cloud Partner Advantage 寻找在整个迁移过程中为您提供支持的合作伙伴。
设计数据库以满足 HA 和 DR 要求
在设计数据库以满足高可用性 (HA) 和灾难恢复 (DR) 要求时,请评估可靠性与费用之间的权衡取舍。专为云构建的数据库服务会在一个区域或多个区域中创建数据的多个副本,具体取决于数据库和配置。
某些 Google Cloud 服务具有多区域变体,例如 BigQuery 和 Spanner。如需应对区域级故障,请在设计中尽可能使用这些多区域服务。
如果您在 Compute Engine 虚拟机上设计数据库,而不是在 Google Cloud 上使用代管式数据库,请确保运行数据库的多个副本。如需了解详情,请参阅“可靠性”类别中的在设计时确保可扩缩性和高可用性。
指定云区域以支持数据驻留
数据驻留描述静态存储数据的实际位置。请考虑选择特定的云区域,以根据您的数据驻留要求部署数据库。
如果您在多个区域中部署数据库,则它们之间可能存在重复数据,具体取决于您如何配置数据库。选择将数据静态保存在所需区域内的配置。某些数据库(如 Spanner)提供默认的多区域复制功能。您还可以通过设置包含资源位置限制条件的组织政策来强制执行数据驻留。如需了解详情,请参阅限制资源位置。
设计数据驻留时包含灾难恢复
在数据驻留方案中添加恢复时间目标 (RTO) 和恢复点目标 (RPO),并考虑 RTO/RPO 与灾难恢复解决方案费用之间的权衡取舍。RTO/RPO 数字越小,费用就越高。如果您希望系统更快地从中断中恢复,则系统运行费用会增加。此外,请将客户满意度纳入灾难恢复方法中,以确保您的可靠性投资是合适的。如需了解详情,请参阅 100% 可靠性是错误的目标和灾难恢复规划指南。
让数据库符合 Google Cloud 的规定
为工作负载选择数据库时,请确保所选服务符合运营所在的地理区域以及数据实际存储位置的规定。如需详细了解 Google 的认证和合规标准,请参阅合规产品。
加密
本部分提供确定加密要求并选择加密密钥策略以支持您的系统的最佳实践。
确定加密要求
加密要求取决于多个因素,包括公司安全政策和合规性要求。默认情况下,存储在 Google Cloud 中的所有数据均采用 AES256 进行静态加密,您无需执行任何操作。如需了解详情,请参阅 Google Cloud 中的静态加密。
选择加密密钥策略
确定您是否要自行管理加密密钥,还是要使用代管式服务。Google Cloud 支持这两种场景。如果您希望全代管式服务来管理您在 Google Cloud 上的加密密钥,请选择 Cloud Key Management Service (Cloud KMS)。如果您希望管理加密密钥以更好地控制密钥的生命周期,请使用客户管理的加密密钥 (CMEK)。
如需在 Google Cloud 外部创建和管理加密密钥,请选择以下任一选项:
- 如果您使用合作伙伴解决方案来管理密钥,请使用 Cloud External Key Manager。
- 如果您在本地管理密钥,并想使用这些密钥在 Google Cloud 上加密数据,请将这些密钥导入到 Cloud KMS,作为 KMS 密钥或硬件密钥模块 (HSM) 密钥。使用这些密钥在 Google Cloud 上加密数据。
数据库设计和扩缩
本部分提供设计和扩缩数据库以支持您的系统的最佳实践。
使用监控指标评估扩缩需求
使用现有监控工具和环境中的指标建立一个基准,以便基本了解数据库大小和扩缩要求,例如,为数据库实例合理调整容量和设计扩缩策略。
对于新的数据库设计,请根据传送应用的预期负载和流量模式确定扩缩数量。如需了解详情,请参阅监控 Cloud SQL 实例、使用 Cloud Monitoring 进行监控和监控实例。
网络和访问权限
本部分提供管理网络和访问权限以支持您的系统的最佳实践。
在专用网络中运行数据库
在专用网络中运行您的数据库,并且仅向需要与数据库交互的客户端授予受限访问权限。您可以在 VPC 内创建 Cloud SQL 实例。Google Cloud 还提供 VPC Service Controls for Cloud SQL、Spanner 和 Bigtable 数据库,以确保只有授权 VPC 网络中的客户端可以访问这些资源。
向用户授予最低权限
Identity and Access Management (IAM) 用于控制对 Google Cloud 服务(包括数据库服务)的访问权限。为了将未经授权的访问风险降至最低,请向用户授予最小数量的权限。如需获得数据库的应用级访问权限,请使用权限数量最少的服务账号。
自动化和合理调整容量
本部分提供定义自动化和合理调整容量以支持您的系统的最佳实践。
将数据库实例定义为代码
迁移到 Google Cloud 的好处之一是能够自动执行基础架构以及工作负载的其他方面(例如计算和数据库层)。借助 Google Deployment Manager 和 Terraform Cloud 等第三方工具,您可以将数据库实例定义为代码,从而应用一致且可重复的方法来创建和更新数据库。
使用 Liquibase 对数据库进行版本控制
Cloud SQL 和 Spanner 等 Google 数据库服务支持 Liquibase,它是数据库的开源版本控制工具。Liquibase 可帮助您跟踪数据库架构更改、回滚架构更改以及执行可重复的迁移。
测试和调整数据库以支持扩缩
对数据库实例执行负载测试并根据测试结果进行调整,以满足应用的要求。通过对关键性能指标 (KPI) 进行负载测试或使用源自当前数据库的监控 KPI,来确定数据库的初始规模。
在创建数据库实例时,请从基于测试结果或历史监控指标的大小开始。使用云中预期的负载来测试数据库实例。然后微调实例,直到数据库实例上预期的负载获得所需的结果。
根据扩缩要求选择合适的数据库
扩缩数据库与扩缩计算层组件不同。数据库具有状态;若数据库的实例无法处理负载,请考虑采用适当的策略来扩缩数据库实例。扩缩策略因数据库类型而异。
请参阅下表,以了解适合扩缩使用场景的 Google 产品。
使用场景 | 推荐产品 | 说明 |
---|---|---|
当您需要纵向扩充服务容量和存储空间时,请向数据库添加节点来横向扩缩数据库实例。 | Spanner | 专为云构建的关系型数据库。 |
添加节点以扩缩数据库。 | Bigtable | 全代管式 NoSQL 大数据数据库服务。 |
自动处理数据库扩缩。 | Firestore | 适用于进行移动、Web 和服务器开发的灵活且可扩缩的数据库。 |
为处理更多查询,请纵向扩充 Cloud SQL 数据库实例,使其具有更多计算和内存容量。在 Cloud SQL 中,存储层与数据库实例相分离。您可以选择在存储层容量快满时自动对其进行扩缩。 | Cloud SQL | 全代管式数据库服务,可帮助您在 Google Cloud 上设置、维护、管理和控制关系型数据库。 |
运维
本部分提供用于运营以支持您的系统的最佳实践。
使用 Cloud Monitoring 监控数据库并设置提醒
使用 Cloud Monitoring 监控数据库实例并设置提醒,以通知事件的相应团队。如需了解高效的提醒功能最佳实践,请参阅构建高效的提醒。
所有专为云构建的数据库都提供日志记录和监控指标。每项服务都提供了一个信息中心,用于直观呈现日志记录和监控指标。所有服务的监控指标都与 Google Cloud Observability 集成。Spanner 提供查询自检工具,例如用于调试和根本原因分析的 Key Visualizer。Key Visualizer 提供以下功能:
- 通过为数据库生成可视化报告来帮助您分析 Spanner 使用模式。这些报告按行范围显示一段时间内的使用模式。
- 深入了解大规模使用模式。
Bigtable 还提供了一个 Key Visualizer 诊断工具,可帮助您分析 Bigtable 实例使用模式。
许可
本部分提供购买许可以支持您的系统的最佳实践。
在购买按需许可和现有许可之间进行选择
如果您使用 Cloud SQL for SQL Server,则不支持自带许可。您的许可费用根据每小时每核心的用量计算。
如果您想使用现有的 Cloud SQL for SQL Server 许可,请考虑在计算虚拟机上运行 Cloud SQL for SQL Server。如需了解详情,请参阅 Microsoft 许可和在购买按需许可和自带现有许可之间进行选择。
如果您使用 Oracle,并且要迁移到适用于 Oracle 的裸金属解决方案,则可以自带许可。如需了解详情,请参阅规划裸金属解决方案。
迁移时间轴、方法和工具集
本部分提供规划和支持数据库迁移以支持您的系统的最佳实践。
确定数据库现代化改造的就绪情况
评估您的组织是否已准备好对数据库进行现代化改造,并使用专为云构建的数据库。
在规划工作负载迁移时间轴时,请考虑对数据库进行现代化改造,因为现代化改造可能会影响您的应用端。
在规划迁移时纳入相关的利益相关方
如需迁移数据库,请完成以下任务:
- 设置目标数据库。
- 转换架构。
- 设置源数据库和目标数据库之间的数据复制。
- 调试在迁移过程中出现的问题。
- 在应用层和数据库之间建立网络连接。
- 实现目标数据库安全。
- 确保应用连接到目标数据库。
这些任务通常需要不同的技能组合,并且需要整个组织中的多个团队协作来完成迁移。在规划迁移时,请纳入所有团队(例如应用开发者、数据库管理员、基础架构和安全团队)中的利益相关方。
如果您的团队缺乏支持此类迁移的技能,则 Google 的合作伙伴可以帮助您执行迁移。如需了解详情,请参阅 Google Cloud Partner Advantage。
确定用于同构迁移和异构迁移的工具集
同构迁移是指在采用相同数据库技术的源数据库和目标数据库之间进行数据库迁移。异构迁移是指目标数据库与源数据库不同的迁移。
异构迁移通常需要执行额外的步骤,以将架构从源数据库转换到目标数据库引擎类型。数据库团队需要评估架构转换过程中遇到的难题,因为它们取决于源数据库架构的复杂性。
测试并验证数据迁移中的每个步骤
数据迁移涉及多个步骤。若要最大限度地减少迁移错误,请在迁移到下一步之前测试和验证迁移中的每个步骤。以下因素推动了迁移过程:
- 迁移是同构迁移还是异构迁移。
- 您必须拥有哪些类型的工具和技能组合才能执行迁移。
- 对于异构迁移,您需要有目标数据库引擎的使用经验。
确定持续数据复制要求
制定最初的数据迁移方案,然后将数据从源数据库持续复制到目标数据库。继续复制,直到目标稳定且应用完全迁移到新数据库为止。此方案可帮助您在数据库切换期间发现潜在的停机时间,并相应地进行规划。
如果您计划从 Cloud SQL、Cloud SQL for MySQL 或 Cloud SQL for PostgreSQL 迁移数据库引擎,请使用 Database Migration Service 以全代管式方式自动执行此过程。如需了解支持其他类型的迁移的第三方工具,请参阅 Cloud Marketplace。
建议
如需将架构框架中的指导应用到您自己的环境,建议您执行以下操作:
数据库的多租户涉及将多个客户的数据存储在共享基础架构上(在本例中为数据库)。如果您向客户提供基于软件即服务 (SaaS) 的产品,请务必了解如何以逻辑方式隔离属于不同客户的数据集,并支持其访问权限要求。此外,根据隔离级层评估您的要求。
对于 Spanner 和 Cloud SQL 等关系型数据库,您可以使用多种方法来隔离租户的数据,例如在数据库实例级层、数据库级层、架构级层或数据库表级层进行隔离。与其他设计决策一样,隔离程度与其他因素(例如费用和性能)也存在权衡取舍。IAM 政策可控制数据库实例的访问权限。
根据数据模型要求选择合适的数据库
选择键值以避免键出现 hotspotting 问题。“热点”是指表中的某个位置,该位置收到的访问请求数量超过其他位置。如需详细了解热点,请参阅架构设计最佳实践。
尽量对数据库实例进行分片。
使用连接管理最佳实践,例如连接池和指数退避算法。
避免非常大型的事务。
设计并测试应用对数据库维护更新的响应。
保护并隔离与数据库的连接。
调整数据库的规模和增长预期,以确保数据库支持您的要求。
测试 HA 和 DR 故障切换策略。
执行备份和恢复以及导出和导入操作,以便熟悉过程。
Cloud SQL 建议
- 使用专用 IP 地址网络 (VPC)。为增强安全性,请考虑以下事项:
- 使用 Cloud SQL Auth 代理支持专用网络。
- 限制公共 IP 地址访问权限
constraints/sql.restrictPublicIp
。
- 如果您需要公共 IP 地址网络,请考虑以下事项:
- 使用具有有限或小范围 IP 地址列表的内置防火墙,并确保 Cloud SQL 实例要求传入连接使用 SSL。如需了解详情,请参阅配置 SSL/TLS 证书。
- 为增强安全性,请考虑以下事项:
- 不授予一般访问权限;请改用 Cloud SQL Auth 代理。
- 限制已获授权的网络
constraints/sql.restrictAuthorizedNetworks
。
- 为数据库用户授予有限的权限。
后续步骤
了解数据分析最佳实践,包括以下内容:
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
分析您的数据
Google Cloud 架构框架中的文档介绍了在 Google Cloud 中进行数据分析的一些核心原则和最佳实践。您将了解一些关键数据分析服务,以及它们在数据生命周期的各个阶段如何提供帮助。这些最佳实践可帮助您满足数据分析需求并创建系统设计。
核心原则
企业想要分析数据并基于这些数据生成富有实用价值的分析洞见。Google Cloud 为您提供了各种服务,可帮助您完成从数据注入到报告和可视化的整个数据生命周期。其中的大多数服务都是全代管式服务,有些是无服务器服务。您还可以在 Compute Engine 虚拟机上构建和管理数据分析环境,例如,用来自行托管 Apache Hadoop 或 Beam。
您的具体侧重点、团队专业知识和战略观可帮助您确定采用哪些 Google Cloud 服务来支持您的数据分析需求。例如,您可以借助 Dataflow 以无服务器方式编写复杂的转换,但您必须依靠独特的配置版本才能满足计算和处理需求。此外,您也可以借助 Dataproc 运行相同的转换,但您可以自行管理集群并微调作业。
在系统设计中,请考虑您的团队使用哪种处理策略,例如提取、转换和加载 (ETL) 或提取、加载和转换 (ELT)。系统设计也应考虑您需要处理的是批量分析还是流式分析。Google Cloud 提供了一个统一的数据平台,可让您构建数据湖或数据仓库来满足您的业务需求。
关键服务
下表简要介绍了各项 Google Cloud 分析服务:
Google Cloud 服务 | 说明 |
---|---|
Pub/Sub | 简单、可靠、可扩缩,可以用作数据流分析和事件驱动型计算系统的基础。 |
Dataflow | 一项全代管式服务,可用于转换采用流式(实时)模式和批量(历史)模式的数据并丰富数据内容。 |
Dataprep by Trifacta | 智能数据服务,可用于直观地探索、清理和准备结构化数据及非结构化数据,以备分析之用。 |
Dataproc | 快速、易用、全代管式云服务,用于运行 Apache Spark 和 Apache Hadoop 集群。 |
Cloud Data Fusion | 全代管式数据集成服务,专为云打造且可让您构建和管理 ETL/ELT 数据流水线。Cloud Data Fusion 提供一个图形界面以及一个由预配置连接器和转换功能组成的大型开源库。 |
BigQuery | 全代管式低成本无服务器数据仓库,可根据您的存储和计算能力需求进行扩缩。BigQuery 是一个列式 ANSI SQL 数据库,能够分析 TB 级乃至 PB 级的数据。 |
Cloud Composer | 全代管式工作流编排服务,您可以利用它编写、安排和监控跨越多个云环境和本地数据中心的流水线。 |
Data Catalog | 可扩缩的全代管式元数据管理服务,可帮助您发现、管理和了解所有数据。 |
Looker 数据洞察 | 全代管式直观分析服务,可帮助您通过交互式信息中心从数据中汲取洞见。 |
Looker | 连接、分析和直观呈现多云环境中的数据的企业平台。 |
Dataform | 全代管式产品,可帮助您协作、创建和部署数据流水线,并确保数据品质。 |
Dataplex | 代管式数据湖服务,它使用一致的控制机制集中管理、监控和治理数据湖、数据仓库和数据集市中的数据。 |
Analytics Hub | 此平台用于在整个组织中以高效、安全的方式交换数据分析资源,以应对数据可靠性和费用的挑战。 |
数据生命周期
在创建系统设计时,您可以围绕任何系统中的一般数据移动或围绕数据生命周期将 Google Cloud 数据分析服务进行分组。
数据生命周期包括以下各阶段和示例服务:
- 注入包括 Pub/Sub、Storage Transfer Service、Transfer Appliance 和 BigQuery 等服务。
- “存储”包括 Cloud Storage、Bigtable、Memorystore 和 BigQuery 等服务。
- 处理和转换包括 Dataflow、Dataproc、Dataprep、敏感数据保护和 BigQuery 等服务。
- “分析和仓储”包括 BigQuery 等服务。
- 报告和可视化包括 Looker Studio 和 Looker 等服务。
以下各阶段和服务将在整个数据生命周期中运行:
- “数据集成”包括 Data Fusion 等服务。
- “元数据管理和治理”包括 Data Catalog 等服务。
- “工作流管理”包括 Cloud Composer 等服务。
数据注入
将以下数据注入最佳实践应用于您自己的环境。
确定可供注入数据的数据源
数据通常来自其他云提供商或服务,或者来自本地位置:
如需从其他云提供商注入数据,您通常可以使用 Cloud Data Fusion、Storage Transfer Service 或 BigQuery Transfer Service。
如需注入本地数据,请考虑要注入的数据量以及团队的技能。如果您的团队倾向于使用低代码的图形界面 (GUI) 方法,请将 Cloud Data Fusion 与合适的连接器(例如 Java Database Connectivity (JDBC))搭配使用。如果有大量数据,您可以使用 Transfer Appliance 或 Storage Transfer Service。
考虑如何在注入数据后如何处理数据。例如,Storage Transfer Service 仅将数据写入 Cloud Storage 存储桶,BigQuery Data Transfer Service 仅将数据写入 BigQuery 数据集。Cloud Data Fusion 支持多个目的地。
确定流式数据源或批量数据源
考虑您需要如何使用数据并确定具有流式或批量使用场景的位置。例如,如果您运行具有低延迟时间要求的全球流式传输服务,则可以使用 Pub/Sub。如果您需要数据以用于分析和报告,则可以将数据流式传输至 BigQuery。
如果您需要从 Apache Kafka 等系统在本地或其他云环境中流式传输数据,请使用 Kafka to BigQuery Dataflow 模板。对于批处理工作负载,第一步通常是将数据注入到 Cloud Storage 中。使用 gsutil 工具或 Storage Transfer Service 注入数据。
使用自动化工具注入数据
将数据从其他系统手动迁移到云可能存在一定的难度。可能的话,请使用可让您自动化数据注入流程的工具。例如,Cloud Data Fusion 提供连接器和插件,以便通过拖放 GUI 从外部来源提取数据。如果您的团队想要编写一些代码,则 Data Flow 或 BigQuery 可帮助自动执行数据注入。Pub/Sub 可帮助您采用低代码或代码优先的方法。如需将数据注入到存储桶中,请针对最高达 1 TB 的数据规模使用 gsutil。如需注入超过 1 TB 的数据量,请使用 Storage Transfer Service。
使用迁移工具从其他数据仓库中注入
如果您需要从其他数据仓库系统(例如 Teradata、Netezza 或 Redshift)迁移,则可以使用 BigQuery Data Transfer Service 迁移协助。BigQuery Data Transfer Service 还提供第三方转移作业,可帮助您按计划从外部来源注入数据。如需了解详情,请参阅每个数据仓库的详细迁移方法。
估算您的数据注入需求
您需要注入的数据量可帮助您确定要在系统设计中使用哪些服务。对于流式注入数据,Pub/Sub 可以扩展为每秒数十 GB。数据的容量、存储空间和区域要求可帮助您确定 Pub/Sub Lite 是否为较好的系统设计方案。如需了解详情,请参阅选择 Pub/Sub 或 Pub/Sub Lite。
对于批量注入数据,请估算要转移的总数据量以及转移速度。查看可用的迁移方案,包括时间估算以及在线转移与离线转移对比。
使用适当的工具按计划定期注入数据
Storage Transfer Service 和 BigQuery Data Transfer Service 都可让您安排注入作业。如需精细化地控制注入时间或来源和目标系统,请使用 Cloud Composer 等工作流管理系统。如果需要手动操作更多的方法,则可以使用 Cloud Scheduler 和 Pub/Sub 触发 Cloud Functions 函数。
如果需要管理计算基础架构,您可以将 gsutil 命令与 Cron 配合使用,来转移高达 1 TB 的数据。如果您使用此手动方法而不是 Cloud Composer,请按照为生产转移作业编写脚本的最佳实践进行操作。
查看 FTP/SFTP 服务器数据注入需求
如果您需要无代码环境从 FTP/SFTP 服务器中注入数据,则可以使用 FTP 副本插件。如果需要进行现代化改造并创建一个长期工作流解决方案,则全代管式服务 Cloud Composer 可让您从各种来源和接收器读写数据。
使用 Apache Kafka 连接器注入数据
如果您使用 Pub/Sub、Dataflow 或 BigQuery,则可以使用某个 Apache Kafka 连接器注入数据。例如,开源 Pub/Sub Kafka 连接器可让您从 Pub/Sub 或 Pub/Sub Lite 中注入数据。
其他资源
- Cloud Storage Transfer Service 代理最佳实践
- 如何将数据注入到 BigQuery 中进行分析
- 使用 Cloud Data Fusion 注入临床数据和运营数据
- 优化分析事件和日志的大规模注入
数据存储
将以下数据存储最佳实践应用于您自己的环境。
根据您的需求选择适当的数据存储区
为帮助您选择使用哪种存储解决方案,请查看并了解数据的下游使用情况。以下常见的数据使用场景提供了可供 Google Cloud 产品采纳的建议:
数据使用场景 | 产品推荐 |
---|---|
基于文件 | Filestore |
基于对象的文件服务器 | Cloud Storage |
低延迟 | Bigtable |
时间序列 | Bigtable |
在线缓存 | Memorystore |
事务处理 | Cloud SQL |
商业智能 (BI) 和分析 | BigQuery |
批处理 | Cloud Storage Bigtable:如果传入数据是时间序列,并且您需要以低延迟时间方式对它进行访问。 BigQuery:如果您使用 SQL。 |
查看您的数据结构需求
对于大多数非结构化数据(例如文档和文本文件、音频和视频文件或日志),基于对象的存储区是最合适的选择。然后,您可以根据需要从对象存储空间加载和处理数据。
对于半结构化数据(例如 XML 或 JSON),您的使用场景和数据访问模式可帮助您做出选择。您可以将此类数据集加载到 BigQuery 中,以便进行自动架构检测。如果您有低延迟时间要求,则可以将 JSON 数据加载到 Bigtable 中。如果您有旧版要求或您的应用使用关系型数据库,则您也可以将数据集加载到关系存储区中。
对于 CSV、Parquet、Avro 或 ORC 等结构化数据,如果您有使用 SQL 的商业智能和分析要求,则可以使用 BigQuery。如需了解详情,请参阅如何批量加载数据。如果需要基于开放式标准和技术创建数据湖,您可以使用 Cloud Storage。
迁移数据并降低 HDFS 的费用
设法将 Hadoop 分布式文件系统 (HDFS) 数据从本地或其他云提供商迁移到更加经济实惠的对象存储系统。Cloud Storage 是企业用作替代数据存储区的最常用选项。如需了解此选项的优缺点,请参阅 HDFS 与 Cloud Storage 比较。
您可以使用推送或拉取方法迁移数据。这两种方法都会使用 hadoop
distcp
命令。如需了解详情,请参阅将 HDFS 数据从本地迁移到 Google Cloud。
您还可以使用开源 Cloud Storage 连接器,让 Hadoop 和 Spark 作业访问 Cloud Storage 中的数据。该连接器默认安装在 Dataproc 集群上,并且可以手动安装在其他集群上。
利用对象存储构建统一的数据湖
数据湖是一个集中存储区,用于存储、处理和保护大量结构化、半结构化和非结构化数据。您可以使用 Cloud Composer 和 Cloud Data Fusion 构建数据湖。
如需构建现代化数据平台,您可以使用 BigQuery 而不是 Cloud Storage 作为中心数据源。BigQuery 是一种现代化数据仓库,具有存储和计算相分离功能。借助基于 BigQuery 构建的数据湖,您可以在 Cloud 控制台中从 BigQuery 执行传统分析。它还可让您从其他框架(如 Apache Spark)访问存储的数据。
其他资源
- Cloud Storage 最佳实践
- Cloud Storage 费用优化最佳实践。
- 确保 Cloud Storage 数据隐私权和安全性的最佳实践
- Memorystore 最佳实践
- 优化 BigQuery 中的存储性能
- Bigtable 架构设计
处理和转换数据
在处理和转换数据时,将以下数据分析最佳实践应用于您自己的环境。
探索可在 Google Cloud 中使用的开源软件
许多 Google Cloud 服务都使用开源软件来帮助您无缝转换。Google Cloud 提供代管式无服务器解决方案,这些解决方案具有开放式 API 且与开源框架兼容,可减少出现受制于特定供应商的情况。
Dataproc 是与 Hadoop 兼容的代管式服务,可让您托管开源软件,并且几乎没有运营负担。Dataproc 支持 Spark、Hive、Pig、Presto 和 Zookeeper。它还提供 Hive Metastore 即代管式服务,以避免本身成为 Hadoop 生态系统中的单点故障。
如果您目前使用 Apache Beam 作为批处理和流式处理引擎,则可以迁移到 Dataflow。Dataflow 是一项使用 Apache Beam 的全代管式无服务器服务。使用 Dataflow 在 Beam 中编写作业,但让 Google Cloud 管理执行环境。
如果您使用 CDAP 作为数据集成平台,则可以迁移到 Cloud Data Fusion 以获得全代管式体验。
确定 ETL 或 ELT 数据处理需求
团队的经验和偏好有助于确定如何处理数据的系统设计。Google Cloud 允许您使用传统 ETL 或更现代化的 ELT 数据处理系统。
对于 ETL 流水线,您可以使用 Data Fusion、Dataproc 或 Dataflow。
- 对于新环境,我们建议使用 Dataflow 作为创建批量和流式应用的统一方法。
- 对于全代管式方法,Data Fusion 提供的拖放式 GUI 可帮助您创建流水线。
对于 ELT 流水线,请使用支持批量和流式数据加载的 BigQuery。将数据存储在 BigQuery 中之后,使用 SQL 执行所有转换以便为您的业务使用场景生成新的数据集。
如果您要进行现代化改造并从 ETL 迁移到 ELT,则可以使用 Dataform。
针对您的数据使用场景使用适当的框架
您的数据使用场景决定了要使用的工具和框架。有些 Google Cloud 产品旨在处理以下所有数据使用场景,而其他 Google Cloud 产品则仅支持一种特定使用场景。
- 对于批量数据处理系统,您可以使用熟悉的 SQL 接口在 BigQuery 中处理和转换数据。如果您有现成的流水线在 Apache Hadoop 或 Spark 本地环境或其他公有云中运行,则可以使用 Dataproc。
- 如果需要在批量和流式使用场景中使用一个统一的编程接口,您也可以使用 Dataflow。我们建议您对 Dataflow 和 BigQuery 进行现代化改造,并使用 Dataflow 来执行 ETL,使用 BigQuery 来执行 ELT。
对于流式数据流水线,您可以使用 Dataflow 等代管式无服务器服务,它提供数据选取、自动扩缩和模板功能。如需了解详情,请参阅使用 Dataflow 构建生产级数据流水线。
- 如果您拥有分析和专注于 SQL 的团队和功能,则还可以将数据流式插入到 BigQuery。
对于实时使用场景,例如时序分析或流式视频分析,请使用 Dataflow。
保留对执行引擎的未来控制权
为了最大程度地减少出现受制于特定供应商的情况并且为了能够在将来使用其他平台,请使用 Apache Beam 编程模型和 Dataflow 作为代管式无服务器解决方案。使用 Beam 编程模型,您可以更改底层执行引擎,例如从 Dataflow 更改为 Apache Flink 或 Apache Spark。
使用 Dataflow 从多个来源注入数据
如需从多个来源(例如 Pub/Sub、Cloud Storage、HDFS、S3 或 Kafka)注入数据,请使用 Dataflow。Dataflow 是一项支持 Dataflow 模板的代管式无服务器服务,让您的团队可以从不同工具运行模板。
Dataflow Prime 为流水线执行过程中使用的机器提供横向和纵向自动扩缩功能。它还提供智能诊断和建议,帮助您发现问题并提出修复问题的建议。
发现、识别和保护敏感数据
使用敏感数据保护来检查和转换结构化和非结构化数据。敏感数据保护适用于位于 Google Cloud 中任意位置的数据,例如 Cloud Storage 或数据库中的数据。您可以对敏感数据进行分类、遮盖和标记化处理,以便继续安全地将其用于下游处理。使用敏感数据保护执行扫描 BigQuery 数据或对大规模数据集中的个人身份信息进行去标识化和重标识处理等操作。
对数据转换流程进行现代化改造
使用 Dataform 以代码形式编写数据转换,并默认开始使用版本控制。您还可以采用软件开发最佳做法,例如 CI/CD、单元测试以及 SQL 代码版本控制。Dataform 支持所有主要云数据仓库产品和数据库,例如 PostgreSQL。
其他资源
- Dataproc
- Dataflow
- Data Fusion
- BigQuery
- Dataform
- 敏感数据保护
数据分析和仓库
将以下数据分析和仓库最佳实践应用于您自己的环境。
查看您的数据存储需求
数据湖和数据仓库并不互斥。数据湖对于非结构化和半结构化数据存储和处理非常有用。数据仓库最适合用于分析和商业智能。
查看您的数据需求,以帮助确定数据的存储位置以及哪种 Google Cloud 产品最适合处理和分析您的数据。BigQuery 等产品可以处理 PB 级数据,并随着您的需求而增长。
发现从传统数据仓库迁移到 BigQuery 的机会
查看您环境中当前正在使用的传统数据仓库。为降低复杂性并降低费用,请发现将传统数据仓库迁移到 BigQuery 等 Google Cloud 服务的机会。如需了解详情并查看示例场景,请参阅将数据仓库迁移到 BigQuery。
规划数据的联合访问事宜
查看您的数据要求以及如何与其他产品和服务进行交互。确定您的数据联合需求,并创建适当的系统设计。
例如,BigQuery 允许您定义可从其他来源(如 Bigtable、Cloud SQL、Cloud Storage 或 Google 云端硬盘)读取数据的外部表。您可以将这些外部来源与您存储在 BigQuery 中的表进行联接。
使用 BigQuery 灵活槽提供按需突发容量
有时,您需要额外的容量来执行需要大量计算资源的实验性或探索性分析。BigQuery 允许您以灵活槽的形式获取额外的计算容量。当需求较高或您希望完成重要分析时,灵活槽便可为您提供帮助。
了解迁移到 BigQuery 时的架构差异
BigQuery 同时支持星型和雪花型架构,但默认情况下使用嵌套和重复字段。与其他架构相比,嵌套和重复字段更易于读取和关联。如果数据以星型或雪花型架构表示,并且您想要迁移到 BigQuery,请在您的系统设计中检查是否对流程或分析进行任何必要更改。
其他资源
报告和直观呈现
将以下报告和可视化最佳实践应用于您自己的环境。
使用 BigQuery BI Engine 直观呈现您的数据
BigQuery BI Engine 是一项高速内存中分析服务。您可以使用 BI Engine 分析存储在 BigQuery 中的数据,并且支持亚秒级查询响应时间和高并发操作。BI Engine 已集成到 BigQuery API 中。使用预留的 BI Engine 容量,根据您的需求来管理按需价格或固定价格。 BI Engine 还可以与需要亚秒级响应时间的其他 BI 或自定义信息中心应用搭配使用。
使用 Looker 对商业智能流程进行现代化改造
Looker 是用于提供商业智能、数据应用和嵌入式分析的现代化企业平台。您可以基于数据快速而准确地创建一致的数据模型,还可以访问事务和分析数据存储区中的数据。Looker 还可以分析多个数据库和云中的数据。如果您有现成的 BI 流程和工具,我们建议您进行现代化改造并使用中央平台,例如 Looker。
其他资源
使用工作流管理工具
数据分析涉及许多流程和服务。数据在数据分析生命周期内会跨不同的工具和处理流水线移动。如需管理和维护端到端数据流水线,请使用适当的工作流管理工具。Cloud Composer 是一款基于开源 Apache Airflow 项目的全代管式工作流管理工具。
您可以使用 Cloud Composer 启动 Dataflow 流水线并使用 Dataproc 工作流模板。Cloud Composer 还可以帮助您创建 CI/CD 流水线以测试、同步和部署 DAG 或使用 CI/CD 流水线进行数据处理工作流。 如需了解详情,请观看 Cloud Composer:开发最佳实践。
迁移资源
如果您已运行数据分析平台,并且希望将部分或全部工作负载迁移到 Google Cloud,请查看以下迁移资源以了解最佳实践和指导:
- 常规迁移指导
- Cloud Storage 迁移
- Pub/Sub 迁移
- Bigtable 迁移
- Dataproc 迁移
- BigQuery 迁移
- Composer 迁移
后续步骤
了解 Google Cloud AI 和机器学习的系统设计最佳实践,包括以下内容:
- 了解支持系统设计的 Google Cloud AI 和机器学习服务。
- 了解机器学习数据处理最佳实践。
- 了解模型开发和训练的最佳实践。
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
实现机器学习
Google Cloud 架构框架中的文档介绍了在 Google Cloud 中进行数据分析的一些核心原则和最佳实践。您将了解一些关键的 AI 和机器学习 (ML) 服务,以及它们在 AI 和机器学习生命周期的各个阶段如何提供帮助。这些最佳实践可帮助您满足 AI 和机器学习需求并创建系统设计。本文档假定您熟悉基本的 AI 和机器学习概念。
如需简化开发过程并在 Google Cloud 上构建机器学习模型时将开销降至最低,请考虑适合您的使用场景的最高抽象级别。抽象级别被定义为查看系统或为系统编程依据的复杂程度。抽象级别越高,查看者可用的详细信息就越少。
如需根据您的业务需求选择 Google AI 和机器学习服务,请参阅下表:
角色 | Google 服务 |
---|---|
企业用户 | 标准解决方案,例如 Contact Center AI Insights、Document AI、Discovery AI 和 Cloud Healthcare API。 |
机器学习经验极少的开发者 | 预先训练的 API 可处理常见感知任务,例如视觉、视频和自然语言。这些 API 受预先训练的模型支持,提供默认检测器。用户无需具备任何机器学习专业知识,也不需要进行模型开发,即可使用这些 API。预先训练的 API 包括:Vision API、Video API、Natural Language API、Speech-to-Text API、Text-to-Speech API 和 Cloud Translation API。 |
面向开发者的生成式 AI | 利用 Vertex AI Search and Conversation,开发者可以使用其开箱即用的功能在几分钟内构建和部署聊天机器人,在数小时内构建和部署搜索引擎。想要将多种功能整合到企业工作流程中的开发者可以使用 Gen App Builder API 来直接集成。 |
开发者和数据科学家 | 借助 AutoML,可使用您自己的图片、视频、文本或表格数据开发自定义模型。AutoML 通过在 Google 模型库中自动搜索性能最出色的模型架构来加速模型开发,因此您无需构建模型。AutoML 会为您处理常见任务,例如选择模型架构、超参数调节、预配机器以进行训练和部署。 |
数据科学家和机器学习工程师 | 通过 Vertex AI 自定义模型工具,您可以训练和部署自定义模型,它们可以将机器学习工作流付诸使用。您还可以在自行管理的计算(例如 Compute Engine 虚拟机)上运行机器学习工作负载。 |
数据科学家和机器学习工程师 | Vertex AI 上的生成式 AI 支持(也称为 genai)可让您访问 Google 的大型生成式 AI 模型,以便在依托 AI 技术的应用中测试、调整和部署该模型。 |
熟悉 SQL 接口的数据工程师、数据科学家和数据分析师 | 借助 BigQuery ML,您可以根据 BigQuery 中存储的数据开发基于 SQL 的模型。 |
关键服务
下表简要介绍了 AI 和机器学习服务:
Google 服务 | 说明 |
---|---|
Cloud Storage 和 BigQuery | 为机器学习数据和工件提供灵活的存储选项。 |
BigQuery ML | 允许您直接根据 BigQuery 内部的数据构建机器学习模型。 |
Pub/Sub、Dataflow、 Cloud Data Fusion 和 Dataproc |
支持批量和实时数据注入和处理。如需了解详情,请参阅数据分析。 |
Vertex AI | 为数据科学家和机器学习工程师提供单一平台,以创建、生成、训练、测试、监控、调整和部署生成式 AI 到 MLOps 各种机器学习模型。 工具包括以下内容:
|
Vertex AI Search and Conversation | 可让您为网站构建聊天机器人和搜索引擎,以便在企业数据中使用。
|
Vertex AI 上的生成式 AI | 可让您访问 Google 的大型生成式 AI 模型,以便对其进行测试、调整和部署,从而在依托 AI 技术的应用中使用。Vertex AI 上的生成式 AI 也称为 genai。
|
预先训练的 API | |
AutoML | 提供自定义模型工具来构建、部署和扩缩机器学习模型。开发者可以上传自己的数据,并使用合适的 AutoML 服务构建自定义模型。
|
AI Infrastructure | 可让您使用 AI 加速器处理大规模机器学习工作负载。这些加速器可让您以经济实惠的方式训练深度学习模型和机器学习模型并从中进行推理。 GPU 可帮助您经济实惠的方式进行推理、纵向扩容或横向扩容深度学习模型的训练。张量处理单元 (TPU) 是定制的 ASIC,用于训练和执行深度神经网络。 |
Dialogflow | 提供可提供对话体验的虚拟客服。 |
Contact Center AI | 借助 Agent Assist 功能,为人工客服提供自动化、具有丰富数据洞见的联络中心体验。 |
Document AI | 为一般文档以及贷款相关文档和采购相关文档等特定文档类型大规模提供文档理解。 |
Lending DocAI | 自动执行抵押贷款文件处理。缩短处理时间并简化数据捕获流程,同时符合法规和合规性要求。 |
Procurement DocAI | 通过将非结构化文档(例如账单和收据)转换为结构化数据,自动大规模捕获采购数据,从而提升运营效率、改善客户体验并做出明智决策。 |
建议 | 提供个性化产品推荐。 |
Healthcare Natural Language AI | 可让您查看和分析医学文档。 |
Media Translation API | 启用从音频数据进行实时语音翻译。 |
数据处理
将以下数据处理最佳实践应用于您自己的环境。
确保数据符合机器学习要求
无论数据类型如何,您用于机器学习的数据都应满足特定基本要求。这些要求包括数据预测目标的能力,用于训练的数据与用于预测的数据之间的粒度一致性,以及用于训练的准确标记的数据。您的数据量也应该足够。如需了解详情,请参阅数据处理。
在 BigQuery 中存储表格数据
如果要使用表格数据,请考虑将所有数据都存储在 BigQuery 中,并使用 BigQuery Storage API 从中读取数据。如需简化与 API 的交互,请使用以下其他工具选项之一,具体取决于您要从哪里读取数据:
- 如果要使用 Dataflow,请使用 BigQuery I/O 连接器。
- 如果要使用 TensorFlow 或 Keras,请使用适用于 BigQuery 的 tf.data.dataset 读取器。
- 如果要使用图片或视频等非结构化数据,请考虑将所有数据都存储在 Cloud Storage 中。
输入数据类型还可以确定可用的模型开发工具。通过预先训练的 API、AutoML 和 BigQuery ML,您可以为某些图片、视频、文本和结构化数据使用场景提供更加经济实惠且更加节省时间的开发环境。
确保您有足够的数据来开发机器学习模型
如需开发实用的机器学习模型,您需要有足够的数据。如需预测类别,建议每个类别的样本数量是特征数量的 10 倍。您需要预测的类别越多,需要的数据就越多。不均衡数据集需要更多数据。如果没有足够的带标签数据可用,请考虑半监督式学习。
数据集大小也会对训练和部署造成影响:如果您的数据集较小,则可以直接在 Notebooks 实例中进行训练;如果您有需要进行分布式训练的较大数据集,请使用 Vertex AI 自定义训练服务。如果您希望 Google 为您的数据训练模型,请使用 AutoML。
准备可供使用的数据
精心准备的数据可以加速模型开发。配置数据流水线时,请确保它可以处理批量数据和流式数据,以便从这两种类型的数据中获得一致的结果。
模型开发和训练
将以下模型开发和训练最佳实践应用于您自己的环境。
选择代管式或自定义训练模型开发
构建模型时,请尽可能考虑最高抽象级别。尽可能使用 AutoML,以便为您处理开发和训练任务。对于自定义训练模型,请选择能够确保可扩缩性和灵活性的代管式选项,而不是自行管理的选项。如需详细了解模型开发选项,请参阅使用推荐的工具和产品。
考虑在 Compute Engine 虚拟机或深度学习虚拟机容器上使用 Vertex AI 训练服务而不是自行管理的训练。对于 JupyterLab 环境,请考虑使用 Vertex AI Workbench,它提供代管式和用户管理的 JupyterLab 环境。如需了解详情,请参阅机器学习开发和实现训练。
对自定义训练模型使用预构建或自定义容器
对于 Vertex AI 上的自定义训练模型,您可以根据机器学习框架和框架版本使用预构建或自定义容器。预构建容器适用于为特定 TensorFlow、scikit-learn、PyTorch 和 XGBoost 版本创建的 Python 训练应用。
否则,您可以选择为训练作业构建自定义容器。例如,如果您想使用预构建容器中没有的 Python 机器学习框架训练模型,或者想使用 Python 以外的编程语言训练模型,请使用自定义容器。在自定义容器中,将您的训练应用及其所有依赖项预安装到运行训练作业的映像上。
考虑分布式训练要求
请考虑您的分布式训练要求。某些机器学习框架(如 TensorFlow 和 PyTorch)可让您在多台机器上运行相同的训练代码。这些框架根据每台机器上设置的环境变量自动协调工作的划分。其他框架可能需要额外的自定义。
后续步骤
如需详细了解 AI 和机器学习,请参阅以下内容:
探索架构框架中的其他类别,例如可靠性、卓越运营以及安全性、隐私权和合规性。
针对环境可持续发展进行设计
Google Cloud 架构框架中的本文档总结了如何在 Google Cloud 中处理工作负载的环境可持续发展。其中介绍了如何最大限度地减少 Google Cloud 上的碳足迹。
了解您的碳足迹
如需了解使用 Google Cloud 产生的碳足迹,请使用碳足迹信息中心。碳足迹信息中心会将排放量归因于您拥有的 Google Cloud 项目以及您使用的云服务。
如需了解详情,请参阅“减少 Google Cloud 碳足迹”中的了解碳足迹。
选择最合适的云区域
一种简单而有效的减少碳排放量的方法是选择碳排放量较低的云区域。为帮助您做出此选择,Google 会发布所有 Google Cloud 区域的碳数据。
选择区域时,您可能需要将降低排放量与其他要求(例如价格和网络延迟时间)进行平衡。为帮助选择区域,请使用 Google Cloud 区域选择器。
如需了解详情,请参阅“减少 Google Cloud 碳足迹”中的选择最合适的云区域。
选择最合适的云服务
为帮助减少现有的碳足迹,请考虑将本地虚拟机工作负载迁移到 Compute Engine。
此外,请考虑许多工作负载不需要虚拟机。通常,您可以改用无服务器产品。这些代管式服务通常可以自动优化云资源用量,同时降低云费用和碳足迹。
如需了解详情,请参阅“减少 Google Cloud 碳足迹”中的选择最合适的云服务。
最大限度地减少空闲云资源
空闲资源会产生不必要的费用和排放量。空闲资源的一些常见原因如下:
以下是一些有助于最大限度地减少浪费的云资源的一般策略:
- 识别空闲或超额预配的资源,并将其删除或进行合理调整。
- 重构您的架构,以采用更优化的设计。
- 将工作负载迁移到代管式服务。
如需了解详情,请参阅“减少 Google Cloud 碳足迹”中的最大限度地减少空闲云资源。
减少批处理工作负载的排放量
在碳排放量较低的区域中运行批处理工作负载。如需进一步减少排放量,请尽可能在电网碳强度较低的时段运行工作负载。
如需了解详情,请参阅“减少 Google Cloud 碳足迹”中的减少批处理工作负载的排放量。
后续步骤
- 了解如何使用碳足迹数据测量、报告和减少云碳排放量。
- 了解如何减少 Google Cloud 碳足迹。
Google Cloud 架构框架:卓越运营
Google Cloud 架构框架中的这一部分介绍了如何在 Google Cloud 上高效运营服务。介绍了如何运行、管理和监控能够提供业务价值的系统。本部分还介绍了支持卓越运营的 Google Cloud 产品和功能。采用卓越运营原则可帮助您为可靠性打好基础。它通过设置可观测性、自动化和可伸缩性等基本元素来实现这一点。
此架构框架介绍了最佳实践,提供了实现建议,并介绍了一些可帮助您实现卓越运营的可用产品和服务。该框架旨在帮助您设计 Google Cloud 部署,以便它能够完全满足您的业务需求。
在架构框架的卓越运营部分中,您将了解如何执行以下操作:
实现部署自动化
Google Cloud 架构框架中的本文档提供了自动执行构建、测试和部署的最佳实践。
自动化功能通过消除因代码更新等重复流程引起的人为错误,从而帮助您标准化构建、测试和部署。本部分介绍如何在自动化过程中使用各种检查和安全措施。标准化的机器控制过程有助于确保安全地应用您的部署。它还提供了一种机制,让您可以根据需要恢复先前的部署,而不会显著影响用户体验。
将代码存储在中央代码库中
将代码存储在中央代码库中,中央代码库包括一个带标记功能和回滚代码更改功能的版本控制系统。通过版本控制,您可以整理文件并控制整个团队和组织的访问、更新和删除。
对于不同的开发阶段,根据需要为代码库添加版本和标签。例如,标签可以是 test
、dev
和 prod
。
在 Google Cloud 中,您可以将代码存储在 Cloud Source Repositories 中,为其添加版本并将它们与其他 Google Cloud 产品集成。如果您要构建容器化应用,请使用容器的管理注册表 Artifact Registry。
如需详细了解版本控制,请参阅版本控制。如需详细了解如何使用代码库实现主干开发,请参阅主干开发。
使用持续集成和持续部署 (CI/CD)
使用持续集成和持续部署 (CI/CD) 方法实现部署自动化。CI/CD 方法是您配置的流水线和开发团队遵循的流程的组合。
CI/CD 方法可让您的软件开发团队提高工作效率,从而加快部署速度。通过这种方法,开发者可以更频繁地进行较小的更改并进行全面测试,同时减少部署这些更改所需的时间。
使用 CI/CD 方法时,自动执行构建、测试和部署代码过程中的所有步骤。例如:
- 每当新代码提交到代码库时,让提交自动调用构建并测试流水线。
- 自动执行集成测试。
- 自动执行您的部署,以便在构建满足特定测试条件之后再部署更改。
在 Google Cloud 中,您可以为 CI/CD 流水线使用 Cloud Build 和 Cloud Deploy。
使用 Cloud Build 帮助定义可用于打包和构建应用软件包的依赖项和版本。对构建配置进行版本控制,确保所有构建都保持一致并且在必要时可以回滚到上一个配置。
使用 Cloud Deploy 将应用部署到 Google Cloud 上的特定环境,并管理部署流水线。
如需详细了解如何实现 CI/CD,请参阅持续集成和部署自动化。
使用基础架构即代码预配和管理您的基础架构
基础架构即代码是指使用描述性模型来管理基础架构(如虚拟机)和配置(如防火墙规则)。通过基础架构即代码,您可以执行以下操作:
- 自动创建云资源,包括 CI/CD 流水线的部署或测试环境。
- 像处理应用更改一样处理基础架构更改。例如,确保对配置所做的更改已经过检查和测试,可以进行审核。
- 为云基础架构提供可靠的单个版本。
- 根据需要复制云环境。
- 如有必要,回滚到前一个配置。
这种基础架构即代码概念也适用于 Google Cloud 中的项目。您可以使用此方法来定义项目中的资源,例如共享 VPC 连接或 Identity and Access Management (IAM) 访问权限。如需查看此方法的示例,请参阅 Google Cloud 项目工厂 Terraform 模块。
Terraform 等第三方工具可帮助您在 Google Cloud 上自动创建基础架构。如需了解详情,请参阅使用 Terraform、Cloud Build 和 GitOps 以代码形式管理基础架构。
请考虑使用 Google Cloud 功能,例如项目安全锁、Cloud Storage 保留政策和 Cloud Storage 存储桶锁定,以防止关键资源遭受意外删除或恶意删除。
在整个软件交付生命周期内纳入测试
测试对于成功发布软件至关重要。持续测试有助于团队更快地创建高品质软件和增强软件稳定性。
测试类型:
- 单元测试。单元测试速度很快,可帮助您执行快速部署。您可以将单元测试视为代码库的一部分,并将其纳入构建流程中。
- 集成测试。集成测试非常重要,特别是对于旨在实现可扩缩性并依赖于多项服务的工作负载而言。当您测试与互连服务的集成时,这些测试可能会比较复杂。
- 系统测试。系统测试非常耗时且复杂,但可帮助您在部署之前识别边缘情况并解决问题。
- 其他测试。您还应运行其他测试,包括静态测试、负载测试、安全测试、政策验证测试等等。请先运行这些测试,然后再在生产环境中部署应用。
如需整合测试,请执行以下操作:
- 在软件交付生命周期内持续执行所有类型的测试。
- 自动执行这些测试,并将其纳入 CI/CD 流水线中。如果有任何测试失败,流水线便会失败。
- 持续更新并添加新测试以改进和维护部署的运营状况。
对于您的测试环境:
- 针对您拥有的每个测试环境使用单独的 Google Cloud 项目。对于每个应用,请使用单独的项目环境。这种分离可以清楚地区分生产环境资源与级别更低的环境的资源。这种分离有助于确保一个环境中的任何更改都不会意外影响到其他环境。
- 自动创建测试环境。实现此自动化的一种方法是使用基础架构即代码。
- 使用合成生产环境来测试更改。此环境提供一个类似生产的环境,用于测试您的应用并对您的工作负载执行各种测试,包括端到端测试和性能测试。
如需详细了解如何实现持续测试,请参阅测试自动化。
逐步启动部署
根据重要参数(例如最大限度地降低对最终用户造成的影响、滚动更新、回滚策略和 A/B 测试策略)选择部署策略。对于每个工作负载,请评估这些要求,并从经过验证的方法(例如滚动更新、蓝绿部署和 Canary 部署)中选择部署策略。
仅允许 CI/CD 流程在生产环境中进行更改和推送更改。
请考虑使用不可变基础架构。不可变基础架构是指未更改或未更新的基础架构。如果您需要在环境中部署新代码或更改任何其他配置,请将整个环境(例如,一组虚拟机或 Pod)替换为新环境。蓝绿部署是不可变基础架构的示例。
我们建议您执行 Canary 测试,并在部署更改时观察您的系统中是否存在任何错误。如果您有可靠的监控和提醒系统,则进行此类型的观察会更容易。如需执行 A/B 测试或 Canary 测试,您可以使用 Google Cloud 的代管实例组。然后,您可以执行缓慢发布,还可在必要时执行恢复。
请考虑使用 Cloud Deploy 自动执行部署并管理部署流水线。您还可以在 Google Cloud 上使用许多第三方工具(如 Spinnaker 和 Tekton)进行自动部署和创建部署流水线。
无缝恢复旧版本
将恢复策略定义为部署策略的一部分。确保您可以将部署或基础架构配置回滚到旧版源代码。恢复上一个稳定部署是管理可靠性和安全性突发事件的重要步骤。
同时确保您可以将环境恢复到部署过程开始之前所处的状态。这可能包括:
- 能够还原应用中的任何代码更改。
- 能够还原对环境所做的任何配置更改。
- 使用不可变基础架构并确保部署不会更改环境。这些做法可让您更轻松地还原配置更改。
监控 CI/CD 流水线
为确保自动化构建、测试和部署过程能够顺畅运行,请监控 CI/CD 流水线。设置提醒,指示流水线中发生故障。流水线的每个步骤都应编写合适的日志语句,以便您的团队可以在流水线发生故障时执行根本原因分析。
在 Google Cloud 中,所有 CI/CD 服务都与 Google Cloud Observability 集成。例如:
- Cloud Source Repositories 与 Pub/Sub 服务集成。
- Cloud Build 与 Pub/Sub 集成,它还会存储审核日志和构建日志。您可以使用 Cloud Monitoring 服务为构建日志中的某些关键字以及为许多其他指标设置提醒。
- Cloud Deploy 用于存储审核日志。
如需详细了解监控和日志记录,请参阅设置监控、提醒和日志记录。
安全地部署应用
查看架构框架的安全性、合规性和隐私权类别中的安全地部署应用部分。
制定版本发布的管理指南
为帮助工程师避免犯错以及实现高速软件交付,请务必明确记录用于发布新软件版本的管理指南。
发布工程师负责监督软件的构建和交付方式。发布工程的系统遵循以下四种做法:
自助模式。制定指南,帮助软件工程师避免常见错误。这些准则通常是在自动化过程中进行编码化。
频繁发布。快速发布有助于排查问题,更轻松地解决问题。频繁发布依赖于自动化单元测试。
封闭构建。确保与构建工具保持一致。对现在(与一个月前相比)用于构建版本的构建编译器进行版本控制。
强制执行政策。所有更改都需要经过代码审核,最好包含一系列准则和政策以加强安全性。强制执行政策可以改进代码审核、排查问题和测试新发布。
后续步骤
- 设置监控、提醒和日志记录(本系列的下一个文档)
- 架构框架的安全性、合规性和隐私权类别中的安全地部署应用。
- 查看构建容器的最佳实践
- 了解技术能力
- 探索架构框架中的其他类别,例如系统设计、安全、隐私权、合规性、可靠性、费用优化和性能优化。
设置监控、提醒和日志记录
Google Cloud 架构框架中的本文档介绍了如何设置监控、提醒和日志记录,以便您可以根据系统的行为采取行动。其中包括识别有意义的指标以及构建信息中心,以便更轻松地查看系统的相关信息。
DevOps 资源和评估 (DORA) 研究项目对监控的定义如下:
“收集、分析和使用信息跟踪应用和基础架构以指导业务决策的过程。监控是一项关键功能,因为它可以让您深入了解您的系统和工作。”
通过监控功能,服务所有者可以:
- 在服务更改影响性能时做出明智的决策
- 运用科学的方法应对突发事件响应
- 衡量服务与业务目标的一致性
设置好监控、日志记录和提醒功能后,您可以执行以下操作:
- 分析长期趋势
- 比较不同时间段内的实验
- 定义针对关键指标的提醒
- 构建相关的实时信息中心
- 执行回顾性分析
- 监控业务驱动的指标和系统健康状况指标
- 业务驱动的指标可帮助您了解您的系统对业务的支持程度。例如,使用指标可监控以下内容:
- 应用为用户提供服务所产生的费用
- 重新设计后网站流量的变化
- 客户在您的网站上购买产品所需的时间
- 系统健康状况指标可帮助您了解系统是否正常运行以及是否在可接受的性能水平内。
- 业务驱动的指标可帮助您了解您的系统对业务的支持程度。例如,使用指标可监控以下内容:
使用以下四个黄金信号来监控您的系统:
- 延迟时间。处理请求所需的时间。
- 数据流量。对您的系统的需求量。
- 错误数。请求失败率。失败可能很明确(例如 HTTP 500)、不明确(例如与错误内容耦合的 HTTP 200 成功响应)或根据政策而定(例如,如果您承诺的响应时间为一秒,则任何超过一秒的请求都是错误)。
- 饱和度。服务的饱和程度。饱和度用于衡量系统比例,凸显受限程度最高的资源(即在内存受限的系统中显示内存;在 I/O 受限的系统中显示 I/O)。
创建监控计划
创建与组织使命一致并遵循其运营策略的监控计划。在应用开发期间纳入监控和可观测性规划。在应用开发的早期纳入监控计划可以推动组织实现卓越运营。
在监控计划中包含以下详细信息:
- 包含所有系统,包括本地资源和云资源。
- 包含云费用监控功能,以帮助确保扩缩事件不会导致使用量超出预算阈值。
- 构建不同的监控策略来衡量基础架构性能、用户体验和业务关键绩效指标 (KPI)。例如,静态阈值可能非常适合用于测量基础架构性能,但并不能真正反映用户体验。
随监控策略的成熟度更新计划。对计划进行迭代以改进系统的健康状况。
定义用于衡量组织各个方面的指标
定义衡量部署行为所需的指标。为此,请执行以下操作:
- 定义业务目标。
- 确定哪些指标和 KPI 可以提供可量化信息来衡量性能。确保将您的指标定义转换为组织的所有方面 — 从业务需求(包括云费用)到技术组件。
- 使用这些指标为您的应用创建服务等级指标 (SLI)。如需了解详情,请参阅选择适当的 SLI。
各种组件的常见指标
系统会在所有服务等级(从基础架构和网络到业务逻辑)上都生成指标。例如:
- 基础架构指标:
- 虚拟机统计信息,包括实例、CPU、内存、利用率和计数
- 基于容器的统计信息,包括集群利用率、集群容量、pod 级别利用率和计数
- 网络统计信息,包括入站流量/出站流量、组件之间的带宽、延迟时间和吞吐量
- 每秒请求数,由负载均衡器测量
- 每个磁盘的读取的总磁盘块数
- 通过指定网络接口发送的数据包
- 给定流程的内存堆大小
- 响应延迟的分布
- 数据库实例拒绝的无效查询数
- 应用指标:
- 应用特有的行为,包括每秒查询次数、每秒写入次数和每秒发送的消息数
- 代管式服务统计信息指标:
- 由 Google 管理的服务(API 或 BigQuery、App Engine 和 Bigtable 等产品)的 QPS、吞吐量、延迟时间、利用率
- 网络连接统计信息指标:
- 有关连接到本地系统或 Google Cloud 外部系统的 VPN/互连相关统计信息。
- SLI
- 与系统整体健康状况相关的指标。
设置监控
设置监控以监控本地资源和云资源。
选择监控解决方案,它:
- 独立于平台
- 提供统一的功能来监控本地、混合云和多云环境
通过使用单个平台来整合来自不同来源的监控数据,您可以构建统一的指标和可视化信息中心。
设置监控时,尽可能自动执行监控任务。
使用 Google Cloud 进行监控
使用监控服务(如 Cloud Monitoring)比自行构建监控服务更容易。监控复杂应用本质上就是一项需要付出努力的重大工程。即使有现成的基础架构可用于插桩、收集和显示数据以及发出提醒,但对于构建和维护的员工而言,这是一份全职工作。
请考虑使用 Cloud Monitoring 深入了解本地资源和云端资源的应用和基础架构的性能、可用性和健康状况。
Cloud Monitoring 是一项托管式服务,它是 Google Cloud Observability 的一部分。您可以使用 Cloud Monitoring 来监控 Google Cloud 服务和自定义指标。Cloud Monitoring 提供用于与第三方监控工具集成的 API。
Cloud Monitoring 可将来自系统云端基础架构的指标、日志和事件汇总在一起。这些数据为开发者和运营人员提供一组丰富的可观测信号,可加快根本原因分析并缩短平均解决时间。您可以使用 Cloud Monitoring 来定义符合您业务目标并帮助您汇总、直观呈现和监控系统健康状况的提醒和自定义指标。
Cloud Monitoring 为云端和开源应用服务提供默认信息中心。借助指标模型,您可以使用强大的可视化工具定义自定义信息中心,并在 Metrics Explorer 中配置图表。
设置提醒
良好的提醒系统可以提高功能发布能力。它有助于比较不同时间段的性能,从而确定功能发布的速度或是否需要回滚功能发布。如需了解回滚,请参阅无缝恢复旧版本。
设置提醒时,请将提醒与关键指标直接对应。这些关键指标包括:
- 四个黄金信号:
- 延迟时间
- 流量
- 错误
- 饱和度
- 系统健康状况
- 服务使用情况
- 安全事件
- 用户体验
让提醒具有实用价值,最大限度地缩短解决时间。为此,对于每个提醒,请执行以下操作:
- 添加清晰的说明,包括说明受监控的对象及其对业务的影响。
- 提供立即采取行动所需的所有信息。如果需要点击几下并进行浏览才能理解提醒,则待命人员将难以采取行动。
- 定义各种提醒的优先级。
- 明确指出负责响应提醒的人员或团队。
对于关键应用和服务,请在因常见故障情况(例如服务健康状况故障、配置更改或吞吐量出现峰值)触发的提醒中构建自我修复操作。
设置提醒时,请尝试减少繁复操作。例如,通过消除经常发生的错误或自动修复这些错误以避免触发提醒,从而减少繁复操作。减少繁复操作可让待命人员专注于确保应用的运营组件可靠。如需了解详情,请参阅打造自动化文化。
构建监控和提醒信息中心
构建好监控后,您可以构建相关的简单信息中心,其中包括来自监控和提醒系统的信息。
选择适当的方法来直观呈现信息中心可能难以与可靠性目标联系起来。请创建信息中心以直观呈现:
- 短期和实时分析
- 长期分析
如需详细了解如何实现目视管理,请参阅功能文章目视管理。
为关键应用启用日志记录
日志记录服务对于监控系统至关重要。虽然指标是监控特定项目的基础,但日志包含您进行调试、安全相关分析和遵循合规性要求所需的有价值信息。
记录系统生成的数据有助于确保提高安全性。如需详细了解日志记录和安全性,请参阅架构框架的安全类别中的实现日志记录和检测控制。
Cloud Logging 是一项集成式日志记录服务,可用于存储、搜索、分析、监控日志数据和事件,并发出提醒。Cloud Logging 会自动从 Google Cloud 和其他云提供商的服务收集日志。您可以使用这些日志来构建监控指标,以及将日志记录导出到外部服务,例如 Cloud Storage、BigQuery 和 Pub/Sub。
设置审核跟踪
如需回答“哪些用户何时在何处对 Google Cloud 项目执行了什么操作”等疑问,请使用 Cloud Audit Logs。
Cloud Audit Logs 可捕获多种类型的活动,例如:
- 管理活动日志包含 API 调用或其他用于修改资源配置或元数据的操作对应的日志条目。管理员活动日志始终处于启用状态。
- 数据访问审核日志会记录用于创建、修改或读取用户提供的数据的 API 调用。数据访问审核日志默认处于停用状态,因为它们可能很大。您可以配置哪些 Google Cloud 服务生成数据访问日志。
如需查看可写入审核日志的 Google Cloud 服务的列表,请参阅具有审核日志的 Google 服务。使用 Identity and Access Management (IAM) 控件来限制哪些人员有权查看审核日志。
后续步骤
- 建立云支持和上报流程(本系列的下一个文档)。
- 探索 Google Cloud Observability。
- 部署 Cloud Monitoring 以深入了解您的应用和基础架构的性能、可用性和健康状况。
- 详细了解监控和可观测性。
- 探索架构框架中的其他类别,例如系统设计、安全、隐私权、合规性、可靠性、费用优化和性能优化。
请求云支持并建立上报流程
Google Cloud 架构框架中的本文档介绍了如何定义有效的上报流程。请求云提供商或其他第三方服务提供商提供支持是有效上报管理的关键环节。
Google Cloud 为您提供了各种支持渠道(包括实时支持),您也可以通过开发者社区或产品文档等已发布的指导获取支持。Cloud Customer Care 中的产品确保您可以使用 Google Cloud 高效地运行工作负载。
请求提供商提供支持
向云提供商或其他第三方服务提供商购买支持合同。支持对确保及时响应和解决各种运营问题至关重要。
如需使用 Google Cloud Customer Care,请考虑购买包含标准、增强或高级支持服务的 Customer Care 产品。请考虑在您的主要生产环境中使用增强或高级支持服务。
定义上报流程
明确定义的上报流程是减少识别和解决系统中的任何问题所耗费精力和时间的关键。其中包括需要支持 Google Cloud 产品或其他云提供方或第三方服务的问题。
如需创建上报路径,请执行以下操作:
- 定义在内部上报问题的时间和方式。
- 定义向云提供商或其他第三方服务提供商创建支持请求的时间和方式。
- 了解如何与为您提供支持的团队合作。对于 Google Cloud,您和您的运营团队应查看使用 Customer Care 的最佳实践。将这些实践纳入您的上报路径。
- 查找或创建描述架构的文档。确保这些文档包含对支持工程师很有帮助的信息。
- 定义您的团队在服务中断期间的沟通方式。
- 确保需要支持的人员具有适当级别的支持权限,以便访问 Google Cloud 支持中心或与其他支持提供商沟通。如需了解如何使用 Google Cloud 支持中心,请访问支持流程。
- 设置监控、提醒和日志记录,以便在出现问题时您拥有执行相应操作所需的信息。
- 创建用于报告突发事件的模板。如需了解要在突发事件报告中包含哪些信息,请参阅使用 Customer Care 的最佳实践。
- 记录贵组织的上报流程。确保您有清晰、明确定义的操作来解决上报问题。
- 制定方案以向新的团队成员传授如何与支持团队互动。
定期在内部测试上报流程。在发生重大事件(例如迁移、新产品发布和峰值流量事件)之前测试上报流程。如果您拥有 Google Cloud Customer Care 高级支持服务,则技术支持客户经理可以帮助审核您的上报流程,并使用 Google Cloud Customer Care 协调您的测试。
确保接收来自支持团队的信息
确保管理员正在接收来自云服务商和第三方服务的信息。借助这些信息,管理员可以做出明智的决策并解决问题,以免造成更大的问题。确保满足以下条件:
- 安全、网络和系统管理员已设置为接收来自 Google Cloud 和其他提供商或服务的重要电子邮件。
- 安全、网络和系统管理员已设置为接收由监控工具(如 Cloud Monitoring)生成的系统提醒。
- 项目所有者具有可路由的电子邮件地址的用户名,以便他们能够接收到重要电子邮件。
如需了解如何管理 Google Cloud 发出的通知,请参阅管理通知的联系人。
建立审核流程
建立审核流程或事后分析流程。发出新的支持服务工单或上报现有支持服务工单后,请按照这些流程操作。在事后分析过程中,请记录经验教训并跟踪应对措施。在此审核过程中,培养事后分析但不责罚文化。
如需详细了解事后分析,请参阅《事后分析文化:从失败中吸取经验教训》。
建立卓越中心
将组织的信息、经验和模式记录到内部知识库(例如,位于 Wiki、Google 网站或内网网站上的内部知识库)是一件非常有价值的事情。随着 Google Cloud 中不断推出新的产品和功能,这些知识可以帮助跟踪您为应用和服务选择特定设计的原因。如需了解详情,请参阅架构决策记录。
同样,还有一种比较好的做法是在您的组织中提名 Google Cloud 专家和倡导者。我们提供一系列培训和认证选项,以帮助被提名的倡导者在其专业领域不断发展。通过订阅 Google Cloud 博客,团队可以及时了解最新新闻、公告和客户案例。
后续步骤
管理容量和配额
Google Cloud 架构框架中的本文档介绍了如何评估和规划云端的容量和配额。
在传统数据中心中,您通常每个季度都需要花时间来审核当前的资源需求并预测未来的资源需求。您必须考虑物理、后勤和人力资源相关的问题。需要考虑的问题举例如下:机架空间、制冷、电力、带宽、布线、采购时间、运输时间以及可以安排多少工程师组装新设备。您还必须主动管理容量和工作负载分配,以防止资源密集型作业(例如 Hadoop 流水线)干扰必须保持高可用性的服务(例如网络服务器)。
相比之下,当您使用 Google Cloud 时,会将大部分容量规划转移到 Google。使用云意味着不需要空闲资源时,您无需预配和维护它们。例如,您可以根据需要创建、扩容和缩容虚拟机实例。由于您需要为所用资源付费,因此可以优化支出,包括仅在高峰流量期间需要的多余容量。为了帮助您节省费用,Compute Engine 会在检测到可调整大小或可删除的利用率过低的虚拟机实例时提供机器类型建议。
评估您的云容量需求
为了有效管理容量,您需要了解组织的容量需求。
如需评估您的容量要求,请先确定您的热门云工作负载。评估这些工作负载的平均利用率和峰值利用率,以及当前和未来的容量需求。
确定使用这些排名靠前的工作负载的团队。与他们合作建立内部需求规划流程。使用此过程来了解其当前和预测的云资源需求。
分析负载模式和呼叫分布。在分析中使用诸如以下因素:最近 30 天的峰值、每小时峰值和每分钟峰值。
请考虑使用 Cloud Monitoring 来深入了解应用和基础架构的性能、正常运行时间和整体健康状况。
查看基础架构利用率指标
为了使容量规划更轻松,请收集并存储有关您的组织使用云资源的历史数据。
确保您了解基础架构利用率指标。例如,对于排名靠前的工作负载,请评估以下内容:
- 平均利用率和峰值利用率
- 使用模式峰值
- 基于业务需求的季节性峰值(例如,零售业中的节假日)
- 为应对峰值事件做好准备并快速处理潜在流量高峰需要多少超额预配
确保您的组织已设置提醒,以便在您接近配额和容量限制时自动发送通知。
使用 Google 的监控工具可以深入了解应用使用情况和容量。例如,您可以使用 Monitoring 来定义自定义指标。使用这些自定义指标来定义提醒趋势。Monitoring 还会提供灵活的信息中心和丰富的可视化工具,以帮助发现紧急问题。
创建容量规划流程
建立容量规划流程并记录此方案。
创建此方案时,请执行以下操作:
- 运行负载测试,以确定在给定固定数量的资源的情况下,系统能够在满足其延迟时间目标的情况下处理多少负载。负载测试应混合使用与实时用户的生产流量配置文件匹配的请求类型。请勿使用统一或随机的混合操作。在流量配置文件中包括使用量峰值。
- 创建容量模型。容量模型是一组公式,用于计算服务负载每单位增加所需的增量资源(根据负载测试确定)。
- 预测未来流量并考虑增长情况。如需查看 Google 如何构建流量预测的摘要,请参阅文章衡量未来负载。
- 将容量模型应用于预测以确定未来的资源需求。
- 估算组织所需资源的费用。然后,获得财务组织的预算批准。此步骤至关重要,因为企业可以选择在一系列产品之间进行费用与风险权衡。这些权衡可能意味着根据业务优先级采购容量,该容量可能会低于或高于对给定产品的预测需求。
- 通过配额和预留,与云服务商合作,在适当的时间获取适当数量的资源。让基础架构团队参与容量规划,并让运营团队创建置信区间的容量规划。
- 每一两个季度重复执行上述步骤。
有关在优化资源用量的同时规划容量的过程更详细的指导,请参阅容量规划。
确保您的配额符合容量需求
Google Cloud 使用配额来限制您可以使用的特定共享 Google Cloud 资源的数量。每个配额代表一个特定的可数资源,例如对特定服务的 API 调用、您的项目并发使用的负载均衡器数量或者您可以创建的项目数量。例如,配额可确保少数客户或项目无法在特定区域或可用区独占 CPU 核心。
在检查配额时,请考虑以下详细信息:
- 提前规划项目的容量需求,以防止资源消耗发生意外限制。
- 设置配额和容量以处理整个区域的故障。
- 使用配额来限制特定资源的消耗。例如,您可以通过 BigQuery API 设置每日查询使用量最大配额,以确保项目在 BigQuery 上不会超支。
- 针对用量高峰进行规划,并在配额规划中将这些高峰考虑在内。用量高峰可能是一天中预期的波动、意外的峰值流量事件或已知的峰值流量和启动事件。如需详细了解如何规划峰值流量和启动事件,请参阅“运营卓越”中的下一部分:规划流量高峰和启动事件。
如果当前配额不足,您可以使用 Google Cloud 控制台管理配额。如果您需要大的容量,请与您的 Google Cloud 销售团队联系。但是,您应该知道许多服务也有一些与配额系统无关的限制,请参阅使用配额以了解详情。
定期审查您的配额。提前提交配额申请,使得在需要时可用。如需详细了解如何评估配额请求以及如何批准或拒绝请求,请参阅使用配额。
您可以通过多种方式查看和管理您的 Google Cloud 配额:
- 使用 Google Cloud 控制台
- 使用 Google Cloud CLI
- 使用 Service Usage API
- 使用 Monitoring 查看配额指标
- 如需管理组织或文件夹中许多 Google Cloud 项目的配额,请考虑实施配额监控信息中心解决方案。
后续步骤
- 规划峰值流量和发布事件(本系列的下一个文档)
- 探索架构框架中的其他类别,例如系统设计、安全、隐私权、合规性、可靠性、费用优化和性能优化。
规划高峰流量和发布事件
Google Cloud 架构框架中的本文档介绍了如何规划高峰流量和发布事件,以避免中断您的业务。
峰值事件是与业务相关的主要事件,导致流量激增,超出应用的标准基准。这些峰值事件需要计划内扩缩。
例如,拥有在线业务的零售商家预计会在节假日期间出现峰值事件。黑色星期五是美国感恩节的次日,属于一年中最繁忙的购物日之一。对于美国的医疗保健行业,由于福利登记的在线流量激增,10 月和 11 月可能会出现峰值事件。
发布事件是生产环境中新功能的任何重大发布或迁移事件。例如,从本地迁移到云,或者发布新的产品服务或功能。
如果您要发布新产品,则应该会预料到系统负载在公告期间和(可能情况下)之后有所增加。这些事件通常可能会导致前端系统的负载增加 5-20 倍(或更多)。增加的负载也会增加后端系统的负载。通常,这些前端和后端负载的特点是随着 Web 流量的事件打开而在短时间内快速扩容。发布事件涉及流量随后下降到正常水平。这种下降的速度通常比扩容到峰值的速度要慢。
峰值事件和发布事件包括三个阶段:
- 规划和准备发布或峰值流量事件
- 发布事件
- 查看事件性能和事件后分析
本文档中介绍的实践可以帮助每个阶段顺畅运行。
为发布和峰值事件创建常规 Playbook
构建一个常规 playbook,可以长期了解当前和未来的峰值事件。请继续向该文档添加获得的经验教训,以便可以作为未来峰值事件的参考。
规划发布和峰值事件
未雨绸缪。为即将进行的发布以及预期(和意外的)峰值事件创建业务预测。如何准备好系统以应对扩容峰值取决于您对业务预测的了解程度。对之前的预测了解得越透彻,针对新业务的预测就越准确。这些新预测是预测系统预期需求的关键输入。
在整个组织中以及与第三方供应商确定计划管理和协调规划也是成功的关键。请尽早建立相关团队,以便您的计划管理团队可以设置时间表、节省预算,以及为额外的基础架构、测试支持和培训收集资源。
建立清晰的沟通渠道非常重要。沟通对发布或峰值事件的所有阶段都至关重要。尽早讨论风险以及所关注的领域,并在问题成为障碍之前加以解决。创建事件规划文档。压缩有关峰值事件的最重要信息并分发。这样做有助于用户了解规划信息并解决基本问题。此外,新人也可以通过查阅该文档掌握有关峰值事件规划的详情。
记录针对每个事件的规划。在记录规划时,请确保执行以下操作:
- 识别任何假设、风险和未知因素。
- 审视过往事件,以确定即将进行的发布或峰值事件的相关信息。确定哪些数据可用以及这些数据在过去提供的价值。
- 详细说明发布事件和迁移事件的回滚计划。
- 执行架构审核:
- 记录关键资源和架构组件。
- 使用架构框架查看环境的所有方面以发现风险和规模问题。
- 创建展示架构主要组件如何连接的图表。您可以查看该图表以便隔离问题并更快地解决问题。
- 如果适用,请将服务配置为使用提醒操作,以便在发生故障时自动重启。使用 Compute Engine 时,请考虑使用自动扩缩来处理吞吐量高峰。
- 为确保 Compute Engine 资源在需要时可用,请使用预留。预留为获取 Compute Engine 可用区级资源的容量提供了极高保障。您可以使用预留来确保项目有可用资源。
- 识别要跟踪的指标和提醒:
- 识别要针对事件监控的业务和系统指标。如果未收集任何指标或服务等级指标 (SLI),请修改系统以收集此数据。
- 确保您有足够的监控和提醒功能,并且已审核正常和以前的峰值流量模式。确保正确设置提醒。 使用 Google Cloud Monitoring 工具查看应用使用情况、容量以及应用和基础架构的整体健康状况。
- 确保通过感兴趣的监控和提醒级别捕获系统指标。
- 与您的 Google Cloud 客户支持团队一起审核增加的容量要求,并规划所需的配额管理。如需了解详情,请参阅确保您的配额符合容量要求。
- 确保您能获享适当级别的云支持服务,您的团队了解如何发起支持请求,并已建立上报路径。如需了解详情,请参阅建立云支持和上报流程。
- 定义沟通计划、时间表和责任:
- 与跨职能利益相关方互动,以协调沟通和安排规划。这些利益相关方可包括来自技术、运营和领导团队以及第三方供应商的相应人员。
- 建立包含关键任务和拥有这些任务的团队的明确时间表。
- 建立责任分配矩阵 (RACI),以便传达团队、团队领导、利益相关方和责任方的所有权。
- 您可以使用高级支持服务的事件管理服务来管理计划的峰值事件。使用此服务时,客户服务团队与您的团队一起制定计划,并在整个活动过程中提供指导。
建立审核流程
当峰值流量事件或发布事件结束时,请查看该事件以记录经验教训。然后,根据这些经验教训更新您的 Playbook。最后,将经验教训运用到下一个重大事件中。从先前的事件中吸取经验教训很重要,尤其是在这些事件强调了系统在压力下的限制条件时。
对于峰值流量事件或发布事件,回顾性审核(也称为事后分析)是一种捕获数据和理解突发事件的实用方法。对于预期峰值流量和发布事件以及导致问题的任何突发事件,请完成此审核工作。在此过程中,请培养无责备文化。
如需详细了解事后分析,请参阅《事后分析文化:从失败中吸取经验教训》。
后续步骤
打造自动化文化
Google Cloud 架构框架中的本文档介绍了如何评估重复劳动并缓解其对系统和团队的影响。
重复劳动是指需要手动完成的重复性工作,这类工作没有持久的价值,并且工作量会随着服务的发展而增加。您应不断努力减少或消除费力的手动操作。 否则,运营工作最终可能会给运营人员带来巨大的压力,而产品使用或复杂性的任何增长都可能需要额外的人力。
自动化是最大限度地减少重复劳动的一个重要途径。自动化还可以提高发布速度并有助于最大限度地减少人为错误。
如需了解详情,请参阅消除重复劳动。
创建清单并评估重复劳动的费用
首先创建一份清单,并评估系统管理团队的重复劳动费用。这是一个持续的过程,然后致力于自定义自动化来扩展 Google Cloud 服务和合作伙伴已经提供的内容。通常,您可以修改 Google Cloud 自有的自动化功能,例如 Compute Engine 的自动扩缩器。
优先减少重复劳动
自动化很有用,但并不能解决所有运维问题。我们建议,在处理已知重复劳动时,第一步是查看现有重复劳动的清单,并优先消除尽可能多的重复劳动。然后,您可以专注于自动化。
自动完成必要的重复劳动
系统中的某些重复劳动无法消除。在处理已知重复劳动时,第二步是使用 Google Cloud 通过可配置的自动化功能提供的解决方案来自动执行此重复劳动。
以下是可配置自动化或自定义自动化功能可帮助您的组织消除重复劳动的一些方面:
- 身份管理,例如 Cloud Identity 和 Identity and Access Management。
- Google Cloud 托管的解决方案(与自行设计的解决方案不同),例如集群管理 (Google Kubernetes Engine (GKE))、关系型数据库管理 (Cloud SQL)、数据仓库管理 (BigQuery) 和 API 管理 (Apigee)。
- Google Cloud 服务和租户预配,例如 Terraform 和 Cloud Foundation Toolkit。
- 针对多步操作的自动工作流编排,例如 Cloud Composer。
- 额外的容量预配,例如 Compute Engine 和 GKE 等多款 Google Cloud 产品提供了可配置的自动扩缩功能。请评估您使用的 Google Cloud 服务,以确定它们是否包含可配置的自动扩缩功能。
- 具有自动部署功能的 CI/CD 流水线,例如 Cloud Build。
- 通过 Canary 分析来验证部署。
- 自动化模型训练(针对机器学习),例如 AutoML。
如果 Google Cloud 产品或服务只能部分满足自动执行或消除手动工作流的技术需求,请考虑通过您的 Google Cloud 客户代表提交功能请求。您的问题可能是其他客户优先考虑的问题或我们路线图的一部分。如果是这样,则了解该功能的优先级和时间轴有助于您更好地评估构建自己的解决方案与等待使用 Google Cloud 功能之间的权衡。
为费用高昂的重复劳动构建或购买解决方案
第三步可以与第一步和第二步同时完成。如果您的重复劳动费用较高(例如重复劳动会耗费任何管理您生产系统的团队大量时间),则第三步需要评估构建或购买其他解决方案。
在构建或购买解决方案时,请考虑集成、安全、隐私权与合规费用。除了最初的开发和设置费用之外,设计和实现您自己的自动化功能还会产生维护费用和可靠性风险,因此请在迫不得已时才考虑此方式。
后续步骤
探索架构框架中的其他类别,例如系统设计、安全、隐私权、合规性、可靠性、费用优化和性能优化。
Google Cloud 架构框架:安全性、隐私权和合规性
Google Cloud 架构框架中的此类别介绍了如何在 Google Cloud 上设计安全服务的架构和运营安全服务。此外,您还将了解支持安全性和合规性的 Google Cloud 产品和功能。
该架构框架介绍了最佳实践,提供了实现建议,并说明了一些可用的产品和服务。该框架可帮助您设计 Google Cloud 部署,以便它能够满足您的业务需求。
将工作负载迁移到 Google Cloud 需要评估您的业务要求、风险、法规遵从义务和安全控制机制。本文档可帮助您考虑与 Google Cloud 中的安全解决方案设计相关的关键最佳实践。
Google 核心原则包括大规模的默认深度防御。在 Google Cloud 中,通过多层防御机制并使用通过 IAM、加密、网络、检测、日志记录和监控功能配置的各项政策和控制机制来保护数据和系统。
Google Cloud 附带了许多安全控制机制,您可以基于这些机制进行构建,例如:
- 适合传输中的数据的安全方案,以及静态数据的默认加密方法。
- Google Cloud 产品和服务的内置安全功能。
- 专为地理位置冗余设计的全球基础架构,在整个信息处理生命周期中纳入了安全控制机制。
- 使用基础架构即代码 (IaC) 和配置安全措施的自动化功能。
如需详细了解 Google Cloud 的安全态势,请参阅 Google 安全白皮书和 Google 基础架构安全设计概览。如需查看原生安全环境示例,请参阅 Google Cloud 企业基础蓝图。
在架构框架的安全性类别中,您将了解如何执行以下操作:
- 在 Google Cloud 上查看共担责任和命运共同体
- 了解安全原则
- 利用控件来管理风险
- 管理资产
- 管理身份和访问权限
- 实现计算和容器安全
- 保护您的网络
- 实现数据安全
- 部署应用安全保障
- 管理法规遵从义务
- 实现数据驻留和主权要求
- 实现隐私权要求
- 实现日志记录和检测控制
Google Cloud 上的共担责任和命运共同体
本文档介绍了 Google Cloud 中共担责任模型和命运共同体之间的差异。文中讨论了共担责任模型的挑战和细微差别。本文档介绍了什么是命运共同体,以及我们如何与客户合作解决云安全挑战。
在确定如何最好地保护 Google Cloud 上的数据和工作负载时,了解共担责任模型非常重要。共担责任模型描述了在云端涉及安全性时的任务,以及这些任务对于云提供商的不同之处。
但是,了解共担责任可能具有挑战性。此模型需要深入了解您使用的每项服务、每项服务提供的配置选项,以及 Google Cloud 为保护该服务而执行的操作。每项服务都有不同的配置文件,并且可能很难确定最佳安全配置。Google 认为,共担责任模型无法帮助云客户获得更好的安全结果。我们依靠命运共同体,而不是共担责任。
共同命运体包括要我们可帮助您为工作负载构建和运营受信任的云平台。我们提供最佳做法指导和安全的经过证明的基础架构代码,可用于以安全方式部署工作负载。我们发布了各种 Google Cloud 服务解决方案,以解决复杂的安全问题,并提供创新的保险方案,帮助您衡量和缓解必须接受的风险。在您保护 Google Cloud 上的资源时,命运共同体的关键在于我们能够更密切地与您互动。
共担责任
您非常了解企业的安全和监管要求,也非常了解保护机密数据和资源的要求。在 Google Cloud 上运行工作负载时,必须确定您需要在 Google Cloud 中配置的安全控制措施,以帮助保护机密数据和每个工作负载。如需确定要实现的安全控制措施,您必须考虑以下因素:
- 法规遵从义务
- 组织的安全标准和风险管理计划
- 客户和供应商的安全要求
由工作负载定义
传统上,责任是根据您运行的工作负载类型和所需的云服务定义的。云服务包括以下类别:
云服务 | 说明 |
---|---|
基础架构即服务 (IaaS) | IaaS 服务包括 Compute Engine、Cloud Storage 以及 Cloud VPN、Cloud Load Balancing 和 Cloud DNS 等网络服务。 IaaS 以随用随付的价格提供计算、存储和网络服务。如果您计划使用直接原样迁移将现有本地工作负载迁移到云端,或者希望使用特定数据库在特定虚拟机上运行应用,则可以使用 IaaS:网络配置。 在 IaaS 中,大部分安全责任属于您,我们的责任侧重于底层基础架构和物理安全。 |
平台即服务 (PaaS) | PaaS 服务包括 App Engine、Google Kubernetes Engine (GKE) 和 BigQuery。 PaaS 提供了您可以在其中开发和运行应用的运行时环境。如果您正在构建应用(例如网站),并且希望专注于开发而不是底层基础架构,则可以使用 PaaS。 在 PaaS 中,我们负责比 IaaS 中更多的控制,包括网络控制。您与我们负责应用级控制和 IAM 管理。您仍需负责您的数据安全和客户端保护。 |
软件即服务 (SaaS) | SaaS 应用包括 Google Workspace、Chronicle 和 Google Cloud Marketplace 中提供的第三方 SaaS 应用。
SaaS 提供在线应用,您可以通过某种方式订阅或付费。如果您的企业对构建应用本身不具备内部专业知识或业务需求,但需要处理工作负载的能力,则可以使用 SaaS 应用。 在 SaaS 中,我们担负大部分安全责任。您仍需负责您的访问权限控制以及您选择存储在应用中的数据。 |
函数即服务 (FaaS) 或无服务器 | FaaS 为开发者提供了运行单一用途的小型代码(称为函数)的平台,用于响应特定事件。如果您希望特定事件发生特定情况,则可以使用 FaaS。例如,您可以创建一个函数,该函数在数据上传到 Cloud Storage 时就会运行以便对其进行分类。 FaaS 具有与 SaaS 类似的共担责任列表。Cloud Functions 是一种 FaaS 应用。 |
下图展示了云服务并定义了云提供商与客户应如何共担责任。
如图所示,云提供商始终负责底层网络和基础架构,并且客户始终负责其访问政策和数据。
由行业和监管框架定义
各个行业都有监管框架,用于定义必须落实的安全控制措施。将工作负载迁移到云端时,您必须了解以下内容:
- 哪些安全控制措施由您负责
- Cloud 产品提供哪些安全控制措施
- 继承的默认安全控制有哪些
继承的安全控制措施(例如我们的默认加密和基础架构控制)是您可以作为安全状况证据的一部分提供给审计员和监管机构的控制措施。例如,支付卡行业数据安全标准 (PCI DSS) 定义了付款处理方的法规。将业务迁移到云端后,这些法规会在您和 CSP 之间共享。如需了解如何在您与 Google Cloud 之间共担 PCI DSS 责任,请参阅 Google Cloud:PCI DSS 共担责任表。
再举一个例子,在美国,《健康保险流通与责任法案》(HIPAA) 规定了处理电子个人健康信息 (PHI) 的标准。这些责任还会在 CSP 与您之间共担。如需详细了解 Google Cloud 如何履行了 HIPAA 规定的责任,请参阅 HIPAA - 合规性。
其他行业(例如金融或制造)也有法规来规定收集、处理和存储数据的方式。如需详细了解与这类事项相关的共担责任以及 Google Cloud 如何履行我们的责任,请参阅合规性资源中心。
由位置定义
根据您的业务场景,您可能需要根据公司办公室的位置、客户和数据来考虑您的职责。不同的国家和地区制定了相应的法规,指导您如何处理和存储客户数据。例如,如果您的企业有欧盟境内的客户,则您的企业可能需要遵守一般数据保护条例中所述的要求 (GDPR),您可能有义务将客户数据保存在欧盟境内。 在这种情况下,您需负责确保您收集的数据会保留在欧盟的 Google Cloud 区域中。如需详细了解我们如何履行 GDPR 义务,请参阅 GDPR 和 Google Cloud。
如需了解与您的区域相关的要求,请参阅符合的法规和标准。 如果您的场景特别复杂,建议您与我们的销售团队或我们的合作伙伴联系,以帮助您评估安全责任。
共担责任所面临的挑战
虽然共担责任有助于定义您或云提供商具有的安全角色,但依赖共担责任仍然可以产生挑战。以下面几种情况为例:
- 大多数云安全事故都属于配置错误直接导致的结果(在 Cloud Security Alliance 的 Pandemic 11 报告中被列为编号 3),此趋势预计会增加。云产品不断变化,并且新产品也在不断发布。跟上不断变化似乎很困难。客户需要云服务提供商为他们提供可靠的最佳做法,以帮助其适应变化,从默认的最佳做法开始,并具有基准安全配置。
- 虽然按云服务划分内容非常有用,但许多企业的工作负载需要多种云服务类型。在这种情况下,您必须考虑这些服务的各种安全控制措施如何交互,包括它们在服务之间是否重叠。例如,您可能有一个要迁移到 Compute Engine 的本地应用,使用 Google Workspace 处理公司电子邮件,同时运行 BigQuery 来分析数据以改进您的产品。
- 随着法规的改变,当您进入新市场或者是收购其他公司时,您的业务和市场都会不断变化。您的新市场可能有不同的要求,而新的收购可能会将其工作负载托管在另一个云平台上。为了管理不断变化,您必须不断重新评估您的风险概况,并能够快速实施新的控制措施。
- 数据加密密钥的管理方式和位置是与您保护数据职责相关的重要决策。您选择的选项取决于您的监管要求(无论您是运行混合云环境还是仍然具有本地环境),以及您要处理和存储的数据的敏感性。
- 事件管理是一项重要而又经常被忽视的领域,在此您的责任和云服务商责任不易定义。许多事件都需要云提供商密切合作和支持,以帮助调查和缓解它们。其他事件可能由于云资源配置不当或凭据被盗而造成,并且确保您满足保护资源和账号的最佳做法非常困难。
- 高级持续威胁 (APT) 和新漏洞会影响您开始云转换时可能不会考虑的工作负载。确保您及时了解最新的变化情况并负责威胁缓解工作,尤其是在您的企业没有大型安全团队的情况下。
命运共同体
我们在 Google Cloud 中开发了命运共同体,以开始解决共担责任模型无法解决的难题。命运共同体希望侧重于所有各方可以更好地互动,以持续提高安全性。 命运共同体基于共担责任模型,因为它将云提供商与客户之间的关系视为持续改善的合作伙伴关系。
命运共同体就是要我们负责确保 Google Cloud 更安全。命运共同体包括帮助您从安全的着陆可用区开始,并清晰、明确、公开地介绍推荐的安全控制措施、设置和关联的最佳做法。它包括使用我们的风险防范计划,帮助您更好地量化和管理网络保险的风险。通过命运共同体,我们希望从标准的共担责任框架转变为更好的模型,帮助您保护企业并在 Google Cloud 中建立信任。
以下部分介绍了命运共同体的各种组件。
使用入门帮助
命运共同体的一个重要组件是我们提供的资源,可帮助您在 Google Cloud 中以安全配置入门。从安全配置开始有助于减少配置错误的问题,而配置错误是大多数安全事故的根本原因。
资源包括以下内容:
- 企业基础蓝图:讨论主要安全问题和我们的主要建议。
安全蓝图:可让您使用基础架构即代码 (IaC) 部署和维护安全解决方案。蓝图默认启用我们的安全建议。许多蓝图由 Google 安全团队创建并作为产品进行管理。此支持意味着它们会定期更新,通过严格的测试流程,并获得了第三方测试组的证明。蓝图包括企业基础蓝图、安全数据仓库蓝图和 Vertex AI Workbench 笔记本蓝图。
着陆可用区导航指南,逐步介绍了为工作负载构建安全基础所需做出的主要决策,包括资源层次结构、身份入门、安全性密钥管理和网络结构。
Risk Protection Program
命运共同体还包括风险防护计划(目前为预览版),可帮助您将 Google Cloud 的强大功能用作管理风险的平台,而不仅仅是查看将云工作负载作为您需要管理的风险的另一个来源。风险防护计划是 Google Cloud 和两家领先的网络保险公司 Munich Re 和 Allianz Global & Corporate Speciality 的合作项目。
风险防护计划包含 Risk Manager,它提供数据驱动的数据分析,可用于更好地了解云安全状况。如需寻找网络承保责任范围,您可以直接与我们的保险合作伙伴分享来自 Risk Manager 的数据洞见,以获取报价。如需了解详情,请参阅 Google Cloud 风险防护计划现提供预览版。
部署和治理方面的帮助
命运共同体还有助于您持续治理环境。例如,我们专注并致力于如下产品:
- Assured Workloads,可帮助您履行合规性义务。
- Security Command Center Premium,使用威胁情报、威胁检测、Web 扫描和其他高级方法监控并检测威胁。它还提供了一种快速自动解决许多此类威胁的方法。
- 组织政策和资源设置,可让您在整个文件夹和项目的层次结构中配置政策。
- Policy Intelligence 工具,可让您深入了解账号和资源的访问权限。
- 机密计算:可用于加密使用中的数据。
- Sovereign Cloud,适用于德国,并实现数据驻留要求。
实践共担责任和命运共同体
在规划流程中,请考虑以下操作,以帮助您理解和实施适当的安全控制措施:
- 创建将在 Google Cloud 中托管的工作负载类型的列表,以及它们是否需要 IaaS、PaaS 和 SaaS 服务。您可以使用共担责任图作为核对清单,以确保您了解需要考虑的安全控制措施。
- 创建您必须遵守的监管要求列表,并访问合规性资源中心中与这些要求相关的资源。
- 查看架构中心的可用蓝图和架构列表,了解特定工作负载所需的安全控制措施。蓝图提供推荐控制措施的列表以及部署该架构所需的 IaC 代码。
- 使用着陆区文档和企业基础指南中的建议来设计符合您需求的资源层次结构和网络架构。您可以使用专用的工作负载蓝图(如安全数据仓库)来加快开发过程。
- 部署工作负载后,请使用 Risk Manager、Assured Workloads、Policy Intelligence 工具和 Security Command Center Premium 等服务验证您是否履行了安全责任。
如需了解详情,请参阅 CISO 的云转型指南论文。
后续步骤
- 查看安全原则(本系列的下一个文档)。
- 及时了解命运共同体资源。
- 熟悉可用的蓝图,包括安全基础蓝图和安全数据仓库等工作负载示例。
- 详细了解命运共同体。
- 阅读 Google 基础架构安全设计概览,了解我们的底层安全基础架构。
- 了解如何在 Google Cloud 中实施 NIST Cybersecurity Framework 最佳实践 (PDF)。
安全原则
Google Cloud 架构框架中的本文档介绍了在 Google Cloud 上运行安全且合规的服务需遵循的一些核心原则。您所熟悉的适用于本地环境的许多安全原则同样也适用于云环境。
构建分层安全方法
通过应用深度防御方法,在应用和基础架构的每个层级实施安全措施。使用每个产品中的功能来限制访问并在适当的情况下配置加密。
针对安全的分离系统进行设计
尽可能简化系统设计以适应灵活性,并记录每个组件的安全要求。纳入强大的安全机制以兼顾弹性和恢复能力。
自动部署敏感任务
通过自动执行部署和其他管理任务,免除人工对工作流的处理。
自动执行安全监控
使用自动化工具监控您的应用和基础架构。如需扫描基础架构中的漏洞并检测安全突发事件,请在持续集成和持续部署 (CI/CD) 流水线中使用自动扫描。
满足区域的合规性要求
请注意,您可能需要模糊或隐去个人身份信息 (PII),以满足您的监管要求。尽可能自动执行合规性工作。例如,使用 Sensitive Data Protection 和 Dataflow 自动执行个人身份信息隐去作业,然后再将新数据存储在系统中。
遵守数据驻留和主权要求
可能会存在内部或外部的要求,需要您控制数据存储和处理的位置。这些要求会因系统设计目标、行业监管问题、国家法律、税务影响和文化而异。数据驻留描述数据的存储位置。为遵守数据驻留要求,Google Cloud 允许您控制数据的存储位置、访问方式和处理方式。
优先确保安全
DevOps 和部署自动化使您的组织可以提高交付产品的速度。为了帮助确保您的产品安全无虞,请从开发流程最初便纳入安全流程。例如,您可以执行以下操作:
- 在部署流水线的早期阶段测试代码中的安全问题。
- 持续扫描容器映像和云基础架构。
- 自动检测配置错误和安全性相关的各种错误模式。例如,使用自动化功能查找在应用或配置中硬编码的 Secret。
后续步骤
使用以下资源详细了解核心安全原则:
利用控制来管理风险
Google Cloud 架构框架中的本文档介绍了管理云部署中的风险的最佳实践。通过仔细分析适用于组织的风险,您可以确定所需的安全控制机制。在 Google Cloud 上部署工作负载之前,您应该先完成风险分析,并在此后根据业务需求、监管要求以及与组织更改相关的威胁定期进行风险分析。
识别组织的风险
在 Google Cloud 上创建和部署资源之前,请先完成风险评估,以确定您需要哪些安全功能才能满足内部安全要求以及外部监管要求。风险评估为您提供了一系列与您相关的风险,并告诉您组织在检测和应对安全威胁方面的能力。
由于您与云提供商签订了共担责任方案,因此云环境中的风险与本地环境中的风险有所不同。例如,在本地环境中,您需要减少硬件堆栈的漏洞。相反,在云环境中,这些风险由云提供商承担。
此外,您的风险会有所不同,具体取决于您计划如何使用 Google Cloud。您是将部分工作负载还是全部工作负载转移到 Google Cloud?您是否将 Google Cloud 仅用于灾难恢复?您是否要设置混合云环境?
我们建议您使用适用于云环境和监管要求的行业标准风险评估框架。例如,云安全联盟 (CSA) 提供了 Cloud Controls Matrix (CCM)。此外,还存在 OWASP 应用威胁建模等威胁模型,其中提供了潜在漏洞列表以及用来补救发现的任何漏洞的建议操作。您可以查看我们的合作伙伴名录,获取针对 Google Cloud 进行风险评估的专家列表。
为了给风险编制目录,请考虑使用 Risk Manager,它是 Risk Protection Program 的一部分。(此计划目前处于预览版阶段。)Risk Manager 会扫描工作负载,以帮助您了解业务风险。它的详细报告提供了一个安全基准。此外,您还可以使用 Risk Manager 报告将您的风险与互联网安全中心 (CIS) 发布的基准中所述的风险进行比较。
为风险编制目录后,您必须确定如何解决这些风险,也就是说,您要接受、避免、转移还是缓解风险。以下部分介绍了应对措施控制机制。
缓解风险
您可以使用技术控制、合同保护以及第三方验证或证明来缓解风险。下表列出了当您采用新的公有云服务时如何使用这些应对措施。
应对措施 | 说明 |
---|---|
技术控制 | 技术控制是指您用于保护环境的功能和技术。其中包括内置的云安全控制机制,例如防火墙和日志记录。技术控制还可包括使用第三方工具来加强或支持您的安全策略。 技术控制分为两类:
|
合同保护 | 合同保护是指我们针对 Google Cloud 服务作出的法律承诺。 Google Cloud 致力于维护和扩展我们的合规产品组合。 云端数据处理附录 (CDPA) 文档定义了我们对维护 ISO 27001、27017 和 27018 认证以及每 12 个月更新一次 SOC 2 和 SOC 3 报告的承诺。 DPST 文档还概述了现有的访问权限控制机制,用来限制 Google 支持工程师对客户环境的访问权限,并介绍了我们严格的日志记录和批准流程。 建议您在查看 Google Cloud 的合同控制时咨询法律和法规专家,并验证它们是否满足您的要求。如需了解详情,请与您的技术客户代表联系。 |
第三方验证或证明 | 第三方验证或证明是指让第三方供应商审核云服务商,以确保云服务商满足合规性要求。例如,第三方曾经针对 ISO 27017 合规性对 Google 进行了审核。 您可以在合规性资源中心查看当前的 Google Cloud 认证和证明函。 |
后续步骤
通过以下资源详细了解风险管理:
- 管理资产(本系列的下一个文档)
管理资产
Google Cloud 架构框架中的本文档提供了管理资产的最佳实践。
资产管理是业务需求分析的重要组成部分。您必须知道您拥有哪些资产,并且必须充分了解所有资产、资产的价值以及与其相关的所有关键路径或流程。您必须先拥有准确的资产库存,然后才能设计任意类型的安全控制措施来保护您的资产。
为了管理安全突发事件并满足组织的监管要求,您需要拥有准确且最新的资产库存,该库存将提供用以分析历史数据的方法。您必须能够跟踪资产,包括其风险暴露随时间变化的情况。
迁移到 Google Cloud 意味着您需要修改资产管理流程以适应云环境。例如,迁移到云端的一个好处是可以提高组织快速扩缩的能力。但是,快速扩缩的能力可能会导致影子 IT 问题,也就是说您的员工可能会创建未经正确管理和保护的云资源。因此,您的资产管理流程在为员工提供足够的灵活性来完成工作的同时,也必须提供适当的安全控制措施。
使用云资产管理工具
Google Cloud 资产管理工具专门针对我们的环境和顶级客户使用场景而量身定制。
其中一个工具是 Cloud Asset Inventory,它为您提供有关资源当前状态的实时信息以及 5 周的历史记录。通过使用此服务,您可以为各种 Google Cloud 资源和政策获取组织范围的清单快照。然后,自动化工具可以使用快照进行监控或强制执行政策,或者归档快照以进行合规性审核。如果您要分析对资产的更改,则资产清单还可让您导出元数据历史记录。
如需详细了解 Cloud Asset Inventory,请参阅用于响应资产变化的自定义解决方案和检测控制。
自动执行资产管理
Automation 允许您根据指定的安全要求快速创建和管理资产。您可以通过以下方式自动执行资产生命周期的各个阶段:
- 使用 Terraform 等自动化工具部署您的云基础架构。Google Cloud 提供了企业基础蓝图,可帮助您部署符合安全最佳实践的基础设施资源。此外,它还会在 Cloud Asset Inventory 中配置资产更改和政策合规性通知。
- 使用 Cloud Run 和 Artifact Registry 等自动化工具部署您的应用。
监控偏离合规性政策的情况
资产生命周期的所有阶段都可能会出现偏离政策的情况。例如,创建的资产可能没有适当的安全控制措施,或者其特权可能被提升了。同样,资产可能会在没有遵循适当的服务终止流程的情况下被废弃。
为了帮助避免这些情况,我们建议您监控资产偏离合规性的情况。您需要监控的资产集取决于您的风险评估结果和业务需求。如需详细了解如何监控资产,请参阅监控资产更改。
与现有资产管理监控系统集成
如果您已经在使用 SIEM 系统或其他监控系统,请将您的 Google Cloud 资产与此类系统集成。集成可确保您的组织可通过单一界面全面了解所有资源,而无论其所处环境如何。如需了解详情,请参阅将 Google Cloud 安全数据导出到 SIEM 系统和 Cloud Logging 数据导出场景:Splunk。
使用数据分析来丰富监控功能
您可以将清单导出到 BigQuery 表或 Cloud Storage 存储桶以进行额外的分析。
后续步骤
详细了解如何使用以下资源管理您的资产:
管理身份和访问权限
Google Cloud 架构框架中的本文档提供了管理身份和访问权限的最佳实践。
身份和访问权限管理(通常称为 IAM)的实践有助于确保适当的人员可访问适当的资源。IAM 解决了身份验证和授权的以下几个方面:
- 账号管理,包括预配
- 身份治理
- 身份验证
- 访问权限控制(授权)
- 身份联合
如果您有不同的环境或使用多个身份提供商,则管理 IAM 可能会比较困难。但是,设置一个既能满足您的业务需求又能降低风险的系统至关重要。
本文档中的建议可帮助您查看当前 IAM 政策和流程,并确定可能需要为 Google Cloud 中的工作负载修改哪些政策和程序。例如,您必须查看以下内容:
- 您是否可以使用现有群组管理访问权限,或者是否需要创建新群组。
- 您的身份验证要求(例如,使用令牌进行多重身份验证 (MFA))。
- 服务账号对当前政策的影响。
- 如果您要使用 Google Cloud 进行灾难恢复,请保持适当的职责分离。
在 Google Cloud 中,您可以使用 Cloud Identity 对用户和资源进行身份验证,并使用 Google 的Identity and Access Management (IAM)产品来指定资源访问权限。管理员可以在组织、文件夹、项目和资源级层限制访问权限。Google IAM 政策指定哪些用户可以对哪些资源执行什么操作。正确配置的 IAM 政策有助于防止未经授权的资源访问,从而保护您的环境。
如需了解详情,请参阅身份和访问权限管理概览。
使用单个身份提供商
我们的许多客户拥有的用户账号都是由 Google Cloud 以外的身份提供商管理和预配。Google Cloud 支持与大多数身份提供商和本地目录(如 Active Directory)进行联合。
大多数身份提供商都允许您为用户和群组启用单点登录 (SSO)。对于您在 Google Cloud 上部署的应用以及使用外部身份提供商的应用,您可以将身份提供商扩展到 Google Cloud。如需了解详情,请参阅参考架构和在混合环境中对企业用户进行身份验证所采用的模式。
如果您没有现成的身份提供商,则可以使用 Cloud Identity 专业版或 Google Workspace 来管理员工的身份。
保护超级用户账号
超级用户账号(由 Google Workspace 或 Cloud Identity 管理)可让您创建 Google Cloud 组织。因此,超级用户账号具有较高的特权。此账号的最佳实践包括以下几个方面:
- 为此目的创建一个新账号;请勿使用现有用户账号。
- 创建和保护备份账号。
- 启用 MFA。
如需了解详情,请参阅超级用户账号最佳实践。
规划服务账号的使用
服务账号是应用用来调用服务的 Google API 的 Google 账号。
与用户账号不同,服务账号在 Google Cloud 中创建和管理。服务账号的身份验证方式也与用户账号不同:
- 若要使 Google Cloud 上运行的应用使用服务账号进行身份验证,您可以将服务账号与运行该应用的计算资源相关联。
- 若要使 GKE 上运行的应用使用服务账号进行身份验证,您可以使用 Workload Identity。
- 若要使在 Google Cloud 外部运行的应用使用服务账号进行身份验证,您可以使用工作负载身份联合。
使用服务账号时,您必须在设计过程中考虑适当的职责分离。请记下您必须进行的 API 调用,并确定 API 调用所需的服务账号和关联角色。例如,如果要设置 BigQuery 数据仓库,您可能至少需要为以下流程和服务提供身份:
- Cloud Storage 或 Pub/Sub,具体取决于您是提供批量文件还是创建流式服务。
- Dataflow 和敏感数据保护,用于对敏感数据进行去标识化处理。
如需了解详情,请参阅使用服务账号的最佳实践。
更新云的身份流程
通过身份治理,您可以跟踪访问权限、风险和违反政策的行为,以便支持法规要求。此治理要求您具有适当的流程和政策,以便可以向用户授予并审核访问权限控制角色和权限。您的流程和政策必须反映您的环境要求,例如测试、开发和生产环境。
在 Google Cloud 上部署工作负载之前,请先查看您当前的身份流程并根据需要进行更新。请务必根据组织所需的账号类型进行适当的规划,并确保您充分了解账号角色和访问权限要求。
为帮助您审核 Google IAM 活动,Google Cloud 会创建审核日志,其中包括以下内容:
- 管理员活动。无法停用此日志记录。
- 数据访问活动。您必须启用此日志记录。
为确保合规性,或者您想设置日志分析(例如,通过 SIEM 系统),您可以导出日志。由于日志可能会增加存储空间要求,因此可能会影响费用。请务必仅记录所需的操作,并设置适当的保留时间表。
设置单点登录和多重身份验证 (MFA)
您的身份提供商负责管理用户账号身份验证。联合身份可以使用单点登录向 Google Cloud 进行身份验证。对于具有特权的账号(例如超级用户),您应配置 MFA。Titan 安全密钥是物理令牌,可用于双重验证 (2FA) 以帮助防范钓鱼式攻击。
Cloud Identity 支持使用各种方法执行多重身份验证。如需了解详情,请参阅对访问公司资源的用户统一执行多重身份验证。
Google Cloud 支持使用 OAuth 2.0 协议或签名的 JSON 网络令牌 (JWT) 对 Workload Identity 进行身份验证。如需详细了解 Workload Identity 身份验证,请参阅身份验证概览。
实现最小权限和职责分离
您必须确保相应人员仅访问执行作业所需的资源和服务。也就是说,您应该遵循最小权限原则。此外,您还必须确保存在适当的职责分离。
过度预配用户访问权限可能会增加内部人员威胁、资源配置错误以及不符合审核要求的风险。如果权限预配不足,则用户可能无法访问完成任务所需的资源。
避免过度预配的一种方法是实现即时特权访问权限 — 仅根据需要提供特权访问权限,并且仅暂时授予该权限。
请注意,创建 Google Cloud 组织后,系统会默认为您网域中的所有用户授予 Billing Account Creator 和 Project Creator 角色。确定将会履行这些职责的用户,并撤消其他用户的这些角色。如需了解详情,请参阅创建和管理组织。
如需详细了解角色和权限在 Google Cloud 中的运作方式,请参阅 IAM 文档中的概览和了解角色。如需详细了解如何强制执行最小权限,请参阅使用角色建议强制执行最小权限。
审核访问权限
如需监控具有特权的账号的活动是否违反批准的条件,请使用 Cloud Audit Logs。Cloud Audit Logs 可记录您的 Google Cloud 组织成员在您的 Google Cloud 资源中执行的操作。您可以在各种 Google 服务中使用各种审核日志类型。如需了解详情,请参阅使用 Cloud Audit Logs 来管理内部人员的风险(视频)。
使用 IAM Recommender 跟踪使用情况并根据需要调整权限。IAM Recommender 推荐的角色可以帮助您根据用户过去的行为和其他条件来确定向用户授予哪些角色。如需了解详情,请参阅角色建议的最佳实践。
如需审核并控制 Google 支持和工程团队对您的资源的访问,您可以使用 Access Transparency。Access Transparency 可记录 Google 员工执行的操作。使用 Access Approval(Access Transparency 的一部分)在每次访问客户内容时授予明确批准。如需了解详情,请参阅控制云管理员对数据的访问。
自动执行政策控制功能
尽可能以编程方式设置访问权限。如需了解最佳实践,请参阅组织政策限制条件。企业基础蓝图的 Terraform 脚本在示例基础代码库中。
Google Cloud 包含 Policy Intelligence,可让您自动查看和更新访问权限。Policy Intelligence 包含 Recommender、Policy Troubleshooter 和 Policy Analyzer 工具,可用于执行以下操作:
- 提供关于 IAM 角色分配的建议。
- 监控并防止过于宽松的 IAM 政策。
- 协助排查与访问权限控制相关的问题。
对资源设置限制
Google IAM 侧重于人员,可让您授权人员根据权限对特定资源执行操作。组织政策服务侧重于资源,可让您设置对资源的限制,以指定资源的配置方式。例如,您可以使用组织政策执行以下操作:
- 根据网域限制资源共享。
- 限制服务账号的使用。
- 限制新创建的资源的实际位置。
除了针对这些任务使用组织政策之外,您还可以使用以下某种方法限制对资源的访问:
- 使用标记来管理对资源的访问,而无需定义对每个资源的访问权限。您可以改为添加标记,然后设置标记本身的访问权限定义。
- 使用 IAM Conditions 对资源访问权限进行基于特性的条件性控制。
- 使用 VPC Service Controls 实现深度防御,以进一步限制对资源的访问。
如需详细了解资源管理,请参阅资源管理。
后续步骤
通过以下资源详细了解 IAM:
实现计算和容器安全
Google Cloud 包含用于保护计算资源和 Google Kubernetes Engine (GKE) 容器资源的控制机制。Google Cloud 架构框架中的本文档介绍了主要控制机制以及使用它们的最佳实践。
使用经过安全强化的精选虚拟机映像
Google Cloud 提供安全强化型虚拟机来帮助您对虚拟机实例进行安全强化。安全强化型虚拟机的设计可以防止在启动周期中加载恶意代码。它提供启动安全性、监控完整性并使用虚拟可信平台模块 (vTPM)。针对敏感工作负载使用安全强化型虚拟机。
除了使用安全强化型虚拟机外,您还可以使用 Google Cloud 合作伙伴解决方案进一步保护您的虚拟机。Google Cloud 上提供的许多合作伙伴解决方案都会与提供 Event Threat Detection 和运行状况监控功能的 Security Command Center 集成。您可以使用合作伙伴进行高级威胁分析或实现额外的运行时安全。
使用机密计算处理敏感数据
默认情况下,Google Cloud 会在整个网络中加密静态数据和传输中的数据,但不会在内存中加密使用中的数据。如果您的组织要处理机密数据,则您需要减少会破坏应用或系统内存中数据的机密性和完整性的威胁。机密数据包括个人身份信息 (PII)、财务数据和健康信息。
机密计算基于安全强化型虚拟机进行构建。它通过在基于硬件的可信执行环境中执行计算来保护使用中的数据。这种安全的独立环境有助于防止应用和使用中的数据遭到未经授权的访问或修改。可信执行环境还可增强管理敏感数据和受监管数据的组织的安全保障。
在 Google Cloud 中,您可以通过运行机密虚拟机或机密 GKE 节点来启用机密计算。如果您要处理机密工作负载,或者您拥有必须在处理时公开的机密数据(例如密钥),请启用机密计算。如需了解详情,请参阅机密计算联盟。
保护虚拟机和容器
OS Login 可让您的员工使用 Identity and Access Management (IAM) 权限作为可靠来源而不是依赖 SSH 密钥来连接虚拟机。因此,您不必管理整个组织的 SSH 密钥。OS Login 将管理员的访问权限与其员工生命周期相关联,这意味着如果员工转换为其他角色或离开您的组织,即会撤消其账号的访问权限。OS Login 还支持双重验证,从而增加一层额外的安全保障以防范账号盗用攻击。
在 GKE 中,App Engine 在 Docker 容器中运行应用实例。如需启用已定义的风险概况并限制员工更改容器,请确保您的容器为无状态且不可变。不变性原则意味着您的员工不会修改容器或以互动方式访问容器。如果必须更改容器,则您需要构建新映像并重新部署。仅在特定调试场景中启用对底层容器的 SSH 访问。
停用外部 IP 地址(除非必要)
如需为生产虚拟机停用外部 IP 地址分配(视频)并防止使用外部负载均衡器,您可以使用组织政策。如果您需要虚拟机访问互联网或本地数据中心,则可以启用 Cloud NAT 网关。
您可以在 GKE 中部署专用集群。在专用集群中,节点仅具有内部 IP 地址,这意味着节点和 Pod 默认与互联网隔离。您还可以定义网络政策来管理集群中 Pod 之间的通信。如需了解详情,请参阅服务的专用访问通道选项。
监控计算实例和 GKE 用量
系统会自动为 Compute Engine 和 GKE 启用 Cloud Audit Logs。Audit Logs 可让您自动捕获集群的所有相关活动并监控任何可疑的活动。
您可以将 GKE 与合作伙伴产品集成以实现运行时安全。您可以将这些解决方案与 Security Command Center 集成,以提供一个界面来监控您的应用。
确保映像和集群保持最新状态
Google Cloud 提供定期修补的精选操作系统映像。您可以自带自定义映像并在 Compute Engine 上运行这些映像,但如果这样做,您必须自行修补映像。Google Cloud 会定期更新操作系统映像以减少新漏洞,如安全公告中所述,并提供补救措施来修复现有部署的漏洞。
如果您使用的是 GKE,我们建议您启用节点自动升级功能,让 Google 使用最新的补丁程序更新您的集群节点。Google 负责管理 GKE 控制层面,这些控制层面会自动进行更新和修补。此外,请使用 Google 精选的容器优化型映像来进行部署。Google 会定期修补和更新这些映像。
控制对映像和集群的访问权限
请务必了解哪些用户能够创建和启动实例。您可以使用 IAM 控制此访问权限。如需了解如何确定工作负载需要哪些访问权限,请参阅规划您的工作负载身份。
此外,您还可以使用 VPC Service Controls 为项目定义自定义配额,以便限制哪些用户可以启动映像。如需了解详情,请参阅保护您的网络部分。
为了向您的集群提供基础架构安全性,GKE 可让您将 IAM 与基于角色的访问权限控制 (RBAC) 搭配使用,以管理对集群和命名空间的访问。
隔离沙盒中的容器
使用 GKE Sandbox 可部署多租户应用,这些应用需要一层额外的安全保障并与其主机内核隔离。例如,当您执行未知或不可信代码时,请使用 GKE Sandbox。GKE Sandbox 是一种容器隔离解决方案,用于在 GKE 上的容器化工作负载之间提供一层额外的安全防御。
GKE Sandbox 专为 I/O 要求低但扩缩性强的应用而构建。这些容器化工作负载需要保持其速度和性能,但也可能会用到需要加强防范的不可信代码。使用容器运行时沙盒 gVisor 可在应用和主机内核之间提供额外的安全隔离。gVisor 可提供额外的完整性检查并限制服务的访问范围。它不是用于防范外部威胁的容器安全强化服务。如需详细了解 gVisor,请参阅 gVisor:保护现实世界中的 GKE 和无服务器用户。
后续步骤
通过以下资源详细了解计算和容器安全:
- 保护您的网络(本系列的下一个文档)
- 为什么容器安全很重要 (PDF)
- Google Cloud 的发布核对清单
- 验证实例的身份
- Workload Identity
- 安全强化型虚拟机
- 永久性磁盘快照最佳做法
- 映像管理最佳做法
保护您的网络
Google Cloud 架构框架中的本文档提供了保护网络安全的最佳实践。
扩展现有网络以包含云环境会对安全性产生许多影响。您的本地多层防御方法可能涉及互联网与内部网络之间的明显边界。您可能会使用物理防火墙、路由器、入侵检测系统等来保护该边界。由于边界已明确定义,因此您可以轻松监控入侵并相应地做出响应。
但当您迁移到云端(完全或采用混合方法),您可能会移动到本地边界之外。本文档介绍如何继续保护贵组织在 Google Cloud 上的数据和工作负载。如利用控制措施来管理风险中所述,如何设置和保护 Google Cloud 网络取决于您的业务需求和风险偏好。
本部分假定您已阅读系统设计类别中的网络部分,并且已经创建了 Google Cloud 网络组件的基本架构图。如需查看示例图表,请参阅中心辐射型。
部署零信任网络
迁移到云端意味着您的网络信任模型必须发生变化。由于您的用户和工作负载不再位于本地边界内,因此您无法以相同方式使用边界保护来创建可信的内部网络。零信任安全模型意味着在默认情况下,任何人都不受信任,无论他们是在组织网络内部还是外部。验证访问请求时,零信任安全模型会要求您同时检查用户的身份和上下文。与 VPN 不同,您可以将访问权限控制从网络边界转移至用户和设备。
在 Google Cloud 中,您可以将 BeyondCorp Enterprise 用作零信任解决方案。BeyondCorp Enterprise 提供威胁和数据保护以及额外的访问权限控制。如需详细了解如何进行设置,请参阅 BeyondCorp Enterprise 使用入门。
除了 BeyondCorp Enterprise 之外,Google Cloud 还提供了 Identity-Aware Proxy (IAP)。IAP 让您可以将零信任安全性同时扩展到 Google Cloud 上的应用和本地应用。IAP 使用访问权限控制政策为访问应用和资源的用户提供身份验证和授权。
保护与本地或多云环境的连接
许多组织的云环境和本地环境中都有工作负载。此外,为了实现弹性,一些组织还会使用多云解决方案。在这些情况下,保护所有环境之间的连接至关重要。
Google Cloud 包括虚拟机的专用访问方法,这些方法受 Cloud VPN 或 Cloud Interconnect 支持,具体包括:
- 使用 Cross-Cloud Interconnect(作为托管式服务),通过高速直接连接将 VPC 网络连接到其他受支持的云服务提供商。使用 Cross-Cloud Interconnect 时,您无需提供自己的路由器或与第三方供应商合作。
- 使用专用互连和合作伙伴互连,通过高速直接连接方式将您的 VPC 网络链接到您的本地数据中心或其他云服务提供商。
- 使用 IPSec VPN 将 Virtual Private Cloud (VPC) 网络链接到您的本地数据中心或其他云服务提供商。
- 使用 Private Service Connect 端点访问您的组织或其他提供商提供的已发布服务。
- 借助 Private Service Connect 端点,虚拟机可以使用内部 IP 地址访问 Google API。通过 Private Service Connect,虚拟机不必具有外部 IP 地址便可访问 Google 服务。
- 如果您使用 GKE Enterprise,请考虑使用 Anthos Service Mesh 出站流量网关。如果您未使用 GKE Enterprise,请使用第三方选项。
如需了解各个产品的对比情况,请参阅选择 Network Connectivity 产品。
停用默认网络
创建新的 Google Cloud 项目时,系统会自动预配具有自动模式 IP 地址和预先填充的防火墙规则的默认 Google Cloud VPC 网络。对于生产部署,我们建议您删除现有项目中的默认网络,并在新项目中停用创建默认网络。
Virtual Private Cloud 网络允许您使用任何内部 IP 地址。为避免 IP 地址冲突,我们建议您首先针对关联的所有部署和项目规划网络和 IP 地址分配。一个项目允许有多个 VPC 网络,但通常最好限制每个项目使用一个网络,以有效地强制执行访问权限控制。
保护边界安全
在 Google Cloud 中,您可以使用防火墙和 VPC Service Controls 等诸多方法来细分和保护云边界。
使用共享 VPC 构建生产部署,以便为您提供单个共享网络,并将工作负载隔离到可由不同团队管理的各个项目中。共享 VPC 让您可以跨多个项目集中部署、管理和控制网络及网络安全资源。共享 VPC 由执行以下功能的宿主项目和服务项目组成:
- 宿主项目包含与网络和网络安全相关的资源,例如 VPC 网络、子网、防火墙规则和混合连接。
- 服务项目会关联到宿主项目。这使您能够使用 Identity and Access Management (IAM) 在项目级隔离工作负载和用户,同时共享集中管理的宿主项目中的网络资源。
在组织、文件夹和 VPC 网络级层定义防火墙政策和规则。您可以配置防火墙规则,以允许或拒绝进出虚拟机实例的流量。如需查看示例,请参阅全球和区域级网络防火墙政策示例以及分层防火墙政策示例。除了根据 IP 地址、协议和端口定义规则之外,您还可以根据虚拟机实例使用的服务账号或使用安全标记来管理流量并应用防火墙规则。
如需控制 Google 服务中数据的移动以及设置基于上下文的边界安全性,请考虑使用 VPC Service Controls。VPC Service Controls 会为 Google Cloud 服务提供一层额外的安全保障,它独立于 IAM 和防火墙规则及政策。例如,VPC Service Controls 允许您在机密数据和非机密数据之间设置边界,以便应用有助于防止数据渗漏的控制措施。
您可以使用 Google Cloud Armor 安全政策来允许、拒绝或重定向对 Google Cloud 边缘尽可能靠近传入流量来源的外部应用负载均衡器的请求。这些政策可防止不受欢迎的流量占用资源或进入您的网络。
使用安全 Web 代理对出站 Web 流量应用精细的访问权限政策,并监控对不受信任的 Web 服务的访问。
检查网络流量
您可以借助 Cloud IDS 和数据包镜像来确保在以下环境中运行的工作负载的安全性和合规性:Compute Engine 和 Google Kubernetes Engine (GKE)。
使用 Cloud Intrusion Detection System(目前为预览版)可以深入了解进出 VPC 网络的流量。Cloud IDS 会创建一个具有镜像虚拟机的 Google 管理的对等互连网络。Palo Alto Networks 威胁防范技术可镜像并检查流量。如需了解详情,请参阅 Cloud IDS 概览。
数据包镜像会克隆 VPC 网络中特定虚拟机实例的流量并转发该流量,以用于收集、保留和检查目的。配置数据包镜像后,您便可以使用 Cloud IDS 或第三方工具来大规模收集和检查网络流量。以这种方式检查网络流量有助于提供入侵检测和应用性能监控。
使用 Web 应用防火墙
对于外部 Web 应用和服务,您可以启用 Google Cloud Armor 以提供分布式拒绝服务攻击 (DDoS) 防护和 Web 应用防火墙 (WAF) 功能。Google Cloud Armor 支持使用外部 HTTP(S) 负载均衡、TCP 代理负载均衡或 SSL 代理负载均衡公开的 Google Cloud 工作负载。
Google Cloud Armor 提供两种服务层级:标准和 Managed Protection Plus。如需充分利用 Google Cloud Armor 的高级功能,您应该为关键工作负载购买 Managed Protection Plus。
自动执行基础架构预配
自动化功能允许您创建不可变基础架构,这意味着预配后便无法再更改。此措施可为您的运营团队提供已知的良好状态、快速回滚和问题排查功能。如需实现自动化,您可以使用 Terraform、Jenkins 和 Cloud Build 等工具。
为了帮助您构建使用自动化功能的环境,Google Cloud 提供了一系列安全蓝图,这些蓝图又是基于企业基础蓝图而构建的。安全基础蓝图为安全应用环境提供了 Google 的独特设计,并逐步介绍了如何配置和部署 Google Cloud 资源。使用安全基础蓝图中的说明和脚本,您可以配置满足安全最佳实践和准则的环境。您可以基于该蓝图和其他蓝图构建自动化功能,也可以设计自己的自动化功能。
如需详细了解自动化,请参阅使用 CI/CD 流水线处理数据处理工作流。
监控网络
使用遥测监控网络和流量。
VPC 流日志和防火墙规则日志记录可让您近乎实时地了解 Google Cloud 环境中的流量和防火墙使用情况。例如,防火墙规则日志记录会记录进出 Compute Engine 虚拟机实例的流量。通过将这些工具与 Cloud Logging 和 Cloud Monitoring 结合使用,您可以跟踪、提醒和直观呈现流量及访问模式,以改进部署的运营安全性。
借助防火墙数据分析,您可以查看有哪些防火墙规则匹配传入和传出连接,以及这些连接是否被允许或拒绝。被覆盖的规则功能可显示有哪些规则由于系统始终会先触发另一个规则而永远不会被触发,从而帮助您调整防火墙配置。
您可以使用 Network Intelligence Center 来查看网络拓扑和架构的性能。您可以获得有关网络性能的详细数据分析,然后优化部署以消除服务中的任何瓶颈。Connectivity Tests 可让您深入了解应用于网络路径的防火墙规则和政策。
如需详细了解监控功能,请参阅实现日志记录和检测控制措施。
后续步骤
通过以下资源,详细了解网络安全:
- 实现数据安全(本系列的下一个文档)
- VPC 设计的最佳做法与参考架构
- 用于管理 VPC Service Controls 的 IAM 角色
- Security Command Center 合作伙伴新手入门
- 在 Security Command Center 中查看漏洞和威胁
- 数据包镜像:直观呈现并保护您的云端网络
- 使用数据包镜像进行入侵检测
- 将数据包镜像与合作伙伴 IDS 解决方案搭配使用
实现数据安全
Google Cloud 架构框架中的本文档提供了实现数据安全的最佳实践。
在部署架构中,您必须考虑计划要在 Google Cloud 中处理和存储的数据以及这些数据的敏感性。请设计您的控制措施,以帮助确保数据在其生命周期内的安全性、识别数据所有权和分类以及保护数据免遭未经授权的使用。
如需了解按照本文档中介绍的安全最佳做法部署 BigQuery 数据仓库的安全蓝图,请参阅确保存储机密数据的 BigQuery 数据仓库的安全性。
自动对数据进行分类
尽早在数据管理生命周期内执行数据分类,最好在创建数据时便对其进行分类。通常,只需要进行如下数据分类:
- 公开:已批准公开访问的数据。
- 内部:未公开发布的非敏感数据。
- 机密:可用于常规内部分发的敏感数据。
- 受限:需要受限分发的高度敏感或监管数据。
使用敏感数据保护发现 Google Cloud 环境中的数据并对其进行分类。敏感数据保护支持对 Cloud Storage、BigQuery 和 Datastore 中的敏感数据进行扫描和分类。 它还提供了一个流式传输 API 来支持其他数据源和自定义工作负载。
敏感数据保护可以使用内置 infoType 识别敏感数据。它可以自动对敏感元素(例如 PII 数据)进行分类、遮盖、令牌化和转换,以便您管理收集、存储和使用数据的风险。换句话说,它可以与数据生命周期内的各流程集成,以确保每个阶段的数据都受到保护。
如需了解详情,请参阅使用敏感数据保护对大规模数据集中的个人身份信息进行去标识化和重标识处理。
使用元数据管理数据治理
数据治理是指为确保数据安全、私有、准确、可用和易用所执行的各流程的组合。虽然您负责为组织定义数据治理策略,但 Google Cloud 可以提供各种工具和技术来帮助您将策略付诸实践。Google Cloud 还在云端提供了数据治理框架 (PDF)。
使用 Data Catalog 以查找、挑选和使用元数据来描述您在云端的数据资源。您可以使用 Data Catalog 搜索数据资源,然后使用元数据标记这些资源。为帮助加速数据分类工作,请将 Data Catalog 与敏感数据保护集成,以自动识别机密数据。标记数据后,您便可以使用 Google Identity and Access Management (IAM) 来限制用户可以通过 Data Catalog 视图查询或使用的数据。
使用 Dataproc Metastore 或 Hive Metastore 来管理工作负载的元数据。Data Catalog 有一个 Hive 连接器,可让服务发现 Hive Metastore 内的元数据。
使用 Dataprep by Trifacta 通过控制台定义和强制执行数据质量规则。您可以从 Cloud Data Fusion 内使用 Dataprep,也可以将 Dataprep 作为独立服务来使用。
根据数据的生命周期阶段和分类来保护数据
在数据的生命周期上下文中定义数据并根据其敏感性和风险对其进行分类后,您可以分配适当的安全控制措施来保护数据。您必须确保控制措施提供了足够的保护、满足合规性要求并降低风险。在迁移到云端后,请查看您当前的策略,以及可能需要更改当前流程的位置。
下表介绍了云端数据安全策略的三个特征。
特征 | 说明 |
---|---|
识别 | 在创建、修改、存储、使用、共享和删除数据时,了解对数据执行这些操作的用户、资源和应用的身份。 使用 Cloud Identity 和 IAM 来控制对数据的访问权限。如果您的身份要求提供证书,请考虑使用 Certificate Authority Service。 如需了解详情,请参阅管理身份和访问权限。 |
边界和访问权限 | 设置控制措施来管理数据的访问方式、能够访问数据的人员以及访问数据需满足的条件。您可以在以下级层管理数据的访问边界:
|
公开范围 | 您可以审核使用情况并创建报告,以展示数据的控制和访问方式。Google Cloud Logging 和 Access Transparency 可让您深入了解自己的云端管理员及 Google 员工的活动。如需了解详情,请参阅监控数据。 |
加密您的数据
默认情况下,Google Cloud 会对静态存储的客户数据进行加密,因此您无需执行任何操作。除了默认加密之外,Google Cloud 还提供信封加密和加密密钥管理选项。例如,虽然 Compute Engine 永久性磁盘会自动加密,但您可以提供或管理自己的密钥。
无论您选择的是用于存储、计算还是大数据工作负载的密钥,都必须确定最适合密钥生成、存储和轮替要求的解决方案。
Google Cloud 提供以下加密和密钥管理选项:
- 客户管理的加密密钥 (CMEK)。您可以使用 Cloud Key Management Service (Cloud KMS) 来生成和管理您的加密密钥。如果您有特定的密钥管理要求(例如需要定期轮替加密密钥),则可以使用此选项。
- 客户提供的加密密钥 (CSEK)。您可以创建和管理自己的加密密钥,然后根据需要将其提供给 Google Cloud。如果您使用本地密钥管理系统生成自己的密钥,即自带密钥 (BYOK),则可以使用此选项。如果您使用 CSEK 提供自己的密钥,Google 会复制这些密钥并将其提供给您的工作负载。但是,CSEK 的安全性和可用性由您负责,因为客户提供的密钥不会存储在实例模板或 Google 基础架构中。如果您出于各种原因无法再访问这些密钥,Google 将无法帮助您恢复加密的数据。请仔细考虑您要自行创建和管理哪些密钥。您最好只将 CSEK 用于最敏感的信息。还有一种方法是对数据执行客户端加密,然后将加密的数据存储在 Google Cloud 中,之后 Google 会再次加密该数据。
- 具有 Cloud External Key Manager (Cloud EKM) 的第三方密钥管理系统。Cloud EKM 使用您在 Google 基础架构外部控制的第三方密钥管理系统中存储和管理的加密密钥来保护您的静态数据。使用此方法时,您可以确保组织外部的任何人都无法访问您的数据。借助 Cloud EKM,您可以轻松地使用高度安全的自行保管密钥 (HYOK) 模型来进行密钥管理。如需了解兼容性信息,请参阅已启用 Cloud EKM 的服务列表。
Cloud KMS 还允许您使用软件支持的加密密钥或经过 FIPS 140-2 3 级验证的硬件安全模块 (HSM) 来加密数据。如果您使用的是 Cloud KMS,则加密密钥将存储在资源部署所在的区域中。Cloud HSM 会跨区域分发密钥管理需求,从而为密钥提供了冗余性和全球可用性。
如需了解信封加密的工作原理,请参阅 Google Cloud 中的静态加密。
控制云管理员对数据的访问权限
您可以控制 Google 支持和工程团队对您的 Google Cloud 环境的访问权限。借助 Access Approval,您可以事先明确批准 Google 员工访问您在 Google Cloud 上的数据或资源。此产品是对 Access Transparency 提供的可见状态的补充,它会在 Google 员工与您的数据交互时生成日志。这些日志中将包含办公地点和访问原因。
您可以将这些产品搭配使用来拒绝 Google 出于任何原因对您的数据进行解密的请求。
配置数据的存储位置以及用户可以访问这些数据的位置
您可以使用 VPC Service Controls 来控制用户可以访问数据的网络位置。此产品让您可以限制特定区域中的用户访问权限。即使用户根据您的 Google IAM 政策获得授权,您也可以强制执行此限制条件。您可以使用 VPC Service Controls 创建服务边界,从而定义可以从中访问服务的虚拟边界,防止数据移动到这些边界之外。
详情请参阅以下内容:
使用 Secret Manager 管理 Secret
借助 Secret Manager,您可以将所有 Secret 存储在一个集中位置。Secret 是数据库密码、API 密钥或 TLS 证书等配置信息。您可以自动轮替 Secret,并且可以将应用配置为自动使用最新版本的 Secret。每次与 Secret Manager 交互都会生成审核日志,因此您可以查看对每个 Secret 的每次访问。
敏感数据保护还提供检测器类别,以帮助您识别可能受到 Secret Manager 保护的数据中的凭据和 Secret。
监控您的数据
如需查看管理员活动和密钥使用日志,请使用 Cloud Audit Logs。为了帮助保护您的数据,请使用 Cloud Monitoring 来监控日志,以确保正确使用您的密钥。
Cloud Logging 会捕获 Google Cloud 事件,并且允许您在必要时添加其他来源。您可以按区域细分日志、将日志存储在存储桶中,以及集成自定义代码来处理日志。如需查看示例,请参阅用于自动日志分析的自定义解决方案。
您还可以将日志导出到 BigQuery 来执行安全和访问分析,以帮助识别对组织数据的未经授权更改及不当访问。
Security Command Center 可以帮助您识别并解决存储在云端的组织敏感数据中的不安全访问问题。通过单个管理界面,您便可以扫描您的云基础架构中的各种安全漏洞和风险。例如,您可以监控数据渗漏,扫描存储系统中的机密数据,并检测有哪些 Cloud Storage 存储桶对互联网开放。
后续步骤
通过以下资源,详细了解数据安全:
安全地部署应用(本系列中的下一个文档)
安全地部署应用
Google Cloud 架构框架中的本文档提供了安全部署应用的最佳实践。
如需部署安全应用,您必须有明确定义的软件开发生命周期,并在设计、开发、测试和部署阶段进行适当的安全检查。在设计应用时,建议使用分层架构系统,该架构使用标准化框架进行身份验证、授权和访问权限控制。
自动发布安全版本
如果没有自动化工具,可能很难在部署、更新和修补复杂的应用环境时,确保满足一致的安全要求。因此,我们建议您为这些任务构建 CI/CD 流水线,这通常可以解决许多此类问题。自动化流水线可消除手动错误、提供标准化开发反馈环并实现快速产品迭代。例如,借助 Cloud Build 专用池,您可以为金融和医疗保健等严格监管的行业部署高度安全的代管式 CI/CD 流水线。
在创建工件时,您可以自动扫描安全漏洞。此外,您还可以为不同的环境(开发、测试、生产等)定义相应的政策,以便仅部署经过验证的工件。
确保应用部署遵循批准的流程
如果攻击者破解了 CI/CD 流水线,则整个堆栈可能会受到影响。为了帮助保护流水线,您应在将代码部署到生产环境之前实施已确定的批准流程。
如果您计划使用 Google Kubernetes Engine (GKE) 或 GKE Enterprise,则可以使用 Binary Authorization 来建立这些制衡。Binary Authorization 会将可配置的签名关联到容器映像。这些签名(也称为证明)可用来验证关联的映像。在部署时,Binary Authorization 会使用这些证明来确定之前是否已完成相应流程。例如,您可以使用 Binary Authorization 执行以下操作:
- 验证特定构建系统或持续集成 (CI) 流水线是否已创建容器映像。
- 验证容器映像是否符合漏洞签名政策。
- 验证容器映像是否将提升标准传递到下一个部署环境,例如从开发环境到质量检查环境。
在部署之前扫描已知漏洞
建议您在容器部署到生产环境之前使用自动化工具,以便持续对容器映像执行漏洞扫描。
使用 Artifact Analysis 自动扫描存储在 Artifact Registry 和 Container Registry 中的容器的漏洞。此过程包括两项任务:扫描和持续分析。
首先,Artifact Analysis 会在新映像上传到 Artifact Registry 或 Container Registry 时扫描这些映像。此扫描可提取有关容器中系统软件包的信息。
然后,Artifact Analysis 会在您上传映像时查找漏洞。初始扫描后,Artifact Analysis 会持续监控 Artifact Registry 和 Container Registry 中所扫描映像的元数据以查找新漏洞。当 Artifact Analysis 从漏洞来源收到新的和更新后的漏洞信息时,它会执行以下操作:
- 更新已扫描映像的元数据,使其保持最新。
- 为新的版本说明创建新的漏洞发生实例。
- 删除不再有效的漏洞发生实例。
监控应用代码是否存在已知漏洞
最佳实践是使用能够持续监控应用代码是否存在已知漏洞(例如 OWASP 十大风险)的自动化工具。如需了解支持 OWASP 十大风险缓解技术的 Google Cloud 产品和功能,请参阅 Google Cloud 上的 OWASP 十大风险缓解选项。
使用 Web Security Scanner 可帮助识别 App Engine、Compute Engine 和 Google Kubernetes Engine Web 应用中的安全漏洞。此扫描程序会抓取您的应用,跟踪起始网址范围内的所有链接,并尝试执行尽可能多的用户输入和事件处理脚本。它可自动扫描和检测常见漏洞,包括跨站脚本攻击 (XSS)、Flash 注入、混合内容(HTTPS 中的 HTTP)以及过时或不安全的库。Web Security Scanner 可让您以较低的假正例率尽早识别这些类型的漏洞。
控制跨边界的数据移动
如需控制跨边界数据移动,您可以为 Google 管理的服务的资源配置安全边界。使用 VPC Service Controls 将所有组件和服务(例如 Container Registry、Artifact Registry、Artifact Analysis 和 Binary Authorization)放在安全边界内的 CI/CD 流水线中。
VPC Service Controls 可帮助您降低未经授权从 Google 代管的服务中复制或转移数据(数据渗漏)的风险。借助 VPC Service Controls,您可以为 Google 代管的服务的资源配置安全边界,并控制跨边界的数据移动。服务边界实施时,违反边界政策的请求(例如从边界外向受保护的服务发出的请求)会被拒绝。当服务受实施边界保护时,VPC Service Controls 可确保:
- 服务无法将数据传输到边界外。受保护的服务在边界内正常运行,但无法将资源和数据发送到边界外。此限制有助于防止可能有权访问边界内项目的恶意内部人员泄露数据。
- 仅当从边界外访问受保护服务的请求满足分配给边界的访问权限级别条件时,系统才会允许这些请求。
- 可以使用边界网桥使其他边界中的项目可以访问服务。
对容器映像进行加密
在 Google Cloud 中,您可以使用客户管理的加密密钥 (CMEK) 来加密容器映像。CMEK 密钥在 Cloud Key Management Service (Cloud KMS) 中进行管理。使用 CMEK 时,您可以通过停用或销毁密钥来临时或永久停用对加密容器映像的访问。
后续步骤
通过以下资源,详细了解如何保护供应链和应用安全:
管理法规遵从义务
Google Cloud 架构框架中的本文档提供了管理合规性义务的最佳实践。
您的云监管要求取决于多种因素,包括:
- 适用于组织实际位置的法律法规。
- 适用于客户实际位置的法律法规。
- 您所在行业的监管要求。
这些要求会影响许多决策,您需要针对 Google Cloud 中的工作负载启用哪些安全控制措施来做出这些决策。
典型的合规流程分为三个阶段:评估、差距补救和持续监控。本部分介绍了您在每个阶段可以使用的最佳做法。
评估您的合规性需求
在合规性评估中,首先需要全面查看所有监管义务以及您的企业如何履行这些义务。为帮助您评估 Google Cloud 服务,请使用合规性资源中心。此网站为您提供以下方面的详细信息:
- 适用于各种法规的服务支持
- Google Cloud 认证和证明
您可以要求与 Google 合规专家互动,以更好地了解 Google 的合规性生命周期以及如何满足您的要求。
如需了解详情,请参阅确保云中的合规性 (PDF)。
部署 Assured Workloads
Assured Workloads 是一款 Google Cloud 工具,它基于 Google Cloud 中的控制措施构建,可帮助您履行合规性义务。借助 Assured Workloads,您可以执行以下操作:
- 选择您的合规制度。然后,该工具会自动设置基准人员访问权限控制。
- 使用组织政策设置数据的位置,以确保静态数据和资源仅保留在该区域中。
- 选择最适合您的安全和合规性要求的密钥管理选项(例如密钥轮替周期)。
- 对于某些监管要求(例如 FedRAMP Moderate),请选择 Google 支持人员的访问条件(例如,他们是否完成了适当的背景调查)。
- 确保 Google 管理的加密密钥符合 FIPS-140-2 要求,并支持 FedRAMP 中等风险级别合规性。为了增强控制层和职责分离,您可以使用客户管理的加密密钥 (CMEK)。 如需详细了解密钥,请参阅加密数据。
查看蓝图,了解适用于您的合规性制度的模板和最佳实践
Google 发布了蓝图和解决方案指南,其中介绍了最佳做法并提供了 Terraform 模块,帮助您发布有助于实现合规性的环境。下表列出了满足安全性和合规性要求的一些蓝图。
标准 | 说明 |
---|---|
PCI | |
FedRAMP | |
HIPAA |
监控合规性
大多数法规要求您监控特定活动,包括访问权限控制。为帮助您进行监控,您可以使用以下方法:
- Access Transparency,它可在 Google Cloud 管理员访问您的内容时提供近乎实时的日志。
- 防火墙规则日志记录,以针对您自己创建的任何规则记录 VPC 网络内的 TCP 和 UDP 连接。这些日志可用于审核网络访问权限,或者针对以未经批准的方式使用网络提供早期警告。
- VPC 流日志,以记录虚拟机实例发送或接收的网络流量流。
- Security Command Center Premium,以监控是否符合各种标准。
- OSSEC(或其他开源工具),以记录对您的环境具有管理员访问权限的个人的活动。
- Key Access Justifications,以查看密钥访问请求的原因。
自动实现合规性
为了帮助您遵守不断变化的法规,请确定您是否可以通过将安全政策作为代码部署整合到基础架构中来自动执行安全政策。例如,应该考虑以下事项:
使用安全蓝图将安全政策构建到基础架构部署中。
配置 Security Command Center 以在出现不合规问题时发出提醒消息。例如,监控是否存在用户停用两步验证或拥有权限过高的服务账号等问题。如需了解详情,请参阅设置发现结果通知。
设置对特定通知的自动纠正功能。如需了解详情,请参阅 Cloud Functions 代码。
如需详细了解合规性自动化,请参阅风险和合规即代码 (RCaC) 解决方案。
后续步骤
通过以下资源详细了解合规性:
- 实施数据驻留和主权要求(本系列的下一个文档)
- 合规性资源中心
- Google 安全性白皮书 (PDF)
- Assured Workloads
实现数据驻留和主权要求
Google Cloud 架构框架中的本文档提供了用于实现数据驻留和主权要求的最佳实践。
数据驻留和主权要求取决于您的区域和行业特有的法规,不同的组织可能有不同的数据主权要求。例如,您可能有以下要求:
- 控制 Google Cloud 对您的数据的所有访问权限,包括哪种类型的人员可以访问数据以及他们可以从哪个区域访问数据。
- 检查云基础架构和服务的更改,此行为可能会对数据的访问或数据的安全性产生影响。深入了解这些类型的更改有助于确保 Google Cloud 无法规避控制或无法将您的数据移出区域。
- 当您无法从 Google Cloud 接收软件更新时,请让工作负载在很长一段时间内持续有效。
管理数据主权
数据主权提供了一种机制,可阻止 Google 访问您的数据。您只为自己认可的必要提供商行为批准访问请求。
例如,您可以通过以下方式管理数据主权:
- 在云之外存储和管理加密密钥。
- 仅根据详细访问理由授予对这些密钥的访问权限。
- 保护使用中的数据。
管理运营主权
运营主权能够保证 Google 员工无法泄露您的工作负载。
例如,您可以通过以下方式管理运营主权:
- 将新资源的部署限制到特定提供商区域。
- 基于预定义的特性(例如,公民身份或地理位置)限制 Google 员工访问权限。
管理软件主权
软件主权能够保证您可以控制工作负载的可用性并在任何位置运行它们,而无需依赖(或受限于)单个云提供商。软件主权包括可承受需要您快速更改工作负载部署位置和允许的外部连接级别的事件的功能。
例如,Google Cloud 支持混合和多云部署。此外,GKE Enterprise 还可让您在云环境和本地环境中管理和部署应用。
控制数据驻留
数据驻留描述静态存储数据的位置。数据驻留要求会因系统设计目标、行业监管问题、国家法律、税务影响甚至文化而异。
如需控制数据驻留,请从下列操作开始:
- 了解数据类型及数据位置。
- 确定数据存在哪些风险以及适用哪些法律和法规。
- 控制数据的存储位置或流向位置。
为遵守数据驻留要求,Google Cloud 允许您控制数据的存储位置、访问方式和处理方式。您可以使用资源位置政策来限制资源的创建位置,并限制数据在区域之间的复制位置。您还可以使用资源的位置属性来标识服务的部署位置及其维护者。
如需了解支持性,请参阅资源位置支持的服务。
后续步骤
通过以下资源详细了解数据驻留和主权:
- 实现隐私权要求(本系列的下一个文档)
- Google Cloud 欧洲客户的数据驻留情况、运维透明度和隐私权 (PDF)
- 设计和部署数据安全策略 (PDF)
- Cloud Key Management Service
- 将数据托付给 Google Cloud (PDF)
- Google 的特权访问权限
- Google Cloud Access Transparency
实现隐私权要求
Google Cloud 架构框架中的本文档提供了实现隐私权要求的最佳实践。
隐私权法规有助于定义如何获取、处理、存储和管理用户数据。许多隐私控制(例如,Cookie、会话管理和获取用户权限控制)由您负责,因为您的数据(包括您从用户接收的数据)归您所有。
Google Cloud 包括以下保护隐私权的控制措施:
- 默认加密所有静态数据、传输中的数据和处理中的数据。
- 防范内部人员访问。
- 支持众多隐私权法规。
如需了解详情,请参阅 Google Cloud 隐私权承诺。
对机密数据进行分类
您必须定义哪些数据是机密数据,然后确保机密数据得到适当的保护。机密数据可能包括信用卡号码、地址、电话号码和其他个人身份信息 (PII)。
使用敏感数据保护,您可以设置适当的分类。然后,您可以对数据添加标记和进行令牌化,再存储到 Google Cloud。如需了解详情,请参阅自动对数据进行分类。
锁定对敏感数据的访问
使用 VPC Service Controls 将敏感数据放置在自己的服务边界内,并对敏感数据设置 Google Identity and Access Management (IAM) 访问权限控制。为需要访问敏感数据的所有用户配置多重身份验证 (MFA)。
如需了解详情,请参阅控制跨边界数据移动以及设置 SSO 和 MFA。
监控钓鱼式攻击
确保您的电子邮件系统配置为防范钓鱼式攻击,此类攻击通常用于欺诈和恶意软件攻击。
如果您的组织使用 Gmail,您可以使用高级钓鱼式攻击和恶意软件防护功能。一系列设置可提供控制来隔离电子邮件,防范异常附件类型,并有助于防范入站仿冒电子邮件。安全沙盒可检测到附件中的恶意软件。Gmail 会使用最新的安全改进和保护功能持续自动更新,以帮助确保组织的电子邮件安全。
对您的混合型工作人员实施零信任安全机制
零信任安全模型意味着没有人受到隐含信任,无论他们是在组织网络内部还是外部。当您的 IAM 系统验证访问权限请求时,零信任安全状态意味着系统会考虑用户的身份和上下文(例如其 IP 地址或位置)。与 VPN 不同,零信任安全机制会将访问权限控制从网络边界转移至用户及其设备。零信任安全机制可让用户从任何位置更安全地工作。例如,用户可以在家中通过笔记本电脑或移动设备访问您组织的资源。
在 Google Cloud 上,您可以配置 BeyondCorp Enterprise 和 Identity-Aware Proxy (IAP),为 Google Cloud 资源启用零信任。如果您的用户使用 Google Chrome 并且您启用 BeyondCorp Enterprise,则您可以将零信任安全措施集成到用户浏览器中。
后续步骤
如需详细了解安全性和隐私权,请参阅以下资源:
- 实现日志记录和检测控制(本系列中的下一个文档)
- 隐私权中心
实现日志记录和检测控制
Google Cloud 架构框架中的本文档提供了实现日志记录和检测控制的最佳实践。
检测控制使用遥测数据来检测云环境中的错误配置、漏洞和潜在的恶意活动。借助 Google Cloud,您可以为您的环境量身定制监控和检测控制。本部分介绍了这些额外功能及其使用建议。
监控网络性能
Network Intelligence Center 可让您了解网络拓扑和架构的性能。您可以详细了解网络性能,然后使用该信息通过消除服务瓶颈来优化部署。Connectivity Tests 可让您深入了解应用于网络路径的防火墙规则和政策。
监控并防止数据渗漏
数据渗漏是组织的关键问题。通常,当已获授权的人员从安全系统中提取数据,然后与未经授权方共享这些数据或将其移至不安全的系统时,会发生这种情况。
Google Cloud 提供了多项功能和工具,可帮助您检测和防止数据渗漏。如需了解详情,请参阅防止数据渗漏。
集中监控
利用 Security Command Center,您可以了解 Google Cloud 中拥有的资源及其安全状态。Security Command Center 可帮助您预防、检测和应对威胁。它提供了一个集中式信息中心,可用于识别虚拟机、网络、应用和存储桶中的安全配置错误。您可以在这些问题造成业务损害或损失之前将它们解决掉。Security Command Center 的内置功能可以发现 Cloud Logging 安全日志中的可疑活动或指出遭到破解的虚拟机。
您可以遵循切实可行的建议或将日志导出到 SIEM 系统进行进一步调查,从而应对威胁。如需了解如何将 SIEM 系统与 Google Cloud 搭配使用,请参阅 Google Cloud 中的安全日志分析。
Security Command Center 还提供多个检测器,可帮助您分析基础架构的安全性。这些检测器包括:
其他 Google Cloud 服务(例如 Google Cloud Armor 日志)也会提供要在 Security Command Center 中显示的发现结果。
请为工作负载启用所需的服务,然后仅监控和分析重要数据。 如需详细了解如何为服务启用日志记录,请参阅 Google Cloud 中的安全日志分析的启用日志部分。
监控威胁
Event Threat Detection 是 Security Command Center 高级方案的可选代管式服务,用于检测日志流中的威胁。通过使用 Event Threat Detection,您可以检测高风险和高成本的威胁,例如恶意软件、挖矿、未经授权访问 Google Cloud 资源、DDoS 攻击和 SSH 暴力破解。利用该工具的功能来提取大量日志数据,您的安全团队可以快速识别高风险突发事件并集中精力加以补救。
为帮助检测组织中可能被盗用的用户账号,请使用敏感操作 Cloud Platform 日志来确定何时执行了敏感操作以及确认正常用户基于合理目的执行了这些操作。敏感操作是指如果由恶意操作者执行,可能会破坏您业务的操作,例如添加具有高特权的角色。您可以使用 Cloud Logging 查看、监控和查询敏感操作 Cloud Platform 日志。您还可以使用 Security Command Center 高级方案的内置服务 Sensitive Actions Service 来查看敏感操作日志条目。
Chronicle 可以集中存储和分析所有安全数据。为了帮助您了解整个攻击过程,Chronicle 可以将日志映射到通用模型中,丰富日志,然后将日志关联到时间轴。此外,您可以使用 Chronicle 创建检测规则,设置失陷指标 (IoC) 匹配,以及执行威胁搜寻活动。您可以使用 YARA-L 语言编写检测规则。如需查看 YARA-L 中的威胁检测规则示例,请参阅社区安全分析 (CSA) 仓库。除了编写您自己的规则之外,您还可以利用 Chronicle 中的精选检测规则。这些精选检测规则是一组预定义的代管式 YARA-L 规则,可帮助您找出威胁。
集中日志以进行安全分析、审核和调查的另一种方法是使用 BigQuery。在 BigQuery 中,您可以使用 SQL 查询(例如 CSA 代码库中的查询)来分析权限更改、预配活动、工作负载用量、数据访问权限和网络活动,从而监控常见威胁或错误配置。如需详细了解 BigQuery 中从设置到分析的安全日志分析,请参阅 Google Cloud 中的安全日志分析。
下图展示如何使用 Security Command Center 的内置威胁检测功能以及您在 BigQuery、Chronicle 或第三方 SIEM 中执行的威胁检测来集中监控。
如图所示,您应该监控各种安全数据源。这些数据源包括来自 Cloud Logging 的日志、来自 Cloud Asset Inventory 的资产更改、Google Workspace 日志,或者来自 Hypervisor 或客机内核的事件。该图显示您可以使用 Security Command Center 来监控这些数据源。如果您已在 Security Command Center 中启用了适当的功能和威胁检测器,则会自动进行此监控。该图显示您还可以通过将安全数据和 Security Command Center 发现结果导出到 BigQuery、Chronicle 或第三方 SIEM 等分析工具来监控威胁。在分析工具中,该图显示您可以通过使用并扩展查询和规则(如 CSA 中提供的查询和规则)来执行进一步分析和调查。
后续步骤
通过以下资源详细了解日志记录和检测:
Google Cloud 架构框架:可靠性
Google Cloud 架构框架中的此类别介绍如何在云平台上构建和运营可靠的服务。此外,您还将了解一些支持可靠性的 Google Cloud 产品和功能。
该架构框架介绍了最佳实践,提供了实现建议,并说明了一些可用的产品和服务。该框架旨在帮助您设计 Google Cloud 部署,以便它能够完全满足您的业务需求。
如需运行可靠的服务,您的架构必须包含以下内容:
- 可衡量的可靠性目标,如有偏差可以及时纠正。
- 具备可扩缩性、高可用性、灾难恢复和自动变更管理的设计模式。
- 尽可能自行修复的组件,以及包含可监测性的插桩的代码。
- 运行服务的操作过程必须将运营人员的手动工作量和认知负担降到最低,同时可让您快速检测并缓解故障。
可靠性是所有工程人员(例如开发、产品管理、运营和站点可靠性工程 (SRE) 团队)的责任。每个人都必须负起责任,了解其应用的可靠性目标、风险和错误预算。团队应该能够适当地确定工作的优先级,并上报可靠性和产品功能开发之间的优先级冲突。
在架构框架的可靠性类别中,您将了解如何执行以下操作:
- 了解核心可靠性原则
- 确定您的可靠性目标
- 定义 SLO
- 采用 SLO
- 将可观测性内置到您的基础架构和应用中
- 在设计时确保可扩缩性和高可用性
- 创建可靠的操作流程和工具
- 构建高效的提醒
- 构建突发事件管理协作流程
可靠性原则
架构框架中的本文档介绍了在云平台上运行可靠服务的一些核心原则。这些原则有助于在您阅读架构框架的其他部分时,建立共识,了解某些 Google Cloud 产品和功能如何支持可靠的服务。
主要术语
有几个与可靠性实践相关的常用术语。许多读者可能都很熟悉。但是,如果要回顾一下,请参阅术语页面中的详细说明。
核心原则
Google 的可靠性理念源于以下核心原则。
可靠性是您的首要任务
从短期来看,新产品功能有时会是您的首要任务。但从长远来看,可靠性是您的首要产品功能,因为如果产品速度太慢或长时间不可用,就可能会被用户放弃,从而使其他产品功能无关紧要。
可靠性由用户定义
对于面向用户的工作负载,请衡量用户体验。用户必须对您的服务的表现满意。例如,衡量用户请求的成功率,而不仅仅是查询 CPU 使用率等服务器指标。
对于批量和流式工作负载,您可能需要衡量数据吞吐量的关键性能指标 (KPI),例如每个时间窗口扫描的行数,而不需要衡量服务器指标,如磁盘使用率。吞吐量 KPI 有助于确保用户需要的每日报告或季度报告按时完成。
100% 可靠性是错误的目标
您的系统应足够可靠以确保用户满意,但不能过于可靠以至投资不合理。确定 SLO 以设置所需的可靠性阈值,然后使用错误预算将变化速率控制在适当的范围内。
只有当该产品或应用的 SLO 与费用相符时,才将此框架中的设计和操作原则应用于产品。
可靠性和快速创新相辅相成
使用错误预算在系统稳定性和开发者敏捷性之间取得平衡。以下指导可帮助您确定何时应该加快或放慢速度:
- 如果错误预算充足,您可以快速创新、改进产品或添加产品功能。
- 当错误预算减少时,请放慢速度并专注于可靠性功能。
设计和操作原则
为了最大限度地提高系统可靠性,需要遵循以下设计和操作原则。架构框架可靠性类别的其余部分中详细讨论了其中每个原则。
确定您的可靠性目标
架构框架的这一部分中介绍的最佳做法包括以下内容:
- 选择适当的 SLI。
- 根据用户体验设置 SLO。
- 反复验证以改进 SLO。
- 使用严格的内部 SLO。
- 使用错误预算来管理开发速度。
如需了解详情,请参阅架构框架可靠性类别中确定您的可靠性目标。
将可观测性内置到您的基础架构和应用中
架构框架的这一部分介绍了以下设计原则:
- 对代码进行插桩以最大限度地提高可观测性。
如需了解详情,请参阅架构框架可靠性类别中的将可观测性内置到您的基础架构和应用中。
在设计时确保可扩缩性和高可用性
架构框架的这一部分介绍了以下设计原则:
- 创建冗余以实现更高的可用性。
- 跨区域复制数据以进行灾难恢复。
- 设计多地区架构以应对地区级服务中断。
- 消除可扩缩性瓶颈。
- 过载时平缓降低服务水平。
- 预防和缓解流量峰值。
- 清理并验证输入。
- 以可以保留系统功能的方式进入故障安全模式。
- 将 API 调用和操作命令设计为可重试。
- 识别和管理系统依赖项。
- 最大限度地减少关键依赖项。
- 确保可以回滚所有更改。
如需了解详情,请参阅架构架构可靠性类别中的在设计时确保可扩缩性和高可用性。
创建可靠的操作流程和工具
架构框架的这一部分介绍了以下操作原则:
- 为应用和服务选择良好的名称。
- 借助 Canary 测试过程实现渐进式发布
- 为限时促销和发布活动分散流量。
- 自动执行构建、测试和部署流程。
- 防范运维人员的错误。
- 测试故障恢复过程。
- 执行灾难恢复测试。
- 试验混沌工程。
如需了解详情,请参阅架构框架可靠性类别中创建可靠的操作流程和工具。
构建高效提醒
架构框架的这一部分介绍了以下操作原则:
- 优化提醒延迟时间。
- 针对表现(而非原因)触发提醒。
- 针对离群值(而不是平均值)触发提醒。
如需了解详情,请参阅架构框架可靠性类别中构建高效的提醒。
构建突发事件管理协作流程
架构框架的这一部分介绍了以下操作原则:
- 指定明确的服务所有权。
- 利用经过微调的提醒来缩短检测时间 (TTD)。
- 通过突发事件管理计划和培训,缩短缓解时间 (TTM)。
- 设计信息中心布局和内容以最大限度地缩短 TTM。
- 针对已知的中断情况记录诊断过程和缓解措施。
- 利用无责备事后分析来了解服务中断情况并防止再次发生。
如需了解详情,请参阅架构框架可靠性类别中的构建突发事件管理协作流程。
后续步骤
- 确定您的可靠性目标(本系列的下一个文档)
探索架构框架中的其他类别,例如系统设计、卓越运营以及安全性、隐私权和合规性。
确定您的可靠性目标
Google Cloud 架构框架中的本文档提供的最佳实践用于定义衡量服务的客户体验的适当方法,以便您可以运行可靠的服务。您将学习如何反复验证您确定的服务等级目标 (SLO),并使用错误预算来了解发布其他更新时可靠性可能受到影响的时间。
选择适当的 SLI
请务必选择适当的服务等级指标 (SLI) 来全面了解您的服务表现如何。例如,如果应用采用多租户架构(多个独立客户使用的典型 SaaS 应用),请务必按租户级层捕获 SLI。如果您仅在全球汇总级层衡量 SLI,您可能会错过应用中会影响单个重要客户或少数客户的关键问题。改为设计应用以在每个用户请求中包含租户标识符,然后将该标识符传播到应用栈的每一层。此标识符可让您的监控系统在请求路径中的每一层或微服务中汇总租户级层的统计信息。
您运行的服务类型还决定了要监控的 SLI,如以下示例所示。
投放系统
以下 SLI 通常是提供数据的系统的 SLI:
- 可用性反映服务可用时间所占的比例。它通常根据格式正确的成功请求来定义,例如 99%。
- 延迟时间反映特定百分比的请求可以完成的速度。它通常用除第 50 百分位以外的百分位来定义,例如,“第 99 百分位为 300 ms”。
- 质量反映特定响应的好坏程度。质量的定义通常是特定于服务的,用于指明对请求的响应内容与理想响应内容的差异程度。响应质量可以用二进制数表示(好或差),也可以用 0% 到 100% 来表示。
数据处理系统
以下 SLI 通常是处理数据的系统的 SLI:
- 覆盖率反映已处理的数据比例,例如 99.9%。
- 正确率反映被视为正确的输出数据所占的比例,例如 99.99%。
- 新鲜度反映源数据或汇总输出数据的新鲜程度。通常更新越新越好,例如 20 分钟。
- 吞吐量反映正在处理的数据量,例如 500 MiB/秒甚至 1000 个请求/秒 (RPS)。
存储系统
以下 SLI 通常是存储数据的系统的 SLI:
- 耐用性反映写入系统的数据将来被检索的可能性,例如 99.9999%。任何数据永久丢失事件都会降低耐用性指标。
- 吞吐量和延迟时间也是存储系统的常见 SLI。
选择 SLI 并根据用户体验设置 SLO
本架构框架部分的核心原则之一是可靠性由用户定义。尽可能靠近用户来衡量可靠性指标,例如以下选项:
- 如果可能,请对移动或 Web 客户端进行插桩。
- 例如,使用 Firebase Performance Monitoring 来深入了解 iOS、Android 和 Web 应用的性能特征。
- 如果不可行,请对负载均衡器进行插桩。
- 例如,使用 Cloud Monitoring 进行外部应用负载均衡器日志记录和监控。
- 在服务器上衡量可靠性应作为最后的选择。
- 例如,使用 Cloud Monitoring 监控 Compute Engine 实例。
将您的 SLO 设置到合适的高度(不要太高),以便几乎所有用户都对您的服务感到满意。由于网络连接或其他暂时性客户端问题,您的客户可能不会注意到应用中短暂的可靠性问题,从而让您能够降低 SLO。
对于正常运行时间和其他重要指标,请尽量将目标值控制在 100% 以下,但接近此值。服务所有者应该客观地评估可让大多数用户满意的最低服务性能和可用性级别,而不仅仅是基于外部合同级别设置目标。
进行更改的速率会影响系统的可靠性。但是,频繁进行细微更改的能力有助于更快地提供更高质量的功能。根据客户体验调整要实现的可靠性目标往往有助于确定客户可以接受的最大更改速度和范围(即功能速度)。
如果您无法衡量客户体验并据此确定目标,则可以运行竞争性基准分析。如果没有可比较的竞争关系,即使您还无法确定目标,也要衡量客户体验。例如,衡量系统可用性或有意义且成功的客户交易率。您可以将此数据与业务指标或 KPI 相关联,例如零售订单的量或客户服务电话和工单量及其严重程度。在一段时间内,您可以使用这样的关联来达到合理的客户满意度阈值。此阈值就是您的 SLO。
反复验证以改进 SLO
SLO 不应一成不变。每季度一次或至少每年一次重新审视 SLO,并确认它们能够准确地反映用户满意度并与服务中断密切相关。确保它们涵盖当前的业务需求和新的关键用户历程。请在定期审核 SLO 之后,视需要对其进行增订。
使用严格的内部 SLO
建议将内部 SLO 设置得比外部 SLA 更严格。由于违反服务等级协议 (SLA) 往往要求您发放财务补偿或客户退款,而您希望在问题产生财务影响之前解决掉。
我们建议您将这些更严格的内部 SLO 与无责备的事后分析流程和突发事件审核搭配使用。如需了解详情,请参阅 Architecture Center 可靠性类别中的构建突发事件管理协作流程。
使用错误预算来管理开发速度
错误预算可说明您的系统在某个时间窗口内是高于还是低于所需的可靠性。一段时间内(例如 30 天)“错误预算”的计算公式为 (100% – SLO)。
当错误预算中有剩余容量时,您可以继续快速发布改进或新功能。当错误预算接近零时,请冻结或减慢服务更改,并投入工程资源以提高可靠性特性。
Google Cloud Observability 包含 SLO 监控,可最大限度减少设置 SLO 和错误预算的工作量。服务包含一个图形界面(可帮助您手动配置 SLO)、一个 API(用于以编程方式设置 SLO)和一个内置信息中心(用于跟踪错误预算资金消耗率)。如需了解详情,请参阅如何创建 SLO。
建议
如需将架构框架中的指导运用到您自己的环境,请遵循以下建议:
- 确定和衡量以客户为中心的 SLI,例如服务的可用性或延迟时间。
- 定义比外部 SLA 更严格、以客户为中心的错误预算。包含违规后果,例如生产冻结。
- 设置延迟时间 SLI 以捕获离群值(例如第 90 或第 99 百分位),以检测最慢响应。
- 每年至少审核一次 SLO,并确认它们与用户满意度和服务中断情况密切相关。
后续步骤
详细了解如何使用以下资源定义可靠性目标:
探索架构框架中的其他类别,例如系统设计、卓越运营以及安全性、隐私权和合规性。
定义 SLO
本文档是由两部分组成的系列中的第 1 部分,其中介绍了运营在线服务的团队如何使用服务等级目标 (SLO) 开始构建和采用站点可靠性工程 (SRE) 文化。SLO 是服务的目标可靠性等级。
在软件即服务 (SaaS) 中,产品开发的速度和运营稳定性之间存在着自然压力。对系统的更改越多,它就越有可能崩溃。监控和可观测性工具可帮助您在提高开发速度时保持对运营稳定性的信心。不过,虽然此类工具(也称为应用性能管理 (APM) 工具)很重要,但这些工具最重要的一个应用是设置 SLO。
如果定义正确,SLO 可以帮助团队做出数据驱动型运营决策,从而加快开发速度,而不会影响稳定性。SLO 还可让开发和运营团队围绕单个商定目标开展工作,从而缓解其目标(创建和迭代产品(开发)和维护系统完整性(运营))之间存在的自然压力。
SLO 以及其他 SRE 做法在 SRE 书籍和 SRE 手册中详细介绍。本系列文章介绍了如何简化理解和开发 SLO 的过程,以帮助您更轻松地采用它们。阅读并理解这些文章后,您可以在书籍中找到更多信息。
本系列文章向您介绍有关在组织中实施 SLO 的清晰路径:
- 本文档介绍什么是 SLO 以及如何为您的服务定义 SLO。
- 采用 SLO 介绍介于工作负载类型的不同 SLO 类型,如何衡量这些 SLO,以及如何根据这些 SLO 开发提醒。
本系列文章面向 SRE、运营团队、DevOps、系统管理员以及负责在线服务稳定性和可靠性的其他人员。其中假定您了解互联网服务与网络浏览器和移动设备的通信方式,并且您对网络服务的监控、部署和问题排查方式有基本了解。
DevOps 现状报告确定了可提高软件交付方面表现的功能。本系列文章将帮助您使用以下功能:
为什么选择 SLO?
构建 SRE 文化时,为什么从 SLO 开始?简而言之,如果您不定义服务等级,则很难衡量您的客户是否对您的服务感到满意。即使您知道您可以改进服务,但只要缺乏定义的服务等级,就很难确定改善之处和投入力度。
您可能倾向于为每项服务开发单独的 SLO,而不考虑是否面向用户。例如,一种常见的错误是分来衡量两个或多个服务,例如前端服务和后端数据存储区,其中用户依赖两个服务但不知道两者的区别。更好的方法是开发基于产品(服务集合)的 SLO,并专注于您的用户与其进行的最重要互动。
因此,要开发有效的 SLO,最好了解您的用户与您的服务的互动,这称为关键用户旅程 (CUJ)。CUJ 会考虑用户的目标,以及用户如何使用您的服务来实现这些目标。CUJ 可从客户的角度定义,而不考虑服务边界。满足 CUJ 后,客户很满意,而客户满意是服务成功的关键衡量指标。
服务的可靠性是客户服务满意度的一个关键方面。如果服务不可靠,则服务的用途并不重要。因此,可靠性是任何服务最重要的特征。可靠性的一个常见指标是正常运行时间,这通常指系统已启动的时间量。但是,我们更倾向于更实用、更精确的指标:可用性。与衡量系统停机时间相比,可用性仍回答系统是否已启动的难问题,但更为精确。在当今的分布式系统中,服务可能会部分停机,而正常运行时间无法很好地捕获此因素。
可用性通常按多个九来描述,例如 99.9% 可用(三个九)或 99.99% 可用(四个九)。衡量可用性 SLO 是衡量系统可靠性的最佳方法之一。
除了帮助定义运营成功之外,SLO 还可以帮助您选择资源投入领域。例如,SRE 书籍通常会指出,您为之设计的每个九都会产生增量费用和边际效用。人们通常认为,实现可用性中下一个九的费用是前一个九的十倍。
选择 SLI
要确定是否满足 SLO(即成功),需要衡量指标。此衡量指标称为服务等级指标 (SLI)。SLI 衡量您提供给客户的特定服务的等级。理想情况下,SLI 与接受的 CUJ 关联。
选择最佳指标
开发 SLI 的第一步是选择要衡量的指标,例如每秒请求数、每秒错误数、队列长度、响应代码在指定时间段的分布或传输的字节数。
此类指标通常属于以下类型:
- 计数器。例如,在给定衡量点发生的错误数。此类指标会增加,但不会减少。
- 分布。例如,在给定时间段内填充特定衡量指标细分的事件数。您可以衡量 0-10 毫秒内完成的请求数、11-30 毫秒内完成的请求数,以及 31-100 毫秒内完成的请求数。结果是每个存储桶的计数,例如 [0-10: 50]、[11-30: 220]、[31-100: 1103]。
- 采用平均值。例如,系统的可衡量部分的实际值(例如队列长度)。此类指标会增加也会减少。
如需详细了解这些类型,请参阅 Prometheus 项目文档和 Cloud Monitoring 指标类型 ValueType
和 MetricKind
。
SLI 的一个重要区别是并非所有指标都是 SLI。实际上,SRE 手册会声明以下内容(已添加实证):
许多软件公司都会跟踪数百或数千个指标;只有少数指标符合 SLI 的要求。除了衡量良好事件与事件总数的比率之外,哪个指标可用作良好 SLI?理想的 SLI 指标具有以下特征:
- 指标与用户满意度直接相关。通常,如果服务的行为与期望不符、失败或缓慢,用户会不满意。任何基于这些指标的 SLO 都可以通过将 SLI 与其他用户满意度指标(例如客户投诉工单数量、支持电话数量、社交媒体情感或上报情况)进行比较来验证。如果您的指标与用户满意度的其他指标不对应,则可能不是用作 SLI 的良好指标。
- 指标恶化与中断相关。 在中断期间看起来良好的指标是 SLI 的错误指标。正常运营期间表现不佳的指标也是 SLI 的错误指标。
- 指标提供良好的信噪比。导致大量假负例或假正例的任何指标都不是良好 SLI。
- 指标随客户满意度单调扩缩,且近似线性扩缩。随着指标改善,客户满意度会提高。
考虑下图中的图表。随着时间的推移绘制了两个可用作服务 SLI 的指标。服务降级的时间段以红色突出显示,而服务良好的时间段以蓝色突出显示。
在发生不良 SLI 的情况下,用户不满意未直接对应于负面事件(例如服务降级、缓慢或中断)。此外,SLI 独立于用户满意度波动。在良好 SLI 中,SLI 和用户满意度相关联,不同的满意度等级清晰,且不相关波动要少得多。
选择适当数量的指标
通常,单个服务具有多个 SLI,特别是在服务执行不同类型的工作或向不同类型的用户提供服务时。例如,最好将读取请求与写入请求分开,因为这些请求会以不同的方式运作。在这种情况下,最好选择适用于每个服务的指标。
相比之下,许多服务在整个服务中执行类型相似的工作,可以直接进行比较。例如,如果您拥有网店,用户可能会查看首页、查看子类别或热门 10 清单,查看详细信息页面,或者搜索商品。您可以将这些操作组合成一个 SLI 类别,例如浏览服务,而不是为其中每项操作开发和衡量单独 SLI。
实际上,用户的期望不会在类似类别的操作之间发生大幅变化。用户满意度不取决于他们所浏览的数据的结构,无论数据是派生自宣传商品的静态列表,还是利用跨大型数据集的机器学习辅助搜索动态生成的结果。通过回答以下问题,可以量化用户满意度:“我是否很快看到整页的商品?”
理想情况下,您希望使用尽可能少的 SLI 来准确表示给定服务的容忍度。通常,一个服务应该具有 2 到 6 个 SLI。如果 SLI 太少,可能会错过有价值的信号。如果 SLI 过多,您的电话接听团队就要跟踪太多东西,但边际附加效用有限。请记住,SLI 应简化您对生产运行状况的理解,并提供覆盖率。
选择 SLO
SLO 由以下值组成:
- SLI。例如,包含 HTTP 代码
200
的响应数与响应总数的比率。 - 持续时间。指标的衡量时间段。此时间段可以基于日历(例如,从一个月的第一天到第二个月的第一天),也可以是滚动窗口(例如,过去 30 天)。
- 目标。例如,您希望在给定持续时间内满足的良好事件占事件总数的目标百分比(例如 99.9%)。
开发 SLO 时,定义持续时间和目标可能会很困难。开始此过程的一种方法是确定 SLI 并随时间绘制图表。如果您无法确定要使用的持续时间和目标,请记住您的 SLO 不一定完美。您很可能会迭代您的 SLO,以确保它符合客户满意度并满足您的业务需求。您可以尝试从一个月两个九 (99.0%) 开始。
在部署、中断和每日流量模式等事件期间跟踪 SLO 合规性时,您可以深入了解哪些目标良好,哪些较差,或者哪些可容忍。例如,在后台进程中,您可以将 75% 的成功率定义为足够。但对于任务关键型、面向用户的请求,您可能会设定更积极的目标,例如 99.95%。
当然,没有单个 SLO 适用于每种用例。SLO 依赖于以下几个因素:
- 客户期望
- 工作负载类型
- 用于传送、执行和监控的基础架构
- 问题领域
本系列文章中的第 2 部分采用 SLO 侧重于与领域无关的 SLO。与领域无关的 SLO(例如服务可用性)不会替换简要指标(例如每分钟销售的微件)。但是,无论企业用例如何,它们都可以帮助衡量服务是否正常工作。
与领域无关的指标通常可以减少到一个问题;例如,“服务是否可用?”或“服务是否足够快?”在考虑两个因素的 SLO 中最常找到答案:可用性和延迟时间。您可以采用以下措辞描述 SLO,其中 X = 99.9% 且 Y = 800 毫秒:
后续步骤
- 请参阅采用 SLO,其中详细探讨了这些定义,并介绍了可能更适合各种工作负载类型的其他 SLI。
- 查看其他 SRE 资源:
- 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud Architecture Center。
- 阅读我们关于 DevOps 的资源。
- 详细了解与本系列相关的 DevOps 功能:
- 进行 DevOps 快速检查,了解您与业界其他公司相比所处的位置。
采用 SLO
本文档定义了几个服务等级目标 (SLO),它们适用于不同类型的常见服务工作负载。本文档为两部分文章中的第 2 部分。第 1 部分定义 SLO 中介绍了 SLO,展示了 SLO 是如何从服务等级指标 (SLI) 派生的,并描述了什么是良好的 SLO。
DevOps 现状报告确定了可提高软件交付方面表现的功能。这两个文档可以帮助您实现以下功能:
衡量的指标
无论您的网域如何,许多服务都具有相同的功能,可以使用通用 SLO。以下关于通用 SLO 的讨论按服务类型组织,并详细介绍了适用于每个 SLO 的 SLI。
请求驱动的服务
请求驱动的服务会接收来自客户端(其他服务或用户)的请求,执行一些计算,可能将网络请求发送到后端,然后向客户端返回一个响应。请求驱动的服务通常通过可用性和延迟时间 SLI 来衡量。
可用性作为 SLI
可用性 SLI 表示服务是否正常运行。可用性 SLI 的定义如下:
首先,您需要定义“有效”。一些基本定义可能是“长度非零”或“遵循客户端-服务器协议”,但服务所有者负责定义“有效”的含义。衡量有效性的一种常用方法是使用 HTTP(或 RPC)响应代码。例如,我们通常认为 HTTP 500
错误是要计入 SLO 的服务器错误,而 400
错误则是不用计入的客户端错误。
在确定要衡量的指标后,您需要检查系统返回的每个响应代码,以确保应用正确、一致地使用这些代码。为 SLO 使用错误代码时,务必询问代码是否是用户服务体验的准确指标。例如,如果用户尝试订购缺货的商品,网站是否会中断并返回错误消息,或者网站是否会建议类似产品?为了与 SLO 配合使用,错误代码需要与用户的期望相关联。
开发人员可能会误用错误。如果用户询问商品暂时缺货的产品,开发人员可能会错误地编写要返回的错误。不过,系统实际上正常运行,没有出现错误。即使用户无法购买所需商品,代码也需要作为成功返回。当然,此服务的所有者需要知道某个产品缺货,但从客户的角度来看,无法进行销售不是错误,不应计入 SLO。但是,如果服务无法连接到数据库以确定商品是否有库存,则这是一个错误,应计入错误预算。
您的服务可能会更复杂。例如,您的服务可能处理异步请求或为客户提供长时间运行的过程。在这些情况下,您可以通过其他方式公开可用性。但是,我们建议您仍将可用性表示为成功的有效请求的比例。您可以将可用性定义为客户的工作负载按请求运行的分钟数。(此方法有时称为衡量可用性的“良好时间”方法。)对于虚拟机,您可以根据初始请求后可通过 SSH 访问虚拟机的分钟比例来衡量可用性。
延迟时间作为 SLI
延迟时间 SLI(有时称为“速度”)指示服务是否足够快。“延迟时间”SLI 的定义与“可用性”类似:
如需测量延迟时间,可以计算计时器启动时间与给定请求类型的停止时间之间的差异。关键是用户对延迟的感知。常见的隐患是衡量延迟时间时过于精确。实际上,用户无法区分 100 毫秒 (ms) 和 300 毫秒的刷新时间,可能会接受 300 毫秒到 1000 毫秒之间的任意值。
相反,最好是开发以活动为中心的指标,可以让用户集中注意力,例如,在以下流程中:
- 交互式:用户在点击元素后等待结果的时间,1000 毫秒。
- 写入:1500 毫秒,用于更改底层分布式系统。虽然对于系统而言,此时间长度会被视为缓慢,但用户往往倾向于接受该时间。我们建议您在指标中明确区分写入和读取。
- 后台:5000 毫秒,针对用户不可见的操作,例如定期刷新数据或其他异步请求。
延迟时间通常以分布的形式进行衡量(参见本系列第 1 部分中的选择 SLI)。在给定分布的情况下,您可以测量各种百分位数。例如,您可以测量比历史第 99 个百分位慢的请求数。在本例中,我们认为好的事件是比这个阈值快的事件,而这个阈值是通过检查历史分布设置的。您还可以根据产品要求设置此阈值。您甚至可以设置多个延迟时间 SLO,例如典型延迟时间与尾延迟时间。
我们建议您不要仅使用平均(或中位数)延迟时间作为 SLI。发现中位数延迟时间太慢意味着一半的用户已经感到不满意。换句话说,在发现对长期错误预算的真正威胁之前,可能会有好几天的延迟。因此,我们建议您为尾延迟时间(第 95 百分位)和延迟时间中位数(第 50 百分位)定义 SLO。
在 ACM 文章重要指标中,Benjamin Treynor Sloss 写下以下内容:
Treynor Sloss 继续写道:
可以遵循的一个好模型是根据历史百分位数确定延迟时间阈值,然后测量每个存储桶中有多少请求。如需了解更多详情,请参阅本文档后面有关延迟时间提醒的部分。
质量作为 SLI
对于复杂的服务而言,质量是很有帮助的 SLI,这些服务 (SLI) 设计为在依赖项变慢或不可用时通过降级来正常失败。质量 SLI 的定义如下:
例如,网页可以从一个数据存储区加载其主要内容,并从其他 100 个服务和数据存储区加载辅助性的可选资源。如果一项可选服务已停止服务或运行速度过慢,该网页仍可以在没有辅助元素的情况下呈现。通过测量已传递降级响应的请求数(即,缺少至少一个后端服务响应的响应),可以报告不良请求的比例。您甚至可以跟踪有多少对用户的响应缺少来自单个后端的响应,或者缺少来自多个后端的响应。
数据处理服务
有些服务不是为了响应用户请求而构建的,而是使用来自输入的数据、处理该数据并生成输出。这些服务在中间步骤中如何表现并没有最终结果那么重要。对于此类服务,最强大的 SLI 是“新鲜度”“覆盖率”“正确性”和“吞吐量”,而不是“延迟时间”和“可用性”。
新鲜度作为 SLI
“新鲜度”SLI 的定义如下:
例如,在批处理系统中,新鲜度可以是为给定输出成功运行一项处理后所经过的时间。在更复杂的或实时处理系统中,您可以跟踪在流水线中处理的最新记录的存在时间。
例如,假设一款实时生成地图块的在线游戏。用户可能不会注意到创建地图块的速度有多快,但他们可能会注意到地图数据丢失或不是最新。
或者,假设某个系统会读取库存跟踪系统的记录,从而为电子商务网站生成消息“X 件商品有货”。您可以按以下方式定义“新鲜度”SLI:
您还可以使用传递非刷新数据的指标来通知质量 SLI。
覆盖率作为 SLI
“覆盖率”SLI 的定义如下:
如需定义覆盖率,请先确定是将输入作为有效项接受还是跳过该输入。例如,如果输入记录损坏或长度为零,无法处理,您可以考虑将该记录视为无效,用于测量您的系统。
接下来,您计算有效记录的数量。您可以使用简单的 count()
方法或其他方法来执行此步骤。此数字是您的总记录数。
最后,要生成覆盖率 SLI,您需要计算已成功处理的记录数,并将该数量与有效记录记录总数进行比较。
正确性作为 SLI
“正确性”SLI 的定义如下:
在某些情况下,您可以通过多种方法确定输出的正确性,以验证输出的处理情况。例如,旋转图片或为之着色的系统绝不应产生零字节图片,或长度或宽度为零的图片。请务必将此验证逻辑与处理逻辑本身区分开来。
测量正确性 SLI 的一种方法是使用已知良好的测试输入数据,即具有已知正确输出的数据。输入数据需要代表用户数据。在其他情况下,可能会对输出进行数学或逻辑检查,如前面旋转图片的示例所示。另一个示例可能是结算系统,它通过检查交易前的余额与交易后的余额之间的差值是否与交易本身的值相符来确定交易是否有效。
吞吐量作为 SLI
“吞吐量”SLI 的定义如下:
在数据处理系统中,吞吐量通常比对给定工作的单一延迟度量等更能代表用户的满意度。例如,如果每个输入的大小变化很大,那么如果作业以可接受的速度进行,比较每个元素完成的时间可能就没有意义了。
“每秒字节数”是测量处理数据所需工作量(无论数据集的大小如何)的常用方法。但是,任何与处理成本大致成线性关系的指标都是可行的。
根据预期吞吐率对数据处理系统进行分区,或实现服务质量系统以确保处理高优先级输入和对低优先级输入进行排队,这可能是值得的。无论哪种方式,按照本节所定义的方式测量吞吐量都可以帮助您确定系统是否按预期工作。
计划执行服务
对于需要按固定间隔执行操作的服务(例如 Kubernetes cron 作业),您可以测量“偏差”和“执行时长”。以下是计划的 Kubernetes cron 作业示例:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "0 * * * *"
偏差作为 SLI
作为 SLI,“偏差”的定义如下:
“偏差”衡量作业的计划开始时间与实际开始时间之间的差异。例如,如果前面的 Kubernetes cron 作业设置为每小时零分钟开始,而实际在每个小时的第三分钟开始,则偏差为三分钟。如果作业提前运行,则偏差为负。
您可以用一段时间的分布情况来衡量偏差,并使用相应的可接受范围来定义良好的偏差。要确定 SLI,您需要比较良好范围内的运行次数。
执行时长作为 SLI
作为 SLI,“执行时长”的定义如下:
“执行时长”是指完成作业所需的时间。对于给定执行,常见的故障模式是实际时长超过计划时长。
一个有趣的案例是,如何使用此 SLI 来衡量永无止境的作业。由于这些作业没有完成,因此您需要记录给定作业花费的时间,而不是等待作业完成。此方法提供了工作完成时间(即使在最坏情况下)的准确分布。
与偏差一样,您可以将执行时长作为分布情况来跟踪,并为良好事件定义可接受的上限和下限。
其他系统的指标类型
许多其他工作负载都有自己的指标,可用于生成 SLI 和 SLO。请参考以下示例:
- 存储系统:耐用性、吞吐量、首字节时间、blob 可用性
- 媒体/视频:客户端播放连续性、开始播放的时间、转码图执行完整性
- 游戏:匹配活跃玩家的时间、生成地图的时间
如何衡量
在了解要衡量的内容之后,您可以决定如何进行测量。您可以通过多种方式收集您的 SLI。
服务器端日志记录
生成 SLI 的方法
处理请求或已处理数据的服务器端日志。
注意事项
优点:
- 可以重新处理现有日志以回填历史 SLI 记录。
- 跨服务会话标识符可以跨多个服务重建复杂的用户历程。
缺点:
- 系统不会记录未到达服务器的请求。
- 导致服务器崩溃的请求可能无法被记录。
- 处理日志的时间长度可能会导致过时的 SLI,这可能是因为操作响应的数据不足。
- 写入代码以处理日志可能是一项容易出错、耗时的任务。
实现方法和工具:
应用服务器指标
生成 SLI 的方法
从处理用户请求或处理其数据的代码导出 SLI 指标。
注意事项
优势:
- 向代码中添加新指标通常既快捷又费用不高。
缺点:
- 系统不会记录未到达应用服务器的请求。
- 多服务请求可能难以跟踪。
实现方法和工具:
- Cloud Monitoring
- Prometheus
- 第三方 APM 产品
前端基础架构指标
生成 SLI 的方法
利用负载均衡基础架构中的指标(例如,Google Cloud 的全球第 7 层负载均衡器)。
注意事项
优点:
- 指标和历史数据通常都已存在,因此减少了工程的入门工作量。
- 测量是在最靠近客户的位置进行,但仍在服务基础架构内。
缺点:
- 不适用于数据处理 SLI。
- 只能大致估算多请求用户历程。
实现方法和工具:
- Cloud Monitoring
- CDN/LB 指标或报告 API(Cloudflare、Akamai、Fastly)
合成客户端或数据
生成 SLI 的方法
构建定期发送虚构请求并验证响应的客户端。对于数据处理流水线,创建合成的、已知良好的输入数据并验证输出。
注意事项
优点:
- 衡量多请求用户历程的所有步骤。
- 从基础架构外部发送请求会捕获 SLI 中更多的整体请求路径。
缺点:
- 借助合成请求大致估算用户体验,可能会有误导性(误报或漏报)。
- 覆盖所有极端情况是困难的,可以转移到集成测试中。
- 可靠性高的目标需要频繁探测才能进行准确测量。
- 探测流量会消除真实流量。
实现方法和工具:
- Cloud Monitoring 正常运行时间检查
- 开源解决方案:
- 供应商解决方案:
客户端插桩
生成 SLI 的方法
向用户与之交互的客户端添加可观察性功能,并将事件记录回跟踪 SLI 的服务基础结构。
注意事项
优点:
- 提供最准确的用户体验衡量。
- 可以量化第三方(例如 CDN 或付款服务机构)的可靠性。
缺点:
- 客户端日志提取和处理延迟使这些 SLI 不适合触发操作响应。
- SLI 衡量指标将包含许多可能不受直接控制的高度可变的因素。
- 将插桩构建到客户端中可能涉及大量的工程工作。
实现方法和工具:
- Google Analytics、Firebase
- 用户分析:Armitude 及类似工具
- 移动/前端监控:New Relic Browser、Raygun Real User Monitoring、Sentry
- 用于记录和跟踪的自定义客户端和自定义服务器
选择测量方法
理想情况下,您需要选择与客户的服务体验密切相关的测量方法,并且需要投入一定的精力。为了实现此理想情况,您可能需要组合使用上表中的方法。下面是一个建议的方法,按工作量增加的顺序列出,您可以慢慢实现:
- 使用应用服务器导出和基础架构指标。通常,您可以立即访问这些指标,并且它们会快速提供值。一些 APM 工具包含内置 SLO 工具。
- 使用客户端插桩。由于旧式系统通常缺少内置的最终用户客户端插桩,因此设置插桩可能需要大量投入。但是,如果您使用能提供客户端插桩的 APM 套件或前端框架,则可以快速了解客户的满意度。
- 使用日志处理。如果您无法实现服务器导出或客户端插桩,但存在日志,则可能会发现日志处理是最有价值的。另一种方法是合并导出和日志处理,将导出用作某些 SLI(例如即时可用性)的直接源,将日志处理用于长期信号(例如 SLO 和提醒指南的后面部分所述的慢速消耗提醒)。
- 实现合成测试。在基本了解客户如何使用您的服务后,可以测试服务等级。例如,您可以用已知的良好数据为测试账号播种,并对其进行查询。此测试可以帮助突出显示不容易观察到的故障模式,例如低流量服务。
设定目标
设置目标的最佳方式之一就是创建一个描述 SLO 以及如何开发它们的共享文档。当文档随着时间的推移在 SLO 上实现和迭代时,您的团队可以对其进行迭代。
我们建议企业所有者、产品所有者和高管查看本文档。这些利益相关方可以提供关于服务预期以及产品可靠性权衡的见解。
对于贵公司最重要的关键用户历程 (CUJ),以下是开发 SLO 的模板:
- 选择 SLI 规范(例如可用性或新鲜度)。
- 定义如何实现 SLI 规范。
- 仔细阅读您的计划,确保涵盖您的 CUJ。
- 根据过去的性能或业务需求设置 SLO。
CUJ 不应限制为单个服务,也不应限于单个开发团队或组织。如果您的用户依赖于数百种以 99.5% 的可用性运行的微服务,但没有人跟踪端到端的可用性,则您的客户可能不满意。
假设您有一个查询依赖于按顺序工作的五个服务:负载均衡器、前端、Mixer、后端和数据库。
如果每个组件的可用性均为 99.5%,则最坏情况下面向用户的可用性如下:
这是最坏情况下面向用户的可用性,因为如果五个服务中的任何一个发生故障,整个系统将失败。只有在栈的所有层都必须立即可用来处理每个用户请求,而没有任何弹性因素(如中间重试、缓存或队列)的情况下,才会出现这种情况。在服务之间具有如此紧密耦合的系统是一种不合理的设计,并且与微服务模型不一致。
以零散的方式(逐个服务)根据分布式系统的 SLO 来衡量性能并不能准确地反映客户的体验,而且可能会导致过于敏感的解释。
相反,您应该根据前端的 SLO 来衡量性能,以了解用户的体验。如果用户的查询仍然成功,则用户不会关心组件服务是否失败,并导致系统自动成功重试查询。如果您共享了内部服务,则这些服务可以根据它们的 SLO 单独衡量性能,而面向用户的服务充当其客户。您应该单独处理这些 SLO。
使用智能重试、缓存和排队等弹性因素,可以在可用性较差的服务(例如 99.9%)之上构建高可用性服务(例如 99.99%)。
通常,任何具有统计工作知识的人都应能够阅读和理解您的 SLO,而无需了解您的基础服务或组织布局。
SLO 工作表示例
开发 SLO 时,请记住执行以下操作:
- 请确保您的 SLI 指定了一个事件、一个成功标准,以及您在哪里如何记录了成功或失败。
- 根据良好事件的比例定义 SLI 规范。
- 请确保您的 SLO 同时指定目标等级和测量时段。
- 描述您方法的优点和缺点,以便相关方了解所涉及的权衡和微妙之处。
例如,请考虑以下 SLO 工作表。
CUJ:首页加载 |
---|
SLI 类型:延迟时间 SLI 规范:在 100 毫秒内处理的首页请求的比例 SLI 实现:
SLO:过去 28 天内 99% 的首页请求在不到 100 毫秒内送达 |
后续步骤
- 阅读 SLO 艺术,这是 Google 客户可靠性工程团队开发的研讨会。
- 尝试学习站点可靠性工程:衡量和管理可靠性(这是有关如何构建 SLO 的在线课程)。
- 阅读站点可靠性工程:实现 SLO。
- 阅读服务监控中的概念。
- 了解如何使用 Cloud Monitoring 开发 SLO。
- 试用 Google 专业服务组织 (PSO) 提供的灵活 SLO 生成器。
- 探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。
- 阅读我们关于 DevOps 的资源。
- 详细了解与本系列相关的 DevOps 功能:
- 进行 DevOps 快速检查,了解您与业界其他公司相比所处的位置。
术语
本文档提供了 Google Cloud 架构框架:可靠性部分中使用的 SLO 相关术语的常见定义。
服务等级:用于衡量给定服务为用户完成其预期工作的指标。您可以基于“用户满意度”来描述此衡量指标,并根据各种方法进行衡量,具体取决于服务的用途以及用户希望执行的操作或告诉它可执行的操作。
示例:“用户希望我们的服务可用且快捷。”
关键用户旅程 (CUJ):用户为实现一个目标与服务进行的一组互动,例如单次点击或多步骤流水线。
示例:“用户点击‘结算’按钮,等待购物车处理完成,系统返回收据。”
服务等级指标 (SLI):可针对某个服务等级定量衡量的用户满意度指标。换句话说,要衡量服务等级,您必须衡量表示用户对该服务等级(例如,服务可用性)的满意度的指标。可以将 SLI 视为图上的一条线,随着服务改善或降级,该条线会随时间变化。 这通常是“正常”/“总计”的单选按钮,以无单位百分比表示。通过始终使用这些百分比,团队可以了解 SLI,而无需深入了解其实现
示例:“衡量过去 10 分钟内的成功请求数量,除以过去 10 分钟内所有有效请求的数量。”
服务等级目标 (SLO):您希望服务在多数情况下达到并据以衡量 SLI 的等级。
示例:“在 14 天衡量的所有有效请求中,95% 的服务响应快于 400 毫秒 (ms)。”
服务等级协议 (SLA):有关未满足 SLO 时将会发生什么情况的描述。一般而言,服务等级协议 (SLA) 是提供商与客户之间的法律协议,甚至可能包含补偿条款。在与 SRE 相关的技术讨论中,我们通常会避免使用该术语。
示例:“如果服务在一个日历月内未达到 99.95% 可用性,则该服务提供商每分钟都会因不合规而补偿客户。”
错误预算:在您在违反 SLO 之前可承受的时间量或负面事件数量。此衡量指标可告诉您贵企业期望或可容忍的错误数。错误预算对于帮助您做出有潜在风险的决策至关重要。
示例:“如果我们的 SLO 达到 99.9% 可用性,我们允许 0.1% 的请求通过突发事件、事故或实验处理错误。”
SLO 和提醒
Google Cloud 架构框架:可靠性部分中的本文档详细介绍了有关 SLO 的提醒。
引入 SLO 等新可观测性系统的错误方法是使用该系统完全替换旧系统。相反,您应该将 SLO 视为一个补充系统。例如,我们建议您不要删除现有的提醒,而是将它们与这里介绍的 SLO 提醒并行运行。这种方法允许您发现哪些就有提醒是可预测的 SLO 提醒,哪些提醒与您的 SLO 提醒并行触发,以及哪些提醒永远不会触发。
SRE 的一个原则是根据症状而不是原因来提醒。SLO 本质上是对症状的测量。在用 SLO 提醒时,您可能会发现症状提醒与其他提醒一起触发。如果您发现旧有的基于原因的提醒触发时没有 SLO 或症状,则不妨完全关闭这些提醒、将它们转换为工单提醒或登录以供以后参考。
如需了解详情,请参阅 SRE 手册,第 5 章。
SLO 消耗率
SLO 的消耗率衡量的是故障向用户暴露错误和消耗错误预算的速度。通过测量消耗率,您可以确定服务违反其 SLO 的时间。基于 SLO 消耗率的提醒是一种很有价值的方法。请记住,您的 SLO 基于时长,而后者可能会很长(数周甚至数月)。但是,目标是快速检测在违规实际发生之前,导致 SLO 违规的条件。
下表显示了在给定的时间间隔内,如果 100% 的请求都失败(假设每秒查询数 (QPS) 是恒定的),则超过目标所需的时间。例如,如果您在 30 天内测量了 99.9% 的SLO,那么您可以在这 30 天内承受 43.2 分钟的完全停机时间。例如,所有停机时间可能会一次性发生,也可以分散到多个事件。
目标 | 90 天 | 30 天 | 7 天 | 1 天 |
---|---|---|---|---|
90% | 9 天 | 3 天 | 16.8 小时 | 2.4 小时 |
99% | 21.6 小时 | 7.2 小时 | 1.7 小时 | 14.4 分钟 |
99.9% | 2.2 小时 | 43.2 分钟 | 10.1 分钟 | 1.4 分钟 |
99.99% | 13 分钟 | 4.3 分钟 | 1 分钟 | 8.6 秒 |
99.999% | 1.3 分钟 | 25.9 秒 | 6 秒 | 0.9 秒 |
在实践中,如果您想获得较高的成功率,就不能承受任何 100% 中断的突发事件。但是,许多分布式系统可以部分失败或平缓降级。即使在这种情况下,您仍想知道是否需要人工介入(即使发生的是部分故障也是如此),而 SLO 提醒为您提供了确定这一点的方法。
何时提醒
一个重要问题是,何时根据 SLO 消耗率采取行动。通常情况下,如果将在 24 小时内耗尽错误预算,那么“现在”就是找人解决问题的时候了。
衡量故障率并不总是简单的。一系列小错误可能在当时看起来很可怕,但结果是短暂的,并且对 SLO 产生的影响无关紧要。同样,如果系统长时间轻微损坏,这些错误会累积为 SLO 违规。
理想情况下,您的团队会对这些信号做出反应,以便您在给定时间段内用完几乎所有的错误预算(而不是超出)。如果用得太多,则表示您违反了 SLO。如果用得太少,则承担的风险不够,或者让待命团队疲于应付。
您需要一种方法来确定系统何时崩溃到需要人工干预的程度。以下部分讨论了解决这个问题的一些方法。
快速消耗
SLO 消耗的一种类型是“快速 SLO 消耗”,因为它会快速消耗您的错误预算,并且需要您干预以避免 SLO 违规。
假设您的服务以每秒 1000 个查询 (QPS) 的速度正常运行,并且希望在一周七天的时间内保持 99% 的可用性。您的错误预算约为 600 万个允许错误(总请求数为 6 亿个)。例如,如果在错误预算耗尽之前还有 24 小时,则每秒的错误数限制为 70 个,或者是一小时内 252,000 个错误。这些参数基于一般规则:可呼叫事件至少占季度错误预算的 1%。
您可以选择在这一个小时过去之前检测这个错误率。例如,在观察 15 分钟每秒 70 个错误的速率后,您可能会决定呼叫待命工程师,如下图所示。
理想情况下,这个问题在您用掉 24 小时预算中的一个小时之前就解决了。选择较短的时段(例如,一分钟)来检测此速率可能太容易出错。如果检测目标时间短于 15 分钟,则可以调整此数字。
慢速消耗
另一种消耗率是“慢速消耗”。假设您引入了一个错误,在第 5 天或第 6 天消耗掉了周错误预算,或者在第 2 周消耗掉了月预算?最佳应对方法是什么?
在这种情况下,您可能会引入一个“慢速 SLO 消耗”提醒,让您知道在提醒时段结束之前,您将消耗掉整个错误预算。当然,该提醒可能会返回很多误报。例如,可能经常存在这样一种情况,即错误发生的时间很短,但速度很快就会消耗掉您的错误预算。在这些情况下,该条件是误报,因为它只持续很短的时间,不会长期威胁您的错误预算。请记住,目标不是消除所有的错误来源;而是要“保持在可接受的范围内,不超出您的错误预算”。对于不会对错误预算构成合理威胁的事件,您希望避免提醒人工干预。
对于慢速消耗事件,我们建议您通知一个工单队列(而不是呼叫或发送电子邮件)。慢速消耗事件不是紧急事件,但是在预算到期之前需要人工干预。这些提醒不应以电子邮件的形式发送给团队列表,否则很快会被忽略。工单应该可跟踪、可分配和可转移。团队应该针对工单负载、完结率、可操作性和重复项创建报告。过多的、无法操作的工单是手动操作的好例子。
熟练地使用 SLO 提醒需要时间,并取决于团队的文化和期望值。记住,您可以随着时间的推移对 SLO 提醒进行微调。根据需要,您还可以有多种提醒方法和不同的提醒时段。
延迟提醒
除了可用性提醒之外,您还可以设置延迟提醒。借助延迟时间 SLO,您可以测量未达到延迟时间目标的请求的百分比。通过使用此模型,您可以使用与用于检测错误预算是快速还是慢速消耗的相同提醒模型。
正如前面提到的延迟时间中位数 SLO,有一半的请求可以不符合 SLO。换句话说,在您检测到对长期错误预算的影响之前,您的用户会面临数天的延迟。相反,服务应定义“尾延迟时间目标”和“典型延迟时间”目标。我们建议使用历史第 90 百分位数来定义典型延迟时间,并使用第 99 百分位数定义尾延迟时间。设置这些目标后,您可以根据希望计入每个延迟时间类别的请求数量,以及速度太慢的数量,来定义 SLO。此方法的概念与错误预算相同,应同等对待。因此,您可能会得到这样的结论:“90% 的请求将在典型延迟时间内处理,99.9% 的请求将在尾延迟时间目标范围内处理”。这些目标可确保大多数用户体验到您的典型延迟时间,并且仍允许您跟踪有多少请求比您的尾延迟时间目标慢。
一些服务可能有高度不同的预期运行时。例如,在数据存储区中读写数据可能会有显著不同的性能预期。您可以引入运行时性能存储桶,而不是枚举所有可能的期望,如下表所示。这种方法假定这些类型的请求是可识别的,并预先分类到各个存储桶中。不要期望动态地对请求进行分类。
面向用户的网站 | |
---|---|
存储桶 | 预期最大运行时 |
读取 | 1 秒 |
写入/更新 | 3 秒 |
数据处理系统 | |
---|---|
存储桶 | 预期最大运行时 |
小 | 10 秒 |
中 | 1 分钟 |
大 | 5 分钟 |
巨大 | 1 小时 |
特大 | 8 小时 |
通过测量当前的系统,您可以了解这些请求通常需要多长时间才能运行。以处理视频上传的系统为例。如果视频很长,处理时间应该会更长。我们可以使用视频长度(以秒为单位)来将这个工作分类到一个存储桶中,如下表所示。该表记录了一周内每个存储桶的请求数以及不同的运行时分布百分比。
视频时长 | 一周内测量的请求数 | 10% | 90% | 99.95% |
---|---|---|---|---|
小 | 0 | - | - | - |
中 | 190 万 | 864 毫秒 | 17 秒 | 86 秒 |
大 | 2500 万 | 1.8 秒 | 52 秒 | 9.6 分钟 |
巨大 | 430 万 | 2 秒 | 43 秒 | 23.8 分钟 |
特大 | 81000 | 36 秒 | 1.2 分钟 | 41 分钟 |
从这样的分析,您可以得出提醒的几个参数:
- fast_typical:最多有 10% 的请求比这个时间快。如果有太多请求的速度超过了这个时间,则您的目标可能是错误的,或者您的系统可能发生了变化。
- slow_typical:至少 90% 的请求都比这个时间快。这个限制得出您的主延迟 SLO。这个参数指示大多数请求是否足够快。
- slow_tail:最少 99.95% 的请求比这个时间快。此限制可确保不会有太多慢速请求。
- deadline:用户 RPC 或后台处理超时并失败的点(通常已经硬编码到系统中的限制)。这些请求实际上不会很慢,但实际上会失败并报错,然后计入可用性 SLO。
定义存储桶的一项准则是将存储桶的 fast_typical、slow_typical 和 slow_tail 放在一个数量级内。这条准则可确保存储桶的宽度不会太大。我们建议您不要尝试防止存储桶之间的重叠或间隙。
存储桶 | fast_typical | slow_typical | slow_tail | deadline |
---|---|---|---|---|
小 | 100 毫秒 | 1 秒 | 10 秒 | 30 秒 |
中 | 600 毫秒 | 6 秒 | 60 秒(1 分钟) | 300 秒 |
大 | 3 秒 | 30 秒 | 300 秒(5 分钟) | 10 分钟 |
巨大 | 30 秒 | 6 分钟 | 60 分钟(1 小时) | 3 小时 |
特大 | 5 分钟 | 50 分钟 | 500 分钟(8 小时) | 12 小时 |
这会产生类似于 api.method: SMALL => [1s, 10s]
的规则。在这种情况下,SLO 跟踪系统将看到一个请求,确定其存储桶(可能通过分析其方法名称或 URI,并将名称与对照表进行比较),然后根据该请求的运行时更新统计信息。如果这个过程花了 700 毫秒,则在 slow_typical 目标范围内。如果花了 3 秒,则在 slow_tail 范围内。如果是 22 秒,则超出 slow_tail,但仍不是错误。
在用户满意度方面,您可以将缺少尾延迟时间视为等同于不可用。(即响应速度很慢,应被视为失败)。因此,我们建议您使用与可用性相同的百分比,例如:
典型延迟时间由您自己决定。Google 的一些团队认为 90% 是不错的目标。这与您的分析以及您为 slow_typical 选择时长的方式相关。例如:
建议的提醒
根据这些准则,下表包含一组 SLO 提醒基准。
SLO | 测量时段 | 消耗率 | 操作 |
---|---|---|---|
可用性,快速消耗 典型延迟时间 尾延迟时间 |
1 小时时段 | 不到 24 小时会违反 SLO | 呼叫某人 |
可用性,慢速消耗 典型延迟时间,慢速消耗 尾延迟时间,慢速消耗 |
7 天时段 | 超过 24 小时才会违反 SLO | 创建工单 |
SLO 提醒是需要时间来培养的技能。本部分中的时长是建议时长;您可以根据自身需求和精确程度来调整这些值。将提醒与测量时段或错误预算支出进行绑定可能会有所帮助,或者您可以在快速消耗和慢速消耗之间添加另一层提醒。
将可观测性内置到您的基础架构和应用中
Google Cloud 架构框架中的本文档提供了在服务中添加可观测性的最佳实践,以便您可以更好地了解服务性能并快速识别问题。可观测性包括监控、日志记录、跟踪、性能剖析、调试和类似系统。
监控是 Google SRE 手册中的服务可靠性层次结构的基础。如果没有适当的监控,您无法判断应用是否正常运行。
对代码进行插桩以最大限度地提高可观测性
精心设计的系统的目标是从开发阶段开始就具有适当的可观测性。不要等到应用进入生产阶段才开始观测。对代码进行插桩并考虑以下指导:
- 为了高效地进行调试和问题排查,请考虑要写入哪些日志和跟踪记录条目,以及要监控和导出哪些指标。对系统中最可能或最频繁出现的故障模式进行排序。
- 定期审核和删减监控。删除未使用或无用的信息中心、图形、提醒、跟踪和日志记录,以免杂乱无章。
Google Cloud Observability 提供实时监控、混合多云监控和日志记录(例如针对 AWS 和 Azure)以及跟踪、性能分析和调试。Google Cloud Observability 还可以自动发现和监控在 App Engine 上或 Istio 等服务网格中运行的微服务。
如果您要生成大量应用数据,可以使用 BigQuery 优化大规模提取分析事件日志。BigQuery 还适用于保存和分析来自监控框架的高基数时序数据。这种方法非常有用,因为它可让您以较低的费用运行任意查询,而无需尝试从头开始设计完美的监控,并将报告与监控分离开来。您可以使用 Looker 数据洞察或 Looker 根据数据创建报告。
推荐
如需将架构框架中的指导运用到您自己的环境,请遵循以下建议:
- 尽早实现监控,例如在启动迁移之前或将新应用部署到生产环境之前。
- 区别应用问题与底层云问题。使用 Monitoring API 或其他 Cloud Monitoring 产品和 Google Cloud 状态信息中心。
- 定义除监控之外的可观测性策略,包括跟踪、性能剖析和调试。
- 定期清理您未使用或未提供值的可观测性工件,例如不可执行的提醒。
- 如果您生成了大量可观测性数据,请将应用事件发送到 BigQuery 等数据仓库系统。
后续步骤
- 在设计时确保可扩缩性和高可用性(本系列的下一个文档)
探索架构框架中的其他类别,例如系统设计、卓越运营以及安全性、隐私权和合规性。
在设计时确保可扩缩性和高可用性
本文档在 Google Cloud 架构框架中,提供了在设计服务架构时需要遵循的设计原则,使这些服务能够容忍故障并根据客户需求进行缩容。当服务需求较高或发生维护事件时,可靠的服务将能够继续响应客户请求。以下可靠性设计原则和最佳实践应该是系统架构和部署计划的一部分。
创建冗余以实现更高的可用性
具有高可靠性需求的系统必须避免单点故障,并且必须在多个故障网域之间复制其资源。故障域是可以单独出现故障的资源池,例如虚拟机实例、可用区或地区。跨故障网域进行复制时,您可以获得高于单个实例可以达到的总体可用性水平。如需了解详情,请参阅地区和可用区。
作为可能属于系统架构的一个具体冗余示例,如需将 DNS 注册过程中的故障隔离到个别区域,请为同一网络中的实例使用区域级 DNS 名称以互相访问。
设计具有故障切换功能的多可用区架构以实现高可用性
您可以将应用的架构设计为使用分布在多个可用区中的资源池,并在可用区之间复制数据、进行负载均衡和自动执行故障切换,从而使应用灵活应对区域级故障。运行应用堆栈每一层的区域级副本,并消除架构中的所有跨可用区依赖项。
跨区域复制数据以进行灾难恢复
将数据复制或归档到远程地区,以便在发生地区级服务中断或数据丢失时进行灾难恢复。在使用复制功能时,除了因复制延迟而可能丢失少量数据之外,远程区域中的存储系统已经具有几乎最新的数据,因此恢复速度会更快。使用定期归档而非持续复制时,灾难恢复涉及从新区域的备份或归档中恢复数据。此过程通常会导致服务停机时间比激活持续更新的数据库副本更长,并且可能因连续备份操作之间的时间间隔而造成数据丢失。无论使用何种方法,整个应用堆栈都必须重新部署并在新区域中启动,并且在发生这种情况时服务将不可用。
如需详细了解灾难恢复概念和技术,请参阅针对云基础架构服务中断设计灾难恢复架构。
设计多区域架构以灵活应对区域级服务中断
如果您的服务需要在整个区域出现故障的罕见情况下持续运行,请将其设计为使用分布在不同区域的计算资源池。 运行应用栈每一层的地区级副本。
跨地区使用数据复制,并在地区发生故障时进行自动故障切换。某些 Google Cloud 服务具有多区域变体,例如 Spanner。为应对区域级故障,请在设计中尽可能使用这些多区域服务。如需详细了解地区和服务可用性,请参阅 Google Cloud 位置。
确保不存在跨地区的依赖项,使得将地区级故障的影响范围限制在该地区。
消除地区级单点故障,例如在无法访问时可能导致全球服务中断的单个地区主数据库。请注意,多区域架构的费用通常较高,因此在采用此方法之前,请综合考虑业务需求与费用。
如需进一步了解如何跨故障域实现冗余,请参阅云应用的部署原型 (PDF) 调查问卷。
消除可伸缩性瓶颈
识别无法超越单个虚拟机或单个区域资源限制的系统组件。某些应用会垂直扩缩,在其中,您可以在单个虚拟机实例上添加更多 CPU 核心、内存或网络带宽以处理负载增加的情况。这些应用对可伸缩性有严格的限制,并且您必须经常手动对其进行配置以处理增长。
如果可能,请将这些组件重新设计为横向扩缩,例如使用分片或分区,跨虚拟机或可用区扩缩。如需处理流量或使用量增长,添加更多分片即可。使用标准虚拟机类型,可自动添加以处理每个分片的负载增长。如需了解详情,请参阅构建可扩缩且弹性佳的应用时应遵循的模式。
如果您无法重新设计应用,则可以将自行管理的组件替换为无需用户操作即可横向扩缩的全托管式云服务。
过载时逐步降低服务级别
设计您的服务以承受过载。服务应该检测过载,并向用户返回降低质量的响应或减少部分流量,而不是在遇到过载时完全不能工作。
例如,服务可以使用静态网页响应用户请求,并暂时停用处理费用较昂贵的动态效果。从 Compute Engine 到 Cloud Storage 的热故障切换模式中详细介绍了此行为。或者,服务可以允许执行只读操作并暂时停用数据更新。
当服务降级时,应通知操作员以纠正错误情况。
预防和缓解流量峰值
请不要跨客户端同步请求。太多客户端在同一时刻发送流量会导致流量高峰,从而会导致级联故障。
在服务器端实施高峰缓解策略,例如限制、排队、减载或熔断、优雅降级和确定关键请求的优先级。
客户端上的缓解策略包括客户端限制和使用抖动的指数退避算法。
清理并验证输入
为了防止会导致服务中断或安全漏洞的错误、随机或恶意输入,请清理并验证 API 和操作工具的输入参数。例如,Apigee 和 Google Cloud Armor 有助于防范注入攻击。
定期使用模糊测试,其中自动化测试框架会有意使用随机、空的或过大的输入调用 API。在隔离的测试环境中进行这些测试。
操作工具应在更改发布之前自动验证配置更改,如果验证失败,则应拒绝更改。
以可以保留功能的方式进入故障安全模式
如果问题导致发生故障,系统组件应以可让整个系统继续运行的方式发生故障。这些问题可能为软件错误、输入或配置有误、计划外实例中断或人为错误。您的服务流程有助于确定您应该是过于宽松或过于简单,而不是过于限制。
请考虑以下示例场景以及应对故障的方法:
- 一般而言,最好是让配置错误或为空的防火墙组件故障打开,并允许未经授权的网络流量在操作员修复错误期间短时间通过。此行为可让服务保持可用,而不是故障关闭并阻止所有流量。该服务必须依靠应用栈中更深层次的身份验证和授权检查,在所有流量都通过时保护敏感区域。
- 但是,最好让控制用户数据访问的权限服务器组件故障关闭并阻止所有访问。当配置损坏时,此行为会导致服务中断,但可在故障打开时避免机密用户数据泄露的风险。
在这两种情况下,故障都应引发高优先级提醒,以便操作员可以解决错误情况。服务组件应偏于故障打开,除非这会对业务造成极大的风险。
将 API 调用和操作命令设计为可重试
API 和操作工具必须尽可能确保重试安全。处理许多错误情况的自然方法是重试以前的操作,但您可能不知道第一次尝试是否成功。
您的系统架构应使操作具有幂等性 - 如果您对一个对象连续执行两次或多次相同的操作,则应该会产生与单次调用相同的结果。非幂等性操作需要更复杂的代码,以避免系统状态损坏。
识别和管理服务依赖项
服务设计人员和所有者必须维护对其他系统组件的依赖项的完整列表。服务设计还必须包括从依赖项故障中恢复,或者如果完全恢复不可行,则优雅降级。考虑系统和外部依赖项(如第三方服务 API)使用的云服务的依赖项,识别具有非零故障率的每个系统依赖项。
设置可靠性目标时,请注意服务的 SLO 受其所有关键依赖项的 SLO 的数学约束。您的可靠性不会高于其中一个依赖项的最低 SLO。如需了解详情,请参阅服务可用性计算。
启动依赖项
与稳定状态行为相比,服务在启动时的行为会有所不同。启动依赖项可能与稳定状态运行时依赖项大不相同。
例如,启动时,服务可能需要从它很少再次调用的用户元数据服务加载用户或账号信息。如果许多服务副本在发生崩溃或例行维护后重启,则副本会严重增加启动依赖项的负载,尤其是在缓存为空且需要重新填充时。
测试服务在负载下启动,并相应地预配启动依赖项。考虑这样的设计:通过保存从重要启动依赖项中检索的数据的副本逐步将设计降级。此行为使您的服务可以使用可能过时的数据重启,而不是在关键依赖项中断时无法启动。在可行的情况下,您的服务稍后可以加载最新数据,以恢复正常运行。
在新环境中引导服务时,启动依赖项也很重要。设计应用堆栈并采用分层架构,各个层之间没有循环依赖关系。循环依赖关系可能看似可容忍,因为它们不会阻止对单个应用的增量更改。但是,循环依赖关系可能会使得在灾难使整个服务堆栈崩溃后难以或无法重启。
最大限度地减少关键依赖项
最大限度地减少服务的关键依赖项数量,即其故障不可避免地导致服务中断的其他组件。为了使您的服务能够更灵活地应对其依赖的其他组件中的故障或运行缓慢的问题,请考虑以下示例设计技术和原则,将关键依赖项转换为非关键依赖项:
- 提高关键依赖项的冗余级别。添加更多副本,从而降低整个组件变得不可用的可能性。
- 使用对其他服务的异步请求,而不是阻止响应,或使用发布/订阅消息功能将请求与响应分离。
- 缓存其他服务的响应,以从依赖项的短期不可用状态中恢复。
为使服务中故障或运行缓慢现象对依赖它的其他组件的影响较小,请考虑以下示例设计技术和原则:
- 使用具有优先次序的请求队列,并优先处理用户正在等待响应的请求。
- 从缓存中提供响应,以减少延迟时间和负载。
- 以可以保留功能的方式进入故障安全模式。
- 在流量过载时逐步降级。
确保可以回滚所有更改
如果没有明确定义的方法来撤消对服务进行的某些类型的更改,请更改服务的设计以支持回滚。应定期测试回滚流程。必须对每个组件或微服务的 API 进行版本控制,并且它们必须具有向后兼容性,使得上一代客户端继续随着 API 的发展而正常运行。此设计原则对于允许逐步发布 API 更改至关重要,可在必要时快速回滚。
对于移动应用而言,实现回滚的成本可能很高。Firebase Remote Config 是一项 Google Cloud 服务,可简化功能回滚。
您无法轻松回滚数据库架构更改,因此请分多个阶段执行。设计每个阶段,以允许按最新版本的应用和先前版本进行安全架构读取和更新请求。这种设计方法让您可以在最新版本出现问题时安全地回滚。
建议
如需将架构框架中的指导运用到您自己的环境,请遵循以下建议:
- 在客户端应用的错误重试逻辑中实现随机化指数退避算法。
- 实现具有自动故障切换功能的多区域架构,以实现高可用性。
- 使用负载均衡功能在分片和地区之间分布用户请求。
- 将应用设计为在过载时逐步降级。提供部分响应或提供有限功能,避免完全停止工作。
- 建立容量规划的以数据为依据的流程,并使用负载测试和流量预测来确定何时预配资源。
- 制定灾难恢复程序并定期进行测试。
后续步骤
- 创建可靠的运营流程和工具(本系列的下一个文档)
探索架构框架中的其他类别,例如系统设计、卓越运营以及安全性、隐私权和合规性。
创建可靠的操作流程和工具
Google Cloud 架构框架中的本文档提供了以可靠方式运行服务的操作原则,例如如何部署更新、在生产环境中运行服务以及测试故障。可靠性架构设计应涵盖服务的整个生命周期,而不仅仅是软件设计。
为应用和服务选择好的名称
避免在生产配置文件中使用内部代号,因为它们可能会造成混淆(尤其是对于较新的员工),从而增加服务中断的缓解时间 (TTM)。请尽可能为您的所有应用、服务和关键系统资源(例如虚拟机、集群和数据库实例)选择良好的名称,并遵守其各自的名称长度限制。良好的名称应描述实体的用途;应该是准确、具体且独特的,并且读起来应该是有意义的。良好的名称应避免首字母缩略词、代号、缩写以及可能具有冒犯性的用语,并且即使对外发布,也不会引发负面的公众反应。
借助 Canary 测试实现渐进式发布
对服务二进制文件或配置进行的即时全局更改本身就存在风险。逐步发布新版本可执行文件和配置更改。从一个小范围(例如一个可用区中的几个虚拟机)开始,逐步扩大范围。如果更改没有达到预期效果,或者在部署过程中的任何阶段对用户产生负面影响,则快速回滚。您的目标是在只影响一小部分用户流量时识别并解决错误,然后再在全球范围内发布更改。
设置一个 Canary 测试系统,该系统会注意到服务更改,并对更改后的服务器与其余服务器的指标进行 A/B 比较。系统应标记意外行为或异常行为。如果更改没有达到预期效果,则 Canary 测试系统应该会自动停止发布。问题可能很明显(如用户错误)或很细微(如 CPU 使用率增加或内存膨胀)。
最好在出现问题的第一个提示时停止并回滚,然后在没有服务中断时间压力的情况下诊断问题。更改通过 Canary 测试后,请逐步将其传播到更大的范围,例如先传播到一个完整的可用区,然后再传播到第二个可用区。让更改后的系统有时间逐步处理更多用户流量,以发现潜在的 bug。
如需了解详情,请参阅应用部署和测试策略。
为限时促销和发布活动分散流量
您可能有一些促销活动(例如在某个精确时间开始的促销),并鼓励许多用户同时连接到服务。如果是这样,请设计客户端代码以将流量分散到几秒内。在发出请求前添加随机延迟。
您还可以预热系统。预热系统时,您需要提前将预期的用户流量发送到系统,以确保系统按预期运行。此方法可以防止在规划的开始时间出现的即时流量高峰导致您的服务器崩溃。
自动构建、测试和部署
通过使用持续集成和持续交付 (CI/CD) 流水线,消除发布流程中的手动工作。执行自动集成测试和部署。 例如,使用 GKE 创建现代化 CI/CD 流程。
如需了解详情,请参阅持续集成、持续交付、测试自动化和部署自动化。
防范运维人员的错误
设计您的操作工具以拒绝可能无效的配置。当配置版本为空、部分或截断、损坏、逻辑不正确或不符合预期或者未在预期时间内收到时,检测并发出提醒。工具还应拒绝与先前版本存在很大差异的配置版本。
禁止范围宽泛导致可能具有破坏性的更改或命令。这些宽泛的命令可能是“撤消所有用户的权限”“重启此地区中的所有虚拟机”或“重新格式化此地区中的所有磁盘”。只有当操作员在部署配置时添加紧急替换命令行标志或选项设置时,才应该应用此类更改。
工具必须显示有风险的命令的影响范围(例如,更改影响的虚拟机数量),并且要求在工具继续操作之前需要明确的操作员确认。您还可以使用功能来锁定关键资源并防止意外或未经授权删除它们,例如 Cloud Storage 保留政策锁定。
测试故障恢复
定期测试从服务故障中恢复的操作过程。如果不进行定期测试,则当发生实际故障而需要这些过程时,它们可能不起作用。定期测试的内容包括地区性故障切换、如何回滚版本以及如何从备份恢复数据。
执行灾难恢复测试
与故障恢复测试一样,不要等到灾难来袭再行动。请定期测试和验证您的灾难恢复程序和流程。
您可以创建一个系统架构来提供高可用性 (HA)。此架构与灾难恢复 (DR) 并不完全重叠,但在考虑恢复时间目标 (RTO) 和恢复点目标 (RPO) 值时,通常需要考虑 HA。
HA 可帮助您达到或超出商定的操作性能级别,例如正常运行时间。当您在 Google Cloud 上运行生产工作负载时,您可以在第二个地区中部署被动或主动备用实例。在此架构中,如果主要地区发生灾难,应用会从不受影响的地区继续提供服务。如需了解详情,请参阅针对云服务中断设计灾难恢复架构。
试验混沌工程
考虑在测试做法中使用混沌工程。将实际故障引入到安全环境中的负载下生产系统的不同组件中。这种方法有助于确保对系统整体没有影响,因为您的服务会在每个级别正确处理故障。
注入到系统中故障可能包括 RPC 的崩溃任务、错误和超时,或者资源可用性的降低。使用随机故障注入功能来测试服务依赖项中的间歇性故障(波动)。这些行为在生产环境中难以检测和缓解。
混沌工程可确保将此类实验的影响降至最低并加以控制。您可以将此类测试视为实际服务中断的演习,并利用收集的所有信息来改善服务中断响应。
后续步骤
- 构建高效的提醒(本系列的下一个文档)
探索架构框架中的其他类别,例如系统设计、卓越运营以及安全性、隐私权和合规性。
构建高效提醒
Google Cloud 架构框架中的本文档提供了用来创建提醒以帮助您运行可靠服务的操作原则。您拥有有关服务性能的信息越多,问题出现时您做出的决策就越明智。设计提醒以及早并准确检测到所有会影响用户的系统问题,并最大限度地减少假正例。
优化提醒延迟时间
在以下两点之间会保持平衡:太早发送的提醒会给运营团队带来压力,太晚发送的提醒会导致长时间服务中断。在监控系统通知用户问题之前调整提醒延迟时间,以最大限度地减少检测时间,同时最大化信号与噪声。使用错误预算使用率来获得最佳提醒配置。
针对表现(而非原因)触发提醒
根据对用户体验的直接影响触发提醒。不符合全局或每个客户的 SLO 则会产生直接影响。不针对故障的每个可能的根本原因发出提醒,尤其是当影响仅限于单个副本时。设计良好的分布式系统可以从单副本故障中顺利恢复。
针对离群值(而不是平均值)触发提醒
监控延迟时间时,请定义 SLO,并为第 90、95 或 99 百分位延迟时间(而不是平均或第 50 百分位延迟时间)设置提醒(三选二)。良好的平均值或延迟时间中位数值可以在第 90 百分位或更高级别隐藏不可接受的高值,以免导致非常糟糕的用户体验。因此,在监控任何关键操作(例如,与网络服务器的请求-响应交互、数据处理流水线中的批量完成或者对存储服务的读取或写入操作)的延迟时间时,您都应该应用此离群值提醒原则。
构建突发事件管理协作流程
Google Cloud 架构框架中的本文档提供了管理服务和定义响应突发事件流程的最佳实践。所有服务都会出现突发事件,因此您需要一个有详尽文档记录的流程来高效响应这些问题并缓解这些问题。
突发事件管理概览
精心设计的系统最终会有无法达到 SLO 的时候,这是不可避免的。在缺少 SLO 的情况下,根据他们以往的经验来确定可接受的服务等级。无论 SLA 包含什么内容,客户都会上报给您的技术支持团队或类似团队。
为了给客户提供合适的服务,请制定并定期测试突发事件管理方案。该方案可以只有短短一页,是包含 10 项内容的一个核对清单。此过程可帮助您的团队缩短检测时间 (TTD) 和缓解时间 (TTM)。
TTM 优于 TTR,其中的 R 是英语 Repair(修复)或 Recovery(恢复)的首字母,它通常用于表示完全修复(而不是缓解)。TTM 强调快速缓解措施,以快速结束服务中断对客户的影响,然后再启动通常需要时间更长的流程来完全解决问题。
如果系统设计良好、运营出色,则其故障间隔时间 (TBF) 也会增加。换句话说,可靠性(包括良好的突发事件管理)的运营原则旨在降低故障频率。
如需运行可靠的服务,请在突发事件管理过程中运用以下最佳做法。
指定明确的服务所有权
所有服务及其关键依赖项都必须有明确的所有者,负责遵守其 SLO。如果存在重组或团队调优,则工程主管必须确保将所有权明确移交给新团队,一并移交所需的文档和进行适当的培训。服务的所有者必须很容易被其他团队发现。
利用经过微调的提醒来缩短检测时间 (TTD)
在缩短 TTD 之前,请查看并实施架构框架可靠性类别中的将可观测性内置到您的基础架构和应用中和确定您的可靠性目标部分中的建议。例如,区分应用问题和底层云问题。
一组完善的 SLI 会在适当的时间向您的团队发出提醒,而不会触发过多提醒。如需了解详情,请参阅架构框架可靠性类别的构建高效的提醒部分或“优化您的 SLI 指标:CRE 经验谈”。
通过突发事件管理计划和培训,缩短缓解时间 (TTM)
如需降低 TTM,请制定一个经过实践检验的突发事件管理方案。轻松获取环境变化数据。确保团队知道他们可以快速应用通用缓解措施以最大限度地缩短 TTM。这些缓解技术包括排空、回滚更改、增加资源容量以及降低服务质量。
如另一份架构框架可靠性类别文档中所述,创建可靠的操作流程和工具以支持安全、快速回滚更改。
设计信息中心布局和内容以最大限度地缩短 TTM
整理服务信息中心布局和导航,以便操作员可在一两分钟内确定服务及其所有关键依赖项是否正在运行。为了快速查明问题的潜在原因,操作员必须能够扫描信息中心上的所有图表,以快速查找在触发提醒时变化显著的图表。
您的信息中心上提供了以下示例图表列表,以帮助排查问题。突发事件响应者应该能够在单个视图中对它们一目了然:
- 服务等级指标,例如成功请求数除以有效请求总数
- 配置和二进制文件发布
- 每秒向系统发出的请求数
- 每秒从系统返回的错误响应数
- 每秒从系统到其依赖项的请求数
- 每秒从系统依赖项到系统的错误响应次数
其他有助于排查问题的图表包括延迟时间、饱和度、请求大小、响应大小、查询费用、线程池利用率和 Java 虚拟机 (JVM) 指标(如果适用)。饱和度是指一些限制(例如配额或系统内存大小)导致变满。线程池利用率会查找由于池耗尽而导致的回归。
针对少数中断场景测试这些图表的位置,确保最重要的图表靠近顶部,并且图表的顺序与标准诊断工作流相匹配。您还可以使用机器学习和统计异常值检测功能来显示这些图表的子集。
针对已知的中断情况记录诊断过程和缓解措施
编写策略方案并从提醒通知链接到它们。如果这些文档可以从提醒通知中访问,那么运营商可以快速获得排查和缓解问题所需的信息。
利用无责备事后分析来了解服务中断情况并防止再次发生
构建无责备的事后分析文化和突发事件审核流程。无责备表示您的团队会客观地评估和记录问题,而不会加以责备。
错误是学习的机会,而不是批评的原因。始终以提高系统弹性为目标,使其能够从人为错误中快速恢复,甚至更好地检测和防止人为错误。从每个事后分析提取尽可能多的学习信息,并严格关注每个事后分析待办项,以降低中断频率,从而增加 TBF。
突发事件管理方案示例
已检测到生产问题(例如通过提醒或页面)或上报给我。
- 我应该委托给其他人吗?
- 是的。如果您和您的团队无法解决问题。
- 此问题是否侵犯隐私权或违反安全规定?
- 如果是,请委托给隐私权或安全团队。
- 此问题是紧急事件还是存在风险的 SLO?
- 如果不确定,请将其视为紧急事件。
- 我是否应该让更多人参与?
- 是的,如果受影响的客户超过 X%,或者解决时间超过 Y 分钟。如果不确定,请务必让更多人参与,尤其是在工作时间。
- 定义主要沟通渠道,例如 IRC、Hangouts Chat 或 Slack。
- 委托以前定义的角色,例如:
- 突发事件指挥官:负责整体协调工作。
- 沟通主管,负责处理内部和外部沟通。
- 运营主管:负责缓解问题。
- 定义突发事件的结束时间。此决策可能需要支持代表或其他类似团队确认。
- 协作完成无责备的事后分析。
- 参加突发事件事后分析审核会议,讨论相关事宜并采取行动。
建议
如需将架构框架中的指导运用到您自己的环境,请遵循以下建议:
- 制定突发事件管理方案,并培训您的团队使用该方案。
- 如需缩短 TTD,请实施建议以将可观测性内置到您的基础架构和应用中。
- 构建一个“变化内容”信息中心,以便在发生突发事件时轻松查看变化。
- 记录查询代码段,或构建包含频繁日志查询的 Looker 数据洞察信息中心。
- 评估 Firebase 远程配置以缓解移动应用的发布问题。
- 测试失败恢复(包括从备份恢复数据),以降低部分突发事件的 TTM。
- 设计并测试配置和二进制文件回滚。
- 跨区域复制数据以进行灾难恢复,并使用灾难恢复测试,以在发生区域服务中断后缩短 TTM。
- 如果企业需要高可用性来证明费用合理,则可以设计多区域架构以应对区域服务中断,从而增加 TBF。
后续步骤
详细了解如何利用以下资源构建协作式事件管理流程:
探索架构框架中的其他类别,例如系统设计、卓越运营以及安全性、隐私权和合规性。
Google Cloud 架构框架:产品可靠性指南
架构框架中的这一部分提供特定于产品的最佳实践指导,用于确保某些 Google Cloud 产品的可靠性、可用性和一致性。这些指南还提供了相关建议,以最大限度减少故障和从故障中恢复,以及在负载下实现良好的应用扩缩。
产品可靠性指南按以下领域分类:
- 计算
- 存储和数据库
- 网络
- 数据分析
Compute Engine 可靠性指南
Compute Engine 是一种可自定义的计算服务,可让用户在 Google 的基础架构上按需创建并运行虚拟机。
最佳实践
- Compute Engine API 最佳实践 - 使用 Compute Engine API 和缓解 API 速率限制影响的推荐最佳实践。
- 设计弹性系统 - 详细指引如何设计 Compute Engine 应用以从单虚拟机故障或重启以及可用区或区域服务故障中恢复。
- 如何通过超额预配来提高可用性 - 添加冗余资源,以确保您的应用在因可用区或区域服务中断而造成容量损失时保持正常运行。
- 为高可用性应用使用负载均衡功能 - 如何将 Cloud Load Balancing 与 Compute Engine 搭配使用来提供高可用性,即使在发生可用区服务中断期间也是如此。
- 选择 Compute Engine 区域时的最佳实践 - 如何选择将哪些 Google Cloud 区域用于您的 Compute Engine 资源,以优化您的应用的延迟,同时兼顾价格/性能。
- 使用 Migrate to Virtual Machines 迁移虚拟机的最佳实践 - 如何使用 Migrate to Virtual Machines 将虚拟机从支持的来源环境迁移到 Compute Engine,包括评估、规划和执行迁移。以及,如何解决迁移时可能出现的常见问题。
- 在 Compute Engine 中使用浮动 IP 地址的模式 - 如何将架构更改为适用于您的使用场景的模式,从而在 Compute Engine 环境中实现共享或虚拟 IP 地址。模式包括使用负载均衡、Google Cloud 路由和自动修复的模式。
- 永久性磁盘快照的最佳实践 - 更快速、更可靠地创建快照。
- 永久性磁盘和复制 - 永久性磁盘如何使用 Colossus 作为存储后端,以及如何从虚拟机访问永久性磁盘。此外,还要监控永久性磁盘延迟时间、在区域或地区之间复制永久性磁盘,以及如何处理副本的读写请求。
- 配置磁盘以满足性能要求 - 影响挂接到虚拟机实例的块存储卷性能的因素。
- 映像管理最佳实践 - 有关如何管理 Compute Engine 映像(例如选择启动映像、自定义映像和映像生命周期以及在项目之间共享映像)的详细指导。
- 映像系列最佳实践 - 在将映像系列用于生产环境之前测试映像系列中的最新映像的重要性,以及如何设置测试流程。
- SQL Server 实例的最佳实践 - 优化运行 Microsoft SQL Server 的 Compute Engine 实例以及优化 SQL Server Enterprise Edition 的最佳实践。以及,如何使用操作系统的默认网络设置和操作活动来提高性能和稳定性。
Cloud Run 可靠性指南
Cloud Run 是一个采用无服务器技术的代管式计算平台,适合用于部署容器化应用。Cloud Run 可让用户不必再操心任何基础架构管理,而是专注于构建应用。
最佳实践
- Cloud Run 常规提示 - 如何实现 Cloud Run 服务、快速启动容器、使用全局变量以及提高容器安全性。
- 负载测试最佳实践 - 如何加载测试的 Cloud Run 服务,包括在执行负载测试之前解决并发问题、管理实例数上限、选择负载测试的最佳区域,以及确保服务随负载变化而伸缩。
- 实例扩缩 - 如何通过使某些实例保持空闲(而不是停止实例)来扩缩和限制容器实例并最大限度地缩短响应时间。
- 使用最少的实例 - 指定可进行响应的容器实例数下限,在此数字设置得较高时,通过减少冷启动次数来最大限度地缩短平均响应时间。
- 优化 Cloud Run 的 Java 应用 - 了解对 Java 编写的 Cloud Run 服务进行优化时的权衡取舍,并减少启动时间和内存用量。
- 优化 Cloud Run 的 Python 应用 - 通过提高 WSGI 服务器的效率来优化容器映像,并通过减少线程数量和并行执行启动任务来优化应用。
Cloud Functions 可靠性指南
Cloud Functions 是一个可扩缩的事件驱动型无服务器平台,可帮助您构建和连接服务。Cloud Functions 函数可以通过 HTTP 请求调用,也可以根据后台事件触发。
最佳实践
- Cloud Functions 最佳实践 - 有关如何使用 Cloud Functions 并与之交互、实现幂等性、部署函数和优化性能的准则。
Google Kubernetes Engine 可靠性指南
Google Kubernetes Engine (GKE) 是用于在云中大规模运行容器化应用的系统。GKE 可为容器化应用部署、管理和预配资源。GKE 环境由许多 Compute Engine 实例构成,这些实例组合在一起形成集群。
最佳实践
- 操作容器的最佳实践 - 如何使用日志记录机制、确保容器无状态且不可变、监控应用以及进行活跃性和就绪性探测。
- 构建容器的最佳实践 - 如何将单个应用封装到一个容器中、处理进程标识符 (PID)、针对 Docker 构建缓存进行优化以及构建较小的映像以提高上传和下载速度。
- Google Kubernetes Engine 网络的最佳实践 - 使用 VPC 原生集群以更轻松地扩缩、规划 IP 地址、扩缩集群连接、使用 Google Cloud Armor 阻止分布式拒绝服务 (DDoS) 攻击、实现容器原生负载均衡以缩短延迟时间、使用外部应用负载均衡器的健康状况检查功能以进行正常故障切换,并使用区域级集群提高集群中应用的可用性。
- 准备云端 Kubernetes 应用 - 了解规划应用容量的最佳实践、横向或纵向扩大应用、根据内存和 CPU 的资源请求设置资源限制、使容器精简以加快应用启动速度,并通过设置
Pod Disruption Budget
(PDB) 来限制Pod
中断。此外,了解如何设置活跃性探测和就绪性探测以正常启动应用,确保无中断的关停,并为重试请求实现指数退避算法以防止流量激增而导致应用超负荷。 - GKE 多租户最佳实践 - 如何设计多租户集群架构以实现高可用性和可靠性,使用 Google Kubernetes Engine (GKE) 用量计量来满足每个租户的用量指标,并提供特定于租户的监控信息。
Cloud Storage 可靠性指南
Cloud Storage 是一个具备耐用性和高可用性的对象存储库,提供高级安全性与共享功能。此服务用于在 Google Cloud 基础架构上存储和访问数据。
最佳实践
- Cloud Storage 最佳做法 - Cloud Storage 的一般最佳做法,包括有关如何最大限度地提高应用可用性以及尽可能缩短延迟时间、提高上传操作的可靠性以及提高大规模数据删除性能的提示。
- 请求速率和访问分配准则 - 如何通过了解 Cloud Storage 自动扩缩的工作原理,在极高的请求速率下最大限度地减少针对读取、写入和删除操作的延迟时间和错误响应。
Firestore 可靠性指南
Firestore 是一款 NoSQL 文档数据库,可让您在全球范围内存储、同步和查询您的移动应用和 Web 应用的数据。
最佳实践
- Firestore 最佳实践 - 如何选择数据库位置以提高可靠性、减少索引中的性能问题、改善读写操作的性能、缩短更改通知的延迟时间以及设计扩缩能力。
Bigtable 可靠性指南
Bigtable 是一项全代管式可扩缩的 NoSQL 数据库,用于处理大规模分析和运营工作负载。它设计为稀疏填充的表,可以扩容到数十亿行和数千列,并支持以短延时方式实现高读写吞吐量。
最佳实践
- 了解 Bigtable 的性能 - 估算 Bigtable 的吞吐量,如何通过查看吞吐量和存储空间用量来规划 Bigtable 容量,启用复制功能对读取和写入吞吐量产生的不同影响,以及 Bigtable 如何不断优化数据。
- Bigtable 架构设计 - 设计 Bigtable 架构的指导,包括键值对存储区的概念,根据计划的读取请求设计行键,处理列和行以及特殊用例。
- Bigtable 复制概览 - 如何跨多个可用区或区域复制 Bigtable,了解复制对性能的影响,以及 Bigtable 如何解决冲突和处理故障切换。
- Bigtable 备份简介 - 如何使用 Bigtable 备份保存表的架构和数据的副本,以帮助您从应用级数据损坏或运维人员错误(例如意外删除表)中恢复。
Cloud SQL 可靠性指南
Cloud SQL 是一项适用于 MySQL、PostgreSQL 和 SQL Server 的全代管式关系型数据库服务。Cloud SQL 可轻松与现有应用和 Google Cloud 服务(如 Google Kubernetes Engine 和 BigQuery)进行集成。
最佳实践
Cloud SQL 高可用性 - Cloud SQL 的高可用性配置(包括处理读取副本和故障切换过程)概览。此外,它还介绍了如何控制数据库维护事件的时间,以及在 HA 配置中使用区域永久性磁盘对数据库性能有何影响。此内容分为三个部分:
Cloud SQL 数据库灾难恢复 - 使用跨区域读取副本的 Cloud SQL 灾难恢复配置概览。
Cloud SQL 的通用性最佳实践 - 有关如何配置实例、数据架构、导入和导出数据以及备份和恢复的指南。此内容分为三个部分:
数据导入和导出最佳实践 - 如何在无法使用 Cloud Storage 存储桶的情况下,压缩数据来缩减费用;了解数据导入和导出的已知限制;如何自动执行导出操作;了解导入和导出操作相关的问题排查。
Spanner 可靠性指南
Spanner 是一种分布式 SQL 数据库管理和存储服务,具有全局事务和高可用性的横向扩缩和事务一致性等功能。
最佳实践
- Spanner 备份和恢复 - Spanner 备份和恢复的主要功能,备份和恢复与导入和导出的比较,实现细节以及如何控制对 Spanner 资源的访问权限。
- 区域级配置和多区域配置 - 介绍 Spanner 提供的两种类型的实例配置:区域级配置和多区域配置。该说明包括每个配置之间的差异和权衡。
- 自动扩缩 Spanner - 介绍 Spanner 的自动扩缩器工具(自动扩缩器)。它是一种开源工具,可用作 Cloud Spanner 的配套工具。借助此工具,您可以根据每个 Spanner 实例的利用率指标自动增加或减少一个或多个 Spanner 实例中的节点或处理单元数量。
- 时间点恢复 (PITR) 简介 - 介绍 Spanner 时间点恢复 (PITR),这是一项防止意外删除或写入 Spanner 数据的功能。例如,运维人员意外写入数据或应用发布损坏了数据库。借助 PITR,您可以无缝地从过去某个时间点(最多七天)恢复数据。
- Spanner 最佳实践 - 关于批量加载、使用数据操纵语言 (DML)、设计架构以避免热点和 SQL 最佳实践的指南。
Filestore 可靠性指南
Filestore 是面向 Google Cloud 应用的代管式文件存储服务,具有文件系统接口和共享文件系统,用于存储数据。Filestore 提供适用于 Compute Engine 和 Google Kubernetes Engine 实例的 PB 级在线网络附加存储 (NAS) 服务。
最佳做法
Filestore 性能 - 性能设置和 Compute Engine 机器类型建议、NFS 装载选项以获得最佳 Linux 客户端虚拟机实例性能,以及使用
fio
工具测试性能。包括针对跨多个 Google Cloud 资源提高性能的建议。Filestore 备份 - Filestore 备份说明、常见使用场景以及创建和使用备份的最佳实践。
Filestore 快照 - Filestore 快照说明、常见使用场景以及创建和使用快照的最佳实践。
Filestore 网络 - 使用 Filestore 所需满足的网络和 IP 资源要求。
Memorystore 可靠性指南
Memorystore 是一种全代管式内存中存储,该存储提供托管版本的两个开源缓存解决方案:Redis 和 Memcached。Memorystore 具有可伸缩性,并且可以自动执行复杂的任务,例如预配、复制、故障转移和修补。
最佳实践
- Redis 的一般最佳做法 - 有关如何导出 Redis 数据库 (RDB) 备份、资源密集型操作和需要连接重试的操作的指南。此外还包含有关维护、内存管理和设置无服务器 VPC 访问通道连接器、专用服务访问通道连接模式以及监控和提醒的信息。
- Redis 内存管理最佳做法 - 内存管理概念,例如实例容量和
Maxmemory
配置、导出、扩缩和版本升级操作、内存管理指标以及如何解决内存不足的问题条件。 - Redis 指数退避算法 - 指数退避算法的工作原理、示例算法以及最大退避算法和最大重试次数的工作原理。
- Memcached 最佳做法 - 如何设计应用以处理缓存未命中、直接连接到节点的 IP 地址以及 Memcached Auto Discovery 服务。此外还包括,有关如何配置
max-item-size
参数、平衡集群以及使用 Cloud Monitoring 监控基本指标的指南。 - Memcached 内存管理最佳实践 - 为 Memcached 实例配置内存、预留内存配置、何时增加预留内存以及内存用量指标。
Cloud DNS 可靠性指南
Cloud DNS 是一种低延迟域名系统,可帮助您注册、管理和提供网域。Cloud DNS 可以扩容以支持大量 DNS 区域和记录,您可以通过界面创建和更新数百万条 DNS 记录。
最佳实践
- Cloud DNS 最佳实践 - 了解如何管理专用区域、配置 DNS 转发以及创建 DNS 服务器政策。包含有关在混合环境中使用 Cloud DNS 的指导。
Cloud Load Balancing 可靠性指南
Cloud Load Balancing 是适用于所有流量的完全分布式、软件定义的托管服务。此外,Cloud Load Balancing 还提供无缝自动扩缩、第 4 层和第 7 层负载均衡,并支持 IPv6 全球负载均衡等功能。
最佳做法
- 性能最佳实践 - 如何在应用实例之间分配负载以提供较佳性能。策略包括在最靠近流量的区域中的后端放置、缓存、转发规则协议选择和配置会话亲和性。
- 为高可用性应用使用负载均衡功能 - 如何将 Cloud Load Balancing 与 Compute Engine 搭配使用来提供高可用性,即使在发生可用区服务中断期间也是如此。
Cloud CDN 可靠性指南
Cloud CDN(内容分发网络)是一种服务,可通过使用 Google 的边缘网络使内容尽可能靠近用户,加快互联网内容的分发速度。Cloud CDN 有助于减少延迟时间、费用和负载,从而让您更轻松地为用户扩缩服务。
最佳做法
- 内容分发最佳实践 - 如何使用缓存键优化缓存命中率、确保启用 HTTP/3 以获得最佳性能,以及使用 Cloud CDN 自定义监控信息中心查看监控指标。此外,如何查看来自第三方性能测试的可用性、延迟时间和吞吐量的报告。
BigQuery 可靠性指南
BigQuery 是 Google Cloud 的数据仓库平台,可用于大规模存储和分析数据。
最佳实践
- 可靠性简介 - 可靠性最佳实践以及可用性、耐用性和数据一致性等概念的简介。
- 可用性和耐用性 - Google Cloud 数据中心中可能发生的故障网类型,BigQuery 如何根据数据存储位置提供存储冗余,以及跨区域数据集增强灾难恢复的原因。
- BigQuery 上多租户工作负载的最佳实践 - 多租户数据平台中使用的常见模式。这些模式包括确保软件即服务 (SaaS) 供应商的客户的可靠性和隔离性,针对容量规划的重要 BigQuery 配额和限制,以及使用 BigQuery Data Transfer Service 将相关数据集复制到其他区域等等。
- 使用具体化视图 - 如何使用 BigQuery 具体化视图以更低的费用更快地执行查询,包括查询具体化视图、调整分区和了解智能调整(自动重写查询)。
Dataflow 可靠性指南
Dataflow 是一种全代管式数据处理服务,它使用开源 Apache Beam 库实现快速、简化的流式数据流水线开发。Dataflow 通过自动扩缩和批处理来最大限度地减少延迟、缩短处理时间并降低费用。
最佳实践
使用 Dataflow 构建支持生产环境的数据流水线 - 一个关于使用 Dataflow 的文档系列,包括规划、开发、部署和监控 Dataflow 流水线。
- 概览 - Dataflow 流水线简介。
- 规划 - 衡量 SLO,了解数据源和接收器对流水线可扩缩性和性能的影响,并在指定运行 Dataflow 作业的区域时考虑高可用性、灾难恢复和网络性能。
- 开发和测试 - 设置部署环境,通过使用死信队列进行错误处理来防止数据丢失,并通过最大限度地减少昂贵的每元素操作来缩短延迟时间和降低费用。此外,通过使用批处理来降低性能开销,而不会使外部服务过载,取消不适当融合的步骤,以便将步骤分开以获得更好的性能,并在投入生产前运行端到端测试,以确保流水线继续满足 SLO 和其他生产要求。
- 部署 - 持续集成 (CI) 以及持续交付和部署 (CD),含有关于部署新版本流处理流水线的特殊注意事项。此外,还介绍了 CI/CD 流水线示例和一些用于优化资源使用情况的功能。最后,讨论高可用性、地理冗余以及流水线可靠性的最佳做法,包括区域级隔离、使用快照、处理作业提交错误以及从会影响正在运行的流水线的错误和服务中断恢复。
- 监控 - 观察服务等级指标 (SLI),这是流水线性能的重要指标,用于定义和衡量服务等级目标 (SLO)。
Dataproc 可靠性指南
Dataproc 是一项可扩缩的全代管式服务,用于运行 Apache Hadoop 和 Spark 作业。您可以 Dataproc 根据需要自定义和扩缩虚拟机。Dataproc 与 Cloud Storage、BigQuery、Bigtable 和其他 Google Cloud 服务紧密集成。
最佳实践
- Dataproc 高可用性模式 - 在实例名称、Apache ZooKeeper、Hadoop Distributed File System (HDFS) 和 Yet Another Resource Negotiator (YARN) 等各项上比较 Hadoop 高可用性 (HA) 模式和默认的非 HA 模式。以及,如何创建高可用性集群。
- 自动扩缩集群 - 何时使用 Dataproc 自动扩缩、如何创建自动扩缩政策、多集群政策用法、自动扩缩配置的可靠性最佳实践以及指标和日志。
- Dataproc 增强的灵活性模式 (EFM) - 使用增强的灵活性模式最大限度地减少作业进度延迟的示例、分区和并行等高级配置以及 EFM 集群上的 YARN 安全停用。
- 安全停用 - 使用安全停用功能以最大限度地减少从集群中移除工作器的影响,如何将此功能与辅助工作器搭配使用,以及安全停用的命令示例。
- 可重启的作业 - 使用可选设置,您可以将作业设置为在失败时重启,以缓解常见的作业失败类型(包括内存不足问题和 Compute Engine 虚拟机意外重新启动)。
Google Cloud 架构框架:费用优化
Google Cloud 架构框架中的这一类别提供了设计建议并介绍了最佳实践,以帮助架构师、开发者、管理员和其他云从业人员优化 Google Cloud 中的工作负载的费用。
将 IT 工作负载迁移到云端可帮助您进行大规模创新、更快地交付功能以及应对不断变化的客户需求。如需迁移现有工作负载或部署专为云打造的应用,您需要一个针对安全性、弹性、卓越运营、费用和性能进行了优化的拓扑。
在架构框架的费用优化类别中,您将了解如何执行以下操作:
- 采用和实施 FinOps:帮助您鼓励员工考虑在 Google Cloud 中预配和管理资源时的费用影响的策略。
- 监控和控制费用:用于跟踪和控制 Google Cloud 中的资源费用的最佳实践、工具和技术
- 优化费用:计算、容器和无服务器:Compute Engine、Google Kubernetes Engine、Cloud Run、Cloud Functions 和 App Engine 的服务专属费用优化控制机制。
- 优化费用:存储:Cloud Storage、Persistent Disk 和 Filestore 的费用优化控制机制。
- 优化费用:数据库和智能分析:BigQuery、Bigtable、Spanner、Cloud SQL、Dataflow 和 Dataproc 的费用优化控制机制。
- 优化费用:网络:Google Cloud 中的网络资源的费用优化控制机制。
- 优化费用:Cloud Operations:帮助您优化在 Google Cloud 中监控和管理资源的费用的建议。
采用和实现 FinOps
Google Cloud 架构框架中的本文档概述了策略,以帮助您在 Google Cloud 中预配和管理资源时考虑您的操作和决策的费用影响。其中介绍了 FinOps 做法,它将人员、流程和技术组合在一起,以在组织中推广财务问责制和费用优化原则,而不考虑组织在云中的规模或成熟程度。
本部分中的指导适用于负责控制其组织在云中的支出的 CTO、CIO 和高管。该指导还可以帮助各个 Cloud Operations 了解并采用 FinOps。
无论角色是分析师、架构师、开发者还是管理员,组织中的每个员工都有助于降低 Google Cloud 中的资源费用。在不必跟踪过去基础架构费用的团队中,您可能需要向员工讲授集体责任制的必要性。
常见模型旨在让中心 FinOps 团队或云技术卓越中心 (CCoE) 实现跨所有云工作负载优化费用流程的标准化。此模型假设中心团队具有必要的知识和专业知识,能够发现提高效率的高价值机会。
虽然集中式费用控制在云采用的初始阶段(此时用量较低)可能运行良好,但随着云采用和用量的增加,效率会下降。中心团队可能会遭遇扩缩问题,而项目团队可能无法接受其团队以外的人员做出的决策。
我们建议中心团队将优化资源的决策制定权委托给项目团队。中心团队可以推动更广泛的工作,从而鼓励在整个组织中采用 FinOps。要使各个项目团队都能够练习 FinOps,中心团队必须实现费用优化流程、报告和工具的标准化。中心团队必须与不熟悉 FinOps 实践的团队密切合作,并帮助他们在制定决策的过程中考虑费用。中心团队还必须充当财务团队与各个项目团队之间的中介。
后续各部分介绍了我们建议中心团队推广的设计原则。
鼓励个人问责制
创建和使用云资源的任何员工都会影响到这些资源的用量和费用。为了让组织成功实现 FinOps,中心团队必须帮助员工转变思想,从费用由其他人承担责任转变为自己的费用自己负责。通过此次转变,员工可以拥有并制定适合其工作负载、团队和组织的费用决策。此所有权可扩展到实现数据驱动的费用优化操作。
为鼓励费用问责制,中心团队可以执行以下操作:
- 向用户讲授费用优化机会和方法。
- 对优化费用的员工进行奖励和表彰。
- 在整个组织中公开费用。
公开费用
如果员工在云中预配和管理资源时要考虑费用,他们需要全方位了解相关数据(尽可能接近实时数据)。随着相关影响的出现,报告和信息中心中的数据必须显示团队成员决策的相关费用和业务影响。其他团队的用量和费用数据可充当识别高效部署模式的基准。这些数据有助于对云服务的最佳使用方式形成共识。
如果组织不鼓励和推广共享费用数据,则员工可能不愿意共享数据。有时,出于业务原因,组织可能不允许共享原始费用数据。即使是在这种情况下,我们都建议您避免使用限制访问费用信息的默认政策。
如需在组织中公开费用,中心团队可以执行以下操作:
- 使用一种明确定义的方法来计算云资源的完全加载费用。例如,该方法会考虑根据购买折扣和共享费用(如共享数据库的费用)进行调整的总计云支出。
- 设置信息中心可让员工近乎实时地查看他们的云支出。
- 为激励团队中的个人拥有自己的费用,请允许跨团队广泛公开云支出。
实现协作行为
高效管理云资源的费用要求团队协作以改进其技术和运营流程。协作文化可帮助团队根据一组一致的业务目标和因素来设计经济实惠的部署模式。
为实现协作行为,中心团队可以执行以下操作:
- 创建工作负载初始配置流程,通过其他工程师对建议的架构进行对等审核,有助于确保在设计阶段提高成本效益。
- 打造经济实惠架构模式的跨团队知识库。
打造不责罚文化
促进建立学习和发展文化,确保安全地承担风险,必要时进行更正,并开展创新。承认错误(有时是代价高昂的错误)可能会在 IT 设计和部署生命周期中的任何阶段发生,就像在业务的任何其他部分发生一样。
不应指责或羞辱对于那些超支或造成浪费的个人,而应推广无责罚文化,帮助确定费用超支和计算错误的原因。在此环境中,团队成员更有可能分享其观点和经验。错误会经过匿名化处理并在整个企业之间共享以防止错误再次发生。
请勿将不责罚文化和缺乏责任感相混淆。员工继续负责自己制定的决策及自己的支出。但是,发生错误后,重点是将它当作学习机会,以防止错误再次发生。
为打造不责罚文化,中心团队可以执行以下操作:
- 针对严重的费用问题运行事后分析但不责罚,将重点放在问题的系统性根本原因,而不是所涉及的人员。
- 对响应费用超支和分享经验教训的团队成员进行表彰。鼓励团队中的其他成员分享错误、执行的操作和经验教训。
专注于业务价值
虽然 FinOps 做法通常侧重于降低费用,但中心团队的重点必须是让项目团队做出的决策能够使云资源发挥最大业务价值。您可以轻松做出决策以将费用降低到满足最低服务等级的程度。但是,此类决策通常会将费用转移到其他资源,从而导致更高的维护费用,并有可能增加总拥有成本。例如,为降低费用,您可能决定使用虚拟机 (VM) 而不是代管式服务。但是,与代管式服务相比,维护基于虚拟机的解决方案需要付出更多的精力,因此代管式服务提供的业务净值更高。
FinOps 做法可以为项目团队提供分析和数据洞见,供团队用来做出架构和运营决策,从而使其云资源发挥最大的业务价值。
为了帮助员工专注于业务价值,中心团队可以执行以下操作:
将云资源用量与业务价值指标(如成本效益、弹性、功能速度和创新)相关联,从而做出费用优化决策。如需详细了解业务价值指标,请参阅 Cloud FinOps 白皮书。
为云中运行的所有应用和服务中实施单位价格。
后续步骤
- 详细了解 FinOps:
- 监控和控制费用
- 优化 Google Cloud 服务的费用:
- 探索 Google Cloud 架构框架的其他类别
监控和控制费用
Google Cloud 架构框架中的本文档介绍了最佳实践、工具和技术,可帮助您跟踪和控制 Google Cloud 中的资源费用。
本部分中的指导适用于预配或管理云资源的用户。
费用管理重点领域
Google Cloud 中的资源费用取决于您使用的资源数量以及结算资源所采用的费率。
如需管理云资源的费用,我们建议您重点关注以下几个方面:
- 费用可见性
- 资源优化
- 费率优化
费用可见性
跟踪您的支出金额以及资源和服务的费用结算方式,以便分析费用对业务成果的影响。我们建议您遵循 FinOps 操作模型,该模型建议您执行以下操作以在整个组织中公开费用信息:
- 分配:为每个费用项分配一个所有者。
- 报告:将费用数据设置为可用、可使用、可操作。
- 预测:估算和跟踪未来的支出。
资源优化
根据工作负载的要求调整云资源的数量和大小。在可能的情况下,请考虑使用代管式服务或重新设计应用架构。通常,各个工程团队比中央团队在优化资源部署的机会和技术方面拥有的背景信息多于中央 FinOps(财务运营)团队。我们建议 FinOps 团队与各个工程团队合作,以发现可应用于整个组织的资源优化机会。
费率优化
FinOps 团队经常集中制定费率优化决策。我们建议各个工程团队与中央 FinOps 团队合作,以充分利用预订的大幅度折扣、承诺使用折扣、Spot 虚拟机、固定费率价格、数量和合同折扣。
设计建议
本部分推荐可用于监控和控制费用的各种方法。
合并结算与资源管理
为了高效地管理 Google Cloud 中的结算和资源,我们建议您为组织使用单个结算账号,并使用内部退款机制分配费用。针对结构松散并且各实体不会相互影响的综合性大企业和组织,使用多个结算账号。例如,转销商可能需要为每个客户使用不同的账号。使用单独的结算账号还可以帮助您遵守特定于国家/地区的税务法规。
另一个建议的最佳实践是将您管理的所有项目都迁移到您的组织中。我们建议您使用 Resource Manager 来构建有助于实现以下目标的资源层次结构:
- 根据每个资源与其直接父级的关系建立资源所有权的层次结构。
- 控制如何将访问权限政策和费用分配标记或标签附加到组织中的资源以及资源如何继承这些政策和标记或标签。
此外,我们还建议您根据使用量按比例分配共享服务的费用。根据业务目标和优先级的变化,定期查看并调整费用分配参数。
使用标记或标签跟踪和分配费用
标记和标签是可用于为 Google Cloud 资源添加注解的两种不同方法。标记比标签提供更多功能。例如,如需实现对资源的精细控制,您可以创建根据支持的资源是否附加了标记而有条件实施的 Identity and Access Management (IAM) 政策。此外,层次结构中的所有子资源都会继承与资源关联的标记。如需详细了解标记和标签之间的区别,请参阅标记概览。
如果要构建新的费用分配和跟踪框架,我们建议您使用标记。
如需按照所需的粒度对费用数据进行分类,请建立一个适合您组织的退款机制并且可帮助您适当分配费用的标记或标签架构。您可以在组织或项目级层定义标记。您可以在项目级层分配标签,并定义一组默认情况下可应用于所有项目的标签。
定义一个流程来检测和纠正标记和标签异常,以及未加标签的项目。例如,从 Cloud Asset Inventory 中,您可以下载项目中所有资源的清单(.csv
文件),并分析清单以确定未分配任何标记或标签的资源。
如需跟踪共享资源和服务(例如,公用数据存储区、多租户集群和支持订阅)的费用,请考虑使用特殊标记或标签来标识包含共享资源的项目。
配置结算账号权限控制
如需控制对 Cloud Billing 的访问权限,我们建议您仅向管理结算联系人信息的用户分配 Billing Account Administrator 角色。例如,财务、会计和运营部门的员工可能需要此角色。
为避免结算支持出现单点故障,请将 Billing Account Administrator 角色分配给多个用户或某个群组。只有拥有 Billing Account Administrator 角色的用户才能联系支持团队。如需查看详细指导,请参阅 Cloud Billing 访问权限控制示例和重要角色。
进行以下配置以管理对结算的访问权限:
- 如需将结算账号与项目相关联,成员需要拥有结算账号的 Billing Account User 角色以及项目的 Project Billing Manager 角色。
- 为了让团队能够手动将结算账号与项目相关联,您可以分配组织级层的 Project Billing Manager 角色和结算账号的 Billing Account User 角色。您可以通过将 Project Billing Manager 和 Billing Account User 角色分配给服务账号,在项目创建期间自动关联结算账号。我们建议您限制 Billing Account Creator 角色或移除此角色的所有分配。
- 为了防止因意外更改项目的结算状态而导致服务中断,您可以锁定项目与其结算账号之间的关联性。如需了解详情,请参阅保护项目与其结算账号之间的关联性。
配置结算报告
设置结算报告,为您需要跟踪的关键指标提供数据。我们建议您跟踪以下指标:
- 费用趋势
- 消费最高的用户(按项目和产品)
- 支出不规则的区域
- 整个公司的关键数据洞见,如下所示:
- 异常检测
- 特定时间段内的趋势
- 在一组模式下(例如按月)发生的趋势
- 内部和外部工作负载之间的费用比较和基准分析
- 业务案例跟踪和价值实现(例如,云费用与类似本地资源的费用的对比)
- 验证 Google Cloud 账单是否与预期一致且准确无误
分析趋势并预测费用
使用 BigQuery 账单导出功能自定义并分析费用报告,并使用 Looker 数据洞察直观呈现费用数据。使用预测工具评估实际费用的趋势以及您可能需要支出的费用。
优化资源用量和费用
本部分推荐了最佳实践,可帮助您优化资源在 Google Cloud 服务中的用量和费用。
为防止超支,请考虑为所有项目配置具有高阈值的默认预算和提醒。为了将预算保持在特定范围内,我们建议您执行以下操作:
为需要绝对使用限制的项目(例如培训项目或沙盒项目)配置预算和提醒。
根据您需要跟踪的财务预算定义预算。例如,如果部门具有总体云预算,请设置 Google Cloud 预算范围,以包含您需要跟踪的特定项目。
为确保预算得以维持,请将配置预算和提醒的责任委派给拥有工作负载的团队。
为了优化费用,我们还建议您执行以下操作:
- 限制 API 用量(如果它对业务的影响最小或没有影响)。设置上限功能非常适合沙盒项目或训练项目以及具有固定预算的项目(例如 BigQuery 中的临时分析)。设置上限功能并不会移除关联项目中的所有资源和数据。
- 使用配额设置硬性限制以限制资源部署。配额可帮助您控制费用并防止恶意使用或滥用资源。配额按项目级层资源类型和位置应用。
- 在 Recommendation Hub 中查看并实施费用优化建议。
- 购买承诺使用折扣 (CUD),以节省处理具有可预测资源需求的工作负载的资源费用。
工具和方法
云中的按需预配和按用量付费特性可帮助您优化 IT 支出。本部分介绍 Google Cloud 提供的工具,以及可用于跟踪和控制云资源费用的方法。在使用这些工具和方法之前,请先查看 Cloud Billing 基本概念。
结算报告
Google Cloud 在 Google Cloud 控制台中提供结算报告,以帮助您查看当前和预测的支出。通过结算报告,您可以查看单个页面上的费用数据、发现和分析趋势、预测期末费用,并在必要时采取更正措施。
结算报告提供以下数据:
- 给定时段的费用和费用趋势,按以下方式进行整理:
- 按结算账号
- 按项目
- 按产品(例如 Compute Engine)
- 按 SKU(例如静态 IP 地址)
- 在不使用折扣或赠送金额后可能产生的费用
- 预测支出
将数据导出至 BigQuery
您可以将结算报告导出至 BigQuery,并使用精细的历史数据视图(包括通过标签或标记分类的数据)来分析费用。您可以使用 BigQuery 机器学习执行更高级的分析。我们建议您在创建 Cloud Billing 账号时启用将结算报告导出至 BigQuery 的功能。您的 BigQuery 数据集包含自设置 Cloud Billing 导出之日起产生的结算数据。该数据集不包含在启用导出之前的时间段内产生的数据。
如需直观呈现费用数据,您可以创建与 BigQuery 集成的自定义信息中心(示例模板:Looker、Looker 数据洞察)。
您可以使用标记和标签作为过滤导出的结算数据的条件。结算数据导出中包含的标签数量有限。在一小时内,系统最多保留 1000 个标签映射。标签不会显示在账单 PDF 或 CSV 中。请考虑使用指示业务部门、内部退款部门和其他相关元数据的标记或标签来为资源添加注解。
结算账号权限控制
您可以通过为资源定义 Identity and Access Management (IAM) 政策,来控制对 Cloud Billing 的访问权限。要授予或限制对 Cloud Billing 的访问权限,您可以在组织级层、结算账号级层或项目级层设置 IAM 政策。
结算和资源管理的访问权限控制遵循职责分离原则。每个用户仅拥有其业务角色所需的权限。Organization Administrator 和 Billing Administrator 角色拥有的权限并不相同。
您可以在结算账号级层或组织级层设置与结算相关的权限。常见角色为 Billing Account Administrator、Billing Account User 和 Billing Account Viewer。
我们建议您使用账单结算或配置备用付款方式。维护适用于结算和付款的联系人和通知设置。
预算、提醒和配额
预算可帮助您根据计划支出跟踪实际的 Google Cloud 费用。创建预算时,您可以配置提醒规则,以便在实际或预测的支出超过定义的阈值时触发电子邮件通知。您还可以使用预算来自动执行费用控制响应。
预算可以触发提醒,让您了解资源用量和费用的趋势,并提示您采取费用优化操作。但是,当实际费用达到或超出预算或阈值时,预算不会阻止您使用或结算服务。如需自动控制费用,您可以使用预算通知以编程方式停用项目的 Cloud Billing。您还可以限制 API 用量,以便在定义的用量阈值后停止产生费用。
您可以为结算账号和项目配置提醒。请为账号至少配置一个预算。
为防止在预配资源时超出预定级层或者为限制特定操作的数量,您可以在资源级层或 API 级层设置配额。以下示例说明了如何使用配额:
- 控制每秒的 API 调用次数。
- 限制创建的虚拟机数量。
- 限制 BigQuery 中每天查询的数据量。
项目所有者可以使用 Service Usage API 将使用方替换值应用于特定配额限制,以减少可根据配额限制收费的配额量。如需了解详情,请参阅创建使用方配额替换值。
改进工作负载效率
建议使用以下策略来帮助您在 Google Cloud 中以经济实惠的方式运行工作负载:
- 通过提高产品效率来优化资源用量。
- 降低资源的结算费率。
- 控制和限制资源用量和支出。
在选择减少费用的方法和 Google Cloud 功能时,请考虑所需的工作量和预期节省的费用,如下图所示:
下面是上图所示的方法摘要:
- 使用以下方法,进行少量工作可以节省大量费用:
- 承诺使用折扣
- 自动扩缩
- BigQuery 槽
- 使用以下方法,进行适量或大量工作可以节省大量费用:
- Spot 虚拟机
- 重新设计架构以将应用设计为无服务器应用或容器化应用
- 更换平台以使用代管式服务
- 使用以下方法,进行适量工作可以节省适量费用:
- 自定义机器类型
- Cloud Storage 生命周期管理
- 合理调整容量
- 收回空闲资源
以下各部分介绍的方法可帮助您提高工作负载的效率。
重构或重新设计架构
您可以通过重构工作量或重新设计工作量架构来使用 Google Cloud 产品,从而大幅节省费用。例如,迁移到支持缩减至零的无服务器服务(如 Cloud Storage、Cloud Run、BigQuery 和 Cloud Functions)有助于提高效率。如需评估和比较这些产品的费用,您可以使用价格计算器。
合理调整容量
此方法可帮助您确保基础架构的规模与预期用途相匹配。此策略主要与基础架构即服务 (IaaS) 解决方案相关,您可以在其中为底层基础架构付费。例如,您已部署 50 个虚拟机,但虚拟机并未充分利用,因此您认为工作负载可以在更少(或更小)的虚拟机上高效运行。在这种情况下,您可以移除一些虚拟机或调整其容量。Google Cloud 提供了合理调整容量建议,可帮助您通过预配较小的虚拟机,来检测既不影响性能又能节省费用的机会。与将资源部署到生产环境后再合理调整容量相比,在设计阶段进行所需的工作量要少一些。
自动扩缩
如果您使用的产品支持动态自动扩缩,请考虑将工作负载设计为可以利用自动扩缩来优化费用和性能。例如,对于计算密集型工作负载,您可以在 Compute Engine 中使用代管实例组,也可以将应用容器化并将其部署到 Google Kubernetes Engine 集群。
Active Assist 建议
Active Assist 利用数据、智能方法和机器学习技术降低云复杂性并减少管理工作量。Active Assist 可让您轻松优化云拓扑的安全性、性能和费用。它提供了优化费用和用量的智能建议。您可以采用这些建议,实现立竿见影的成本节约和更高的效率。
以下示例演示了 Active Assist 提供的建议:
- Compute Engine 资源调整:根据用量来调整虚拟机实例的容量,以优化费用和性能。识别并删除或备份空闲的虚拟机和永久性磁盘,以便优化基础架构费用。
- 承诺使用折扣 (CUD):Google Cloud 会分析您的历史用量,找到最适合您工作负载的承诺量,以及提供易于理解且切实可行的建议来帮助您节省费用。 如需了解详情,请参阅承诺使用折扣 Recommender。
- 无人使用的项目:发现组织中无人使用的项目,并移除或回收它们。如需了解详情,请参阅无人使用的项目 Recommender。
如需查看完整列表,请参阅 Recommender。
后续步骤
- 了解 Cloud Billing 概念
- 设置预算和预算提醒
- 优化计算服务、存储、数据库、网络和运营的费用:
- 探索 Google Cloud 架构框架的其他类别
优化费用:计算、容器和无服务器
Google Cloud 架构框架中的本文档提供了建议,以帮助您优化 Google Cloud 中的虚拟机 (VM)、容器和无服务器资源的费用。
本部分中的指南适用于负责为云端工作负载预配和管理计算资源的架构师、开发者和管理员。
计算资源是云基础架构最重要的部分。在将工作负载迁移到 Google Cloud 时,通常首选 Compute Engine,它可让您在云端高效地预配和管理虚拟机。Compute Engine 提供了各种各样的机器类型,可在全球所有 Google Cloud 区域使用。借助 Compute Engine 的预定义和自定义机器类型,您可以预配具有与本地基础架构类似计算容量的虚拟机,从而加速迁移过程。Compute Engine 具有价格优势,您只需为所用的基础架构付费,并且由于可以凭借持续使用折扣使用更多的计算资源,因此可以显著节省费用。
除了 Compute Engine 之外,Google Cloud 还提供容器和无服务器计算服务。对于并非始终运行的新服务(例如 API、数据处理和事件处理),无服务器方法可能更加经济实惠。
除了一般性建议,本文档还提供了指南来帮助您在使用以下产品时优化计算资源的费用:
- Compute Engine
- Google Kubernetes Engine (GKE)
- Cloud Run
- Cloud Functions
- App Engine
一般建议
以下建议适用于本部分讨论的所有 Google Cloud 计算、容器和无服务器服务。
跟踪用量和费用
使用以下工具和方法监控资源使用情况和费用:
- 在 Recommendation Hub 中查看和响应费用优化建议。
- 通过配置预算提醒,接收有关潜在资源使用量和费用增加的电子邮件通知。
- 使用 Pub/Sub 和 Cloud Functions 服务以编程方式管理和响应提醒。
控制资源预配
您可以按照以下建议来控制在云端预配的资源数量以及用于创建资源的位置:
- 为帮助确保资源消耗量和费用不超过预测值,请使用资源配额。
- 在费用最低并且能够满足工作负载延迟时间要求的地区预配资源。如需控制资源的预配位置,您可以使用组织政策限制条件
gcp.resourceLocations
。
获取承诺使用折扣
承诺使用折扣 (CUD) 非常适合具有可预测资源需求的工作负载。将工作负载迁移到 Google Cloud 后,找到所需资源的基准,并获取承诺使用折扣。例如,购买一年或三年期承诺,并在 Compute Engine 虚拟机价格上享受大幅折扣。
使用标签自动执行费用跟踪
以一致的方式定义和分配标签。以下示例展示了如何使用标签来自动执行费用跟踪:
对于开发者仅在工作时间使用的虚拟机,请指定
env: development
标签。您可以使用 Cloud Scheduler 设置无服务器 Cloud Functions 函数,以便在工作时间结束后关停这些虚拟机,并在必要时重启它们。对于具有多个 Cloud Run 服务和 Cloud Functions 实例的应用,请为所有 Cloud Run 和 Cloud Functions 资源分配一致的标签。识别费用较高的区域,并采取措施降低费用。
自定义结算报告
通过设置所需的过滤条件并根据需要对数据进行分组(例如,按项目、服务或标签),配置 Cloud Billing 报告。
宣传节省费用文化
为您的云基础架构培训开发者和操作员。使用传统或在线课程、论坛、对等审核、结对编程和费用节省游戏化等方式创建和推广学习计划。如 Google 的 DORA 研究成果中所述,组织文化是提高绩效、减少返工和倦怠以及优化费用的关键驱动因素。通过让员工了解资源费用,帮助他们根据业务目标和限制条件来安排其优先级和活动。
Compute Engine
本部分提供的指导可帮助您优化 Compute Engine 资源的费用。除了本指南之外,我们还建议您遵循前面讨论的一般性建议。
了解结算模式
如需了解 Compute Engine 的结算选项,请参阅价格。
分析资源消耗情况
为了帮助您了解 Compute Engine 中的资源消耗情况,请将使用情况数据导出到 BigQuery。查询 BigQuery 数据存储区,以分析项目的虚拟 CPU (vCPU) 使用趋势并确定可回收的 vCPU 数量。如果您已定义每个项目的核心数阈值,请分析使用趋势以发现异常情况并采取纠正措施。
收回空闲资源
按照以下建议来识别和收回未使用的虚拟机和磁盘,例如已降低优先级的概念验证项目的虚拟机:
- 使用空闲虚拟机 Recommender 根据使用情况指标识别无效虚拟机和永久性磁盘。
- 在删除资源之前,请评估该操作的潜在影响,并计划在必要时重新创建资源。
- 在删除虚拟机之前,请考虑截取快照。 在删除虚拟机时,除非您已经选择了保留磁盘选项,否则挂接的磁盘也会被删除。
- 在可能的情况下,请考虑停止虚拟机而不是删除虚拟机。停止虚拟机时,实例会终止,但磁盘和 IP 地址会保留下来,直到您分离或删除它们。
调整容量以满足需求
安排虚拟机自动启动和停止。例如,如果一个虚拟机每天只使用 8 小时,一周使用 5 天(即一周使用 40 小时),那么可以通过在不使用虚拟机时将其停用(一周停用 128 小时)将费用减少 75%。
使用代管式实例组根据需求自动扩缩计算容量。您可以根据对业务至关重要的参数(例如 CPU 使用率或负载均衡容量)自动扩缩容量。
选择适当的机器类型
使用虚拟机机器类型 Recommender 调整虚拟机的大小,以满足工作负载的计算要求。
对于具有可预测资源要求的工作负载,请使用自定义虚拟机根据需求定制机器类型并节省资金。
对于容错的批处理工作负载,请考虑使用 Spot 虚拟机。可以部署在 Spot 虚拟机上的工作负载示例包括高性能计算 (HPC)、大数据、媒体转码、持续集成和持续交付 (CI/CD) 流水线和无状态 Web 应用。如需查看 Descartes 实验室如何通过使用抢占式虚拟机(Spot 虚拟机的旧版本)处理卫星图像来降低分析费用的示例,请参阅 Descartes 实验室案例研究。
评估许可选项
将第三方工作负载迁移到 Google Cloud 时,可以通过自带许可 (BYOL) 来降低费用。例如,如需部署 Microsoft Windows Server 虚拟机,您可以创建并使用自定义 Windows BYOL 映像,而不要使用高级映像,这种方式将使用第三方许可并因而产生额外费用。 然后,您只需为在 Google Cloud 上使用的虚拟机基础架构付费。此策略可帮助您继续从现有第三方许可投资中实现价值。
如果您决定使用 BYOL 方法,我们建议您执行以下操作:
- 使用自定义机器类型预配独立于内存的所需计算 CPU 核心数量,并将第三方许可费用限制为所需的 CPU 核心数量。
- 通过停用同时多线程 (SMT),将每个核心的 vCPU 数量从 2 减少到 1,将许可费用降低 50%。
如果您的第三方工作负载需要专用硬件来满足安全或合规性要求,那么可以为单租户节点自带许可。
Google Kubernetes Engine
本部分的指南可帮助您优化 GKE 资源的费用。
除了以下建议之外,另请参阅前面讨论的一般性建议:
- 使用 GKE Autopilot 让 GKE 最大限度地提高集群基础架构的效率。您无需监控节点的运行状况、处理装箱或计算工作负载所需的容量。
- 使用水平 Pod 自动扩缩器 (HPA)、纵向 Pod 自动扩缩器 (VPA)、集群自动扩缩器 (CA) 或节点自动预配,根据工作负载的需求微调 GKE 自动扩缩。
- 对于对启动延迟时间不敏感的批处理工作负载,请使用优化利用率自动扩缩配置文件来帮助提高集群利用率。
- 使用节点自动预配来扩展 GKE 集群自动扩缩器,并基于没有过度预配的待处理 pod 规范高效创建和删除节点池。
- 使用单独的节点池:用于静态负载的静态节点池,以及包含用于动态负载的集群自动扩缩组的动态节点池。
- 如果您的 Pod 具有容错能力并且可以在 25 秒内正常终止,则请为 Kubernetes 节点池使用 Spot 虚拟机。此策略与 GKE 集群自动扩缩器结合使用时,有助于确保包含较低费用虚拟机的节点池(在此情况下为包含 Spot 虚拟机的节点池)优先进行扩缩。
- 选择经济实惠的机器类型(例如 E2、N2D、T2D),性价比提升 20-40%。
- 使用 GKE 用量计量按命名空间和标签分析集群的用量概况。确定支出最多的团队或应用、导致用量或费用出现高峰的环境或组件,以及浪费资源的团队。
- 在多租户集群中使用资源配额可防止任何租户使用超过其分配份额的集群资源。
- 在工作时间结束后安排开发和测试环境的自动缩减。
- 按照最佳实践在 GKE 上运行费用经过优化的 Kubernetes 应用。
Cloud Run
本部分提供的指南有助于优化 Cloud Run 资源的费用。
除了以下建议之外,另请参阅前面讨论的一般性建议:
- 调整并发设置(默认值:80)以降低费用。Cloud Run 根据 CPU 和内存用量确定要发送到实例的请求数。 您可以通过增加请求并发数来减少所需实例数。
- 为可以部署的实例数设置限制。
- 使用可计费实例时间指标估算所需实例数。例如,如果指标显示
100s/s
,则表示大约安排了 100 个实例。添加 30% 的缓冲区以保留性能;也就是说,使用 130 个实例来实现每秒 100 秒的流量。 - 为降低冷启动产生的影响,请配置实例数下限。当这些实例处于空闲状态时,它们将按十分之一的价格计费。
- 跟踪 CPU 使用率并相应地调整 CPU 限制。
- 使用流量管理来确定费用最优配置。
- 请考虑使用 Cloud CDN 或 Firebase Hosting 来传送静态资源。
- 对于全局处理请求的 Cloud Run 应用,请考虑将应用部署到多个区域,因为跨大洲数据传输的费用可能很高。如果您使用负载均衡器和 CDN,则建议采用此设计。
- 减少实例的启动时间,因为启动时间也会计费。
- 购买承诺使用折扣,在一年的期限内,最多可节省 17% 的按需价格。
Cloud Functions
本部分提供的指南可帮助您优化 Cloud Functions 资源的费用。
除了以下建议之外,另请参阅前面讨论的一般性建议:
- 观察函数的执行时间。进行实验和基准测试,以设计出仍满足所需性能阈值的最小函数。
- 如果您的 Cloud Functions 工作负载不断运行,请考虑使用 GKE 或 Compute Engine 来处理工作负载。对于始终运行的工作负载,容器或虚拟机可能是费用较低的选项。
- 限制可以共存的函数实例的数量。
- 根据函数的工作负载,对 Cloud Functions 编程语言的运行时性能进行基准测试。采用编译语言的程序的冷启动时间较长,但运行速度更快。采用解释语言的程序运行速度较慢,但冷启动开销较低。频繁运行的简短函数在使用解释语言时花费更低。
- 删除写入本地磁盘的临时文件,该磁盘是内存内文件系统。临时文件会使用分配给您的函数的内存,并且有时会在多次调用之间持续存在。如果不删除这些文件,可能会发生内存不足错误并触发冷启动,这会增加执行时间和费用。
App Engine
本部分提供的指导能够帮助您优化 App Engine 资源的费用。
除了以下建议之外,另请参阅前面讨论的一般性建议:
- 根据您的流量和请求延迟时间设置实例数上限。App Engine 通常根据应用接收的流量扩缩容量。您可以通过限制 App Engine 可以创建的实例数来控制费用。
- 如需限制应用可用的内存或 CPU,请设置实例类。对于 CPU 密集型应用,请分配更多 CPU。测试一些配置以确定最佳大小。
- 以多种编程语言对 App Engine 工作负载进行基准测试。 例如,如果使用两种语言对工作负载进行编程,相对于另外一种语言,使用这种语言实现的工作负载能够以更少的实例数和更低的费用按时完成任务。
- 进行优化以减少冷启动。尽量减少全局范围内发生的 CPU 密集型或长时间运行的任务。尝试将任务分解为多个可以“延迟加载”到请求上下文中的较小操作。
- 如果您预计会发生突发流量,请配置预热的最小空闲实例数。如果您预计不会有流量,则可以将最小空闲实例配置为零。
- 要平衡性能和费用,请在两个版本之间拆分流量(每个版本具有不同的配置),以运行 A/B 测试。监控每个版本的性能和费用,根据需要进行调整,然后确定将流量发送到的目标配置。
- 配置请求并发,并将并发请求数上限设置为高于默认值。每个实例可以并行处理的请求越多,您可以使用现有实例来处理流量的效率就越高。
后续步骤
- 了解如何优化 GKE 资源的费用:
- 了解如何优化 Cloud Run 和 Cloud Functions 资源的费用:
- 优化存储、数据库、网络和运营的费用:
- 探索 Google Cloud 架构框架的其他类别
优化费用:存储
Google Cloud 架构框架中的本文档提供了建议,以帮助您优化 Cloud Storage、Persistent Disk 和 Filestore 资源的用量和费用。
本部分中的指南适用于负责为云端工作负载预配和管理存储空间的架构师和管理员。
Cloud Storage
为工作负载规划 Cloud Storage 时,请考虑对性能、数据保留和访问模式的要求。
存储类别
选择适合工作负载的数据保留和访问频率要求的存储类别,如下表所建议:
存储要求 | 建议 |
---|---|
不经常访问的数据(高吞吐量分析或数据湖、网站、流式视频和移动应用)。 | Standard Storage |
存储至少 30 天的不常访问数据(例如备份和长尾多媒体内容)的低成本存储。 | Nearline Storage |
可以存储至少 90 天的不常访问数据(例如,用于灾难恢复的数据副本)。 | Coldline Storage |
可以存储至少 365 天的不常访问数据(例如,法律归档和监管归档)的最低费用存储空间。 | Archive Storage |
位置
根据性能、可用性和数据冗余的要求,为存储桶选择位置。
- 如果区域靠近最终用户,建议使用单区域。您可以选择一个特定区域,并在该区域内保证冗余性。单区域可为特定地理区域内的用户经常访问的数据集提供快速、冗余且经济实惠的存储服务。
- 多区域可为分布式用户提供高可用性。但是,存储费用高于单区域。对于内容传送使用场景和低端分析工作负载,建议使用多区域存储桶。
- 双区域可提供高可用性和数据冗余。Google 建议将双区域存储桶用于高性能分析工作负载,以及需要真正的主动/主动存储桶并且计算和存储共同位于多个位置的使用场景。双区域可让您选择数据的存储位置,这有助于您满足合规性要求。例如,您可以使用双区域存储桶来满足有关云端数据副本之间的物理距离的行业特定要求。
生命周期政策
通过定义生命周期政策,优化 Cloud Storage 中对象的存储费用。这些政策可以根据您设置的条件自动降级特定对象的存储类别或删除对象,从而帮助您节省费用。
根据对象的访问频率以及需要保留对象的时长来配置生命周期政策。以下是生命周期政策的示例:
- 降级政策:您希望经常访问数据集,但仅在约三个月内。如需优化此数据集的存储费用,请使用 Standard Storage,并配置生命周期政策以将超过 90 天的对象降级为 Coldline Storage。
删除政策:数据集必须保留 365 天以满足某些法律要求,并且可在该时间段后删除。配置政策以删除任何超过 365 天的对象。
为了帮助您确保需要在特定时间段保留的数据(出于法律或监管合规性要求)在该日期或时间之前不会被删除,请配置保留政策锁定。
问责机制
如需推动运维费用、网络费用和数据检索费用的问责制,请视情况使用请求者付款配置。使用此配置时,费用会计入使用数据的部门或团队,而不是所有者。
以一致的方式为所有存储桶和对象定义和分配费用跟踪标签。请在可行时自动添加标签。
冗余
您可以使用以下方法来保持所需的存储冗余,而无需复制数据:
- 如需使用单一可靠来源保持数据弹性,请使用双区域或多区域存储桶,而不是不同存储桶中数据的冗余副本。双区域和多区域存储桶可提供跨区域的冗余。您的数据可跨两个或更多位置异步复制,并且可以防范区域服务中断。
- 如果启用对象版本控制,请考虑定义生命周期政策,以便在较新版本成为非当前版本时移除对象的最早版本。对象的每个非当前版本都将按与其当前版本相同的费率进行计费。
- 对象版本控制政策不再需要时将其停用。
- 定期查看备份和快照保留政策,并对其进行调整以避免不必要的备份和数据保留。
Persistent Disk
您在 Compute Engine 中部署的每个虚拟机实例都有一个启动磁盘,以及一个或多个可选的数据磁盘。每个磁盘都会产生费用,具体取决于预配大小、区域和磁盘类型。您为磁盘截取的任何快照都会根据快照的大小产生费用。
您可以使用以下设计和操作建议来优化永久性磁盘的费用:
- 不要过度分配磁盘空间。预配后,您无法减少磁盘容量。从小磁盘开始,并根据需要增加大小。永久性磁盘按预配容量计费,而不是按存储在磁盘上的数据计费。
选择与工作负载的性能特征匹配的磁盘类型。SSD 提供高 IOPS 和吞吐量,但费用高于标准永久性磁盘。
仅在需要保护数据免受可用区服务中断影响时,才使用区域永久性磁盘。区域永久性磁盘会复制到该区域内的另一个可用区,因此会产生等效可用区磁盘的两倍费用。
使用 Cloud Monitoring 跟踪永久性磁盘的使用情况,并为使用率较低的磁盘设置提醒。
删除您不再需要的磁盘。
对于包含将来可能需要的数据的磁盘,请考虑将数据归档到低费用的 Cloud Storage,然后删除这些磁盘。
在 Recommendation Hub 中查找并采纳建议。
此外,请考虑将 Hyperdisk 用于高性能存储,并将临时磁盘(本地 SSD)用于临时存储。
磁盘快照默认采用增量方式创建,并且会自动压缩。请考虑以下优化磁盘快照费用的建议:
- 在可行的情况下,将数据整理到单独的永久性磁盘中。然后,您可以选择性地备份磁盘,并减少磁盘快照的费用。
- 创建快照时,根据可用性要求和关联的网络费用选择位置。
- 如果您打算使用启动磁盘快照来创建多个虚拟机,请通过该快照创建映像,然后使用该映像创建虚拟机。此方法可帮助您避免在快照位置和恢复快照的位置之间传输数据的网络费用。
- 考虑设置保留政策,以最大限度地减少磁盘快照的长期存储费用。
- 删除不再需要的磁盘快照。链中的每个快照都可能依赖于存储在上一个快照中的数据。因此,删除快照不一定会删除该快照中的所有数据。如需彻底删除快照中的数据,您应当删除链中的所有快照。
Filestore
Filestore 实例的费用取决于其服务层级、预配容量和实例的预配区域。以下是可优化 Filestore 实例费用的设计和操作建议:
- 选择适合您的存储需求的服务层级和存储类型(HDD 或 SSD)。
- 请勿过度分配容量。从小磁盘开始,之后根据需要增加大小。Filestore 结算基于预配容量,而非存储的数据。
- 在可行的情况下,将数据整理到单独的 Filestore 实例中。然后,您可以选择性地备份实例,并减少 Filestore 备份的费用。
- 选择区域和可用区时,请考虑在与客户端相同的可用区中创建实例。您需要为 Filestore 实例的可用区中的数据传输流量付费。
- 确定应存储 Filestore 备份的区域时,请考虑在与来源实例不同的区域中存储备份的数据传输费用。
- 使用 Cloud Monitoring 跟踪 Filestore 实例的使用情况,并为使用率较低的实例设置提醒。
- 缩减为使用率较低的 Filestore 实例分配的容量。您可以减少除基本层级以外的实例容量。
后续步骤
- 查看 Cloud Storage 费用优化的最佳实践(博客)
- 优化计算服务、数据库、网络和运维的费用:
- 探索 Google Cloud 架构框架的其他类别
优化费用:数据库和智能分析
Google Cloud 架构框架中的本文档提供了建议,以帮助您优化 Google Cloud 中的数据库和分析工作负载的费用。
本部分中的指导适用于负责预配并管理云数据库和分析工作负载的架构师、开发者和管理员。
本部分包括针对以下产品的费用优化建议:
Cloud SQL
Cloud SQL 是一项适用于 MySQL、PostgreSQL 和 SQL Server 的全代管式关系型数据库服务。
监控用量
查看监控信息中心上的指标,并验证您的部署是否满足工作负载的要求。
优化资源
以下建议可帮助您优化 Cloud SQL 资源:
- 设计与您的恢复时间目标 (RTO) 和恢复点目标 (RPO) 一致的高可用性和灾难恢复策略。根据您的工作负载,我们建议您执行以下操作:
- 为数据库预配所需的最小存储容量。
- 如需在数据增长时自动扩缩存储空间容量,请启用存储空间自动扩容功能。
- 选择适合您的使用场景的存储类型:固态硬盘 (SSD) 或普通硬盘 (HDD)。对于大多数使用场景而言,SSD 是最有效且最经济实惠的选择。HDD 可能适用于对延迟不敏感或不常访问的大型数据集 (>10 TB)。
优化费率
请考虑为具有可预测资源需求的工作负载购买承诺使用折扣。1 年期承诺可节省 25% 的按需价格,而 3 年期承诺则可节省 52%。
Spanner
Spanner 是云原生、规模不受限制、具备强一致性的数据库,可用性高达 99.999%。
监控用量
以下建议可帮助您跟踪 Spanner 资源的用量:
优化资源
以下建议可帮助您优化 Spanner 资源:
- 使用处理单元 (PU) 而不是节点来预配资源,从而以更低的费用在 Spanner 上运行较小的工作负载。一个 Spanner 节点等于 1,000 个处理单元。
- 使用查询优化器提高查询执行性能。
- 按照最佳实践构建 SQL 语句来构建高效的执行计划。
- 使用自动扩缩器工具管理 Spanner 部署的使用情况和性能。该工具会自动监控实例、添加或移除节点,并有助于确保实例保持在建议的 CPU 和存储空间限制范围内。
- 使用时间点恢复 (PITR) 防止意外删除或写入。版本保留期较长的数据库(尤其是经常覆盖数据的数据库)会使用更多系统资源,并且需要更多节点。
- 查看您的备份策略并选择以下选项之一:
- 备份和恢复
- 导出和导入
优化费率
在确定 Spanner 节点的位置时,请考虑 Google Cloud 区域之间的费用差异。例如,部署在 us-central1
区域的节点的每小时费用远远低于 southamerica-east1
区域的节点。
Bigtable
Bigtable 是一种云原生宽列 NoSQL 存储区,适用于大规模、短延迟时间的工作负载。
监控用量
以下建议可帮助您跟踪 Bigtable 资源的用量:
- 分析用量指标以发现资源优化机会。
- 使用 Key Visualizer 诊断工具可识别 Bigtable 集群中的热点和热键。
优化资源
以下建议可帮助您优化 Bigtable 资源:
- 为帮助确保 CPU 和磁盘用量以实现延迟时间与存储空间容量的平衡,请评估和调整 Bigtable 集群的节点数和大小。
- 通过以编程方式扩缩 Bigtable 集群来自动调整节点数,尽可能以最低的费用来维持性能。
请根据以下注意事项来评估最经济实惠的存储设备类型(HDD 或 SSD)是否适合您的使用场景:
- HDD 存储设备的费用低于 SSD,但性能不及 SSD。
- SSD 存储设备的费用高于 HDD,但可提供更快速和可预测的性能。
除非您存储大量数据,否则 HDD 所节省的费用相对于 Bigtable 集群中的节点费用而言微乎其微。HDD 存储设备有时适用于对延迟不敏感或不常访问的大型数据集 (>10 TB)。
使用垃圾回收功能移除过期和过时的数据。
为避开热点,请运用行键设计的最佳实践。
设计符合您的 RPO 且经济实惠的备份方案。
如需降低集群用量并减少节点数,请考虑使用 Memorystore 为可缓存的查询添加容量缓存。
附加阅读材料
BigQuery
BigQuery 是一个扩缩能力极强且经济实惠的无服务器多云数据仓库,旨在提升您的业务敏捷性。
监控用量
以下建议可帮助您跟踪 BigQuery 资源的用量:
优化资源
以下建议可帮助您优化 BigQuery 资源:
- 根据您的合规性策略为数据设置数据集级、表级或分区级到期时间。
- 通过限制每个查询的字节数来限制查询费用。为防止意外出现人为错误,请在用户级和项目级启用费用控制。
- 仅查询您需要的数据。避免完整查询扫描。如需探索和了解数据语义,请使用免费的数据预览选项。
- 如需降低处理费用并提高性能,请尽可能对表进行分区和聚簇。
- 尽早并尽可能经常过滤查询。
- 处理来自多个来源(例如 Bigtable、Cloud Storage、Google 云端硬盘和 Cloud SQL)的数据时,请使用联合访问数据模型来避免复制数据并避免直接从来源查询数据。
- 利用 BigQuery 的备份,而不是复制数据。请参阅数据的灾难恢复场景。
优化费率
以下建议可帮助您降低 BigQuery 资源的结算费率:
- 评估数据的修改方式,并利用较低的长期存储价格。
- 查看固定费率和按需价格之间的区别,并选择适合您的要求的选项。
- 评估是否可以为数据工作流使用批量加载而不是流式插入。要使加载到 BigQuery 中的数据立即可用,请使用流式插入。
- 如需提高性能并降低检索数据的费用,请使用缓存的查询结果。
附加阅读材料
Dataflow
Dataflow 是一项快速且经济实惠的无服务器服务,用于进行统一的流式和批量数据处理。
监控用量
以下建议可帮助您跟踪 Dataflow 资源的用量:
- 通过运行小型负载实验,找到作业的最优性能并推断吞吐量因素,来预测 Dataflow 作业的费用。
- 使用可观测性信息中心更深入地了解吞吐量和 CPU 使用率。
- 使用 Dataflow 监控界面观察与性能、执行和健康状况相关的流水线指标。
优化资源
以下建议可帮助您优化 Dataflow 资源:
- 请考虑使用 Dataflow Prime 高效地处理大数据。
- 通过对自动扩缩的批量流水线使用 Flexible Resource Scheduling (FlexRS) 来降低批处理费用。FlexRS 使用高级安排选项 (Dataflow Shuffle) 以及抢占式虚拟机和常规虚拟机的组合,来降低批处理流水线的费用。
- 通过使用内存中的 Shuffle 服务而不是 Persistent Disk 和工作器节点来提高性能。
- 如需提高自动扩缩的响应速度并减少资源消耗量,请使用 Streaming Engine,它会将流水线的执行操作从工作器虚拟机中移出并移入 Dataflow 服务后端。
- 如果流水线不需要访问互联网和其他 Google Cloud 网络,请停用公共 IP 地址。停用互联网访问权限有助于降低网络费用并提高流水线安全性。
- 请遵循使用 Dataflow 实现高效流水线的最佳实践。
Dataproc
Dataproc 是一项代管式 Apache Spark 和 Apache Hadoop 服务,可用于批处理、查询、流式传输和机器学习。
以下建议可帮助您优化 Dataproc 资源的费用:
- 选择适合您的工作负载的机器类型。
- 使用自动扩缩集群进行自动扩缩以满足需求,用户只需为所需的资源支付费用。
- 如果作业完成后可以删除集群,请考虑使用受管集群工作流模板预配一个临时集群。
- 为避免非活跃集群产生费用,请使用计划删除,以便在指定的空闲时间段后、在指定的时间,或在指定的时间段后删除集群。
- 请遵循在 Dataproc 上构建长时间运行的集群的最佳实践。
- 为始终处于开启状态的工作负载购买承诺使用折扣。
后续步骤
- 优化计算服务、存储、网络和运营的费用:
- 探索 Google Cloud 架构框架的其他类别
优化费用:网络
Google Cloud 架构框架中的本文档中提供了建议,以帮助您优化 Google Cloud 中网络资源的费用。
本部分中的指南适用于负责为云工作负载预配和管理网络的架构师和管理员。
设计考虑事项
与传统数据中心网络的固定费用相比,本地网络和云网络的根本区别在于云中基于用量的动态费用模型。
在规划云网络时,请务必了解基于流量方向的价格模型,如下所示:
- 传入 Google Cloud 的流量不会产生费用。 用于处理入站流量的资源(如 Cloud Load Balancing)会产生费用。
- 对于数据传输流量(包括 Google Cloud 中虚拟机之间的流量以及从 Google Cloud 到互联网和本地主机的流量),价格与以下因素有关:
- 流量使用的是内部还是外部 IP 地址
- 流量是否跨越了可用区边界或区域边界
- 流量是否离开了 Google Cloud
- 流量在离开 Google Cloud 之前传输的距离
当 Google Cloud 中的两个虚拟机或云资源进行通信时,每个方向的流量在来源处都被指定为出站数据传输,而在目的地处则被指定为入站数据传输,并相应地进行计费。
设计费用最优的云网络时,请考虑以下因素:
- 地理位置
- 网络布局
- 连接方案
- Network Service Tiers
- 日志记录
以下各部分对这些因素进行了更详细的讨论。
地理位置
网络费用可能会因预配资源的 Google Cloud 区域而异。如需分析区域之间的网络带宽,您可以使用 VPC 流日志和 Network Intelligence Center。对于在 Google Cloud 区域之间流动的流量,即使流量不通过互联网,费用也可能因区域的位置而异。
除了 Google Cloud 区域以外,还请考虑部署资源的可用区。根据可用性要求,您可以将应用设计为通过内部 IP 地址免费在某个可用区内通信。在考虑单个可用区架构时,请在任何潜在的网络费用节省与对可用性产生的影响之间进行权衡。
网络布局
分析网络布局、流量在应用和用户之间的流动方式以及每个应用或用户消耗的带宽。网络拓扑工具可让您全方位了解 Google Cloud 的全球部署及其与公共互联网的交互情况,包括整个单位内的用户都可以查看的拓扑和关联的网络性能指标。您可以找出低效部署,并采取必要的措施来优化区域和洲际数据传输费用。
连接方案
如果您经常需要将大量数据(TB 或 PB 级数据)从本地环境推送到 Google Cloud,请考虑使用专用互连或合作伙伴互连。与遍历公共互联网或使用 VPN 相关的费用相比,专用连接更便宜。
请尽可能使用专用 Google 访问通道,以降低费用并改进安全状况。
Network Service Tiers
默认情况下,Google 的高级网络基础架构(高级层级)用于所有服务。如果资源不需要高级层级提供的高性能和低延迟时间,则您可以选择费用更低的标准层级。
选择服务层级时,请考虑层级之间的差异以及标准层级的限制。根据应用的需求微调网络,也可以降低能够承受更长延迟时间且不需要 SLA 的服务的网络费用。
日志记录
借助 VPC 流日志、防火墙规则日志记录和 Cloud NAT 日志记录,您可以分析网络日志并发现降低费用的机会。
对于“VPC 流日志”和 Cloud Load Balancing,您还可以启用采样来减少写入数据库的日志量。您可以将采样率从 1.0(保留所有日志条目)更改为 0.0(不保留任何日志)。对于问题排查或自定义使用场景,您可以选择始终收集特定 VPC 网络或子网的遥测结果,或监控特定的虚拟机实例或虚拟接口。
设计建议
为优化网络流量,我们建议您采取以下措施:
- 设计您的解决方案,使应用更接近您的用户群。使用 Cloud CDN 来减少流量并降低延迟时间,并利用 CDN 的较低价格来提供您希望许多用户经常访问的内容。
- 在全球范围内,请避免在远离最终用户或网络费用较高的区域之间同步数据。如果应用仅在某个区域内使用,请避免跨区域处理数据。
- 确保某个可用区内的虚拟机之间的通信是通过其内部 IP 地址进行路由,而不是在外部路由。
- 通过压缩数据输出来降低数据传输费用和客户端延迟时间。
- 使用 VPC 流日志观察关键项目的出站流量和入站流量,从而分析支出模式并发现控制费用的机会。
- 在云中设计网络时,请考虑分布式网络提供的高可用性与流量集中到单个可用区或区域所节省的费用之间的权衡取舍。
为优化您为网络服务支付的价格,我们建议您采取以下措施:
- 如果服务器位置不受限制,请评估不同区域的费用,然后选择最经济实惠的区域。对于常规出站流量(例如一组网络服务器提供的内容),价格可能会因服务器的预配区域而异。
- 如需降低经常将大量数据迁移到云所产生的费用,请在本地网络与 Google Cloud 网络之间使用直接连接。请考虑使用专用互连或合作伙伴互连。
- 为每个环境选择适当的服务层级:亦即为开发和测试环境选择标准层级,为生产环境选择高级层级。
后续步骤
- 查看网络价格信息
- 查看网络费用优化的最佳实践
- 优化计算服务、存储、数据库和运营的费用:
- 探索 Google Cloud 架构框架的其他类别
优化费用:Cloud Operations
Google Cloud 架构框架中的本文档提供了建议,以帮助您优化在 Google Cloud 中监控和管理资源的费用。
本部分中的指导适合负责监控和控制其组织资源在云中的用量和费用的云用户。
Google Cloud Observability 是一组托管式服务,可用于监控 Google Cloud 中的工作负载、排查其问题并提升其性能。这些服务包括 Cloud Monitoring、Cloud Logging、Error Reporting、Cloud Trace 和 Cloud Profiler。Google Cloud 中代管式服务的好处之一是服务基于用量。您只需按使用量和数据量付费,每月都有免费的数据用量配额并且拥有对 Google Cloud 指标和审核日志的无限制使用权限。
Cloud Logging
以下建议可帮助您优化 Logging 操作的费用:
- 过滤结算报告以显示 Logging 费用。
- 通过排除或过滤不必要的日志条目来减少提取和存储的日志量。
- 通过在 Google Cloud 控制台中监控
billing/bytes_ingested
和billing/monthly_bytes_ingested
指标来验证排除项过滤条件是否足以满足需求。 - 将日志分流并将日志导出到费用较低的存储空间。
- 从第三方应用流式传输日志时,请只对生产实例使用日志记录代理或将其配置为发送较少的数据,从而减少日志量。
Cloud Monitoring
以下建议可帮助您优化 Monitoring 操作的费用:
- 通过限制标签数量来优化指标和标签的使用。避免使用基数较高的标签。例如,如果您使用 IP 地址作为标签,则每个 IP 地址都有一个单项标签系列,这样一来,如果您有许多虚拟机,则会产生许多标签。
- 请减少不需要详细指标的应用的指标数量,或移除监控代理,特别是对于非必要环境而言。
- 通过减少应用发送的自定义指标数量来最大限度地减少提取量。
Cloud Trace
以下建议可帮助您优化 Trace 操作的费用:
- 如果使用 Trace 作为 OpenCensus 跟踪记录的导出目标,请使用 OpenCensus 中的采样功能来减少提取的跟踪记录量。
- 使用配额来限制 Trace 的用量并控制费用。您可以使用 Google Cloud 控制台中 API 特定的配额页面来强制实施 span 配额。
后续步骤
- 优化 Google Cloud Observability 的费用
- 视频:管理 Google Cloud Observability 的费用
- 优化计算服务、存储、数据库和网络的费用:
- 探索 Google Cloud 架构框架的其他类别
Google Cloud 架构框架:性能优化
Google Cloud 架构框架中的这一类别介绍了性能优化过程和最佳实践,以优化 Google Cloud 中的工作负载的性能。
本文档中的信息适用于规划、设计、部署和管理 Google Cloud 中的工作负载的架构师、开发者和管理员。
优化云中的工作负载的性能可帮助您的组织高效地运营、提高客户满意度、增加收入并降低费用。例如,当应用的后端处理时间缩短时,用户会体验更快的响应速度,从而可以提高用户留存率并增加收入。
可能需要在性能和费用之间进行权衡取舍。但有时,优化性能可以帮助您降低费用。例如,自动扩缩可确保资源不会过载,从而帮助您在负载增加时提供可预测的性能。自动扩缩还会移除未使用的资源,从而帮助您在低负载期间降低费用。
在架构框架的此类别中,您将了解如何执行以下操作:
性能优化过程
Google Cloud 架构框架文档简要介绍了性能优化过程。
性能优化是一个连续的过程,而不是一次性的活动。下图显示了性能优化过程中的各个阶段:
下面简要介绍了性能优化过程的各个阶段:
定义性能要求
在开始设计和开发您打算部署或迁移到云的应用之前,请确定性能要求。尽可能准确地定义应用堆栈的每一层的要求:前端负载均衡、Web 或应用服务器、数据库和存储。例如,对于堆栈的存储层,请确定应用需要的吞吐量和每秒 I/O 操作次数 (IOPS)。
设计和部署应用
使用有助于满足性能要求的弹性和可扩缩设计模式来设计应用。考虑以下设计弹性和可扩缩应用的准则:
- 构建工作负载以实现最佳内容放置。
- 隔离读取和写入流量。
- 隔离静态和动态流量。
- 实现内容缓存。对内部层使用数据缓存。
- 使用代管式服务和无服务器架构。
Google Cloud提供了开源工具,您可以使用这些工具来测试 Google Cloud 服务与其他云平台的性能。
监控和分析性能
部署应用后,您可以使用日志和提醒来持续监控性能,分析数据,并识别性能问题。随着应用的发展和发展,请重新评估您的性能要求。您可能需要重新设计应用的某些部分才能维护或提高性能。
优化性能
根据应用的性能和要求的变化,配置云资源以满足当前的性能要求。例如,调整资源大小或设置自动扩缩功能。配置资源时,请评估使用最近发布的 Google Cloud 功能和服务的机会,以帮助进一步优化性能。
此时,性能优化过程不会结束。继续监控性能的周期,必要时重新评估要求,并调整云资源以维持和改善性能。
后续步骤
监控和分析性能
Google Cloud 架构框架中的这篇文档介绍了 Google Cloud Observability 中的服务,您可以使用这些服务来记录、监控和分析工作负载的性能。
监控性能指标
使用 Cloud Monitoring 来分析性能指标的趋势、分析实验的影响、定义关键指标的提醒,以及执行回顾性分析。
记录关键数据和事件
Cloud Logging 是一项集成式日志记录服务,您可以使用此服务来存储、分析、监控和设置日志数据和事件的提醒。Cloud Logging 可以从 Google Cloud 和其他云提供商的服务收集日志。
分析代码性能
性能不佳的代码可能会增加应用的延迟时间和运行费用。Cloud Profiler 能够持续分析应用使用的 CPU 密集型或内存密集型函数的性能,从而帮助您确定并解决性能问题。
收集延迟数据
在复杂的应用堆栈和基于微服务的架构中,评估服务间通信的延迟和识别性能瓶颈可能很困难。Cloud Trace 和 OpenTelemetry 工具可帮助您从部署中大规模收集延迟数据。这些工具还可帮助您高效地分析延迟数据。
监控网络性能
借助 Network Intelligence Center 的性能信息中心,您可以全面了解 Google 网络的性能指标和项目中的资源。这些指标可帮助您确定与网络相关的性能问题的原因。例如,您可以识别性能问题是由项目或 Google 网络中的问题引起。
后续步骤
优化计算性能
Google Cloud 架构框架中的这篇文档提供了建议,可帮助您优化 Compute Engine、Google Kubernetes Engine (GKE) 和无服务器资源的性能。
Compute Engine
本部分提供的指导可帮助您优化 Compute Engine 资源的性能。
自动扩缩资源
代管式实例组 (MIG) 可让您高效地扩缩部署在 Compute Engine 虚拟机上的无状态应用。自动扩缩可帮助您的应用在负载增加时继续提供可预测的性能。在 MIG 中,一组 Compute Engine 虚拟机会根据您定义的模板启动。在模板中,您可以配置自动扩缩政策,以指定自动扩缩器用于扩缩实例组的一个或多个信号。自动扩缩信号可以基于时间表(如开始时间或时长)或目标指标(如平均 CPU 利用率)。如需了解详情,请参阅自动扩缩实例组。
停用 SMT
您分配给 Compute Engine 虚拟机的每个虚拟 CPU (vCPU) 都作为单个硬件多线程实现。默认情况下,两个 vCPU 共用一个物理 CPU 核心。此架构称为同时多线程 (SMT)。
对于高度并行或执行浮点计算的工作负载(例如转码、蒙特卡罗模拟、基因序列分析和财务风险建模),您可以通过停用 SMT 来提高性能。如需了解详情,请参阅设置每个核心的线程数。
使用 GPU
对于机器学习和可视化等工作负载,您可以向虚拟机添加图形处理单元 (GPU)。Compute Engine 以直通模式提供 NVIDIA GPU,让您的虚拟机可以直接控制 GPU 和相关内存。对于图形密集型工作负载(例如 3D 可视化),您可以使用 NVIDIA RTX 虚拟工作站。部署工作负载后,监控 GPU 使用情况并查看优化 GPU 性能的选项。
使用计算优化机器类型
游戏、媒体转码和高性能计算 (HPC) 等工作负载要求每个 CPU 核心始终保持高性能。Google 建议您为运行此类工作负载的虚拟机使用计算优化机器类型。计算优化虚拟机基于使用非统一内存访问 (NUMA) 等功能的架构构建,以实现最佳可靠的性能。
紧密耦合的 HPC 工作负载具有一组独特要求,可实现性能峰值。如需了解详情,请参阅以下文档:
选择适当的存储空间
Google Cloud 为 Compute Engine 虚拟机提供了各种存储方案:永久性磁盘、本地固态硬盘 (SSD) 磁盘、Filestore 和 Cloud Storage。如需了解优化每种存储选项的性能的设计建议和最佳实践,请参阅优化存储性能。
Google Kubernetes Engine
本部分提供的指导可帮助您优化 Google Kubernetes Engine (GKE) 资源性能。
自动扩缩资源
您可以使用集群自动扩缩器功能自动调整 GKE 集群中节点池的大小以与当前负载相匹配。自动扩缩可帮助您的应用在负载增加时继续提供可预测的性能。集群自动扩缩器会根据在节点上运行的 Pod 的资源请求(而不是实际资源利用率)自动调整节点池的大小。使用自动扩缩时,需要在性能和费用之间进行权衡。查看高效配置集群自动扩缩的最佳实践。
使用 C2D 虚拟机
您可以使用 C2D 机器类型来提高计算密集型容器化工作负载的性能。您可以在节点池中选择 C2D 机器类型,将 C2D 节点添加到 GKE 集群。
停用 SMT
同时多线程 (SMT) 可以显著提高一般计算任务和需要高 I/O 的工作负载的应用吞吐量。但对于两个虚拟核心均受计算限制的工作负载而言,SMT 可能会导致性能不一致。为了获得更好且可预测性能,您可以将每个核心的 vCPU 数量设置为 1,从而为 GKE 节点停用 SMT。
使用 GPU
对于图片密集型工作负载(例如图片识别和视频转码),您可以创建使用 GPU 的节点池来加快性能。如需了解详情,请参阅运行 GPU。
使用容器原生负载均衡
利用容器原生负载均衡,负载均衡器能够直接将流量均匀分发给 Pod。此方法可提供更好的网络性能,可让您更好地了解负载均衡器和 Pod 之间的网络延迟时间。由于具备这些优势,因此容器原生负载均衡是通过 Ingress 实现负载均衡的建议解决方案。
定义紧凑放置政策
紧密耦合的批处理工作负载在 GKE 节点池中的节点之间需要低网络延迟。您可以将此类工作负载部署到单区域节点池,并通过定义紧凑放置政策来确保节点在物理上彼此靠近。如需了解详情,请参阅为 GKE 节点定义紧凑放置。
无服务器计算服务
本部分提供的指导可帮助您优化 Google Cloud 中无服务器计算服务的性能:Cloud Run 和 Cloud Functions。这些服务提供的底层基础架构会自动处理扩缩的自动扩缩功能。通过使用这些无服务器服务,您可以减少扩缩微服务和功能的工作,并专注于优化应用级层的性能。
如需了解详情,请参阅以下文档:
后续步骤
查看优化存储、网络、数据库和分析资源性能的最佳实践:
优化存储性能
Google Cloud 架构框架中的本文档中提供了建议,以帮助您优化 Google Cloud 中存储资源的费用。
Cloud Storage
本部分提供的最佳实践可帮助您优化 Cloud Storage 运维的性能。
评估存储桶性能
使用 gsutil perfdiag
命令评估 Cloud Storage 存储桶的性能。此命令通过发送一系列具有不同大小的读写请求来测试指定存储桶的性能。您可以调整测试,以匹配应用的使用模式。使用该命令生成的诊断报告来设置性能预期并确定潜在的瓶颈。
缓存经常访问的对象
要缩短可公开访问的频繁访问对象的读取延迟时间,您可以配置对此类对象进行缓存。虽然缓存可以提高性能,但如果缓存具有对象的旧版本,则可能提供过时的内容。
高效扩缩请求
随着存储桶请求速率的增加,Cloud Storage 会通过将请求负载分配到多个服务器上,自动提高存储桶的 I/O 容量。如需在扩缩请求时实现最佳性能,请遵循最佳实践以逐步提高请求率并均匀分配负载。
启用多线程和多处理
使用 gsutil
上传许多小文件时,您可以使用 -m
选项提高操作的性能。此选项会导致上传请求以批量并行(即多线程和多处理)操作的形式实现。仅当您通过快速网络连接执行操作时,才能使用此选项。如需了解详情,请参阅全局命令行选项中 -m
选项的文档。
将大文件上传为复合文件
如需上传大型文件,您可以使用一种名为并行复合上传的策略。使用此策略时,大文件会分成块进行上传,然后并行上传,接着在云端重新组合。如果网络带宽和磁盘速度不是限制因素,则并行复合上传的速度可能比常规上传操作快。但是,此策略存在一些限制和费用影响。如需了解详情,请参阅并行复合上传。
永久性磁盘和本地 SSD
本部分提供的最佳实践可帮助您优化挂接到 Compute Engine 虚拟机的永久性磁盘和本地 SSD 的性能。
永久性磁盘和本地 SSD 的性能取决于磁盘类型和大小、虚拟机机器类型和 vCPU 数量。请按照以下准则来管理永久性磁盘和本地 SSD 的性能:
- 为虚拟机预配块存储时,请选择适合您的工作负载的磁盘类型和磁盘大小。如需了解详情,请参阅配置磁盘以满足性能要求。
- 对块存储性能进行基准测试。如需了解详情,请参阅以下文档:
- 优化永久性磁盘和本地 SSD 的性能。如需了解详情,请参阅以下文档:
Filestore
本部分介绍优化 Filestore 实例性能的最佳实践。您可以使用 Filestore 为 Compute Engine 虚拟机和 GKE 集群预配全托管式网络文件系统 (NFS) 文件服务器。
- 预配 Filestore 实例时,请选择满足工作负载性能和容量要求的服务层级。
- 对于运行依赖于缓存的工作负载的客户端虚拟机,请使用有助于优化 Filestore 实例的网络性能的机器类型。如需了解详情,请参阅建议的客户端机器类型。
- 如需为运行 Linux 的客户端虚拟机优化 Filestore 实例的性能,Google 建议使用特定 NFS 装载设置。如需了解详情,请参阅 Linux 客户端装载选项。
- 为了最大程度地减少网络延迟,请在计划使用实例的位置附近的区域和可用区中预配 Filestore 实例。
- 监控 Filestore 实例的性能,并使用 Cloud Monitoring 设置提醒。
后续步骤
查看优化计算、网络、数据库和分析资源性能的最佳实践:
优化网络和 API 性能
Google Cloud 架构框架中的这篇文档提供了建议,可帮助您优化 Google Cloud 中的网络资源和 API 的性能。
Network Service Tiers
通过 Network Service Tiers,您可以优化工作负载的网络费用和性能。您可以从以下层级中进行选择:
- 高级层级使用 Google 高度可靠的全球骨干网,帮助您最大限度地减少丟包并缩短延迟时间。流量会在靠近最终用户的全球边缘入网点 (PoP) 进入和离开 Google 网络。为获得最佳性能,我们建议使用高级层级作为默认层级。对于虚拟机和负载均衡器,高级层级同时支持区域级和全球级外部 IP 地址。
- 标准层级仅适用于使用区域级外部 IP 地址的资源。流量会在最靠近工作负载运行的 Google Cloud 位置的边缘 PoP 进入和离开 Google 网络。标准层级的价格低于高级层级。标准层级适用于对丟包不敏感且没有低延迟要求的流量。
您可以在 Network Intelligence Center 性能信息中心中查看每个云区域的标准层级和优质层级的网络延迟时间。
巨型帧
Virtual Private Cloud (VPC) 网络的默认最大传输单元 (MTU) 为 1460 字节。但是,您可以将 VPC 网络配置为支持最大 8896
的 MTU(巨型帧)。
当 MTU 较高时,网络需要较少的数据包来发送相同数量的数据,从而减少 TCP/IP 标头占用的带宽。这可以提高网络的有效带宽。
如需详细了解 VPC 内 MTU 和其他连接的 MTU 上限,请参阅 VPC 文档中的最大传输单元页面。
虚拟机性能
Compute Engine 虚拟机的出站带宽上限部分取决于机器类型。为了选择适当的机器类型,您需要考虑希望虚拟机生成多少流量。
网络带宽页面讨论了各种 Compute Engine 机器类型的网络带宽并包含表格。
如果虚拟机间带宽要求非常高,请考虑使用支持 Tier_1 网络的虚拟机。
Cloud Load Balancing
本部分提供的最佳实践可帮助您优化 Cloud Load Balancing 实例的性能。
在靠近用户的位置部署应用
在您预计用户流量到达负载均衡器的位置附近预配您的应用后端。用户或客户端应用离工作负载服务器越近,用户和工作负载之间的网络延迟时间越短。为了最大限度地缩短全球不同区域的客户端的延迟,您可能需要在多个区域部署后端。如需了解详情,请参阅 Compute Engine 区域选择最佳实践。
选择适当的负载均衡器类型
您为应用选择的负载均衡器类型决定了用户体验的延迟时间。如需了解如何衡量和优化不同负载均衡器类型的应用延迟,请参阅通过负载均衡优化应用延迟。
启用缓存
为加快内容传送速度,请在默认外部 HTTP 负载均衡器配置中启用缓存和 Cloud CDN。确保后端服务器已配置以发送缓存静态响应所需的响应标头。
不需要 HTTPS 时使用 HTTP
Google 会在数据包级别自动加密代理负载均衡器和后端之间的流量。数据包级加密会使负载均衡器和后端之间的 HTTPS 第 7 层加密在大多数情况下实现冗余。对于负载均衡器和后端之间的流量,请考虑使用 HTTP 而不是 HTTPS 或 HTTP/2。您还可以使用 HTTP 减少后端虚拟机的 CPU 利用率。但是,如果后端是互联网网络端点组 (NEG),请为负载均衡器和后端之间的流量使用 HTTPS 或 HTTP/2。这有助于确保您的流量在公共互联网上安全无虞。为了获得最佳性能,我们建议您对应用的流量模式进行基准化分析。
Network Intelligence Center
Google Cloud Network Intelligence Center 可让您全面了解 Google Cloud 网络在所有区域的性能。Network Intelligence Center 可帮助您确定延迟问题是由项目还是网络中的问题引起。您还可以使用此信息选择区域和可用区,以部署工作负载以优化网络性能。
使用 Network Intelligence Center 提供的以下工具监控和分析 Google Cloud 中的工作负载的网络性能:
性能信息中心显示 Google Cloud 区域与互联网上各个区域和位置之间的延迟时间。性能信息中心可帮助您确定将工作负载置于何处以实现最佳延迟,并帮助确定底层网络问题导致了应用问题的情况。
网络拓扑直观呈现您的 Virtual Private Cloud (VPC) 网络、与本地网络的混合连接以及与 Google 管理的服务的连接。网络拓扑提供实时操作指标,可用于分析和了解网络性能以及识别异常的流量模式。
网络分析器是一种自动配置监控和诊断工具。它验证 VPC 网络配置的防火墙规则、路由、配置依赖项以及服务和应用的连接性。它可以帮助您识别网络故障,并提供根本原因分析和建议。网络分析器提供优先数据分析,以帮助您分析网络配置问题,例如子网中 IP 地址的高利用率。
API Gateway 和 Apigee
本部分提供一些建议,帮助您通过使用 API Gateway 和 Apigee 来优化在 Google Cloud 中部署的 API 的性能。
API Gateway 可让您为 Google Cloud 无服务器后端(包括 Cloud Functions、Cloud Run 和 App Engine)创建和管理 API。这些服务是代管式服务,可自动扩缩。但是,随着在这些服务上部署的应用进行扩缩,您可能需要提高 API Gateway 的配额和速率限制。
Apigee 提供以下分析信息中心,可帮助您监控代管式 API 的性能:
- API 代理性能信息中心:监控 API 代理流量模式和处理时间。
- 目标性能信息中心:直观呈现 API 代理后端目标的流量模式和性能指标。
- 缓存性能信息中心:监控 Apigee 缓存的性能指标,例如平均缓存命中率和缓存平均时间。
如果您使用 Apigee Integration,请在构建和管理集成时考虑系统配置限制。
后续步骤
查看优化计算、存储、数据库和分析资源性能的最佳实践:
优化数据库性能
Google Cloud 架构框架中的这一文档提供了一些建议,可帮助您优化 Google Cloud 中数据库的性能。
Cloud SQL
以下建议可帮助您优化运行 SQL Server、MySQL 和 PostgreSQL 数据库的 Cloud SQL 实例的性能。
- 对于 SQL Server 数据库,Google 建议您修改特定参数并保留某些参数的默认值。
- 为 MySQL 或 PostgreSQL 数据库选择存储类型时,请考虑 SSD 和 HDD 存储空间之间的费用性能权衡取舍。
- 如需确定和分析 PostgreSQL 数据库的性能问题,请使用 Cloud SQL Insights 信息中心。
- 如需诊断运行 SQL 查询时性能不佳的问题,请使用
EXPLAIN
语句。
如需了解详情,请参阅以下文档:
Bigtable
本部分提供了一些建议来帮助您优化 Bigtable 实例的性能。
根据性能要求规划容量
您可以在多个应用中使用 Bigtable,每个应用具有不同的优化目标。例如,对于批量数据处理作业,吞吐量可能比延迟时间更重要。对于响应用户请求的在线服务,您可能需要优先考虑较短的延迟时间,而不是吞吐量。在规划 Bigtable 集群的容量时,请考虑吞吐量和延迟时间之间的权衡取舍。如需了解详情,请参阅规划 Bigtable 容量。
遵循架构设计最佳实践
表可以扩容到数十亿行和数千列,使您能够存储 PB 级的数据。为 Bigtable 表设计架构时,请考虑架构设计最佳实践。
监控性能并进行调整
监控实例的 CPU 和磁盘使用情况,分析每个集群的性能,并查看监控图表中显示的容量建议。
Spanner
本部分提供了一些建议来帮助您优化 Spanner 实例的性能。
选择一个主键以避免热点
热点是指单个服务器,它会被强制处理许多请求。为数据库选择主键后,请遵循架构设计最佳实践以避免热点。
遵循 SQL 编码的最佳实践
Spanner 中的 SQL 编译器会将您写入的每个声明式 SQL 语句转换为命令式查询执行计划。Spanner 使用该执行计划运行 SQL 语句。构建 SQL 语句时,请遵循 SQL 最佳实践以确保 Spanner 使用可获得最佳性能的执行计划。
使用查询选项来管理 SQL 查询优化器
Spanner 会使用 SQL 查询优化器将 SQL 语句转换为高效的查询执行计划。当查询优化器本身发生变化或数据库统计信息更新时,该优化器生成的查询执行计划可能会略有不同。通过使用查询选项,您可以在查询优化器或数据库统计信息发生变化时最大限度地降低性能下降的可能性。
直观呈现和调整查询执行计划的结构
如需分析查询性能问题,您可以使用查询计划可视化工具直观呈现和调整查询执行计划的结构。
使用操作 API 来管理长时间运行的操作
对于某些方法调用,Spanner 会创建长时间运行的操作,可能需要大量时间才能完成。例如,恢复数据库时,Spanner 会创建长时间运行的操作来跟踪恢复进度。为了帮助您监控和管理长时间运行的操作,Spanner 提供了操作 API。如需了解详情,请参阅管理长时间运行的操作。
遵循批量加载的最佳实践
Spanner 支持多种用于批量加载大量数据的选项。批量加载操作的性能取决于分区、写入请求数和每个请求的大小等因素。为了高效地加载大量数据,请遵循批量加载最佳实践。
监控和控制 CPU 利用率
Spanner 实例的 CPU 利用率可能会影响请求延迟时间。后端服务器过载可能会导致较长的请求延迟时间。Spanner 提供了 CPU 利用率指标来帮助您调查高 CPU 利用率。对于性能敏感型应用,您可能需要通过增加计算容量来降低 CPU 利用率。
分析和解决延迟时间问题
当客户端对 Spanner 进行远程过程调用时,客户端库首先会准备 API 请求。然后,该请求会经过 Google Front End 和 Cloud Spanner API 前端,然后再到达 Spanner 数据库。如需分析和解决延迟时间问题,您必须衡量和分析 API 请求遍历的每段路径的延迟时间。如需了解详情,请参阅 Spanner 端到端延迟时间指南。
在数据库达到热状态后启动应用
随着 Spanner 数据库不断增长,它会将数据的键空间划分为分块。每个分块是一系列行,其中包含表的子集。如需平衡数据库的整体负载,Spanner 会单独动态移动各个分块并将其分配给不同的服务器。当分块分布在多个服务器上时,数据库会被视为处于热状态。处于热状态的数据库可以最大限度提高并行性并提升性能。在启动应用之前,我们建议您先使用测试数据负载预热数据库。
后续步骤
查看优化计算、存储、网络和分析资源的性能的最佳实践:
优化分析性能
Google Cloud 架构框架中的这一文档提供了一些建议,可帮助您优化 Google Cloud 中分析工作负载的性能。
BigQuery
本部分提供了一些建议来帮助您优化 BigQuery 中查询的性能。
优化查询设计
查询性能取决于查询读写的字节数以及槽之间传递的数据量等因素。为了优化 BigQuery 中查询的性能,请应用以下文档中介绍的最佳实践:
高效地定义和使用具体化视图
为了提升使用常见和重复查询的工作负载的性能,您可以使用具体化视图。您可以创建的具体化视图的数量存在限制。请不要为查询的每个排列都创建一个单独的具体化视图。而是定义可用于多种查询模式的具体化视图。
提升 JOIN
性能
您可以使用具体化视图来降低基于 JOIN
执行聚合的查询的费用并缩短延迟时间。设想一种场景,您要联接一个包含几个较小维度表的大型事实表,然后基于联接执行聚合。切实可行的做法是重写查询,首先基于事实表执行聚合(将外键用作分组键)。然后,将结果与维度表相联接。最后,执行聚合后操作。
Dataflow
本部分提供了一些建议来帮助您优化 Dataflow 流水线的查询性能。
创建和部署流水线时,您可以配置执行参数,例如应该用于 Dataflow 工作器虚拟机的 Compute Engine 机器类型。如需了解详情,请参阅流水线选项。
您部署流水线后,Dataflow 会管理运行作业所需的 Compute Engine 和 Cloud Storage 资源。此外,Dataflow 的以下功能有助于优化流水线的性能:
- 并行处理:Dataflow 会自动对数据进行分区,并将工作器代码分布到 Compute Engine 实例以进行并行处理。如需了解详情,请参阅并行处理和分布。
- 优化:Dataflow 会使用流水线代码创建一个执行图来表示流水线中的 PCollection 对象和转换。然后优化此执行图以实现最高效的性能和资源使用率。Dataflow 还会自动优化可能产生高额费用的操作,例如数据聚合。如需了解详情,请参阅融合优化和组合优化。
- 自动调整:Dataflow 会在作业运行时使用横向自动扩缩、纵向自动扩缩和动态工作负载再平衡来动态优化作业。
您可以使用基于 Web 的监控界面或 Dataflow gcloud CLI 监控 Dataflow 流水线的性能。
Dataproc
本部分介绍了优化 Dataproc 集群性能的最佳实践。
自动扩缩集群
为确保 Dataproc 集群提供可预测的性能,您可以启用自动扩缩功能。Dataproc 使用 Hadoop YARN 内存指标和您定义的自动扩缩政策来自动调整集群中工作器虚拟机的数量。如需详细了解如何使用和配置自动扩缩,请参阅自动扩缩集群。
预配合适的存储空间
根据您的性能和费用要求,为 Dataproc 集群选择合适的存储选项:
- 如果您需要进行少量更改 Hadoop 和 Spark 作业即可在其中读取和写入数据的低费用的 Hadoop 兼容文件系统 (HCFS),请使用 Cloud Storage。存储在 Cloud Storage 中的数据是永久性的,可供其他 Dataproc 集群和其他产品(如 BigQuery)访问。
- 如果您需要适用于 Dataproc 集群的低延迟的 Hadoop 分布式文件系统 (HDFS),请使用挂接到工作器节点的 Compute Engine 永久性磁盘。存储在 HDFS 存储空间中的数据是瞬时性的,存储费用高于 Cloud Storage 选项。
- 如需获得 Compute Engine 永久性磁盘的性能优势和 Cloud Storage 的费用和耐用性优势,您可以结合使用这两种存储选项。例如,您可以将源数据集和最终数据集存储在 Cloud Storage 中,并为中间数据集预配有限的 HDFS 容量。在确定 HDFS 存储空间的磁盘大小和类型时,请考虑永久性磁盘和本地 SSD 部分中的建议。
缩短使用 Cloud Storage 时的延迟时间
为了缩短访问 Cloud Storage 中存储的数据时的延迟时间,我们建议您执行以下操作:
- 在 Dataproc 集群所在的区域中创建 Cloud Storage 存储桶。
- 为存储在 Cloud Storage 中的 Apache Hive 管理的表停用
auto.purge
。 - 使用 Spark SQL 时,请考虑使用最新版本的可用映像创建 Dataproc 集群。通过使用最新版本,您可以避免可能保留在旧版本中的性能问题,例如 Spark 2.x 中
INSERT OVERWRITE
性能缓慢。 - 为了最大限度地降低将多个大小不同或较小的文件写入 Cloud Storage 的可能性,您可以配置 Spark SQL 参数
spark.sql.shuffle.partitions
和spark.default.parallelism
或 Hadoop 参数mapreduce.job.reduces
。
监控并调整存储负载和容量
挂接到 Dataproc 集群中的工作器节点的永久性磁盘用于保存shuffle 数据。为了实现最佳性能,工作器节点需要足够的磁盘空间。如果这些节点没有足够的磁盘空间,则会在 YARN NodeManager 日志中被标记为 UNHEALTHY
。如果发生此问题,请增加受影响节点的磁盘大小,或同时运行较少的作业。
启用 EFM
工作器节点从正在运行的 Dataproc 集群中移除后(例如由于缩减或抢占),shuffle 数据可能会丢失。为了在此类情况下最大限度地缩短作业延迟时间,我们建议您为使用抢占式虚拟机的集群启用增强的灵活性模式 (EFM),或者仅自动扩缩辅助工作器组。
后续步骤
查看优化计算、存储、网络和数据库资源的性能的最佳实践:
架构框架的新功能
本文档列出了 Google Cloud 架构框架的重大更改。
2023 年 11 月 28 日
2023 年 11 月 9 日
- 系统设计类别:
- 新增了帮助云架构师为 Google Cloud 中的工作负载选择部署原型的指导。
2023 年 9 月 8 日
费用优化类别:
- 新增了有关使用标记进行费用分配和治理的信息。
- 更新了有关确定标签异常的指导信息。
如需了解详情,请参阅使用标记或标签跟踪和分配费用。
2023 年 8 月 28 日
- 系统设计类别:
- 更新了 Google Cloud 中的 AI 和机器学习服务列表。
2023 年 8 月 23 日
- 费用优化类别:
- 新增了有关如何使用处理单元(而不是节点)优化小型工作负载的 Spanner 资源用量的指导信息。
2023 年 8 月 18 日
- 安全性、隐私权和合规性类别:
- 新增了与 HIPAA 相关的指导信息。
- 卓越运营类别:
- 更新了规划高峰流量事件的最佳实践。
2023 年 8 月 9 日
2023 年 7 月 13 日
- 系统设计:
- 将 AlloyDB for PostgreSQL 添加到了 Google Cloud 中的数据库服务列表中。
- 费用优化:
- 在 Persistent Disk 部分中新增了有关 Google Cloud Hyperdisk 和本地 SSD 的指导信息。
2023 年 6 月 23 日
- 性能优化:
- 新增了有关使用巨型帧和虚拟机的相应机器类型优化带宽用量的指导信息。
2023 年 6 月 15 日
- 安全性、隐私权和合规性:
- 新增了有关使用 Cross-Cloud Interconnect 来保护与本地和多云环境的连接的指导信息。
- 新增了有关使用防火墙政策和规则以及安全 Web 代理来保护云工作负载边界的指导信息。
2023 年 3 月 30 日
2022 年 9 月 16 日
- 性能优化类别的重大扩展。
2022 年 8 月 10 日
2022 年 8 月 4 日
在费用优化类别中添加了以下功能的相关信息:
通过锁定项目与其结算账号之间的关联,防止由于结算问题而导致服务中断。如需了解详情,请参阅配置结算账号访问权限控制。
使用 Service Usage API 减少配额。如需了解详情,请参阅预算、提醒和配额。
识别并移除无人参与的项目。如需了解详情,请参阅 Active Assist 建议。
2021 年 7 月 13 日
2022 年 6 月 27 日
- 在安全性类别中添加了有关 Google Cloud 中的共担责任和共同命运体的信息。
2022 年 6 月 13 日
2022 年 6 月 1 日
- 在优化费用:计算、容器和无服务器部分中增加了有关 Spot 虚拟机的信息。
2022 年 5 月 7 日
- 在 Cloud Storage 的费用优化最佳实践中增加了有关双区域位置的信息。
2022 年 5 月 4 日
增加了产品可靠性指南。这些指南包括以下产品的可靠性最佳做法:
2022 年 2 月 25 日
2021 年 12 月 15 日
2021 年 10 月 25 日
可靠性类别中的更改:
- 添加了跨区域复制数据以用于灾难恢复和设计多区域架构以灵活应对区域级服务中断的最佳做法。
- 添加了如何计算错误预算的示例。
- 添加了为应用和服务选择好的名称的最佳做法。
2021 年 10 月 7 日
- 所有类别的重大刷新。
-
Anna Berenberg and Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 ↩