Litestream v0.5.0

 (fly.io)
1 ポイント 投稿者 GN⁺ 2025-10-04 | 1件のコメント | WhatsAppで共有
  • Litestream v0.5.0 は、SQLite ベースのアプリケーションの復元力を大幅に向上させるアップデート
  • 新しい LTX ファイルフォーマットを導入し、効率的なポイントインタイムリカバリ（PITR） とデータ圧縮をサポート
  • 複数の Litestream インスタンス間の 世代（generation） の概念を廃止し、管理と運用を簡素化
  • JetStream のサポートや モダンな Go SQLite ドライバへの移行 などにより、開発および統合環境がさらに扱いやすくなった
  • 今後は VFS ベースの読み取りレプリカ など、さらに強力な機能を追加予定

概要と主なアップデート

  • Litestream は SQLite アプリケーション向けのバックアップおよび復旧ツールで、オープンソースかつどこでも実行できる点が特徴
  • サーバー障害からの復旧 が容易で、SQLite を基盤としたフルスタックアプリケーションの構築に安全性をもたらす
  • 最新版（v0.5.0）は 高速化 と ポイントインタイムリカバリ（Point-In-Time Recovery, PITR） をサポート

LiteFS と Litestream の発展の流れ

  • Fly.io の Ben Johnson が開発した主な SQLite 関連プロジェクトは Litestream と LiteFS
  • LiteFS は FUSE ファイルシステムを活用し、データベース内部のトランザクションレベルでのライブレプリケーションを目指している
  • しかし市場の需要は より運用がシンプルな Litestream に集まり、LiteFS で得られた技術的知見が Litestream に再び取り込まれることになった

LTX ファイルフォーマットの導入

  • 従来の SQLite の ページ単位バックアップ方式 の限界と非効率を解消するため、LTX（トランザクションベースのフォーマット） を導入

  • LTX は トランザクション順に基づくページ範囲管理 と 重複ページの圧縮（compaction） を提供

    • 例: 複数の LTX ファイルを新しい順に適用し、重複したページは最新バージョンのみを反映することで、最終的なデータベース状態を素早く復元できる
    • ファイル階層構造により、30秒・5分・1時間単位で LTX ファイルを統合し、復元に必要なファイル数を大幅に削減

  • データ復旧速度 は I/O スループットのみに制約される

世代（generation）概念の廃止

  • Litestream は 一般的な Unix プロセス のように実行・クラッシュしうるため、動作停止時にはデータ同期に不整合が生じる可能性がある
  • 以前は複数インスタンス間の競合を防ぐために 世代（generation） という管理方式を導入していたが、
  • LTX への移行により トランザクション ID ベースの復旧 が可能になり、複雑な世代管理は不要になった

Litestream v0.5.0 へのアップグレード

  • ファイルフォーマットが大きく変更されたため、v0.3.x の WAL セグメントから直接復旧することはできない
  • アップグレードはシンプルで、新バージョンを実行 → 新しい LTX ファイルを生成 する方式で、以前の WAL ファイルもそのまま保持される
  • 設定ファイルの互換性も維持される
  • 主な変更点: データベースごとに単一のレプリケーション先のみ許可 されるようになった。これは開発のしやすさとレプリケーション競合の回避のための判断
  • コマンドは従来と同じだが、参照方式はトランザクション ID（TXID）ベースに変更された

その他の改善点

  • LTX ファイルフォーマットライブラリで ページ単位圧縮 と インデックス追加 が行われ、大容量ファイル内での選択的なページアクセスや機能拡張が可能になった
  • 今後は 特定時点のデータクエリ などの追加機能も実装可能になる
  • CGO 依存を排除 し、Go SQLite ドライバを modernc.org/sqlite に切り替えたことで、自動ビルドやクロスコンパイル環境に利点 が生まれた
  • JetStream 対応 のレプリカタイプと、S3/Google Storage/Azure Blob Storage クライアントの更新、さらに S3 API の新バージョン対応が含まれる

今後の計画

  • 読み取りレプリカ（target）環境向けの Litestream VFS 機能の開発が進行中
  • この機能により、S3 から必要なページだけを即座に読み出して高速にレプリカを生成 できるようになる予定
  • プロトタイプはすでに存在し、公開を控えている

関連記事

