亚马逊云科技助力PingCAP构建高效能系统

关键字: [亚马逊云科技中国峰会2024, TiDB, 云存储优化, 计算资源利用, 网络流量控制, 分布式架构, 成本优化实践]

本文字数: 7500, 阅读完需: 38 分钟

导读

在亚马逊云科技中国峰会2024上,PingCAP的演讲者分享了如何在亚马逊云科技上构建高效能系统的思考和实践。演讲者解释了在云上开发时需要重新思考对计算机资源的假设,例如存储、计算和网络几乎是无限的。他们介绍了如何通过优化存储引擎、利用ARM实例和Spot实例等技术来降低成本,并分享了一个案例展示了成本降低了70%。演讲者还讨论了如何通过本地读取和数据集中等方式来降低网络成本,以及如何利用S3来提高吞吐量和降低跨AZ流量费用。最后,演讲者呼吁将亚马逊云科技视为一台计算机,并推广了TiDB Serverless这一云原生数据库解决方案。

演讲精华

以下是小编为您整理的本次演讲的精华，共7200字，阅读时间大约是36分钟。

大家好,这个感谢亚马逊云科技有给我这样一个机会能够来从这个作为一个亚马逊云科技用户的角度去吐槽的机会。

然后,对,因为首先介绍一下PingCAP,然后跟刚才这个数里行间的朋友不一样就是我们其实是其实也还挺相似的,也是这个在亚马逊云科技上去构建一个这个ToB的一个服务,但我们其实是做的一个数据库的一个服务。大家可能啊有的小伙伴PingCAP这个名字比较不太熟悉,但是我可能说到这个TiDB可能就大家就比较知道了,这可是一个开源的一个分布式的关系数据库。

对,其实我们在海外这边就主要的这个数据库的交付方式其实是云服务的,这个服务方式其实看起来有点奇怪是吧,这个亚马逊云科技也是云服务,这个TiDB诶怎么也是云服务啊,对没错,我所以我觉得亚马逊云科技还是很开放的,这我们其实是基于这个亚马逊云科技的云去做我们的这个数据库的一个云服务,所以这个里面就有两个视角:第一个视角就是我们本身作为这个亚马逊云科技的用户在去使用亚马逊云科技这些基础设施来去构建我们自己的云服务。第二个视角就是从那个我们的用户来看,他其实使用的是就是TiDB提供的这个服务,但底下可能我们把这个亚马逊云科技的一些这些服务给屏蔽掉了。

所以今天其实给大家讲的这个东西比较技术,但是我尽量讲得比较这个好玩一点,就是比较适合这个开发者就是我相信今天其实来听我是talk的大多数还是会写点代码的,所以希望今天这个聊完,大家回去这个在回头看自己的亚马逊云科技账单的时候,能够这个擦亮你的双眼,然后这个不要被这个对复杂的账单迷惑了。

所以其实在开始的时候,我想去让大家仔细思考一个问题,就是从一个软件工程师的角度来说,我个人觉得就是云其实改变了很多东西,其实改变了一些非常这个开发软件或者写程序时候的一些非常基础的假设,就比如说这个20年前我可能刚开始这个写代码的时候,我可能看到的东西就是一台计算机,比如说有多少个CPU,有多少内存,有多少磁盘是吧,就是我所有的资源就局限在我这一台计算机里边,然后但是最近这两年,尤其这两年开始去在云上去构建应用的时候,我发现就我原来对于这个计算机的一些基础的印象,我其实都慢慢地抛弃掉了,比如说我现在比如用S3,用其他的在云上的一些存储,我几乎是无限的空间是吧,就S3,我从来没想过它到底有多大,从来没有哪一个亚马逊云科技,这个告诉你诶,你最多只能存100个G,这个只要你有钱,反正你想存多少就存多少。

第二就是几乎你可以有无限的计算资源,比如说过去你可能在一台机制上,也就是那么这个两个socket,这个几十个CPU是吧,这了不得了,一个服务器,然后你开个线程可能开个这个100个线程是吧,这个就你的CPU可能就在那就很费劲了诶,但是你可能在云上,只要你有钱,你开1万个Lambda都没人管你,然后所以几乎是无限的计算资源,然后而且同时这个我觉得搞分布式系统,因为我本身的这个背景,其实做这个分布式系统出身的就是网络这个事情真的是非常费劲。但是亚马逊云科技这边,其实在你开箱的时候就已经基本把这些这个网络基础设施全都连接在一起,而且甚至完全屏蔽掉这个这些网络Topology的一些复杂性,虽然去配置什么VPC,IGW这些比较麻烦一点,但是基本上这些基础设施上的东西你基本不用考虑。

