快速扩展在线存储以服务超过10亿ChatGPT用户

# 快速扩展在线存储以服务超过10亿ChatGPT用户 来源：https://openai.com/index/scaling-storage-one-billion-users-part-one/ OpenAI的每款产品都依赖于对数据的快速可靠访问，无论是用户登录、检查Codex设置，还是在ChatGPT中开始新对话。每个操作背后可能需要进行多次独立的数据查询，产品才能响应。如果这些请求缓慢，产品就会显得卡顿；如果这些请求失败，产品将完全停止工作。 Habitat是我们构建的在线存储平台，旨在让OpenAI产品能够快速可靠地访问所需信息。如今，Habitat每秒处理超过7000万次请求，支持每周使用人数超过10亿的多款产品，覆盖近40个地理区域。两年前，Habitat起步于一个简单的Python客户端库，连接着单一数据库。今天，它已演变为一个复杂的分布式系统，服务着超过500PB的数据。 图01 · 什么是Habitat？ ## 在线存储平台 Habitat是我们构建的在线存储平台，旨在让OpenAI产品能够快速可靠地访问所需信息。 - 请求 - 响应 - 变更（CDC） 在此规模上构建和运维基础设施绝非易事，但也并非特别具有挑战性。使我们处境独特的是，为了支持惊人的用户增长和产品需求，我们必须以前所未有的速度进行扩展，同时还要构建一个成熟的平台。通常，系统工程师会为10倍规模进行构建，并希望其能维持数年，同时为下一个10倍规模做准备。而在我们这里，过去三年里规模每年增长都超过10倍。因此，构建和运维Habitat成为了一系列战术决策和优先排序：深入理解每个组件的底层细节，以最大化利用现有技术栈的价值，同时应对存储和计算能力的紧缺，为基础投资争取时间。 - 每秒7000万+请求 - 每周10亿+用户 - 500PB+数据 随着OpenAI的发展，Habitat也必须随之成长：首先变得足够可靠以支撑关键任务流量，然后足够快速以服务全球用户，最后，能够高效地在巨大规模下运行。本文是我们关于在线存储扩展的两部分系列文章的第一篇。在这篇文章中，我们将分享Habitat如何演进，我们为何将其从库转变为服务，以及我们如何将一个用非主流服务语言——Python编写的服务，扩展为一个可靠的存储平台层。 在后续文章中，我们将详细介绍如何实现大规模多租户可靠性、优化读取性能的分层策略，以及我们如何扩展与Azure Cosmos DB的合作以可靠地处理前所未有的需求。 ## 什么是Habitat？ Habitat源于一个简单的理念：产品工程师无需关心数据库管理。Habitat始于2024年中期，最初是一个与ChatGPT主服务器交互的小型Python库。它支持一小部分操作，这些操作在底层映射到数据库应用Azure Cosmos DB。 该库的任务是为产品团队提供一种简单的方式来存储和检索数据，而无需掌握底层细节。Habitat负责处理必要工作：确定涉及何种数据、数据应从哪里来（或去）、请求是否被允许等等。 产品工程师无需关心模式查找、路由、授权、加密、序列化、请求整形和连接池。他们甚至不需要考虑数据来自哪里：是Azure Cosmos DB、缓存还是其他类型的存储。 图02 · Habitat服务 ## 简化的Habitat请求流程 通过将存储逻辑解耦为独立服务，我们为部署、可观察性和平台增强建立了单一的控制点。 - 请求 - 响应 这个Python库运行良好，Habitat在OpenAI的产品工程师中迅速得到采用，尽管当时并没有进行集中的推广来替代自助使用的Postgres和Azure Cosmos DB。 随着产品需求的演变，产品开发者也很容易为共享库添加对客户端缓存、压缩或加密等特性的支持。 ## 构建服务以更好地支持多个复杂产品 到2025年中期，Habitat作为客户端实现的局限性已显现。随着Habitat层变得更加复杂以及OpenAI服务数量的增加，向后兼容的协议更改变得不可行。 例如，我们曾希望通过将最关键的数据集迁移到一组区域分布的Azure Cosmos DB账户中，来减少单个区域故障的影响范围。进行此更改需要在客户端引入额外的路由逻辑（通过功能标志控制），确保其滚动部署到所有客户端，然后启用该功能标志。 协调数十个服务的部署并与每个团队协作进行部署，耗费了数天时间。在启用之前，我们意识到需要引入一些流量镜像，以确保分片逻辑正确。这又花了几天时间进行部署。为修复一个我们后来发现的错误又需要几天时间。最终，我们准备好启用标志时，其中一个团队却因无关原因将其服务回滚到了一个之前有缺陷的客户端版本，导致了我们极力避免的故障。 对客户端库的更改需要跨数十个服务进行复杂的协调，这个过程被证明越来越脆弱、低效且容易出现操作故障。为了减少未来部署的这种操作扩散，我们决定将Habitat抽取为独立服务。 通过将存储逻辑解耦为独立服务，我们为部署、可观察性和平台增强建立了单一的控制点。我们不再需要管理分散的更新，而是可以集中实施改进，从而让每个OpenAI产品立即受益。 集中式服务还为我们提供了一个单一的控制点，以提供最强大的数据安全和隐私基础能力。Habitat服务是我们可以集中实施访问控制策略、执行审计日志以及限制对底层存储资源（如Azure Cosmos DB）访问的地方。Habitat在保护用户数据和防止来自外部、内部和代理行为者的未授权访问方面起着关键作用。 ## 大规模推出Python服务 我们知道需要一个服务，但并不想立即脱离Python，即使Python作为服务存在额外开销。与本地库执行相比，使用Python构建高吞吐量服务会增加网络延迟，并带来显著的CPU和内存扩展成本。而且，我们认识到Python的效率低下在100倍规模下将变得不可接受，因此最终重写几乎是必然的。 然而，我们将此视为技术债务的战略性侵入。我们当时的主要目标不是成本或资源优化，而是为产品开发者扫清障碍并实现平台稳定性。通过短期内接受Python服务的性能权衡，我们得以优先解决更紧迫的挑战、建立核心API并构建强大的基础设施。 我们还做出了一个经过深思熟虑的押注：我们自己编码模型的快速进步将在未来简化技术路径。我们赌的是，等到需要完全脱离Python时，Codex和GPT将使迁移变得可行。这个押注最终被证明是正确的。 以Python服务运行Habitat在性能上并非最优，但却是一个必要的选择。Python让我们能够快速行动，但这并不意味着我们可以不加谨慎地接受显著更高的延迟。当平均用户请求导致数百次数据库调用时，最慢的那一次数据库调用就是用户实际感受到的延迟。我们发现，在如此规模下运行Python服务的主要挑战在于管理这些尾部延迟。 ### 跟踪asyncio延迟 Asyncio帮助Python并发执行I/O密集型工作负载，但无法绕过Python全局解释器锁（GIL）提供CPU并行。除了I/O密集型的请求代理外，Habitat还处理许多CPU密集型职责和后台任务：路由、压缩、加密、校验和、下游健康检查、请求镜像和对冲。 在我们的服务中有如此多的CPU密集型工作负载和后台任务，asyncio调度延迟很容易主导尾部请求延迟。在为初始服务启动进行调优之前，我们在p99及更高延迟请求的追踪中发现，虽然下游存储响应很快，但请求经常在等待负责的协程被重新调度以解析响应时停滞不前。 图03 · 跟踪asyncio延迟 ### 并发不等于CPU并行 Python asyncio允许并发请求处理，但在任意时刻，只有一个请求在CPU线程上执行。当有大量CPU工作需要完成时，这对请求延迟有重大影响。 CPU请求/响应处理 Python网络读写 等待Cosmos #### 低CPU工作量 简短的Python步骤；I/O等待重叠 #### 高CPU工作量 冗长的Python步骤使准备就绪的响应等待 示例时间 0.0 / 40示例单位 对于OpenAI的Python服务，我们发现除了衡量内存、CPU、网络和磁盘使用情况的标准利用率和饱和度指标外，监控asyncio事件循环及其繁忙程度也至关重要，然后据此进行调优。 通过定期调度后台任务并记录预期与实际执行时间之间的差值，我们能够实时经验性地测量事件循环调度延迟。在高利用率下，许多昂贵的任务即使与每个进程适度数量的并发请求结合，也足以产生显著的调度抖动，最高可达数百毫秒，在某些边缘情况下甚至达到数秒。 因此，我们不得不让每个进程仅服务少量并发请求，转而大规模扩展Python工作进程的数量。 ### 降低功能标志配置中的尾部延迟 在初始服务启动期间，我们通过实时服务CPU性能分析，发现高asyncio延迟（以及随之产生的高尾部延迟）的一个根本原因：通过Statsig（一个管理功能标志的工具，可用于运行A/B测试等）周期性解析我们的功能标志配置。 默认情况下，Statsig被配置为每分钟无抖动地轮询刷新配置，且配置包含了每个服务的所有生产规则。另外，在架构决策中，我们选择在每个Pod中运行多达8个Python进程以提高CPU使用率并提供更低的延迟。综合起来，这意味着每分钟每个Pod都会有某个时刻，所有工作进程停滞处理进行中的请求，转而花费CPU周期解析一个巨大的配置文件。 一旦CPU性能分析帮助我们找到了根本原因，修复就很简单：部署一个更小的针对性配置，延长刷新间隔，并为这类后台任务添加一些抖动。 ### 平衡负载和管理连接池 为了保持较低的asyncio延迟，保持跨服务器进程的良好请求负载平衡也至关重要；连接池配置不当可能适得其反。 使用客户端连接池时，一个执行大量并发请求的客户端进程可能只建立少量服务器连接，结果将其所有负载仅发送到少数几个进程上。在调整负载平衡方式之前，我们的服务存在利用率方差较大的问题，一些尾部进程服务的并发请求数量是平均水平的5-10倍。 我们在一次偶然事件中发现了这个问题：尽管停止了过载我们部分服务的客户端，但部分进程的降级状态在突发流量后仍持续了很长时间。事实上，我们注意到这些进程经历了失控的降级，接收到越来越多的请求，直到我们重启它们。一旦一个Pod过载，某种行为会将更多流量固定到这个过载的Pod上。这是我们的队友从之前工作中非常熟悉的一类故障：亚稳态故障（新窗口打开） (https://engineering.fb.com/2014/11/14/production-engineering/solving-the-mystery-of-link-imbalance-a-metastable-failure-state-at-scale/)。 我们怀疑是连接池的问题，并通过限制最大连接重用时间来验证这个怀疑，这确实限制了降级情况，并证实了我们的调查方向。进一步调查发现，Python的aiohttp TCPConnector默认使用后进先出（LIFO）的连接重用策略：选择最近返回的连接用于下一个请求。这通常是一个合理的默认值：重用最近的连接允许为处理突发流量而创建的额外连接超时闲置，从而减少维护额外连接的开销。但在本案例中，它为我们创造了一个亚稳态故障。在请求突发期间，对较慢过载服务器的请求会更晚将连接返回到连接池，因此更可能被后续请求选中，逐渐将更多流量集中到已经苦苦挣扎的Pod上。修补连接池以使用先进先出（FIFO）重用打破了这个反馈循环，甚至减少了我们稳态下的请求方差。 图04A · 客户端连接池 ### LIFO将新工作发回慢速进程 在请求突发之后，较慢的服务器最后将连接返回池中。LIFO鼓励更多工作集中在这些较慢的服务器上。 一次初始突发请求到达A、B和较慢的进程C。 图04B · 客户端连接池 ### FIFO打破连接重用反馈循环 FIFO在突发后维持更多活动连接，但在所有服务器间公平平衡工作负载。 一次初始突发请求到达A、B和较慢的进程C。 如今，我们主要依赖Istio和Envoy在整个OpenAI基础设施中提供连接池和更优的服务器感知负载平衡策略，从而完全避免这个问题。 ### 避免淹没下游资源 为降低asyncio延迟并运行如此多Python进程带来的一个副作用是，庞大的连接数量非常容易使下游依赖不堪重负（即所谓的“惊群效应”）。 一次常规的每日部署——如果没有调优为慢速启动——可能因连接循环而导致严重的CPU抖动。或者一个连接泄漏可能通过耗尽NAT网关的带宽来影响整个网络。这些问题对其他服务也不罕见，但由于进程数量多了一个数量级，触发阈值显著降低，常常使网络相关资源饱和，而客户端仅凭稳态吞吐量预期并不需要处理这些。 我们还依赖Envoy来最大化我们的连接扇入。我们用它将Python的HTTP/1连接升级到HTTP/2以利用多路复用，然后对这些连接进行池化并延长连接生命周期。Envoy还为我们提供了一个集中实施速率限制和断路器的地方，如果分散在各个独立的Python进程中，这些措施的效果会大打折扣。 图05 · 连接扇入 ### 相同的请求，更少的连接 连接池和HTTP/2连接多路复用有助于减少下游的连接负载。 请求响应空闲保活 ## 为什么选择