MongoDB 및 NoSQL 아키텍처

관계형 데이터베이스는 데이터를 테이블과 행, 열의 구조로 저장하며, 정규화를 통해 데이터 중복을 최소화하고 참조 무결성을 유지합니다. 데이터 간의 관계는 기본 키와 외래 키를 통해 정의되며, SQL이라는 강력한 표준화된 질의 언어를 사용하여 복잡한 조인과 트랜잭션을 처리합니다. 이 모델은 데이터 구조가 명확하고 일관성이 중요한 금융, ERP 시스템과 같은 환경에 적합합니다.

반면, NoSQL 데이터베이스는 고정된 스키마와 관계 모델을 따르지 않습니다. 데이터 모델은 애플리케이션의 요구사항에 따라 유연하게 설계될 수 있으며, 주로 대규모 분산 시스템과 빠른 읽기/쓰기 성능, 수평적 확장성을 위해 개발되었습니다. 관계형 데이터베이스의 ACID 트랜잭션보다는 BASE 모델[3]을 따르는 경우가 많아, 즉시 일관성보다는 가용성과 분산 내결함성을 우선시하는 경향이 있습니다.

다음 표는 두 유형의 주요 차이점을 요약합니다.

이러한 차이로 인해 관계형 데이터베이스는 구조화된 데이터와 복잡한 관계, 정확성이 핵심인 비즈니스 로직에, NoSQL은 반구조화 또는 비구조화된 대용량 데이터, 빠른 프로토타이핑, 급변하는 요구사항을 가진 웹/모바일 애플리케이션에 더 적합한 것으로 평가됩니다.

NoSQL 데이터베이스는 데이터 모델에 따라 크게 네 가지 주요 유형으로 분류된다. 각 유형은 특정한 데이터 구조와 접근 패턴에 최적화되어 있으며, 서로 다른 사용 사례에 적합하다.

첫 번째 유형은 문서형 데이터베이스이다. 이 유형은 JSON이나 XML과 같은 문서 형식으로 데이터를 저장하며, MongoDB와 CouchDB가 대표적이다. 각 문서는 필드와 값의 쌍으로 구성되며, 다른 문서와 다른 구조를 가질 수 있는 유연성이 특징이다. 이는 반정형 데이터를 처리하거나 스키마가 자주 변경되는 애플리케이션에 적합하다. 두 번째 유형은 키-값 저장소이다. 이는 가장 단순한 데이터 모델로, 고유한 키와 그에 연결된 값 하나로 데이터를 관리한다. Redis와 Amazon DynamoDB가 이에 속하며, 세션 저장, 캐싱, 프로필 정보 저장과 같이 빠른 조회가 필요한 간단한 데이터 구조에 주로 사용된다.

세 번째 유형은 컬럼형 데이터베이스 또는 와이드 컬럼 저장소이다. Apache Cassandra와 HBase가 이 범주에 포함된다. 관계형 데이터베이스의 테이블과 유사하지만, 각 행이 동일한 컬럼 집합을 가질 필요가 없으며, 대량의 데이터를 여러 서버에 분산하여 저장하고 처리하는 데 특화되어 있다. 시계열 데이터나 분석 워크로드에 적합하다. 네 번째 유형은 그래프 데이터베이스이다. 이 유형은 노드(Node), 엣지(Edge), 속성(Property)을 사용하여 데이터 간의 관계를 명시적으로 모델링하고 저장한다. Neo4j가 대표적이며, 소셜 네트워크, 추천 엔진, 사기 탐지 시스템처럼 복잡한 관계와 연결성을 분석하는 데 뛰어난 성능을 보인다.

이러한 유형들은 상호 배타적이지 않으며, 일부 데이터베이스는 여러 모델의 특징을 결합한 멀티 모델 접근 방식을 지원하기도 한다. 애플리케이션의 데이터 접근 패턴, 확장성 요구사항, 그리고 일관성 수준에 따라 적절한 NoSQL 유형을 선택하는 것이 중요하다.

