大家好 今天我跟大家分享一下Uber怎么使用Multi Framework Mentors所以我们下一代class management的集中管理的解决方案自我介绍一下 我叫李志涛现在在Uber的class management进行工作我是Uber第一组把Docker introduced到Uber的Engineer之一然后我也是第一组把Messos introduced到Uber的Engineer之一在之前我在Facebook和Google都工作过这也是黄小剑我们team的Engineer Manager所以我今天的Docker来分享一下的部分第一我会讨论一下Uber为什么会用Multi Framework Mentors所以我们下一代class management的解决方案然后我会大概把我们的工作分成几块来讨论一下一块是Microservice也就是Wavewood的部分一块是Storage存储的业务另一个就是Analytics也就是数据处理的部分然后我会大概用讨论一下我们是怎么把Messos整合到我们现有的infrastructure里面而且用一个Messos的新的叫做Eventstream的特性来improve一些integration这里面我用我们跟我们的Service Discovery的System的integration做一件研究解释一下我为什么要我们做这些工作最后我会大概介绍一下我们在短期的未来还准备进行的一些试试工作和我们在这过程中遇到的一些需要整个社区一起来帮助一起来帮助的一些技术的挑战首先要么我理解我们为什么要使用Multi Framework Messos我打算从Uber的Mission说起Uber的Mission是TransportationAs reliable as running waterEverywhere for everyone我就不翻译了这样的Mission对我们的UberUber的Engineering Service有什么来挑战呢首先Uber整个后端的Service要能够提供超过4个9的可运度Everywhere表示Uber整个Service要能够Scale到非常大图一模Everywhere表示我们整个Service需要As inexpensive as possible所以根据我们对我们整个Uber Service上面的要求所以我们整个Uber Service我们大概规纳了一下我们在寻找下一个解决方案的时候这个解决方案要满足的特性首先在可靠性方面我们想要一个已经在很大规模的部署被证实的系统我们不想找一个很新的东西然后这个系统必须能够支持我们上面整个Uber的Service提供超过4个9的可运性在Scalability方面这个解决方案必须能够支持属于1G的服务器1G的Task在每个Cluster里面并且它能够支持我们把我们的服务软在任何一样的环境里无论是我们自己的大对的Sender还是在Public Cloud上面然后在效率的方面这个解决方案必须能够支持我们跑各种不同类型的Workload并且IdeaLay我们能够在每天我们各种各样服务的质量的同时尽量Maximize我们Cluster里面资源的利用率所以经过各种各样的寻找我们发现也只有Apache Mentos在所有Open Source的solution里面也只有Apache Mentos能够基本上满做我们的要求所以我们最后选择了Apache Mentos对我们的Clust Management的solution我们在这些Apache Mentos这些事情上做了不到一年那样子但是我们的Final都已经比较清晰了我们打算把Uber尽量把Uber所有的东西都逐渐迁移到Messos上我们的工作大概分成了三块像我刚才说的微服务,存储和数据的业务我先下面分别快速地讲一下我们在每个方面做的工作首先是微服务的部分在Messos以前我们其实已经有一个证券微服务的deployment system叫做Udeploy我们的风格就是在每一个term前面加一个U表示Uber所以这个系统其实有一些已经有一些不错的优点就是它也有一个很好的UI然后它给我们每个services都定义了一些很标准的公务部署部署和生理的流程而且整个系统非常容易上手很多ngn也到公司第一天就可以用这个系统来免费他们的services但那个系统的articulers上面是有很多问题的比如说所有的task都在statically placed到不同的服务器上面这边最大的问题就是当服务器出现故障的时候这个task这个服务的本身可高兴也会受到影响然后我们的service owner或者invert engineer只要帮他们把task从故障的服务器留到一个好的服务器上第二整个系统整个系统是完全完全只能支持静态的端口相互我们有很多很多的服务这就意味着我们要管理一个集中的静态服务的数据库整个数据库的大了之后其实并不是很能为户而且经常会在生产环境中发生比如说端口侧配或者端口冲突这样的事情就发生服务被抵挂出去但是穿这个过不来然后整个系统是没有一个centralized resource management和 orchestration的解决方案的这样的话我们的engineer经常需要手动的把服务从一些机器能到另一些机器上面如果机器过热或者如果机器要take out production有很多守护的功能这个在机器和服务多了之后其实非常的费劲功然后最后整个这里面有很多service还没有没容器化这样的话他们并没有基本的在性能方面的隔离所以我们在微服务方面选择了选择了Apache Aurora作为我们的微服务的解决方案Apache Aurora是最早从推特OpenSoft出来的针对service framework它有一些优点挺有些优点很好的满足了我们需要的功能首先所有的task都是被动态地scan就到message cluster之间的而且在在Machine出现故障的时候task配自动的重新部署到部署到好的服务器上面这就保证了我们上面跑的服务可以在对服务器的故障有自动物修复的能力而且这个系统支持动态端口的分配这就使得我们不亦在维护集中的端口数据库了最关键的一点是这个系统skill的可以skill到非常大的规模在推特public的talked number里面他们说他们可以在一个message cluster里面跑超过10万个跑手超过10万个bow running的task最后我们发现我们是可以把Aurora作为我们线有系统的back end部署出去的这样的话我们的engineer就不需要直接interactive的Aurora在他们可以使用他们原有的工作流程和UI继续管理他们的service而且整个从老的系统到新的系统迁移的过程中基本上对用户来讲是simless这个图大概就介绍了我们是怎么做到这一点的灰色的问题是原有的系统我们所有的用户从上网下看的话我们所有的用户都已经工作了但是到aggregator这个部件它会自动understand这个service是已经被移植到message上面还是还在老的系统里如果移植到message上面的话aggregator会自动把这个service相关的configuration翻译成Aurora里面的罩并且通过Aurora的strip atm把这罩上面移到Aurora然后Aurora就会dynamicate把这个罩罩的各个taskSchedule到Message Caster里面关于severe discoveryAurora Executor是可以把这个服务的IP和端口动态的注册到Message Discovery这些paper里面这样我们的我们这样这个服务的client就可以将用这个服务了整个过程中我们基本上重用了整个进于docker的build distribution和我们dockerreddit infrastructure这样在整个迁移的过程中我们的用户并不像每天两套build的方案他们可以在整个即使在这个迁移过程中同一套build的方案然后可以继续工作有一点值得一提但是由于Uber快速的增长我们在微服务方面遇到了很多growing pain我们现在我们现在整个地步需要支持超过2000个微服务而且这个速度还在以每个月超过100个速度低增我们现在工作的重点就是把所有的这些微服务逐渐一个一个的容器化并且把他们把他们全部迁移到Message Caster里面我们预测在2017年我们的content我们的class里面要支持超过下面我简单说一下我们在身处方面的工作在这方面我们最大的我们主要的工作就是部署了DCOS看到Service是一个Uber的我们的computer teamUber的Storage team和Message Sphere的Infinite team共同合作的项目这个东西这个Service本身是一个Declarative Metals FrameworkBuild on top of DCOS SDK它关键就是关键就是把Casano database作为一个Message Framework在我们Message Caster上面部署并且管理起来利用了一些Message正面整体的State for Service的一些 Feature比如说Dynamic ReservationPresist Volume这样的话它的所有的数据都会存在Task Sandbox的外面即使这个Casano taskFill之后被Restart这个task能够正确地excess all the data现在我介绍一下我们是怎么管理这些Casano Cluster我们就starting build了一个Centralized Web Interface用来管理Multiple的Casano Cluster在我们需要create a new cluster上的那个Web Interface首先我们要talk to our Deployed System你就前面提到Deploy这个Deployed System会动态地把一个back by一起带我们的AuraCaster里面起一个AuraJob这个AuraJob的内容其实就是Casano Framework的scheduler这个scheduler在起来之后会动态地 automatically register自动的register到message master上面然后根据从message master上面拿到的resource offer选出合适的message agent在message agent上面Dynamic Reserved需要the resource然后create需要precision volume最后把Casano database起来在起来的过程中特会正确地pinch不同的Casano database使得他们自动的成为一个correct的Casano Replicator ring这个服务有这个服务支持了很多功能最重要的一点就是它可以把整个Casano cluster ring up的过程完全自动化并且自动冲击所有fail task这样基本上takeout了所有人工需要管理的部分除此以外它还支持自动增加整个Casano cluster的规模修改Casano database的configuration如果有服务器破掉了它可以支持replace一个坏掉的服务器比如说我支持对Casano数据的backup和restore并且还有一点值得一提的是这个framer可能在multiple data center上面的message cluster之间自动的pinch这些Casano cluster使得他们形成一个corrected replication我们这个系统大概g-production有6个月的样子但是已经supported很多Mission-created workload像我说的我们那边很多每个东西都是一个service包括这种本身也是一个service现在他们已经支持了超过20个的Casano cluster在我们两个不同的数据中心之间replicate并且已经他们的service本身已经在管理已经在超过300台服务器上面的Mission我们发现的performance基本上说把Casano跑到Air Metal上面基本上是一样的这个项目最关键是给我们很多信心说这套storage叫Message assembly architecture是可以work的所以我们现在和我们的storage的优部没有好几个项目同时合作把各种各样其他open source的solution比如说messico或者postgres还有一些纯粹还有一些homegrown storage system都逐渐的试着把它牵一个metal上面下面我要简单说一下数据处理最快的东西我们这一块开始相对晚一点现在主要的成果就是把sparkprojection来跑到我们的message cluster上面我们现在我们的结构也是跑了整的spark on mesos的installation这边的 architecture跟刚才Casano的那个差不多基本上就是我们仍然用Aurora的schedule去manage各种样的spark job每一个spark job都会ready成一个版图的message framework他们会sharemessage cluster和别的spark job一起sharemessage cluster我们在设的spark job和他们的executor都用了同一套doctor container和doctor register setup这样我们全公司可以用一套标准的标准系统去管理所有的东西这块在在资源调度方面还有一些没有解决的challenge但是整个系统已经在把它整跑一段时间了我们下一步的多的众员主要会移到我们自己用的一些homegrown framework就支援了一些比较custom比较复杂的安排的workload一些类似于yarn的workload或者一些非常custom的一些针对machine learning或者deburning的工作都出现在message of上面稍微总结一点就是说我们我们对这个multi framework这套actual我们总结了一下它跟我们的info做个代表打击优点呢首先我们可以用一套同一的API去管理我们class里面的资源和任务哪怕他们是从不同的workload过来的第二点整个system无论是对于开源的软件还是homegrown的system都非常friendly我们可以在同一个class里面同时在运行open source framework和我们自己研发的一些framework第三这个actual保证了我们上层的system对于machine failure基本上是有自动修复的能力然后整个actual非常容易scaled非常大的deployment这个对我们对我们这样的公司是非常关键的一点最后值得一提的是整个system非常operator friendly我们的经验发现跟以往的经验相比如果需要运用一个相同大小的cluster我们现在报警的频率大概是以前的几分之一的样子所以这个对我们都on call来讲其实也好我们可以把更多的经历投入在做automation或者研发的上面而不是纯粹的体育应付的这些警报下面我会大概讨论一下我们是怎么把这个system后我们其他的不会integrate起来的用了MessusEvent Stream的这个新的特性我们在这个integration的过程中发现我们有很多systemto understandMessus cluster里面的state在Messus 1.0以前基本上大家能做的就是puretally callMessus master上面这个state至上的end point然后把整个cluster里面task和agents都pure出来然后在client端不停的进行处理这里面有两个问题第一是当cluster变大的时候client端要重复的处理很多的data这样的话整个system就变得有慢第二是有一些system其实是希望能够在cluster里面有变化的时候动态是可以通知的所以我们想要所以我们试着用MessusEvent Stream的这个新的特性去解决这个问题event stream的API是在Messus 1.0作为operatorAPI的一部分没介绍的这是现在还是experimental的feature但是我们希望我们可以给产举合作尽量把它enter stableand state它关键的目标就是允许external的system可以subscribe到这个Messus cluster上面毕竟有change的时候毕竟有change的时候到一个event这里面我要特别感谢两个Messus CommitterNOT和NAND两个w它和我它这个和UberNAND也主要是我还有很多experimental比如耗收掌钱一起work整个operatorAPI的工作我们会解释这个feature代言怎么work首先在一个MessusMaster里面如果一个experimentalsubscriber需要subscribe到这个event stream的话它首先我通过HEP post从subscriber到master上一个叫做subscriber call这个当master成功出一个subscriber call它会像Scheduler的API一样把整个connectionkeep open并且在并且散到一个subscriberevent这里面要注意的一点就是整个subscriberevent这个response里面包含了整个cluster当前的state所有的所有的task所有registered agent和所有registeredscheduler这样的话subscriber里面就可以把这个snapshot作为一个increatebuild base在上面继续applyfutureevent现在比如说有一个新的taskt1左边有点被切掉了有一个新的taskt1被launch out在cluster里面mastersubscribersendevent然后如果这个task开始agent上面被starting了或者一个taskupdateeventsendsubscriber它的state或者taskstarting类似的subscriber会继续收到一个running thetaskstate并且如果这个task如果用event terminate的话subscriber会继续收到futureeventtask update比如说finishedor killedor task failed像刚才这里面很值得注意的一个design就是整个event stream的event所有的outer是被实现所保证的所有subscriber里面收到的event是和masterprocess的event数据是相同的这样的话subscriber像我刚才说的可以在initial snap shot上面用相同的顺序把所有的event逐渐apply在snap shot上面这样在任何时候它所观察到的class of state和master在观察的class里面是相同的这样的话哪怕传输上面如果有错的话subscriber可以直接把原来的connection扔掉重新重新看一个新的connection重新subscribe并且从从一个新的snap shot开始这样的话subscriberobserve到的class of state仍然是相同一个这样的话就使得我们的bansai的programming变得容易了很多我们基本上是不需要autobounder的state to get this大家也知道discorded system这种证确性其实其实其实是很难保障的我们看现在我们介绍一下我们是能够subscriber的system用这个feature做整合的像我们Uber下一代的subscriber的system是一套完全基于subscriber的世界方案但是因为我们在我们class里面跑了aroracassembler和一些homegrown framework所以arora的subscriber有能力自动注册subscriber把这个IP和端口的信息registersubscriber里面但是我们我们既不想也没有办法重用同一subscriber到不同的framework上面比如说cassembler的subscriber其实是还有一些关于cassemblerspecific base logic比如说数据备份数据恢复相关的工作所以我们的继续方案是我们开发了一个小的部件叫做ness of bridge这个部件的功能就是把subscriber discovery的information从subscriber直接publish到subscriber里面这样的话我们每个framework的scheduler只要把这个只要把这个端口的信息publish到每个task的discovery info这个field的上面这个bridge可以自动把它pick up起来或者寫到subscriber这个这个图就是我刚才所说的bridge会从master里面把所有task读出来然后把他们寫到subscriber里面这个作其实和subscriber来然后generalif didn't ask the record在email stream这个feature被介绍以前我们的bridge就像我刚才说的基本上也是每n秒钟泡一次搜到discovery point这里面有一个问题是我们发现我们没有办法泡得太平凡因为每次泡下来我们要处理很多数据但是如果我们这个时间太长的话我们整个subscriberdiscovery systemconverter速度会比较慢这样的话给我们的client带来了很多问题discovery point并不是适合一个很大的clusterdesign并不是skillable我们在我们在做的时候发现哪怕cluster可能只有1500task的时候整个processor有人会45秒钟那样子但是我们eventral这个subscriberintegration design够时整个converter最好能够少于一秒并且我们要支持大概这个数字的50倍以上的messus cluster size所以这个肯定这个肯定是不论说exceptable performance所以这个这个project也是我们主要只要motivate我们和messus community和作法eventstreaming feature做出来的原因所以在eventstreamingfeature做出来之后我们就重新重新design从messus master之间的integration我们现在的作法就是在bridge里面一个task到ip和dunk的hashmap这样的话我们就可以从messus mastershallowed event从statshot去丢的一个引力手的hashmap并且通过每一个taskchange的event去incrementallyupdate的hashmap然后我们可以用另外一些进行的gurr routine去把这些taskmapchange写到papers里面integrant结果表明我们可以在messusbrake之间所处理的data process被reduce了超过90%我们大概主要处理原来不到一成的data而且我们直接把N second delay直接系统中有消灭掉这个pattern还是很重要所以我们我们现在我们现在等到我们希望这个event stream这个feature stable之后逐渐把这个逐渐把这个patternapply到我们其他的需要个metalsystemintegrated system装灭现在我点灯一下event stream里面我们还想去和科学区一起合作做这些事情首先是我们希望我们以后能够不离离发tasked event还能够发agent和scheduled eventagent身边的event有两个event已经在1.11.1被merged但是scheduled里面的event的event还刚刚开始另外一个值得一提的就是在这个feature stable之前我们希望能够支持filter out掉一些subscriber不感兴趣的event比如说有些subscriber可能不care initialinitial snapshot比如说可能仅仅是一个logging的proper或者有些subscriber有些subscriber可能只care一个particular framework的event这样的话我们希望他给你在subscriber的时候删灭了一个filtr的东西这样他就只收到他所需要的event最后一个interesting idea就是我们在想我们能不能在agent里面bill的一个类似event stream的机制因为buckered event其实是有一个duckered event的API的而且其实有很多在production里面的integration在agent上面有很多系统都是用那个API和duckered event做整合但是如果messles要move to unifiedcontinuizermessles自己做continuizer engine的话很多这种system就希望他们能够直接talk to messles agent在比如说有task或者continuizer在launch或者by destroyer的情况下这些system可以收到一些event并且更新他们自己的一些configuration我们现在也在和messles community的讨论我们能够把这个东西是不是说做出来所以这基本上就是我们做的一些东西那真的比较快没问题然后我们现在讨论一下我们未来想要做的一些事情和我们在整个过程中遇到的一些挑战首先我们在短期内想要做的一件事情就是我们想做整个cluster-wise的maintenance automation这个在每天比较大的cluster-wise其实是一件非常痛苦的事情举个例子每次linux有每次linux完全落洞的时候基本上大家在公司里做opinion可能知道基本上大家就要然后list out所有的机器在公司大了team多了cluster-wise大了这个processor-wise变得很漫长而且很痛苦平常是这个team来三亿另一个team来三亿另一个team来三亿说现在不行我们能不能短一短然后再短一下整个processor-wise会太久而且要耗费耗费很多很多的人力我们在想我们能够利用messus-maintenance这个API这个东西来build一个automatedcluster-wise这里面有一条有一个要求就是我们所有的framework第一是要adapt新的HTB API第二是我们上面每一个framework都需要understand他们自己的SLA这样的话我们才能够build一个统一的messus-maintenance等机制说我们什么时候要把这台机器takeout production什么时候可以把这台机器出现return to production里面我们另外一块在自己想做或者想跟社区一起做的事情就是我们希望messus-maintenance每一个能够支持dimming的framework这个东西和copenet里面dimming-set比较像像像Uber我们其实是像比如说我们自己是有有一些我们自己写的在每台机器上就得允许用一些dimming software比如说我们用自己的lock-shipping的dimming我们有自己的load-batteryload-battery-proxy类似HAProxy这样的我们还有一些自己的status-collection这些dimming这些dimming的日常管理也是一个比较痛苦的事情我们在messus-maintenance以前这东西基本上就是用PAPE加上SystemD或者VND在管理这些东西但这里面有两个问题第一是我们没有办法在整个classes上面做corrected rolling upgrade或者在如果有问题的时候没有办法做corrected rolling back或者自动的 rolling back第二个是这些dimming基本上都没有被容器化这里面有一个问题就是他们没有result restriction和isolation所以他们经常会把我们给task预留的results有的时候甚至在某些机器上这些dimming本身用掉了30%-50%的CPU results这是一个非常糟糕的情况所以我们就希望找到一个相对lightweight的一点一个基于容器化的一个解决方案我们自己在试一些PoC但是如果跟community有兴趣做这个事情的话可以跟我们联系我们可以一起在这下面进行合作然后我们遇到的一些challenge我们在过程遇到的一些challenges要失去帮忙一起做的一些事情第一个就是在education方面我们觉得education方面还是有更多的improvement比如说这个在我们设计下一代的大数据的framework中就有起的明显刚才像是IBM的马达同学和隔壁的方勇同学在design他们的spark的tashet scatters也提到过就是对于这种大规模的高并发的大数据的工作的话现在Vessels还是有一些missing的东西比如说我们希望在quota类似clusterquota这种配置上面能够在进行results guarantee的同时能够increase theresults allocation的elasticity使得我们可以更好的利用这个cluster跟results第二就是我们希望educator这边能够providesome kind ofconstraint support比如说我们需要保证我们所有的casseter都必须跑在casseter的机器上面往一个specialcasseter sdt机器上面或者我们需要保证或者我们需要保证有一些重要只有一些重要的framework能够用我们cluster的GPU这都是一些一些现在elasticity那边还没有的东西最后就是我们希望在elasticityvessels里面可以有一个同一的priority和一个preemption一个强占的机制这里面我们也是在密切的关注vessels一些新的feature而且希望能够在各个社区一起共同work on this feature比如说hierarchical rows每个framework可以有多个multi-raw或者revocable default和一些futureoptimistic offer这些东西我们就这些东西对我们的未来下一步在把数据数据工作的vessels里面会写很关键的一些问题我们碰到另一个挑战就是怎么max the mean increase我们cluster的research utilization我们在实际operatevessels里发现我们的service cluster里面cputilization其实是远远对于整个allocation的result在有的时候在allocation达到60%到70%的时候cputilization有时候可能只要10%到20%但是我们这个其实是一个比较正常的现象因为很多service都需要overallocate这样的话他们如果用salon的traffics back或者daily traffic pattern的话它可以有足够多的results buffer去take this traffic去take additional traffic但是我们就在想我们能不能够用其他方式同时increasecluster utilization我们现在也在messels我们现在也在实验messels里面over subscription feature这个over subscription就是说我们想要想要allocate比我们cluster里面更多的results给我们上层的framework比起让这framework用revocable的方式跑一些low parttask在上面我们也试着写的我们已经是写了一些简单的poc的results estimatorql controller module但是我们觉得我们现在的实验肯定是过于简单可能还需要还需要很多的一些进步如果有市区里有公司对或者谁对这方面的project感兴趣我们也可以讨论一下这方面长期来给它怎么做而且我们在这方面我们发现我们可能现有的现有的escalation mechanism肯定也是不足以完全使我们做比较复杂的做比较复杂的overfiltration比如说我们希望我们可能需要cpu-setnuma的这种一些的escalation的机制或者是我们肯定是需要disk-io或者network-io的一些escalation的机制并且还有一点就是我们需要我们需要在我们的customer run更多的best effortrevocable比如说it's a batchstream processing或者数据处理的一些工作以上就是我今天想要分享的东西有什么问题吗之前看到你们用1.0里面的event stream来做服务发现的我有个问题是有时候你应用本身可能精神气起来但是它并不一定是available的极端一点的情况比如说我预热要几十秒但是我精神气起来在methods看来肯定task已经是start应议服务发现的开始的时间比如说for a waiting time这是个很好的问题我们最近其实在fighting这边一些相关的basic logic因为其实methods里面task update如果你用因为我们跑的东西里面都有customized security所以我们的customized security的话status update是从security传出来的比如说arrowed security的话在task刚开始的时候我们传了一个task starting event我们我们现在的实现里面并不把在task starting the stated taskbrought ready from the zookeeper 里面只有在arrowed executor在对相关的tasktask health check 之后这个task state还有transition of task running the state我们只会把task running the task写到 zookeeper 里面这就保重在 zookeeper 里面发现一个新的task 的时候这个task 已经是可用的但是这个可能和其他executor的实现有关所以我们可以看我们可以offline sync一下比如说default executor或bid executor的实现是什么样子有没有过那种情况就是说在一个大型的环境里头我并不是一个纯粹的container环境我同时虽然我是一大别的Linux的主机但是我还要支持KVM上面的训练机这样的话container和训练机在同样一样一个大规模的发生一些运行然后results管理怎么做我们公司是没有什么训练机的我们在container以前所有的process直接基本上我跑在Linux环境上来的所以我们并没有直接处理这方面工作的经验不好意思感觉就到这里如果有什么大家有什么想要我讨论的我们可以自己来讨论一下谢谢