OpenAI Habitat存储架构演进：如何支撑十亿级用户的Azure Cosmos DB多租户优化

事件概述

OpenAI在其工程博客中发布了关于在线存储平台Habitat扩展的第二部分文章。该平台需为超过10亿ChatGPT用户在40个地理区域内提供毫秒级响应，管理着超过500PB的数据。本文重点阐述了如何通过优化底层Azure Cosmos DB数据库，解决大规模增长带来的可靠性、性能及开发效率挑战，并详细回顾了多租户架构设计的三次关键迭代。

核心信息

1. 多租户架构的演进路径

随着规模扩大，OpenAI在单租户（易于隔离但资源浪费）与多租户（资源高效但存在噪音邻居问题）之间进行了权衡，经历了以下三个阶段：

• 第一阶段：依赖Azure Cosmos DB原生原语

  • 初期使用单个默认容器，依靠每逻辑分区键10K RU/s（请求单位/秒）的限制进行背压控制。
  • 问题暴露：由于早期API设计允许客户端直接选择逻辑分区键，导致常用分区键频繁冲突；同时出现“噪音邻居”效应，即单一租户占用过多资源影响其他租户，以及弱分区导致的性能不均。

• 第二阶段：尝试工作负载隔离与单租户

  • 为解决上述问题，曾尝试为不同服务分配独立的单租户容器以实现隔离。
  • 局限性：缺乏稳定的聚合增长模型，导致容量规划困难，且运维成本显著上升。

• 第三阶段：默认多租户 + 数据移动能力

  • 最终回归多租户模式，但引入了数据移动能力和更精细的管理机制。
  • 关键技术点：
    • 热点键限流：针对高频访问键实施专门的限流策略。
    • 服务质量 (QoS)：确保关键业务流量的优先级。
    • Serverless模式：利用无服务器特性应对流量波动。
    • 共管理服务可靠性：通过与Azure团队协作，将容器作为共管理服务运营，提升了整体稳定性。

2. 全球性能优化策略

为了在全球范围内提升读取性能并降低延迟，Habitat采取了分层存储与缓存策略：

• 就近存储：在容量允许的情况下，将数据存储在靠近用户的区域。
• 最小数据集广泛复制：仅对最小且对延迟最敏感的数据集进行广泛的全球复制。
• 集成缓存：对于非关键或较大体积的数据，主要依赖内置的集成缓存机制（如Valkey）来加速访问。
• Rust重构代理层：使用Rust语言重写代理层代码，显著降低了网络请求的处理开销。
• 变更数据捕获 (CDC) 扩展：优化了CDC服务的扩展性，以支持Databricks、Rockset、Kafka等下游数据消费场景。

值得关注

• 技术栈混合：Habitat平台并非单一技术堆栈，而是结合了Azure Cosmos DB（在线存储）、Nanobase（在线存储）、Valkey（缓存）和Blob Storage（对象存储），并通过CDC服务连接分析型数据库。
• 合作模式：OpenAI强调与微软Azure团队的紧密合作是解决复杂分布式系统问题的关键，特别是在容器管理和资源调度层面。
• 架构反直觉性：尽管多租户通常被认为更具扩展性，但在极端规模下，OpenAI发现完全的单租户隔离不可持续，而纯粹的多租户又难以保证SLA，因此采用了带有动态数据迁移能力的混合多租户方案。