AWS 03-3 특수 목적 DB — Neptune·Timestream
AWS 의 DB 목록 끝에는 이름부터 낯선 둘이 있습니다. Neptune 과 Timestream. 둘 다 PostgreSQL 같은 관계형 데이터베이스로도 흉내는 낼 수 있는 일을 맡습니다. 그런데 AWS 는 굳이 별도 서비스로 팝니다.
이 편의 질문은 하나입니다. 관계형 DB 로 버티다가 언제 넘어가고, 안 넘어가도 되는 때는 언제인가. 답은 데이터의 모양에 있습니다. 관계를 따라갈수록 행이 불어나거나 경로 자체가 답인 데이터는 그래프 DB 로, 시각이 붙은 측정값이 끝없이 쌓이는 데이터는 시계열 DB 로 갑니다. 둘 다 아니면 관계형 DB 에 남는 편이 싸고 편합니다. 요금은 전부 2026-09-23 서울(ap-northeast-2) 기준입니다.
지도
flowchart TD
START["관계형 DB 가 버거워 보인다"] --> Q1{"데이터가 어떤 모양인가"}
Q1 -- "관계를 여러 단계 따라간다" --> Q2{"깊어지면 느려지나<br/>경로 자체가 답인가"}
Q2 -- "아니다. 2~3단계에서 충분하다" --> PGR["PostgreSQL 재귀 질의<br/>관계형 DB 에 남는다"]
Q2 -- "그렇다" --> NEP["Neptune<br/>관리형 그래프 DB"]
Q1 -- "시각이 붙은 측정값이 쌓인다" --> Q3{"무엇을 얼마나 쌓나"}
Q3 -- "AWS 자원·앱 상태 지표" --> CW["CloudWatch 지표"]
Q3 -- "하루 수십만 행 이하" --> PGT["PostgreSQL 날짜별 표 나누기"]
Q3 -- "그보다 많은 센서·장비" --> TS["Timestream for InfluxDB<br/>관리형 시계열 DB"]
두 갈래 모두 「PostgreSQL 재귀 질의」와 「PostgreSQL 날짜별 표 나누기」처럼 관계형 DB 에 남는 출구가 있습니다. 넘어가는 쪽은 그 출구로 부족할 때입니다.
1. 그래프 DB 가 푸는 문제 — 깊이가 아니라 불어나는 행과 경로
그래프 는 점(노드)과 점을 잇는 선(간선)으로 이루어진 자료 구조입니다. 사람은 노드, 「친구다」는 간선이 됩니다. 그래프 DB 는 이 모양 그대로 저장하고 질의하는 DB 입니다.
장면 하나로 봅니다. SNS 에서 「나와 3단계 안에 있는 사람」을 추천하려 합니다. 관계형 DB 에는 friendship(user_id, friend_id) 표 하나가 있고, 한 단계를 더 가려면 이 표를 자기 자신과 한 번 더 JOIN 합니다.
PostgreSQL 은 이 반복을 재귀 CTE 로 씁니다. CTE(Common Table Expression, 공통 테이블 표현식)는 WITH 로 이름을 붙인 임시 결과입니다. WITH RECURSIVE 를 쓰면 자기 결과를 다시 입력으로 받아 반복합니다(PostgreSQL: WITH Queries).
WITH RECURSIVE fof(id, depth) AS (
SELECT friend_id, 1
FROM friendship
WHERE user_id = 1
UNION
SELECT f.friend_id, fof.depth + 1
FROM friendship f
JOIN fof ON f.user_id = fof.id
WHERE fof.depth < 3
)
SELECT DISTINCT id FROM fof;
- 첫
SELECT는 출발점으로, 1번 사용자의 직접 친구를 고릅니다 UNION아래는 앞 단계 결과fof에friendship을 JOIN 해서 한 단계 더 갑니다WHERE fof.depth < 3이 3단계에서 멈추게 합니다
같은 질문을 openCypher 로 쓰면 이렇습니다. openCypher 는 Neo4j 의 질의 언어 Cypher 에서 나온 공개 그래프 질의 언어로, 노드와 간선을 그림 그리듯 패턴으로 적습니다.
MATCH (me:Person {id: 1})
-[:FRIEND*1..3]->(p:Person)
RETURN DISTINCT p
(me:Person {id: 1})는 이름표가 Person 이고 id 가 1인 노드를 찾습니다-[:FRIEND*1..3]->는 FRIEND 간선을 1~3번 따라갑니다
깊이는 양쪽 다 숫자 하나입니다. SQL 의 depth < 3 과 openCypher 의 *1..3 은 같은 일을 합니다. 차이는 두 군데서 납니다.
첫째, 행 수가 곱으로 불어납니다. 친구가 평균 200명이면 1단계에서 200행, 2단계에서 4만 행, 3단계에서 800만 행이 중간 결과로 생깁니다(중복 포함). 관계형 DB 는 단계마다 이 중간 결과를 다시 표에 JOIN 합니다. AWS 는 연결이 촘촘한 데이터에서 SQL 질의가 복잡하고 성능을 조율하기 어렵다고 보고, 수십억 개의 관계를 밀리초 단위로 질의하도록 만든 엔진을 내세웁니다(What Is Amazon Neptune?).
둘째, 경로 자체가 답일 때입니다. 「A 에서 B 까지 어떤 사람들을 거쳐 이어지나」를 돌려받으려면 CTE 안에 거쳐 온 id 를 배열로 쌓고, 같은 사람을 두 번 밟지 않게 순환 검사를 적어 넣어야 합니다. 친구·직장·학교처럼 관계 종류가 섞이면 JOIN 할 표도 늘어납니다. openCypher 에서는 패턴에 path = (...) 로 이름을 붙이고 RETURN path 하면 끝입니다.
2. Neptune — 관리형 그래프 DB
1절의 두 문제를 맡기는 곳이 Neptune 입니다. 수십억 개의 관계를 밀리초 단위로 질의하도록 만든 관리형 그래프 DB 이고, 하드웨어 준비·패치·백업을 AWS 가 맡습니다.
그래프를 저장하는 방식이 둘이고, Neptune 은 둘 다 받습니다. 1절의 openCypher 예가 쓴 방식은 속성 그래프(property graph)로, 노드·간선에 이름표와 키-값 속성을 붙입니다. 여기에는 openCypher 말고 Gremlin 도 씁니다. Apache TinkerPop 프로젝트의 질의 언어로, 「이 노드에서 저 간선을 따라가라」를 단계별로 이어 씁니다. 다른 하나는 RDF(Resource Description Framework)로, W3C(World Wide Web Consortium, 웹 표준 단체)가 정한 데이터 표현 표준입니다. 「주어-술어-목적어」 세 칸짜리 문장 하나에 사실 하나를 적기 때문에, 여러 출처의 사실을 한 그래프로 합치는 지식 그래프에서 주로 씁니다. 질의는 표준 질의 언어 SPARQL(SPARQL Protocol and RDF Query Language)로 합니다. 방식을 먼저 고르면 질의 언어가 따라옵니다.
| 모델 | 무엇을 저장하나 | 질의 언어 |
|---|---|---|
| 속성 그래프(property graph) | 노드·간선에 이름표와 키-값 속성을 붙인다 | Gremlin · openCypher |
| RDF | 「주어-술어-목적어」 세 칸짜리 문장을 쌓는다 | SPARQL |
다만 Neptune 의 openCypher 는 shortestPath() 처럼 지원하지 않는 기능이 있습니다(openCypher specification compliance in Amazon Neptune).
구성은 단순합니다. 쓰기를 맡는 기본 인스턴스 1대와 읽기 전용 복제본 최대 15대가 저장소 하나를 같이 씁니다. 저장소는 데이터 사본 6개를 가용 영역 3곳에 나눠 둡니다.
Neptune Serverless 는 인스턴스 크기를 고르는 대신 부하에 맞춰 연산 용량을 늘였다 줄입니다. 단위는 NCU(Neptune Capacity Unit)이고, 1 NCU 는 메모리 2 GiB 와 그에 맞는 CPU·네트워크입니다. 범위는 1.0~128 NCU 이고, 최소가 1.0 이라서 0 까지 내려가지는 않습니다(Capacity scaling in a Neptune Serverless DB cluster).
Neptune Analytics 는 그래프 전체를 메모리에 올려 분석하는 별도 엔진입니다. 영향력 순위 매기기·군집 찾기 같은 그래프 알고리즘을 openCypher 로 돌리고, 데이터는 Neptune Database 나 S3 에서 불러옵니다(What is Neptune Analytics?). 용량 단위 m-NCU 는 메모리 1 GB 와 그에 맞는 연산을 1시간 쓰는 양입니다.
Neptune · 서울 · 한 달(730시간)
db.t4g.medium $0.1424 × 730 = $103.95 (가장 작은 인스턴스)
Serverless $0.1941 × 730 = $141.69 (최소 1 NCU)
저장소 GB·월 $0.12 · 입출력 100만 건당 $0.24
Neptune Analytics · 16 m-NCU(가장 작은 크기)
시간당 $0.581, 일시 중지하면 연산 요금의 10%
- 위는 Standard 요금입니다. 입출력 요금이 전체의 25% 를 넘으면 입출력 요금이 없는 I/O-Optimized 로 최대 40% 를 아낄 수 있습니다
- 복제본마다 인스턴스 요금, 클러스터 저장량을 넘는 백업(GB·월 $0.023), 데이터 전송 요금이 더 붙습니다
- 무료 체험은 30일 동안
db.t3.medium·db.t4g.medium750시간, 입출력 1,000만 건, 저장소 1 GB, 백업 저장소 1 GB 입니다(Amazon Neptune pricing)
작게 시작할 땐 인스턴스가 더 쌉니다. Serverless 는 쉬는 동안에도 최소 1 NCU 값이 나가서, 늘 켜 둔 db.t4g.medium 보다 월 $38 가량 비쌉니다. Serverless 는 부하가 들쭉날쭉할 때 고릅니다.
이 고정비를 내고도 남는 것은 불어나는 행과 경로가 질의의 중심일 때입니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 친구·팔로우 관계로 추천을 만든다 | 관계가 2~3단계에서 끝나고 경로를 돌려받을 일이 없다 | 가장 작게 켜도 월 $103.95 |
| 사기 탐지 — 계좌·기기·주소가 몇 단계 건너 이어지는 고리를 찾는다 | 대부분의 질의가 집계·합계다 | 팀이 그래프 모델과 새 질의 언어를 익혀야 한다 |
| 지식 그래프 — 여러 출처의 사실을 합친다(RDF) | 그래프 질의는 하루 몇 번 도는 분석뿐이다(→ Neptune Analytics 로 가끔) | 관계형 DB 와 데이터를 나눠 두면 동기화를 내가 맡는다 |
관계형 DB 에 남아 있다가 재귀 CTE 의 중간 결과가 불어나 응답이 느려지거나, 경로 배열과 순환 검사를 질의마다 손으로 짜게 되면 그때 Neptune 을 봅니다.
3. 시계열 DB 가 푸는 문제 — 쌓이기만 하고 고쳐지지 않는 행
시계열 데이터는 시각이 붙은 측정값이 한 줄씩 이어지는 데이터입니다. 온도 센서가 10초마다 값을 하나 보내는 모습을 떠올리면 됩니다. 특징은 셋입니다. 거의 추가만 하고 고치지 않습니다. 질의는 대부분 최근 구간을 잘라 평균·최대를 내는 것입니다. 오래된 데이터는 지우거나 줄여서 보관합니다. 1초 단위 값을 1시간 평균으로 줄여 남기는 일을 다운샘플링(downsampling)이라고 합니다.
규모를 재 봅니다. 센서 10개가 10초마다 값을 보내면 하루 8만 6,400행입니다. 센서 1,000개면 하루 864만 행, 한 달이면 2억 5,920만 행입니다.
하루 수십만 행 이하라면 관계형 DB 로 버팁니다. 날짜별로 표를 나누는 파티셔닝 을 걸면 오래된 날짜는 표째로 지우고, 질의는 필요한 날짜 표만 읽습니다. RDS for PostgreSQL 에서는 파티션을 자동으로 만들고 지우는 확장 pg_partman, 예약 작업을 돌리는 pg_cron, BRIN(Block Range Index)을 함께 씁니다. BRIN 은 페이지 묶음마다 시각의 최솟값·최댓값만 적어 두는 가벼운 인덱스입니다(Designing high-performance time series data tables on Amazon RDS for PostgreSQL).
시계열 DB 와의 차이는 질의 모양보다 질의 밖에 있습니다. 보존 기간이 지난 데이터 삭제, 시계열에 맞춘 압축 저장, 센서가 한 줄씩 보내는 쓰기 형식(4절의 line protocol)을 시계열 DB 는 처음부터 갖고 있습니다. 관계형 DB 에서는 이것을 파티션 관리로 직접 짭니다.
4. Timestream — 두 갈래 중 하나는 신규 가입이 막혔다
Timestream 이라는 이름 밑에 서비스가 둘 있습니다. AWS 가 먼저 내놓은 Timestream for LiveAnalytics 와, 오픈소스 시계열 DB 를 맡아 운영하는 Timestream for InfluxDB 입니다. 앞의 것은 신규 가입이 막혀서 새로 쓸 수 있는 것은 뒤의 것뿐입니다.
| 갈래 | 상태(2026-09-23) |
|---|---|
| Timestream for LiveAnalytics | 2025-06-20 유지보수 단계에 들어갔습니다. 새 고객은 가입할 수 없고 기능도 더하지 않습니다. 서울에는 원래 없었습니다 |
| Timestream for InfluxDB | 정상 제공이고, LiveAnalytics 의 대안으로 안내됩니다. 서울에서 됩니다 |
(Services in Maintenance · Amazon Timestream endpoints and quotas)
그래서 이 절은 Timestream for InfluxDB 만 봅니다. 오픈소스 시계열 DB 인 InfluxDB 를 AWS 가 띄워 백업·버전 갱신·복제를 맡는 서비스입니다. RDS 가 PostgreSQL 을 맡는 것과 같은 관계입니다.
InfluxDB 는 데이터를 표와 조금 다르게 부릅니다(What is Timestream for InfluxDB?).
| InfluxDB | 관계형 DB 로 치면 | 예 |
|---|---|---|
| bucket | 보존 기간이 붙은 데이터베이스 | factory |
| measurement | 표 | sensor |
| tag | 인덱스가 걸리는 문자열 열 | room=A1 |
| field | 측정값 열 | temp=23.5 |
쓰기는 line protocol 이라는 한 줄 형식으로 합니다. measurement,tag들 field들 시각 순서입니다.
sensor,room=A1 temp=23.5 1758585600000000000
- 시각의 기본 단위는 나노초입니다. 초 단위 값을 보내려면 쓰기 요청에
precision=s를 붙입니다
measurement 와 tag 값의 조합 하나를 시리즈라고 하고, 시리즈의 개수를 시리즈 카디널리티 라고 합니다. tag 값이 다양할수록 시리즈가 늘어 인덱스가 커집니다. 요청 ID 처럼 매번 다른 값을 tag 에 넣으면 쓰기와 읽기가 함께 느려집니다. AWS 는 인스턴스 하나에 시리즈 키를 1,000만 개 넘게 두지 말라고 권합니다.
InfluxDB 는 판이 둘입니다. InfluxDB 2 는 인스턴스 1대와 거기 붙은 SSD 로 돌고, InfluxDB 3 는 노드 1대 이상의 클러스터가 데이터를 S3 에 쌓습니다. 질의 언어와 서울 최소 요금까지 나란히 놓으면 이렇습니다.
| InfluxDB 2 | InfluxDB 3 | |
|---|---|---|
| 단위 | DB 인스턴스 1대. 필요하면 다른 가용 영역에 대기 인스턴스(Multi-AZ) | DB 클러스터(노드 1대 이상) |
| 저장소 | 인스턴스에 붙은 SSD. 20 GiB 부터, 3K·12K·16K IOPS 세 단계 | S3 에 Parquet(열 단위 파일 형식)로 저장 |
| 질의 | Flux(InfluxDB 2 의 함수형 질의 언어) · InfluxQL | SQL · InfluxQL |
| 서울 최소 노드 | db.influx.medium 시간당 $0.1448 |
db.influxIOIncluded.medium 시간당 $0.1592 |
InfluxDB 3 에는 다시 둘이 있습니다. Core 는 노드 1대뿐이고 compaction(작은 파일을 합쳐 저장 형식을 다듬는 작업)이 없습니다. Enterprise 는 노드를 여러 대 두고 compaction 을 하며, vCPU 시간당 InfluxData 라이선스 요금이 AWS Marketplace 로 붙습니다. 며칠 치 최근 데이터만 보는 실시간 모니터링이면 Core, 오래 쌓아 분석하면 Enterprise 를 고릅니다(Amazon Timestream for InfluxDB 3).
Timestream for InfluxDB · 서울 · 한 달(730시간)
InfluxDB 2 db.influx.medium, Single-AZ
인스턴스 $0.1448 × 730 = $105.70
저장소 최소 20 GiB × $0.1206 = $2.41
합계 = $108.11
InfluxDB 3 db.influxIOIncluded.medium, Core
노드 $0.1592 × 730 = $116.22
+ S3 저장(월 200 GB 치 최소 요금)
- 요금은 초 단위로 매기고 최소 10분입니다. Multi-AZ 는 인스턴스·저장소 단가가 약 두 배입니다
- InfluxDB 3 의 S3 저장 GB 단가는 확인하지 못했습니다(미확인). 전송 아웃 요금과 Enterprise 라이선스가 더 붙습니다
이 값을 내기 전에 볼 대안이 둘 있습니다. 하나는 PostgreSQL 에 TimescaleDB 를 얹는 것입니다. TimescaleDB 는 자동 파티션·압축·시간 구간 함수를 더하는 확장인데, RDS for PostgreSQL 의 확장 목록에는 없어서 쓰려면 EC2 에 PostgreSQL 을 직접 설치하고 운영까지 맡습니다(Extension versions for Amazon RDS for PostgreSQL). 다른 하나는 CloudWatch 지표입니다. AWS 자원의 지표는 이미 CloudWatch 에 쌓이고, 애플리케이션이 보내는 사용자 지정 지표도 받습니다. 서버와 앱 상태를 그래프로 보고 알람을 거는 것이 목적이라면 시계열 DB 가 필요 없습니다.
두 대안으로 모자랄 만큼 측정값이 쌓이고, 그 측정값을 다른 업무 데이터와 섞지 않을 때 Timestream for InfluxDB 가 맞습니다.
| 이럴 때 맞다 | 이럴 때 안 맞다 | 대신 치르는 것 |
|---|---|---|
| 공장·건물 센서, IoT(Internet of Things, 사물 인터넷) 장비가 많아 하루 수십만 행을 넘긴다 | 하루 수십만 행 이하이고 날짜별 표 나누기로 충분하다 | 가장 작게 켜도 월 $108.11 |
| InfluxDB·Telegraf(InfluxData 의 수집 에이전트)를 쓰고 있다 | AWS 자원과 앱 상태 지표만 본다(→ CloudWatch) | 서버에 직접 접속할 수 없고 API 와 웹 화면으로만 다룬다 |
| 보존 기간·다운샘플링을 DB 가 맡아 주길 원한다 | 측정값을 주문·회원 데이터와 자주 JOIN 한다 | tag 설계를 잘못하면 카디널리티로 느려진다 |
관계형 DB 에서 측정값 표의 파티션 관리가 운영 일의 큰 몫이 됐거나, 쓰기가 몰리는 시간에 다른 질의까지 느려지면 그때 Timestream for InfluxDB 를 봅니다.
이럴 땐 무엇
| 상황 | 서비스 | 이유 |
|---|---|---|
| 친구의 친구를 2~3단계만 찾고 경로는 필요 없다 | PostgreSQL 재귀 CTE | 중간 결과가 감당할 만하면 SQL 로 충분하고 고정비가 없다 |
| 관계 탐색에서 행이 불어나 느려지거나, 경로 자체를 돌려받는다 | Neptune | 탐색을 기본 동작으로 두고 경로를 RETURN path 로 받는다 |
| 여러 출처의 사실을 합친 지식 그래프 | Neptune (RDF + SPARQL) | 표준 모델로 사실을 한 그래프에 합친다 |
| 부하가 들쭉날쭉한 그래프 DB | Neptune Serverless | 1~128 NCU 자동 조절. 늘 켜 두면 인스턴스보다 비싸다 |
| 그래프 전체에 알고리즘을 가끔 돌린다 | Neptune Analytics | 메모리에 올려 분석하고, 안 쓸 땐 일시 중지(10%) |
| 센서가 많아 하루 수십만 행을 넘긴다 | Timestream for InfluxDB 2 | 시간 구간 질의·보존 정책이 기본 |
| 시리즈가 아주 많고 오래 보관한다 | Timestream for InfluxDB 3 Enterprise | S3 에 Parquet 로 쌓고 compaction |
| 측정값이 하루 수십만 행 이하다 | RDS for PostgreSQL + 파티셔닝 | 새 DB 없이 pg_partman·BRIN 으로 버틴다 |
| TimescaleDB 를 꼭 쓰고 싶다 | EC2 에 직접 설치 | RDS 확장 목록에 없다 |
| 서버·앱 상태 그래프와 알람 | CloudWatch 지표 | AWS 자원 지표가 이미 쌓이고 있다 |
| Timestream for LiveAnalytics 를 새로 쓰려 한다 | Timestream for InfluxDB | 2025-06-20 부터 신규 가입 불가 |
자주 붙는 서비스
S3(Neptune 대량 적재·Analytics 입력, InfluxDB 3 저장소) · VPC(두 서비스가 뜨는 망) · CloudWatch(두 서비스의 상태 감시) · IoT Core(센서 데이터를 받아 넘기는 쪽)
한 장 요약
넘어가는 이유는 깊이가 아니라 데이터의 모양입니다. 관계를 따라갈수록 중간 결과가 곱으로 불어나거나 경로 자체가 답이면 Neptune 으로 가고, 가장 작게 켜도 월 $103.95 입니다. 센서·장비의 측정값이 하루 수십만 행을 넘기면 Timestream for InfluxDB 로 가고, 가장 작게 켜도 월 $108.11 입니다. 그 아래라면 PostgreSQL 재귀 CTE·파티셔닝으로 남는 편이 싸고, 서버 모니터링이 목적이면 CloudWatch 로 충분합니다. Timestream for LiveAnalytics 는 새로 쓸 수 없습니다.
관련 항목
이 편이 다루는 특수 목적 DB
Neptune · Neptune Serverless · Neptune Analytics · Timestream for InfluxDB · Timestream for LiveAnalytics
그래프 DB 를 이루는 개념
그래프 데이터베이스 · 그래프 · 속성 그래프 · RDF · 지식 그래프 · 그래프 알고리즘
Neptune 이 받는 질의 언어와 그 출처
Gremlin · openCypher · SPARQL · Cypher · Apache TinkerPop · Neo4j
그래프 DB 가 풀어 주는 문제
추천 시스템 · 사기 탐지 · 벡터 검색 · 최단 경로
시계열 DB 를 이루는 개념
시계열 데이터베이스 · InfluxDB · line protocol · 카디널리티 · 다운샘플링 · Parquet · compaction
관계형 DB 에 남을 때 쓰는 도구
관계형 데이터베이스 · PostgreSQL · SQL · JOIN · 재귀 CTE · 파티셔닝 · pg_partman · BRIN 인덱스 · TimescaleDB
같은 데이터를 다른 방식으로 담는 AWS 서비스
RDS · Aurora · DynamoDB · CloudWatch
두 서비스가 쓰는 기반
VPC · 가용 영역 · S3 · AWS 리전 · 서비스 수명 주기
시계열 데이터를 만들고 모으는 쪽
IoT · IoT Core · Telegraf · Prometheus · Grafana