クラウド・インフラ

専用に割ったら破綻した——10億人規模のストレージ設計が、共有コンテナへ戻るまで

イーランサー・ジャパン株式会社
この記事の要点

OpenAIが公開したデータ保管の基盤は、10億人規模・500ペタバイト超、毎秒7,000万件の処理を担っています。用途ごとに保管領域を分ける設計へ移したものの、必要な容量を見積もる組織的な負担に耐えられず、再び共有する形へ戻しました。読み取りにかかる時間は約120ミリ秒から約10ミリ秒へ短縮され、要因は近い地域への複製、地域内での一時保存、処理部分の作り替えの3つです。

用語の説明
  • ペタバイト／データの量を表す単位で、よく使われるギガバイトの100万倍にあたる大きさです。
  • ミリ秒／1000分の1秒を表す単位で、画面や処理の反応の速さを測るときに使われます。

「ワークロードごとにコンテナを分ける」は直感的に安全な判断に見えます。ところが10億人規模で実際にやってみた結果は、隔離を得た代わりに別のものを失ったというものでした。そして「Rustに書き換えて12倍速くなった」という見出しの裏側では、配置とキャッシュのほうが大きく効いています。

目次
  1. 要点
  2. 規模が大きくなるとRU/sモデルが裏返る
  3. 専用コンテナは、技術ではなく運用で倒れた
  4. 共有へ戻る。ただし素の共有ではない
  5. 12倍の内訳——Rustは3分の1
  6. 読み取りは90%超。だから信頼性が先に来る
  7. なぜ日本でまだ語られていないのか
  8. エンジニアにとって何が変わるか
  9. 確認できなかった点
  10. 出典

要点

優先順位も明記されています。まず信頼性、次に速度、そして規模。

規模が大きくなるとRU/sモデルが裏返る

第1段階は単一共有コンテナでした。論理パーティションキーの選択をクライアントに開放したため、user_id や workspace_id で衝突が起きます。

制限は物理パーティション側で効くので、論理パーティションは隣人と容量を分け合うことになる。いわゆるノイジーネイバーです。

さらに厄介なのが、記事が「weak partitions」と呼ぶ現象です。

スケールアウトが、単一キーの天井を下げる。直感に反する挙動で、ここを知らずに設計すると「増やしたのに遅くなる」が起こります。

専用コンテナは、技術ではなく運用で倒れた

第2段階はワークロードごとの専用コンテナです。隔離は得られました。失ったのは集約による成長の平滑化です。

記事が挙げる具体例が分かりやすい。負荷試験で1K RU/sだった機能が、ローンチで1M RU/sに達したとき——

そしてより根本的な問題が起きました。容量計画がほぼ全チームのプロダクト知識を要求するようになり、これがスケールしなかった。

破綻したのは技術ではなく、運用の分担です。アーキテクチャ図の上では正しく見える分割が、組織の負債として返ってきた、という事例になります。

共有へ戻る。ただし素の共有ではない

第3段階は共有コンテナへの回帰ですが、前提装置が追加されています。

回帰後の数か月、プロビジョニング起因とノイジーネイバー起因のインシデントはゼロと報告されています。

ただしこの改良サーバーレスは、2026年10月29日時点のMicrosoft公開ドキュメント（最終更新2026年6月29日）では確認できません。公開ドキュメントは「サーバーレスコンテナ内の各物理パーティションは最大5,000 RU/sを処理できる」のままで、RU使用量ベースの分割についての記述もありません。一般提供なのか先行提供なのかは、Microsoftに確認すべき項目です。

12倍の内訳——Rustは3分の1

グローバル読み取りp50が約120msから約10msへ。この12倍を生んだのは3つの要因です。

  1. 重要データの近接リージョンへの複製
  2. リージョン内キャッシュ（Valkeyを使った分散ルックアサイド。無効化はCosmos DBの変更フィード（CDC）経由で数秒以内にグローバル伝播。参照先はMetaのTAO）
  3. PythonプロキシのRust書き換え

