Jepsen、ParticleDB 1.1.4における重大な安全性および安定性の欠陥を暴露

独立系テスト企業であるJepsenは、ParticleDBバージョン1.1.4に関する包括的なレポートを発表し、このデータベースエンジンにおける重大な安全性違反と安定性問題を明らかにしました。バージョン1.1.4から1.1.18.11.rc-22にかけて実施されたこの分析では、形式検証に関するマーケティング上の主張と、負荷下でのシステムの実際の挙動との間に不一致があることが浮き彫りになりました。AIエージェントや高スループットアプリケーション向けのインフラストラクチャを評価しているエンジニアにとって、これらの発見事項は、本プラットフォームがプロダクション環境で使用できるほどの成熟度に達しているかどうかについて深刻な疑問を投げかけます。

何が起きたか

Orkes社が開発したParticleDBは、同社のConductorワークフローオーケストレーションプラットフォームをサポートするために設計され、トランザクション対応SQL、キーバリューストア、ベクトル検索、アナリティクスを単一のRustベースのエンジンに統合することを目指しています。同社は、PostgreSQLよりも桁違いに高速であり、AIエージェントワークロードに特化した完全なACID準拠を提供するデータベースとしてこれを宣伝しています。より広範なリリースに先立ちこれらの主張を検証するため、Orkesはリファクタリング後のコードベース（バージョン1.1.4から開始）をテストするためにJepsenを起用しました。提供されたビルドにはエンタープライズクラウドデプロイメントでのみ利用可能なレプリケーションクラスタ機能がサポートされていなかったため、テストは単一ノードの挙動に焦点を当てました。

Jepsenチームは、可用性、機能の破綻、トランザクション並行性、状態破損など、さまざまなカテゴリーにわたる96の異なる問題を特定しました。一部の問題は後続のリリース候補で解決されましたが、レポートでは、エラーメッセージなしの突然のクラッシュ、わずか2つの同時トランザクションによるデッドロック、トランザクション分離レベルの黙殺といった深刻な異常が詳細に記載されています。テストプロセスでは、プロセスクラッシュ、ディスク破損、ネットワーク障害をシミュレートし、システムの耐久性と整合性保証に対して負荷をかけました。

大きな論争の的となったのは、トランザクション分離と耐久性に関するドキュメントでした。ParticleDBのホームページでは「完全なACID」とTLA+による「形式的に証明された」安全性が謳われていましたが、コラボレーション期間中にTLA+仕様書は提供されませんでした。さらに、occ（楽観的並行制御）やgroupsync（WAL同期）などのトランザクションモードに関するドキュメントには、それらが強い耐久性または直列化可能な分離を提供するのかどうかについて矛盾する情報が含まれていました。多くの場合、データベースは分離レベルを設定するための標準SQLコマンドを黙って無視し、代わりに公開ドキュメントで十分に説明されていない起動フラグに従った挙動を示しました。

仕組み

Jepsenは、障害を注入し、システムが宣言された整合性モデルを維持しているかどうかを観察することで分散システムをテストします。ParticleDBの場合、チームは既存のSQLワークロードと、データベース固有の機能向けに特別に設計された新しいテストを組み合わせて使用しました。また、直列化可能性やスナップショット分離の違反を示すサイクルを検出するために、トランザクション依存関係グラフを分析するElleチェッカーを採用しました。テストは公式のPostgres JDBCクライアントとネイティブのParticleDB Java SDKの両方に対して実行されましたが、後者は当初Maven依存関係として利用できませんでした。

テストスイートには、ランダムな読み取りと書き込み、リスト構造への追加、単一トランザクション内の内部整合性チェックを実行するワークロードが含まれていました。注目すべき手法としてcompareワークロードがあり、これはランダムなSQL文を生成し、ParticleDBとPostgreSQLの両方で実行しました。結果が異なる場合、ツールはバグを再現するためにテストケースを最小限に絞り込みました。このアプローチにより、ParticleDBは基本的なクエリにおいてPostgreSQLの挙動と一致しないことが多く、Postgresワイヤープロトコルの実装が不完全またはバグだらけであることが示唆されました。

