MongoDB를 이제는 사용해도 되는 이유

몽고 DB에 대한 기존 인식

몽고는 이미 굉장히 유명한 데이터베이스 중 하나이다.

Redis와 더불어 NoSQL의 선두주자 같은 느낌으로, 들었을 때 모르는 사람은 별로 없을 것이다.

또한 Node.js 가이드들의 경우 간단하게 다룰 수 있어서인지 mongoose를 사용해서 express를 가르치는 경우도 많이 보았다.

 

하지만 Redis의 경우에는 이미 실무에서 널리 사용되고 있는 보편적인 기술이 되었지만,

몽고는 실제로 그러한가라고 물어보았을 때 아직 많지는 않은 것 같다.

혹여나 도입을 했다고 하더라도 서비스의 메인 데이터베이스로 사용하고 있는 사례가 많지는 않다.

 

물론 제대로 써본 적이 없다는 것이 몽고 DB에 대한 가장 큰 벽이었던 것 같다.

"로그 수집이나 관계가 중요하지 않은 데이터에 선택적으로 저장하기에 나쁘지 않을까?"

정도의 생각만 가지고 있었다.

 

Document 데이터베이스라서 스키마 구성이 자유롭다는 장점 등도 이미 알고는 있었지만,

직접 사용해보지 못했기에 공감되는 내용도 아니기도 했다.

 

나도 그렇고 보통은 아마 다음의 케이스 때문에 몽고 도입을 주저할 것이다.

 

1. 몽고를 잘 모른다: 새로운 데이터베이스 사용에 대한 러닝커브, 개발에 대한 노하우가 없음 

2. 어차피 RDB로도 크게 문제는 없다: 굳이 몽고로 넘어가야할 유스케이스가 굳이 없음

3. DBA가 없다: 없으면 결국 어느 정도는 스스로 운영도 책임을 져야 함

4. 기술이 아직 사용하기에 성숙하지 않다고 들었다: 실제로 오래되지는 않았음

 

하지만 그럼에도 요새 점점 몽고를 도입하고 있다는 소식이 여기저기에서 들려오고 있다. 

 

- flo의 도입기: https://www.blog-dreamus.com/post/flo-tech-mongodb-%EB%8F%84%EC%9E%85%EA%B8%B0
- 라인의 도입기: https://www.bloter.net/newsView/blt201910010009

 

위의 글들을 읽어보니 슬슬 도입이 가능한 수준인 것 같기는 하다.

 

하지만 결국은 구체적으로 어떤 점들 때문에 사용이 가능한지를 알아보는 건 스스로 알아봐야만 했다.

 

그래서 참고도서와 각종 자료들을 서칭하면서

이게 도대체 어느정도까지 커버를 할 수 있는지,

RDB를 대체할 수 있는 메인 데이터베이스로의 충분한 역량을 제공하는지,

안정성과 성능에 문제는 없는지 등을 확인하고자 했다.

 

---

MongoDB의 현재

몽고는 최근 가장 빠른 발전을 이룬 데이터베이스 중 하나일 것이다. 

공식 문서에서 최근 몇 년 간의 몽고의 업데이트들을 확인할 수 있었는데 엄청난 속도로 업데이트 되고 있다는 것이 체감이 된다.

https://www.mongodb.com/evolved

MongoDB Evolved – Version History

https://www.mongodb.com/collateral/mongodb-evolved-becoming-the-worlds-most-wanted-database 에서 제공하고 있는 문서 중

 

위의 도식은 Mongo에서 제공하고 있는 대표적 릴리즈 내용들을 정리한 것이다.

최근 학습할 때 사용한 Real MongoDB는 3.4 버전으로 작성된 책인데,

나름 최신 책을 샀는데 그 이후에 업데이트 된 내용들이 너무 많다.

공식 홈페이지의 릴리즈는 벌써 6.0 을 바라보고 있다.

