【ITニュース解説】The Ugly Truth About Postgres & pgvector

ある開発者が、自分がよく知っているPostgresデータベースと、ベクターデータを扱うための拡張機能であるpgvectorを使って、より賢い検索機能を持つアプリケーションを開発しようとした。この計画はシンプルで、既存の知識とツールを活用できるはずだった。

しかし、アプリケーションを公開してわずか数日後、深刻なパフォーマンス問題に直面した。検索結果の表示が遅くなり、ユーザーは読み込み中の画面を頻繁に見ることになった。設定を調整したり、より高性能なサーバーを借りたり、一部の処理を別のサーバーにオフロードしたりと、様々な対策を試みたが、一時的に状況が改善されてもすぐに問題が再発した。最終的には、データベースを複数のサーバーに分割する「シャーディング」という複雑な計画を手書きで検討する羽目になった。

この開発者の計画自体は間違っていなかった。Postgresは単一のサーバー上で非常に堅牢に動作するデータベースであり、pgvectorもベクターデータ処理において優れた機能を提供する。問題は、アプリケーションのデータとアクセスのパターンにあった。通常のデータベースの行データに加えて、検索のスマート化のためにベクター埋め込みデータも扱う必要があったため、データ構造が複雑になった。さらに、データの書き込みと読み込みが一時的に集中する「バースト的」なアクセスパターンや、「スパイク的」な読み込みが発生した。

ベクターデータを高速に検索するための「ベクターインデックス」は、データ量が非常に大きくなりがちで、これがデータベースの処理を重くする一因だった。また、Postgresの自動メンテナンス機能である「Autovacuum」や、データの永続性を確保するための「チェックポイント処理」が、ユーザーからのライブトラフィックと競合し、システム全体の速度低下を引き起こした。これにより、データベース内に不要なデータが蓄積される「ブロート」が発生しやすくなり、トランザクションログ（WAL）の処理に大きな負荷がかかり、システムが一時的に停止する「ストール」現象が、まさに使用量が急増するタイミングで発生した。

読み込み処理の負荷を軽減するために、データベースの「リードレプリカ」（読み取り専用の複製）を導入することは有効だが、これによってレプリカのデータが一時的に古くなる「データの不整合」が発生する可能性が生じる。さらに、データベースのアップグレード作業、たびたび必要になる「バキューム作業」（不要なデータをクリーンアップする作業）、手動でのシャーディング、そして最新データに基づくレビューを待つ時間など、運用にまつわる様々な負担が常に付きまとった。このような単一サーバー構成で発生する運用上の負担こそが「シングルボックス税」と呼ばれるものだった。

もしこの時、分散データベースという異なる基盤を使っていたらどうだろうか。例えばTiDBのようなシステムでは、データを複数の「レンジ」に自動的に分割し、それぞれを複数のサーバーにコピーして保持することで、データの耐久性を高めている。特定のデータにアクセスが集中しても、そのデータを担当するサーバーが自動的に負荷の少ないサーバーに移動する仕組みがある。また、SQLの処理を行う層が「ステートレス」、つまり個々のリクエストの状態を保持しないため、アクセスが急増した時に必要な分だけサーバーを追加し、負荷が落ち着けば元の規模に戻すといった柔軟なスケーリングが可能になる。

このような分散データベースでは、ベクター埋め込みデータもビジネスデータも同じデータベース内に共存させることができる。開発者はベクター検索のためのインデックスを設定し、距離の計算方法を選択するだけで、データベースが自動的に最適な検索プランを立て、通常のデータフィルターとベクター類似性検索を組み合わせた複雑なクエリも効率的に実行できるようになる。外部の特別なシステムを組み合わせる必要もなく、手動でシャーディング計画を立てる手間も不要になるのだ。

TiDBでは、ユーザーからのリクエストは、必要に応じて柔軟にスケールできるステートレスなSQL処理層で受け付けられる。実際のデータは、複製されて高耐久性を持つKey-Valueストアに保存される。特定のデータ範囲への負荷が変化すると、システムは自動的にその範囲を分割し、より適切なサーバーへ移動させることで、特定のデータが処理のボトルネックになる「ホットスポット」を防ぐ。分析用途のレプリカは、データをカラム形式で保持することで高速なスキャンを可能にするが、トランザクション処理と全く同じ時点のデータを参照するため、日常の取引データと分析データの間で矛盾が生じる心配がない。トランザクションは「スナップショット分離」という仕組みを提供し、常に一貫性のあるデータを読み取れるため、「レプリカのデータは最新か？」といった疑問に悩まされることも減る。予期せぬシステムの負荷増大が発生した際も、夜中に緊急対応に追われるのではなく、システム構成の調整で対応できるため、運用担当者の負担が大きく軽減される。

