요약
- H2 DB가 생각보다 성능이 괜찮고 가볍게 쓰기엔 충분하다.
- 하지만 대규모 사용자 기반 시스템에서는 안정성, 성능이 부족하다
- 대안 DB 중에서 PostgreSQL은 잘 몰라서 사용을 못하겠고
- MySQL은 라이선스 관련해서 공개 배포시에 조금 우려되는 점이 있어
- MariaDB를 선택했습니다.
본문
1. H2 DB로 지내온 Yobi
이전 Yobi에서는 기본적으로 H2 DB를 Embedded Mode로 사용했습니다.
네트워크 연결비용없이 파일과 메모리만으로 동작하기때문에 굉장히 고속으로 동작하면서도 가벼운 것이 그 특징이었습니다.
실제 회사내에서도 2년가까이 H2 DB를 회사 전체 인원이 업무로 사용하는 Yobi 인스턴스에 적용해서 운영했습니다.
한 동안은 문제 없이 잘 지내왔습니다만 사용자가 수 천명대로 늘고 프로젝트가 그 배의 수 천 개로 늘어나는 과정에서 이런저런 문제가 발생하기 시작했습니다.
(물론 반대로 생각해보면 그 정도 규모가 아니라면 H2 DB로도 충분하다는 이야기이기도 합니다.
사실 초창기엔 Yobi 자체가 수 천명이 동시에 사용하는 시스템을 가정하고 만든 것도 아니었고요. 1~200명 이하의 조직이나 개인이 사용하는걸 목표로 했었습니다
그런데 또 다시 반대의 반대로 생각해 보면 조금만 더 신경써서 DB를 교체하고 몇 가지 옵션을 바꾸면 수 천명이 사용할 수 있는 시스템이 되니까 이왕이면 그 쪽으로... )
우선 global lock 이 걸려서 다른 SQL 파일들의 실행이 멈추는 현상이 발생하기 시작했습니다.
connection pool을 쓴다해도 결국 embedded 상태의 H2 DB의 최종 목적지인 DB file로의 접근은 single point lock 이 발생하였고 그 순간 시스템 전체의 DB 쿼리 수행이 멈칫하게 될 수 밖에 없었습니다. 워낙 고속으로 응답을 주고 받기 때문에 대개의 경우 문제가 없지만 실행시간이 오래 걸리는 트랜잭션의 경우 상태가 심각해 졌습니다. 물론 여러가지 상태를 저장/가정해 줄 수 있는 MVCC(Multiversion Concurrency Control)이 된다면 좀 나아질가 했지만 H2 DB이 MVCC 지원 버전은 그 버전대로의 문제가 심각해서 결국 버전업 관련해서도 개발팀이 큰 고통을 겪게 되었습니다.
그래서 H2 DB 의 마지막 Stable 버전이기도 하고 MVCC가 기본상태가 아닌 2014년 4월에 나온 1.3.176에 계속 머무를 수 밖에 없었습니다.
부실한 H2 DB의 관리도구
H2 DB 자체의 성능은 나쁘지 않았지만 점점 중요한 데이터들이 쌓여가기 시작하면서 백업이나 복구 등이 중요해 졌습니다만 관련해서 기능이 매우 부족하다는 것을 알게 되었습니다. 때로는 작은 DB 버전 차이에서조차도 서로 export/import가 호환되지 않거나 recover로 만들어낸 스크립트가 정상 동작하지 않는 경우도 발생했습니다.
단일 파일 기반에서의 처리로 인해 play framework 강제 정지시에 자칫 DB 파일이 깨질 수 있는 문제
Yobi는 기반으로 play 프레임워크를 사용하고 있습니다. 그리고 그 play 프레임워크가 H2 DB를 기본으로 사용하고 있고요.
그런데 간혹 Yobi의 JVM이 hang이 걸려서 강제로 JVM을 중단해야 할 때 kill로 처리가 되지 않아 강제 kill인 kill -9로 종료했을 때 DB파일이 깨지는 현상이 생겼습니다.
경우에 따라 복구에 애를 먹거나 아니면 수 시간 분의 데이터를 날리는 장애를 겪게 되었습니다.
2. 대안들
Yona(yobi)는 배포 설치형 오픈소스로 만들었기 때문에 DB선정이 조금 까따로웠습니다. 그렇다고 여러 DB를 지원할 여력도 안되고요.
PostgreSQL
우선 물망에 올랐던건 세상에서 가장 앞서있는 오픈소스 DB(the world's most advanced open source database)라고 자신을 칭하는 PostgreSQL 이었습니다.
그런데 개발팀 어느 누구도 PostgreSQL 을 써본사람이 없었고 사내에서도 관련 경험자니 팀의 지원을 받을 수가 없었습니다.
MySQL
그래서 MySQL로 사내 Yobi 인스턴스는 이전하게 되었습니다.
안전성과 성능이 대폭 향상되게 되었습니다.
MariaDB (Yona의 기본 DB)
Yona는 외부 오픈소스이고 2차 배포시에도 문제가 없도록 만든 제품이라 MySQL에 종속적인 제품을 만들어 배포하는건 라이선스에 문제가 있다는 걸 알게되었습니다.
그래서 비슷한 이유로 Fork해서 만들어진 MariaDB로 Yobi의 fork 버전인 Yona도 따라가기로 마음먹었습니다.
특히 라이선스 관련해서
- MariaDB는 라이선스 문제를 회피하기 위해 InnoDB 대신 XtraDB 를 사용하고
- 특히나 문제의 소지가 큰 MySQL Connector 대신 MariaDB Connector를 사용하기 때문에
필수 의존 DB로 MariaDB를 선택하기에 좋았습니다. (기타 MariaDB에 대해서는 wikipedia::MariaDB를 참고해 주세요.)
MariaDB는 기본 성능도 좋지만 JDBC 커넥터도 MySQL 커넥터에 비해 성능이 좋습니다.
기존보다 3배 빨라졌다고 광고하는 MySQL최신인 5.7
하지만 일반 하드웨어서의 MariaDB와서 Benchmark에서 결과는..
Yona가 기본으로 권장 사용하고 있는 MariaDB 10.1.x에 비해 5~10% 정도 성능이 낮습니다.
https://mariadb.org/maria-10-1-mysql-5-7-commodity-hardware/
3. 결론
Yona는 DB관련 문제를 최소화 하면서도 안정성과 성능을 높이며 수 천명이 함께 사용해도 문제 없는 환경을 제공하기 위해서 MariaDB를 선택했습니다.
그리고 다른 서비스나 제품을 만들때도 소스 공개 및 2차 배포를 염두에 두고 만든다면 MySQL 대신 MariaDB를 선택하게 될 것 같습니다.