草庐IT

云原生时代数据库运维体系演进

Deng Song 2023-03-28 原文

首先,vivo自研了数据库运维平台DaaS来支撑数据库运维工作。在规模覆盖、效率提升、故障告警处理等层面均衡发力,保障了数据的稳定性,以工单自助,故障自愈为核心,实现了数据库的高效运维。 

其次,在数据库资源弹性管理层面,vivo重视资源成本优化。围绕资源分配、资源弹性伸缩、资源隔离分别给出了智能化解决方案,并通过套餐自动优化,进一步降低了管理成本。

最后,基于个人隐私数据,平台也提供了对业务几乎无影响的MySQL的透明加密方案,来减轻因为隐私数据加密带来的研发和运维工作量。

一、云原生时代数据库运维挑战

1.1 数据库运维体系演进

从数据库运维体系的演进历程来看,

1、2000年左右,PC互联网时代兴起,商业数据库是市场主流,而开源数据库方兴未艾。普遍的数据库运维方式,还是人工加脚本,当时大部分公司数据库规模量相对不大,这样做完全够用。人们面临的主要运维挑战是商业数据库软硬件成本高,而开源数据库软件和配套工具不成熟,通常要自研来满足开源数据库自身的稳定性和扩展性要求,门槛高。

2、到了2010年左右,移动互联网时代兴起,社会数字化进程陡然加速,数据量规模大增。此时,一个针对IT基础设施的革命性的概念提出来了,那就是云计算,简单来说,就是通过网络的方式提供服务器,数据库,或者某种软件服务资源。在数据库运维领域,则自然衍生出了云计算的一个分支概念,DaaS,data as a service,数据库的运维方式因此由人工脚本方式转变为了数据库平台的方式。同时,随着开源数据库技术以及各种周边生态软件走向成熟,开源数据库得到了广泛应用。这时,数据库运维的挑战变成了如何高效率交付资源,保障数据库稳定性,做好数据库成本优化。

3、到了2020年左右,后移动互联网时代,社会数字化程度进一步加深。云原生的概念被提了出来。微服务架构,资源弹性,容器等云原生技术广为传播。数据库的稳定性方面,因为开源数据库的高可用体系普遍成熟而大大缓解。数据库规模方面,实例数量和品类都进一步大增。数据库安全方面,2021年8月我国正式出台了个人信息保护法,个人隐私数据保护成为了数据库运维的时代重点。

1.2 云原生时代挑战

这样的时代背景下,我以为数据库运维主要有三个方面的挑战

  1. 云原生时代应用架构普遍微服务化,一个系统拆成多个微服务,这个系统的数据库也分拆成多个。这导致数据库实例成倍增加,数据库的运维工作量也成倍增加。因此大规模数据库实例如何有效运维?这就是第一个挑战。
  2. 云原生理念应用架构层面的弹性伸缩,自然也要求数据库层面做到弹性伸缩。具体来说,是效率上做到快速扩缩,业务无损,成本上也要做到,按需按量使用。但是主流开源数据库本身是存算一体架构,这两点支持不容易。数据库如何做好资源弹性伸缩?这是第二个挑战。
  3. 数据库安全方面,个人隐私数据需要保护,这个必要性无需多说,但是怎么技术落地?怎么识别个人隐私数据,识别之后又如何进行数据加密。而开源数据库在这方面,即也没有具体的落地方案,没有提供专门的工具,这些都有待自己探索。这是第三个挑战。
挑战讲完了,接下来我们看下vivo在这三个挑战方向的应对。

二、vivo 大规模数据库实例高效运维

2.1 高效运维实践现状

vivo是自研了数据库运维平台DaaS来支撑数据库运维工作。

规模上,支撑了数万数据库实例的运维服务,包含了6种数据库:MySQL,Redis,MongoDB,Elasticsearch,TiDB5个开源数据库,1个公司内部自研的磁盘KV。

效率上,节省了92%的数据库运维工作量。月均数千的总工单量,其中92%都是无需运维参与,由平台用户自助执行。

故障告警处理上,70%的数据库告警实现自动分析或者处理,进一步解放了数据库运维人力,保障了数据稳定性。

综上所述,数据库高效运维的核心就是,工单自助,故障自愈。接下来将详细介绍这两点。

