何が発表されたか
- OpenAIは、自社プロダクトのデータ基盤「Habitat」に関する連載のPart IIを公開した。今回の主題は、基盤の中核であるAzure Cosmos DBのスケーリングである。
- Habitatは世界40リージョンで10億人超のユーザーにミリ秒単位で応答する必要があり、保存データは500PB超に達しているという。
- Cosmos DBの使い方は、(1)共有のデフォルトコンテナ、(2)用途ごとの専用コンテナ、(3)共有コンテナを基本とする方式、の3段階で変遷した。
- 3段階目では、ホットキーの抑制、リクエストの優先度制御（QoS）、Azureチームと作った改良版serverlessモードを組み合わせた。以後の数か月は、プロビジョニングやノイジーネイバーに起因する障害は起きていないとされる。
- 最大のCosmos DBアカウントは数十PBのデータを保持し、毎秒2,000万件超のリクエスト（QPS）を処理している。OpenAIは、この規模での利用は自社のみだと認識している。
ポイント解説
そもそも「マルチテナント」とは
マルチテナントとは、複数のサービスや利用者が1つのシステムを共有する設計のことです。反対に、サービスごとに専用のシステムを持つ形がシングルテナントです。共有にすると資源を無駄なく使えますが、ある利用者の大量アクセスが他の利用者の性能を落とす「ノイジーネイバー問題」が起こりえます。専用にすれば影響は隔離できますが、容量の見積もりや運用の負担が各チームに降りかかります。今回の話は、この古典的なトレードオフをOpenAIがどう乗り越えたかという事例です。
共有から専用へ、そして共有へ戻った
最初は1つの共有コンテナで運用していましたが、いくつかの弱点がありました。クライアントがパーティションキーを直接選ぶ設計だったため、user_idのような一般的なキーが複数の機能で衝突しました。また、制限は実際には物理パーティション単位でかかるため、周辺機能の負荷がログインやサインアップといった中核の処理に影響する場面もありました。さらに、データが増えて物理パーティションが分割されると、スループットが据え置きのまま分け合う形になり、1つあたりの上限が下がってしまいます。
対策として重要な機能は専用コンテナに分けたところ、サイト全体の障害は減りました。その一方で新たな問題が出ました。共有コンテナなら多数の用途が混ざって負荷が平準化されますが、専用コンテナでは新機能のアクセスがそのまま全体の負荷になります。公開直後に急増しても、事前にスケールアップを忘れていれば、当日に慌てて対応することになります。さらに、容量計画に多くのプロダクトチームが関わる必要が生じ、組織として回らなくなったと説明されています。
共有に戻すための3つの工夫
OpenAIはAzureチームと協力し、共有方式の欠点を機能面で補いました。
- ホットキーの抑制：負荷の大きいキーから先に制限をかけ、1つのキーが全体を巻き込むのを防ぐ。
- QoS（優先度制御）：一括投入やデータ抽出などのオフライン処理は優先度を下げ、ユーザーに応答する処理を守る。
- 改良版serverlessモード：既存のserverlessは、RU（処理量の単位）の上限が物理パーティションあたり5K RU/sに限られていました。新しいモードでは10K RU/sまで伸ばせるうえ、RU使用量に応じた分割も行われ、手動での監視やスケールアップが不要になったといいます。
つまり、隔離のために専用コンテナを増やすのではなく、共有したまま「影響を局所化する仕組み」をデータベース側に持たせた形です。
マネージドサービスを「共同管理」する
もう一つの注目点は、運用体制の話です。2024年後半には、リージョンの停電を受けたフェイルオーバーで、最大級のアカウントの切り替えに数時間かかると判明しました。その約1か月後、元のリージョンへ戻す際に、接続が一斉に集中して別の障害も起きたとされています。どちらも、この規模ではクラウド事業者側も十分にテストしていなかった領域でした。
これを受けて両チームは、本番相当の規模の非本番アカウントでの検証、SDKの共同改善、共通のダッシュボード、直接連絡できる窓口などを整えました。マネージドサービスは「任せきり」で済むとは限らず、規模が極端に大きくなると、提供側と利用側が一体となって運用する必要が出てくる、というのが本文の主張です。
なお、今回受け取った本文は、Azure側のコントロールプレーンやゲートウェイの改善を述べる部分で途切れています。それ以降の内容は、この記事では扱っていません。
どんな人に関係があるか
- 大規模サービスのバックエンドを設計する人：共有か専用かという判断は、多くの組織で直面する課題です。今回の事例は、専用化が運用負担を招き、共有を軸に隔離機能を足す方向へ戻った例として参考になります。
- Cosmos DBの利用者：論理パーティションキーの設計、物理パーティション単位で制限がかかる点、分割による実効スループットの低下などは、規模の大小を問わず確認する価値があると考えられます。
- クラウドの契約・運用を担当する人：規模が大きくなるほど、事業者との共同テストや直接のエンジニアリング窓口が重要になるという視点は、自社の体制を見直す材料になるかもしれません。
- AIサービスの裏側に関心がある人：チャットAIの快適さは、モデルだけでなく、こうしたデータ基盤の運用にも支えられていることがわかります。
まとめ
OpenAIはHabitatのCosmos DB運用で、共有から専用、そして共有へと方針を変えました。専用コンテナは隔離に有効でしたが、容量計画の負担が組織全体に広がったためです。共有に戻すにあたっては、ホットキー抑制、QoS、改良版serverlessモードで影響範囲を抑えています。また、極端な規模では、クラウド事業者との共同運用が欠かせないという教訓も示されています。自社のシステムに当てはめる際は、規模や要件の違いを踏まえて判断する必要があると考えられます。
出典: Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)（OpenAI）
※この記事はAIを活用して作成しています。正確な情報は出典元をご確認ください。
コメント