10億人を超えるChatGPTユーザーに対応するためのオンラインストレージの急速なスケーリング(後編)

OpenAIのすべての製品には、高速かつ信頼性の高いデータアクセスが必要であり、それは当社のストレージプラットフォームであるHabitatによって提供されています。Habitatは、40の地理的リージョンにわたる10億人を超えるユーザーに対して、ミリ秒単位で応答しなければなりません。当社のインフラストラクチャは、爆発的な成長と新しいユースケースをサポートしながら、信頼性、パフォーマンス、そして製品開発の速度を向上させ続けるという、並外れた課題に直面していました。この課題を解決するには、オンラインストレージプラットフォームの設計と運用のあり方を見直す必要がありました。私たちはトレードオフを絶えず評価し、「まずミッションクリティカルな製品トラフィックに耐えうる十分な信頼性を確保し、次に世界中のユーザーにとって十分な速度を実現し、最後に大規模なスケールでも機敏に運用できるようにする」というパターンに従って進めました。

この2部構成のシリーズでは、私たちがどのようにHabitatをシンプルなクライアントライブラリとデータベースから、500ペタバイトを超えるデータを扱うグローバルに分散したストレージプラットフォームへと発展させたかを説明します。 第I部 では、HabitatがPythonクライアントからサービスへと進化した過程に焦点を当てました。また、Pythonベースのサービスを、多くの人が実用的だと考える範囲をはるかに超えて押し進めることを可能にした技術についても取り上げました。

本記事である第II部では、基盤となるストレージコンポーネントであるAzure Cosmos DBをどのようにスケールさせたかを解説します。Azureチームとの緊密なパートナーシップを通じて、共同管理されたコンテナによる実現可能なマルチテナンシーのアプローチにたどり着き、大規模かつグローバルなスケールで優れた読み取りパフォーマンスを達成しました。

マルチテナンシーを大規模に確実に実現する

企業が拡大するにつれ、インフラチームはシングルテナントシステムの運用からマルチテナントシステムへの移行を進めることがよくあります。すべてのプロダクトサーチームが自前のシステムを維持するシングルテナancyは、影響範囲を狭め、容易な所有権の境界とワークロードの分離を提供します。しかし、チームやプロダクトサーフェスが成長するにつれて、これは運用コストが高くなります。シングルテナンシーではすべてのプロダクトチームがキャパシティプランニングの責任を負うことになり、しばしば大幅な過剰プロビジョニングにつながります。

逆に、マルチテナンシーではリソースのプロビジョニングについてより高度な知識と経験を持つ中央集権的なデータベースチームに管理を任せます。しかし、マルチテナンシーはノイジーネイバー問題など、独自の問題を生み出します。これは、あるテナントが異常に大きなリソースを消費し、他のテナントに悪影響を及ぼす問題です。

Habitatでは、大規模で信頼性が高く効率的なストレージシステムを設計するために、これらすべてのトレードオフを検討する必要がありました。今日、Habitatは多くのOpenAI製品向けのマルチテナントデータベースレイヤーですが、そこに至るまで、単一のマルチテナントAzure Cosmos DBコンテナを使用する段階から、シングルテナントのバッキングコンテナをプロビジョニングする段階を経て、デフォルトでマルチテナントコンテナに戻るという、循環的な道のりをたどりました。Habitatにおけるマルチテナンシーの取り組みはまだ始まったばかりです。多数のユースケースをサポートしていますが、可能な限りAzure Cosmos DBの組み込みプリミティブを活用することで、この領域への投資を先送りできています。

Azure Cosmos DBコンテナの簡易入門

Azure Cosmos DBの道のりを説明する前に、いくつかの基本的な背景情報を示します。

• Azure Cosmos DBアカウントは、一連のコンテナとレプリケーションポリシーを定義します

• 各コンテナには、秒あたりのリクエストユニット(RU/s)で一定量のスループットがプロビジョニングされます

