OpenAI 工程师讲述存储平台多租户循环：当工作负载成为云服务商的异常值

OpenAI 的存储平台 Habitat 经历了从多租户到单租户再回到多租户的完整循环。三名技术成员 Jon Lee、Hrachya Hakobyan 和 Chaomin Yu 在 2026 年 10 月 23 日发布的工程博客中，详细记录了这一循环背后的原因和代价。文章的核心判断不是某个具体的性能数字，而是一条更普遍的规律：当一家公司的规模大到使自身工作负载成为云服务商基础设施中的异常值时，'托管服务'就变得不再那么托管了。

Habitat 是 OpenAI 所有产品（ChatGPT、API、Codex 及内部服务）依赖的在线存储平台，需要在 40 个地理区域以毫秒级响应服务超过 10 亿用户，管理超过 500 PB 数据。其底层存储使用 Azure Cosmos DB。第一阶段，团队完全依赖 Cosmos DB 的原生多租户能力：每个账户只使用一个默认容器，让所有产品共享。这很快暴露了三个问题。

第一个问题是逻辑分区键冲突。由于早期 API 设计将逻辑分区键的选择权直接暴露给客户端，不同产品用例频繁使用相同的键名（如 user_id 或 workspace_id），导致同一用户的跨产品请求共享同一分区配额，约束了整体吞吐量。第二个问题是噪声邻居。文档中声称的逻辑分区键 10K RU/s 上限实际上由物理分区执行，而多个逻辑分区键共存于同一物理分区，一个冷门产品功能的后台批量操作可以拖慢核心登录和注册流程。第三个问题是弱分区：随着数据量增长，物理分区分裂，总吞吐量不变但每分区可用容量减半。对于存储密集型用例，仅数据增长本身就会降低活跃工作负载的吞吐能力，即使请求速率保持稳定。

第二阶段，团队转向为关键新用例创建独立容器，实现工作负载隔离。这在一定程度上缓解了分区键冲突和噪声邻居问题，但带来了新的组织性失败。独立容器意味着每个产品团队必须自行负责容量规划。在共享容器中，一个用例从 0 QPS 增长到 100 万 QPS 对总用量影响微乎其微；但在独立容器中，这可能意味着 1000 倍的基线跳变。产品团队经常忘记在上线前预扩容，团队不得不在发布日坐在事故响应室里临时调整容器参数。更根本的是，这种模式要求每个产品团队都具备对 Azure Cosmos DB 配置细节的深入了解，与 Habitat 平台'让产品开发者不需要理解数据库'的设计目标直接矛盾。

第三阶段，团队重新回到多租户，但这次是与 Azure 团队联合工程的结果。具体修复包括：热键限流（优先限制最热键的吞吐，防止单键耗尽物理分区全部容量）、请求分级 QoS（将批量插入和数据导出等离线工作负载标记为低优先级，确保交互式请求不被挤占）、以及 Azure 团队专门为 OpenAI 构建的改进版 Serverless 模式，允许每个物理分区扩展到 10K RU/s 并引入基于 RU 用量的分裂（而非仅基于存储用量），从而消除了手动监控和扩容容器的需要。

文章中最值得读者注意的判断出现在'托管服务'一节。作者写道：'当公司增长到 OpenAI 的规模时，托管服务变得不再那么托管了。许多工作负载成为云服务商基础设施中的异常值。'他们举了 2024 年底两次真实事故为例：一次区域停电导致故障切换需要数小时（双方团队此前都未在此规模下测试过）；另一次在回切过程中，网关模式客户端的一个缺陷导致所有连接涌向原区域，压垮了网关。这些事故暴露的不是某个 bug，而是双方团队在测试和运维模式上的系统性不匹配。

此后，Habitat 与 Azure 工程团队建立了深度联合运维模式：共享测试环境和仪表盘、直接工程通道（通过 Teams 互相呼叫，绕过支持层级）、共同拥有只在 OpenAI 规模才出现的故障模式、在预生产环境中使用生产规模的 Cosmos DB 账户进行变更验证。过去一年中，双方共同完成了控制平面和网关可扩展性改进、元数据缓存、连接池优化、工作负载共置以及通过不同 VPC 隔离关键与离线工作负载等工作。

在性能层面，团队开发了一套分层读优化策略（读请求占 Habitat 总流量的 90% 以上）：将最延迟敏感的小型数据集（如认证元数据）高度复制到多个区域；在靠近用户请求处理位置部署 Valkey 分布式缓存；通过 Azure Cosmos DB 变更数据捕获（CDC）在数秒内全局传播缓存失效（参照 Meta 的 TAO 系统模式）；以及用 Rust 重写 Habitat 服务本身以消除代理开销。这些措施将全球读 p50 延迟从约 120 毫秒降至约 10 毫秒。