但是这一切都是要钱的。过去对于一个传统的软件工程师来说,我们从来不考虑钱,为什么呢?因为反正计算机买回来,那就是我的了,对吧,我爱怎么折腾。但是在云上,所有你在去设计软件和做架构的时候,都会多一个维度,这个维度就是钱的维度。

嗯,所以今天我的这个主题就是在当你的这个系统加上了一个新的Cost维度的时候,会你的系统的这个设计会变得有一点不一样。

好,这个正式开场的时候,第一个是要分享一个非常有意思的,作为大家提神醒脑的一个这个Opening。大家知道S3就是相当于在座的大家都是亚马逊云科技的用户。S3如果你仔细看他那个文档,你就发现一个特别有意思的一个现象,就是S3的这个Insert、Update跟这个Scan、List这些都是要钱的。但是我当时看的时候,诶,我发现没有Delete,为什么?Delete难道是免费的吗?我还以为当时是那个文档写错了,然后本来还给他们提个诶你看这个S3那个Delete这个API,你好像没有收他多少钱啊?结果这个回复说诶,亚马逊云科技销售跟我说免费的,这个随便用。唉,这也太好了!然后我说诶,非常敞亮,然后这个高兴妈哈但其实这个答案就是没有大家想得这么美好。

虽然这个亚马逊云科技告诉你这个API是免费的,但好,那第一个场景就是假设我们要去删除一个这个几百万个Object的S3 Bucket。好,非常简单,符合直觉,这个100万,反正我就写一个for循环,然后这个Delete Delete Delete,这就反正就Delete 100万次,而且他每一次调用都免费,所以就算调用一次都没问题。但不好意思,当你在真正写这个程序的时候,你就发现你要Delete的时候,你需要知道这个KeyName,然后这个KeyName你必须得去这个List,但List这个API是要收钱的。所以最终当你再去这个,要去删除这个S3 Bucket里面的这个Object的时候,你仍然要给钱,而且给的还挺多。

但是有没有免费的做法?其实还是有的,就是然后你会在那个S3的一个这个文档浩如烟海的文档里面找到一行小字,就是说你可以配置一个东西叫做这个S3 Life Cycle,然后Life Cycle里边可以去当,比如说你要把那个这一堆Bucket的Key全都删掉,你可以把Life Cycle设成一个这个最近的值诶,它这个在回收的时候会自动把它回收掉。没错,就是那么一行小字,确实是免费的。但它也有缺点,缺点就是你这个这个删除其实是完全异步的,你永远其实不知道什么时候回收完,但没关系,其实大多数的时候你这个Delete其实也不太需要关心他什么时候Delete的完,大多数时候还是异步的。

所以其实这个小小的例子就给今天的这个Talk定了个调,就是同样你完成一件事情,就是在云上可能有这个N种做法,因为我们在作为一个这个传统的软件,或者说开发这种单机应用的时候,不同的算法或者说不同的实现方式,基本只关乎效率。就说诶,我执行个一天还是执行个一个小时,还是执行1秒是吧?时间复杂度,空间复杂度。但在云上其实还关乎钱。如果像刚才那个程序,如果大家这个一个程序员,他不知道这个s3有一个生命周期这样的东西,然后老板说给我清除掉这个bucket,一下一看账单,哇,这个可能删除一下几百美金就出去了,但是诶,如果你这个厉害一点,可能搞到一个免费的一个这个效果。

所以其实今天我们就介绍一下PingCAP怎么去薅亚马逊云科技的羊毛的。

其实我今天会从三个方面,一个方面是这个存储,一个方面是计算,一个方面是网络,因为这三个基本都是这个亚马逊云科技来去收你们钱的这个地方。

