데이터 스토리지 솔루션 고르기 (1)

    사이드 프로젝트를 진행할 때 프로젝트의 상황에 알맞은 데이터 스토리지 솔루션(솔루션으로 축약)을 고르는 건 매우 중요하다. 적절한 솔루션은 우리 프로젝트에서 추구하는 요건에 따라 데이터를 저장 및 관리할 수 있게 해 주고, 솔루션 자체적으로 제공하는 기능을 통해 우리 프로젝트에서 적용 중인 기술적인 측면에서 개선을 이뤄낼 수 있도록 한다. 말이 너무 추상적이니, 우리 프로젝트에서 궁극적으로 중요하게 생각하는 바를 먼저 제시하고, 그다음부터 순차적으로 우리가 솔루션으로부터 추구했던 바가 무엇이었는지까지 제시하겠다.

---

결국, 가장 중요한 것은 어떻게 유저를 만족시킬 것이냐에 있다.

 

    필자는 우리 프로젝트에서 애자일 방법론을 채택한 이래로 이와 같은 목적을 지속적으로 강조해왔다. 우리가 하는 일의 목적은 프로젝트의 목적에 기여하는 데 있고, 그 목적을 달성하기 위해 우리가 할 수 있는 최고의 수단은 그 어느 상황에서든지 유저가 바라는 바를 문제없이 제공하는 데 있다. 그렇다면 이러한 가장 높은 수준의 목적을 달성하기 위한 목표로 우리는 어느 것들을 고려해야 할까? 당연할 수도 있겠지만 빠뜨릴 수는 없는 내용이다.

 

1. 성능

    훌륭한 성능은 백엔드 개발자가 제공할 수 있는 가장 최고의 것 중 하나가 아닐까 생각한다. 예를 들어 페이지를 첫 방문할 때는 캐시 데이터가 있을리가 없기 때문에 다른 상황에 비해 로드하는 데 오래 걸릴 수밖에 없는데, 프론트엔드가 제아무리 최적화를 잘한다고 하더라도 백엔드에서 TTFB를 맞춰주지 않는다면 사용자는 금세 불만을 갖게 되어 웹페이지를 이탈할 것이다. 이런 종류의 솔루션은 프로젝트에서 사용되는 주요 외부 서비스이기도 하고 성능에 미치는 영향도 크기 때문에 성능을 고려한 솔루션 설계는 필수적이다.

 

2. 용량

   CS에서 흔히 접하는 메모리 계층 구조에서도 쉽게 접할 수 있듯, 으레 성능과 대조되면서도 마찬가지로 중요하게 고려되는 것이 솔루션이 다룰 수 있는 용량이다. 솔루션 중에서는 적은 용량을 다룰 수 있지만 매우 높은 처리량과 성능을 제공하는 솔루션도 있고, 장기적으로 데이터를 보관하는 데 특화된 솔루션도 있다. 각자의 장단점이 명확하기 때문에, 상황에 따라 적절한 솔루션을 사용해야 그 장점을 극대화하고 가용한 리소스를 효율적으로 사용할 수 있다.

 

3. 비용

   성능과 용량은 서로 다른 구조 혹은 역할을 수행하는 솔루션을 비교하기 위한 조건이라면, 비용은 그보다는 같은 범주에 속하는 솔루션을 비교하기 위한 조건이라고 할 수 있다. 유명한 솔루션은 그만큼 활용 사례도 많고 커뮤니티도 풍부하기 때문에 비교적 도움을 구하기가 쉽다는 장점이 있지만, 신입 개발자에게는 필요 없는 각종 기능으로 인해 높은 비용이 청구되는 문제점도 공존한다고 본다. 프리 티어로 충분히 사용할 수 있거나, 비용이 무시할 만큼 작거나, 플랫폼 전환이 간단해서 크게 신경을 쓰지 않아도 되는 경우가 아니라면, 미리미리 비용도 고려 대상에 넣어 두는 편이 좋을 것이다.

 

4. 익숙함

   나는 솔루션을 정할 때 팀원들이 쉽게 이해하고 사용할 수 있는지도 중요하다고 생각한다. 특히 프로젝트를 처음 시작할 때는 전 세계적으로, 또는 대한민국 기준으로 익숙하게 사용되는 기술이 우리 백엔드 팀원들에게도 익숙한 도구일 것이다. 익숙한 도구를 사용해야 프로젝트에서 필수적으로 제공해야 하는 기능을 빠르게 개발 및 배포할 수 있을 것이고, 여기서 문제가 발생했을 때 다른 솔루션을 도입하는 게 맨 처음부터 도전적인 기능을 골라서 팀원의 부담을 가중시키는 것보다 낫다고 판단했다.

 

    또한 프로젝트 초반에 만들 기능은 기술적 요구사항이 그리 높지 않을 것이기 때문에, 일반적으로 사용되는 솔루션이 특정한 요구사항(예로, RDBMS vs NoSQL)을 만족한다는 게 보장되기만 한다면 널리 채택되지 않는 솔루션까지 파고들어 분석하고 비교하는 행위는 크게 의미가 없을 것이라고 생각했다. 필자가 팀원과 할 일은 지금 당장 우리가 생각할 수 있는 수준에서 무엇이 필요한지, 그리고 그러한 조건을 일반적으로 널리 채택되는 솔루션이 만족시키는지 철저히 분석하고, 만약에 그 과정에서 문제가 식별된다면 설령 잘 쓰이지 않더라도 다른 솔루션이 있는지 탐색하여 결정하는 것 정도라고 봤다.

