MongoDB

LINE+가 사내에 MongoDB를 도입한 이유

Q1. 안녕하세요 강사님, 먼저 자기소개를 부탁드립니다.

안녕하세요, 저는 LINE+에서 현재 MongoDB DBA로 일하고 있는 유호수입니다.

Q2. 지금 하고 있는 일을 설명 해 주실 수 있을까요?

제가 하는 DBA 업무를 소개드리면 LINE은 메신저 기반의 플랫폼 회사입니다. 여러 국가에서 굉장히 다양한 서비스들을 제공해주고 있기 때문에, 각각 서비스에서 사용하는 데이터베이스의 수가 굉장히 많습니다. 이때, 저희 Database실에 소속되어 있는 DBA분들이 투입되는데요. 개발자 분들께서 온전히 개발에 집중할 수 있도록 저희는 안정적으로 Database를 사용하고 최대 효율을 낼 수 있도록

▪ Database에 발생하는 장애나 이슈에 대한 관리
▪ 신규 서비스에 대한 스키마, 용량, 구성 방식 등의 컨설팅 업무
▪ 백업 및 모니터링, 쿼리 튜닝, 마이그레이션, 버전 업그레이드 등의 다양한 Database 관련 업무
▪ Database관련 개발자 문의 대응 신규 버전에 대한 검토나 신규 기능 테스트와 같은 연구 업무
▪ Database 교육

DBA 한명이 여러 Database를 관리하는 형태가 되니까 DBMS에 따라 조금씩 다르겠지만, 평균적으로 크고 작은 서비스를 20~30개 정도 맡아서 운영하고 있는 것 같습니다.

그래서 저는 MongoDB Database를 사용하는 서비스를 대상으로 이런 운영업무를 진행하고 있고 이외에도 프로젝트 형태의 개발도 진행합니다.

Q3. 현재 IT업계에서 MongoDB가 트렌드로 떠오르고 있는데 LINE+ 운영팀에서 MongoDB를 지원하게 된 배경에 대해 설명해주실 수 있을까요?

LINE은 플랫폼 회사이고 One 서비스가 아닌, 여러 종류의 서비스를 제공하고 있기 때문에 Database 종류도 다양하게 사용되고 있습니다.

그래서 “MongoDB를 도입하겠다” 라는 것은 회사차원에서 라기보다는 어떤 팀 차원에서 신규 서비스를 개발할 때 MongoDB를 사용하기로 결정하고 회사에서 해당 Database에 대한 표준 및 운영을 지원해주지 않으면 그냥 팀에서 MongoDB를 구축하고 사용하게 됩니다.

MySQL이나 Oracle 처럼 전통적인 수요가 많은 그런 Database는 표준을 제공하고 운영을 당연히 해주고 있었는데 MongoDB도 초기에는 수요가 없었기 때문에 제공해주지 않다가 개발자들로부터 수요가 많아지게되면서 Database실에서 제공되었을 겁니다.

MongoDB를 선택하는 가장 큰 이유는 3가지 정도로 정리할 수 있습니다.

▪자유로운 스키마
▪편리한 확장
▪다양한 종류의 Index

개발하는 입장에서 이 3가지가 기존에 사용하던 관계형 데이터베이스에서 할 수 없었던 것들을 할 수 있고 단점을 보완해줄 수 있는 수단으로 사용할 수 있기 때문에 너무나 강력한 도구가 됩니다. 자유로운 스키마를 서비스단의 예시로보면 이런 경우가 있을 수 있습니다. 예를 들어 아래와 같은 관계형 데이터베이스에서 회원 정보에 대한 테이블이 있습니다.

2010년대 초반까지만해도 라인, 카톡, 인스타그램이나 페이스북 등이 SNS를 회원정보나 인증 정보로 사용되지는 않았습니다.

그런데 이제는 우리가 페이스북이나 카톡을 이용해서 특정 플랫폼에 가입하는 용도로 사용되고 있습니다. 관계형 데이터베이스를 사용해왔다면 아래처럼 테이블을 변경하는 작업이 필요할 수 있습니다.

