Litestream Writable VFS → **Litestream の書き込み可能な VFS**

著者

• 名前: ベン・ジョンソン
• ハンドル: @benbjohnson

画像提供: Annie Ruygt

---

私はベン・ジョンソンです。Fly.ioでLitestreamを開発しています。LitestreamはSQLite用の「欠けていたバックアップ／リストアシステム」です。無料でオープンソース、どこでも動くように設計されており、詳細はこちらをご覧ください。

毎回記事を書くたびに、Litestreamを簡潔に説明するスキルが向上しています。いかがでしょうか：

Litestream は、SQLite データベースを S3 互換オブジェクトストレージと同期させる Unix ライクなツールです。SQLite の高速さとシンプルさを享受しつつ、データ損失の恐怖から解放します。アプリ側は存在を意識する必要もなく、バックグラウンドでツールとして走らせるだけです。

ここ数週間は非常に忙しく過ぎました！

最近 Sprites を公開しました。Sprites が何かご存知でない方はぜひチェックしてみてください。私たちが今まで出した中でもっともクールな製品の一つです。今回はそれを販売する時間はありません。ただ言うと、Sprites は大きな話題であり、Litestream がそのロードバリアングコンポーネントとして機能していることは私にとって重要です。

Sprites で Litestream を使う方法

Sprites は Litestream に直接依存しています。主に次の二点です。

1. グローバル Sprites オーケストレーター

   • Fly Machines（PostgreSQL クラスターを前提とした製品）とは異なり、Elixir で書かれた Sprites オーケストレーターは S3 対応オブジェクトストレージから直接稼働します。
   • Sprites に登録された各組織には、Litestream が同期する専用 SQLite データベースが割り当てられます。

2. ディスクストレージスタック

   • Sprites は 1 秒以内に起動し、100 GB の耐久ストレージをブート時に確保します。
   • ストレージの根幹は S3 対応オブジェクトストレージです。NVMe をリードスルーキャッシュとして活用した「使用中ブロック」のデータベースで高速化しています（システム名：JuiceFS）。
   • 「ブロックマップ」データベースは BoltDB に基づく再実装メタデータストアで、もちろん Litestream SQLite です。

Sprite のストレージは厳格

Sprite 内のすべては高速起動を前提に設計されています。Fly Machine が落ちた場合、ブロックマップをオブジェクトストレージから再構築する必要があります。ブロックマップは大きくありませんが、数十メガバイトには達します。

この作業は Sprite の起動中に行われます—すなわちウェブリクエストへの応答として発生し得ることです。時間的余裕は極めて限られています。

さらに高速化するため、Litestream VFS を統合して起動時間を短縮しています。

使い方例

sqlite> .open file:///my.db?vfs=litestream
sqlite> PRAGMA litestream_time = '5 minutes ago';
sqlite> SELECT * FROM sandwich_ratings ORDER BY RANDOM() LIMIT 3;
22 | Veggie Delight   | New York     | 4
30 | Meatball         | Los Angeles  | 5
168| Chicken Shawarma Wrap | Detroit | 5

Litestream VFS は、オブジェクトストレージのバイナリから直接ポイント‑イン‑タイムの SQLite クエリを実行できるため、データベース全体をダウンロードする前にクエリ結果が返ります。

これは良いですが完璧ではありません。2 つの問題点があります：

1. 読み取りのみで書き込みができない。Sprite のディスクは書き込み対象です。
2. オブジェクトストレージから直接クエリを実行することは、冷却起動時にデータベース全体をダウンロードしなくても済むという恩恵がありますが、常時運用では十分高速とは言えません。

---

書き込み可能な VFS

最初の取り組みとして、VFS を読み書き可オプションにしました。これは微妙で興味深い機能ですが、必ずしも汎用的というわけではありません。

• VFS はオブジェクトストレージ内の各ページを

  (file, offset, size)

  でインデックス化します。このインデックスは LTX ファイルに格納され、VFS 起動時に迅速に再構築できるよう設計されています。
• 読み取り専用モードでは、リモートライターが作成した新しい LTX ファイルをポーリングで検知します。
• 書き込みモードでは複数書き手は許可せず、VFS はポーリングを無効化します。単一の書き手のみを想定し、追加バックアップの監視も行いません。
• 書き込みはローカルテンポラリバッファ（「書き込みバッファ」）へ送られます。1 秒ごとまたはクリーンシャットダウン時に、このバッファをオブジェクトストレージと同期します。VFS 経由で書き込まれたデータは、同期が完了するまで実質的に耐久性を持ちません。

この書き込みモードにより、Sprite は起動後数ミリ秒で書き込みを受け付けることができ、10 MB のブロックマップの完全コピーを保持せずとも「最終的な耐久性」を実現します。Litestream VFS で書き込みを有効にするには

LITESTREAM_WRITE_ENABLED=true

を設定してください。

---

水和（Hydration）

Sprite ストレージスタックは SQLite を VFS モードで使用しています。当初の VFS 設計では、ほとんどのデータが S3 に保持されるため、冷却起動時には便利ですが、常時運用では不十分です。

そこで、dm‑clone などから取り入れた「バックグラウンド水和」を採用しました。

LITESTREAM_HYDRATION_PATH

を設定して VFS を起動すると、水和処理が開始されます。

• 水和は各ページの最新バージョンのみを書き込み（LTX 圧縮を通じて）します。
• 読み取りは水和中でもブロックストレージから即座に提供され、準備完了次第水和ファイルへ切り替わります。
• 水和ファイルはデータベースの完全コピーです。

  litestream restore

  を実行したときと同じ状態になります。

Sprites のような頻繁に再起動する環境を想定しているため、データベースは一時ファイルに書き込まれます。終了時には水和ファイルを破棄します。この挙動は VFS に組み込まれています。

---

まとめ

これら二つの大規模変更は、Sprites のストレージスタックが抱える問題に特化したものです。もしご自身で有用だと感じたらぜひ教えてください。

通常の読み書きワークロードでは、この仕組みを使う必要はありません。Litestream は VFS を介さずにサイドカーとして動作させても十分に機能します。VFS の主目的は、データベース全体が書き込み可能な状態であることを効率的に保つことです。

しかし、私にとってこの一連の実装は、Litestream が比較的複雑かつ要求の高いドメインでどのように活用できるかを示す貴重なケーススタディです。Sprites は本当にクールで、Sprite 上で発生するすべてのディスク書き込みが Litestream を経由していることは非常に満足感があります。

---

前回の記事 →
The Design & Implementation of Sprites