---

   이제 본격적으로 우리 프로젝트에서 어떤 솔루션을 채택했는지에 관해 설명할 차례인 듯하다.

 

1. 메인 DB(PostgreSQL vs MariaDB(MySQL 계열))

    우선 우리 프로젝트에서 메인 DBMS로는 RDBMS 계열을 채택하기로 했다. 현재로서는 다루는 데이터가 주로 연관관계가 설정된 정형 데이터이며, 레코드 간 무결성 및 일관성이 중요하기 때문이다. 그중에서 PostgreSQL로 고른 데는 크게 다음과 같은 세부 기준이 작용했다.

 

a. 본질적으로 ACID를 보장하는가?

    우리 팀은 어떤 상황에서든 간에 ACID를 보장하는 솔루션을 찾고 있었다. BASE를 적용해야 하는 시스템을 구축하기에는 너무 멀게 느껴졌으며, 그저 단일 시스템에서 데이터가 충돌 없이 동일한 상태로 공유되기를 희망했다. RDBMS를 도입하는 만큼 기초적인 요구사항부터 확실히 충족하고자 했다. PostgreSQL은 모든 작업에서 ACID를 보장하는 반면에 MariaDB는 적용하는 엔진에 따라 ACID 준수 여부가 달라진다. 엔진을 고정해서 사용하면 될 일일 수도 있겠지만, PostgreSQL을 사용하는 것이 ACID 보장 측면에서 더욱 신뢰할 수 있는 RDBMS라는 점은 분명해 보였다.

 

b. 어떤 RDBMS가 복잡한 쿼리에서 더욱 높은 성능을 발휘하는가? 

    우리 팀도 여느 팀들과 마찬가지로 프로젝트 초기 단계에서 DB 스키마 설계를 진행했고, 그로 인해 프로젝트에서 몇 개 정도의 테이블이 사용될지 대강 파악할 수 있었다(대강이라고 표현한 이유는, 프로젝트가 진행되면서 테이블이 늘어날 수도 있기 때문이고, 실제로 늘어났다). 이때, 필자가 보기에는 우리 프로젝트의 읽기 쿼리가 그리 단순하지만은 않을 것이라고 생각했다. 우리 프로젝트는 현재 게시글 컨텐츠 위주로 데이터를 관리하는데, 이와 관계를 맺은 테이블이(오래전이라 정확히 기억나지는 않지만) 5개 정도 있었고, 추가될 수도 있는 테이블까지 고려하면 꽤나 많은 테이블이 하나의 SQL문에 조인될 여지가 있었다.

 

    PostgreSQL은 MariaDB 대비 다수의 테이블 조인에서 더욱 강력한 성능을 보유하고 있고, 조인의 성격에 따라서도 MariaDB와 비교하여 성능상 큰 차이가 있을 수 있다. 이러한 시나리오 모두가 실제로 현실화될지 확실히 알 수 있는 건 아니었지만, 굳이 위험을 감수할 이유도 없었기에 PostgreSQL이 더욱 돋보이는 계기가 되었다.

 

c. 무엇이 확장성 측면에서 더 좋은가?

    우리 팀은 이제 막 태동하려는 참이었고, 기획이 있긴 했지만 기획자 역할을 팀장인 본인이 맡던 시기였기 때문에 변동의 위험이 컸다. 그런 점에서 필자는 RDBMS가 다른 서비스와도 가능한 한 많은 호환성을 갖추고, 가능한 많은 전문화된 기술을 보유하기를 원했다. 기능을 구현하면서 DB의 한계로 인한 제약 조건이 발목을 붙잡는 일은 없었으면 좋겠다고 여겼다.

 

    PostgreSQL은 PostGIS라고 하는 지리학적인 데이터를 다루기 위한 익스텐션을 보유하고 있으며, JSONB 자료형을 통해 MariaDB보다 훨씬 더 단순하고도 효과적인 방식으로 JSON 데이터를 바이너리 서식으로 다룰 수 있다. PostGIS는 쓸지 안 쓸지 모른다 쳐도, JSONB는 PostgreSQL을 도입하면 유용하게 사용할 수 있겠다 싶었다. 여러 장점이 있지만, 필자가 가장 마음에 드는 장점은 테이블 구조의 변경 없이 다양한 속성을 저장할 수 있다는 점(JSON 자체의 장점)과 JSONB의 특유한 쿼리 성능 및 저장 효율성 개선의 결합이다.

 

    여기에 MariaDB와 차별화되는 PostgreSQL의 또 하나의 기술인 전문 검색(Full Text Search)까지 제대로 활용할 수 있다면, 반정형 데이터(특히 JSON 형식의 데이터)를 검색할 때 PostgreSQL이 MariaDB 대비 상당히 높은 수준의 성능 차이를 낼 수 있겠다는 생각이 있었다. 비록 수치화된 데이터로 그 차이를 비교할 수는 없었지만 말이다. 우리 프로젝트는 그 특성상 쓰기가 한 번 일어나면 많은 사람들로부터 읽기가 일어나기 때문에 읽기 중심적이라고 말할 수 있고, 그로 인해 복잡할 수도 있는 쿼리를 사용하는 검색을 얼마나 효율적으로 처리할 수 있느냐가 성능에서 중요한 요소로 다뤄질 것이었다. 이 점에서도 PostgreSQL은 상대적으로 우위를 드러냈다.

---

    ... 아직 다루지 못한 비교가 최소 4가지가 더 있는데 벌써 포스팅이 꽤 길어진 듯하다. 그래서 이번 포스팅은 이쯤에서 마치고, 다음에는 시작하자마자 바로 남은 비교부터 쭉 진행해보겠다.