MongoDB의 기본 데이터 단위는 문서(Document)이다. 문서는 JSON과 유사한 BSON 형식으로 표현되며, 필드와 값의 쌍으로 구성된다. 각 문서는 고유한 _id 필드를 가지며, 이는 문서를 식별하는 기본 키 역할을 한다. 문서는 중첩된 구조를 지원하기 때문에, 복잡한 계층적 데이터를 하나의 레코드에 자연스럽게 저장할 수 있다. 예를 들어, 한 사용자 문서 내에 주소 배열이나 연락처 객체를 직접 포함시킬 수 있다.

문서들이 논리적으로 그룹화된 저장소를 컬렉션(Collection)이라고 한다. 관계형 데이터베이스의 테이블과 유사한 개념이지만, 컬렉션은 고정된 스키마를 강제하지 않는다는 점에서 근본적으로 다르다. 동일한 컬렉션 내의 문서들이 서로 다른 구조를 가질 수 있다. 이 유연성은 애플리케이션 요구사항이 빠르게 변하거나 데이터 형태가 다양할 때 큰 장점이 된다.

문서와 컬렉션의 관계는 다음과 같이 정리할 수 있다.

이러한 구조는 개발 생산성을 높이는 반면, 데이터 무결성을 애플리케이션 계층에서 더 많이 관리해야 할 수 있다. 따라서 컬렉션 설계 시, 문서의 논리적 관계와 함께 쿼리 패턴 및 성능 요구사항을 함께 고려하는 것이 중요하다.

BSON은 Binary JSON의 약자로, MongoDB가 데이터를 저장하고 네트워크를 통해 전송할 때 사용하는 이진 인코딩 형식이다. JSON과 유사한 구조를 가지지만, 이진 형식으로 인해 더 효율적인 공간 활용과 빠른 파싱 속도를 제공한다. BSON은 날짜(Date), 이진 데이터(BinData), ObjectId와 같은 JSON에는 없는 추가 데이터 타입을 지원하여 데이터 표현력을 확장한다. 이 형식은 문서를 데이터베이스에 저장하거나 쿼리 결과를 반환할 때 내부적으로 사용된다.

MongoDB의 스키마 디자인은 관계형 데이터베이스의 정규화된 테이블 설계와는 근본적으로 다른 접근법을 따른다. 핵심 원칙은 애플리케이션의 데이터 접근 패턴에 맞춰 문서를 설계하는 것이다. 이는 관련된 데이터를 하나의 문서 내에 중첩된 서브도큐먼트나 배열 형태로 모델링하는 임베디드 데이터 모델을 권장한다. 예를 들어, 사용자 정보와 그 사용자의 주문 내역을 별도의 컬렉션이 아닌 하나의 사용자 문서에 포함시킬 수 있다. 이 방식은 읽기 성능을 극대화하고 조인 연산의 필요성을 줄인다.

반면, 데이터 중복이 발생하거나 관계가 매우 복잡한 경우에는 문서 간 참조 데이터 모델을 사용한다. 이는 관계형 데이터베이스의 외래 키 개념과 유사하게, 한 문서가 다른 문서의 ObjectId를 저장하는 방식이다. 적절한 스키마 디자인을 위해서는 애플리케이션이 수행하는 읽기와 쓰기 연산의 비율, 쿼리 패턴, 데이터 일관성 요구사항 등을 종합적으로 고려해야 한다.

효과적인 스키마 설계는 쿼리 성능, 저장소 효율성, 애플리케이션 개발 편의성에 직접적인 영향을 미친다. 따라서 초기 설계 단계에서 데이터의 성장과 접근 방식을 예측하는 것이 중요하다.

샤딩은 MongoDB가 대규모 데이터셋과 높은 처리량 요구사항을 처리하기 위해 채택하는 핵심적인 수평 확장 전략이다. 이는 단일 서버의 물리적 한계를 극복하기 위해 데이터를 여러 서버(샤드)에 분할하여 저장하고 운영하는 방식이다. 샤딩 클러스터는 주로 샤드 서버, 설정 서버, 라우터 서버라는 세 가지 구성 요소로 이루어진다. 각 샤드는 데이터의 일부를 담당하며, 설정 서버는 클러스터의 메타데이터를 저장하고, 라우터(mongos)는 애플리케이션의 쿼리를 받아 적절한 샤드로 라우팅하는 역할을 한다.