(이 때문에 5년 된 책인데도 벌써 옛날 책이 된 느낌이라 공부할 때 공식문서를 끼고 해야만 했다)

 

몽고는 원래 처음에는 분산처리에 특화된 도큐먼트 데이터베이스였다.

애초에 트랜잭션/조인 등에 대한 지원은 별로 없어서 RDB와는 완전히 다른 길을 가는 듯한 데이터베이스였다.

실제로 내부 스토리지 엔진인 MMAP는 다양한 기능을 제공하는 데에는 어려움이 있었다.

 

그러나 WiredTiger 라는 데이터베이스 엔진을 도입하면서 많은 것이 달라졌다.

클러스터링과 샤딩이라는 장점은 유지하면서 주류 RDB의 다양한 기능들을 점점 가져오기 시작했다.

많은 기업들이 몽고를 사용하고 그에 따른 투자를 받으면서 빠른 시일 내에 발전을 이룬 것으로 보인다.

 

위의 표를 보면 알겠지만, 이전에는 제약이 많았던

동시성, 트랜잭션, 조인, 인덱스 등 다양한 제한사항들이 빠르게 사라지고 있다.

자세한 업데이트 내용은 생략하고 요약하자면 RDB에서 되는 것은 몽고에서도 거의 다 된다고 보면 되는 수준이다.

 

이제 더 이상 몽고에 대해서

"뭐가 안 돼서 사용할 수 없다. 뭐가 안 돼서 시기상조다" 

라는 말은 필요 없는 시대가 되어가고 있다.

단지 Document NoSQL이라는 특징과 비교를 해보고, 데이터 구조의 측면에만 집중하면 된다. 

 

심플하게,

무결성과 관계성이 중요하다면 RDB를 선택하고,

자유로운 스키마가 중요하다면 Mongo를 선택하면 되는 시대가 점점 오고 있다.

 

---

MongoDB Atlas

몽고를 사용해도 될 만한 이유가 하나 더 존재하는데, 그건 몽고에서 제공하는 관리형 서비스인 Atlas 이다.

 

https://www.mongodb.com/atlas

MongoDB Atlas | Multi-cloud Application Data Platform

클라우드 기술이 발전하면서 DataBase As A Service(DBaaS) 의 존재도 등장하게 되었는데,

Atlas도 그 중 하나라고 볼 수 있다.

AWS의 Aurora나 Dynamo 같은 것이라고 보면 될 것 같다.

 

아무래도 기업에서는 오픈소스만 사용하기에는 부담이 될 수도 있는데,

그런 어려움을 어느 정도 서포트해주고 책임져주는 것만으로도 기업 입장에서는도움이 된다.

그래서 클라우드의 매니지드 데이터베이스를 쓰는 것이기도 하고.

 

Atlas를 사용하면 애초에 많은 부분을 신경쓰지 않게 해주며,

AWS, GCP 같은 Public Cloud들과의 연동도 어렵지 않게 할 수 있다.

게다가 글로벌 리전의 개념도 제공하여 레이턴시도 줄일 수 있어서 유용해 보인다.

 

실제로 많은 기업들이 Atlas를 사용하고 있고 기업차원에서 매니징이나 컨설팅을 받을 수 있다고 들어서,

처음 사용하는 팀도 그나마 적은 부담으로 도입할 수 있다는 생각이 든다. 

 

이외에도 데이터라는 리소스를 이용해서 할 수 있는 여러가지 서비스를 제공하고 있는데,

써보지는 않았지만 그 중에서 좀 괜찮아 보이는 건 Atlas Search라는 상품이다.

이건 루씬 엔진을 이용하여 ElasticSearch 처럼 검색엔진을 제공해주는 서비스이다.

검색을 위해서 ElasticSearch를 하나 더 띄우는 부담을 덜어준다는 점에서는 유용해보인다.

 

다만 Mongo의 각종 솔루션들은 아직 유스케이스가 적어서(아직 한국어로 된 블로그나 문서가 없다)