다양한 SNS를 사용하기 때문에 누구는 있고 누구는 없는 데이터에 대한 관리도 힘들어지기도 하는데 이렇게 관계형 데이터베이스에서 스키마를 바꾸는 것은 다른 데이터에 영향을 주기 때문에 생각보다 엄청 큰 작업이 됩니다.

그래서 스키마를 건드리는 작업에 여러 검증작업이 필요하고 문제가 있어 원상복구 하는 것도 부담이 될 수 있습니다. 반면 MongoDB의 자유로운 스키마를 이용하면 그냥 필드하나 추가하고 각각 Document도 다른 필드를 갖고 있을 수 있기 때문에, 기존 관계형 데이터베이스에서 겪었던 문제를 해소할 수 있습니다.

이런 자유로운 스키마의 또하나의 장점으로는 관계형 데이터베이스와는 다르게 MongoDB는 역정규화가 기본 철학이어서 데이터에 대한 가시성이 좋아집니다.

예를 들어 “Spring”이라는 사람의 정보를 확인하려고하는데 이렇게 정규화된 테이블에서 확인하려면 쿼리를 통해 조인해서 쿼리를 복잡하게 작성해야한다는 불편함이 있습니다.

반면에 MongoDB에서는 아래와 같이 한눈에 볼수 있죠. 이처럼 다양하게 스키마를 원하는대로 조정할 수 있고 JSON 형태로 제공하다보니까 API 호출 정보를 가공 없이 그대로 저장할 수 있어서 개발시간에 대한 단축도 가능하고 아키텍처링 및 비즈니스 로직도 간단해질 수 있어 많은 개발자들에게 선택받고 있습니다.

두번 째 편리한 확장은 하나의 예시를 들어보면, MySQL을 사용하다가 MongoDB로 이관하는 경우들이 좀 있습니다. MySQL은 자체적으로 제공해주는 Sharding 즉 확장에 대한 솔루션이 없습니다. 그래서 3rd-party를 사용하거나 직접 분산에 대한 로직을 구현해서 분산처리를 진행해서 여러 번거로운 작업이나 문제가 발생할 수 있어요. 예를 들어 3rd-party의 경우 MySQL의 버전이 올라갔을 때 내부적인 기능이 변경되어 해당 버전에서 사용하지 못해 업그레이드를 하지 못하는 문제가 발생할 수 있습니다.
직접 분산을 구현하게되면 확장용 노드가 추가되었을 때, 어떻게 분산시킬지 로직을 변경해서 다시 구현해야하는 번거로움이 있어요. 그래서 확장이 필요할 때마다 변경이 필요한 엄청 번거로운 작업이 발생할 수 있습니다.

반면에 MongoDB는 자체적으로 제공해주는 HA와 분산 솔루션이 있기 때문에, 버전이 올라가도 상관없고, 분산 자체에 대한 문제가 있다면 그거는 MongoDB에서 버그 fix를 통해 해결해야할 문제이고 즉, 분산에 대한 특정 의존성이 사라져서 개발에 집중할 수 있습니다.

그래서 서비스의 트래픽이나 데이터의 특성에따라 다르겠지만, 개발자들의 얘기를 들어보면 MongoDB를 도입하는 가장 큰 이유는 편리하게 분산할 수 있는 Sharded Cluster가 제공된다는 점과 자유로운 스키마가 있다는 점입니다.

Q4. 도입하고 나서 생긴 변화와 직접 느끼셨던 초기 도입시 어려웠던 부분, 도입 이후 달라진 점, 강사님이 개발자 입장에서 가장 크게 느끼는 장점에 대해 말씀 부탁드립니다.

여러 팀에서 다양하게 MongoDB를 사용하고 있고 지금도 계속 MongoDB를 처음 사용하는 팀들에서 MongoDB 구축 및 운영 요청이 들어오는데요. 공통적으로 많이 어려워하는 부분들이 있습니다.

▪MongoDB를 관계형 데이터베이스 처럼 사용하는 문제
▪자유로운 스키마로 인해 Modeling이 잘못되어 성능 저하나 remodeling이 필요한 문제
▪분산처리를 쉽게 했지만, 운영이 어렵다는 점

