▲

Litestream v0.5.0

 (fly.io)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • Litestream v0.5.0는 SQLite 기반 애플리케이션의 복원력을 크게 향상시키는 업데이트
  • 새로운 LTX 파일 포맷을 도입하여 효율적인 시점 복구(PITR) 및 데이터 압축 기능을 지원
  • 여러 Litestream 인스턴스 간 세대(generation) 개념을 제거하여 관리 및 운용을 간소화
  • JetStream 지원 및 모던 Go SQLite 드라이버로의 전환 등 개발과 통합 환경이 더 편리해짐
  • 향후 VFS 기반 읽기 복제본 등 더 강력한 기능 추가 예정

개요 및 주요 업데이트

  • Litestream은 SQLite 애플리케이션을 위한 백업 및 복구 도구로, 오픈소스이며 어디서나 실행 가능한 점이 특징임
  • 서버 장애 복구가 간편하여, SQLite를 기반으로 한 전체 스택 애플리케이션 구축에 안전성을 보장함
  • 최신 버전(v0.5.0)은 속도 개선과 시점 복구(Point-In-Time Recovery, PITR) 를 지원함

LiteFS와 Litestream의 발전 흐름

  • Fly.io의 Ben Johnson이 개발한 주요 SQLite 관련 프로젝트는 Litestream과 LiteFS임
  • LiteFS는 FUSE 파일 시스템을 활용해 데이터베이스 내부 트랜잭션 수준의 라이브 복제를 지향함
  • 그러나 시장의 수요는 운용이 더 간단한 Litestream에 집중되어, LiteFS에서 얻은 기술적 교훈을 Litestream에 다시 적용하게 되었음

LTX 파일 포맷 도입

  • 기존의 SQLite 페이지 단위 백업 방식의 한계와 비효율성 해소를 위해 LTX(트랜잭션 기반 포맷) 를 도입함

  • LTX는 트랜잭션 순서에 따른 페이지 범위 관리 및 중복 페이지 압축(compaction) 기능을 제공함

    • 예시: 여러 LTX 파일을 최신순으로 적용, 중복된 페이지는 최신 버전만 반영하여 최종 데이터베이스 상태를 빠르게 복원 가능함
    • 파일 계층 구조를 통해 30초, 5분, 1시간 단위로 LTX 파일을 통합하여 복원에 필요한 파일 수를 대폭 줄임

  • 데이터 복구 속도는 오직 I/O 처리량에 의해 제한됨

세대(generation) 개념 제거

  • Litestream은 일반적인 유닉스 프로세스처럼 실행 및 충돌 가능하며, 동작 중단 시 데이터 동기화에 불일치 현상이 발생함
  • 이전에는 여러 인스턴스 간 충돌 방지를 위해 세대(generation) 라는 관리 방식을 도입했으나,
  • LTX로 전환하면서 트랜잭션 ID 기반 복구가 가능해져, 복잡한 세대 관리가 불필요해짐

Litestream v0.5.0 업그레이드

  • 워낙 파일 포맷이 변경되어, v0.3.x WAL 세그먼트에서 직접 복구가 불가능함
  • 업그레이드는 단순하게 새 버전 실행 → 신 LTX 파일 생성 방식이고, 이전 WAL 파일도 그대로 보존됨
  • 구성 파일 호환성도 유지됨
  • 주요 변경점: 이제 데이터베이스 당 단일 복제 대상만 허용되며, 이는 개발 용이성과 복제 충돌 회피를 위한 결정임
  • 명령어는 기존과 같으나, 트랜잭션 ID(TXID) 기반 참조 방식으로 변경됨

기타 개선점

  • LTX 파일 포맷 라이브러리의 페이지 단위 압축 및 인덱스 추가로 대용량 파일 내 선택적 페이지 접근 및 기능 확장 가능함
  • 향후 특정 시점 데이터 쿼리 등 추가 기능이 구현 가능해짐
  • CGO 의존성 제거 및 Go SQLite 드라이버를 modernc.org/sqlite로 전환하여 자동 빌드와 크로스 컴파일 환경에 이점이 생김
  • JetStream 지원 복제본 타입과, S3/Google Storage/Azure Blob Storage 클라이언트 최신화 및 S3 API 신버전 지원이 포함됨

