PerplexityがDynamoDB脱却！Rust自作DBでレイテンシ5分の1を達成

• Perplexityが検索サービング基盤をAWS DynamoDBからRust製独自KVストア「CobbleDB」へ完全移行した。
• 平均50KBの大容量バッチ取得に対し、RocksDBとAZ内優先ルーティングを用い、p99レイテンシを123msから24.2msへ短縮した。
• マネージドDBのコストと内部ブラックボックス化に苦しむ現場に、強烈な自作DB回帰とAIエージェント活用の新たな選択肢を示した。

深夜の障害対応でモニタリングツールを見つめながら、解決不能なテールレイテンシのスパイクに頭を抱えた経験は、多くのシニアエンジニアにあるはずだ。特にAWS DynamoDBのようなフルマネージド型データベース（RDB/KV問わず）は、立ち上げ初期には圧倒的な開発スピードを提供してくれる神のツールだが、スケールが特定の境界線を超えた瞬間に「高額で制御不能なブラックボックス」へと変貌する。

対話型AI検索エンジンを展開するPerplexityが直面したのは、まさにこの壁だった。同社のサービスが処理するトラフィックは秒間20万リクエスト（200,000 RPS）を超える。しかし、通常のWeb検索とRAG（検索拡張生成）などのLLM検索とでは、バックエンドで発生するリードパターンが根本的に異なる。一般的な検索エンジンであれば、検索結果として数文字のタイトルと数百文字のメタデータスニペットを返せば十分であり、ペイロードは数キロバイト程度で済む。だが、LLMにコンテキストとして注入するためのデータ抽出では、1クエリにつき100〜120個のターゲットページキーが生成され、それらを10〜20キーごとのバッチに分割して並列取得する。しかも、返すべきデータは単なるテキストではなく、チャンク化された文書本文や高次元の dense vector（密ベクトル）埋め込みであり、1レコードの平均サイズは約50KBに達するのだ。

この超高頻度かつ大容量パケットのアクセスパターンに対し、DynamoDBは財務的にも技術的にも耐えきれなくなった。AWSのDynamoDBは読み書きの転送バイト数に応じて従量課金されるため、毎秒20万リクエストで50KBのペイロードを流し続けば、クラウド破産を招くような請求書が届く。さらに致命的だったのは、DynamoDBの内部挙動が見えない構造的限界だ。パーティションの物理配置、インメモリキャッシュの割り当てポリシー、レプリカ間のルーティングアルゴリズムはすべてAWSのブラックボックス内にある。そのため、クロスAZ（アベイラビリティゾーン）のネットワークホップや、遅延しているレプリカからの応答、キャッシュ未ヒットのリードによって起きるテールレイテンシのスパイクを、エンジニア側で制御する手段が一切存在しなかった。

加えて、新しいチャンキングロジックや更新されたベクトル埋め込みモデルを適用するためのバッチ再処理ジョブを走らせると、大量のライトリクエストがDynamoDBに直接流れ込み、リアルタイムなユーザー検索に深刻なノイジーネイバー（近隣騒音）問題を引き起こしていたのである。インフラ担当者がどれだけプロビジョニング容量を積んでも、不透明なマネージドの壁に阻まれる——この構造的欠陥を打破するため、Perplexityは自社専用データベースのゼロベース開発という劇薬を選択した。

Perplexityのエンジニアリングチームが下した決定は、単にDynamoDBを別のNoSQLに置き換えることではない。ストレージアーキテクチャ全体を役割ごとに「Pillar」「Lorry」「CobbleDB」という3つのシステムへ明確に分離することだった。

永続データの管理とアトミックなトランザクション処理は、メカニカルHDD（HDDストレージ）上で動作する「YTsaurus」ベースの『Pillar』が担当する。ウェブのクローリング結果やメタデータ、ベクトル表現の書き込み処理はすべてここで行われる。次に、ステートレスなキューコンシューマーである『Lorry』が、Pillarからエクスポートされたデータをパーティション単位で整列したバッチファイルとしてAmazon S3に保存し、メタデータの通知のみを『CobbleDB』へ送る。そして、ホットなサービング層を担当するのが、独自開発されたRust製の分散KVストア『CobbleDB』だ。CobbleDBのワーカーノードはS3からバッチを独立して取得・インジェストするため、重いクローリングや再処理の書き込みパイプラインからサービング層が完全に物理隔離（アイソレーション）される仕組みを作り上げた。

