与“十“俱进 阿里数据库运维10年演进之路

导语
阿里巴巴集团拥有超大的数据库实例规模,在快速发展的过程当中咱们在运维管理方面也在不断的面临变化,从物理器到容器、从独占到混布、从本地盘到存储计算分离、从集团内到大促云资源,从开源的MySQL到自研分布式数据库,运维管控进行了自我革新与进化。前端

做者——谭宇(花名:茂七),阿里巴巴高级技术专家。2009年加入阿里,对分布式系统和数据库领域有很大的兴趣。目前负责阿里巴巴集团数据库中台建设,支撑了集团数据库在容器化、存储计算分离、在离线混部、大规模迁移建站以及智能运维等技术探索与落地。算法

本文梳理了阿里巴巴数据库运维发展历程以及对将来数据库自治时代的见解,期待与诸位一块儿讨论。数据库

正文
我在阿里快十年了,前五年作一些分布式系统开发相关的工做,参与的系统包括TFS/Tair/OceanBase,后五年聚焦在数据库运维平台及服务的建设,从搭建数据库集群、数据采集等底层运维到外部客户服务、POC支持等都有所经历,好的想法从来稀少,外加我的天资愚钝,不敢说有什么首创的想法,都是实践过程当中的一些感悟,且与你们分享,也是对过去一段时间的总结。网络

关于阿里的数据库,你们可能已经据说过不少,阿里巴巴数据库技术的发展与整个集团的技术发展相似,从商业到开源再到自主研发。早在09年之前,阿里巴巴数据库或DBA团队已经在业界很是知名,拥有多名Oracle ACE / ACE Director,外加自发性的与业界的交流、分享以及著做,构建了很是强的影响力,不少人所以吸引而加入,这是一段荣耀时光,当时不少知名人物如今有的在创业、有的仍在集团不一样的领域奋斗,江湖中仍然能够搜索到他们的传说。架构

后来就是轰轰烈烈的去IOE运动了,刚入职时常常在内部BBS上看到各类成功去除Oracle的帖子,基本套路就是DBA和业务开发一块儿配合,经过各类脚本把数据迁移到MySQL上。在这个过程当中,遇到过不少问题,也在积极寻求各类新的技术,好比为了突破磁盘性能问题,在当时主流的仍是机械硬盘的时候,使用了Fusion-IO等,也在MySQL内核上开始各类改进,造成了AliSQL。并发

关于去IOE、各自数据库内核技术、支撑的业务这些方面,讲的不少,你们能够搜到各自技术相关的文章,但不多有人讲过这背后有一个什么样的平台来支持这些业务变化以及技术迭代。过去的5年里,我和个人团队一直在作数据库运维或者是服务方面的事情,很难,我相信各位若是有作过这方面经验会感同身受。框架

一方面,这是运维类或服务类系统的“原罪”,这类系统造成初期,它只是一个工具或一个平台,使命是支撑好业务,本身并不实际产生价值。全部的技术要在这里落地,等落完地好像和你又没什么关系,价值感比较弱。今天K8S等系统的出现说明这个也能够作得很好,但相对来讲这是一个更难作好的领域。less

另外一方面,业务的复杂性、技术栈的多样性以及所依赖的组件决定了这个系统在实现层面很难,你须要把各个组件一层一层的串联起来。从业务访问到数据库内核再到底层的网络、存储、OS、硬件等,任何一个层面出了问题都会集中反应到你的系统中,实现人员面临着从上到下各个层面问题的理解、异常的处理,对团队及我的能力要求极高。运维

一个很具体的例子,咱们的运维系统涉及了前端、大数据处理、算法、数据库、底层软硬件等各个技术领域。在最初期团队不可能有各个领域的专家,须要每一个同窗了解并解决不一样的领域的问题。机器学习