데이터 분할의 기준이 되는 샤드 키를 선택하는 것은 샤딩 설계에서 가장 중요한 결정 중 하나이다. 샤드 키는 문서가 클러스터 내의 특정 샤드에 할당되는 방식을 결정한다. 샤드 키 선택은 데이터 분포의 균형성(샤드 간 부하 분산)과 쿼리 효율성에 직접적인 영향을 미친다. 부적절한 샤드 키는 특정 샤드에 데이터와 트래픽이 집중되는 핫스팟 현상을 초래하거나, 쿼리 성능을 저하시킬 수 있다.

MongoDB는 샤드 키를 기반으로 데이터를 분산시키는 두 가지 주요 샤딩 전략을 제공한다.

샤딩을 구현하면 시스템의 전체 저장 용량과 읽기/쓰기 처리량을 선형적으로 증가시킬 수 있다. 그러나 이는 운영 복잡성을 증가시키며, 조정된 쿼리나 다중 샤드 트랜잭션과 같은 작업은 단일 서버 환경보다 더 많은 주의를 요구한다.

레플리카 셋은 동일한 데이터 셋을 복제하여 유지하는 MongoDB 서버들의 그룹이다. 하나의 서버가 프라이머리(Primary) 노드로 선출되어 모든 쓰기 연산을 처리하고, 나머지 서버들은 세컨더리(Secondary) 노드로 읽기 연산과 데이터 복제를 담당한다. 이 구조는 자동 장애 조치(Failover)를 통해 고가용성을 제공하는 핵심 메커니즘이다. 프라이머리 노드에 장애가 발생하면 나머지 노드들이 새로운 프라이머리를 선출하는 선거 과정을 자동으로 수행하여 서비스 중단 시간을 최소화한다.

레플리카 셋의 구성은 일반적으로 홀수 개의 멤버(예: 3개 또는 5개)로 이루어지며, 데이터 안정성을 위해 다양한 유형의 노드를 포함할 수 있다. 예를 들어, 아비터(Arbiter) 노드는 선거에만 참여하고 데이터를 저장하지 않는 특수 멤버로, 짝수 개의 데이터 노드가 있을 때 투표권을 제공하여 장애 조치 결정을 돕는다. 또한, 히든(Hidden) 노드나 지연된(Delayed) 노드는 백업, 보고, 또는 특정 시간 전의 데이터 스냅샷을 유지하는 용도로 구성된다.

데이터 복제는 프라이머리 노드의 오플로그(Oplog, operation log)를 기반으로 한다. 모든 쓰기 작업은 오플로그에 순서대로 기록되며, 세컨더리 노드는 이 로그를 비동기적으로 적용하여 자신의 데이터 셋을 최신 상태로 유지한다. 이 복제 방식은 결과적 일관성(Eventual Consistency) 모델을 따르지만, 읽기 작업 시 쓰기 고려(Write Concern)와 읽기 선호도(Read Preference) 설정을 조정하여 강한 일관성이 필요한 경우에도 대응할 수 있다.

MongoDB Query Language는 MongoDB에서 데이터를 조회, 삽입, 갱신, 삭제하기 위해 사용하는 질의 언어이다. SQL과 달리 절차적이지 않으며, JSON과 유사한 형태의 객체를 사용하여 쿼리 조건과 작업을 정의한다. 이는 개발자가 애플리케이션 코드에서 사용하는 데이터 구조와 매우 유사하여 직관적으로 사용할 수 있다는 장점을 가진다.

MQL의 기본적인 쿼리 연산은 db.collection.find() 메서드를 통해 이루어진다. 이 메서드는 필터 객체를 인자로 받아 조건에 맞는 문서를 커서 형태로 반환한다. 예를 들어, db.users.find({ age: { $gt: 25 }, status: "active" })는 age 필드가 25보다 크고 status 필드가 "active"인 모든 사용자 문서를 찾는다. 갱신 작업은 db.collection.updateOne() 또는 db.collection.updateMany()를, 삭제 작업은 db.collection.deleteOne() 또는 db.collection.deleteMany()를 사용한다.

MQL은 다양한 쿼리 연산자를 제공하여 복잡한 질의를 구성할 수 있다. 주요 연산자 카테고리는 다음과 같다.