CobbleDB内部の設計も、読取性能の極限化に振り切っている。組み込みストレージエンジンには信頼性の高いRocksDBを採用し、メモリマップドキャッシュとローカルの高速NVMe SSDを組み合わせた。パーティションごとに3つのレプリカを独立した計算ノードに分散配置。さらに、ステートレスなクエリルーターがハッシュ化されたページIDをマッピングし、同一AZ内にあるレプリカへとリクエストを優先ルーティングしてネットワークオーバーヘッドを削り取っている。もし特定のレプリカの応答が遅延した場合は、即座に別ノードのレプリカへ投機的並列読み込み（speculative hedging）を打つことで、テールレイテンシの跳ね上がりを強制的に抑え込んでいる。

以下のベンチマーク結果とプロダクション測定データを見れば、このアーキテクチャ刷新がもたらした圧巻のインパクトが一目瞭然だ。

CobbleDBがこれほどまでの高速化を達成できた最大の理由は、従来の分散データベースが金科玉条としてきた「厳密な同期合意アルゴリズム（Raft/Paxos等）」や「分散トランザクション」をあっさりと捨て去った点にある。検索サービングにおいては、ミリ秒単位の厳密な即時一貫性（Strong Consistency）は不要であり、数秒のレプリケーション遅延を許容する結果整合性（Eventual Consistency）で十分実用に耐える。レプリカがそれぞれのペースで非同期にバッチファイルをインジェストすることを許容した割り切りこそが、極限の低レイテンシを引き出す鍵となったのだ。

この記事の中で、私を含め世のシステムアーキテクトに最も強烈な衝撃を与えたのは、CobbleDBの性能値そのもの以上に、その「開発の裏側」である。CEOのAravind Srinivas氏が明かしたところによると、CobbleDBを構成する約40,000行のRustコードは、**たった2人のシステムエンジニアが、わずか2ヶ月**で書き上げたという。

通常、分散キーバリューストアをゼロから内製し、プロダクションに耐えうる堅牢性に仕上げるには、熟練のインフラエンジニアチームが数年単位の歳月を費やすのがこれまでの常識だった。この異常な開発速度を可能にした正体は、エンジニアとペアを組んだ「自律型AIコーディングエージェントの群れ（AI agent swarm）」だ。AIエージェント群が統合テストの記述、ビルドパイプラインの監視、エラー対応のランブック作成や運用スクリプトの生成といった泥臭いタスクを24時間体制で自律処理し、2人のエンジニアはコアなアーキテクチャ設計とパフォーマンスチューニングだけに100%集中したのである。これはソフトウェア工学における歴史的なパラダイムシフトと言わざるを得ない。

しかし、この美しい成功譚の裏にある重いトレードオフから目を背けてはならない。フルマネージドなDynamoDBを捨てるということは、AWSがこれまで裏側で肩代わりしてくれていたノードのライフサイクル管理、バックアップの整合性検証、パーティションの再バランシング、そしてディスク障害時の緊急対応といった運用負荷のすべてを、自社のSRE（Site Reliability Engineering）チームが背負い込むことを意味する。一度バグが潜み込めば、データロストやサイレントデータクラプション（データ破損）のリスクと直接対峙しなければならない。

「クラウドネイティブ＝既存のSaaSやマネージドサービスをパズルのように組み合わせるだけ」という時代は終わりを告げつつあるのかもしれない。AIエージェントという強力な推進力を手に入れた現代のエンジニアは、汎用マネージドサービスの限界に達した時、自社データ構造に100%特化した「尖った専用データベース」を数週間で自作する武器を手に入れたのだ。

我々エンジニアは今、自問する必要がある。今使っているマネージドサービスのブラックボックスと高額な料金に甘んじ続けるのか、それともドメイン特化のアーキテクチャを自ら再構築する覚悟を持つのか。明日からの開発において、汎用ライブラリやAWSサービスを安易に採用する前に、「自社のユースケースに特化した最適化の余地はどこにあるか」「AIを相棒にしてインフラのコア部分を内製できないか」を技術選定のテーブルに載せるべきだ。CobbleDBのオープンソース化が予告される中、この自作DBへの回帰トレンドは、確実に我々のプロダクト開発のあり方を再定義し始めている。