본문 바로가기
Database2026년 5월 17일5분 읽기

Litestream + LiteFS 프로덕션 — SQLite 복제 6개월 운영

YS
김영삼
조회 1044
Litestream + LiteFS 프로덕션 — SQLite 복제 6개월 운영

핵심 요약

월 트래픽 1,200만 PV SaaS를 Postgres에서 SQLite + Litestream + LiteFS로 옮겨 6개월 운영. p99 쿼리 지연 18ms -> 1.4ms, DB 비용 월 $640 -> $42로 떨어졌다. 단, 동시 쓰기 1만 QPS 이상 워크로드와 복잡한 트랜잭션은 여전히 Postgres가 답.

1. 아키텍처 한눈에

Litestream은 WAL을 S3로 스트리밍 백업, LiteFS는 FUSE 파일시스템으로 primary/replica 노드 간 실시간 복제. 둘은 함께 쓸 수도 있고 따로 쓸 수도 있는데, 우리는 둘 다 썼다 — LiteFS로 읽기 분산, Litestream으로 PITR(특정 시점 복구).

# litestream.yml
dbs:
  - path: /data/app.db
    replicas:
      - type: s3
        bucket: my-backup
        path: prod/app
        region: ap-northeast-2
        sync-interval: 1s
        retention: 720h
        snapshot-interval: 1h

2. LiteFS 설정 — primary 자동 선출

# litefs.yml
fuse:
  dir: "/litefs"
data:
  dir: "/var/lib/litefs"
lease:
  type: "consul"
  consul:
    url: "http://consul:8500"
    key: "litefs/prod"
proxy:
  addr: ":20202"
  target: "localhost:8080"
  db: "app.db"

proxy 섹션이 핵심: replica에 들어온 쓰기 요청을 자동으로 primary로 포워딩한다. 앱 코드는 자기가 primary인지 모른 채 동작.

3. 6개월 운영 지표

지표Postgres 14(RDS)SQLite+LiteFS변화
p50 read latency4.2ms0.3ms-93%
p99 read latency18ms1.4ms-92%
p99 write latency22ms9ms-59%
월 인프라 비용$640$42-93%
최대 동시 쓰기 QPS84001100-87%
장애 횟수1회3회+2

4. 장애 사례 1 — FUSE 패닉

3월에 LiteFS 노드 한 대가 FUSE 모듈 메모리 누수로 OOM. primary였던 탓에 13초간 쓰기 중단. 원인은 LiteFS 0.5.10 버그였고 0.5.12에서 수정됨. 교훈: 모든 노드에 OOM killer 알람을 걸고, primary lease TTL을 5초로 줄였다.

5. 장애 사례 2 — S3 throttling

마케팅 이벤트로 쓰기가 평소 10배 폭주, Litestream이 S3 PUT을 초당 4천 번 시도하다 throttled. 백업이 30분 밀렸는데 그동안 PITR 윈도우가 비었다. 해결: sync-interval을 1s에서 5s로, snapshot-interval은 1h 유지, 별도 EBS 스냅샷도 병행.

6. 쓰기 패턴 최적화

-- 부팅 시 1회
PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA cache_size=-64000;   -- 64MB
PRAGMA mmap_size=268435456; -- 256MB
PRAGMA wal_autocheckpoint=1000;
PRAGMA busy_timeout=5000;

이 설정만으로 동시 쓰기 처리량이 3.4배 늘었다.

7. 복구 실전 — PITR 1분 30초

litestream restore \
  -timestamp 2026-04-22T14:32:00Z \
  -o /tmp/restored.db \
  s3://my-backup/prod/app

총 1분 32초. Postgres pgBackRest로 같은 작업하면 보통 15분 이상.

8. 결론

월 PV 500만 ~ 5000만, 쓰기 QPS 2000 이하, 단일 리전 서비스에는 적극 권장. 그 이상 또는 다중 리전 강일관성이 필요하면 Postgres·CockroachDB가 답. SQLite는 운영 부담이 적은 대신 한계가 명확하니 워크로드를 정직하게 측정하고 결정해야 한다.

참고

  • litestream.io
  • fly.io/docs/litefs
  • sqlite.org/wal.html
  • github.com/superfly/litefs

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록