我想就这些方面,系统性地跟你们介绍一下咱们所作的一些工做。主要包括三个方面:第一,咱们整个系统的发展历程,所谓从历史看将来,不知道过去,没法推断出将来咱们的样子。第二,现阶段的技术和产品,好比咱们如何支撑咱们现有的工做,双11大促等。第三,从过去和如今出发,咱们将来一段时间要到达的样子。

  1. 从历史看将来

阿里巴巴数据库运维发展的历程,主要有这几个阶段。09年之前,以商业数据库为主,去IOE也才开始。以前没有总体运维规划、运维平台。使用了各种脚本、工具。

在09年之后,因为规模迅速膨胀,这个时候天然产生了一些工具团队,把各种脚本拼在一块儿,弄个界面,造成了最初的产品。

接着,随着复杂度进一步增长,以及云计算的推进。交付方面有了更高的要求,造成了服务化,好比DBaaS等。

近年来,随着大数据、机器学习等技术的发展,AIOPS催生智能化。在智能化的基础之上,对各种服务平台的服务质量的进一步要求,也就是自治。

图片描述

整体来说,有两次比较大的革新。

第一次是从产品化到服务化。最初,咱们的产品造成很是简单。没有什么平台,没有什么系统,你们一边干活一边沉淀一些脚本,处处分发。随着规模的增加,原来的那套脚本须要管理起来了,我相信不少团队最开始都会设立一个工具组,专门来干这个事情。这就会演变成一个团队作工具,另外一个团队来使用,慢慢的二者之间的GAP就出现了。工具团队有工具团队的KPI,业务团队有业务团队的KPI,分歧会逐渐增大。

另一个问题则是你们都在攒工具,攒平台。结果这些平台之间是相互不能通讯的。好比一个应用开发,须要数据库、搜索、分布式存储等各个系统,开发人员须要去逐个申请,效率不高。

服务化的变革就是在这种状况下发生的。咱们不提供工具、平台,而提供服务。这些服务之间相互打通,而且咱们对提供的服务有相关SLA保证。此次革新能够说是云计算的基础,云计算的本质是IT资源交付技术的进步,这是云计算带给咱们的最大价值。

图片描述

第二次革新是自治,咱们目前正处于此次革新中。

对SLA或者服务质量的追求是没有止境的。如今很火的Cloud Native、Serverless本质上都是对更高服务质量的一种追求。要提高服务水平,关键点有两个,一是规模,规模大了才能作更多事情,好比混合部署、智能调度、机器学习,都要求必定的规模和大量的数据。这也符合当前提供基础服务的云计算趋于集中的趋势。

规模也是问题的根源,管理一千个实例和十万个实例所需的技术彻底不同,因此另外一个关键点是技术水平,有了规模还必须有相应的技术,好比容器化、机器学习、存储计算分离、RDMA网络等技术的提高。

图片描述

  1. 理想照进现实

固然技术的积累是一个长期的过程,积累到必定程度就会引发质变。咱们这些年在系统建设、技术积累方面所作了许多工做。先来看一组数据,这是刚刚过去的双十一数据库相关的一些状况。

你们可能看过一些数据,好比成交额,交易峰值。对于背后的数据库而言,每秒有超过5000万次的访问。特别是在高峰期,读写比是和平时不同的。一般通常系统读写比大约是9:1或者7:1。但在双11高峰时,数据库的读写比多是2:1。在写入比例极高的状况下,要求数据库不能出现任何抖动或者延迟,咱们对任何一种新技术的引入都很是严格。

另外,阿里巴巴大促场景很是复杂,包括线上线下以及海内外多种场景。基础设施分布在全球多地,数十个机房同时支撑,系统复杂性很是高。

总结来看,咱们的业务场景大体有如下几个特色:

业务多样性。做为数据库中台,数据库团队要支撑集团全部业务。包括核心电商、线下新零售场景以及各个独立子公司。各类场景对数据库的要求也不同,好比线上场景就要求高并发低延时,故障快速恢复。线下场景则要求绝对可用,并且接入及使用数据库的方式都不受控制。而新加入阿里体系的收购公司,有原来的运维体系,要求他们作改变也不太现实。总之需求的多样性对数据库的要求很是高。
基础设施多样化,数据中心分布在全球,有的用公有云、有的有自建机房,有的用物理机,有的用Docker、用弹性计算等,整个集团就是一个超级大的混合云。
双11超级大热点,除了成本和性能方面,双11在弹性方面有很高的要求。咱们也不可能为双11买这么多机器,那太浪费了。早期,会在不一样的业务线之间进行拆借,好比借云的机器或者借离线的机器,大促后归还,全靠人肉搬机器。整个大促周期很是长,人力成本和机器成本都很高。
图片描述

针对以上状况,咱们造成了以下架构。主要思路是向下层屏蔽差别,向上层提供多样化服务能力,中间围绕着弹性、稳定性、智能化进行建设。

图片描述

早期的运维系统由于各类缘由,没有设计好的架构致使难以扩展,最后愈来愈臃肿,推翻重构的事情并很多见。现今,咱们设计了服务化的运维系统总体架构:

一来能够清晰地理顺系统各个模块之间的交互方式并标准化,完全解决原来工具时代遗留下来的各自为政,各个功能散落在不一样地方的问题,整个系统的发展再也不背负历史包袱;
二来能够解决技术栈太多的问题,从前端到底层采集、算法分析,咱们不可能统一成一个框架、一种语言。让这些模块能互不影响、互相交互,是整个系统能作强的基础;
三来能够将整个系统的数据集中起来,为后续智能化所须要的统一数据、统一算法提供基本要素;四来能够向外提供统一形式、功能多样化的服务。要想作好作强一个服务类的系统,服务化是第一步。
在底层,咱们作了统一的资源调度层,用来屏蔽底层计算、存储、网络资源的差别,向上交付标准的容器。

中间是数据库层。由于业务的多样性,数据库类型多种多样,运行在不一样的环境,咱们经过统一的命令通道和采集通道的抽象来屏蔽这些差别。

再往上是传统的数据库运维层,包括常见的数据库的生命周期管理,咱们称之为Lego,但愿OPS这样的基础功能能像乐高同样百变组合,迅速搭建咱们想要的功能。还包括数据采集、处理存储的模块Kepler,咱们但愿把全部的运行数据实时采集到,而后经过大数据处理、机器学习等手段发掘出深层价值,采集的数据包括OS、网络、存储,数据库的SQL流水、性能指标等等,整个处理的数据量很是大,而且全部指标都要求是秒级的。每秒都要处理超过100G的原始报文。

再往上是智能决策层,这一层完成自动修复与优化的工做,好比预期内的故障,异常处理。也经过采集到的数据,作一些分析和决策。

咱们把整个系统的功能以服务的形式提供出来,你们能够在这个基础之上定制想要的功能。过去几年,咱们在架构实现方面一直坚持“一个平台、一套架构,集团孵化、云上输出”的策略,集团内部数据库管控平台提供服务,全部模块在一套架构下实现,产品在集团检验后开始在云上输出。不一样的时期有不一样的坚持,在智能化时代,咱们对这个架构及策略也有所调整,这个在后面会说起。

解决架构问题后,咱们过去两年主要围绕几个能力进行建设,一是容器化与存储计算分离,二是快速弹性与混部的能力,三是规模化交付与智能运维,这几项工做都是今天可以发展成为集团数据库中台以及支撑双十一的关键能力。

图片描述

第一,容器化是技术的量变到质变,容器并无不少开创性的技术,各类技术合在一块儿开辟了新的思路。因此在把数据库放到容器里首先要突破咱们的运维思路,坚决能够把数据库放到容器里的这个想法。固然这个过程当中也遇到过稳定性和性能问题,好比网络在使用bridge模式的时候,会有些CPU的增长。

