데이터베이스 튜닝으로 병목을 줄이는 성능 최적화 전략

DB 병목은 여러 층에서 나타난다

데이터베이스 튜닝은 DB 시스템의 성능을 최적화하는 활동이다. 사용자 응답 시간을 줄이고 처리량을 높이며 시스템 자원의 활용도를 개선하는 것이 목적이다. 대부분의 엔터프라이즈 시스템에서 데이터베이스는 병목 지점이 되기 쉽고, 데이터 처리량과 비즈니스 규모가 커질수록 확장성과 운영 비용, 사용자 경험에 직접 영향을 준다.

원인을 한 곳에서만 찾기보다 하드웨어, DBMS, 데이터베이스 설계, SQL, 애플리케이션을 연결해 살펴야 한다.

⤢✕

자원 배치와 DBMS 설정에서 확인할 항목

하드웨어에서는 CPU 코어 수, 클럭 속도, 캐시 크기를 검토한다. 메모리는 버퍼 캐시와 공유 풀에 필요한 물리 메모리를 확보하고, 메모리 계층 구조까지 고려해 설계한다. 디스크 I/O는 RAID 구성으로 분산하고 SSD를 활용해 랜덤 액세스 성능을 높일 수 있다. 데이터 파일과 로그 파일을 분리해 배치하는 방식도 대상이다. 네트워크는 충분한 대역폭과 낮은 지연 시간을 확보해야 한다.

A 금융회사는 트랜잭션 로그와 데이터 파일을 별도 디스크로 분리하고 RAID 10을 적용해 I/O 병목현상을 30% 줄였다.

DBMS 설정에서는 버퍼 캐시 크기(Oracle의 SGA, SQL Server의 Buffer Pool), 쿼리 작업 공간(Oracle의 PGA, MySQL의 Sort Buffer), 프로시저 캐시(Oracle의 Shared Pool)를 다룬다. 최대 연결 수와 병렬 쿼리 처리 옵션, 체크포인트 빈도와 아카이브 로그 설정, 자동 통계 수집과 히스토그램 생성 기준도 함께 조정한다.

B 제조기업은 Oracle 데이터베이스의 SGA를 시스템 메모리의 40%에서 60%로 늘리고 PGA_AGGREGATE_TARGET을 조정해 디스크 I/O를 25% 감소시켰다.

데이터 모델이 쿼리 비용을 결정하는 방식

테이블 설계에서는 정규화와 반정규화의 수준, 컬럼 데이터 타입, 자주 접근하는 컬럼의 배치 순서를 검토한다. 인덱스는 선택도에 따라 설계하고, 복합 인덱스의 구성과 필터링·커버링 인덱스 활용 여부를 워크로드에 맞춰 결정한다.

대용량 데이터는 접근 패턴에 맞는 파티션 키를 선택해 범위, 해시, 리스트 파티셔닝을 적용할 수 있다. 관련 데이터를 물리적으로 가깝게 배치하거나 인덱스 클러스터링을 적용하는 방법도 있다.

C 전자상거래 회사는 주문 테이블을 날짜 기준으로 파티셔닝해 월별 통계 쿼리 성능을 8배 높였고, 주문상태+고객ID 복합 인덱스를 추가해 조회 성능을 65% 개선했다.

실행계획에서 SQL의 낭비를 찾는다

SQL 튜닝은 옵티마이저가 만든 실행계획을 읽는 데서 시작한다. 테이블 스캔과 인덱스 사용 여부를 확인하고, Nested Loop·Hash·Sort Merge 조인 방식과 조인 순서를 검토한다. WHERE 절 조건을 조정해 인덱스 스캔을 유도할 수 있으며, 서브쿼리와 조인, 임시 테이블의 성능 차이도 비교 대상이다.

다음은 조인 순서와 힌트를 조정한 쿼리 예시다.

-- 튜닝 전 쿼리
SELECT o.order_id, c.customer_name, p.product_name
FROM orders o, customers c, order_items oi, products p
WHERE o.customer_id = c.customer_id
AND o.order_id = oi.order_id
AND oi.product_id = p.product_id
AND o.order_date BETWEEN '2023-01-01' AND '2023-12-31'
AND c.region = 'APAC';

-- 튜닝 후 쿼리
SELECT /*+ LEADING(c o oi p) USE_NL(o) USE_NL(oi) USE_NL(p) */
       o.order_id, c.customer_name, p.product_name
FROM customers c, orders o, order_items oi, products p
WHERE c.region = 'APAC'
AND o.customer_id = c.customer_id
AND o.order_date BETWEEN '2023-01-01' AND '2023-12-31'
AND o.order_id = oi.order_id
AND oi.product_id = p.product_id;

측정과 변경 검증을 반복한다

모니터링에서는 버퍼 캐시 히트율을 95% 이상 유지하는지, 물리적·논리적 읽기 비율은 어떤지 확인한다. 래치·락 경합, CPU 사용률, 대기 이벤트도 병목 분석에 필요하다. 응답 시간, 처리량, 자원 사용률, 확장성 지표는 튜닝 효과를 판단하는 KPI가 된다.

⤢✕

Oracle 19c에서 일 500만 트랜잭션을 처리하는 시스템은 피크 시간대 응답 시간 지연과 락 경합을 겪었다. 인덱스 재구성 및 통계 정보 갱신, 월별에서 일별로의 파티션 전략 변경, 핫스팟 테이블의 읽기·쓰기 분리, 애플리케이션 커넥션 풀 최적화를 적용한 뒤 응답 시간은 65% 개선되고 처리량은 40% 증가했다.

SQL Server 2019와 15TB 데이터를 사용하는 데이터 웨어하우스에서는 복잡한 분석 쿼리 실행 시간이 문제였다. 컬럼스토어 인덱스, 세분화한 통계 정보, 쿼리 병렬 처리 설정, 자주 사용하는 집계용 구체화 뷰(Materialized View)를 적용해 쿼리 실행 시간을 평균 78% 단축했다.

워크로드 변화에 맞춰 튜닝 범위를 넓힌다

자동화된 튜닝에는 Oracle Automatic Database Diagnostic Monitor(ADDM), SQL Server Query Store와 자동 튜닝 기능, 머신러닝 기반 자동 인덱스 추천이 포함된다. 인메모리 컬럼스토어와 OLTP 인메모리 기술은 메모리 최적화의 선택지가 된다.

클라우드 환경에서는 탄력적 리소스 할당과 서버리스 DB 환경의 최적화를 고려해야 한다. NoSQL과 NewSQL에서는 분산 환경의 샤딩 전략, 일관성 수준과 성능 사이의 트레이드오프가 튜닝 대상이다.

성능 목표와 SLA 기준을 먼저 세우고 워크로드와 병목을 분석한 뒤, 우선순위와 리스크를 정해 변경을 적용한다. 변경 사항은 테스트하고 성능 영향을 측정해야 하며, 검증 결과와 운영 노하우를 문서화해 다음 튜닝 주기에 반영한다.