lobste.rs는 왜 서버 DB를 MariaDB 대신 SQLite로 옮겼을까요

lobste.rs는 왜 서버 DB를 MariaDB 대신 SQLite로 옮겼을까요

IT & AI 뉴스 썸네일

개발자 커뮤니티 lobste.rs가 운영 데이터베이스를 MariaDB에서 SQLite로 옮겼어요. 첫 배포는 CPU 사용률이 100%까지 치솟아 되돌렸지만, 병목 쿼리 3개를 고친 뒤 두 번째 배포에 성공했어요. 작은 서비스가 데이터베이스 구조를 단순하게 만들 때 무엇을 준비해야 하는지 보여 주는 사례예요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
운영 결과	월요일 트래픽 증가를 처리했고 CPU와 메모리 사용량도 줄었어요	SQLite가 실제 웹서비스에서도 조건에 따라 충분히 버틸 수 있다는 운영 사례예요
비용	별도 MariaDB VPS를 내리면 전체 VPS 비용이 절반으로 줄어요	데이터베이스 선택이 서버 구조와 고정비에 바로 연결돼요
성능	전체 테이블 스캔 2건과 N+1 쿼리 1건이 첫 배포를 막았어요	엔진 자체보다 쿼리 패턴과 데이터 규모가 병목을 만들 수 있어요
호환성	UDF로 일부 함수를 보완했고 정수형과 문자열 정렬 차이도 처리했어요	SQL 문법만 바꾸는 작업으로 끝나지 않는다는 점을 확인할 수 있어요

1. 서버 한 대로 합치기까지 두 번의 배포가 필요했어요

lobste.rs는 웹 애플리케이션과 MariaDB를 서로 다른 VPS에서 운영했어요. SQLite로 바꾸면 데이터베이스 서버를 따로 유지할 필요가 줄어요. 운영팀은 MariaDB VPS를 종료한 뒤 VPS 비용이 기존의 절반 수준으로 내려갈 것으로 봤어요. 2019년에 시작된 데이터베이스 이전 논의도 이번 전환으로 마무리됐어요. 2

첫 실패는 읽기 트래픽에서 나왔어요

첫 배포에서는 사이트를 읽기 전용으로 열었는데도 모든 CPU가 100%에 도달했어요. 운영팀은 원인을 바로 찾지 못해 MariaDB 구성으로 되돌렸어요. 프로덕션 데이터베이스에 직접 접근할 수 없어서 실제 데이터 크기에서 나타나는 성능 문제를 미리 재현하기도 어려웠어요.

728x90

이후 실제 운영 데이터의 절반 정도 크기를 로컬에서 만드는 스크립트를 준비했어요. 데이터를 채우는 데만 약 1주가 걸렸어요. 이 환경에서 대형 테이블을 전부 훑는 쿼리 2개와 N+1 쿼리 1개를 찾아 고쳤어요. 두 번째 배포 당일에는 느린 쿼리 로그도 추가해 새 병목을 바로 추적할 수 있게 했어요.

두 번째 배포는 월요일 트래픽도 버텼어요

재배포 뒤 사이트는 정상적으로 열렸고 CPU와 메모리 사용량도 이전보다 낮아졌어요. 운영팀은 사이트 지표와 IRC 반응을 함께 보면서 발견된 문제 2건을 바로 수정했어요. 평소 접속이 늘어나는 월요일에도 서비스가 안정적으로 움직였고, 작성자는 체감 응답 속도도 빨라졌다고 설명했어요. 다만 공개 글에는 구체적인 요청량이나 응답 시간 수치가 없어 다른 서비스와 성능을 곧바로 비교하기는 어려워요.

데이터베이스별 차이는 코드에서 메웠어요

MariaDB에서 쓰던 기능이 SQLite에 모두 같은 형태로 존재하지는 않았어요. 운영팀은 SQLite gem의 사용자 정의 함수 기능을 이용해 `regexp`, `if`, `stddev`를 구현했어요. 기존 SQL을 전면 개편하는 대신 필요한 함수를 추가하는 방식을 택했어요.

자료형과 문자열 비교 방식도 손봐야 했어요. SQLite는 unsigned bigint를 지원하지 않아 일부 ID를 bigint로 바꿨어요. MariaDB의 `utf8mb4_general_ci`를 대신한 SQLite `NOCASE`는 ASCII 문자만 대소문자 구분 없이 처리해요. 다국어 검색이나 정렬이 중요한 서비스라면 이 차이를 별도로 설계해야 해요. 전문 검색 테이블에서는 기본 설정이 아닌 contentless-delete 방식을 선택했어요.

Rails 쪽에서는 기본 PRAGMA 설정이 lobste.rs의 운영 조건에 잘 맞았어요. 과거 마이그레이션 파일은 데이터베이스에 종속된 SQL을 포함하고 있어서 별도 위치로 옮겼어요. 애플리케이션 코드만 현재 SQLite 구조에 맞추고, 오래된 이력까지 억지로 호환시키지 않은 선택이에요.

왜 중요한가요

이 사례는 SQLite를 쓰면 언제나 더 빠르거나 싸진다는 결론을 주지 않아요. lobste.rs의 트래픽 형태, 쓰기 부하, 배포 구조에 맞았기 때문에 서버 한 대 중심의 구성이 가능했어요. 복제, 다중 쓰기 노드, 복잡한 권한 분리가 필요한 서비스라면 같은 선택이 맞지 않을 수 있어요. 2

더 눈여겨볼 부분은 실패 뒤의 대응이에요. 운영 규모와 비슷한 데이터를 만들고, 전체 테이블 스캔과 N+1 쿼리를 찾아낸 뒤, 느린 쿼리 로그와 롤백 절차를 갖췄어요. 데이터베이스 이전을 준비하는 팀이라면 SQL 호환성 표만 확인해서는 부족해요. 실제에 가까운 데이터 크기, 성능 측정, 데이터 무결성 확인, 배포와 복구 순서를 함께 준비해야 해요.

비용 절감도 데이터베이스 라이선스보다 운영 구조에서 나왔어요. 별도 MariaDB VPS를 없애면서 서버 수와 관리 지점이 줄었어요. 규모가 작은 웹서비스라면 현재 데이터베이스가 정말 별도 서버를 필요로 하는지, 단순한 구성이 장애 대응과 유지비를 얼마나 줄이는지 따져볼 만해요.

참고 자료

1. lobste.rs, MariaDB에서 SQLite로 전환 — GeekNews
2. lobste.rs is now running on SQLite — Lobsters