우선 관계형 데이터베이스에 익숙하신 분이라면 정규화하고 Join을 통해서 쿼리를 작성하거나 Transaction을 이용하는 것이 익숙한데 MongoDB를 관계형 데이터베이스처럼 사용하면 성능이 좋을 수가 없습니다. 경험상 MongoDB에서 성능 저하의 가장 큰 요인은 Join과 Transaction을 잘못 사용하고 있어서 발생하고 이것의 원초적인 문제는 MongoDB의 Modeling을 이해하지 못한 점입니다.

아무래도 스키마가 자유롭다보니까 모델링을 어떻게하느냐에 따라서 성능에 대한 차이가 매우 클 수 있습니다. 즉, MongoDB를 이해하지 못하면 MongoDB를 제대로 사용할 수 없다는 초기 도입시 주의점이 있습니다. 예를 들어 이런 경우 입니다.

자료 출처 "구글"

MongoDB에서 데이터를 내장 시킬 것인지, 참조할 것인지, 역정규화를 할 것인지, 정규화를 할 것인지 이런 고민하는 것 자체가 Modeling이라고보면 됩니다. 왼쪽처럼 내장시키는 방식으로 모델링하면 하나의 Collection만 조회해서 Read에 대한 속도가 빠르고 Document 단위로 원자성이 보장되어 데이터의 일관성을 유지시키는 방식이 쉽지만, 데이터의 중복이 발생하고 내장된 데이터의 수정이 필요하다면 모든 내장된 Document를 다 수정해야하기 때문에 Write에 대한 성능이 좋지 못할 겁니다.

반면에 오른쪽처럼 데이터를 참조하는 형태로 가면 데이터의 중복이 없고 단일 건에 대해서만 수정하면 되기 때문에 Write에 대한 속도가 빠를겁니다.

하지만, 반대로 MongoDB에서말하는 Join인 Lookup을 사용해서 여러 Collection을 읽어야하기 때문에 Read에 대한 속도가 많이 느리고 Collection이 쪼개져 있으니까 데이터의 일관성을 보장해야하는 경우 Transaction을 사용해야할 수도 있습니다. 역정규화를 기본 철학으로 갖는 MongoDB에서 이게 최악이지만, 때로는 데이터의 크기 때문에 참조형태를 선택해야하는 경우도 있습니다.

내장 시켰을 때 문제는 수정할게 많다는 것이었습니다. 그리고 참조했을 때는 Lookup을 사용 해야한다는 문제가 있습니다. 그럼 Read할 때 꼭 필요한 필드와 자주 변경이 필요 없는 필드만 내장 시키면 어떨까요?

자료 출처 "https://www.mongodb.com/"

위의 예시처럼 고객이 주문한 정보를 확인하고 싶은데 참조형태로 되어 있으면 lookup을 통해 조회를 해야하니까 차라리 이름, 국적 처럼 변하지 않은 값과 주소처럼 잘 변경되지 않고 꼭 조회가 필요한 정보만 내장 시키는 것 입니다. 그럼 주요 로직에서 사용하는 쿼리는 lookup을 사용하지 않고 Order Collection만 조회해서 Read에 대한 성능이 보장 가능하고 고객 한명이 여러번 주문했어도 주소가 변경되는 경우에만 즉,정말 드물게 여러 Document를 수정하기 때문에 Write에 대한 성능도 크게 문제가 없습니다.

이외에 만약 고객의 다른 정보를 확인해야하는 경우 , 주요 쿼리가 아닌 분석용 쿼리이거나 요청이 많지 않은 쿼리에대해서는 Join을 통해 더 많은 정보를 확인해도 성능에 큰 타격을 주지 않습니다.
이런식으로 Application의 요구사항과 성능의 균형점을 찾아가는 것이 MongoDB의 자유로운 스키마를 활용하는 Modeling 방법입니다.

Q5. LINE+ 사내에서 교육하실 때 MongoDB 사용 또는 MongoDB 학습법에 대해 가장 강조하시는 Key 포인트가 따로 있을까요 ?