• 各コンテナ内のデータは、指定された論理パーティションキーによるシャーディングという典型的な方式で保存され、論理パーティションキーごとのストレージとスループットには公表された制限があります

• Azure Cosmos DBは、論理パーティションキーをより少数のバッキング物理パーティションにまたがってシャーディングし、ストレージが閾値を超えた場合や、プロビジョニングされたスループットを維持するためにコンテナがより多くの物理パーティションを必要とする場合に、それらを複数の物理パーティションに分割します

フェーズI:Azure Cosmos DBプリミティブへの依存

当初は、論理パーティションキーあたり10K RU/sという公表された制限に依存してバックプレッシャーを提供し、あらゆるクライアントの負荷を通過させていました。開始時点では、各アカウントでデフォルトのAzure Cosmos DBコンテナを1つだけ使用していました。これは十分に機能しましたが、いくつかの理由で問題があることが判明しました。

論理パーティションキーの制限

初期のAPI設計の選択により、論理パーティションキーの選択をクライアントに直接公開していました。その結果、 user_id や workspace_idといった、よく使われるパーティションキーで異なるプロダクトユースケース間で頻繁に衝突が発生しています。これらのユースケースが同じ論理パーティションキー上でAzure Cosmos DBの制限を共有していたため、この設計は特定のユーザーの全体的なスループットを制約していました。

HabitatとAzure Cosmos DBに移行する前にPostgresをスケールさせる際に直面した一般的な問題のひとつは、非常にホットな組織やホットなキー(不釣り合いに高い負荷を生み出すテナント)からの多数のリクエストがデータベース全体をダウンさせてしまう可能性でした。その結果生じるキャッシュミスの負荷が基盤のデータベースを圧倒しないよう、これらのキーをキャッシュし、キャッシュミスにリースを組み込むために、多大な労力が費やされました。

ノイジーネイバー

公表されたデータサイズとスループットの制限は論理パーティションキーに適用されますが、実際に制限が適用されるのは物理パーティションです。実際には、これは論理パーティションが10,000 RU/sに到達できないことを意味します。代わりに、論理パーティションは、その物理パーティション上に共存する他のすべての論理パーティションキーと物理パーティションの制限を共有します。

そのため、ノイジーネイバーが多くの無関係な論理パーティションキーに影響を及ぼし、ニッチなプロダクト機能のデータに対するワークロードが、コアとなるログインやサインアップのフローを妨害することがありました。

弱いパーティション

特定の物理パーティションのスループット制限は可変であり、Azure Cosmos DBコンテナに割り当てられた総スループットに依存します。コンテナのプロビジョニングされたスループットは、そのコンテナの物理パーティション間におよそ均等に分配されます。

データ量が増えると物理パーティションが分割され、総プロビジョニングスループットは変わらないままパーティションの総数が増加します。その結果、パーティションあたりの実効スループット制限は、データサイズの増加に伴って縮小していきます。

最もストレージ負荷が高くblob的なユースケースでは、リクエストレートや使用量が安定していても、ストレージの増加だけでアクティブなワークロードのスループット容量が低下するという障害モードが生じます。

フェーズ II: ワークロード分離とシングルテナンシーの試行

コンテナーを分けることは、これらのパーティションキーの制限やノイジーネイバーの問題を部分的に解決する助けになります。別々のコンテナーを使用することで、それぞれに独立した物理パーティションを割り当てられ、そのコンテナー自体上の変動するワークロードだけがノイジーネイバーになったり、パーティションキー空間で重なったりする可能性があります。一方で欠点として、新しいコンテナーのプロビジョニングにはゼロではないオーバーヘッドが伴います。各コンテナーには個別の容量計画が必要なため、コンテナーの作成は意味のあるサービスやユースケースの境界でのみ行いたいところです。

私たちは、強い分離を必要とする最も重要な新しいユースケースのために、独立した Azure Cosmos DB コンテナーを使い始めました。各コンテナーにプロビジョニングされた合計スループットをその物理パーティション数と同期させることで弱いパーティションを管理するスクリプトと組み合わせることで、直面していた問題のほとんどを回避できました。