最终在网络团队不断优化后,基本能够作到与物理机持平。容器化一方面解决了不少环境问题,另外一方面也为数据库的调度提供了可能,咱们从16年开始作数据库容器化,到今年,绝大部份的数据库都跑在了容器里。

图片描述

第二,存储计算分离。其实数据库最开始就是存储计算分离架构的。在互联网时代,这个架构在最初遇到了瓶颈,由于互联网时代的容量扩张很是快。而后出现了分布式系统,把计算搬到数据所在的地方。可是随着技术的发展,特别是云的交付方式,存储计算分离的交付则更为便捷。交付多少计算能力,交付多少存储,一目了然。

另外,存储和计算的发展也不太均衡,好比双11的时候,我要求的是计算能力,其实存储并无增长多少。因此随着技术的发展,咱们这一圈基本上又转了回来。固然存储计算分离要不要上,咱们也是通过了很长时间的讨论,今天来看,上存储计算分离这个决定是对的。在这个过程当中也遇到不少问题,主要是延迟的问题,毕竟通过一层网络,IO时间是有增长的。

咱们最开始上了左边这个架构,将远程存储挂载到本地,这个延迟要较本地盘大不少,核心业务难以接受,在这个基础之上,咱们大规模引入RDMA网络,经过DBFS bypass掉kernel,延时基本能和本地盘至关,因此今年全部的核心业务就跑在了这个架构上。

有了容器化和存储计算分离的基础,就能够比较好的解决弹性问题了。以前咱们的弹性主要靠搬数据加搬机器,如今数据能够不用搬了。咱们大促所用的机器主要来自两个地方,一个是离线资源,另一个是云资源,咱们用完以后云能够继续对外售卖。

你们知道,双11的高峰期主要在零点时段。因此咱们在高峰期来的时候弹性扩容,高峰期结束当即缩容,还机器给别人用。咱们结合集团的调度,作了一套混部调度系统,能够作到数据库快上快下,今年咱们的核心集群10分钟就能够完成弹性扩缩,而咱们最终的目标是在1分钟内完成。

图片描述

第三,交付和诊断。咱们说云计算是IT资源交付能力的进步。咱们基本完成了向用户交付数据库资源,开发人员能够经过系统自助完成数据库资源的申请与使用。若是只是把交付理解为用户自助获取数据库资源的话,咱们已经完成得很好了。

但集团有更严苛和复杂的交付任务。好比下面两个例子:大促时须要在上十万个数据库实例里扩容数千甚至上万个实例,大促完成后还须要缩容回来。每一年有固定的或临时的建站、迁站等操做,例现在年的一路向北和上海、张北屡次建站,可能会涉及到数万数据库实例及数十PB数据,这些都很是考验咱们交付的能力。

以前的常规作法是让人来评估,肯定好操做的数据库范围,算好须要多少机器资源,如何摆放等,再经过咱们提供的迁移操做来完成。人须要来控制其中的每个步骤,这是一个至关繁琐的工做。每一年都要作那么几回,在咱们今天要求快上快下的时候就显得特别力不从心。

因此咱们提出软件定义部署的概念,相似常说的编排。主要作两个事情,一是把咱们的这些操做都精肯定义和记载下来,线上的运行环境也能用代码精肯定义出来。二是把中间的腾挪步骤交给系统,人只须要描述最终的状态,在咱们预测准确到必定程度后,这个最终描述状态也能够由系统来完成,真正的完成大促自动化交付。

图片描述

能够看到,咱们的链路其实很长,中间的各个组件出了问题诊断是一件很难的事情。Gartner有一个名词叫AIOPS,相信你们都据说过,其实Gartner提出AIOPS很早,最开始指的是基于算法的OPS,随着AI技术的发展呢,他顺势把这个词的写法给改了,但本质上没有变,仍然是依托大数据、算法来改变OPS。

应该说这也是个朴素的概念,咱们在差很少时刻也提出了这个想法,最开始叫作数据驱动,后来更名为运行数据与数据运营,也是经过各类算法,好比基线、异常检测、关联分析、趋势预测等等来自动决策或辅助咱们决策。