2.2 工单自助

首先看工单自助,要实现工单自助,主要有三点

  1. 95%运维操作平台化,用平台操作替代手工或者脚本操作。所谓平台化的本质,就是用代码的方式,将最佳的运维经验固化在平台中。这才是一切运维效率的基础。
  2. 99%工单成功率,一方面是要做到,所有运维操作都有工单流记录,这是运维工作量化和进步的基础;另一方面,因为异常的工单还是要数据库专业运维介入处理的,所以只有工单一键执行成功率达到99%以上才可以开放自助,才谈得上提升了效率。
  3. 部分开源数据库生态工具是空白的,例如常见数据库Redis 要数据变更自助,一方面需要做到变更过程业务无影响,这要求做好变革速度&负载控制,变更前排除大key等风险因素。另一方面还需要做到变更过程数据安全,这要求变更前做好备份,变更后可随时回滚。这些都没有现成开源工具集成,vivo是通过自研逐个填补了这些工具空白。

2.3 故障自愈

随着数据库规模的成倍增加,故障告警的数目也急剧增多,vivo日均数百数据库故障告警,存粹靠手工进行告警问题排查处理越来越不能满足数据库稳定性的要求。

数据库故障自愈的需求就被自然提了出来。故障处理简单分为:发现,定位,恢复 三个步骤,针对已经发生的故障我们反复分析确认,其中定位环节是最耗时,所以当前故障自愈系统主要做的就是故障分析定位的工作。整体上故障自愈主要是两个难点,一个故障自愈方案的确认,另一个是相关基础工具的开发。

通常认为故障自愈方案最好是全面信息采集+机器学习自动确认的,这样的方案具备普适性,也更有效率且准确。但是立足于团队和问题现状,我们认为当前的故障自愈方案可以是全基于运维专家经验确认的。这是因为在数据库运维方向,目前常见数据库相关故障场景不到50个,且变量因素单一,所以即便凭借优秀专家经验枚举处理办法,也能自动解决大部分故障,简单实用。另外在故障自愈的基础工具上,我们主要自研了:Redis流量分析,热key分析,MySQL 根因SQL分析等工具。

接下来介绍故障自愈的逻辑架构

整个系统是由故障告警驱动,系统获取到告警消息后去查找相匹配的预案,然后执行预案中设定的基础操作,包括分析操作和恢复操作,例如Redis流量分析或者MySQL binlog清理等,最终生成执行报告,其中包括中间状态的现场监控快照,智能的分析结果等,同时也提供案例标注的能力。最后执行结果会自动分配并通知到对应负责的数据库运维人员或者消息群组当中。

通过这套架构,最后实现了超70%的故障自动分析或者处理,包括至少30个基础能力建设,26个故障预案,10个故障场景全自动处理。

三、vivo 数据库弹性资源管理

3.1 资源弹性管理问题&现状

我们先来看vivo数据库资源管理上要面临的现状和问题

  1. 传统数据库占主流,从数量上看,线上数据库数万个实例,85%是REDIS,10%是MySQL,剩下5%是其它数据库。都是存算一体的传统数据库,弹性伸缩能力并不完美,例如开源Redis Cluster的弹性伸缩是单线程的,上了一定数据规模后其扩缩速度和稳定性都有待进一步提升。
  2. 当前数据库资源管理还没有容器化,数据库资源隔离得另想办法。同时对于Redis等传统数据库来说,容器化也不能解决其弹性伸缩的速度和稳定性问题,这些都只能从数据库软件本身上去解决。
  3. 目前数据库资源都是直接部署在物理机上,PB级数据直接部署在数千台物理机上,数据库成本问题比较敏感。

3.2 资源弹性管理主要实现点

针对上述问题,vivo数据库平台主要做了如下工作:

  1. 资源分配上,实行单机器多实例多版本多套餐混合部署,同类数据库资源池统一,提升资源利用率。
  2. 资源弹性伸缩上,自研多线程Redis Cluster扩缩工具,显著加速Redis Cluster扩缩容过程,同时增加限速,大key巡检,历史负载检测,脑裂检测等功能尽量增扩缩容稳定性。
  3. 资源隔离上,则采用两个措施。
    (1)程序配置实现隔离,如Redis,线程模型决定了几乎只消耗一个CPU核心,而内存占用也主要由配置决定,其它网络磁盘很少存在争用,所以混部就没隔离问题了。
    (2)通过巡检和容量预测的方式实现软隔离,尽量解决非突增的资源争用问题。

