毎秒2200万リクエスト、10億人のChatGPTユーザーを支える裏側で、OpenAIはHabitatというストレージ基盤を運用しています。もともとは社内向けのPythonライブラリだったものを、グローバル分散のプラットフォームへと作り替えた事例です。テスト戦略やリリース手法の観点から何を学べるか、整理してみます。
対象読者は、急成長中のプロダクトでバックエンドの信頼性を担保する立場にあるQAエンジニア・SRE・バックエンド開発者を想定しています。トラフィックが桁違いに伸びる局面で、テストとリリースの仕組みをどう見直すか、考える材料になれば幸いです。
何が起きたのか、なぜ注目に値するか
Habitatは当初、社内のさまざまなサービスがデータを読み書きするための、単純なPythonライブラリでした。
それが数年のうちに、毎秒2200万リクエストを捌く分散ストレージプラットフォームへと進化しています。
注目すべきは、単なるスケールアウト（サーバー台数を増やして負荷を分散する手法）の話ではない点です。
ライブラリという「単一プロセス内で完結する仕組み」から、ネットワーク越しに複数ノードが協調する「分散システム」へと、アーキテクチャの前提そのものが変わっています。
この変化は、テストのやり方・品質の測り方・リリースの進め方すべてに影響します。
段階的に何が変わったのか
ライブラリ形態のときは、呼び出し元のプロセス内でHabitatのコードが直接実行されていました。
この場合のテストは比較的シンプルです。関数の入出力を検証する単体テスト（ユニットテスト）が中心になり、ネットワーク遅延やノード障害を考慮する必要はほとんどありません。
分散プラットフォーム化すると、状況が一変します。
クライアントとストレージノードがネットワークを介してやり取りするため、タイムアウト・部分的な失敗・リトライといった「分散システム特有の異常系」が発生します。
たとえば、あるノードへの書き込みが成功したのに、その直後の読み込みが別のノードにルーティングされて古いデータを返す、というケースが考えられます。
こうした整合性の問題は、単体テストでは検出できません。
複数ノードを実際に立てた統合テスト環境や、意図的に障害を注入するカオステスト（システムに人為的な障害を起こして耐性を確認する手法）が必要になります。
さらにリクエスト数が毎秒2200万という規模になると、平均的な応答時間だけでなく、p99（全体の99%がその時間以内に収まる遅延値）のようなテールレイテンシの指標が重要になります。
少数の遅いリクエストがユーザー体験全体を損なうためです。
関連技術との比較で見えてくること
この「ライブラリから分散サービスへ」という進化は、決して目新しいパターンではありません。
古くはGoogleの内部インフラ、近年ではNetflixのマイクロサービス化などでも、同様の道筋がたどられてきました。
日本の開発現場に置き換えると、モノリシックなRailsアプリからマイクロサービスへ分割していく過程に近いイメージです。
この移行でよく語られる技術に、サーキットブレーカー（障害が起きたサービスへの呼び出しを一時的に遮断する仕組み）やリトライのバックオフ戦略があります。
Habitatのような大規模ストレージ基盤でも、こうした耐障害性のパターンがテスト対象として重要になっているはずです。
CI/CDパイプラインの観点では、変更のたびに全ノード構成を再現したテスト環境を回すのはコストが高くなります。
そのため、変更の影響範囲を見極めて「どのテストをどの段階で実行するか」を設計するテストピラミッド（単体・結合・E2Eの比率を最適化する考え方）の再検討が欠かせません。
単体テストを厚くし、実環境に近い統合テストは重要な変更点に絞って実行する、という配分が一般的な指針です。
リリース手法としては、カナリアリリース（新バージョンを一部のトラフィックだけに適用して様子を見る手法）や、フィーチャーフラグ（機能のON/OFFをコードデプロイと切り離して制御する仕組み）の活用が、この規模のサービスでは前提になっていると考えられます。
毎秒2200万リクエストという規模では、全トラフィックへの一括デプロイは、障害発生時の影響範囲があまりに大きくなるためです。
読者への影響と、今日確認できること
自分のプロジェクトが同じ課題に直面しているか、次の観点で確認してみてください。
- 呼び出し元と呼び出し先が同一プロセスか、ネットワーク越しかを整理する（ライブラリ的な依存か、サービス的な依存かの棚卸し）
- 障害注入テスト（意図的にノード停止やネットワーク遅延を発生させる試験）を実施できる環境があるか確認する
- 監視ダッシュボードでp50だけでなくp99・p999のレイテンシを可視化しているか確認する
- デプロイ手法がカナリアリリース・段階的ロールアウトに対応しているか、CI/CDパイプラインの設定を見直す
- リクエスト数の増加率をログやメトリクス基盤（Prometheus・Datadogなど）で定点観測し、スケール閾値を事前に定義しているか確認する
具体的な確認先としては、CI/CD設定ファイル（GitHub Actionsの.github/workflowsやGitLab CIの.gitlab-ci.ymlなど）で、デプロイ対象の割合を制御する設定項目があるかを見る方法があります。
また、負荷試験ツール（k6・Locust・Gatlingなど）の既存シナリオが、現在のトラフィック規模の何倍まで想定して作られているかも、確認しておく価値があります。
急成長するプロダクトほど、負荷試験のシナリオが半年前の想定のまま更新されていない、という状況は起こりがちです。
まとめ
Habitatの事例が示しているのは、ストレージ基盤がライブラリから分散サービスへ変わる過程で、テスト戦略もまた根本的に見直す必要がある、という点です。
単体テスト中心の体制から、統合テスト・カオステスト・テールレイテンシ監視への拡張が求められます。
リリース面では、全量デプロイからカナリアリリースやフィーチャーフラグを使った段階的ロールアウトへの移行が、規模拡大に伴う自然な選択肢になります。
手元のプロジェクトでまず着手できるのは、依存関係の棚卸しとp99レイテンシの可視化です。
そこから、障害注入テストの導入やデプロイ設定の見直しへと、一歩ずつ広げていく進め方が現実的です。