[개인 프로젝트]

개인 프로젝트라고 하기엔 다소 애매하지만, 겨울방학 인턴을 하면서 필요한 DB를 조사하던 중, 마침 ACC 활동하면서 부족하다고 느꼈던 AWS 서비스 중 NoSQL 분야를 함께 공부해 정리해두면 좋을 것 같아서 티스토리 블로그에 기록하려고 한다. 이번 글은 ACC에서 발표를 관련 발표를 진행하신 분 자료를 많이 참고할 예정이다.

1. AWS 클라우드 데이터베이스

AWS에서 제공하는 데이터베이스 종류는 다음과 같이 크게 3가지로 나뉠 수 있다.

RDS/AuroraDB: 관계형 데이터베이스
DocumentDB/DynamoDB: NoSQL
Redis/Memcached: 인 메모리 데이터베이스

내가 발표를 진행했던 RDS/AuroraDB 제외하고 지금과 다음 글에서는 아래 두 개에 대해서 정리해 볼 예정이다. 본격적으로 DocumentDB와 DynamoDB에 대해서 정리하기 전에, 세 종류의 데이터베이스를 더 세분화해서 표로 정리해보면 다음과 같다.

데이터베이스 종류	설명	활용 예시	AWS	On-premis
관계형 데이터베이스	미리 정의된 스키마로 데이터를 저장하는 데이터베이스	대학교 내 학생 관리 시스템, 전자상 거래	Aurora, RDS	MySQL, PostgreSQL
Key-Value	단순한 키-값 쌍 형태로 저장하는 데이터베이스	전자상 거래, 토큰 관리	DynamoDB	Redis
인 메모리	데이터를 메모리에 직접 저장하는 데이터베이스	캐싱, 세션 관리	ElastiCache, MemoryDB	Redis, Memcached
문서	JSON 형태 문서를 저장하는 데이터베이스	콘텐츠 관리, 프로필 관리	DocumentDB	MongoDB
그래프	노드 간 관계를 기반으로하는 데이터베이스	연관 검색 결과 추천, 소셜, 사기 탐지	Neptune	Neo4j
와이드 컬럼	행마다 다른 열 구조를 가지는 데이터베이스	대규모 IoT 센서 데이터	KeySpaces	Apache, Cassandra
시계열	시간 흐름에 따라 변화하는 데이터를 저장하는 데이터베이스	IoT, 모니터링	Timestream	InfluxDB

위 표는 데이터베이스 종류별로 데이터베이스의 특징, 활용 예시, AWS 제공하는 서비스, 그리고 On-premis, 즉 로컬 환경에서 사용하는 대표적인 데이터베이스를 기준으로 정리한 것이다.

+) 여기서 관심있는 것들이라 하면 와이드 컬럼과 시계열 데이터베이스? 그리고 인 메모리 데이터 베이스 등이 조금 궁금하다. 특히 네트워크 관점에서실시간으로 급변하는 트래픽 데이터를저장할 때는 어떤 데이터베이스를 활용하는 거이 적절한지, 시계열 데이터베이스를 활용하는지에 대해서 조금 더 조사해 볼 필요가 있다고 생각한다. 아마 Redis/Memcached에 대해서 정리하고 추가적으로 조사할 것 같다.

2. NoSQL

2.1. NoSQL 개요

먼저, 기초데이터베이스 시간에 간단히 배웠지만, 관계형 데이터베이스 위주로 학습하다 보니 NoSQL에 대해서는 제대로 정리하지 못하고 넘어간 부분이 있다. 이번 기회에 개념부터 다시 정리하려고 한다.

NoSQL은 SQL이 아니다(=No SQL)라고 오해되지만, 실제로는 Not Only SQL의 줄임말이다. 즉, SQL을 배제한다는 의미가 아니라 SQL과 NoSQL을 모두 포함하는 비관계형 데이터베이스를 의미한다.

그렇지만, 일반적으로 NoSQL은 비관계형 데이터베이스를 의미한다. 즉, 기존의 관계형 데이터베이스에서 벗어나 대규모 데이터 처리와 유연성을 제공하는 새로운 데이터 저장 방식을 의미한다.

2.2. NoSQL 등장 배경

그럼 이 NoSQL이 등장한 이유는 무엇일까? 기존의 관계형 데이터베이스로는 무엇이 부족하여 새로운 개념이 등장했을까?