3.3 套餐自动优化

在资源成本优化上,除了刚才提过的混合部署,还可以做套餐自动优化,进一步降低成本。

下面介绍下具体的套餐自动优化流程

  • 第一步 平台自动扫描全网数据库实例,挑出其中被认定是满足缩容条件的。
  • 第二步 平台自动发送缩容工单交由实例对应的业务项目经理审批。
  • 第三步 根据审批结果执行缩容,或者放弃本次缩容。
大概在这个功能上线后的4个月内,平台自动发起超千次缩容,节省了超百T空间。

四、vivo个人隐私数据全链路保护

4.1 隐私保护数据库层面现状

在线数据库有数十万张“表”,总计超千万个字段,其中隐私数据识别覆盖100% ,涉及MySQL,MongoDB,Elasticsearch,TiDB四种数据库,人工抽查识别准确度79%。

而当个人隐私数据识别出来了,处理的主要手段就是加密,所以平台也提供了对业务几乎无影响的,MySQL的透明加密方案,来减轻因为隐私数据加密带来的研发和运维工作量。

4.2 全链路功能

隐私数据库保护应该是贯穿业务研发阶段,运营阶段的全链路保护。

  • 研发阶段:统一数据库建表入口,同时提供平台工具便于用户对新建表中的隐私数据字段进行标记,这主要解决日常新增数据结构的识别问题。
  • 运营阶段:定期扫描全网表结构数据,自动识别未标记的隐私数据,并人工抽查校准,这主要解决存量数据结构的识别问题,同时也是研发阶段识别的补充。
  • 运营阶段操作:数据查询结果中包含隐私数据自动加密显示.数据导出隐私数据时自动加密,并添加水印。

4.3 最后的防线:数据库加密

对于数据安全来说,数据库加密是最后一道防线。前面提到隐私数据识别出来了,那么加密的目标有了。基础加密算法业界也比较成熟,加密方式也不缺。唯一的问题是,加密的过程。

对于新增业务来所,加密过程比较简单,没有业务访问怎么做都行。但是对于存量的成熟业务来说,几十张表,数据规模千万记录都是常事,怎么加密还能不影响用户访问,就是个麻烦的问题。为了解决这个痛点,目前数据库平台提供了一个存量业务数据无损加密方案,因为主要隐私数据都在MySQL中,所以这是基于MySQL的。

首先介绍加密涉及的三个组件:数据库平台是用户操作入口,表结构变更工具gh-ost负责历史数据加密转化,MySQL代理负责让加解密过程对业务程序透明。

接下来介绍无损加密的主要流程

  • 第一步、用户要在数据库平台上配置需要加密的字段。如果不需要对历史数据加密那么整个加密配置流程就结束了。
  • 第二步、如果要加密历史数据,就会产生一个数据清洗工单,交给表结构变更工具gh-ost执行,具体过程就是新增一个密文列复制明文列数据并加密。然后MySQL代理会自动将明文列请求转向密文列,至此数据清洗完成。
  • 第三步、步骤2执行后,业务如果发现有问题,可以随时回滚。业务方认定数据加密后服务稳定时,就可以选择回收明文列,最后更新MySQL代理配置,去掉明文数据同步更新,整个加密过程就算完结,全程几乎无需业务改动代码,且对业务无损。

五、未来展望

5.1 故障处理

个人认为故障自愈的演进可以分为三个阶段:

  • 阶段一:专家经验式枚举故障自愈(这是当前所在的阶段)。
  • 阶段二:在阶段一基础上引入AI判断,形成AI判断为辅,专家经验为主的故障处理体系。
  • 阶段三:构建AI判断为主,专家经验为辅的自愈系统,进一步提升自动化程度。

3.2 资源管理