所以先说存储,一个个来,因为我们做这个数据库的公司这个每天都跟这个存储来去打交道,我们其实看到嗯,说到存储,其实一般我们都不会去直接去碰这个磁盘,因为大家这个不管是这个做数据库还是用数据库,到最后你肯定也不会直接去调用磁盘的这个direct IO去写东西对吧,虽然你可能看到了一堆都是这个IOPS,唉,其实在这块我真的非常想吐槽一下这些云厂商的公司,就是到最后其实你给一个账单给个IOPS,但是如果从这个业务的角度来说,你其实永远不知道你真正的一个业务上的IO到磁盘上的这个IOPS会被放大到多少倍。

我举个简单的例子就是LSM Tree,LSM Tree是一个这个非常常见的这个存储的数据结构,大家比较耳熟能详的这个LevelDB或者RocksDB,包括TiDB的底层其实用的是RocksDB。所以其实就如果你看你用的虽然是一个TiDB或者RDS是吧,然后但是在真正在这台EC2的磁盘上运行着的这个存储的数据结构其实是这种存储引擎就以这个,当然今天我也不是主要讲这个。

LSM Tree的这个课其实大家可以脑补成另外任何的这个数据结构都OK,比如说像RDS可能是InnoDB,InnoDB底下是这个B+树,对于TiDB来说比较熟悉,因为LSM Tree,LSM Tree,大家可以看到整个这个数据结构,它其实虽然看上去比较复杂,但是它这个数据结构就是内存里面有一个MemTable,然后磁盘上有一部分顺序写的这个Log,然后还有一堆,这个叫SSTable,就是你实际的这个数据文件。

大家具体不用去这个研究它到底是怎么实现的,简单来说我想表达点就是LSM Tree它只是一个不同存储介质的一个组合,同时它的核心特点就是因为磁盘,大家知道这个顺序读写其实是比较高效的,所以相当于LSM Tree这个数据结构会把所有的写入,然后在磁盘上变成顺序写,就算你其实是在这颗存储引擎上是一个随机的这个Insert,但是它到最后在磁盘上表现出来的这个IO的模式一定是一个顺序的Append的写入,所以这个就是LSM Tree的一个核心,在读取的时候,它通过这个内存的一些Cache来去做一下加速,就这么简单是吧?这个也因为它这么简单,所以现在很多主流的数据库都在使用结构LSM Tree这种数据结构来去作为它的这个存储引擎好。

LSM Tree处理有什么问题对吧?就是其实我觉得写软件写多了,就是你到最后发现计算机科学里面所有的这个这个话题,或者说编程这个事情,到最后就会变成一个权衡,就是你选择了这个方案,你得到了一些好处,但是你一定就就会牺牲掉什么东西。对于我觉得一个好的软件工程师,你必须得知道你牺牲了什么东西,所以就很多时候就是年轻的程序员,或者说这个拿If,就是刚入行的这个小朋友经常会看广告,就是因为一些厂商真的非常唉,怎么说就是永远是吹牛,就说啊,我这个多厉害,这个世界第一的性能,但是一般这个老就今老师傅看到这种的时候,一般都会心里就会很紧张,就是一般来说,你有一项特别强,那你一定会有一项就是特别糟糕。

所以LSM Tree刚才虽然看到这个写入顺序,写入多好是吧,但它有一个特别大的问题,就是写放大,就是你可能在应用层,你在业务层1KB的写入会在这个磁盘上变成十几KB,从我们自己的经验来说,就大概的放大倍数是12倍左右,12-15倍,那意味着什么呢?意味着很多你的这个业务层的一个IOPS可能会被放大成N个N多个在磁盘上,而且你本身的磁盘带宽,你会发现,诶,有的时候我可能写入一个这个磁盘本身,嗯,一个G,两个G的这个写入的存储,但是你可能在应用层看到可能就变成了这个一个G,这100兆甚至可能更小。这第一个是个缺点,它本身是一个有写放大的一个问题。

第二个就是Compaction,就是刚才我其实提到了一个非常Tricky的地方,就是我的应用层是可以随机地写入,就是我,我一会写在这,一会写在那,但是这个磁盘上它是一个这个顺序写入,那中间必然会有一个过程叫做Compact,就是就有点像这个垃圾回收,或者说重新整理归档这些数据的一个过程。这个过程其实是需要消耗CPU的,所以大家经常会,尤其是做这个DBA或者说做这个存储引擎的工程师,他在去看这个系统的时候,尤其是用这种LSM Tree的数据结构,你会发现每隔一段时间,CPU就会疯狂地抖动一下啊,这个抖动对于这个老司机来说,一看就知道。噢,这个又是这个程序在做Compaction了是吧?所以当你的这个写入特别凶猛的时候,你会发现经常它会触发这个Compaction,然后会让你的业务层就是特别不稳定。

