Tailscale、16年前のSQLite WALリセットバグによるデータベースの破損を追跡

2026年8月12日原文(tailscale.com)

概要

Tailscale のサービスで 大規模な障害 が発生した経緯
原因は SQLiteの深層バグ で、追跡と修正に数ヶ月を要した事例
障害の影響範囲や ユーザー体験への影響、信頼性の低下
バグ特定のための 技術的な調査・対策 と、SQLite開発者との連携
最終的な バグ発見と修正 までの詳細なプロセス

Tailscaleのサービス障害の概要

2023年末から2024年初頭 にかけて、Tailscaleの 稼働率が不安定 となった事象
コントロールプレーン の内部でシャードごとに SQLiteデータベース を利用
19回のデータベース破損 が6ヶ月間で発生、復旧や調査に多大な労力
破損時は コントロールプレーンの停止 が必要となり、該当シャードのtailnetが一時的に利用不可
影響範囲は一部だが、 信頼性の低下や顧客への不信感 を招く結果

SQLiteアーキテクチャとバックアップ体制

各シャードは 1プロセス・1データベース のシングルライター構成
数分ごとに全体スナップショットをS3へバックアップ する運用
SQLiteは「 退屈な技術」として安定運用を期待していた
2023年8月、バックアップから データベース破損 が初検知
PRAGMA integrity_check で破損を確認し、修復・原因調査を実施

問題発生時の影響範囲と対応

コントロールプレーン停止により 新規デバイス追加や設定反映不可
既存接続は維持されるが、 ネットワーク変更情報が同期されない
Web管理コンソールやAPIも一時利用不可
インシデント発生時は グローバルなステータスページ で公開
影響ユーザーは限定的だが、 繰り返しの障害で信頼性低下

バグ調査と原因究明の困難

コードの再確認・関連変更点の調査 も異常発見できず
インシデント間の共通点も見つからず、 再現性のないバグ に苦戦
ライブ環境でのフォレンジック・テレメトリ 導入による監視
インシデント発生間隔が不規則で、 調査計画が困難
SQLite開発元とのサポート契約 を締結し、共同で根本原因を追求

取った対策と新たなヒント

破損検知時の即時停止・自動復旧プロセスの強化
PRAGMA integrity_checkの自動定期実行
トランザクションログの導入 で、バックアップからの安全な復旧を目指す
トランザクションログの再生時、 コミット済みデータが消失する事象 を発見
これが SQLite内部の異常挙動 であることの重要な手がかりに

SQLiteのWALとチェックポイントの仕組み

Write-Ahead Logging（WAL）モード で運用し、パフォーマンスと同時実行性を確保
チェックポイント処理 を手動制御し、バックアップの一貫性を担保
インシデント時、 WALファイルのページ数とコピー数の不一致 を観測
SQLite開発者が 仮想ファイルシステム層のデバッグツール（tmstmpvfs shim） を新規開発
ライブ環境にshimを適用し、 次回発生時の詳細ログ取得 を実施

WAL-Resetバグの発見と修正

チェックポイントと書き込みトランザクションが競合 するタイミングで発生する レースコンディション
チェックポイント処理が 一部ページをコピー済みと誤認識 し、実際には書き込みが消失
これにより データベース破損と不可逆なデータ消失 が発生
SQLite開発者がこのバグを “WAL-Resetバグ” と命名し、修正パッチを公開
Tailscaleは 迅速に修正版SQLiteを適用 し、以降同様の破損は発生していない

障害から得た教訓と今後の取り組み

安定稼働を前提とした「退屈な技術」でも、未知のバグが潜むリスク
ライブ環境での詳細な観測・外部専門家との連携 の重要性
自動復旧・監視体制の強化 によるユーザー影響の最小化
今後も 信頼性向上と透明性確保 に努める姿勢
SQLiteコミュニティへの バグ発見・修正の貢献

以上が、TailscaleにおけるSQLite深層バグの発見と修正までの全体像です。

Hackerたちの意見

オープンソースのSQLite VFSシムを資金提供して、レースコンディションをほぼすぐに特定できたし、今後も似たようなバグを追跡するのに役立つだろう。企業がオープンソースに資金を提供する面白い例だね。この場合は、新しくて特定のデバッグツールの開発にお金を払っている。