우리나라에서 이것들을 도입한다면 거의 베타테스터 수준일 것 같다는 생각이 들긴 한다.

아마 몽고 코리아에서는 좋아하지 않을까?

 

다양한 서비스들과 발전 속도를 보면 매니지드 데이터베이스로서의 몽고의 앞으로의 발전이 더 기대가 되기는 한다.

 

뭔가 너무 칭찬만 하니 몽고를 사용하라고 홍보해 주는 사람 같은데,

사실 아직 프로덕션 적용 단계까지는 좀 시간이 남아서 직접 사용을 해봐야 알 것 같다.

애초에 이런 고민에 대한 해답 자체가 국내 구글링 결과에는 별로 없기 때문이다.

그렇다고 공식문서의 설명만 참고하기에는 장사 때문인지 너무 약파는게 느껴지긴 하더라...

 

---

어떤 몽고 DB 문서를 읽다보니 이런 문구가 있었다.

There are some who describe MongoDB (and “NoSQL” databases generally) as “schemaless”.
Of course this isn’t true, ... .
What MongoDB does have is a flexible schema.

 

몽고가 이젠 자신들을 스키마리스라고 하는 것 까지도 부정하고 있다.(근데 다른 문서에선 Schemaless라고 설명하던데? ㅋㅋ)

하고 싶은 이야기는 스키마 주도로 이루어지는 데이터베이스가 아닌,

유저의 어플리케이션에서 작성한 스키마가 유연하게 반영되는 데이터베이스라는 의미라고 하는 것 같다.

 

실제로 RDB와는 다르게 DDL을 매번 호출하지 않는 것은 개발 단계에서 굉장히 편했다.

그리고 무결성 체크를 하지 않는 것에서 또 한 번 귀찮은 처리를 해주지 않아도 되어서 편했다. 

물론 이 편리함이 추후 프로덕션에서는 불안함으로 다가오겠지만,

그런 점들은 몽고를 도입하고자 할 때 고민해야 하는 포인트라고 생각한다.

 

또한 실제 설계를 보면서 느낀 점은 몽고를 쓰든 MySQL을 쓰든,

대규모 데이터를 저장하려면 모델링에 공을 들여야 한다는 것이다.

몽고를 쓴다고 RDB에 존재하던 문제가 해결되는 경우가 그렇게 많지는 않았다.

 

그래서 느낀 점은 '아 데이터베이스는 다 똑같구나...' 라는 점이었는데,

데이터베이스의 보편적인 구조(쿼리 파싱, 프로세싱, 인덱싱, 메모리, 운영체제, 저장소, 분산처리 등)를 알아야

더 데이터베이스를 스마트하게 사용할 수 있겠다는 점이었다.

 

MongoDB의 내부 아키텍처

각 데이터베이스의 기능에 대해서 학습하는 것도 중요하지만,

어떤 아키텍처를 가지고 있는지, 어떤 프로세싱 과정을 거치는지 등을 비교할 수 있어야 더 스마트하게 사용할 수 있다.

 

결론적으로 말하고 싶은 것은 몽고는 이제 더 이상 실무에서 사용하기에 불안하지 않은 데이터베이스라는 것이다.

스터디를 해보니일단 이론적으로는 괜찮은 정도라고 판단도 되었다.

몽고는 안정성, 성능 둘 다 이젠 크게 하자가 없는 수준의 괜찮은 데이터베이스가 되었다. 

 

하지만 몽고를 제대로 사용하려면 이런 내부 구조에 대해서는 한번 학습해봐야 한다.

나는 'Real MongoDB' 라는 책으로 학습하긴 했는데 버전이 3.x 에 쓰여진 책이라 추천은 좀 애매하다.

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9791158390921&orderClick=LAG&Kc=

 

그렇지만 내부 구조가 잘 정리되어 있어서 개인적으로는 많은 도움이 되었다.