2019年, 有一篇关于的文章被发表了: “Cloud : A View on ”, 它把带入到大家的视野之中。它带来了几大核心挑战:1. 资源粒度是小的, 不同的是, 传统虚拟机所提供的是一个机器的资源抽象, 而这里提供的是一个应用的资源抽象, 甚至是一个函数的资源抽象。2. 飞速冷启动, 给出了按照需求去申请资源, 依据所用数量来支付费用的方式, 得按照需求申请, 要马上回应3. 具备海量的并发情况, 按照需要来进行申请 当使用完毕之后就立即销毁这样的模式 这说明每一次进行请求的时候 它对应的是后台要有一次真正的资源创立 而且并发量比传统的虚拟机超过千倍还要以上。传统的云计算IaaS是针对虚拟机负载设计的, 其资源粒度、冷启动速度以及并发能力, 都远低于要求, 早期腾讯云的做法是, 在传统虚拟机之上构建一个预创池, 通过成本换体验, 不过这带来了成本过高的问题, 比如0.的资源需求却实际占用1C1G的虚拟机资源, 还有大量闲置的预创资源, 同时体验也不佳, 像预创池打穿后回归虚拟机体验这种情况。成为Cube以下简称“Cube”系统设计初衷的, 是去建设一个以原生方式来解决难题的体系结构。核心设计1.1 分布式调度 单机装箱分布式调度, 是由中心来进行的调度, 本地装箱, 则是每个节点的调度, 调度由这两部分构成, 这两部分能够线性平行扩展整个系统的并发能力, 都可以做到这点。Cube 能够达成分布式调度, 所依据的两个前提与其他系统的集中式调度不一样: 其一, Cube 的资源层里每个节点非常大大配置裸金属或者虚拟机, 联合 Cube 自身的轻量化高密设计单节点超出 1K 的沙箱密度, 单节点具备充足的能力来容纳些许的调度偏差其二, 负载的生命周期一般不长, 处于单节点上的始终是处于动态变化的状况。并且, 要是单机装箱确实没法满足, 仍然能够反馈至调度层进行重新调度来兜底。1.2 资源池化 单机闭环单机装箱属于节点内本地闭环的操作, 所有沙箱所需资源要提前完成预准备并进行池化, 沙箱的生产是从各类资源池中取出资源予以拼装的过程, 这般设计加快了沙箱的启动速度, 与此同时降低了节点内不同沙箱并发生产时的路径碰撞, 提升了单机的并发生产能力。1.3 前后端解耦沙箱里面的系统, 它是完全没有状态的, 所有状态均保存在虚拟化的后端, 这就使得沙箱批量克隆的技术设计得到大幅简化。1.4 快照恢复 lazy load所有在Cube系统之下的沙箱, 皆是依据模板恢复来创建的, 沙箱里面系统的无状态情形, 极大地简化了此地的工作, 在Cube沙箱的生产进程里面, 沙箱自身的恢复以及后端配置的刷新能够并发开展, 在百毫秒以内就能够从端到端把一个可服务的沙箱交付完成, 基于快照恢复的沙箱生产逻辑链路十分短, 降低了沙箱并发生产时的资源抢占以及逻辑碰撞, 这成为Cube单机并发能力得以提升的一个关键要素。以快照作为基础展开的启动方式, 还暗中包含了 EPT 页表的 lazy load 机制, 这里面, 所有快照未曾 touch 的沙箱内存, 都是按照需求去建立 EPT 映射的, 把所有应当操作的事情, 延迟至真正呈现出需求之时再去开展, 这同样是确保启动速度的一项关键设计, 并且, 这个思想, 也于 Cube 系统的多个设计里得以体现。于高IO性能之硬件直通情形而言, 业界之举措乃是预先把沙箱之内存全然PIN住以构建DMA映射关联, 借此便利硬件予以访问。然而此等做法会极大地对沙箱之启动速率产生影响, 并且启动速率与沙箱内存规模紧密相关。Cube自行研发了基于之PVDMA技术, 于硬件切实需要访问内存之际方才去构建DMA映射关联, 把硬件直通沙箱之启动延迟依旧把控在百毫秒层级, 而且IO性能基本并无影响。1.5 资源复用 按需申请Cube 系统的设计目标是, 所有只读存储, 且整节点都只存储一份, 通过这种方式, 在沙箱内外打通, 沙箱内部的存储实际上都是由外部统一提供, 这里其中涵盖了沙箱自体, 一些等等的容器镜像等, 对于大多数性能不敏感的场景, 我们甚至使得只读存储里的 page cache, 同样的整节点也是仅有一份。源自同一个内存快照文件而克隆出来的沙箱, 运用mmap方式来共享内存快照, 其在本质上会共享内存里未曾被修改的部分, 就拿内核的代码段来说, 在启动完成之后基本上就不会再有修改, 这种情况使得整个节点能够共享一份内核的代码段, 如此一来单沙箱因而至少能够节省30M的内存消耗。沙箱是基于同一个磁盘快照文件克隆而成的, 它借助特定方式共用同一个磁盘文件, 要知道真正的磁盘块是在真实写入确实发生之际才会进行真实分配的。单个沙箱视角下, 所有这些优化带来的资源节省或许极为有限, 然而鉴于我们要打造一个高密度系统, 整个节点层面可节省超过10%的内存, 并且在实际业务场景里, 存储空间消耗能直接减少超过90%。1.6 全栈锁优化很多小细节得到了优化, 这些优化逐渐积累, 如同聚沙成塔一般, 最终为Cube系统在单机超高并发状况下以及高并发情形下的时延稳定性, 筑造了相当不错的基础。1.7 原生安全沙箱的内部属于不可信任的区域, 它被完全交付给用户去使用, 所有跟内部敏感系统的交互, 以及资源的准备工作, 都是在沙箱的外部来完成的, 而内部与外部借助硬件虚拟化的方式实施隔离, Cube基于自研构建了高性能的内外通信通道, 以此来用于沙箱内外的协作。所有经过沙箱的网络, 必然是受限的, 沙箱所有被动请求, 都得经过, 只有匹配到转发规则的, 才会被转发到沙箱内所有沙箱主动外访, 也都得经过这些检测, 所有沙箱网络IO, 同样必须经过节点上设定的那个环节才能达成。不管沙箱实现的是被动访问, 还是主动访问, 都必然会经过特定的网络节点这一情况, 为后续审计以及网络策略控制等能力扩展, 预留了空间。1.8 复用虚拟机资源Cube运用KVM虚拟化技术以保障安全隔离能力, 然而嵌套虚拟化存有性能损耗过大的状况, 因此行业中类似的轻量虚拟化技术皆运行于物理机上, 这会大幅削减Cube可利用的资源, 为解决此问题, Cube依据社区的PVM方案加以改良与优化, PVM基于PV技术给出完整的linux内核虚拟化方案, 不依赖硬件虚拟化, 相较于嵌套虚拟化无需L0虚拟化辅助L1虚拟化, 且提供更短的EPT虚拟化路径。1.9 总结通过以上的设计, 我们最终塑造了一个拥有高密特性具备高弹性机能, 拥有高并发能力的虚拟化体制:从 到 Agent首先, 从去年起, AI应用开始渐渐从“对话式”朝着“执行式”发展, 其次, 作为执行大模型生成代码的代码沙箱, 其对于高弹性以及高并发依旧有着非常高的要求, 然后, 执行环境的安全隔离能力, 变成了Agent沙箱最基础的要求, 最后, Cube之前服务场景所打磨而成的高并发、高弹性、强安全隔离能力在Agent场景仍有发挥作用的地方。2.1 极速的代码执行场景Agent代码执行的场景当中, 底层沙箱是需要具备快速启动的能力的。并且, 底层沙箱还需要具备高并发的能力, 才可满足该场景需求。在元宝代码执行接入了那基于 Cube 沙箱所精心打造的 AGS 产品之后, 其体验相较于友商而言, 也已然有了大幅度的提升。2.2 高并发的 RL 场景在 RL 场景当中, 需要把大量沙箱同时拉起, 以此来对结果进行验证, 这对于大规模并发能力有着很高的要求。在 RL 场景里, 搭配一个具备高吞吐特质的分布式存储, Cube 的高并发能力展现出极为显著的优势, 有某外部头部大模型客户运用立方对应的商业化版本, 在短短1分钟之内能够拉起数量达数十万的实例, 处于行业领先地位, 极大地提升了 RL 训练的效率。2.3 块级去重 按需加载的镜像加速系统采用共享的分布式存储, 很好地化解了 RL 场景海量镜像的难题, 然而与此同时, 却带来了两个方面的问题: 其一, 镜像之中大部分内容是一样的, 造成了大量存储空间的浪费其二, 单节点的高并发短生命周期沙箱创建, 会给后端共享存储带来极大的 IO 吞吐冲击。Cube 自行研发了镜像加速系统, 用以处理这两个问题, 其一, 镜像分块后进行去重操作, 以此解决重复内容存储的问题, 其去重效率相较于传统的 layer 级去重而言, 要远远高出许多其二, 具备块级的三级缓存按需加载机制, 能够减少对后端存储的吞吐压力其三, 大部分镜像采用低成本的 COS 存储, 使得成本大幅下降。2.4 基于快照的分支克隆Cube 系统之中, 最关键的技术里, 有快照技术, 在 Agent 场景下, 快照技术能适用于更多场景, 比如说, 给一个运行中的沙箱拍快照, 接着进行 1: N 的 Clone 来做分支探索任务, 又或者, 凭借快照保存特定的任务状态, 将其作为后续其他任务的一个状态起始点。2.5 面对 Agent 的安全与防御当沙箱的使用者, 从由人编写的程序这一主体, 转变成为Agent过后, 安全性以及防御性, 就变成了需要着重考虑的要点所在。Agent的行为秉有着概率属性, 根本没有办法做出预先的预测, 这与以人编写的程序存在着差异, 那种程序能够借助大量的事前相关手段, 去确保行为与预期相契合, 而Agent仅仅只能通过事中或者事后的手段, 才能够达成这一保证,这对于Infra的安全能力以及防御的能力来说, 提出了更为高层的要求。2.5.1 安全扩展Cube系统具备原生的沙箱安全能力, Cube系统具备原生的网络安全能力, 这两方面是可以进一步扩展的能力:首先, 沙箱内存在一种完全硬件隔离的 OS 环境, Agent 任何行为所产生的影响域被局限于沙箱内部沙箱内有着内核级的敏感行为采集并且配合以高性能的沙箱内外通信通道, 这能够实现对 Agent 高危行为的审计, 后续还可以进一步拓展成为针对 Agent 高危行为的准入控制。对于沙箱而言, 其被动访问路径必定会经过某一点, 凭借这一点能够拓展准入安全策略的能力沙箱的主动访问路径一定经过某一点和另外一点, 这两点均可导出流量以此扩展准出安全策略, 还具备像敏感信息注入这样的高阶安全能力。2.5.2 防御能力事件级的无感快照和回滚即将开源Agent 的那些不可预期的行为, 有可能造成严重的影响, 这影响对于个人而言, 或许会是文档资料被彻底删除, 其对企业来说, 可能是数据库内容遭删除, 哪怕即使辅以再严格的事中安全策略也是难以避免这种情况发生的, 所以呀, 系统的事件级快照和回滚能力, 就成为了面对 Agent 用户时的关键设计环节。针对沙箱来讲, 就得让我们拥有事件级别的环境快照能力, 这里面是涵盖着可写磁盘快照的, 以及内存快照的。有着这样一种诉求, 要满足那种高频次, 且对用户基本没有感知的快照能力, 为此 Cube 设计并实现了一套 CoW 存储 , 把该诉求达成了。借助的途径是把该存储里块存储的索引, 以及实际的数据块分离开, 如此一来, 快照的过程就仅仅是复制一份数据块索引而已 , 实际的数据块呢, 只有在真实写入的时候, 才会按照 CoW 的方式真实分配, 从而达成了百毫秒级别的海量环境下的快照能力。这套有关的机制为沙箱的事件级快照回滚提供了很不错的基础。这种事件级的快照以及回滚能力, 不应当仅仅被限定于沙箱之上, 最终是要扩展至整个 Agent Infra, 从而形成整个 Agent Infra 所特有的那种事件级快照以及回滚能力, 以此为整个 Agent Infra 在面对 Agent 的不可预测行为之际, 提供足够强大的防御能力。展望在系统上运行的逻辑, 从由人类编写的程序变成 Agent 后, 诸多方面都发生了改变。其中极具典型性的改变在于, 整个运行的基础由此前人类精确约束的逻辑机器, 转变成为了一个概率性的运行时。并且, 与这个体系的交互方式, 也从约定俗成的通信协议, 转变成了自然语言。Agent 本身的能力, 还随着 LLM 能力的进化而产生变化, 呈现出此消彼长的态势。这已然是一个全然不同的世界, 而且处于飞快的变化之中。然而, 当下承载着这个飞速演进的应用形态的基础设施并没出现特别大的改变, 在4.9发布的Agent大概能够被视作一个不错的起始点, 跟完全由虚拟机/容器独自承载整个Agent不一样, 它把Agent解耦成为: 有着决策与执行循环的大脑, 包含执行环境、工具等的双手, 还有不可变持久化数据、可重放的会话, 期望每一个独立的Agent请求均运行在完全独立的沙箱环境里。Cube 正在着手打造的事件级快照回滚能力, 分支探索能力, 强安全控制能力等方面, 或许能够形成为“大脑”的一个颇为良好的载体。Cube 历经多年打磨所具备的“极快启动能力超大并发能力, 超高密度能力”等技术方面, 或许可以充当为“双手”的一个最为适宜的匹配。我们也会把 Cube 系统完完全全地向行业进行开源, 期望我们这些多年始终持续打磨与建设的能力能够给行业 Agent Infra 的发展奉献出一份力量。Cube 开源项目地址- /: , , for AI .今日好文推荐