DB 조회 읽기 성능 최적화 패턴

Database System Foundation이 말하듯 DBMS 성능은 Disk I/O에 의해 결정된다. 이 패턴은 그 Disk I/O 병목을 어느 레이어에서 어떤 기법으로 줄이는지를 다룬다. B+ Tree 인덱싱과 순차 키 삽입이 어떤 index page를 읽고 쓰는지를 결정한다면, 이 페이지는 그 page를 메모리·스토리지·아키텍처 레이어에서 어떻게 더 빨리 접근하는지를 다룬다. Buffer Pool은 OS Memory Management와도 맞닿아 있다.

세 가지 최적화 레이어

조회 성능 문제는 DBMS 메모리 → 스토리지 I/O → 아키텍처 세 레이어에서 각각 다른 기법으로 해결한다.

flowchart TD
    A[조회 요청] --> B{Buffer Pool 히트?}
    B -- Yes --> C[메모리에서 즉시 반환]
    B -- No --> D{RAID 병렬 I/O}
    D --> E[디스크 읽기 병렬화]
    E --> C
    A2[과부하 읽기 요청] --> R{Read-Write Split}
    R -- Read --> Rep[Replica 노드]
    R -- Write --> M[Master 노드]

1. InnoDB Buffer Pool — DBMS 메모리 레이어

InnoDB가 데이터 페이지와 인덱스를 캐싱하는 메모리 영역이다. 조회 시 Buffer Pool 히트가 나면 Disk I/O 없이 메모리에서 반환된다. 히트율 99% 이상이면 Buffer Pool이 충분히 설정된 기준으로 본다.^[1]

핵심 파라미터

상태 확인 쿼리

-- 현재 크기 확인
SELECT @@innodb_buffer_pool_size / 1024 / 1024 / 1024 AS buffer_pool_gb;

-- 히트율 확인
SHOW ENGINE INNODB STATUS\G

-- 전체 InnoDB 데이터 크기 추정
SELECT CEILING(SUM(data_length + index_length) / POWER(1024, 2)) AS size_mb
FROM information_schema.tables
WHERE engine = 'InnoDB';

동적 변경 (MySQL 8.0+)

SET GLOBAL innodb_buffer_pool_size = 8589934592; -- 8GB

재시작 후 초기화되므로 my.cnf에도 반드시 병행 기록해야 한다.^[4]

LRU 구조 (캐시 교체 알고리즘)

Buffer Pool은 Young sublist와 Old sublist 두 영역으로 구성된다. 새 페이지는 Old sublist head에 삽입되고, 재접근 시 Young sublist로 승격된다. Full scan 시에는 Old에만 머물다 제거돼 Hot 페이지를 보호한다.^[5]

실패 패턴

• 물리 RAM을 초과 할당하면 OS 스왑이 발생해 성능이 급락한다.^[6]
• innodb_buffer_pool_size는 chunk × instances의 배수가 되도록 설정해야 한다.^[3:2] 배수가 아니면 MySQL이 값을 자동 조정해 의도와 다른 크기가 된다는 동작 설명은 원문에 없는 이 page의 해석이다.
• 히트율 모니터링 없이 크기를 결정하면 실제 워크로드 패턴이 반영되지 않는다.^[7]

2. RAID — 스토리지 I/O 레이어

RAID(Redundant Array of Independent Disks)는 여러 디스크를 논리적으로 묶어 병렬 I/O, 가용성, 용량을 향상시킨다. 데이터베이스에서 Disk I/O가 병목일 때 스토리지 레이어에서 병렬화로 해결하는 방법이다.^[8] (레벨별 자세한 분석은 RAID Storage Systems 참조.)

RAID 레벨 비교

RAID 10 — 프로덕션 표준

flowchart LR
    D1[(Disk 1)] --- M1[(Mirror 1)]
    D2[(Disk 2)] --- M2[(Mirror 2)]
    S[Stripe Layer] --- D1
    S --- D2
    Client --> S

RAID 1 미러 세트를 RAID 0으로 스트라이핑한다. 최소 4개 디스크가 필요하다. Parity 연산이 없어 Write Penalty가 없고, 디스크 1개 장애 시에도 데이터 보존 및 성능이 유지된다.^[10]

RAID 5 — 읽기 중심 환경의 대안

N-1개 병렬 읽기로 읽기 성능은 우수하지만, Write마다 parity 블록을 Read → 수정 → Write하는 Write Penalty(Read-Modify-Write)가 있다. 디스크 장애 시 Degraded Mode로 들어가 성능이 대폭 저하된다. MySQL 공식 문서도 OLTP 환경에서 RAID 5를 비권장한다.^[11]

실패 패턴

