なぜDynamoDBがボトルネックになったのか
Perplexityの検索APIは非常に負荷の高いワークロードを処理しています。各リクエストで約100〜120個のページキーを、通常10〜20個のバッチで取得します。各レコードの平均サイズは約50KBであり、クエリあたりのデータ量は膨大です。このアクセスパターンと急速に拡大するWebインデックスにより、従量課金モデルの限界がすぐに露呈しました。
DynamoDBのコスト構造では、読み書きされるすべてのバイトに対して課金されます。Perplexityのデータインデックスが拡大し、本番環境のトラフィックが増加するにつれ、バイト単位の読み取りコストが線形に増大し、マネージドデータベースの維持費がますます高額になりました。この経済的な圧力が、Perplexityがデータベース戦略を再評価する大きな要因となりました。
コスト以外にも、DynamoDBのマネージドという性質は重要な制御制限を課していました。Perplexityは、特定のアクセスパターンに最適化するためにデータベースの基本的な動作を調整することができませんでした。エンジニアは以下の項目を制御する能力を欠いていました：
- 特定のマシンへのパーティション配置
- キャッシュ用に割り当てられたローカルメモリ
- 読み取りリクエストに応答するレプリカの指定
このような詳細な制御、特にレプリカ選択の欠如は、1つの低速なレプリカがバッチ読み取り全体を停滞させ、ユーザーのテールレイテンシに大きな影響を与えることを意味していました。Perplexityには、より柔軟で高性能なソリューションが必要でした。
最も遅いレプリカが全体の速度を決定する
DynamoDBでのバッチ読み取りはレイテンシを増幅させました。100〜120個のページキーを10〜20個のバッチで取得する単一の検索リクエストにおいて、他のレコードがすぐに到着しても、1つの低速なレプリカがリクエスト全体を遅延させる可能性がありました。最も遅い操作が全体的なパフォーマンスを決定するこの現象は、テールレイテンシとして知られています。
Perplexityはこの問題を解決するために、特化したホットキーバリューストアであるCobbleDBを構築しました。Rustで開発されたCobbleDBはRocksDB上で動作し、ローカルのNVMeストレージから直接データを供給します。キーはパーティションごとに論理的にグループ化されており、効率的なデータ局所性を確保しています。このアーキテクチャにより、Perplexityはマネージドサービスにはない、キャッシュとデータ配置に対する詳細な制御能力を獲得しました。
ステートレスなルーターがCobbleDBの読み取りを調整します。ルーターは複数のレプリカに並列リクエストを送信し、ヘッジドリード（hedged reads）を採用しています。もし1つのレプリカが遅延した場合、ルーターは即座に同じ読み取りリクエストを別のレプリカに送信します。この積極的な戦略により、低速なノードの影響を最小限に抑え、バッチ操作のテールレイテンシを大幅に削減しました。このアプローチにより、バッチ読み取りのメディアンレイテンシは31.4ミリ秒から5.6ミリ秒に、P99レイテンシは123ミリ秒からわずか24ミリ秒に短縮され、約5倍の改善を実現しました。
5倍の成果、そしてその数値が意味するもの
PerplexityのCobbleDBへの移行は、本番環境のバッチ読み取りレイテンシを劇的に改善しました。メディアン応答時間はDynamoDBの31.4 msからわずか5.6 msへと急減しました。さらに驚くべきことに、以前は検索リクエスト全体を停滞させていたP99テールレイテンシが、123 msから約24 msへと低下し、約5倍の高速化を達成しました。
このパフォーマンス向上には、大きな経済的メリットも伴いました。Perplexityの内部コストモデルでは、CobbleDBはすべてのコミットメントティアにおいてDynamoDBよりも少なくとも20%安価になると予測されています。合成テストでもCobbleDBの堅牢性が検証され、パフォーマンスを低下させることなく、毎秒最大50万リクエストまでの安定したスループットが実証されました。
これらの結果は印象的ですが、Perplexityの特定のワークロードと運用モデルを反映したものです。100〜120ページキー（平均50 KB）をバッチ読み取りすることを特徴とする独自の検索APIは、テールレイテンシを軽減するためのヘッジドリード（hedged reads）の使用など、CobbleDBの最適化されたアーキテクチャから直接的な恩恵を受けました。
この成功は、すべてのチームやユースケースにおいて、カスタム構築されたデータベースがマネージドサービスを上回ることを普遍的に保証するものではありません。Perplexityの特注ソリューションは、2人のエンジニアとAIエージェントを活用して、同社の規模とコスト要因に独自に適したシステムを構築し、彼らの正確なニーズに合わせて最適化されました。アーキテクチャの詳細については、CobbleDB: Rebuilding AI Search Storage for Lower Latency and Costをご覧ください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
2人のエンジニア、AIエージェント、そして隠れたトレードオフ
CobbleDBの急速な開発は、エンジニアリングの新たなフロンティアを浮き彫りにしました。約40,000行のRustコードが、AIコーディングエージェントと連携した2人のエンジニアによって約2ヶ月で納品されました。この迅速な実行は、AIを活用した開発の可能性を強調しています。
労働の分担が極めて重要でした。AIエージェントは、テストの記述、修正の実装、可観測性フックの生成、ドキュメントの作成、CI/CDのフォローアップの追跡といった反復的なタスクを処理しました。一方、人間のエンジニアは戦略的な要素のオーナーシップを維持しました：
- アーキテクチャ設計
- コードレビュー
- デプロイゲート
- 本番環境での意思決定
このコラボレーションにより、少人数のチームが異例のスピードで動くことが可能となり、人間の専門知識を高レバレッジな問題に集中させることができました。
しかし、DynamoDBのようなマネージドサービスを置き換えることは、重大な運用のトレードオフを伴います。Perplexityは現在、ハードウェアの故障、データのバックアップ、継続的な信頼性の確保に対する責任を直接負っています。このモデルは、特殊なハイパースケールワークロードに対して比類のない制御とパフォーマンスを提供しますが、ほとんどのスタートアップには負担できないレベルの運用成熟度とリソースの投入を要求します。CobbleDBの成功は特注エンジニアリングの証ですが、運用負荷の増大という隠れたコストを伴います。
よくある質問
CobbleDBとは何ですか？
CobbleDBは、従来のDynamoDB環境よりも低いレイテンシとコストで検索データを提供するために構築された、Perplexityの社内用キーバリューストアです。
CobbleDBはどのようにしてレイテンシを削減しましたか？
ローカルNVMe上のRocksDBと並列レプリカ読み取りを使用しており、低速なリクエストを別のレプリカに対して再試行するヘッジドリードを採用しています。
CobbleDBはDynamoDBよりどれくらい高速でしたか？
報告された中央値のバッチ読み取りレイテンシは31.4 msから5.6 msに低下し、P99レイテンシは123 msから約24 msに低下しました。
AIエージェントが自律的にCobbleDBを構築したのですか？
いいえ。エージェントはテスト、修正、監視、ドキュメント作成などのタスクを支援しましたが、システムの設計、変更のレビュー、本番リリースの管理はエンジニアが行いました。