しかし、デフォルトコンテナーから開始していたため、多くのレガシーな重要ユースケースがデータ移行なしではそこに留まってしまっていました。依然として共有デフォルトコンテナー内のデータに依存している重要なサービスを保護するため、新しいサービスや主要な製品機能向けには別のコンテナーを作成するようチームに何度も助言しました。私たちがスケールするにつれ、デフォルトコンテナーへの負荷が高まり、本番環境のインシデントも増加しました。デフォルトコンテナーをこれ以上の負荷から守るため、新しいサービスや大規模な製品機能のためにコンテナーをプロビジョニングするようになりました。

これにより多くのサイト全体に及ぶ障害を回避し、影響範囲を機能やサービスの劣化による障害に限定できました。しかし、新しいコンテナーのプロビジョニングのオーバーヘッドが最終的に私たちを追い詰めました:

安定した集計増加の欠如

古い共有デフォルトコンテナーでは、特定の新しいユースケースが 0 QPS から 100万 QPS に成長しても、合計の集計使用量を大きく変えることはほとんどありませんでした。しかし分離されたコンテナーでは、新しいユースケースが 0 から 100万 QPS に成長すると、社内のドッグフーディングのみに起因するベースラインの 1,000 倍の負荷を表す可能性がありました。

専用コンテナーでは、チームはローンチに向けて期待されるスループットレベルまでコンテナーを事前にプロビジョニングすることを忘れないようにする必要がありました。製品チームは機能を本番環境にリリースしたまま事前のスケーリングを忘れることが多く、ローンチ当日に土壇場でコンテナーをスケールアップしようと SEV ルームに座り込むことになりました。

これはマルチテナントシステムの、ワークロード混合によるコアな利点であり、このコンテナー戦略によってより良い分離と引き換えに失うものです。

キャパシティプランニング

時間が経つにつれ、専用コンテナの使用状況を監視するには、トラフィックがいつ変化または成長するかを見極めるための、製品に対する深い知識も必要になりました。

成長傾向に基づいて各コンテナのプロビジョニングされたスループットをスケールアップする基本的なコントロールプレーンのスクリプトは提供できますが、安定した総合的な成長がなければ、これらを正しくスケーリングすることは、事実上 OpenAI のすべてのプロダクトチームがキャパシティプランニングに関わることを意味しました。

この方式では、各サービスの担当チームが Azure Cosmos DB のプロビジョニングに払う注意の度合いに大きなばらつきがあり、組織としてスケールしませんでした。

フェーズ III: データ移動機能を備えた、マルチテナンシーをデフォルトとする運用

組織が成長するにつれ、これらの運用上の問題はスケールが難しくなりました。計画を担当する単独の中央チームが存在しなかった結果、多くのチームが不十分な計画を立てることになりました。そのため、私たちはマルチテナント方式のソリューションへと方針を戻し、Azure チームと緊密に連携して、共有テナンシーの設計によって当初のマルチテナンシーの問題を修正する取り組みを進めました。

ホットキーのスロットリング

最もホットなキーを最初にスロットリングすることで、ノイジーネイバーが特定の物理パーティションで利用可能なスループットをすべて消費することを防ぎます。これにより、1 つのホットキーがサイト全体に影響を及ぼしうるノイジーネイバー効果が軽減されます。

サービス品質 (QoS)

リクエストの階層化による QoS は、バルク挿入やデータ抽出などのオフラインワークロードが特定の物理パーティションのスループットをすべて利用することを防ぎます。これらのワークロードのリクエストに低い優先度を割り当てることで、それらが最初にスロットリングされ、エンドユーザーにサービスを提供する優先度の高いインタラクティブなリクエストがスロットリングされるのを防ぎます。

サーバーレスモード

