本文作者: 张显华、窦智浩、卢进文
与集中式架构相比,分布式架构的系统复杂性呈指数级增长,混沌工程在信创转型、分布式架构转型、小机下移等过程中有效保障了生产的稳定性。本文分享了 TiDB 分布式数据库在银行核心业务系统落地中进行混沌测试的场景设计和实践。
混沌工程是一种全面的测试方法,它覆盖了从应用层前端到底层硬件环境的所有环节,确保整个系统在面对各种异常和故障时的稳定性和弹性。本文将聚焦于与 TiDB 分布式数据库相关的混沌工程场景。
混沌工程和普通测试在软件系统工程中都扮演着重要的角色,但它们关注的质量属性和测试实施的方式存在明显差异。混沌工程更侧重于系统的健壮性和在面对异常情况时的响应能力,而普通测试则侧重于验证系统的功能正确性和性能指标。两者的差异详见下表:
在着手进行混沌测试的场景设计和实施之前,有几个关键问题需要我们深思熟虑:
首先,需要明确混沌测试的目标,希望通过测试掌需要关注的能力边界、容错能力、稳定性等。其次,选择合适的混沌测试工具,这些工具能够帮助我们在分布式环境中模拟各种故障和异常情况。接下来,精心设计测试用例,确保它们能够覆盖到可能影响系统稳定性的关键环节。最后,梳理总结混沌测试可能带来的收益,包括提高系统可靠性、优化故障恢复流程、增强团队对系统行为的理解等。通过这些环节的综合考量,我们可以更有效地实施混沌测试演练,为 TiDB 分布式数据库的稳定性提供坚实的保障。
TiDB 作为一款原生分布式数据库,其架构设计与银行系统中的传统集中式数据库相比具有显著的差异。银行核心系统对性能、稳定性、跨地域的高可用性都有着严苛的要求。为了满足这些要求,我们计划通过混沌测试来摸底性能边界、评估系统高可用性和容灾能力、验证系统的弹性、检验应急预案有效性、优化监控和告警机制、并准确评估外围作业的影响。
摸底数据库的能力边界,对上线后的运维工作具有重要的参考意义。一个新的业务系统在设计之初,不仅要满足当前的业务需求,还要考虑满足未来的业务发展需求,尤其是在极致稳定性要求下,银行核心系统的设计需要考虑未来 5 年至 10 年以上的业务发展需求。通过混沌测试,在总体设计的配置下,测试数据库的能力边界,将结果作为上线后运维的重要参考指标,并检验系统是否满足总设要求下未来业务的承载体量。
此外,通过混沌测试还可以发现整个业务链路可能存在的一些瓶颈点。
TiDB 的存算分离架构由核心组件和外围组件组成。核心组件包括 TiDB、TiKV、PD 和 TiFlash,用于处理计算和存储任务。外围组件包括 BR 和 TiCDC 等,用于满足备份、数据共享等业务场景的需求。这些组件可以单独部署或混合部署,以满足隔离性和资源利用率的平衡。
在银行核心系统中,常见的部署模式是两地三中心。通过混沌测试,可以在实际的部署架构下模拟各种故障场景,评估系统的高可用能力和灾备接管能力。测试结果可以提供每个场景或多场景组合下的 RTO 和 RPO 指标,并帮助识别应用连接恢复的健壮性和透明性问题,以及发现可能存在的访问链路瓶颈。
业务发展具有动态性,在突发的高流量高负载业务活动中,可能需要进行系统扩容以兼顾效率和稳定性。此外,X86 服务器相比小型机稳定性差、故障率高、生命周期短,需要通过扩缩容动作完成对硬件的升级和更换。基于这些因素,我们从两个维度对扩展性进行评估:
利用混沌测试中涉及的破坏性测试场景,对应急预案进行全面的检验和优化,为上线后的运行维护做好充分准备。
利用混沌测试,可以有效检验告警系统的有效性和准确性,并对告警进行全面的查漏补缺和优化。通过测试验证和持续优化,确保告警及时、准确、等级合理、避免过度冗余。
生产业务系统涉及数据库备份、统计信息收集、TiCDC 数据同步等外围作业,以及版本/补丁升级、重启、扩缩容、硬件替换、容灾切换等运维作业。混沌测试应关注此类作业对系统负载、业务指标、网络流量等方面的影响,并优化相关的作业窗口和并发度,确保业务平稳运行。
我们以某商业银行核心场景为例,使用 Chaosd 工具来进行混沌测试的场景设计和演练。Chaosd 组件 ( https://chaos-mesh.org/zh/docs/chaosd-overview/ ) 是 Chaos Mesh ( https://chaos-mesh.org/zh/ ) 提供的一款混沌工程测试工具(需要单独下载和部署 ( https://chaos-mesh.org/zh/docs/chaosd-overview/#下载和部署 )),用于在物理机环境上注入故障,并提供故障恢复功能。
Chaos Mesh 是 PingCAP 自主研发的开源云原生混沌工程平台,提供丰富的故障模拟类型,具有强大的故障场景编排能力,方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常,帮助用户发现系统潜在问题。
Chaosd 具有以下核心优势:
Chaosd 提供完善的可视化操作,旨在降低用户进行混沌工程的门槛。用户可以方便地在 Web UI 界面上设计自己的混沌场景,以及监控混沌实验的运行状态。你可以使用 Chaosd 模拟以下故障类型:
对于每种故障类型的详细介绍和使用方式,请参考对应的说明文档 Chaosd 组件简介 | Chaos Mesh ( https://chaos-mesh.org/zh/docs/chaosd-overview/ )。
混沌测试场景设计的原则是尽可能的模拟真实的生产情况。为了最大程度地模拟真实环境,测试的目标环境推荐使用准生产环境或按照生产环境设计要求搭建 1:1 仿真测试环境,并确保环境配置、部署架构、数据容量和业务负载等方面与预估上线后或系统设计要求一致。
测试从业务压力、故障注入、外围作业和运维操作等多个维度进行全方位测试,包括但不限于:
交易型业务压力
混沌测试建议采用真实业务模型,通过等比例的业务流量进行压测,或者有条件的采用流量回放( 生产环境流量需严格遵循安全管控流程,仅适用于生产域,且需进行脱敏处理 )的形式进行。对于项目前期无法基于真实业务模型进行压力模拟的情况,可以选择部分较为核心(或简化)的业务模型进行压力模拟。
如果上述条件均不具备,也可采用 sysbench 进行压力注入。由于 sysbench 与真实业务模型存在较大差异,对性能边界的评估意义有限,但基本不影响对高可用、容灾能力、扩展性、检验和优化监控告警等其他方面的验证结果。
对于注入压力的大小,建议按梯队逐层加压展开:
以上几个梯队可以按需进行,兼顾测试成本,不建议过度细分压力场景 。
对每个压力场景,记录各项基础环境和数据库实例级别的资源使用率、数据库 QPS/TPS、数据库 SQL 时延、端到端的业务时延、业务 TPS 等关键信息,建议将当时的压测场景结合关键的监控信息进行存档。以下登记表供参考(为方便展现,部分信息项简化合并):
批量业务压力
银行核心业务中的日终、日切、日结、报表等批量类业务,并发量大,负载高,需按照真实的用户量和总设要求的承载用户量分别进行压力测试。除了根据用户量维度施加压力外,还需关注此类业务的并发度、作业编排等方面,以探索最佳的业务实践。
长稳压测
长稳压测建议以交易型业务压力为主(总设要求的 TPS 指标压力),结合实际情况周期性注入批量业务压力,开展 7*24 小时长稳压测,全面验证系统整体的可靠性和稳定性。此外,长稳压测还可以有效发现一些容易被忽略的潜在问题,例如基础硬件的质量问题、配置是否合理、全链路中的脆弱点和性能瓶颈等。
其他场景
按需根据实际的业务特点扩展测试场景,针对性地进行验证。例如测试表数据量增长对 SQL 响应时延的影响:
针对 TiDB 的故障注入测试可以从实际部署架构和故障面积两个维度进行设计,本文以同城双机房双活的 DR Auto-Sync 架构 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#单区域双-az-部署-tidb ) (即 Data Replication Auto Synchronous,简称 DR Auto-Sync)进行介绍,其他部署架构的故障注入测试用例设计思路与此类似。故障注入和恢复后,需要关注的事项有:
以下故障注入跟踪表供参考(为方便展现,部分信息项简化合并):
建议采用分级故障注入策略,实例级故障注入时需要根据不同的实例角色进行,服务器级故障注入时需要结合部署架构(尤其是存在混合部署情况下)进行。
外围作业注入应关注相关作业对资源使用和 SQL 延迟的影响,并结合生产实际业务周期性变化的情况,优化作业窗口和并发度等配置。主要的外围作业包括全量物理备份、全量逻辑备份、BR log 备份(常驻作业)、统计信息收集和 TiCDC 数据同步(常驻作业)等。
运维操作注入是模拟真实运维操作对 TiDB 系统的影响,需要关注的事项与故障注入一致,部分运维操作场景和故障注入场景可能存在重叠,主要包括的场景有:滚动重启、 扩容(关注线性扩展比、对应用的透明度) 、缩容、补丁/版本升级、在线 DDL(增、删、修改字段、创建索引)和容灾切换等。其中,容灾切换需要模拟各类场景进行重点测试,如测试系统在计划内切换(主备机房不停机)和计划外切换(主备机房完全失联)场景下的表现。
DR Auto-Sync 架构 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#单区域双-az-部署-tidb ) 适用于同城双机房 RPO=0 的高可用容灾架构 (本系列后续文章将进行详细介绍,敬请关注)
该方案在同一区域部署两个 AZ (Availability Zone, AZ),以满足高可用和容灾要求,且成本更低 。下图为集群部署架构图:
该部署方案定义了三种状态来控制和标示集群的同步状态,该状态约束了 TiKV 的同步方式。集群的复制模式可以自动在三种状态之间自适应切换。
针对应用双机房部署的情况,通过混沌测试的场景设计,来验证 TiKV 和 PD leader 的最佳放置位置以及流量分发的最优链路,以期实现最佳的性能。如图所示,根据业务流量访问和数据 Leader 分布分别在单、双中心的四种场景组合进行测试,从而找到最佳方案。
混沌测试能够帮助我们全面了解系统的能力边界,为业务上线及后续的运维提供重要的参考依据, 具体包括:获得当前配置和部 署下数据库最高可承载的业务量,为容量规划提供指导;评估数据库的扩展能力,为未来的扩容提供指导;模拟各类故障对数据库服务能力的影响,进而验证和优化应急预案设计;模拟各类运维操作对数据库服务能力的影响,从而指导变更流程设计;模拟单表数据快速增长,评估对数据库性能的影响,并采取相应的优化措施。
实测结 果举例:
银行核心业务中,部分业务表(如交易流水表)数据量会随着业务办理而急剧增长,并需在生产集群中保留一定时间(超过一定周期转移到近线库,超过在线查询周期转移到带库存储)。这类表通常体积较大,银行客户基于对集中式数据库的使用经验,会担心单表数据量增长对性能产生影响。
为此,我们通过测试进行了验证。测试结果表明,单表数据(实测多张相关联业务表等比例增长)从百万级到 10 亿 急速增长的情况下,相关业务的 SQL 时延几乎不受影响,打消了客户的疑虑。如下图所示,短时间内少量业务流水表数据量急剧增长,相关业务 SQL 时延非常稳定,无明显变化。
混沌测试可以帮助我们发现系统全链路中的瓶颈点,从而进行针对性的优化,实现最佳实践。通过混沌测试,我们可以识别数据库部署架构和配置、负载均衡和探活配置、应用连接池和探活配置、双活架构下的数据库配置和流量分发、各类外围作业的时间窗口和并发度配置等方面存在的潜在问题,并进行相应的优化,例如调整数据库参数、调整流量分发规则、优化导入导出作业的并发度等。
实测结果举例:
混沌测试能够帮助我们全面了解数据库在不同故障情况下服务能力的变化,从而检验应急预案的有效性,并针对性地进行优化。
实测结果举例:
这里的 “应急预案”仅指故障场景中满足 SLA 情况下的应急,不包括集群整体健壮性或健康度的修复。
若兼顾健壮性或健康度的修复,还需要关注的事项:
常见的故障场景对于 TiDB 数据库服务的影响(下表中的 MTTR、业务影响比例受集群部署架构、故障实例个数、集群规模、业务负载特征、负载均衡探活策略等因素影响):
混沌测试可以帮助我们检验和优化监控告警,确保监控告警能够及时、有效地发现和识别系统故障。以下是一些对监控告警设置的建议:
过去一年,PingCAP 在金融行业场景累计完成数千个混沌演练测试,发现近百个问题。展望未来,PingCAP 将持续深耕金融行业,积极探索混沌工程在分布式数据库领域的应用,通过不断丰富的故障场景,结合故障诊断、根因分析等技术手段,做好故障沉淀积累,稳步提升 TiDB 处理异常事故及极端场景的应变能力,为金融业务稳健运行提供有力保障。