MySQL ‐ MySQL Horizontal Scaling - thought-corner/Backend-PlayGround GitHub Wiki

MySQL - MySQL Horizontal Scaling

Replication & Distribution

쓰기 경로 : Client → Master DB → Binary Log → Replica DB ← Relay Log

클라이언트가 INSERT, DELETE, UPDATE같은 쓰기 요청을 보낸다.
Master DB가 해당 트랜잭션을 처리하고 커밋한다.
변경 사항을 Binary Log에 기록한다. → 이 때, Binary Log는 Master의 모든 변경 이벤트를 기록한다.
Replica가 Binary Log를 읽어 Relay Log에 저장한다. → 이 때, Relay Log는 Master의 Binary Log를 Replica에서 임시 저장하고 SQL Thread가 소비하게 된다.
Replica의 SQL Thread가 Relay Log를 재실행해서 Replica DB에 반영한다.

읽기 경로 : Client → Replica DB

Client는 읽기 요청(SELECT)을 직접 Replica DB로 보낸다.

설계 관점에서 주의할 점

🔴Replication Lag(복제 지연)

네트워크 지연, Master - Replica 간 대역폭, 노드 간 물리적 거리에 의한 요인으로 발생한다.

Master 커밋 → Replica 반영까지 비동기 갭이 존재한다.

쓰기 직후 상황에서 데이터를 읽게 되면 데이터의 일관성이 보장되기 어려울 수 있다.

🔴Replica 단일 장애점

Replica가 1대인 경우 읽기 가용성이 저하될 우려가 있기 때문에 다중 Replica를 구성하는 것을 권장한다.

Master 장애 시 자동 Failover 메커니즘이 필요하다.

Partitioning & Sharding

Application : 직접 샤딩 키를 계산 후 DataSource를 선택한다.
ProxySQL : SQL 파싱 후 쿼리 라우팅을 한다.
Vitess : MySQL 클러스터 전체를 추상화, 쟈동 리샤딩을 지원한다.
DB Server 1/2 : 각각 독립된 스키마와 데이터르 가진다.

설계 관점에서 주의할 점

🔴Modulo 샤딩의 리샤딩 문제

운영하는 서버를 늘리는 순간 거의 모든 데이터가 이동해야 한다.

이렇게 되면 리샤딩이 매우 위험해지며 이 때문에 권장되지 않는다.

🔴Cross Shard 쿼리 불가

-- user_id IN (123, 124) → Server 1, Server 2 동시 조회 필요
SELECT * FROM users WHERE user_id IN (123, 124)

-- 집계 쿼리도 불가
SELECT COUNT(*) FROM users

🟡샤딩 키 설계 중요성

Hot Shard : 특정 샤드에 데이터가 쏠릴 우려가 있다.

🟡트랜잭션 범위 제한

샤드를 넘나드는 분산 트랜잭션은 기본적으로 2PC(Two-Phase Commit)나 SAGA 패턴으로 해결해야 하는데 이게 설계의 복잡도를 크게 높이게 된다.

Data Archive/Compression

-- 압축 기능을 활성화하여 테이블 생성
CREATE TABLE logs_compressed (
     log_id BIGINT AUTO_INCREMENT PRIMARY KEY,
     user_id INT,
     message TEXT,
     created_at TIMESTAMP
)
    ROW_FORMAT=COMPRESSED
    KEY_BLOCK_SIZE=8; -- 페이지 압축 후 목표 크기 (KB). 4, 8, 16 등.

설계 관점에서 주의할 점

🔴CPU vs Disk 트레이드오프

압축은 Disk I/O 절감 ↔ CPU 사용량 증가의 트레이드오프이다.

압축은 I/O Bound, 로그성 테이블 등에 유리하지만 CPU Bound, 빈번한 DB I/O, 고빈도 쓰기 작업의 경우 압축은 불리하다.

🔴Buffer Pool 효율 저하 가능성

압축 해제된 페이지와 압축 페이지를 둘 다 들고 있으면 같은 데이터가 Buffer Pool을 두 배로 점유할 수 있다.

메모리가 넉넉하지 않은 환경에서는 오히려 Buffer Pool Hit Rate가 떨어지는 역효과가 발생할 수 있다.

🟡압축 비율이 예측 불가능

데이터 특성에 따라 압축률이 크게 다르다.

텍스트/JSON과 같은 컬럼 많은 테이블의 경우 압축률이 높아져 절감이 가능하나 이미 압축된 BLOB, 숫자 위주의 경우 압축률 효과가 미미하고 오히려 CPU만 낭비될 수 있다.

🟡KEY_BLOCK_SIZE 설정이 중요

너무 작은 값으로 설정하면 한 페이지에 데이터가 안 맞아서 압축 실패 → 분할 → 용량 증가 현상이 발생할 수 있다.