Azure Cosmos DB にはすでにサーバーレスモードがあり、それを使えばプロビジョニングモードにおける弱いパーティションの問題は解決できたはずでした。しかし、大きな欠点がありました。それはストレージ使用量のみに基づいてスケールし、物理パーティションあたりの RU 使用量が 5K RU/s に制限されていたことです。これは弱いパーティションの問題を解決する一方で、RU を大量に消費するユースケースをスケールアップすることを妨げていました。

Azure Cosmos DB チームが私たちのために構築した新しい改良版サーバーレスモードでは、すべての物理パーティションが 10K RU/s までスケールアップ可能になり、ストレージ使用量に基づく分割に加えて RU 使用量に基づく分割が導入されたことで、コンテナを手動で監視およびスケールアップする必要がなくなりました。

これらの変更により、単一の共有コンテナを使用する運用に戻すことができ、ワークロード間の分離を維持しながら、プロダクトチームにおける事前または継続的なキャパシティプランニングの必要性を大幅に簡素化できました。その後の数か月間、製品開発が加速しているにもかかわらず、プロビジョニングやノイジーネイバーに関するインシデントは一件も発生していません。

共同管理サービスとしてのより高い信頼性

企業が OpenAI の規模に成長すると、マネージドサービスは「マネージド」ではなくなっていきます。多くのワークロードがクラウドプロバイダーのインフラストラクチャにおける外れ値になります。OpenAI が Azure Cosmos DB の最大級のユーザーの一つになるにつれ、これを成功裏に運用するには、異なるモデルが必要でした。すなわち、共有テスト、共有ダッシュボード、直接のエンジニアリングチャネル、そして私たちの規模でのみ現れる障害モードの共同所有です。今日、私たちの最大の Azure Cosmos DB アカウントは 10s of petabytes のデータを保存し、20M QPS 以上を処理しています。私たちの知る限り、この規模で Azure Cosmos DB をデプロイしている企業は私たちだけです。

2024 年後半、リージョン障害が発生し、この協力がなぜ必要であったかが明らかになりました。当時、私たちの最大級の Azure Cosmos DB アカウントの一つが使用するプライマリの Azure リージョンで停電が発生しました。その結果として行われたフェイルオーバーの演習で、最大のアカウントをセカンダリリージョンにフェイルオーバーするには数時間かかることが判明しました。これは私たちのチームにとっても Azure Cosmos DB チームにとっても、この規模でテストしたことのないものでした。

約 1 か月後、それらのアカウントを元のリージョンにフェイルバックしている際に、さらに深刻な障害を引き起こしました。元のリージョンへの接続のスタンピードが、元のリージョンの Azure Cosmos DB ゲートウェイを圧倒したのです。ゲートウェイモードの Azure Cosmos DB クライアントがフェイルオーバーを処理する方法にあった特殊な挙動により、物理パーティションのごく一部しかそのリージョンに戻っていないにもかかわらず、すべてのクライアントが即座に接続を確立して元のリージョンにリクエストを送信しました。

それぞれの障害において、OpenAI と Azure の双方がインシデント管理プロセスを実行し、複数の根本原因が特定され、修正がデプロイされました。しかし、これらの障害は、私たちのチームと Azure Cosmos DB チームの運用およびテストの方法の間にある、より大きな体系的な問題の症状でした。当初、マネージドサービスを活用することで、私たちは迅速に動き、ビジネス目標に集中することができました。しかし規模が大きくなると、マネージドサービスは「マネージド」の度合いが下がり、設計から運用に至るすべてのレベルでサービスプロバイダーとの深い統合が必要になります。

今日、Habitat と Azure のエンジニアリングチームは、サービスレイヤーから Azure Cosmos DB の物理ストレージレイヤーに至るまで、Habitat のあらゆるレイヤーを共同で監視しています。私たちは本番相当だが本番ではない Azure Cosmos DB アカウントに対して変更の運用とテストを行っています。SDK について共にテストと反復を行い、Azure Cosmos DB アカウントのスケーリングとサイジングのベストプラクティスを決定しています。Teams を通じて互いに直接エンジニアリングアクセスを行っており、サポート階層を経由せずに互いを直接ページできる仕組みさえ整えています。