향후 계획

  • 읽기 복제(target) 환경을 위한 Litestream VFS 기능 개발이 진행되고 있음
  • 이 기능을 통해 S3에서 필요한 페이지만 즉시 읽어서 빠른 복제 생성이 가능해질 예정임
  • 프로토타입이 이미 존재하며, 공개를 앞두고 있음
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • Fly.io에 SQLite 앱을 배포하는 과정에서 개발자 경험이 다소 아쉬움, 프로덕션 Rails 앱을 실행하려고 몇 시간 동안 시도했지만 데이터베이스 초기화, 마이그레이션, 쓰기 가능 상태 등 다양한 문제에 부딪혔음, 문제의 근원은 자신이 만든 gem의 eager loading이었지만, 그 위에 여러 레이어의 runner가 있어서 진단이 어려웠음, DX 개선에 좀 더 힘을 써줬으면 하는 바람이 있지만, 큰 고객들이 이런 워크로드를 쓰지 않기 때문에 Fly.io 입장에서는 우선순위가 아닐 것으로 생각함, 프로덕션에서 SQLite 앱을 배포해본 사람들이 어떤 호스트를 쓰고 있는지 궁금함

    • 작년에 Fly에서 Rails 8 앱을 새로 세팅했고, 메인 데이터 저장소로 PG를 쓰고 있지만 보조 solid stack db들은 SQLite를 사용함, solid queue 마이그레이션과 관련해 Rails단에서 약간의 문제가 있었으나 Fly 쪽 문제는 아니었음, 메인 PG를 SQLite로 이전하는 것도 고려 중이며 현재는 일부에서 SQLite를 잘 활용하고 있음

    • 나는 프로덕션 환경에서 콘솔 앱에 SQLite를 사용하고 있음, DB는 파일 공유 드라이브에 위치함

  • Fly가 2년간의 개발 중단 끝에 다시 Litestream 개발을 재개해서 매우 반가움, Litestream을 매번 사용하는데 너무 만족함, “하루에 몇 페니 정도”라는 광고 문구보다 실사용 비용이 훨씬 저렴함, 실제 프로덕션 앱에서 S3로 Litestream 복제를 썼을 때 월 실제 비용이 2~3센트(0.02~0.03달러) 수준이었음 관련 경험담 링크 공유

  • 곧 Litestream이 모든 s3-호환 목적지 지원 예정이라는 사실이 신기함, 지금까지는 SFTP 솔루션을 사용 중인데 이유는 하드코딩된 클라우드 오브젝트 스토리지 서비스를 쓰지 않기 때문임, 개발자들에게 감사의 말을 전함 PR 링크 및 가이드 링크

  • Litestream을 곧 사용해보고 싶음, 실제 복원 시간이 얼마나 걸리는지에 대한 벤치마크나 데모가 궁금함, 예전에는 직접 S3 백업을 구현했는데 당시에는 Litestream으로 1,000개 행을 복원하는 데 20분이나 걸렸음, 꽤 비최적화된 느낌이었음, 요즘 복원 속도가 얼마나 개선됐는지 궁금함

  • Litestream이 sqlite.org/rsync 대비 갖는 장점이 무엇인지 궁금함

    • Litestream의 차별점은 다른 쪽 끝에 “서버”가 필요 없고 오브젝트 스토리지만 있으면 된다는 점임, 이게 비용상 더 저렴하게 작용할 수 있음

    • Litestream에서는 시점 복구(Point In Time Recovery)가 가능함, 현재 시점 레플리카만 있는 것이 아니라 아무 시점 스냅샷으로 복원이 가능함

  • LiteFS와 Litestream에 관련된 흥미로운 이야기로, “시장 반응이 답이다! 사용자들은 Litestream을 더 선호한다”, 솔직히 Litestream이 더 쉽게 운용되고 이해하기 쉬워서 이쪽에 다시 집중하게 됐음

    • 내 생각에도 말이 됨, LiteFS는 FUSE를 기반으로 커스텀 파일시스템을 실행하고 마운트해야 했지만, Litestream은 SQLite DB 파일과 관련된 WAL 파일을 가리키는 Go 바이너리 하나만 있으면 됨

  • Litestream Revamped 관련 링크와 Hacker News 토론글을 공유함
    블로그
    HN 토론글

  • 우리는 사내 애플리케이션을 외부 원격 플릿에 배포하고 있는데 인터넷이 불안정해서 데이터 수집 시스템을 제대로 만들기 힘듦, Litestream이 이런 불안정한 환경에서 백업을 어떻게 처리하는지, 그리고 여러 백업을 중앙 DB로 통합해서 쿼리할 수 있는지 궁금함

  • 소규모 경고로, 한 번은 레거시 비즈니스 앱을 Azure로 이전할 때 앱과 함께 로컬 MSSQL 서버가 동작하는 구조(마치 Litestream 패턴처럼)를 다루게 됐음, 앱이 로컬(1ms 미만 지연) 접근을 가정하고 개발되어서 모든 곳에 N+1 쿼리가 심각하게 있던 경험이 있음, 이로 인해 다른 구조로 전환하는 것이 거의 불가능해졌음, 만약 이런 형태의 호스팅을 썼다가 스케일 한계에 부딪힐까봐 걱정된다면 추천하지 않음, 다만 단일 머신만으로도 상당히 큰 규모까지 갈 수 있으니 현실적으로는 별 문제 아닐 수도 있다고 봄

    • 단일 인스턴스가 20TB 이상의 RAM과 수백 개의 코어를 지원하는 요즘, 이 옵션은 충분히 경쟁력이 있다고 생각함, 사용자/테넌트 단위로 셀 아키텍처와 결합하면 더 효율적인 방식이 될 수 있음

    • 나도 예전에 앱 서버와 데이터베이스가 같은 랙에 있던 제품을 작업했었는데, 비슷하게 저지연 구조였음, 그 제품이 성공해서 N+1 쿼리가 수천 개로 늘어나면 1ms가 곧 500ms 이상이 되곤 했음, 두 달마다 NewRelic에서 느린 구간 찾아 고치는 작업이 반복됐음, Rails 앱이라 N+1 문제가 쉽게 발생하지만 고치기도 비교적 쉬웠음

    • 잘못된 쿼리 관행은 언젠가는 반드시 문제를 일으킴, 이 접근 방식 자체의 단점이라고 보기는 어려움

    • 사실 결국 이런 서비스를 쓰면 자신의 코드가 얼마나 문제가 있는지 드러나는 것뿐이라는 점에서 큰 트레이드오프가 아니라고 생각함, 코드 탓이지 서비스 탓이 아님

    • N+1이 무엇인지 질문함

  • Litestream을 정말 좋아함, 사용이 쉽고 한 번도 크래시가 없었음, systemd 유닛 서비스로 쓰는 것을 추천함, 백업 툴로만 쓰는 게 아니라 데이터베이스 미러링에도 사용 중임, 앞으로 나올 read-replica 기능도 기대 중임

답변달기