接下来在弹性资源管理这个方向,个人认为其发展可以分为三个阶段:

  • 阶段一:数据库混合资源管理(这是当前所在的阶段,套餐,版本可以混合)。
  • 阶段二:数据库容器混合资源管理,这一阶段主要是利用容器消除机型隔离,品类隔离,有助于更高密度资源部署以及套餐统一标准化的实现。
  • 阶段三:存算分离架构数据库的资源管理。在底层资源调度层面发挥到极致后,只能通过数据库架构本身的升级提升资源弹性。

5.3 隐私数据治理

在个人隐私数据这个方向,还有两个待解决的问题

  1. 第一个是,非结构化数据隐私自动识别和加密问题。结构化和半结构化数据,就是MySQL,MongoDB这种,通过字段的可以批量识别和处理一个表或者集合的隐私数据。但是对于Redis这种结构,当前一次只能识别和处理一个key-value键值对。解决思路是,非结构化转为半结构化数据,例如特定前缀key或者正则key,绑定固定的value结构。
  2. 第二个问题是,隐私数据的识别准确率问题,当前只有79%,这个目前思路是人工标注+AI识别。

5.4 数据库平台的未来展望

最后谈下数据库平台建设,概括来说8个字,统一标准,开源共建。

展开来说,如今的数据库技术市场百花齐放,DBengines网站榜上有名的数据库就有395种,单个系统构建依赖多个品类数据库的情况逐渐普及,通过统一的数据库平台来支撑数据库运维工作,几乎成了企业的刚性需求。但我们缺乏一个公认的跨品类的数据库运维标准,也缺乏一个主流的跨越多品类的开源数据库平台。

个人期望用这样的开源平台来承载数据库厂商,数据库生态工具开发者以及企业用户对数据库服务共建的诉求,加速数据库服务建设速度,让云原生时代没有难运维的数据库。

