Tailscale における SQLite ダウンタイムの根本原因究明と修復レポート

概要：長期不具合の解決報告

• 現状: 昨年 12 月に稼働率（Uptime）が不安定化し、新年を迎えても解消されませんでした。
• 原因: 単一の SQLite データベース上の長年のバグによるもので、数ヶ月間にわたる集中的なフォレンジック調査の結果見出されました。
• 結論: 現在、当該バグの仕組みを理解した上で修復を完了し、安定稼働を目指しています。
• お詫び: 顧客が期待する「信頼できるサービス」に応えられなかった期間につきまして、心よりお詫び申し上げます。

Tailscale のデータベースアーキテクチャと背景

• 構造:
  • クライアントは単一の公開エンドポイントを介してアクセスしますが、内部では制御サーバーを複数の**シャード（Shard）**に分割しています。
  • 各シャードには SQLite データベースがあり、その上にテールネット（Tailnet）が動作します。
  • **「単一書き手」**設計のため、SQLite の本来の使い道として適切でした。
• 採用理由:
  • 2022 年から主要データベースとして採用。広く認知され、多数の企業で信頼性高く利用されている実績があります。
• 運用状況（異常以前）:
  • 数分に一度のスナップショットを S3 にアップロードするバックアップパイプラインが 2023 年初頭より不具合なく動作していました。

問題の発覚と初期対応

• 発覚経緯: 昨年 8 月、S3 へのバックアップ読み取り時にエラーが検出されました。

  • PRAGMA integrity_check

    コマンドの結果、データベースが破損していたことが判明しました。
• 影響範囲:
  • データベースにはメタデータのみ含まれており、機密鍵や個人情報は保存されていませんでした（データの完全喪失はありませんでした）。
  • 初期対応ではダウンタイムは 1 時間以上発生しましたが、修復プロセスは徐々に高速化されました。
• 繰り返しの事象:
  • システム規模が大きいため稀な現象であっても一定頻度で発生する可能性がありました。
  • 結果として、6 ヶ月間にわたって計 19 回ものデータベース破損事象に遭遇しました。
  • ダウンタイムはテールネット全体が一時的に制御不能になるものであり、メッシュネットワーク上の接続確立に影響を与えていました。

故障箇所の検索と調査プロセス

• 初期の困難:
  • リポジトリ内の最近の変更履歴や低レベルコードレビューから原因を特定することができませんでした。
  • 特定のシャード、顧客、時間帯などに依存せず、再現可能なトリガー条件が見つけられませんでした。
• アプローチの転換:
  • 合成的な再現が不可能だったため、実環境への受動的なフォレンジックテレメトリー導入へと方針を転換しました。
  • 破損事象の間隔は数時間から数週間と不規則であり、計画が立てにくかったです。
• SQLite 開発者チームとの協力:
  • SQLite のコア開発者チームに専門サポート契約を結び、詳細な技術対話を開始しました。
  • 検証仮説：POSIX ロックの故障、メモリ管理の不備、スレッド安全性の無効化など。
  • 各事象ごとにデータを収集し、これらの仮説を体系的に否定してまいりました。

「鳴かなかったトランザクション」と WAL ファイル

• 積極的対策の実施:
  • 破損検知時の即座停止設定、自動監視システムの展開、復旧手順の改善により対応時間を 1 時間未満に短縮しました。
• トランザクションログパイプラインの開発:
  • データベースを変更するすべての SQL 文を別ログファイルに記録。
  • SQLite の「単一書き手」という性質を利用し、直線的かつ決定論的なトランザクション履歴から破損した状態を復元しようと試みました。
• 重大な手がかり:
  • トランザクションログの再生が 2 件において完全になしとなったことが判明しました。
  • 書き込まれたデータが「理由不明」に不可視化されており、エラーなしで消えていたという異常現象が発生していました。
• WAL（Write-Ahead Logging）ファイルへの焦点:
  • 破損事象は SQLite のチェックポイント（Checkpoint）プロセスに関連していたと疑われました。
  • 私どもは非標準的にチェックポイントを手動で制御しており、これが潜在的な原因として浮上しました。
  • メトリクスから報告されるコピーされたページ数が、実際に利用可能なページ数よりも多いという矛盾が観測されました。

発見：WAL-Reset バグ

• 開発者チームによるツールの導入:
  • SQLite 開発者チームは仮想ファイルシステム層向けの新しいデバッグツールを作成し、内部構造の詳細な可視化を行いました。
• バグの特定と命名:
  • **「WAL-Reset バグ」**として特定されました（SQLite に少なくとも 16 年以上存在していた可能性）。
  • 原因: チェックポイントプロセスと書き込みトランザクションの間で発生する極めて稀なデータレース（Data Race）。
    • チェックポイント中に WAL がリセットされると、コピー処理が混乱し、実際にはデータベースファイルに書き込まれず、データが永久に失われます。
• 私どもの環境との親和性:
  • このバグは非常に稀ですが、私どもがチェックポイントを頻繁かつ手動で行っていたため、発火確率が極めて高かったと解明されました。
• 修復とロールアウト:
  • 修復パッチは SQLite 3.52.0 リリースで公開されました。

誤報とさらなる修正

• 新たな問題の発見:
  • 初版修復後に「13 のデータベースが破損した」という警鐘的なアラートが発生しました。
  • しかし、これらは真正的な破損ではなく、**陳腐化された式インデックス（Stale Expression Indexes）**という別のバグによる誤報でした。
    • 高精度なタイムスタンプを文字列として保存し、変換時の丸め動作が SQLite のバージョンアップで微妙に変わったため、誤って破損と検出されていました。
• 最終的な解決:
  • SQLite チームは 3.52.0 を撤回し、WAL-Reset バグ修復のみを含む3.51.3を公開しました。
  • 私どもはタイムスタンプの精度を整数秒へ低下させることで対応し、問題解決に至りました。

検証と完了：パーティタイム！

• 修正後の監視:
  • 修復が展開されましたが、「破損事象の消失＝問題解決」ではないことを認識し、引き続き監視を続けました。
  • SQLite ドライバーにパッチを適用し、書き込みトランザクションと WAL リセットが重なる際に警告ログを出力するようにしました。
• 最終的な確認:
  • 警告が発火しても破損は起きないことを確認し、バグの挙動が検証できました。
  • 2 ヶ月後、待ち続けていたアラートが finally 発火しました。
  • これが WAL-Reset バグによるものだったことは証明され、これが長期間にわたる稼働率低下の主因であることが確認されました。
• 現在の状況: アラート発火以降、執筆時点でさらに4 ヶ月間データベース事象なく安定動作しています。

教訓と今後の展望

• 「つまらない技術」のリスク:
  • SQLite は標準的な運用であれば極めて信頼性が高いですが、チェックポイントを手動制御するなどの非標準的な構成はリスクを孕んでいます。
  • 標準的な経路から外れることは、稀なバグを発火させるトリガーとなり得ます。
• 組織的取り組み:
  • Tailscale エンジニアリングチーム、サポートチーム、SQLite コアメンテナによるクロスファンクショナルな努力が成功の鍵でした。
  • 影響範囲の拡大を防止し、迅速に修復する体制を整えました。
• 今後の対策:
  • SQLite VFS shim の資金提供を行い、類似バグの追跡と早期検知に貢献します。
  • データベースバックアップ・復旧プロセスを見直し、十数回テストして再発防止を徹底しています。
  • 万が一の不慮の事象にも備え、より強力な位置からサービスを提供いたします。