MySQL 대용량 데이터 처리 전략 (파티셔닝, 샤딩)

lilililililiiii 2025. 5. 5. 15:07

MySQL 대용량 데이터 처리 전략 중 파티셔닝과 샤딩을 알아보겠습니다. 데이터가 폭발적으로 증가하는 현대 환경에서, 테이블 크기가 수억 건을 넘어서면서 기존의 인덱싱 및 쿼리 튜닝만으로는 감당하기 어려운 성능 한계에 직면하는 경우가 빈번합니다. 단일 데이터베이스 서버의 물리적 제약(CPU, 메모리, 디스크 I/O)을 넘어서는 대용량 데이터를 효율적으로 관리하고 처리하기 위해서는 데이터 저장 및 접근 방식 자체에 대한 근본적인 변화가 필요합니다. 이러한 문제를 해결하기 위한 대표적인 두 가지 핵심 전략이 바로 파티셔닝(Partitioning)과 샤딩(Sharding)입니다. 파티셔닝은 하나의 거대한 테이블을 논리적인 규칙에 따라 내부적으로 여러 조각으로 나누어 관리하는 단일 데이터베이스 내의 기술이며, 샤딩은 데이터를 아예 여러 대의 독립적인 데이터베이스 서버에 분산하여 저장하는 아키텍처 수준의 접근 방식입니다. 본 글에서는 이 두 가지 대용량 데이터 처리 전략의 기본 개념과 목적, 다양한 구현 방식(RANGE, LIST, HASH 등), 그리고 각각의 명확한 장단점을 비교 분석하여, 언제 어떤 전략을 선택하는 것이 효과적인지에 대한 이해를 돕고자 합니다.

파티셔닝 (Partitioning)

개념: 하나의 논리적인 테이블을 특정 규칙(파티션 키)에 따라 여러 개의 물리적인 파티션으로 나누어 저장하는 기술입니다. 애플리케이션 입장에서는 여전히 하나의 테이블처럼 보이지만, 내부적으로는 데이터가 여러 조각으로 분산되어 관리됩니다. MySQL 자체에서 제공하는 기능입니다.
목적:
- 성능 향상: 쿼리 조건에 파티션 키가 포함되면, 전체 테이블이 아닌 특정 파티션만 스캔하여 검색 범위를 줄일 수 있습니다 (Partition Pruning).
- 관리 용이성: 파티션 단위로 데이터를 추가, 삭제, 백업, 복구하는 등의 작업을 수행하여 관리를 용이하게 할 수 있습니다. 예를 들어, 오래된 로그 데이터를 파티션 단위로 빠르게 삭제(DROP PARTITION)할 수 있습니다.

파티셔닝 종류

1. RANGE 파티셔닝: 지정된 컬럼 값의 범위를 기준으로 파티션을 나눕니다. (예: 날짜별, 연도별, ID 범위별)

CREATE TABLE sales (
    id INT AUTO_INCREMENT,
    order_date DATE NOT NULL,
    amount DECIMAL(10, 2),
    PRIMARY KEY (id, order_date) -- 파티션 키는 PK 또는 Unique Key에 포함되어야 함 (MySQL 5.6.7 이전 제약)
)
PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

2. LIST 파티셔닝: 지정된 컬럼 값이 미리 정의된 목록 중 하나에 해당하는지에 따라 파티션을 나눕니다. (예: 특정 지역 코드, 상태 코드)

CREATE TABLE customers (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    region_code INT NOT NULL
)
PARTITION BY LIST (region_code) (
    PARTITION p_east VALUES IN (1, 2, 3),
    PARTITION p_west VALUES IN (4, 5),
    PARTITION p_south VALUES IN (6, 7, 8),
    PARTITION p_north VALUES IN (9)
);

3. HASH 파티셔닝: 지정된 컬럼 값에 해시 함수를 적용한 결과에 따라 데이터를 균등하게 분배합니다. 특정 파티션에 데이터가 몰리는 것을 방지하고 로드를 분산시키는 데 목적이 있습니다.

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100)
)
PARTITION BY HASH (id)
PARTITIONS 4; -- 4개의 파티션으로 분할

4. KEY 파티셔닝: HASH 파티셔닝과 유사하지만, MySQL에서 제공하는 내부 해시 함수를 사용하며 컬럼 타입 제약이 적습니다. (PK 또는 Unique Key가 아닌 컬럼도 사용 가능)

CREATE TABLE logs (
    log_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id INT,
    log_message TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
)
PARTITION BY KEY (user_id)
PARTITIONS 8;

5. 서브파티셔닝 (Subpartitioning): 파티션을 다시 하위 파티션으로 나누는 방식입니다. (예: RANGE-HASH, LIST-RANGE 등) 더 세분화된 데이터 관리가 가능합니다.

장점
- 특정 조건의 쿼리 성능 향상 (Partition Pruning).
- 데이터 관리(삭제, 백업 등) 용이성 증대.
- 단일 서버 내에서 구현 가능.
단점
- 모든 쿼리의 성능이 향상되는 것은 아님 (파티션 키 조건이 없는 경우).
- 테이블 생성/변경 시 파티션 키 제약사항 존재 (특히 PK 관련).
- 파티션 수가 너무 많아지면 관리 오버헤드 증가 및 성능 저하 가능성.
- 단일 서버의 I/O, CPU, 메모리 한계를 넘어서는 확장성에는 한계가 있음.

샤딩 (Sharding)