2000년대 후반, 관계형 데이터베이스 발전으로 인해 저장 비용은 과거에 비해 크게 감소했고, 동시에 SNS와 모바일 애플리케이션이 급격히 성장했다.

이로 인해 사용자의 읽기, 쓰기 요청 빈도와 동시 접속자 수가 증가했으며, SNS와 모바일 앱의 특성상 잦은 요구사항 변경으로 데이터 구조 역시 자주 변경되었다. 이 과정에서 존 SQL 기반 스키마를 지속적으로 수정해야 하는 문제가 발생했다.

한편, 분산 시스템 기술과 클라우드 인프라가 함께 발전하면서 수평 확장이 가능해졌고, 이러한 흐름 속에서 기존 관계형 데이터베이스의 구조적 한계를 보완하기 위한 대안으로 스키마에 유연하고 대규모 분산 처리가 가능한 NoSQL이라는 개념이 등장하게 되었다.

2.3 NoSQL 주요 유형

NoSQL의 주요 유형은 다음과 같이 4가지로 나눌 수 있다.

Key-Value
문서
와이드 컬럼
그래프

이 중, 1, 2번에 대해서 정리해 보려고한다.

2.3.1 Key-Value

Key-Value 데이터베이스는 키(Key)와 값(Value)으로 이루어진, 저장과 조회라는 가장 간단한 원칙에 충실한 데이터베이스이다. 테이블 간 조인을 고려하지않기 때문에 관계형 데이터베이스에서 사용하는 외래 키나 제약 조건 등이 필요하지 않다는 장점이 있다.

또한 스키마가 정해져 있지 않기 때문에 값에 모든 데이터 타입을 허용한다. 그만큼 개발자가 데이터 입력 단계에서 검증 로직을 제대로 구현하는 것이 중요하다.

Key-Value 데이터베이스는 Boolean이나 Integer와 같은 단순한 스칼라 값뿐만 아니라 List나 JSON같은 구조화된 값도 저장할 수 있다.

Key-Value 데이터베이스는 대표적으로 Redis와 AWS DynamoDB 등이 있으며, 주로 다음과 같이 사용된다.

성능 향상을 위한 관계형 데이터베이스에서 데이터 캐싱
장바구니와 같은 웹 애플리케이션에서 일시적인 상태 정보 저장
모바일 애플리케이션용 사용자 데이터 정보 및 설정 정보 저장
이미지나 오디오 파일 같은 대용량 객체 저장

2.3.2 Document

Document DB는 Key-Valye DB와 동일하게 데이터 저장에 Key-Value 타입을 사용한다. 중요한 차이점은 Key-Value DB는 주로 Boolean이나 Integer와 같은 단순한 값을 저장하는 반면, Document DB는 VAlue에 문서 형태의 데이터를 저장한다는 점이다. 이 문서는 보통 JSON이나 XML과 같은 형식을 사용한다.

이러한 특성 때문에 데이터를 저장하기 전에 별도의 스키마를 정의하지 않아도 되며, 추가된 문서 자체가 스키마 역할을 하게 된다. 각 문서마다 서로 다른 필드를 가질 수 있기 때문에, Key-Value DB와 마찬가지로 애플리케이션 단에서 데이터 관리가 중요하다.

예를 들어, 필수 속성(Not NULL)에 대한 제약 역시 애플리케이션 레벨에서 직접 관리해야 한다.

이 DocumentDB는 주로 다음과 같은 상황에서 사용된다.

대용량 데이터를 읽고 쓰는 백엔드 시스템
제품과 같이 다양한 속성이 있는 데이터 관리
다양한 유형의 메타데이터 추적
JSON 데이터 구조를 사용하는 앱

3. DynamoDB

그럼 이제 본격적으로 AWS에서 제공하는 NoSQL 서비스인 DynamoDB에 대해서 정리해 보려고 한다.

AWS에서 제공하는 DynamoDB는 다음과 같은 특징이 있다.

어떠한 규모든 10ms 미만의 성능을 제공한다.
Serverless: 서버를 직접 설치, 관리, 유지 및 보수, 운영할 필요 없이 AWS가 자동으로 서버와 용량을 관리해준다(like AuroraDB). 따라서 사용한 만큼만 비용을 지불한다.
NoSQL: NoSQL은 앞서 정리했듯, ACID 트랜잭션을 보장하지 않는 경우가 많지만, DynamoDB는 제공한다.
완전관리형: 설정, 보안, 백업, 복구, 모니터링 등 AWS가 관리해준다.