第三个点就是这个,所有的这个存储引擎都有这个问题,单机的存储型,因为它就是单机的,你的上限可能就是一台机器的磁盘,比如说你的磁盘100G,你写到100G,你也不能变得更大了,因为你就这么大点空间,所以这个为什么像什么RDS什么,但RDS不一定,但是这个基本上都有一个这个存储的一个上限,这很好理解。

所以传统的分布式系统,这里我先把我们自己的之前的这个TiKV定义成传统的分布式数据库。解决这个问题的办法也非常简单,对吧?就是你一台机器不行,那我就把这个工作负载和这个存储分散在多台机器是吧?我就分片,我就是一部分数据,一台机器负责一部分数据,把它拆成多个这个分片。这个抱歉,这里我用了一个Region来作为我们这个逻辑分片的单位,但是事实上它跟那个地理的那个Region不是一个东西,它只是一个逻辑上的这个Region其实可以用这个Shard,或者说用Range可能会更好一点。

所以很简单,它就是把这个数据拆分成N多份,然后这个就有点像这个化整为零的思路,就是每一台机器上的单机负责一小块,然后但是整个它拥有了一个扩展性,嗯,再往深一点看就是大概传统的TiDB其实也做了一点点优化。在TiDB上,我们其实是这个日志是用这个EBS,好处什么呢?好处就是在你做这个,比如说台机器挂了,或者说这台EC2直接就没有了,这是这种情况是经常发生的,然后你再起一台,这个一季度的时候你能快速地去把这个EBS就存储日志的这块的EBS给Load上来,再Mount上去,这样你的这个故障恢复的时间就能够短一点。除此之外,基本上都是一个标准的LSM Tree的一个实现。

但是即使是在云上这么做,仍然还有很多问题。第一就是刚才我提到了这个Log,本身我们的数据存储是放在除了Log以外,包括实际的那个数据也是在EBS上的,EBS当我们再去做这个高可用一会讲那个网络的部分,还会提到这个地方,就是会有一个比较高的这个网络成本。

第二个就是就像我刚才说的每一个SSTable再去就是每一个存储文件再去做Compaction的时候,包括像Compaction再去压缩,都会导致一个这个CPU的这个Spike。

嗯,然后第三个点,其实就是刚才我说到TiDB是一个分布式系统,然后当你再去做扩容,再去做这个甚至缩容的时候,一定会涉及到数据的这个重分布。在刚才这种传统的这个分布式系统上,因为干是基于分片的分布式,所以想象一下,如果我再加一台新的节点,我要去把这个数据这个重新均衡,那你是势必是要一片一片数据把它这个搬过来。这个有点像什么呢?我给大家举一个简单的例子,就是你要给你的朋友发一部电影,这个电影100个G,然后有两种方法,一种方法是这个我给你传一个网盘链接是吧,百度云盘,然后他那边下载。还有一种办法就是把这个电影100个G拆成100个一个G的小文件,然后通过邮件一个个一个G发过去,大家这个用脑子随便想一想就知道哪一种这个传输的这个效率会更高。所以很遗憾,就是传统的分布式系统的这个传送这个文件的方式,就像刚才我说的用邮件把它拆成100个,这个邮件发过去的方式一样,所以它的扩展效率,扩容效率是非常非常低的。

这个自己吐槽自己真的毫不留情是吧,没问题。然后因为我们有更好的东西,对,还有像这种大量分片,导致这种各样的成本,whatever,所以其实两年前我开始重新想,就是如果我假设这个,嗯,咱们就不是针对一台计算机开发程序了,就是我是在假设我看不到计算机,我看到就是亚马逊云科技好,那亚马逊云科技给我什么样的?这个我有,手上我有什么东西可以用,对吧?

大概数了一下,有三种东西可以用: 1. 一种是这个S3 2. 一种是这个快存储,其实EBS
3. 一种就是这个比较传统的这个本地磁盘

