2편 · 약 17분
OLTP와 OLAP: 운영 DB와 분석 DB를 나누는 이유
이 세션의 목표
DBA가 데이터 플랫폼을 이해할 때 가장 먼저 나눠야 하는 축은 OLTP와 OLAP다. 둘 다 SQL을 쓰고 테이블을 다루지만 목적이 다르다.
- OLTP는 서비스가 지금 발생시키는 거래를 안전하게 처리한다.
- OLAP은 쌓인 데이터를 크게 읽고 집계해서 판단을 돕는다.
운영 DB에 무거운 분석 쿼리가 들어와 장애가 나는 대부분의 사고는 이 둘의 목적을 섞어서 생긴다.
OLTP: 현재 상태를 지키는 시스템
OLTP(Online Transaction Processing)는 주문 생성, 결제 승인, 로그인, 재고 차감처럼 작은 트랜잭션을 많이 처리하는 시스템이다.
중요한 기준은 다음과 같다.
| 기준 | OLTP에서 중요한 이유 |
|---|---|
| 짧은 응답 시간 | 사용자 요청과 직접 연결됨 |
| ACID 트랜잭션 | 돈, 재고, 권한처럼 틀리면 안 되는 상태 관리 |
| 동시성 제어 | 여러 사용자가 같은 데이터를 바꿔도 일관성 유지 |
| 인덱스 최적화 | 특정 행을 빠르게 찾고 갱신해야 함 |
| 백업/복구 | 서비스 장애와 데이터 손실을 막아야 함 |
OLTP DB의 대표 예시는 MySQL, PostgreSQL, Oracle, SQL Server 같은 RDBMS다.
OLAP: 과거와 패턴을 읽는 시스템
OLAP(Online Analytical Processing)은 대량 데이터를 읽고 집계하는 분석 시스템이다. “지난 6개월간 고객군별 매출 추세”, “취약점 데이터 수집량 변화”, “고객사별 동기화 지연 패턴” 같은 질문에 답한다.
OLAP은 보통 다음 특징을 가진다.
| 기준 | OLAP에서 중요한 이유 |
|---|---|
| 대량 scan | 많은 행을 읽고 집계함 |
| columnar storage | 필요한 컬럼만 읽어 집계 성능을 높임 |
| 병렬 처리 | 데이터를 여러 노드/파일로 나눠 처리함 |
| 과거 데이터 보관 | 트렌드 분석과 감사에 필요함 |
| 비즈니스 정의 | “활성 사용자”, “정상 수집” 같은 지표 정의가 중요함 |
왜 운영 DB에서 분석을 하면 위험한가
운영 DB는 작은 트랜잭션을 많이 처리하도록 설계된다. 분석 쿼리는 그 반대다. 긴 시간 동안 많은 행을 읽고, 임시 테이블을 만들고, 정렬·집계를 수행한다.
문제는 다음처럼 나타난다.
- buffer pool이 분석 쿼리 데이터로 오염되어 서비스 쿼리 cache hit가 떨어진다.
- 긴 쿼리가 lock, MVCC bloat, replication lag를 유발한다.
- read replica로 보냈더라도 replica lag가 커져 운영 판단이 늦어진다.
- 분석팀이 만든 ad-hoc query가 어떤 인덱스를 타는지 DBA가 통제하기 어렵다.
분리 패턴
OLTP DB
orders · users · payments → CDC / Batch Export
binlog · snapshot · ETL → Lake / Warehouse
raw · curated · marts → BI / Report
dashboard · audit · ML
orders · users · payments → CDC / Batch Export
binlog · snapshot · ETL → Lake / Warehouse
raw · curated · marts → BI / Report
dashboard · audit · ML
데이터를 빼내는 방식
| 방식 | 장점 | 주의점 |
|---|---|---|
| Read replica | 기존 RDBMS 구조를 활용하기 쉬움 | replica lag, 장시간 쿼리, 운영 DB 부하 전파 |
| Dump/Snapshot | 단순하고 재현 가능 | 전체 추출 비용, freshness 한계 |
| CDC/binlog | 변경분만 전달 가능 | ordering, schema change, idempotency 설계 필요 |
| Application event | 비즈니스 이벤트 의미가 명확 | 이벤트 누락/중복, DB 상태와 불일치 가능 |
DBA가 외워야 하는 구분
| 질문 | OLTP 답 | OLAP 답 |
|---|---|---|
| 주요 작업 | INSERT/UPDATE/DELETE/point SELECT | scan/join/group by |
| 데이터 모델 | 정규화 중심 | 비정규화·star schema 가능 |
| 성능 기준 | p95/p99 latency | 처리량, scan cost, dashboard refresh |
| 장애 영향 | 서비스 장애 | 의사결정 지연, 리포트 오류 |
| 대표 저장소 | MySQL, PostgreSQL | BigQuery, Snowflake, Redshift, ClickHouse, Hive/Spark |
실무 판단법
운영 DB에 들어온 쿼리를 보고 다음 중 하나라도 해당하면 OLAP 쪽으로 보내는 것을 검토한다.
- 하루/한 달 단위 집계가 들어간다.
GROUP BY,ORDER BY,COUNT(DISTINCT ...)가 크다.- 조회 범위가 수십만~수천만 행 이상이다.
- 결과가 사용자 요청 즉시 필요하지 않다.
- 같은 결과를 여러 사람이 반복해서 본다.
세션 과제
운영 DB slow query log에서 가장 무거운 SELECT 하나를 골라 다음을 적어보자.
- 이 쿼리는 OLTP 요청인가, OLAP 요청인가?
- 서비스 응답에 즉시 필요한가?
- replica나 warehouse로 옮길 수 있는가?
- 옮긴다면 freshness는 몇 분/몇 시간까지 허용되는가?
References
- https://www.ibm.com/think/topics/olap
- https://www.ibm.com/think/topics/oltp
- https://cloud.google.com/learn/what-is-a-data-warehouse