3.1 DynamoDB 구성 요소

DynamoDB는 다른 데이터베이스 시스템과 동일하게 테이블에 데이터를 저장한다. DynamoDB의 구성요소는 크게 두 가지로 나눌 수 있다.

항목: 각 테이블에 0개 이상의 항목이 존재해야 한다. 항목은 모든 항목 중에서 고유하게 식별할 수 있는 속성들의 집합이다. 관계형 데이터베이스에서 인스턴스에 해당한다고 볼 수 있다.
속성: 각 항목은 하나 이상의 속성으로 구성된다.

DynamoDB는 기본키(Primary Key)를 제외하고 스키마가 존재하지 않는다. 다음 그림 예시를 한 번 살펴보자.

위의 예시에서, 같은 PK를 가지더라도, 항목마다 속성의 개수가 다르고 스키마가 고정되어 있지 않다는 것을 알 수 있다. DynamoDB는 이러한 속성을 통해 유연한 데이터 저장이 가능하며, 하나의 항목은 최대 32개의 속성까지 지원한다.

3.2 DynamoDB 파티셔닝

DynamoDB는 내부적으로 데이터를 여러 파티션에 분산 저장하는 파티셔닝 구조를 사용한다.

데이터를 저장할 때 파티션 키(Partition Key)를 기준으로 해시 값을 계산하고, 해당 해시 결과에 따라 특정 파티션에 데이터가 저장된다. 이로 인해 파티션 키를 기준으로 한 조회는 매우 빠른 성능을 가지며, 일반적으로 O(1)에 가까운 시간 복잡도로 데이터를 조회할 수 있다.

DynamoDB의 기본 키(Primary Key)는 다음과 같이 두 가지 형태로 구성할 수 있다.

기본 키(Simple Primary Key): 파티션 키만으로 구성된 단순 기본 키
복합 기본 키(Composite Primary Key): 파티션 키 + 정렬 키(Sort Key)로 구성된 복합 기본 키

단순 기본 키를 사용하는 경우, 파티션 키가 곧 기본 키가 되며 해당 값은 테이블 내에서 유일하다.

복합 기본키를 사용하는 경우, 파티션 키는 데이터를 어떤 파티션에 저장할지를 결정하고, 정렬 키는 동일한 파티션 키를 가진 아이템들 사이에서 정렬 및 범위 조회를 가능하게 한다.

즉, DynamoDB에서는 반드시 파티션 키가 존재해야 하며, 선택적으로 정렬키를 추가하여 데이터 모델링과 조회 패턴을 더욱 유연하게 설계할 수 있다.

3.4 DynamoDB 용량

DynamoDB는 다음과 같이 두 가지의 용량 유형을 제공한다.

On-demand
- 사전에 용량을 설정하지 않고, 실제로 사용한 읽기-쓰기 요청량만큼 비용을 지불하는 방식이다.
- 트래픽이 급격히 증가하더라도 자동으로 확장되며, 이전 최대 트래픽 수준을 기준으로 빠르게 처리 용량을 늘려 스파이크 트래픽에도 대응할 수 있다.
- 트래픽 패턴이 예측하기 어렵거나 초기 서비스에 적합하다.
Privisioned
- 프로비저닝 방식으로, 애플리케이션에 필요한 초당 읽기 용량과 쓰기 용량을 미리 지정하고 그에 따라 비용을 지불한다.
- 트래픽 패턴이 비교적 안정적인 서비스에 적합하며, Auto Scailing을 설정하면 일정 범위 내에서 자동 확장도 가능하다.

3.5 DynamoDB 테이블 종류

DynamoDB는 다음과 같이 두 가지 테이블 종류를 제공한다.

Standard
- 저장비용이 높지만 요청비용이 낮은 테이블 클래스이다.
- 조회와 갱신이 빈번하게 발생하는 데이터에 적합하다.
Standard-IA(Infrequent Access)
- 저장비용이 낮지만 요청비용이 낮은 테이블이다.
- 조회 빈도가 낮은 로그 데이터, 과거 주문 내역, 오래된 기록 데이터 저장에 적합하다.

3.6 DynamoDB 생성 과정

