▲

Litestream이 이제 빠른 시점 복구가 가능해집니다

 (fly.io)
6P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • Litestream은 SQLite 기반의 전체 스택 애플리케이션을 안전하게 객체 저장소에 백업하며, 이번에 가장 큰 기능 변경이 이루어짐
  • 기존 구조보다 효율적인 LTX 파일 포맷과 컴팩션 기법을 적용해 빠르고 효율적인 시점 복구가 가능해짐
  • Conditional write를 활용한 새로운 방식으로 리더 싱글톤 및 read replica 기능 구현을 단순화함
  • 곧 VFS 기반 read-replica 계층이 제공되어 다양한 환경에서 손쉽게 확장 가능함
  • 대폭 개선된 구조로 다수의 데이터베이스 동시 동기화가 가능해져 확장성이 높아짐

Litestream 소개 및 중요성

  • Litestream은 오픈소스 도구로서 SQLite를 기반으로 하는 다양한 전체 스택 애플리케이션을 객체 저장소에 안전하게 백업하는 기능을 제공함
  • SQLite의 임베디드 특성으로 인해 데이터가 한 서버에 종속되던 문제를 해결하고, 서버 장애 시에도 데이터 복구가 용이해짐

Litestream의 발전 과정

  • SQLite를 더 쉽게 활용하기 위해 Litestream이 2020년에 등장했음
  • Litestream은 SQLite 애플리케이션과 별도의 프로세스로 실행되며, WAL 체크포인팅 프로세스를 대체해 실시간으로 데이터 변경 사항을 S3와 같은 객체 저장소로 스트리밍함
  • 서버가 손실되어도, 객체 저장소에서 최신 상태로 데이터베이스를 효율적으로 복구할 수 있음
  • 이후 LiteFS라는 프로젝트가 추가 개발되어 read replica와 기본 장애조치(Primary Failover)까지 지원하는 등, SQLite를 Postgres와 같은 현대적 배포 구조로 활용할 수 있게 만듦
  • LiteFS와 Litestream 모두 장점이 있으나, Litestream은 더 널리 사용될 정도로 배포 및 사용이 쉬움

효율적인 시점 복구(Point-in-time Restore)

  • 이전 Litestream 설계는 모든 변경 사항을 지속적으로 기록해 S3에 전송했으나, 데이터가 잦게 변경되는 경우 복구 시 비효율적임
  • LiteFS에서는 트랜잭션 인지 기반의 접근법을 도입, 변경 페이지 범위를 정렬해서 기록하는 LTX 파일 포맷 사용
  • 여러 LTX 파일을 쉽게 병합(compaction)해 최신 버전만 남기는 방식으로, 데이터 복구 속도와 효율성을 대폭 향상시킴
  • 이 구조는 LSM 트리와 유사함
  • 새로운 Litestream에서도 LTX 파일 및 컴팩션 방식을 도입하여 많은 중복 저장 없이 정확한 시점 복구 지원이 가능해짐

CASAAS: Compare-and-Swap as a Service

  • Litestream은 SQLite 애플리케이션이 백업 시스템을 인지하지 않아도 작동해야 하며, 장애 등으로 프로세스가 죽는 경우 데이터 변경 누락이 발생 가능함
  • 이런 문제를 해결하기 위해 generation이라는 개념을 도입해 각 백업 세션과 그에 대한 로그 스트림을 고유하게 식별함
  • LiteFS에서는 Consul을 이용해 싱글 리더를 보장했으나, 외부 종속성 필요성 때문에 Litestream은 S3 등 객체 저장소의 conditional write 기능으로 단일 복제 경로(싱글톤)를 간편하게 구현함
  • 이에 따라 ephemeral 노드 환경에서도 혼동 없이 안정적인 동작이 가능해짐