然后我这边做了一个表格,就是首先这个世界上没有什么完美的东西,包括像其实刚才那个分享完整听完了,一开始那个可能是你们亚马逊云科技的这个同学分享了一下S3 Express,Three Express这个东西出来的时候,哇,我真的非常兴奏,这个东西真好,然后又快,然后又这个便宜是吧?啊,不算太便宜,但是还挺便宜的。但是一看,诶,他怎么放弃掉了这个数据的这个可用性呢?Durability没法搞,那是吧,只有一个数据中心,所以一般来说广告不会告诉你这些事情,但是他一定会说,你看节省了这么多这么多成本,这多的快,但是对,所以当你把这所有的这个标准把它放在一起的时候,你就会发现每个都很好。

比如说S3特便宜,但它latency就特别高。这个本地磁盘你买EC2就自动送给你,比如20G,但是它的容量非常有限,但它快,对吧?那EBS这个啥都好,就是不太便宜。所以其实在云上我们重新想了一下,我知道了,还有10分钟,我可能还没开始,1/3,对,还没。

好吧,那个我快速加速一下,大概就是我们给这个TiDB重新设计了一个存储引擎,这个存储引擎是一个纯分布式的存储引擎,这个分布存储引擎其实是由S3、EBS以及本地磁盘组合在一起去做的。所以仍然还是这个刚才说的LSM Tree这个数据结构。

我们其实把这个这种冷的数据,或者说compact好的这些文件全都放在S3上,因为一般这种冷的数据用户也不会经常访问。诶,那放S3正好了对吧?这个latency不怕,因为反正也没什么人去读它,每次都是这种compaction的工作,负责来去在这上面做这个数据整理。

然后那个本地的热数据,这个日志,你没办法你还是得写到EBS对吧?然后这个因为你需要它的这个高可靠性,然后故障恢复刚才我也提到了,然后你的本地的这些内存和这个local的SSD,因为访问速度特别快,但它容量有限,那它就用来做一些热数据的缓存,这样一来这个好处成本瞬间降低是吧?

这个S3比刚才说的,比如说原来你有100个T的数据,你可能需要100台EC2来取,以及它背后的那个EBS来去来去来去支撑。但现在其实就是你的大量数据其实还在S3上,但是一个冷数据,但是因为它本身是用了一个这种LSM Tree的数据结构,它会定期地去把这些冷热数据做交换。而且用S3有个好处就是它的durability是更好的,就是持久化,这些包括拓展性,你不需要去考虑太多。

第三个带来的这个非常好的好处就是当你这个存储做完分离了以后,你会发现你的所有的计算节点几乎变成无状态的了,无状态。好处意味着比如说刚才我说的像一些LSM Tree本身的先天问题,比如说compaction是吧,你无论如何你都要去做compact,不compact不行,因为你对吧,这个很好理解,但是如果是用S3把这个存储的这个跟计算分开了以后,你就会发现你可以随便找一台这个机器在S3上去做这个这个compaction,或者是做一些这种离线的任务,你不会去影响你在线的这些服务器诶,这样你一下你就可以去把你在线的这个机器的100%的资源这个给这个业务去用。

所以而且另外还有一个好处就是像这种compaction和这个离线的后台的这些任务有一个特点就是它不是7*24小时都在那了,可能你几个小时跑一下,或者说这个几十分钟跑一下就OK,这样一来的话,你就会发现像Spot Instance这种,可能它的价格比那个EC2要便宜10倍,甚至可能有些这个可能便宜更多,那一下你的整个成本就下架好多。

然后第四个特别好的好处就是一会我会给大家分享一张图,就是一个我很喜欢用的S3的一个benchmark,好哈哈,5分钟,我看5分钟怎么把剩下70%的内容讲完。

对,所以一个这个很好的例子就是那个我们其实自己做了一个网站叫OpsInsight,其实是我们自己的demo,它大概它做什么不重要啊,大家看一眼数字就行了。我们把它从一个传统的分布式数据库移动到这个TiDB的这个在云上的服务以后,用上了刚才那些诸多的这个优化的存储引擎以后,它的这个成本降了70%。