1件のコメント

 
GN⁺ 2025-10-04
Hacker Newsの意見

  • Fly.ioにSQLiteアプリをデプロイする過程で、開発者体験がやや物足りないと感じた。プロダクションRailsアプリを動かそうとして何時間も試したが、データベース初期化、マイグレーション、書き込み可能状態などさまざまな問題にぶつかった。問題の根本原因は自分が作ったgemのeager loadingだったが、その上に複数レイヤーのrunnerがあって診断が難しかった。DX改善にもう少し力を入れてほしいと思うが、大口顧客はこうしたワークロードを使わないため、Fly.ioにとっては優先度が高くないのだろうとも思う。プロダクションでSQLiteアプリをデプロイしている人たちがどのホストを使っているのか気になる

    • 昨年FlyでRails 8アプリを新規セットアップし、メインのデータストアにはPGを使っているが、補助的なsolid stack dbにはSQLiteを使っている。solid queueのマイグレーションに関連してRails側で少し問題はあったが、Fly側の問題ではなかった。メインのPGをSQLiteへ移行することも検討しており、現時点でも一部でSQLiteをうまく活用している

    • 自分はプロダクション環境のコンソールアプリでSQLiteを使っている。DBはファイル共有ドライブ上に置いている

  • Flyが2年間の開発停止を経て再びLitestreamの開発を再開したのはとてもうれしい。毎回Litestreamを使っていて非常に満足している。「1日数ペニー程度」という宣伝文句より実運用コストはずっと安い。実際のプロダクションアプリでS3へのLitestreamレプリケーションを使ったとき、月の実費は2〜3セント（0.02〜0.03ドル）程度だった。関連する体験談 のリンクを共有

  • 近いうちにLitestreamがすべてのs3互換宛先をサポート予定だというのは興味深い。これまではSFTPソリューションを使ってきたが、その理由はハードコードされたクラウドオブジェクトストレージサービスを使いたくないからだ。開発者たちに感謝を伝える。PRリンク および ガイドリンク

  • Litestreamを近いうちに使ってみたい。実際の復元時間がどれくらいかかるのか、ベンチマークやデモが気になる。以前は自前でS3バックアップを実装していたが、当時はLitestreamで1,000行を復元するのに20分もかかっていた。かなり最適化不足に感じられた。最近は復元速度がどれほど改善されたのか知りたい

  • Litestreamが sqlite.org/rsync と比べて持つ利点は何なのか気になる

    • Litestreamの差別化要因は、反対側に「サーバー」が不要で、オブジェクトストレージさえあればよい点だ。これはコスト面でより安くなる可能性がある

    • Litestreamではポイントインタイムリカバリ（Point In Time Recovery）が可能だ。現在時点のレプリカだけでなく、任意時点のスナップショットへ復元できる

  • LiteFSとLitestreamに関する興味深い話として、「市場の反応が答えだ。ユーザーはLitestreamをより好む」。正直、Litestreamのほうが運用しやすく理解もしやすいため、こちらに再び注力するようになった

    • 自分もそれは納得できる。LiteFSはFUSEベースのカスタムファイルシステムを実行してマウントする必要があったが、LitestreamはSQLite DBファイルと関連するWALファイルを指すGoバイナリ1つあればよい

  • Litestream Revampedに関するリンクとHacker Newsの議論を共有
    ブログ
    HNの議論

  • 社内アプリケーションを外部のリモートフリートにデプロイしているが、インターネットが不安定で、データ収集システムをきちんと作るのが難しい。Litestreamがこのような不安定な環境でバックアップをどう処理するのか、そして複数のバックアップを中央DBに統合してクエリできるのか気になる

  • 小さな注意喚起として、以前レガシーな業務アプリをAzureへ移行した際、アプリと一緒にローカルMSSQLサーバーが動く構成（ちょうどLitestreamパターンのようなもの）を扱ったことがある。アプリがローカルアクセス（1ms未満の遅延）を前提に開発されていたため、いたるところでN+1クエリが深刻に存在していた。そのせいで別構成への移行はほぼ不可能になっていた。こうした形式のホスティングを使って、後でスケールの限界にぶつかるのが心配ならおすすめしない。ただし単一マシンでもかなり大規模まで対応できるので、現実的には大きな問題にならないかもしれないとも思う

    • 単一インスタンスが20TB超のRAMと数百コアをサポートする今、この選択肢は十分競争力があると思う。ユーザー/テナント単位のセルアーキテクチャと組み合わせれば、さらに効率的な方式になり得る

    • 自分も以前、アプリサーバーとデータベースが同じラックにある製品に携わっていて、同様に低レイテンシな構成だった。その製品が成功し、N+1クエリが数千件に増えると、1msがすぐ500ms以上になった。2か月ごとにNewRelicで遅い箇所を見つけて修正する作業を繰り返していた。RailsアプリなのでN+1問題は起きやすいが、比較的直しやすくもあった

    • 間違ったクエリ慣行は遅かれ早かれ必ず問題を引き起こす。これをこのアプローチ自体の欠点と見るのは難しい

    • 実際のところ、こうしたサービスを使うと自分のコードにどれだけ問題があるかが露呈するだけなので、それほど大きなトレードオフではないと思う。サービスのせいではなくコードの問題だ

    • N+1とは何かと質問している

  • Litestreamが本当に好きだ。使いやすく、一度もクラッシュしたことがない。systemdユニットサービスとして使うのを勧める。単なるバックアップツールとしてだけでなく、データベースミラーリングにも使っている。今後登場するread-replica機能にも期待している