Tailscale、SQLiteに16年潜むWAL-Resetバグを特定

Tailscaleが、自社サービスの不安定さの原因を数カ月追い、SQLiteに16年間潜んでいたバグに行き着いた経緯を公開した。同社は2022年からSQLiteを主要DBに使う。コントロールプレーンは複数の「シャード」で構成され、各シャードが担当テールネットの全情報を持つSQLiteデータベースを抱え、単一のGoプロセスが排他的にアクセスする。バックアップは数分おきに完全スナップショットを取得し、ファイル全体をオブジェクトストレージへ上げていた。

この構成は2023年初頭から問題なく動いていたが、2025年8月にバックアップ側で破損が報告される。破損は6カ月で19件。影響は設定データのみだが、都度プロセスを停止して修復・復元する必要があり、対象シャードのコントロールプレーンが使えなくなった。直近の変更を洗っても関連しそうな修正はなく、低レベルコードは数年前のまま手が入っていない。トリガーが不明で再現もできず、発生間隔は数時間おきのことも数週間空くこともあった。同社はSQLite開発者とサポート契約を結ぶ。

並行して、破損を検知したらシャードを直ちに停止させ、応答時間を1時間未満に短縮。さらに、データベースを変更するすべてのSQLステートメントをログに流すトランザクションログパイプラインを構築した。狙いは安全な復旧だったが、これが手掛かりになった。2件のインシデントで再現に失敗。あるトランザクションがコミットしたはずのデータが、後のトランザクションから見えていなかった。

疑いはチェックポイント処理に向かった。SQLiteはWrite-Ahead Logging（WAL）で動作し、更新された更新ページは一旦WALに書かれる。これをメインのDBファイルへ書き戻すのがチェックポイントで、通常は自動実行されるが、Tailscaleは高速かつ一貫したバックアップのために手動制御していた。メトリクスは、破損時に実際に利用可能なページより多くをWALからコピーしていることを示していた。SQLite開発者が追加トレースを書き出す仮想ファイルシステム（VFS）層のラッパーを作り、本番投入直後に起きた破損ログからバグが特定される。原因はチェックポイントと書き込みトランザクションの間でまれに起きるデータ競合だった。

「WAL-Resetバグ」と名付けられたこの不具合は、少なくとも16年間潜んでいたと推定される。まれな現象なのにTailscaleが繰り返し踏んだのは、チェックポイントを手動で、しかも非常に積極的に作成していたためだ。修正を含む3.52.0は別の問題で撤回され、修正のみの3.51.3を経て3.53.0で決着。適用後2カ月で「待望の」アラートが出て破損しないことを確認し、以降4カ月間インシデントなしだという。ありふれた技術を非標準的に使うリスクが浮き彫りになった。