有关云原生时代数据库运维体系演进的更多相关文章

  1. ruby - 解析 RDFa、微数据等的最佳方式是什么,使用统一的模式/词汇(例如 schema.org)存储和显示信息 - 2

    我主要使用Ruby来执行此操作,但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式,例如使用这个yaml文件,它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i

  2. ruby - Ruby 有 `Pair` 数据类型吗? - 2

    有时我需要处理键/值数据。我不喜欢使用数组,因为它们在大小上没有限制(很容易不小心添加超过2个项目,而且您最终需要稍后验证大小)。此外,0和1的索引变成了魔数(MagicNumber),并且在传达含义方面做得很差(“当我说0时,我的意思是head...”)。散列也不合适,因为可能会不小心添加额外的条目。我写了下面的类来解决这个问题:classPairattr_accessor:head,:taildefinitialize(h,t)@head,@tail=h,tendend它工作得很好并且解决了问题,但我很想知道:Ruby标准库是否已经带有这样一个类? 最佳

  3. ruby - 我如何添加二进制数据来遏制 POST - 2

    我正在尝试使用Curbgem执行以下POST以解析云curl-XPOST\-H"X-Parse-Application-Id:PARSE_APP_ID"\-H"X-Parse-REST-API-Key:PARSE_API_KEY"\-H"Content-Type:image/jpeg"\--data-binary'@myPicture.jpg'\https://api.parse.com/1/files/pic.jpg用这个:curl=Curl::Easy.new("https://api.parse.com/1/files/lion.jpg")curl.multipart_form_

  4. 世界前沿3D开发引擎HOOPS全面讲解——集3D数据读取、3D图形渲染、3D数据发布于一体的全新3D应用开发工具 - 2

    无论您是想搭建桌面端、WEB端或者移动端APP应用,HOOPSPlatform组件都可以为您提供弹性的3D集成架构,同时,由工业领域3D技术专家组成的HOOPS技术团队也能为您提供技术支持服务。如果您的客户期望有一种在多个平台(桌面/WEB/APP,而且某些客户端是“瘦”客户端)快速、方便地将数据接入到3D应用系统的解决方案,并且当访问数据时,在各个平台上的性能和用户体验保持一致,HOOPSPlatform将帮助您完成。利用HOOPSPlatform,您可以开发在任何环境下的3D基础应用架构。HOOPSPlatform可以帮您打造3D创新型产品,HOOPSSDK包含的技术有:快速且准确的CAD

  5. FOHEART H1数据手套驱动Optitrack光学动捕双手运动(Unity3D) - 2

    本教程将在Unity3D中混合Optitrack与数据手套的数据流,在人体运动的基础上,添加双手手指部分的运动。双手手背的角度仍由Optitrack提供,数据手套提供双手手指的角度。 01  客户端软件分别安装MotiveBody与MotionVenus并校准人体与数据手套。MotiveBodyMotionVenus数据手套使用、校准流程参照:https://gitee.com/foheart_1/foheart-h1-data-summary.git02  数据转发打开MotiveBody软件的Streaming,开始向Unity3D广播数据;MotionVenus中设置->选项选择Unit

  6. 使用canal同步MySQL数据到ES - 2

    文章目录一、概述简介原理模块二、配置Mysql使用版本环境要求1.操作系统2.mysql要求三、配置canal-server离线下载在线下载上传解压修改配置单机配置集群配置分库分表配置1.修改全局配置2.实例配置垂直分库水平分库3.修改group-instance.xml4.启动监听四、配置canal-adapter1修改启动配置2配置映射文件3启动ES数据同步查询所有订阅同步数据同步开关启动4.验证五、配置canal-admin一、概述简介canal是Alibaba旗下的一款开源项目,Java开发。基于数据库增量日志解析,提供增量数据订阅&消费。Git地址:https://github.co

  7. ruby-on-rails - 创建 ruby​​ 数据库时惰性符号绑定(bind)失败 - 2

    我正在尝试在Rails上安装ruby​​,到目前为止一切都已安装,但是当我尝试使用rakedb:create创建数据库时,我收到一个奇怪的错误:dyld:lazysymbolbindingfailed:Symbolnotfound:_mysql_get_client_infoReferencedfrom:/Library/Ruby/Gems/1.8/gems/mysql2-0.3.11/lib/mysql2/mysql2.bundleExpectedin:flatnamespacedyld:Symbolnotfound:_mysql_get_client_infoReferencedf

  8. STM32读取串口传感器数据(颗粒物传感器,主动上传) - 2

    文章目录1.开发板选择*用到的资源2.串口通信(个人理解)3.代码分析(注释比较详细)1.主函数2.串口1配置3.串口2配置以及中断函数4.注意问题5.源码链接1.开发板选择我用的是STM32F103RCT6的板子,不过代码大概在F103系列的板子上都可以运行,我试过在野火103的霸道板上也可以,主要看一下串口对应的引脚一不一样就行了,不一样的就更改一下。*用到的资源keil5软件这里用到了两个串口资源,采集数据一个,串口通信一个,板子对应引脚如下:串口1,TX:PA9,RX:PA10串口2,TX:PA2,RX:PA32.串口通信(个人理解)我就从串口采集传感器数据这个过程说一下我自己的理解,

  9. SPI接收数据异常问题总结 - 2

    SPI接收数据左移一位问题目录SPI接收数据左移一位问题一、问题描述二、问题分析三、探究原理四、经验总结最近在工作在学习调试SPI的过程中遇到一个问题——接收数据整体向左移了一位(1bit)。SPI数据收发是数据交换,因此接收数据时从第二个字节开始才是有效数据,也就是数据整体向右移一个字节(1byte)。请教前辈之后也没有得到解决,通过在网上查阅前人经验终于解决问题,所以写一个避坑经验总结。实际背景:MCU与一款芯片使用spi通信,MCU作为主机,芯片作为从机。这款芯片采用的是它规定的六线SPI,多了两根线:RDY和INT,这样从机就可以主动请求主机给主机发送数据了。一、问题描述根据从机芯片手

  10. 微信小程序通过字典表匹配对应数据 - 2

    前言一般来说,前端根据后台返回code码展示对应内容只需要在前台判断code值展示对应的内容即可,但要是匹配的code码比较多或者多个页面用到时,为了便于后期维护,后台就会使用字典表让前端匹配,下面我将在微信小程序中通过wxs的方法实现这个操作。为什么要使用wxs?{{method(a,b)}}可以看到,上述代码是一个调用方法传值的操作,在vue中很常见,多用于数据之间的转换,但由于微信小程序诸多限制的原因,你并不能优雅的这样操作,可能有人会说,为什么不用if判断实现呢?但是if判断的局限性在于如果存在数据量过大时,大量重复性操作和if判断会让你的代码显得异常冗余。wxswxs相当于是一个独立

随机推荐