MongoDB를 MongoDB답게 사용하는 것이 Key Point가 될 것 같습니다. "내가 관계형 데이터베이스는 좀 사용해봤으니까 그대로 비슷하게 사용하면 되겠지" 라는 식으로 접근하면 데이터의 양이 적을 때는 크게 문제가 없겠지만 서비스가 커지면 언젠가는 이게 발목을 잡게 될 것 입니다. 만약 처음 사용하신다면 최대한 Join과 Transaction을 사용하지 않고 처리할 수 있는 방법이 뭐가 있을까 고민해보면 도움 될 것 입니다.

또 하나 Join같은 경우는 써야하는 상황이 발생할 수 있습니다. 그래서 모델링을 어떻게할지 항상 고민하면서 MongoDB를 학습하면 크게 도움될 것 같습니다.

Q6. [백엔드 개발자를 위한 한 번에 끝내는 대용량 데이터 & 트래픽 처리]에서 MongoDB 파트를 담당해 주셨는데, 파트에 대한 소개 + 어떤 부분에 초점을 두고 준비하셨는지 말씀부탁드려요.

패스트캠퍼스에서 진행한 백엔드 개발자를 위한 한번에 끝내는 대용량 데이터 & 트래픽 MongoDB 파트는 LINE에서 진행한 MongoDB 교육의 커리큘럼을 베이스로 준비를 했습니다. 작년에 3일정도를 잡고 온라인 세미나 형식으로 LINE의 한국인 개발자들을 대상으로 교육을 실습없이 MongoDB에 대한 전반적인 내용의 강의를 진행했었는데요.

특정 기능에 대해서 Deep-Dive 한다기보다는 MongoDB를 가장 MongoDB답게 사용하고 MongoDB의 전반적인 주요 기능과 개념에 대해서 다뤘고 작년에 진행한 강의에서 처음으로 MongoDB의 Modeling을 커리큘럼에 포함했어요. 그러다 운이좋게도 패스트캠퍼스에서 MongoDB 강의를 준비할 수 있게 되었고 사내에서 진행한 MongoDB 강의와 유사한 커리큘럼으로 패스트캠퍼스에서는 간단한 실습을 포함해서 강의를 준비했습니다. 그리고 제가 알기로는 시중에서 판매되고 있는 한국어 MongoDB Modeling강의는 이번 처음인 것으로 알고 있는데요. 다른 강의들과는 이런 부분에서 큰 차이가 있지않을까 싶습니다.

Q7. 강의를 준비한 각오를 말씀해주시고, 수강생에게 학습 독려를 부탁드립니다. 실무에서 대용량 데이터 처리를 하게된 백엔드 개발자에게 조언이나 응원의 한 마디도 부탁드립니다.

한가지 확실하게 말씀드리고 싶은 것은 MongoDB는 관계형 데이터베이스의 대체재가 아닙니다. 단지, 다른 방식으로 데이터를 저장할 수 있는 수단에 불과합니다. MongoDB 뿐만아니라, Redis, Hbase, Elastic Search 등 NoSQL 종류의 Database 모두 데이터를 저장할 수 있는 새로운 수단이 생긴 것입니다.

그래서 이러한 데이터베이스가 처음 세상에 나온것은 꽤 오래됐지만, 지금은 트렌드나 흐름으로 봤을 때, 다양한 종류의 Database를 잘 이해하고 서비스의 특성과 비즈니스 로직에 따라 어떤 Database를 선정할지에 대한 인사이트를 갖고 있는 것이 좋은 개발자의 덕목 중 하나이지 않을까 싶은 개인적인 의견입니다.

“백엔드 개발자를 위한 한번에 끝내는 대용량 데이터 & 트래픽” 강의에서 다양한 종류의 데이터베이스를 다루는 것으로 알고 있는데요. Database를 선정하는 인사이트를 기르고 싶다면 추천드립니다.

지금 패캐머들이 읽고있는 BEST 아티클이 궁금하다면

미디어 전체 보러가기 👉