개념: 매우 큰 데이터셋이나 워크로드를 여러 개의 독립적인 데이터베이스 서버(샤드, Shard)에 수평적으로 분산하여 저장하고 처리하는 기술입니다. 각 샤드는 동일한 스키마를 가지지만, 서로 다른 데이터 조각을 담당합니다. 파티셔닝이 단일 DB 서버 내에서의 분할이라면, 샤딩은 여러 DB 서버로의 분산입니다. MySQL 자체 기능이 아니라 애플리케이션 레벨이나 별도의 미들웨어/솔루션을 통해 구현됩니다.
목적
- 수평적 확장성 (Horizontal Scalability): 단일 서버의 물리적 한계를 넘어 시스템 전체의 저장 용량과 처리 능력을 확장할 수 있습니다.
- 부하 분산 (Load Balancing): 읽기/쓰기 부하를 여러 서버로 분산하여 단일 서버 병목 현상을 해소합니다.
- 고가용성 향상: 일부 샤드에 장애가 발생하더라도 전체 서비스 중단 없이 다른 샤드는 정상 작동할 수 있습니다.
샤딩 방식 (샤드 키 선정 및 데이터 분배)
- Range Based Sharding: 특정 키 값의 범위를 기준으로 샤드를 분할합니다. (파티셔닝의 RANGE와 유사) 관리는 용이하지만 특정 범위에 데이터가 몰릴 수 있습니다.
- Hash Based Sharding: 키 값에 해시 함수를 적용하여 데이터를 각 샤드에 분산시킵니다. 데이터 분산은 비교적 균등하지만, 특정 범위 검색이 어려울 수 있습니다.
- Directory Based Sharding: 별도의 조회 테이블(Lookup Table)을 두어 어떤 키가 어떤 샤드에 있는지 매핑 정보를 관리합니다. 유연성은 높지만, 조회 테이블이 병목 지점이 되거나 단일 실패 지점(SPOF)이 될 수 있습니다.
장점
- 뛰어난 수평적 확장성 (Scale-out).
- 높은 처리량 및 부하 분산 효과.
- 고가용성 구성에 유리.
단점
- 구현 복잡성: 애플리케이션 로직 수정, 샤딩 미들웨어 도입 등 구현 및 관리가 복잡합니다.
- 데이터 재분배(Rebalancing) 어려움: 샤드 추가/삭제 시 데이터를 재분배하는 작업이 복잡하고 서비스 영향이 클 수 있습니다.
- 여러 샤드에 걸친 쿼리/트랜잭션 처리 어려움: 여러 샤드의 데이터를 조인하거나 하나의 트랜잭션으로 묶는 작업이 복잡하고 성능 저하를 유발할 수 있습니다. (Distributed Transactions)
- 데이터 일관성 유지 어려움: 여러 서버에 데이터가 분산되므로 일관성을 유지하기 위한 추가적인 노력이 필요합니다.

파티셔닝 vs. 샤딩

구분	파티셔닝 (Partitioning)	샤딩 (Sharding)
개념	단일 DB 서버 내에서 테이블을 논리적으로 분할	여러 DB 서버에 데이터를 수평적으로 분산
수준	데이터베이스 (MySQL 기능)	아키텍처 (애플리케이션/미들웨어 구현)
목표	성능 향상, 관리 용이성	확장성, 부하 분산, 고가용성
확장성	수직적 확장 (Scale-up) 한계 내	수평적 확장 (Scale-out) 가능
구현 복잡도	상대적으로 낮음	높음
쿼리/트랜잭션	단일 DB 내에서 처리 (투명함)	여러 샤드에 걸칠 경우 복잡 (분산 트랜잭션 필요)

파티셔닝과 샤딩은 대규모 데이터셋을 효과적으로 관리하기 위한 필수 전략이지만, 그 적용 범위와 목적에서 명확한 차이를 보입니다. 파티셔닝은 MySQL 자체 기능을 활용하여 단일 데이터베이스 서버 내에서 큰 테이블을 관리 가능한 작은 단위로 분할하는 기술입니다. 이는 파티션 키를 활용한 쿼리 성능 개선(Partition Pruning)과 파티션 단위의 데이터 관리(백업, 삭제 등) 용이성 증대에 주된 목적을 두며, 구현이 비교적 간단하다는 장점이 있습니다. 하지만 단일 서버의 물리적 한계를 넘어서는 확장성을 제공하지는 못합니다.

반면, 샤딩은 데이터와 워크로드를 여러 독립적인 데이터베이스 서버로 분산시키는 아키텍처 수준의 접근 방식입니다. 주된 목표는 단일 서버의 한계를 뛰어넘는 수평적 확장성(Scale-out) 확보, 부하 분산, 그리고 고가용성 향상에 있습니다. 이를 통해 시스템 전체의 처리 용량을 크게 늘릴 수 있지만, 애플리케이션 레벨에서의 구현 복잡성 증가, 여러 샤드에 걸친 쿼리 및 트랜잭션 처리의 어려움, 데이터 재분배(Rebalancing)의 복잡성 등 관리 및 운영 측면에서 상당한 비용과 노력이 요구됩니다.

결론적으로, 어떤 전략을 선택할지는 당면한 문제의 성격에 따라 달라집니다. 단일 서버 내에서 특정 쿼리의 성능을 개선하거나 대용량 테이블의 관리 효율성을 높이는 것이 주 목적이라면 파티셔닝이 적합한 해결책이 될 수 있습니다. 그러나 데이터 규모나 트래픽이 단일 서버의 용량을 초과하여 시스템 전체의 확장성과 가용성 확보가 필요하다면, 더 복잡하지만 강력한 확장성을 제공하는 샤딩을 고려해야 합니다. 실제 시스템 설계 시에는 데이터의 특성, 증가 추세, 쿼리 패턴, 가용성 요구사항, 그리고 운영 복잡성에 대한 감내 수준 등을 종합적으로 평가하여 최적의 전략을 선택하거나, 때로는 두 가지 전략을 조합하여 사용하는 방안도 고려해야 할 것입니다.