障害注入は、耐久性の問題を暴く上で重要な役割を果たしました。LazyFSを使用して未fsync書き込みの喪失をシミュレートし、プロセスを強制的に終了させることで、JepsenはWrite-Ahead Log（WAL）がデータを正しく保持しているかどうかを検証しました。テストは3つのWAL同期モード（sync、groupsync、nosync）を対象としました。これらのモードのドキュメント化された挙動と実際の性能との間の不一致により、ユーザーが安全な設定を選択したと考えていてもデータが失われたり破損したりするいくつかの事例が発見されました。

主要な詳細

• Jepsenは、パフォーマンスボトルネックから重大なデータ安全性違反まで、ParticleDBで96件の問題を発見しました。
• ドキュメントではTLA+による「形式的に証明された」安全性が主張されていましたが、この主張を検証するための仕様書は提供されませんでした。
• SQL経由で設定されたトランザクション分離レベルはしばしば黙って無視され、その挙動は不透明な起動フラグによって支配されていました。
• バージョン1.1.18.11.rc-6までは深刻なデッドロックが発生しており、わずか2つの同時トランザクション後にノードがフリーズすることがありました。
• 標準的なPostgres機能のサポートは不完全で、プリペアドステートメント、CASE式内の集約関数、累乗演算子などで失敗が見られました。
• バージョン1.1.18.6では、エラーログなしの突然のクラッシュが観察され、長時間実行タスクに対してシステムが信頼できなくなりました。

なぜ重要なのか

ソフトウェアエンジニアや技術リードにとって、このレポートは、重要なインフラストラクチャにおいてマーケティング上の主張に頼ることの危険性を示す教訓です。ParticleDBは、データ整合性が極めて重要なAIエージェント向けの統一ソリューションとして位置づけられています。トランザクション分離レベルが黙って無視される可能性があるという発見は、強い整合性を想定しているアプリケーションが、微妙でデバッグが困難な競合状態に苦しむことを意味します。データベースが「完全なACID」を主張しながら、実際にはスナップショット分離またはより弱い保証で動作する場合、開発者は並行負荷下で失敗するシステムを設計してしまう可能性があります。

デッドロックや原因不明のクラッシュを含む不安定性の問題は、システム可用性に直接影響を与えます。プロダクション環境において、数秒間の同時アクティビティ後にフリーズしたり、エラーを記録せずにクラッシュしたりするデータベースは、運用上持続不可能です。これらの欠陥は、チームに監視や回避策戦略への多大な投資を強要し、約束されたパフォーマンス上の利点を相殺してしまいます。さらに、Postgresワイヤープロトコルの不完全な実装は、既存アプリケーションのParticleDBへの移行がドロップイン置換ではないことを意味し、大規模なリファクタリングとテストが必要になります。

公開ドキュメントと内部オペレーターガイドとの間の不一致も、成熟度のギャップを浮き彫りにしています。重要な安全性特性がヘルプテキスト、ホームページ、内部ドキュメントで異なって記述されている場合、ユーザーはリスクについて十分な情報に基づいた決定を行うことができません。AIワークフローのためにParticleDBを検討している組織にとって、透明で検証可能な安全性証明の欠如と既知のデータ破損バグの存在は、このテクノロジーがミッションクリティカルなデプロイメントにまだ準備できていないことを示唆しています。

対処方法

• 既知のデッドロックおよびクラッシュ問題のため、バージョン1.1.18.11.rc-7以前のParticleDBをプロダクションで使用しないでください。
• ドキュメントに頼るのではなく、トランザクション分離の挙動を実証的に検証してください。並行負荷下での競合状態をテストしてください。
• 完全なPostgres互換性を想定しないでください。CASEステートメント内の集約関数や累乗演算子など、サポートされていない機能についてSQLクエリを監査してください。
• ParticleDBを使用する場合、潜在的なパフォーマンスコストにもかかわらず、より強い整合性を確保するために、重要なデータにはtable-2plまたはserializableモードを優先してください。
• アプリケーションレベルのチェックサムを実装したり、PostgreSQLなどの信頼できるデータベースと比較テストを行ったりすることで、静かなデータ破損を監視してください。
• プラットフォームへのコミット前に、ベンダーに内部オペレーターガイドや詳細な安全性仕様のアクセスを要求してください。