rqliteからマネージドクラウドサービスへ：分散型SQLiteの進化

2014年9月、Philip O'Tooleは、SQLiteとRaft合意プロトコルを組み合わせてフォールトトレラントなクラスタリングデータベースを作成するオープンソースシステム「rqlite」をリリースしました。それから12年後、O'Toole氏は、この初期の実験が、ローカルファーストのCRDTからベンチャー資金によるマネージドサービスまで、より広範な分散型SQLiteソリューションのカテゴリーを生み出した経緯を振り返っています。

何が起きたか

O'Toole氏は当初、jut.ioにおける特定のインフラストラクチャ上の課題を解決するためにrqliteを開発しました。それは、単一のノードを永続的なデータ保持者として指定することなく、クラスタリングシステムに対してリレーショナルストレージを提供するというものでした。SQLiteの前にRaftログを配置することで、すべての書き込み操作がクラスタ全体にレプリケートされ、ノード障害時のデータ損失を防ぐ仕組みを実現しました。ソースコードはその週末にGitHubで公開され、O'Toole氏によれば、これはRaftとSQLiteを組み合わせた初のオープンソース事例となりました。数年間、rqliteはこのニッチ分野で唯一の存在であり、同様のアーキテクチャを試みる他の主要プロジェクトはありませんでした。

状況が変わり始めたのは2016年で、Expensify社が内部で長年使用していたPaxosベースのSQLiteレプリケーションシステム「Bedrock」を公開しました。ほぼ同時期に、Erlang環境内の個々のアクター向けにRaftレプリケーションされたSQLiteデータベースを提供する「ActorDB」も登場しました。両者とも自社以外での広範な採用には至りませんでしたが、SQLiteをレプリケーションするという概念が注目を集めつつあることを示しました。しかし、rqliteは特定のアプリケーションフレームワークに依存せず、開発者が独立してデプロイできるスタンドアロンかつ汎用的なツールとして、独自性を保ち続けました。

2017年には、Canonical社がLXDおよびMicroK8s用に組み込み型のレプリケーションストアを提供し、etcd運用に伴うオーバーヘッドを回避するため「dqlite」を開発しました。O'Toole氏とMark Shuttleworth氏は潜在的な協力について議論しましたが、両プロジェクトはパッケージングモデルにおいて分岐しました。dqliteはアプリケーションに直接埋め込まれるCライブラリとなった一方、rqliteは独立したサーバープロセスとして残りました。この違いにより、それぞれのユースケースが明確になりました。dqliteは製品内部でのデータベース機能提供に向き、rqliteは製品外部でのデータベースインフラ構築に向いているのです。

仕組み

rqliteの中核メカニズムは、複数ノード間で状態を管理するためにRaft合意アルゴリズムを利用しています。このCP（一貫性とパーティション耐性）システムでは、すべての書き込み操作はリーダーノードへ送信されなければなりません。リーダーは変更内容を自身のログに追加し、フォロワーノードへレプリケートします。クラスタの多数派が書き込みを承認した場合のみ、その書き込みは成功とみなされます。ネットワークパーティションによって少数派のノードが隔離された場合、それらのノードはデータの分岐を防ぐために書き込みを拒否し、パーティション発生時の可用性を犠牲にして強い一貫性を確保します。

この設計は、Ben Johnson氏が2021年にリリースしたLitestreamのような後のアプローチとは対照的です。Litestreamは合意プロトコルを使用しません。代わりに、SQLiteのWrite-Ahead Log（WAL）を監視し、S3などのオブジェクトストレージへ変更点をストリーミングします。これにより、単一ノード構成でも最小限のコストでディザスタリカバリが可能になり、リアルタイムクラスタリングではなくバックアップという一般的なニーズに対応します。rqliteはダウンタイムが許容されない場面での高可用性に応える一方で、Litestreamはよりシンプルなアーキテクチャにおけるデータの耐久性に対応しています。