• RAID 0을 프로덕션 DB에 쓰면 디스크 1개 고장 시 전체가 유실된다.^[12]
• RAID 5를 쓰기 빈번한 OLTP에 쓰면 Write Penalty로 쓰기 성능이 저하된다.^[11:1]
• RAID chunk size는 InnoDB page size(기본 16KB)와 FS 설정에 맞추는 것이 권장된다.^[13] 맞추지 않으면 불필요한 I/O 오버헤드가 생긴다는 결과는 이 page의 해석이다.

추가 고려사항

Hardware RAID + BBU(배터리 백업 컨트롤러)는 쓰기 성능에 유리하다. Software RAID(mdadm)는 CPU 오버헤드가 발생해 고성능 DB에는 하드웨어 RAID가 권장된다. SSD/NVMe 환경에서도 RAID 10이 기본 권장된다.^[14]

3. Replication — 아키텍처 레이어

MySQL Replication은 Binary Log 기반으로 Source(Master)의 변경사항을 Replica들에 비동기 전달한다. Read-Write Splitting으로 읽기 부하를 수평 분산한다.^[15]

아키텍처

flowchart TD
    App[Application]
    App -- Write --> M[(Source / Master)]
    App -- Read --> LB[Load Balancer / ProxySQL]
    M -- Binary Log --> R1[(Replica 1)]
    M -- Binary Log --> R2[(Replica 2)]
    M -- Binary Log --> R3[(Replica 3 - 분석 전용)]
    LB --> R1
    LB --> R2

읽기 성능 향상 메커니즘

• 수평 읽기 확장: Replica 추가 → 읽기 처리량이 선형에 가깝게 증가.^[16]
• Master 부하 분리: 조회 트래픽이 Replica로 이동 → Master는 Write에 집중.^[17]
• 워크로드 격리: 무거운 분석 쿼리·리포팅·백업을 전용 Replica에서 처리 → OLTP 성능 보호.^[17:1]

Read-Write Splitting 구현

Replication Lag (복제 지연) — 핵심 트레이드오프

MySQL 기본 복제는 비동기다: Master 커밋 후 Replica 반영까지 지연이 발생한다. 사용자가 쓴 데이터를 즉시 Replica에서 읽으면 아직 미반영일 수 있다(Read-After-Write 문제).^[19]

Multi-Threaded Replication

-- Replica에서 병렬 적용 설정
SET GLOBAL replica_parallel_workers = 4;
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';

단일 스레드 복제는 고부하 시 지연이 쌓인다. 병렬 적용으로 Replication Lag를 최소화한다.^[20:1]

계단식 복제 (Cascading Replication)

Replica가 매우 많으면 Master의 Binary Log 전송 자체가 네트워크/I/O 병목이 된다. 중간 중계 서버(Intermediate Replica)를 두어 Master → 중계 → 최종 Replica 구조로 분산한다.^[21]

한계

• 쓰기 분산 불가: Replication은 읽기만 분산한다. 쓰기 병목은 Sharding으로 해결한다.^[22]
• 비동기 지연: 실시간 금융 등 강한 일관성 요구에는 추가 설계가 필요하다.^[22:1]

세 기법 통합 비교

레이어 적용 순서

1. Buffer Pool 먼저: 설정 하나로 가장 즉각적인 효과.
2. RAID 구성: 스토리지 교체·구성 시 RAID 10 선택.
3. Replication: 단일 서버 한계 도달 시 아키텍처 확장.

세 기법은 독립적으로 작동하므로 동시 적용 가능하다. 다만 Replication을 먼저 고려하기 전에 Buffer Pool 튜닝으로 개선 여지를 먼저 소진하는 것이 비용·복잡도 면에서 유리하다고 볼 수 있다.^[7:4]

관련

• Database System Foundation — DBMS 성능이 Disk I/O에 의해 결정된다는 원칙.
• B+ Tree 인덱싱과 순차 키 삽입 — 어떤 index page를 읽고 쓰는지가 이 페이지의 cache·storage 비용보다 앞선 접근 경로를 결정한다.
• OS Memory Management — Buffer Pool은 OS 메모리 관리와 맞닿아 있다.
• RAID Storage Systems — RAID 레벨별 상세 분석.

출처

테스트 질문

• InnoDB Buffer Pool 히트율이 95%일 때 어떻게 판단하고 어떤 조치를 취하는가?
• RAID 5와 RAID 10의 쓰기 성능 차이가 발생하는 원인은 무엇인가?
• MySQL Replication에서 Read-After-Write 문제가 발생하는 이유와 대응 방법은?
• 세 기법 중 쓰기 분산까지 해결할 수 있는 것은 무엇이며, 그 이유는?
• innodb_buffer_pool_instances를 늘리면 무엇이 개선되는가?