SQLite 기반 Rails 앱의 핵심 차이점 및 도전 과제
SQLite는 웹 서버 프로세스 내부에 내장되어 별도의 데이터베이스 서버 없이 단일 파일로 데이터를 관리합니다. 이는 인프라를 단순화하고 연결 오류를 없애는 장점이 있으나, 동시에 몇 가지 중요한 운영 및 배포 고려 사항을 발생시킵니다.
- 데이터 영속성 확보:
- 컨테이너 환경에서 재시작 시 데이터가 유실될 수 있으므로, SQLite 데이터베이스 파일은 반드시 AWS EBS나 Fly.io 볼륨과 같은 영구 저장소에 보관하고 자동 스냅샷을 활용해야 합니다.
- 동시성 및 스케일링:
- Rails 모델, 캐시, Active Job 큐 등 모든 데이터가 기본적으로 하나의 SQLite 파일에 저장되어 동시 접근 시 파일 시스템 락으로 인한 병목 현상이 발생하기 쉽습니다.
- 수평 스케일링(VM 추가)이 불가능하며, CPU와 RAM을 증설하는 수직 스케일링에 의존해야 합니다.
- 백그라운드 작업은 웹 프로세스와 동일한 VM 내에서 별도 프로세스나 스레드로 실행하여 데이터 파일에 접근해야 합니다.
- 동시성 문제 해결 전략:
- WAL(Write-Ahead Log) 모드: 쓰기 작업은 로그 파일에 기록하고 읽기 작업은 동시에 처리하여 동시성을 향상시킵니다. 단, 백업 시 주 파일과 WAL 파일을 함께 관리해야 합니다.
- 다중 DB 파일: Active Record, 캐시, 백그라운드 작업 등 기능별로 별도의 SQLite 파일을 사용하여 서로 다른 접근 패턴 간의 경쟁을 줄일 수 있습니다.
- 단일 서버 아키텍처의 제약:
- 단일 서버는 다운 시 전체 서비스 중단으로 이어지며, 컨테이너 환경에서 무중단 배포가 어렵습니다.
- 로드 밸런싱이나 지리적 분산(read replica)이 불가능한 한계가 있습니다. 다만, 디버깅은 단순해집니다.