또한, find() 메서드와 함께 사용하는 프로젝션을 통해 반환되는 문서의 필드를 제한하거나, sort(), limit(), skip() 메서드로 결과의 정렬과 페이징을 처리할 수 있다. 집계 파이프라인은 db.collection.aggregate()를 사용하여 $match, $group, $sort, $project 같은 여러 단계를 거치는 복잡한 데이터 변환과 분석을 가능하게 한다.

MongoDB는 다양한 유형의 인덱스를 지원하여 쿼리 성능을 최적화한다. 가장 기본적인 형태는 단일 필드 인덱스로, 하나의 필드에 대해 생성된다. 복합 인덱스는 여러 필드를 조합하여 생성되며, 필드의 순서가 쿼리 성능에 중요한 영향을 미친다. 다중 키 인덱스는 배열 필드의 각 요소에 대해 인덱스를 생성할 때 사용된다. 또한, 공간 데이터를 효율적으로 검색하기 위한 2dsphere 인덱스와 전문 검색을 지원하는 텍스트 인덱스, 특정 데이터만 인덱싱하는 희소 인덱스 등 특수 목적의 인덱스도 존재한다.

성능 최적화를 위해서는 쿼리 패턴을 분석하여 적절한 인덱스를 설계하는 것이 핵심이다. 실행 계획을 확인하여 인덱스가 효율적으로 사용되는지 평가할 수 있다. 인덱스는 읽기 성능을 향상시키지만, 쓰기 작업 시에는 인덱스를 갱신하는 오버헤드가 발생하므로 과도한 인덱스 생성은 성능 저하를 초래할 수 있다. 따라서 자주 사용되는 쿼리 필드와 정렬 필드를 우선적으로 인덱싱하고, 필요하지 않은 인덱스는 주기적으로 정리하는 것이 좋다.

인덱스 설계 시 고려해야 할 주요 요소는 다음과 같다.

마지막으로, 인덱스는 생성 후에도 관리가 필요하다. 인덱스 조각화가 발생하면 성능이 점진적으로 저하될 수 있으므로 주기적인 모니터링과 재구성이 권장된다[6]. 또한, 복제본 세트의 보조 멤버에서 인덱스를 빌드하면 프라이머리의 운영 부하를 줄일 수 있다.

초기 MongoDB는 단일 문서 수준의 원자성만 보장하며 전통적인 ACID 트랜잭션을 완전히 지원하지 않았다. 이는 NoSQL 데이터베이스가 높은 확장성과 성능을 위해 일관성 모델을 완화하는 경향과 맞닿아 있었다. 그러나 버전 4.0부터 MongoDB는 복제본 셋 내에서의 다중 문서 트랜잭션을 도입했고, 버전 4.2에서는 샤딩 클러스터 환경에서의 분산 트랜잭션을 지원하게 되었다[7].

현재 MongoDB는 다음과 같은 ACID 속성을 지원한다.

이러한 지원에도 불구하고, 다중 문서 트랜잭션의 사용은 성능 오버헤드를 수반하므로 신중하게 적용해야 한다. 트랜잭션의 지속 시간은 짧게 유지하고, 가능하면 스키마를 적절히 설계하여 단일 문서 내에서 작업을 완결하는 것이 권장된다. MongoDB의 접근 방식은 관계형 데이터베이스의 엄격한 트랜잭션 모델과 NoSQL의 유연성 및 확장성 요구 사이의 균형을 찾는 것으로 볼 수 있다.

분산 트랜잭션 관리는 여러 샤드에 걸쳐 저장된 데이터의 원자성(Atomicity)을 보장하는 메커니즘을 의미한다. MongoDB는 버전 4.0부터 단일 레플리카 셋 내에서의 다중 문서 트랜잭션을 지원하기 시작했으며, 버전 4.2부터는 샤드 클러스터 환경에서의 분산 다중 문서 트랜잭션을 공식 지원한다. 이는 여러 샤드에 분산된 문서들을 하나의 트랜잭션 단위로 묶어 ACID 속성을 준수하며 처리할 수 있게 한다.