過去 1 年間で、Azure Cosmos DB のコントロールプレーンとゲートウェイのスケーラビリティを向上させるための多大な共同作業が行われました。具体的には、Azure Cosmos DB のメタデータパーティションを保護するためにゲートウェイに負荷保護と各種 Azure Cosmos DB メタデータのキャッシュを追加したこと、コネクションプーリングとより高いコネクション再利用によって Python の habitat-service プロセス群からの負荷を軽減したこと、可能な場合にはワークロードをコロケーションしたこと、そして異なる VPC を使って重要なワークロードをオフラインワークロードから分離したことが挙げられます。

このレベルの共同エンジニアリングは、過去 1 年間の Azure Cosmos DB の安定性にとって極めて重要でした。十分に大規模で重要なシステムであれば、この種のチームワーク、すなわち所有権の壁を取り払い、組織の境界を越えて運用することが必然的に求められます。

グローバル規模でのパフォーマンス向上

Part Iで述べたように、私たちの中心的な哲学は「まず動くようにする、次に速くする、そして安くする」というものです。まず信頼性、次にパフォーマンス、そして効率性です。HabitatはOpenAIにとって重要なインフラとなっていたため、最優先事項は信頼性を高めることでした。2025年にシステムが安定し、OpenAIがグローバルに拡大するにつれて、レイテンシがユーザーと製品チームにとって次の制約となりました。

コンピュートとストレージのキャパシティはしばしば別々のリージョンに配置されており、リージョンをまたぐリクエストが避けられませんでした。

レイテンシは、データがどこに保存され、リクエストがどこで処理されるかによって大きく異なりました。Habitatリクエストのパフォーマンスを高めるため、製品開発者はクライアント側の追加キャッシング、リクエストのバッチ処理、データベースの読み書きの最小化、そして可能な限りクリティカルパスから処理を外に移すことに頼っていました。これはデータベースの問題に対してより耐性のある興味深い製品設計を生み出す一方で、製品をより複雑にし、製品のイテレーションを遅らせました。これは、高速な製品開発を促進し、データベースを理解する必要をなくすというHabitatの目標の達成失敗を意味します。

これは2026年における私たちの大きな焦点となっており、Habitatのリクエストの90%以上を占める読み取りパフォーマンスを最適化するための階層型戦略を開発しました。

キャパシティが許せばユーザーの近くにデータを保存する

私たちは、データレジデンシー要件を持つユーザーのために、世界中の異なるAzureリージョンに複数のAzure Cosmos DBアカウントを保有しています。厳格なデータレジデンシー要件のないユーザーに対しても、ユーザーの近くにデータをコロケーションすることで、低いレイテンシにより体験が向上します。

実際には、配置は物理的なクラウドのキャパシティに制約されるため、データレジデンシーのユースケース以外でこれを広く実現することはできません。データセットの規模のため、多くのリージョンでは、ユーザートラフィックの比例分に必要な巨大なストレージフットプリントを収容できません。

データセンターのキャパシティ、電力、冷却が限られているリージョンでは、時に直接的なトレードオフに直面します。コロケーションされたストレージのためにキャパシティを確保してHabitatのレイテンシを下げるか、そのキャパシティを追加のサービング用コンピュートに使い、ストレージリクエストを遠くにルーティングするかの選択です。

その結果、配置の決定はしばしば、A) 異なる製品やユーザーサブセットのためのレイテンシの最適化と、B) 生のストレージおよびコンピュートのキャパシティとの間の製品トレードオフとなります。

最小かつ最もレイテンシに敏感なデータセットのみを広くレプリケートする

すべてのリクエストで必要とされる認証メタデータのような、最もレイテンシが重要なワークロードに対しては、多数のセカンダリリージョンを持つ高度にレプリケートされたAzure Cosmos DBアカウントを使用することで、コンピュートとHabitat間のRTTを削減しています。一部のアカウントは、トラフィックを提供しているすべての40のAzureリージョンにレプリケートし、他のアカウントは各大陸で少なくとも1つのリージョンにレプリケートしています。