第二,那个整体的这个有个小故事,就是有一天突然这个网站上了那个Hacker News的首页,哇一下这个流量涨了十几倍,然后七倍,然后结果这个系统就自动在后排吭哧吭哧自己扩容扩上去,把这个流量撑住了以后,然后又缩回来,它整个过程人是没有参与的,而且这个系统的扩容速度非常非常快。

存储说完了,然后计算这张图其实也是从你们这个亚马逊云科技的这个PPT上抠出来的,然后给大家介绍一些这个在亚马逊云科技上这个光速省钱的这个办法。

第一个就是如果所有你们还没有用上ARM的,你马上去用ARM,然后可能会有惊喜。这个是就是Graviton,就是如果大家普通那些机型,你换一换试试。这里面我们是一个TiDB的一个Benchmark的一个,这个一个测试就是同样的一个这个workload,同样的节点数,只是换成了一个接近的Graviton的node了以后,性能几乎差不多,甚至可能在比如说这个OLTP Read这个场景下还有接近快10%的提升。这个地方有点下降,我不知道为什么,但应该是这个正常的抖动范围之内,因为它跟CPU也没什么关系。这个部分其实简单来说解读一下就是性能差不多,但这个地方就差别大了,就是你一行代码没改的情况下,直接整体的成本省了20%是吧?可能你最后这个公司上市就是要成本20%的Merge,这个这时候你无脑一换,你到最后就一下就财报又好看了。

对,好这个第二步,刚才如果这个换完了,然后发现这个成本还是很高,接下来你还能做什么事情好的,让我继续生成剩余的内容:

对,好这个第二步,刚才如果这个换完了,然后发现这个成本还是很高,接下来你还能做什么事情?这个高级省钱技巧就是我推荐大家去梳理一下,因为其实在云上最贵的东西是什么?我不知道大家有没有思考过一个问题,就是如果去看这个单位资源,亚马逊云科技最贵的东西就是我发现有个东西是,就是虽然看上去亚马逊云科技上所有的这些资源都是无限的,但是其实最贵的东西是计算,大家仔细看,就是单位CPU的这个成本vs你自己买一台这个主机,然后你最后发现,诶,其实差别最大的其实是CPU。所以而且原来我觉得很少有人去仔细梳理过你自己在CPU上去跑的workload到底有哪些,但是你梳理了一下会有惊喜,为什么?

我给大家举个例子,其实刚才他DB上面有很多这种计算,有一部分计算其实是用户直接的workload traffic,或者这OTP就增删改查,另外一部分计算是刚才说的这种compaction、DDL或比如build index,或者说这个数据的插入,或者说排序,或者说这些离线的OLAP分析,你会发现不同种类的计算的特征是不一样的,有些是短平快,有些的可能是要消耗你一个小时这样的。

对,我给大家举个例子,拆出来的一个好处就是这个例子其实是一个加索引。简单来说就是把你的一些离线的这个任务拆出来了以后用一些这个更便宜的这些比如说lambda或者说spot instance来去去跑。第一它能用更高的并发量,所以你整体的跑的速度很快,因为你并发高了。第二就是因为你的是底下是S3,所以就反正无状态,然后你可以把一些更好的资源留给你的在线的这个计算节点。

嗯,我其实举这个例子是想让大家去思考一个问题,就是当然这个问题我可能没有直接的答案,但是非常值得大家去这个动手算一算,大家觉得是一颗CPU跑100个小时贵,还是100个CPU跑一个小时贵?我现在很少人算这个东西,但是最后你会发现,如果你搞得好的话,100个CPU算一个小时可能远比你一个这个CPU算100个小时要便宜得多。

所以这个里面其实是真的S3,我觉得真的是这个亚马逊云科技最好的东西就是所有这个薅羊毛技巧里边的一个基础,其实就是这个S3。对是哈哈哈,这张就是我刚才说的我特别喜欢的图。

这张图稍微介绍一下,右边这个蓝色的框框是这个亚马逊云科技的不同的EC2的instance type,然后纵向的这个纵轴吞吐,就比如说就是下载一个文件,上传一个文件这样的一个这个S3的一个吞吐。这张图有意思的地方是什么呢?这张图有意思的地方是S3的吞吐基本只跟机型的网络带宽有关,就是说你越有钱,你就能够拥有越好的这个吞吐,而且它没有上线是吧,就是你会看到这条线其实一直可以顶穿这个天花板,所以这个意味着什么呢?这张图的意义非常关键,就是S3的吞吐性能几乎是无限的,只受限于你的网络带宽。回头想一想,对于需要高吞吐的场景,利用S3可以极大提升性能,而成本也很低。

