☁️Cloud/Alibaba

Alibaba Cloud: PolarDB-X의 샤딩과 분산 처리 개념

Diven 2026. 3. 28. 16:06

DB를 여러조각(샤드//파티션)으로 나눠 여러 노드에 분산 저장해서, 읽기뿐 아니라 ‘쓰기까지’ 수평 확장하는 분산 SQB DB 입니다.

‘샤딩’이 들어가는 이유

  • 복제 : 같은 데이터를 여러 개로 “복사” → 읽기 분산/장애 대비에 좋음
  • 샤딩 : 데이터를 여러 조각으로 “분할” → 용량 + 쓰기 처리량 까지 여러 노드로 분산

PolarDB-X는 보통 샤딩(분할)을 하고, 그 각 조각을 또 Paxos 기반 다중 복제로 저장해서 장애에 대비합니다.

‘PolarDB-X’ 에서의 리더

PolarDB-X는 계층이 나뉘어 있어서, 어디에 리더가 있는지가 핵심

앱이 붙는 입구(CN)는 “리더가 없다”에 가까움

  • CN는 stateless SQL 엔진(파서/옵티마이저/실행기)
  • 그래서 어느 CN으로 접속해도 read/write SQL을 받을 수 있고, CN이 알아서 해당 파티션에 있는 DN으로 라우팅함.

데이터가 실제로 저장되는 쪽(DN의 복제그룹)에는 “리더가 있음”

  • DN(Data Node)는 실제 데이터를 저장하고, Paxos(X-Paxos)기반으로 leader/follower/learner 같은 역할이 존재함
  • 특히 Paxos는 leader 기반이라 “쓰기”는 기본적으로 해당 그룹의 leader가 중심이 됩니다.

샤딩: 장애가 날 경우 데이터 손실 여부

이러한 상황을 막기 위해 샤딩 + 복제를 같이 씁니다.

  • 파티션(샤드) 하나가 한 DB에만 있는 게 아니라, Paxos 다중 복제본으로 여러 노드에 존재
  • leader가 죽으면 남은 복제본 중에서 새 leader 선출로 계속 서비스(다수결 기반)

분산 트랜잭션은 어떻게 되나?

PolarDB-X는 분산 환경에서도 트랜잭션 일관성을 위해

  • TSO(전역 타임스탬프) + MVCC로 스냅샷 일관성 유지
  • 여러 파티션을 건드릴 떄 2PC로 원자성(ACID)을 맞추는 구조로 설명

샤딩을 직접 설계 해야하는가?

  • 시작은 자동도 가능(Auto 자동 파티셔닝)
    • 테이블 생성 시 파티션 키를 안주면 PK(또는 암묵 PK) + KEY 파티셔닝으로 자동 분산 됩니다.
    • 기본 파티션 개수도 논리 노드 수 x 8 같은 기본 규칙이 있습니다.
  • 트래픽이 커지면 “잘” 나누는 설계가 성능을 좌우
    • 파티셔닝은 RANGE/LIST/HASH 등 규칙과 Partition Key 지정이 핵심이고, 큰 테이블에 서 중요합니다.
    • Join이 많은 서비스면, 관련 테이블을 같은 파티션 키로 맞춰서 Partition-wise join / pushdown을 유도하는게 유리합니다.

사용법: 콘솔에서 운영 까지 최소 루트

아래는 “처음 도입”할 때 가장 흔한 흐름이에요.

Step 1) 인스턴스 만들고 네트워크 준비

  • 접속 전 필수: Whitelist(허용 IP) 설정
  • 온프레/외부에서 붙으면 Public Endpoint를 쓰되, 성능/보안 이유로 VPC 내부 접속을 권장하는 안내가 있습니다.

Step 2) 계정/DB 생성

  • 콘솔에서 DB 생성 절차가 정리돼 있습니다.
  • 이후 계정 만들고 권한 부여(콘솔 흐름은 “계정 생성 → DB 로그인” 순으로 안내).

Step 3) 연결(애플리케이션/클라이언트)

  • PolarDB-X는 MySQL 생태계(클라이언트/문법) 호환을 전제로 연결 가이드를 제공합니다.

예시(개념용):

mysql -h <endpoint> -P <port> -u <user> -p

Step 4) 테이블 만들기 — 처음엔 AUTO로 시작해도 됨

  • 먼저 “일반 MySQL처럼” 테이블을 만들고, 자동 파티셔닝을 활용할 수 있습니다.
  • 이후 병목이 보이면 파티션 키/규칙을 명시적으로 조정하는 방식이 자연스럽습니다.

Step 5) 테이블 타입(중요): single / broadcast / partitioned

  • 큰 트랜잭션 테이블은 partitioned
  • 작은 코드/참조 테이블은 broadcast
  • 특정 테이블은 single로 두는 식으로 조합하고, 필요하면 타입/파티션 규칙 변경도 지원합니다.

운영: 이럴 때 PolarDB-X가 진짜 필요해진다.

  • 읽기만이 아니라 쓰기까지 계속 커져서 “한 Primary에 쓰기 몰림”이 구조적으로 버거운 구간
  • 초대용량/초고동시성에서 스케일-아웃이 우선인 서비스 → PolarDB-X의 방향성이 딱 맞습니다.
저작자표시 비영리 변경금지 (새창열림)