近年の革新では、デザイン空間の異なるポイントが探求されています。Cr-sqliteは、競合フリーレプリケイテッドデータタイプ（CRDT）をSQLite拡張機能として導入し、中央リーダーなしで複数の書き込み手が変更を発散・統合できるようにしました。このAP（可用性とパーティション耐性）アプローチは、即時の一貫性よりもオフライン機能が重要なローカルファーストアプリケーションに適しています。一方、libSQLのようなプロジェクトはSQLiteエンジン自体をフォークしてより深い統合を可能にし、Tursoのようなマネージド製品としてエッジレプリケーションデータベースを提供するサービスの基盤となっています。

主要な詳細

• Rqliteは2014年9月にリリースされ、当初はgoraftライブラリを使用していましたが、2016年初頭にHashicorpのRaft実装へ移行しました。
• Canonical社のdqliteは2017年に作成され、アプリケーションに埋め込まれるCライブラリである一方、rqliteはスタンドアロンサーバーとして動作します。
• Litestreamは2021年に開始され、合意プロトコルを使用せずにSQLite WALファイルをS3へストリーミングし、ディザスタリカバリを実現します。
• Cr-sqliteはCRDTを通じてマルチライターサポートを有効にし、結果整合性を必要とするローカルファーストアプリケーションに対応します。
• libSQLフォーク上に構築されたTursoは2026年にSupabaseに買収され、マネージド分散型SQLiteの商業的実現可能性を示しました。
• CloudflareのD1およびDurable Objectsは、エッジにおけるサーバーレスでマネージドなSQLiteレプリケーションへのシフトを表しています。

なぜ重要なのか

ソフトウェアエンジニアやインフラ責任者にとって、分散型SQLiteの歴史を理解することは、異なるアーキテクチャパターン間のトレードオフを明確にする上で重要です。デザイン空間における3つの異なる領域——合意ベースのクラスタリング、WALストリーミング、CRDTマージ——の出現は、ソリューション選択には要件の精密な定義が必要であることを意味します。開発者は、高可用性を伴う強い一貫性が必要なのか、コスト効率の良いディザスタリカバリが必要なのか、それともオフラインファーストのコラボレーション機能が必要なのかを決定しなければなりません。バックアップのみが必要なユースケースにrqliteのようなCPシステムを誤って適用したり、その逆を行ったりすると、不要な複雑さやデータリスクを招く可能性があります。

オープンソースツールからマネージドプラットフォームへの軌跡は、インフラストラクチャソフトウェアにおけるより広範なトレンドも反映しています。rqlite、dqlite、Litestreamは引き続き無料かつオープンソースですが、大きなベンチャーキャピタルや買収は、運用の複雑さを抽象化するサービスへと流れています。TursoやCloudflareのような企業は、レプリケーションされたSQLiteをユーティリティとして販売し、チームがクラスタ管理に伴うメンテナンス負担を回避できるようにしています。このシフトは基盤技術の有効性を裏付けるものですが、従来セルフホスティングソリューションに頼っていた開発者にとっての経済モデルを変えています。

実行可能なこと

• 一貫性の要件を評価してください。強い一貫性が必要な場合はrqliteのようなRaftベースのシステムを、オフラインファーストアプリの場合はcr-sqliteのようなCRDTを選択してください。
• リアルタイムクラスタリングではなく、単一ノードのSQLiteデータベースに対するディザスタリカバリが主なニーズであれば、Litestreamを検討してください。
• 外部サービス依存なしで組み込み型のレプリケーションデータベースが必要なアプリケーションを構築している場合は、dqliteを使用してください。
• 分散データベースクラスタの管理に伴う運用オーバーヘッドを軽減したい場合は、TursoやCloudflare D1などのマネージドサービスを探ってください。
• rqlite v8.0のWALストリーミング機能を確認してください。これはLitestreamに触発されたものであり、バックアップおよび復旧プロセスの最適化に役立ちます。
• チームにセルフホスティングRaftクラスタを維持する専門知識があるか、あるいはマネージドプラットフォームの方がリソース配分的に優れているかを評価してください。