然后那个实话,因为我们用了EKS,所以本身虽然大家看在云上,我们其实是用了一个,这个看大家可能用起来是一个数据库,但事实上大家每个人都没有独占的自己的数据库,因为我所有的这些计算的资源都是放在一个池子里,唯一在线上长期存在的是这个最左边这个叫gateway的模块,这gateway就是假装成一个计算节点来去接收用户的连接,他收到这个连接了以后,有点像前台是吧?

这个比如说我平时都不在办公室,然后我的前台,但是必须得天天在办公室,所以如果有个客人过来,然后那个前台说诶?这个比如说那客人过来说找黄总,然后前台说你等一下,黄总在忙着呢,其实我可能在家,然后这时候我的前台会赶紧给我打电话,从让我从家里这个赶过来,然后就其实原理是一样的,所以就无状态的这些服务的话,你其实可以放在一个这个资源池里,这个模式其实给我们省了无数的钱。

好第三部分,网络,网络其实是最容易被人忽视的一个部分,就是我以前其实这个没有长期搞匀的时候,我就觉得网络这种东西还能比买计算机贵是吧,我买台电脑是吧,这个1万块钱这个,但现在你仔细想想,其实你家每个月的带宽钱乘起来是吧,比你可能这个电脑是要贵的,然后为了介绍网络,然后我会介绍一个在数据库领域里边,现代数据库的高可用的一个基石,这个叫replicated state machine,就是数据复制的状态机。

所以你看到现代的这种分布式数据库,它有这个高可用,都靠这样的算法,说白了就是这个组重复制。主动复制的本质是什么呢?主动复制的本质就是通过这个冗余来去创造这个高可用的强一致性,但是这个算法非常好,这个是吧,self healing how to favor?但在云上意味着什么呢?云上就意味着跨AZ的复制和跨AZ的读取,你不跨AZ,这个东西一点意义都没有。

所以如果你在同一个AZ里面去做这个什么主备副本这种,大家就哈哈,如果你的教师敢跟你说,诶,我做了个MySQL,高可用,但不好意思在同一个AZ里,那你回去你可能要考虑一下是不是要把这个人给开掉,因为这个东西其实一点意义都没有,因为你只有跨AZ其实才是真正的这个。但是亚马逊云科技坏就坏在这一点,它的这个跨AZ的这个流量费用超级贵,所以一般来说我们典型有一些高这个客户,时间到了,快速结束了,然后这个跨AZ部署的时候,一般3个AZ去部署。

然后我这里有一个实际的例子,这是我们自己做的一个测试,我当时看诶,那个性能报告什么都挺好,但是最后我一看,这个data transfer cost居然是我们机器成本的16倍,这个哈哈,我当时万万没想到,比如我这个做一次测试,我可能花1万美金,但是最后结果网络费给我收了16万美金,就是这样的一个,这个黑心亚马逊云科技是吧,对,很有救吗?其实还是有的,就是给。

但是其实这个如果你需要高可用,你必须得去放弃掉你的数据复制的这一部分,这个写入你肯定没办法,但是读这边你可以做一点工作,大概两种思路,一种就是第一种思路,就是你其实有时候你也不需要强一致是吧?像TiDB其实提供了这种数据的这个本地,这lot of style read,你可以在本地的这数据中心,本地的AZ跟你,比如说你这个AZ部署了你这个本地数据中心的这个application,你可以其实从这个本地去读,这样就少了这个跨数据中心的这个流量费用。

第二种思路就是你的业务动不了,那你就动数据呗,是吧的TiDB也给你这样的一个选项,就是把这个数据集中在一个这个数据中心来去避免这个快速中心的访问啊。还有的时候这个流量是在你不经意之间,这个账单就上去了。这种是最吓人的,就可能你一个月之后一看,我靠这个非常surprise,你的这个这个账单为什么有这么多?比如说我举个简单例子,就是在这种一个集群挂掉了以后,或者说一台节点挂掉了以后,这个数据要重新的去做故障恢复,这故障恢复就势必涉及到这个数据的这个移动,但这移动肯定是走网络的,那这种时候比如说你这个挂个几台,你这个流量费用可能就上去了,怎么解决这个问题?唉,又是S3,真是YYDS就是S3真的是我觉得薅羊毛神器,为什么呢?因为S3在跨AZ的流量是不收钱的,这个是一个我觉得还挺大的漏洞,就是对,哈哈,然后挺好的,因为S3只会调那个,只对API收钱。

