Databricks重构无服务器网络配置交付：延迟降低97.5%
译文 AI 逐段翻译
摘要
- Databricks 的无服务器平台每天启动数千万台虚拟机，每台虚拟机在服务客户工作负载之前都需要网络配置，例如允许的目的地和私有端点。每个节点在启动时获取配置并在其生命周期内轮询更新，这意味着每天有数十亿次网络配置请求。旧架构从多个上游服务同步获取这些配置，造成了延迟和可用性瓶颈。
- 我们使用事件驱动管道和快照预计算重新架构了网络配置交付，将 RPC 延迟降低了 97.5%（5000ms → 125ms），实现了 99.99% 的服务可用性。
问题陈述
Databricks 的无服务器计算平台支持我们几乎所有的数据和 AI 产品，例如 SQL 仓库、笔记本、ML 服务端点等。该平台每天在 AWS、Azure 和 GCP 上启动数千万台虚拟机。
在任何无服务器工作负载执行之前，虚拟机需要知道其网络配置：它可以访问哪些存储目标？是否有应路由流量的私有链接端点？Unity Catalog 中是否有最近更改允许访问新的存储目标？我们是否开始使用通过 Delta Sharing 共享的新目标？
挑战在于网络配置不存储在任何单一位置。它必须从多个上游服务组装，每个服务贡献完整图景的一部分。
旧架构
在原始设计中，每次无服务器集群启动时，我们的网络配置服务都会同步调用所有上游服务，聚合它们的响应，计算每个工作区的网络配置，并将其返回给无服务器数据平面。这发生在集群创建的关键路径上。
虽然旧架构简单且在小规模下运行良好，但这种架构存在根本性问题，反映在我们运营仪表板上跟踪的以下指标中：
- 延迟：由于多个上游服务位于关键路径上，提供网络配置的 RPC 延迟在 p99 时为 5000ms。这影响了无服务器集群的启动延迟。
- 服务器成功率：每个上游服务都有自己的可用性特征。多个服务串联时，复合可用性迅速下降，这意味着每年无服务器集群启动失败的可能性增加。
随着无服务器使用的持续快速增长，同步模型变得越来越不可持续。每次同步调用都会在所有工作区中触发昂贵的操作，通常进行重复计算。这增加的负载与租户数量及其配置的资源成比例增长。
解决方案：事件驱动预计算
我们对 Databricks 交付网络配置的方式进行了从头开始的重新架构。它基于以下核心原则：
- 事件驱动管道：新系统不是同步调用所有上游服务，而是通过消息队列订阅更改事件。当客户创建新的 Unity Catalog 连接或修改网络策略时，上游服务会发出事件。系统处理该事件并更新预计算的配置。
- 快照预计算：网络配置在后台异步计算并存储在预计算的快照存储中。服务路径变为一次简单的存储获取，与上游服务完全解耦。
- 静态稳定性：在任何上游服务中断的情况下，我们可以维护静态配置，为无服务器集群提供静态稳定性。
该架构清晰地区分了两条路径。管理路径在后台异步运行：上游服务将更改事件发送到消息队列，事件处理器消费这些事件以确定受影响的哪些工作区，并分发每个工作区的更新通知。本地事件管理器然后从上游获取相关细节，重新计算工作区的网络配置，并将结果存储在预计算的快照存储中。周期性的协调器还在后台重新同步所有工作区，确保最终一致性，即使事件丢失也不会漏。相比之下，服务路径是关键的且快速的：当无服务器集群启动并需要网络配置时，网络配置服务直接从快照存储中提供，只需一次存储读取，无需调用上游服务，并显著减少上游服务的负载。
关键设计决策
- 上游服务将更改事件推送到消息队列。系统在后台处理这些事件。低频协调器定期重新同步所有工作区作为安全网，提供了同步框架的可靠性和推送的效率。
- 网络配置在每个服务分区内本地计算和存储，与它们服务的工作区放在一起。这分散了计算，减少了事件期间的爆炸半径，并消除了服务路径上的跨分区依赖。
- 事件只携带工作区和资源标识符。这使事件保持轻量，使它们幂等（可以以任何顺序重放），并避免通过消息传递管道传输敏感的客户数据。
事件如何流动
当客户创建新的 Unity Catalog 连接时，Unity Catalog 会向消息队列发出变更事件。然后，事件处理器接收该事件，确定哪些工作区附加到受影响的元存储，并向外分发每个工作区的更新通知。在每个工作区的分区中，事件管理器接收此通知，获取更新后的连接详细信息，重新计算工作区的网络配置，并以新的版本标记存储。从那时起，当无服务器集群请求网络配置时，它会直接从快照存储提供，无需上游调用。
影响
推出新架构后，所有运营指标均发生了变革性变化：
| 指标 | 之前（旧） | 之后（新） | 改进 |
|---|---|---|---|
| 延迟（RPC p99） | 约 5,000 毫秒 | 125 毫秒 | 减少 97.5% |
| 服务器成功率 | 99.8% | 99.99% | 减少停机时间 |
除了关键指标之外：
- 上游调用量减少了 86%。系统仅在事件指示发生变化时才调用上游服务，而不是在每次请求时调用。
- 我们观察到网络配置的新鲜度有了显著改善。
- 旧版同步框架已完全弃用。
结论
这个项目教会了我们关于在云规模下运营网络基础设施的几个教训：
预计算解耦关键路径。通过将昂贵的聚合移到后台，服务路径变得非常简单和快速。这是最具影响力的架构决策。它将多服务依赖链转变为单一存储读取。
事件驱动架构以一致性换取可扩展性，而对账提供安全网。基于事件的推送有效处理常见情况，而定期协调器捕获任何遗漏的情况。
从第一天起就设计可扩展性。模块化、基于阶段的架构意味着为新的上游数据源添加支持仅需要一个新的阶段实现，对核心管道零更改。随着 Databricks 产品范围的扩大，网络配置系统也随之扩展。
如今，该系统每天为 Databricks 全球无服务器舰队提供数十亿次网络配置请求，延迟约 125 毫秒，可用性达 99.99%。随着无服务器计算的快速增长，事件驱动架构确保网络配置交付与之同步扩展。
我们一直在寻找喜欢应对全球规模分布式系统挑战的工程师。如果您对这类问题感到兴奋，我们期待您的加入，请查看 databricks.com/careers 上的空缺职位！