경량 read replica 기능

  • LiteFS는 트랜잭션 인지를 위해 FUSE 파일시스템을 사용하지만, 이는 복잡성과 도입 부담이 있음
  • 이를 완화하기 위해 LiteVFS라는 SQLite Virtual Filesystem(VFS) 확장 모듈을 통해 FUSE 없이도 다양한 환경에서 동작 가능하게 설계됨
  • 향후 Litestream에도 동일한 VFS 기반 레이어를 적용하여 S3 등 객체 저장소에서 직접 페이지를 fetch하고 cache하는 read-replica 계층을 제공 예정임
  • 로컬 SQLite처럼 빠르지는 않으나, 캐싱 및 prefetching 전략을 통해 많은 사용 사례에서 만족스러운 성능 제공 가능성 기대함

오픈 소스 및 활용성

  • Litestream은 완전한 오픈소스이며, Fly.io에 종속되지 않고 어디서든 사용 가능함
  • 대량의 데이터베이스를 하나의 프로세스에서 동기화하는 기능이 추가되어, 수백~수천 개 데이터베이스도 효율적으로 백업/복제 가능해짐

SQLite와의 지속적 동반성장

  • SQLite는 산업 변화 속에서도 꾸준히 새로운 활용 사례를 창출하는 견고한 데이터베이스임
  • 최근 LLM 기반 코드 생성 에이전트와 같은 분야에서도, 실시간 데이터 롤백 및 분기가 중요해짐에 따라 Litestream의 발전된 시점 복구 기능이 중요한 기반이 될 수 있음
  • 향후 이러한 개선된 아키텍처는 롤백, 포크, 자동화 에이전트 대응 등 확장 기능에도 기여할 것임
  • 새로운 Litestream은 기존 디자인 대비 보다 우수하며, 확장성과 사용성을 모두 강화함
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 코드 저장소 위치를 찾은 경험 공유 내용, 2년 전 litestream과 litefs 사용에 불편함이 있었지만 이번에는 대부분의 문제가 해결된 느낌이라는 의견, 이제는 데이터베이스에 litestream을 자유롭게 적용할 수 있고 여러 writer 문제에 대한 걱정이 줄어들었다는 관점, read replica FUSE 레이어의 장점을 기대하는 입장, 관련 풀 리퀘스트에서 lease 인수 방식에 대해 소개(lease가 이미 있으면 새로운 프로세스가 1초 간격으로 재시도해 빠른 롤링 리스타트 지원), 실용적인 접근 방식이라는 생각

  • 새로운 Litestream에서 내가 바라던 모든 기능이 구현된 것 같다는 느낌, 기대감과 흥분되는 감정

  • 매우 똑똑하고 배포가 간단해지는 방식에 대해 긍정적 시각, 수천 개의 SQLite DB 백업이 필요한 상황에서 지금까지는 fanotify와 SQLite의 Backup API로 임시 방편을 제작 경험, wildcard replication이 많은 파일을 지원한다면 Litestream으로 전환하고 싶다는 기대

  • LTX 전환 이후 한 디렉토리에 수백, 수천 개의 데이터베이스가 있어도 /data/*.db 복제가 가능해진 점 강조, 이 부분이 이전에는 결정적 장애였다는 입장, 이젠 멀티 테넌트 환경에서 각 사용자 별 데이터베이스 단위로 원하는 시점 복구나 데이터 다운로드 및 이관이 가능해지는 점에 대한 긍정적인 전망

  • ben에게 감사 인사와 함께 실사용 경험을 공유, 약 1년 이상 write-heavy 내부용 케이스에(압축 기준 약 12GB) litestream을 프로덕션에서 사용하며 월 비용이 극소수(azure 기준 몇 백원)에 불과하다는 점 소개, 새로운 변경 사항 적용을 기대하는 입장

  • Fly의 SQLite 기반 개발자 경험이 좀 더 다듬어지길 바라는 마음, 현재 아쉬운 점으로 자체 UI와 CLI가 부족해 초기 데이터베이스를 Fly Machine에 세팅하는 작업이 생각보다 많은 과정이라는 점, fly console은 SQLite와 제대로 연동이 안되고 별도 머신에서 실행되어 데이터가 있는 볼륨에 접속할 수 없는 점, 결국 fly ssh console —pty로 직접 해당 머신에 들어가야 하는 불편함 지적, SQLite 기반 웹앱은 소규모가 대부분이라 수익을 내려면 많은 개수를 운영해야 한다는 고충

    • Rails 8과 SQLite 조합에 대한 개인의 선택 방향 질문, 최근 Postgres보다 더 선호하는지 궁금증 제기

  • Litestream을 막 조사하던 중 타이밍 좋게 글을 접한 개인적 경험 공유, VPS에서 Sqlite를 사용하며 Litestream 도입을 고려 중, Litestream 프로세스가 실행 중인 동안 특정 시점으로 데이터베이스를 복구할 수 있는지 질문, auto-checkpointing이 프로세스가 다운됐을 때 WAL을 소비하기 때문에 복구 불가 시간대(예시: 장애로 2:00~3:00 동안 프로세스 중지, 1:55 또는 3:05에는 복구 가능하지만 2:00~3:00 사이 복구 정보는 사라짐)에 대해 궁금증 표시

    • Litestream은 WAL 세그먼트를 특정 시간 단위로 저장, 기본적으로 WAL 변경 내역을 매초 전송해서(설정한 보존기간 내) 원하는 시점의 초 단위 복구가 가능하다는 설명

    • DST(일광절약시간) 처리 문제에 대한 질문, 유럽 기준 3월 30일에 2:00에서 3:00로 시간이 점프하는 상황에서의 동작 방식 궁금증 제기

  • 과거 dynamodb 기반 DonutDB라는 sqlite vfs를 만든 경험 공유, S3에 CAS(Content Addressable Storage) 기능이 추가된 점을 계기로 DonutDB를 S3 지원 버전으로 리뉴얼하려고 했고, 이번에 lightstream이 이를 지원해줘서 직접 개발할 필요가 없어진 점 반가움 표시, 새로운 도구 사용에 대한 기대

    • S3에 CAS(Content Addressable Storage)가 추가됐다는 언급에 대해 공식 자료나 참고 링크를 요청, CAS 의미가 맞는지 확인하고 싶다는 궁금증 표현

  • 앱 배포시 기존 방식에서는 새로운 서버 인스턴스를 띄워 헬스체크가 통과되면 트래픽을 전환하고 기존 서버를 종료하는데, 이 전환 과정에서 데이터베이스 변경사항 손실 문제가 있었다고 회상, 이번 변경 사항으로 이 문제가 해결됐는지 궁금증 제기

    • 서버를 일회성 웹 서버 인스턴스가 아닌 프로덕션 데이터베이스 관점으로 봐야 한다는 의견, python/sqlite 웹앱 배포시 머신 전체를 바꾸지 않고 패키지만 업그레이드하고 systemd 서비스를 재시작하는 방식을 사용, 다운타임 줄이려면 SO_REUSEPORT 등으로 전환 과정을 고민할 수 있고, 이때 새 구버전 프로세스가 데이터베이스를 동시에 사용할 수 있지만 DB 스키마 변경이 포함되면 일정 다운타임은 불가피하다고 판단, 이는 다른 DB도 마찬가지일 수 있다는 견해

    • 쉽게 해결되진 않는 문제라는 입장, 여전히 한 writer만 lease를 잡을 수 있기 때문, 새 서비스가 실행돼도 이전 writer가 내려가야만 lease를 얻을 수 있음, writer 교체를 위한 도구는 제공되지만 요청 대기 또는 짧은 다운타임은 어쩔 수 없다는 설명

  • litestream으로 사용자별로 수많은 데이터베이스를 복제하려면(문서에서 다루는 대표 use case), 런타임에 새로운 데이터베이스를 동적으로 추가할 방법이 궁금하다는 질문, 현재 설정 파일이 정적이고 실시간 API를 찾지 못했다는 경험 공유

    • 이 문제는 결국 해결될 것으로 예상, 새로운 SQLite 탐지 로직이 까다롭지만 불가능하지 않다고 지적, 그 전까지는 라이브러리 형태로 쉽게 사용 가능하다는 안내
답변달기