핵심 요약
월 트래픽 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 latency | 4.2ms | 0.3ms | -93% |
| p99 read latency | 18ms | 1.4ms | -92% |
| p99 write latency | 22ms | 9ms | -59% |
| 월 인프라 비용 | $640 | $42 | -93% |
| 최대 동시 쓰기 QPS | 8400 | 1100 | -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