1. SQLite 기반 멀티테넌시 실험의 배경
Fizzy는 자가 호스트형 제품과 SaaS 모델을 모두 수용하기 위해 설계되었습니다. 기존의 SaaS는 거대한 중앙 데이터베이스를 사용하지만, 자가 호스트형은 SQLite와 같은 가벼운 엔진이 유리합니다. 개발팀은 두 모델의 장점을 결합하여 고객별로 독립된 SQLite 파일을 제공하는 아키텍처를 구상했습니다. 이를 통해 다음과 같은 이점을 얻고자 했습니다.
- 데이터 지역성(Data Locality): 고객의 데이터를 물리적으로 가까운 서버에 배치하여 지연 시간을 최소화하고 응답 속도를 극대화하려 했습니다.
- SQLite의 성능: 네트워크 통신 없이 프로세스 내에서 직접 데이터를 조회하므로 MySQL보다 훨씬 빠른 읽기 속도를 제공합니다.
- 격리성: 고객 간 데이터가 파일 단위로 분리되어 보안과 관리가 용이할 것으로 기대했습니다.
2. 기술적 도전과 복잡성의 증가
단순해 보였던 ‘파일 단위 데이터베이스’ 접근 방식은 실제 SaaS 환경에서 예상치 못한 복잡성을 초래했습니다. 가장 큰 문제는 기존 도구들이 이 모델에 최적화되어 있지 않았다는 점입니다.
- 복제 시스템(Beamer) 구축: SQLite는 표준적인 실시간 복제 도구가 부족하여, 개발팀은 ‘Beamer’라는 자체 복제 시스템을 직접 만들어야 했습니다. 이는 파일 변경 사항을 실시간으로 감지하고 네트워크를 통해 전송하는 고도의 엔지니어링이 요구되는 작업이었습니다.
- 교차 테넌트(Cross-tenant) 기능의 어려움: 로그인 정보나 프로필 사진처럼 여러 계정에 걸쳐 공유되어야 하는 데이터는 개별 데이터베이스 구조에서 구현하기가 매우 까다로웠습니다. 계층 구조상 테넌트 상위에 존재하는 데이터에 접근할 때마다 다른 서버의 데이터베이스와 통신해야 하는 상황이 발생하여, 당초 기대했던 단순함이 오히려 복잡성으로 변질되었습니다.
- 운영 준비성 부족: 수천 개의 SQLite 파일을 관리하고 서버 장애 시 데이터를 복구하는 운영 매뉴얼(Runbook)과 벤치마킹이 출시 전까지 충분히 검증되지 않았습니다.
3. ‘Plan B’로의 과감한 전환
출시를 불과 이틀 앞두고, 개발팀은 현재의 아키텍처가 장기적으로 유지보수에 걸림돌이 될 수 있다는 판단하에 ‘Plan B’인 MySQL 기반의 전통적 구조로 회귀하기로 결정했습니다.
- 결정의 이유: 기술적인 애착보다는 서비스의 안정성과 향후 기능 확장성을 우선시했습니다. 특히 출시 당일 대규모 트래픽이 몰릴 경우 발생할 수 있는 잠재적 위험을 감수하기 어렵다고 판단했습니다.
- 작업 내용: 일주일간의 집중적인 작업을 통해 SQLite 전용 로직을 제거하고, 데이터를 MySQL로 이전하는 스크립트를 작성하며, Active Record의 테넌트 처리를 MySQL에 맞게 수정했습니다.
4. 실험이 남긴 가치 있는 유산
비록 최종 아키텍처는 MySQL로 돌아갔지만, 실험 과정에서 개발된 기술들은 Fizzy의 성능을 높이는 데 기여했습니다.
- Kamal Proxy: 로드 밸런싱과 동적 라우팅 기능이 강화되어 현재 서비스의 핵심 구성 요소로 사용되고 있습니다. 특히 동적 라우팅 기능은 요청이 들어올 때마다 최적의 데이터 센터와 서버를 찾아주는 역할을 수행하며 시스템의 효율성을 높였습니다.
- 복제 지연 최적화: 낙관적 읽기(Optimistic Reads)와 트랜잭션 추적 기술을 MySQL 환경에 이식하여, 사용자가 데이터를 수정한 직후에도 지연 없이 최신 상태를 확인할 수 있도록 구현했습니다.