테이블 세부 정보를 입력한다.
- 테이블 이름, 파티션 키, 정렬 키 등을 설정한다.
테이블 설정을 선택한다.
- 기본 설정 선택 시 테이블 클래스는 DynamoDB Standard, 용량 모드는 On-demand로 자동 설정된다.
- 설정을 사용자 지정할 경우 테이블 클래스(Standard/Standard-IA)와 읽기-쓰기 용량모드(On-demand/Privisioned)를 직접 선택할 수 있다.

4. DocumentDB

다음으로는 AWS에서 제공하는 DocumentDB에 대해서 정리해 보려고 한다. DocumentDB는 MongoDB와 호환되는 데이터베이스를 쉽게 설정, 운용 및 조정할 수 있는 빠르고 안정적인 완전 관리형 NoSQL 데이터베이스 서비스이다.

DocumentDB는 DynamoDB와 마찬가지로 다음과 같은 특징을 지닌다.

스키마가 존재하지 않는 NoSQL 데이터베이스이다.
완전 관리형 서비스로, 인프라 운영 부담 없이 사용할 수 있다.
데이터는 주로 JSON 형태의 문서(Document) 구조로 관리된다.
현재 Amazon DocumentDB는 3.6, 4.0, 5.0 버전이 릴리즈되어 있으며, MongoDB 3.6, 4.0, 5.0 API와 호환된다.

DocumentDB에서는 관계형 데이터베이스에서 사용하는 테이블, 컬럼 등의 용어를 사용하지 않고, 문서 지향 데이터베이스에 맞는 새로운 용어를 사용한다. 이를 정리하면 다음과 같다.

RDBMS	DocumentDB
테이블	컬렉션(Collection)
컬럼	필드(Field)
행	Document
PK	ObjectId

위 표는 RDBMS의 각 개념이 DocumentDB에서 어떤 개념으로 대응되는지를 나타낸 것이다. 즉, RDBMS의 테이블은 DocumentDB의 컬랙션에 해당하며, 컬럼은 필드, 행은 Document, 기본 키는 ObjectId로 표현된다.

출처: Amazon DocumentDB(MongoDB 호환)란 무엇인가 - Amazon DocumentDB

위 그림은 DocumentDB의 아키텍처 구조를 나타낸 것이다.

주요 개념은 다음과 같다.

Cluster(클러스터)
- DocumentDB는 기본적으로 클러스터 단위로 구성된다.
- 하나의 클러스터는 1개의 Primary(Writer) 인스턴스와 최대 15개의 Replica(Reader) 인스턴스로 구성된다.
Instance(인스턴스)
- 각 인스턴스는 EC2 기반으로 생성되는 독립적인 컴퓨팅 리소스이다.
- Replica 인스턴스를 추가함으로써 수평 확장이 가능하며, 이를 통해 읽기 처리량을 증가시킬 수 있다.
Storage Layer
- DocumentDB는 스토리지와 컴퓨팅을 분리한 아키텍처를 사용한다.
- 모든 데이터는 3개의 가용 영역(AZ, Availiability Zone)에 자동 복제되어 높은 내구성을 제공한다.
- 또한 WAL(Write-Ahead Logging) 기반의 저장 방식을 사용하여 빠른 쓰기 성능을 제공한다.
엔드포인트
- 클러스터 엔드포인트: Writer 인스턴스로 자동 라우팅된다.
- Reader 엔드포인트: 모든 Reader 인스턴스에 대해 로드 밸런싱된다. 장애 발생 시 자동으로 역할 전환(Failover)이 이루어진다.

4.1. DocumentDB 클러스터 생성과정

1. 클러스터 유형을 선택한다.

인스턴스 기반 클러스터: 기본 방식으로, EC2 기반 인스턴스를 사용하는 기존 방식의 클러스터이다.
Elastic 클러스터: 서버리스 방식으로 확장되며, 인스턴스 관리 없이 사용할 수 있는 최신 클러스터 유형이다.

2. 클러스터 식별자 및 엔진 버전을 선택한다.

선택한 엔진 버전에 따라 호환 가능한 MongoDB API 버전이 결정된다.

3. 클러스터 스토리지 configuration 설정

Amazon DocumentDB Standard: 스토리지 요금 + I/O 요청당 비용 별도 청구되는 방식이다.
Amazon I/O Optimized: 스토리지 요금에 I/O 비용이 포함되어 있으며, I/O 요청이 잦은 서비스에 적합하다.