配置は一律ではありません。全40リージョンへ複製するアカウントと、大陸ごとに最低1リージョンのアカウントが混在します。広域複製には容量制約があり、一部データセットに限られるためです。

記事は寄与度を分解していませんが、言語の置き換えは可視化されやすく、配置とキャッシュは地味です。「Rustで12倍」という要約が流通しやすい理由がここにあります。

読み取りは90%超。だから信頼性が先に来る

読み取りはリクエストの90%超を占めます。だからこそ「まず信頼性」という優先順位になる。実際に2024年後半、2件の障害が記録されています。

フェイルオーバーよりフェイルバックで壊れる——マルチリージョン構成を持つ側には馴染みのある話で、復旧手順の検証対象として見落とされやすい箇所です。

なぜ日本でまだ語られていないのか

第1部（9月11日）は日本語で複数書かれました。ところがそれらはマルチテナンシーを「第2部の予定トピック」と挙げたまま終わっています。

英語側も「Rustと12倍」で止まった要約が多く、中国語の解説が先に出ている状況でした。weak partitionsや専用コンテナの失敗理由は、Cosmos DBのRU/sモデルを前提にMicrosoftのドキュメントと突き合わせないと意味が取れません。

エンジニアにとって何が変わるか

①設計

ワークロードごとにコンテナやクラスタを割るのは直感的に安全ですが、統計的多重化の利得を捨て、容量計画を全プロダクトチームに配ることになります。後者は技術的負債ではなく組織的負債として返ってきます。

共有に戻すなら、ホットキー抑制とQoSティアリングが前提装置になります。これを置かずに共有へ戻すと、最初の問題に戻るだけです。

もう1つの教訓は、12倍を生んだ3要因のうちRustが1つでしかない点です。「言語を変えれば速くなる」という要約は、投資判断を誤らせます。

②調達

Cosmos DBを使っているなら、分割でパーティションあたりのRU/sが割れる挙動を自分の構成で確認するのが今日の作業です。

そのうえで、物理パーティションあたり10K RU/sのサーバーレスとRU使用量ベースの分割が一般提供なのか先行提供なのかをMicrosoftに確認してください。公開ドキュメントは5,000 RU/sのままです。

ここから読める選択肢がもう一つあります。マネージドの限界を、乗り換えではなく共同エンジニアリングで押し広げる。規模のある利用者なら、交渉のテーブルに載る項目です。

③キャリア

NoSQLのパーティション経済、CDCによるキャッシュ無効化、ベンダーとの共同運用。この3つが並ぶ職能は、AI基盤を持つ組織で希少性が上がります。

次の方向も読めます。RocksDB CloudコアとRaft複製で、ドキュメントモデルは維持しつつストレージを分離し物理複製へ移す。フラッシュ容量は下がるがピークQPSは落ちるというトレードオフが明示されています。

確認できなかった点

出典

本記事は2026年10月25日時点で公開されている情報に基づき、Cosmos DBの公開仕様は2026年10月29日に再確認しています。性能数値はすべて発表側の自己計測であり、第三者による検証は確認できていません。

CONSULTATION

案件をお探しの方へ

イーランサーでは、専任担当がご経歴と希望条件を整理したうえで案件をご提案し、条件面の調整もお手伝いしています。すぐに稼働できる状態でなくても、情報収集としてご相談いただけます。

ご登録いただいた情報が企業に公開されることはありません。氏名・連絡先を伏せたスキルシートを使用します。登録から案件のご紹介、契約手続きまで費用は一切かかりません。

案件を見る
RELATED
プログラミングSQLとは何をする言語か操作する言語です クラウド・インフラデータ基盤・BIエンジニアの仕事と需要職種の解説です プログラミングバックエンド開発とはデータを扱う側の仕事です
← 記事一覧へ
案件をお探しの方 人材をお探しの方