└

そうだね、tailscaleはリーダーシップがしっかりしてるみたいで、彼らのやり方には賛成だよ。

└

2週間前から使い始めたけど、どう動くか見られて嬉しいよ。

TailscaleはGo用のどのSQLiteドライバーを使ってるの？

└

https://github.com/tailscale/sqlite

いい記事だった！この話を伝える時間を取ってくれて嬉しいよ。（利益追求の企業としてSQLiteとサポート契約を結んでくれたのも嬉しい。問題が解決した後も続けてくれるといいな。）

よく書かれた投稿で、読んでて楽しかった。 > 「単一のGoプロセスがそのデータベースに独占的にアクセスし、tailnetsのコントロールプレーンを提供している。この単一ライター設計は、SQLiteが使われるべき方法そのものだ。」この文から、ライターとチェックポイントのロジックが同じデータベース接続にあると思ったので、データレースがどう発生したのか気になった。でも、SQLiteのページのバグ詳細[0]によると、複数の接続が開いている場合にしか発生しないから、ライターとチェックポインターは異なるスレッドにいたはずだね。[0] https://sqlite.org/wal.html#the_wal_reset_bug

└

この制約が一番面白いと思う。wal-indexは-shmファイルにあり、SQLiteはそれをファイルとして使わないんだ。クライアントはそれをmmapして共有メモリとして扱い、アクセスは普通のファイルロックではなくxShmLockを通じて調整される。レースが必要なのは2つの接続で、その共有調整レイヤーが存在しなければならないから。これが16年間隠れていた理由のヒントにもなるね。ページャーの下にあるほとんどすべてはVFSインターフェースを通じて交換可能で、そういうパスを使う変わったVFSがたくさんある。共有メモリメソッドは例外だ。WALは通常、xShmMap、xShmLock、xShmBarrier、xShmUnmapを必要とし、unixとwindowsが実際にトラフィックを持つ唯一の2つの実装だ。他の人たちは実装する代わりにオプトアウトしてる。SQLiteは逃げ道を文書化していて、最初のアクセス前にlocking_mode=exclusiveを設定すると、wal-indexはヒープメモリに保持され、shmファイルは全く使われない。これがブラウザビルドが取る道だ。WASMビルドには共有メモリアピがないから、OPFSデータベースのWALは排他モードでしかできないし、ドキュメントにはこれがすべての同時実行性を排除するってはっきり書いてある。だから、代替のVFS世界はこのバグが存在していた正確なコードパスのカバレッジにはほとんど寄与しない。第三の実装になりそうな人たちはそれを避けてしまったから、見つけるのはunixでチェックポイントを使って何か変わったことをしている誰かに任せられることになる。

私たちのコントロールプレーンでは、チェックポイントプロセスを手動で制御して、迅速かつ一貫したバックアップを実行しています。 > 標準外の方法で退屈な技術を運用するのはリスクです。これは良い読み物で、業界が徐々に専門家を失っていることを思い出させてくれました。私はDBAではありませんが、この行動については過去に少なくとも数回、避けるべきものとして聞いたことがあります。専門家が避けて、一般の人が関わる機会がなかったから、文書化されることがなかったんでしょうね。

└

つまり、この理由からHOTバックアップとCOLDバックアップという概念が存在するんです。

16年前のエッジケースをデータベースの内部で追跡するのは、エンジニアリングの粘り強さの極みですね。すごい深掘りです。

もしかしたら私だけかもしれませんが、原因の説明が一致していないように思います。一つの手がかりは、破損事故の際に、私たちのメトリクスがSQLiteがWALファイルから実際に存在するページよりも多くのページをコピーしていると報告していたことです。WALファイルに10ページあって、データベースに20ページがコピーされるなら、明らかに何かがおかしいです。「WALからメインデータベースファイルにページがコピーされたと思っているが、実際にはそうではない」というのが一つの説明です。そのページはデータベースファイルに書き込まれず、そのデータは永久に失われます。最初の説明は「存在したページよりも多くがコピーされた」と言っていますが、二つ目は「コピーされるべきページよりも少ない」と言っています。私が言ったように、たぶん私が何かを誤解しているだけかもしれません。

Hacker Newsで議論の続きを見る

ハクソク