4. 인스턴스 configuration 설정

Memory optimized classes: 메모리 중심 작업에 최적화한 인스턴스 유형으로, 대부분의 DocumentDB 워크로드에서 사용된다.
NVMe-backed classes: 로컬 NVMe SSD를 사용해 디스크 I/O 성능을 극대화 인스턴스 유형이다.
- DocumentDB 인스턴스가 실행되는 AWS EC2 호스트에 물리적으로 연결된 로컬 NVMe 스토리지를 사용하며, 주로 캐시나 임시 데이터 등 내부 처리용 데이터가 저장된다.
- 실제 데이터는 분리된 스토리지 레이어에 저장되므로, 인스턴스 재시작이나 교체 시에도 NVMe에 데이터는 유지된다.
db.t3.medium: 테스트 환경이나 저부하 환경에 적합한 최소 사양 인스턴스이다.

5. Connectivity 설정

Connect to an EC2 compute resource: DocumentDB와 EC2 인스턴스를 같은 VPC/Subnet 내에서 자동으로 연결한다. EC2 기반 백엔드 서버에서 DocumentDB를 사용하는 경우 권장된다.
Don't connect to an EC2 Compute resource: 이후 Lambda나 로컬 환경 등 다른 서비스에서 수동으로 접근할 경우 사용하는 설정이다.

5. AWS DB 활용

곧 웹 서비스로 구현할 프로젝트가 JSON 형식으로 데이터를 저장하고, 사용자에게 해당 데이터를 보여줘야 하는 서비스이다. 처음에는 RDBMS에 파일 경로만 저장해두고 파일 기반으로 관리하려고 했지만, 동아리 스터디 시간에 배웠던 NoSQL을 실제로 적용해 볼 좋은 기회라고 생각해 NoSQL의 기본 개념과 활용 방향을 정리해 보았다.

JSON으로 저장하고 보여줄 데이터는 사업 아이디어, 사업 지표(TAM/SAM/SOM), 활용 데이터셋 정보 등이다. 또한 여러 논문들의 메타데이터(초록, 제목, DOI 등)를 함께 보여줘야 한다. 이때 논문마다 보유한 메타데이터가 제각각이기 때문에 어떤 논문은 DOI가 없거나 어떤 논문은 초록(abstract)를 추출하지 못하는 등 필드가 누락되는 경우가 자주 발생한다.

RDBMS로 이를 그대로 모델링하면 누락 필드를 위한 NULL 컬럼이 늘어나거나, 메타데이터 구조 변경 시 스키마 변경이 잦아질 수 있다. 반면 NoSQL은 문서마다 필요한 필드만 저장할 수 있고, 데이터 구조가 유동적으로 바뀌는 상황에서도 확장과 변경이 상대적으로 유연하다. 특히 초록은 존재 여부가 케이스별로 달라, 문서 단위로 필드 유무가 달라질 수 있는 Document 모델이 잘 맞는다고 판단했다.

따라서 이번 아키텍처에서는 NoSQL 중 DocumentDB를 활용해 클러스터를 구성하고, 저장할 데이터를 문서(Document) 형태로 관리하려고 한다. 개발 환경에서는 MongoDB를 사용해 로컬에서 테스트하고, 배포 환경에서는 AWS DocumentDB를 사용해 운영하는 형태로 가져라겨 한다. 또한, AWS에서 MongoDB와 호환되는 버전이 한정되어 있기 때문에 호환 API 범위 내에서 설계해야 한다는 주의점도 기억해야 한다.

DynamoDB를 활용하지 않은 이유는 단순히 Key-Value 기반 조회보다는, 논문의 초록(asbtract)과 같은 문서 내용 중심의 조회가 더 많이 발생할 것으로 예상되기 때문이다. DynamoDB는 기본적으로 파티션 키와 정렬 키 기반의 정형 조회에 최적화된 반면, DocumentDB는 문서 단위로 데이터를 저장하고 중첩 구조나 가변 필드를 자연스럽게 다룰 수 있어 이러한 조회 패턴에 더 적합하다고 판단했다. 따라서 이번 프로젝트에서는 DocumentDB를 사용할 예정이다.

윈디개 님의 블로그

[개인 프로젝트] - NoSQL