Tailscale이 데이터베이스 손상 원인을 16년 된 SQLite WAL-Reset 버그로 추적한 과정

6개월간 발생한 19건의 데이터베이스 손상과 반복적인 제어 평면 장애를 조사한 끝에, SQLite 체크포인트와 쓰기 트랜잭션 사이의 희귀한 데이터 경쟁을 찾아냄 WAL 페이지가 주 데이터베이스에 복사되지 않았는데도 체크포인트가 완료된 것으로 처리돼 데이터가 영구 소실됐으며, SQLite 개발진은 이를 WAL-Reset 버그로 명명함 재현 조건을 찾지 못해 운영 환경에 진단 도구를 배포하고, SQL 트랜잭션 로그와 tmstmpvfs VFS 추적으로 사라진 쓰기와 비정상적인 체크포인트 통계를 연결함 수정판인 SQLite 3.52.0은 부동소수점 변환 변화로 13개 데이터베이스에 거짓 손상 경고를 일으켜 철회됐고, WAL-Reset 수정만 담은 3.51.3과 자체 복구 인덱스를 지원하는 3.53.0으로 정리됨 문서화되고 지원되는 기능이라도 수동 체크포인트를 공격적으로 실행하는 비표준 운용 방식은 일반 설정보다 검증 범위가 좁으며, Tailscale은 복구 자동화와 백업 검증 체계를 강화함 Tailscale의 SQLite 구성 공개적으로는 단일 엔드포인트인 controlplane.tailscale.com을 제공하지만, 내부 제어 평면은 여러 조정 서버 샤드로 나뉨 각 tailnet은 한 번에 하나의 샤드에 속하며 다른 샤드로 원활하게 이동할 수 있음 각 샤드는 tailnet 정보를 담은 SQLite 데이터베이스를 보유하고, 단일 Go 프로세스만 독점적으로 접근함 2022년부터 SQLite를 주 데이터베이스로 사용했으며, 단일 작성자 구조는 SQLite가 의도한 사용 방식과 일치함 백업 파이프라인은 몇 분마다 데이터베이스 전체 스냅샷을 만들고 SQLite 파일을 S3에 업로드함 이 구성은 2023년 초부터 별다른 사고 없이 운영됨 지난해 8월 S3 백업을 읽는 데이터 파이프라인에서 오류가 발생했고, PRAGMA integrity_check로 실제 손상을 확인함 첫 데이터베이스를 복구하고 원인을 조사했지만 당시에는 찾지 못함 이후 6개월 동안 별개의 손상 사고가 총 19회 발생함 손상 사고가 서비스에 미친 영향 데이터베이스에는 tailnet과 장치의 구성 메타데이터가 저장되며, 사용자의 비공개 암호화 키나 네트워크 트래픽은 들어 있지 않음 초기 복구 과정에서는 일부 신규 장치와 구성 변경이 유지되지 않아 소량의 메타데이터를 다시 입력해야 했음 손상된 샤드의 데이터베이스를 복구하거나 복원하는 동안 제어 평면 프로세스를 중단...