- Litestream は SQLite ベースのフルスタックアプリケーションを安全に オブジェクトストレージ へバックアップするツールであり、今回最大級の機能刷新が行われた
- 従来構造より効率的な LTXファイルフォーマットとコンパクション 手法を適用し、高速かつ効率的なポイントインタイムリカバリが可能になった
- Conditional write を活用した新方式により、リーダーシングルトンおよび read replica 機能の実装が簡素化された
- まもなく VFSベースの read-replica レイヤーが提供され、さまざまな環境で容易にスケール可能になる
- 大幅に改善された構造により、多数のデータベースを同時に同期できるようになり、スケーラビリティが向上した
Litestream の紹介と重要性
- Litestream はオープンソースツールとして、SQLite を基盤とするさまざまなフルスタックアプリケーションをオブジェクトストレージへ安全にバックアップする機能を提供する
- SQLite の組み込み型という特性によってデータが1台のサーバーに依存してしまう問題を解決し、サーバー障害時でも データ復旧 を容易にする
Litestream の発展の過程
- SQLite をより簡単に活用するために、Litestream は 2020 年に登場した
- Litestream は SQLite アプリケーションとは別プロセスで動作し、WAL チェックポイントプロセス を置き換えて、データ変更をリアルタイムで S3 のようなオブジェクトストレージへストリーミングする
- サーバーが失われても、オブジェクトストレージから最新状態のデータベースを効率よく復元できる
- その後 LiteFS というプロジェクトが追加開発され、read replica や基本的なフェイルオーバー（Primary Failover）までサポートすることで、SQLite を Postgres のようなモダンな配布構成で活用できるようにした
- LiteFS と Litestream はどちらにも利点があるが、Litestream はより導入と運用が容易で、広く使われている
効率的なポイントインタイムリストア（Point-in-time Restore）
- 以前の Litestream の設計では、すべての変更を継続的に記録して S3 に送信していたが、データの更新が頻繁な場合、復元時に非効率だった
- LiteFS では トランザクション認識 ベースのアプローチを導入し、変更ページ範囲を並べ替えて記録する LTX ファイルフォーマットを使用している
- 複数の LTX ファイルを容易にマージ（compaction）し、最新バージョンだけを残す方式によって、データ復旧の速度と効率を大幅に向上させた
- この構造は LSM ツリーに似ている
- 新しい Litestream でも LTX ファイルとコンパクション方式を導入し、多くの重複保存なしに正確なポイントインタイムリカバリを実現できるようになった
CASAAS: Compare-and-Swap as a Service
- Litestream は SQLite アプリケーションがバックアップシステムを意識しなくても動作する必要があり、障害などでプロセスが停止した場合にはデータ変更の取りこぼしが発生する可能性がある
- この問題を解決するために generation という概念を導入し、各バックアップセッションとそれに対応するログストリームを一意に識別する
- LiteFS では Consul を使ってシングルリーダーを保証していたが、外部依存が必要になるため、Litestream は S3 などオブジェクトストレージの conditional write 機能 を使って単一のレプリケーション経路（シングルトン）を簡単に実装する
- これにより、ephemeral ノード環境でも混乱なく安定して動作できるようになった
軽量な read replica 機能
- LiteFS はトランザクション認識のために FUSE ファイルシステムを使うが、これは複雑さと導入負担がある
- これを緩和するために、LiteVFS という SQLite Virtual Filesystem（VFS） 拡張モジュールを通じて、FUSE なしでもさまざまな環境で動作できるよう設計された
- 今後 Litestream にも同じ VFS ベースのレイヤーを適用し、S3 などのオブジェクトストレージから直接ページを fetch・cache する read-replica レイヤーを提供する予定だ
- ローカル SQLite ほど高速ではないものの、caching と prefetching 戦略によって多くのユースケースで十分満足できる性能を提供できると期待されている
オープンソースと活用性
- Litestream は完全なオープンソースであり、Fly.io に依存せずどこでも利用できる
- 1 つのプロセスで大量のデータベースを同期する機能が追加され、数百〜数千のデータベースでも効率的にバックアップ・複製できるようになった
SQLite との継続的な共進化
- SQLite は業界の変化の中でも着実に新しい活用事例を生み出し続ける堅牢なデータベースである
- 最近では LLM ベースのコード生成エージェント のような分野でも、リアルタイムなデータロールバックや分岐が重要になっており、Litestream の進化したポイントインタイムリカバリ機能が重要な基盤になり得る
- 今後こうした改善されたアーキテクチャは、ロールバック、フォーク、自動化エージェント対応 などの拡張機能にも貢献する見込みだ
- 新しい Litestream は従来の設計より優れており、スケーラビリティと使いやすさの両方を強化している
2件のコメント
Litestream - SQLiteストリーミングレプリケーションツール
私はサーバーサイドSQLiteに全力投入します
Hacker Newsのコメント
コードベースを見つけた体験の共有。2年前に litestream と litefs を使った際には不便さがあったものの、今回はその大半の問題が解消されたように感じるという意見。これでデータベースに litestream を気軽に適用でき、複数 writer の問題への不安も減ったという見方。read replica の FUSE レイヤーの利点にも期待しており、関連プルリクエストでは lease の引き継ぎ方式も紹介されている（すでに lease がある場合、新しいプロセスが1秒間隔で再試行して高速なローリングリスタートをサポート）。実用的なアプローチだという考え
新しい Litestream には、自分が求めていた機能がすべて実装されたように感じる。期待していて、とても興奮している
とても賢く、デプロイが簡単になる方式だという肯定的な見方。数千個の SQLite DB をバックアップする必要がある環境で、これまでは fanotify と SQLite の Backup API で間に合わせの仕組みを作っていた経験があり、wildcard replication が多数のファイルをサポートするなら Litestream に移行したいという期待
LTX への移行後は、1つのディレクトリに数百、数千のデータベースがあっても
/data/*.dbの複製が可能になった点を強調。これは以前は決定的な障害だったという立場で、今ではマルチテナント環境で各ユーザーごとのデータベース単位で、必要な時点への復旧やデータのダウンロード、移行が可能になることへの前向きな見通しben への感謝とともに実運用の経験を共有。1年以上、write-heavy な社内向け用途（圧縮後で約 12GB）で litestream を本番利用しており、月額コストがごくわずか（Azure 基準で数百ウォン程度）にすぎない点を紹介。新しい変更の適用を楽しみにしているという立場
Fly の SQLite ベースの開発者体験がもう少し洗練されてほしいという思い。現状の不満として、独自 UI と CLI が不足しており、初期データベースを Fly Machine にセットアップする作業が思った以上に手間だという点を挙げている。fly console は SQLite ときちんと連携せず、別マシンで実行されるためデータのあるボリュームに接続できない。結局
fly ssh console —ptyで直接そのマシンに入るしかない不便さを指摘。SQLite ベースの Web アプリはたいてい小規模なので、収益を上げるには多数を運用しなければならないという悩みLitestream をちょうど調べていたところで、タイミングよくこの記事を見かけた個人的な体験の共有。VPS で Sqlite を使っており、Litestream 導入を検討中で、Litestream プロセスの実行中に特定時点へのデータベース復旧が可能かを質問。auto-checkpointing がプロセス停止時に WAL を消費するため復旧できない時間帯が生じるのではないか（例: 障害で 2:00〜3:00 の間プロセスが停止すると、1:55 や 3:05 には復旧できても、2:00〜3:00 の間の復旧情報は失われるのではないか）という疑問
Litestream は WAL セグメントを一定の時間単位で保存する。デフォルトでは WAL の変更内容を毎秒送信するため、設定した保持期間内であれば望む時点へ秒単位で復旧できるという説明
DST（夏時間）処理の問題についての質問。欧州では 3 月 30 日に 2:00 から 3:00 へ時間が飛ぶが、その場合どう動作するのかが気になるという指摘
過去に dynamodb ベースの DonutDB という sqlite vfs を作った経験の共有。S3 に CAS（Content Addressable Storage）機能が追加されたことをきっかけに、DonutDB を S3 対応版として作り直そうとしていたが、今回 lightstream がそれをサポートしてくれたおかげで自分で開発する必要がなくなったことを喜んでいる。新しいツールを使うのが楽しみだという反応
アプリをデプロイする際、従来の方式では新しいサーバーインスタンスを立ち上げ、ヘルスチェック通過後にトラフィックを切り替えて古いサーバーを終了していたが、その切り替えの過程でデータベース変更の取りこぼしが起きていたことを思い出し、今回の変更でその問題が解決されたのかを質問
サーバーを使い捨ての Web サーバーインスタンスではなく、本番データベースとして見るべきだという意見。python/sqlite の Web アプリをデプロイする際は、マシン全体を入れ替えるのではなくパッケージだけ更新して systemd サービスを再起動する方式を使っているという。ダウンタイムを減らすには SO_REUSEPORT などで切り替え方法を工夫でき、その場合は新旧プロセスが同時にデータベースを使えるが、DB スキーマ変更が含まれるなら一定のダウンタイムは避けられないという判断。他の DB でも同様かもしれないという見解
簡単には解決しない問題だという立場。依然として lease を取得できる writer は1つだけなので、新しいサービスが起動しても前の writer が停止しない限り lease は得られない。writer 切り替え用のツールは提供されるが、リクエスト待ちや短いダウンタイムは避けられないという説明
litestream でユーザーごとに非常に多くのデータベースを複製するには（ドキュメントで扱われている代表的なユースケース）、実行時に新しいデータベースを動的に追加する方法があるのかを尋ねる質問。現在の設定ファイルは静的で、リアルタイム API も見つけられなかったという経験の共有