所以像这种副本的这个恢复,或者说这个缓存预热的场景,你能用S3来去做缓存预热,用S3就一定比EC2直传是要审核多的,而且刚才还记得刚才那张图吗?它的吞吐是几乎是无限的,所以你可以甚至起一大堆这个节点起来,然后做预热,然后再把它销毁掉。只需要你去控制一下你的API cost的次数,这里边其实有很多技巧去减少这个API cost的次数。

好,最后一页,就最后一个,这个你可能想不到,杂项就是EC2、EKS,不升级可能会多差距你百分之十几的钱,所以你经常要去升级,这个还挺烦的。

对,为什么就one模型?最后一个,我觉得未来其实ADBS就是个计算机是吧,就以后我们其实在思考这所有问题的时候,把它当成一台计算机去考虑就好了。

对,这里做个广告就TiDB Serverless,跟ByteDance有一个合作,然后这是一个社区的人写的一篇很好的文章,谢谢。

总的来说,在亚马逊云科技上构建高效能的系统需要从存储、计算和网络三个方面综合考虑成本优化。利用S3、EBS、本地存储的组合、ARM架构、Spot实例等策略,能够极大降低总体成本。同时也需要注意跨AZ的网络流量费用,可以通过本地读取、数据集中等方式减少开支。最后,亚马逊云科技就像一台大型计算机,需要全面审视各种资源的使用,才能充分发挥性价比。这确实是一场内容丰富、见解独到的技术分享。

下面是一些演讲现场的精彩瞬间：

PingCAP 的代表在亚马逊云科技中国峰会 2024 上介绍了他们在 亚马逊云科技 上构建的面向企业的数据库服务。

亚马逊云科技中国峰会2024上,演讲者分享了云计算如何改变了软件开发的基础假设,从有限的本地资源到无限的云端资源,彻底颠覆了传统的编程思维。

亚马逊云科技中国峰会2024:解释了LSM Tree数据结构中Compaction过程的重要性,以及如何识别和应对Compaction导致的CPU抖动问题。

TiDB 作为分布式数据库系统,在扩容和缩容时能够高效地重新分布数据,避免了传统分布式系统中低效的数据迁移方式。

亚马逊云科技中国峰会2024上,演讲者强调采用ARM架构的Graviton实例可以在保持性能的同时降低20%的成本,为企业带来显著的成本优化。

亚马逊云科技中国峰会2024:利用 S3 跨可用区域传输数据无需付费,解决数据迁移导致的高昂流量费用问题

亚马逊云科技中国峰会2024上,演讲者提出了将人工智能视为一台计算机的新颖观点,引发了与会者的深思。

总结

亚马逊云科技中国峰会2024上,PingCAP作为亚马逊云科技用户分享了在云上构建高效能系统的思考和实践。主要内容包括:

1. 在云上开发应用时,需要重新思考传统的软件开发假设,如无限存储、计算资源和网络带宽。同时,成本也成为一个新的考虑维度。
2. 存储方面,PingCAP重新设计了基于S3、EBS和本地磁盘的分布式存储引擎,将冷数据存储在S3上,热数据存储在EBS和本地磁盘上,降低了存储成本并提高了扩展性。
3. 计算方面,建议使用ARM架构的EC2实例(Graviton)以及将离线任务拆分到Spot实例或Lambda上运行,可显著降低计算成本。
4. 网络方面,跨可用区数据复制和读取会产生高昂的网络流量费用。PingCAP提出了本地读取和数据集中部署等策略来减少网络成本,并利用S3的跨可用区免费数据传输来进行数据恢复和缓存预热。
5. PingCAP将亚马逊云科技视为一台大型计算机,在云上构建高效能系统需要全面考虑存储、计算和网络等各个方面,并通过各种优化手段来降低总体成本。

2024年5月29日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。