결정: 서버 사이징
올바른 사이징은 워크로드 프로필(OLTP, 데이터 웨어하우스, 혼합)에서 시작하며 실제 병목(CPU, I/O, RAM)을 찾아야 한다. 황금률: 자주 접근하는 데이터 집합(working set)은 RAM에 들어가야 한다. 먼저 측정한 뒤 확장하고, 갑작스러운 부하에 대비해 여유를 남긴다. 이 트리는 워크로드를 식별하고 병목에 따라 리소스와 확장 방향(수직/수평)을 선택하도록 돕는다.
워크로드 프로필은 무엇인가?
OLTP와 분석 부하는 완전히 다른 리소스 프로필을 요구하므로 사이징은 워크로드에서 시작한다. 시스템의 주된 작업은 무엇인가: 작고 빠른 다수의 트랜잭션(OLTP)인가, 대규모 스캔과 집계를 수행하는 보고/분석(DWH)인가, 아니면 둘의 혼합인가? 확실하지 않다면 먼저 측정해야 한다.
- OLTP — 작고 짧은 다수의 트랜잭션(웹/애플리케이션)
- 분석 / 데이터 웨어하우스(DWH) — 대규모 스캔과 집계
- 혼합 워크로드이거나 확실하지 않음
- 병목은 알고 있다. 수직 확장과 수평 확장 중 무엇을 해야 하는가?
병목은 어디인가: RAM, I/O, CPU?
OLTP에서는 무작정 리소스를 추가하는 대신 실제 병목을 찾는다. 지표를 확인한다: 자주 접근하는 데이터가 RAM에 들어가지 않아 디스크 읽기가 많은가(RAM/I/O), 디스크 지연/IOPS가 부족한가(I/O), 아니면 데이터는 이미 메모리에 있지만 CPU가 포화 상태인가(CPU)? 잘못된 리소스를 확장하면 비용과 시간을 낭비한다.
- 자주 접근하는 데이터가 RAM에 들어가지 않음, 디스크 읽기가 많음
- 데이터는 메모리에 있지만 디스크 지연/IOPS가 부족함(쓰기 중심)
- 데이터는 메모리에 있고 디스크도 정상이지만 CPU가 계속 포화 상태임
권장: 먼저 측정한 뒤 사이징
추측에 기반한 하드웨어 구매는 거의 항상 잘못된 크기로 이어진다. 워크로드 프로필과 병목은 실제 지표에서 드러난다. 사이징은 추측이 아니라 측정 기반의 반복 작업이다.
권장: RAM 증설 — working set이 메모리에 들어가야 한다
가장 중요한 OLTP 규칙: 자주 접근하는 데이터와 인덱스(working set)는 메모리(buffer/cache)에 들어가야 한다. 그렇지 않으면 모든 쿼리가 디스크로 가서 지연이 폭증하고 I/O가 병목이 된다. RAM은 대개 투자 대비 효과가 가장 큰 항목이다.
권장: I/O 계층 강화(IOPS/지연)
데이터가 메모리에 있어도 쓰기 중심 부하(commit, WAL/redo/binlog, checkpoint)에서는 디스크 속도가 결정적이다. 여기서 문제는 용량이 아니라 IOPS와 지연이다. 잘못된 디스크 등급은 빠른 CPU/RAM에도 불구하고 시스템을 마비시킨다.
권장: CPU 병목 해결(먼저 쿼리, 그다음 코어)
데이터가 메모리에 있고 디스크가 정상인데 CPU가 포화라면 근본 원인은 대개 비효율적인 쿼리(나쁜 실행 계획, 누락된 인덱스, 다수의 작은 쿼리) 또는 과도한 동시성이다. 코어를 추가하기 전에 부하를 줄이는 것이 대개 더 저렴하고 효과적이다.
권장: 분석/DWH — 처리량, 병렬성, 수평 확장
데이터 웨어하우스 워크로드는 큰 테이블을 스캔하고 집계하는 소수의 무거운 쿼리로 구성된다. 여기서 우선순위는 낮은 지연이 아니라 높은 스캔 처리량, 병렬성, 그리고 대개 수평 확장 가능한 아키텍처다.
일반 원칙: 수직 vs 수평 + 여유 + 먼저 측정
어떤 리소스를 확장하느냐만큼 어떻게 확장하느냐도 중요하다. 수직(더 큰 머신)은 단순하지만 한계와 단일 장애 지점이 있고, 수평(더 많은 머신)은 확장되지만 복잡성을 더한다. 어떤 경우든 갑작스러운 부하에 대비해 여유를 남기고 측정으로 결정을 검증한다.