異なるレプリケーショントポロジを持つアカウント間でデータセットを移動できるよう、私たちは望んだ時期より早く、Habitatに透過的なデータ移動およびルーティング層を構築しなければなりませんでした。

しかし、このアプローチも結局はキャパシティに制約されるため、少数の手作業で選ばれたデータセットに限定されます。

それ以外は統合キャッシングに依存する

Habitatのワークロードは圧倒的に読み取り中心であり、アプリケーションは設定、状態、その他のプロパティを絶えず取得しています。トラフィックの不釣り合いな割合が、頻繁にアクセスされる型の比較的小さなワーキングセットに起因しています。このため、このシステムは分散キャッシングに特に適しています。キャッシングは単一リージョンのインフラでパフォーマンスを向上させますが、リージョンをまたぐ作業では、リージョン間レイテンシを「隠す」ために使用できるため、その改善は複合的に効果を発揮します。

私たちは分散型ルックアサイドキャッシング層をHabitatに統合しました。これは、ユーザーリクエストが処理される場所の近くにある私たちのインフラに配置されたValkeyサーバーに、最近アクセスされたオブジェクトとエッジのコピーを保存します。通常、この種のキャッシュは、ヒット率と鮮度のトレードオフを調整するTTLを使用します。短いTTLは鮮度を保ちますが、項目がキャッシュからすぐに失効しより頻繁に取得する必要があるため、キャッシングの好影響を鈍らせます。長いTTLはヒット率を向上させますが、長期間古いデータを提供し続け、劣悪なユーザー体験と予測不能な製品動作につながります。

もう一つのアプローチは、アプリケーションが同じ基盤データに対して書き込み操作を行う際に、明示的な無効化操作を実行することです。これによりキャッシュされたデータの鮮度が大幅に向上しますが、正しく実装するのは難しい場合があります。また、部分的な障害など、キャッシュを陳腐化させる多くのエッジケースの影響も受け続けます。マルチリージョンデプロイでは、信頼性の低いリージョン間ネットワークや、基盤ストレージのレプリケーションとのキャッシュの競合により、これらの問題が悪化します。これにTTLを組み合わせれば最大の陳腐化を制限できますが、上述のTTLトレードオフという根本的な問題は残ります。

私たちはMetaのTAOのようなシステムの先例に倣い、より高度な無効化のアプローチを採用しました。Habitatの統合キャッシュは、Azure Cosmos DBのチェンジフィードを通じた変更データキャプチャ（CDC）に依存して無効化を数秒以内にグローバルに伝播させ、高いヒット率を達成しながら陳腐化を低く抑えています。私たちのインフラ内のサービスがこのチェンジフィードを消費し、基盤データが更新された際にローカルキャッシュへの無効化を実行します。これにより、次にデータが読み取られるときにキャッシュミスが発生し、キャッシュには最新バージョンのデータが格納されます。

Rustでプロキシのオーバーヘッドを削減

また、元のPythonより高性能なRustでコードを書き直すことで、Habitatサービス自体のオーバーヘッドを取り除き、レイテンシを大幅に削減しました。

これらの変更を合わせることで、グローバル全体のread p50は約120 msから約10 msに削減され、今年初めにパフォーマンスに注力し始めて以来、12倍の改善となりました。

キャッシングにより中央値のレイテンシは大幅に削減されましたが、最も遅いリクエストでは依然として、キャッシュされていないデータを基盤となるストレージから取得する必要があり、多くの場合遠く離れたリージョンをまたぐことになります。より多くの容量がオンラインになり、ストレージ効率が向上するにつれて、私たちはより根本的な課題、すなわち最初からデータをアクセスされる場所の近くに配置するという課題に取り組む予定です。

Change Data Captureのスケーリング