图片描述

这即是CloudDBA的初衷,先把各类采集到的数据汇聚统1、预处理再加上领域知识和算法,打通从用户到DB,从DB到底层硬件这两个链路。在双11的时候也能实时的诊断访问链路。固然这里待挖掘的还很是多,如今咱们能够说只应用了很是小的一部份。

最后,我把以前讲的这些都融进了一个产品HDM,全称是混合云数据库管理平台。Gartner有一份报告指出,到2020年的时候,有85%的企业会使用混合云的架构。这和咱们的判断是一致的。以前提到过,阿里巴巴集团就是一个超大的混合云,因此咱们推出了HDM,帮助企业把混合云数据库架构打通。

图片描述

HDM主要提供两大功能,一是统一管理,无论是云上的仍是云下仍是其余云的数据库,均可以进行统一管理与诊断。二是弹性扩展,一键把数据库上云也再也不是梦想。在数据库层消除本地IDC和云的区别。

在提出HDM后一段时间里,我一度认为这基本上就是数据库服务的将来了。但这些年,无论是数据库领域,仍是运维领域,都在飞速的向前发展,咱们彷佛又到了一个技术集中爆发的时间点。一方面是新的软硬件技术,好比容器、高速网络,机器学习,另一个是云计算的发展,都在不断的推进咱们向前,提供更好的交付及服务。

  1. 通往智能之路:自治数据库平台

在数据库领域,有自治数据库、智能数据库,在运维领域,有AIOPS等等。这对数据库运维来讲到底意味着什么,咱们结合过去和如今的状况,提出了自治数据库平台。这个定义是不少人一块儿讨论了好久才定出来的。

图片描述

首先是平台的能力和目标,咱们但愿能作到自动驾驶,简单的说就是不须要人的参与。要作到这个,就要具有自感知、自决策、自恢复、自优化四大能力。其次是平台能为数据库赋能,今天的现状是咱们用了不少种数据库,不能对每一个数据库有很高的要求才能自治,咱们能够进行能力分级。

咱们也有很是明确的业务目标,这是阿里数据库事业部掌门人公开的目标:在2020财年结束的时候,阿里集团85%的数据库实例要能作到自动驾驶。我为此定了两个评估指标,一是没有人接收这些数据库的报警,另外一个是稳定性要达到99.995%。

目标有了,具体怎么实现?首先,自治是一个技术的量变到质变的过程。在过去的一段时间里,咱们应用了大量的新技术,包括存储计算分离,大数据处理与机器学习等等,掌握好这些技术是自治的基础。

有了这些技术,还须要革新咱们的思路,就像今天的电动汽车或自动驾驶,由传统厂商来制造,都显得差强人意,这一方面是思惟定势,另外一方面则是有它的历史包袱。

咱们须要破除这些,好比咱们以前的数据、运维、资源都是分割开来的,所谓自动处理都是先接收一个报警,而后根据报警的内容作自动化,这明显没办法造成一个统一的总体。今天咱们须要先去构建整个骨架,而后让数据、算法去丰富、去润滑整个系统。

另外还须要专业知识。数据库是高度专业的系统,以前可能由DBA、内核开发人员去调校,靠数据,靠试错,靠经验。这些知识如何精确化、数字化下来,让系统也具有这些能力,是咱们要去努力的事情。

最后,重要的一点是要持续提高原有的基础能力,不是说咱们今天智能化、自治化就是数据和算法,其余基础能力同等重要,好比OPS,咱们提出了一个ad-hoc执行:假如决策模块做出了一个决策是全网内存水位高于95%的数据库实例作一个action,你要可以很快执行下去。

图片描述

咱们目前正在向这个方向前进,预计很快咱们就会对一部份数据库实例实施自治,欢迎有兴趣的同窗加入一块儿建设,共同迎接自治时代的到来。