しかし、Postgresとpgvectorの組み合わせが最適な状況ももちろん存在する。それは、扱うデータがサーバーのメモリ容量に余裕を持って収まる場合、ユーザーからのアクセスパターンが非常に予測可能で安定している場合、開発チームがPostgresの深い知識を持っており、運用に習熟している場合、そしてベクターインデックスのメンテナンスが頻繁な作業になっていない場合だ。このような環境であれば、最もシンプルで理解しやすい構成を維持することが最善である。システムが複雑化する「協調のための税金」が発生し始める、例えば、大量の書き込み後にAutovacuumの処理が追いつかなくなったり、レプリカの遅延がユーザーに明確に認識されるようになったり、あるいは製品の機能開発がデータベースの限界によって制限され始めたときに初めて、分散システムへの移行を検討すべき時期が来る。

TiDBのような分散システムは、単に性能が高いというだけでなく、システム障害がどのように発生し、運用担当者がどのように時間を使うかという点で大きなメリットをもたらす。拡張機能のアップグレード計画に頭を悩ませる必要がなくなる。データの鮮度と安全性のどちらかを選ぶというジレンマから解放される。深夜にシャーディングの再調整に追われることもなくなる。議論の焦点は「いかに負荷の急増を隠すか」から「ユーザーが問題に気づくレベルの遅延がどのくらいの頻度で発生するか」へと移る。監視は意図的に「退屈」になる。つまり、開発チームは遅いクエリやトラフィックの急増に目を光らせるだけでよく、データ配置、レプリカ遅延、フェイルオーバーといった複雑な処理はシステムが自動的に行ってくれる。運用が「退屈」になることで、開発者はより価値のある機能開発に集中できる時間を得られるのだ。

もちろん、TiDBのような分散データベースが常に最適な選択肢であるわけではない。例えば、データの鮮度がユーザー体験に直接影響せず、主に夜間のバッチ処理やデータウェアハウスのジョブが中心となるようなワークロードでは、分散システムである必要性は低い。Postgres固有の機能に強く依存しており、それを他のデータベースに置き換えることが難しい、あるいは望まないアプリケーションの場合も適していない。また、システムの弾力性よりも、毎月の費用が固定されていることを重視する予算やポリシーを持つチームにとっても、TiDBは最適な選択とはならないかもしれない。新しい技術だからという理由だけで導入するのではなく、既存の運用計画が夜間や週末の作業として「利子」を請求し始めたときに、初めて移行を検討すべきだ。

分散システムは一見すると複雑に思えるかもしれない。しかし、システムがその複雑さを吸収してくれることで、人間が運用で抱える複雑さはかえって小さくなることがある。開発者は、拡張機能のライフサイクルや、データをどのサーバーに配置するか、レプリカのデータ遅延といった心配事を頭の中から手放すことができる。これらはシステムの責任となり、開発者はよりプロダクトの機能開発に直結する課題に集中できるようになる。もし友人が、単一のPostgresサーバーとpgvectorで週末プロジェクトを始める代わりに、TiDB Cloudのような分散データベースからスタートしていたら、アプリケーションは月曜日に公開された後も安定して稼働し続け、水曜日の夜に緊急対応で誰かが呼び出されることもなく、金曜日のレビューは今朝の最新データに基づき行われただろう。そして、開発期間の終わりには新しい運用手順書ではなく、新しい機能が完成していたはずだ。

開発者が慣れたツールからプロジェクトを始めるのはごく自然なことだが、現実の要求に応じて、より適切な基盤へとレベルアップしていく必要がある。もしあなたが「シングルボックス税」を支払い、たびたびのバキューム作業や手動でのシャーディング、レプリカ遅延に関する議論に頭を悩ませているのであれば、機能リストを変えるのではなく、その基盤を根本から見直す時期が来ているのかもしれない。