분산 트랜잭션의 내부 동작은 2단계 커밋(Two-Phase Commit) 프로토콜을 기반으로 한다. 트랜잭션을 시작한 몽고스(mongos) 라우터는 조정자(coordinator) 역할을 하며, 관련된 모든 샤드에 트랜잭션 명령을 전파하고 최종 커밋 또는 중단(abort)을 결정한다. 이 과정은 다음과 같은 단계를 거친다.

이러한 분산 트랜잭션은 개발자에게 강력한 데이터 일관성 보장을 제공하지만, 성능과 가용성에 대한 비용이 따른다. 트랜잭션의 지속 시간이 길어질수록 관련 데이터에 대한 잠금이 유지되며, 이는 시스템의 동시성(concurrency)을 저하시킬 수 있다. 또한 네트워크 지연이나 노드 장애가 발생할 경우 트랜잭션 처리 시간이 증가하거나 복잡한 장애 복구 절차가 필요해진다. 따라서 설계 시에는 트랜잭션의 범위를 최소화하고, 스키마 디자인 단계에서 가능한 한 관련 데이터를 동일한 샤드에 배치하는 전략을 고려하는 것이 성능에 유리하다[8].

MongoDB의 백업 전략은 데이터의 중요성, 시스템 규모, 복구 시간 목표에 따라 달라진다. 가장 기본적인 방법은 mongodump와 mongorestore 명령줄 도구를 사용하는 것이다. mongodump는 데이터베이스나 컬렉션 단위로 BSON 형식의 바이너리 덤프를 생성하며, mongorestore는 이 덤프 파일로부터 데이터를 복구한다. 이 방법은 간단하지만, 백업 수행 중인 데이터베이스에 부하를 줄 수 있으며, 대용량 데이터셋에서는 완료 시간이 길어질 수 있다.

보다 안정적인 운영을 위해서는 파일 시스템 스냅샷을 활용하는 방법이 권장된다. 레플리카 셋의 보조 멤버에서 LVM[9], EBS[10] 스냅샷 또는 클라우드 공급자의 스냅샷 기능을 이용해 데이터 파일이 위치한 볼륨의 일관된 스냅샷을 생성한다. 이 방법은 데이터베이스를 잠그지 않고 빠르게 백업을 수행할 수 있으며, 특히 대규모 배포 환경에서 효율적이다. 스냅샷 생성 시점의 oplog(운영 로그)를 함께 보관하면, 특정 시점으로의 정확한 복구가 가능해진다.

복구 전략은 장애 시나리오에 따라 다르게 수립된다. 단일 문서나 컬렉션의 손실에는 mongorestore를 사용해 특정 컬렉션만 복원할 수 있다. 전체 노드 장애 시에는 레플리카 셋의 자동 복구 메커니즘에 의존하거나, 백업된 멤버를 새로운 노드로 교체한다. 가장 심각한 데이터 센터 장애와 같은 재해 복구 시나리오에는 지리적으로 분산된 백업 스냅샷이나 보조 데이터 센터의 레플리카 셋을 활용한다. 정기적인 복구 훈련을 통해 백업의 무결성과 복구 절차의 신뢰성을 검증하는 것이 필수적이다.

MongoDB의 성능과 상태를 지속적으로 관찰하고 문제를 사전에 감지하기 위해 다양한 모니터링 도구를 사용할 수 있다. MongoDB는 자체적으로 제공하는 무료 도구와 상용 솔루션, 그리고 타사 모니터링 플랫폼과의 통합을 지원한다.

주요 모니터링 도구는 다음과 같다.

이 외에도 널리 사용되는 APM(Application Performance Management) 및 인프라 모니터링 플랫폼과의 통합이 일반적이다. 예를 들어, Datadog, New Relic, Prometheus와 Grafana 조합은 지표 수집, 대시보드 시각화, 경고 발송을 위한 강력한 오픈소스 스택을 구성한다. Prometheus는 MongoDB Exporter를 통해 메트릭을 수집하고, Grafana에서 이를 사용자 정의 대시보드로 표현한다. 모니터링의 핵심 지표에는 QPS(초당 쿼리 수), 연결 수, 복제 지연 시간, CPU/메모리/디스크 사용률, 인덱스 히트율 등이 포함된다.