信頼性とスケーラビリティを備えたCDC—データベースの変更を下流システムへ伝播すること—は、Habitatのキャッシング戦略だけにとどまらない重要なコンポーネントです。毎秒数百万件のキャプチャされた変更が、数千のコンテナと数百万のコンテナパーティションを横断して100以上のKafkaトピックに流れ込み、結果整合性のあるセカンダリインデックス、データ移動パイプライン、オフライン分析、その他のリアルタイム製品機能にも電力を供給しています。基盤インフラがグローバルに成長するにつれ、行の変更をリッスンすることはますます複雑になっています。クライアントが自分の型の行が変更されるたびに実行されるコールバックを登録したい場合、少なくとも、どのCosmosアカウントとコンテナに自分のデータが含まれているか、それぞれのリージョンでそれらのコンテナをリッスンしているどのCDCサービスデプロイメントが稼働しているかを特定し、CDCサービスのワーカーフリート、Kafka、および自身のコンシューマを適切にスケーリングしなければなりません。私たちのCDCプラットフォームは、これらすべてを製品開発者から抽象化し、代わりに、クライアントが変更された行に対して呼び出してほしい関数を登録すれば、配管やスケーリングのすべてを私たちが処理するというシンプルなサーフェスを提供することを目指しています。

内部のコントロールプレーンが、必要なすべてのコンテナがキャプチャされていることを継続的に保証し、どのCosmosリージョンから読み取るかを選択し、複数の地理的リージョンにわたる数千のワーカー間で作業を効率的に分散させます。レプリカリージョンと低優先度のフィード読み取りを使用することで、レイテンシに敏感なHabitatのトラフィックをバックグラウンドのキャプチャワークロードから保護しています。ワーカーのクラッシュ、コンテナの問題、リースストアのエラー、無効な構成、宛先の障害は、これほど大きなフリートでは絶えず発生します。私たちはCDCワーカーのライフサイクルとリース処理を強化し、ストリーム間で障害を分離し、構成変更とロールアウトのための安全策を構築しました。永続的な配信失敗によるヘッドオブラインブロッキングを防ぐためにデッドレターキューを利用しています。リージョンの障害には、リーダーを代替のCosmosリージョンに切り替えることで対応しています。当社の規模では、AzureのCDC SDKのチェックポイント実装を、チェックポイントをインメモリでバッチ化し定期的にのみフラッシュすることでより効率的にする変更さえ行う必要がありました。

HabitatのAzure Cosmos DBの内部利用は複雑ですが、その価値提案は一貫して、製品開発の速度を向上させるためにインフラの詳細を製品開発者から抽象化することであり、私たちのCDCプラットフォームも同様です。

今後の展望

小さなチームでも、ストレージAPIを意図的に狭く保ち、Pythonサービスをスケールし続け、最も緊急のエンジニアリング課題に優先順位を付けることで、急速に成長するストレージプラットフォームを支えることができました。私たちはまずミッションクリティカルな製品トラフィックの信頼性に、次にグローバルユーザー向けのreadパフォーマンスに、最後に大規模運用の効率性に焦点を当てました。このアプローチにより、信頼性、パフォーマンス、製品開発速度を向上させながら、急速な成長と新しいユースケースを実現することができました。

次の十億人のユーザーに向けてHabitatと会話ストレージをスケールするためには、さらに大規模にインフラ全体でデータをレプリケートする難しさに対処する必要があります。これに先手を打つため、私たちはHabitatの大きなデータ型に最適化された、社内開発のエクサバイト規模のオンラインストレージシステムを構築してきました。開発中のこのシステムは、RocksetのRocksDB CloudコアとRaftベースのレプリケーションを組み合わせたものです。Azure Cosmos DBと同じドキュメントモデルを実装していますが、ディスアグリゲーテッドストレージと物理レプリケーションを使用して必要なフラッシュ容量を削減し、その代償として低いピークqpsを受け入れています。

フロンティア規模でのこの種のデータインフラの取り組みに興味がある方は、 当社の公開中の求人をぜひご覧ください⁠.