데이터 중심 애플리케이션 설계06

---

파티셔닝

파티셔닝 개요

파티셔닝의 정의와 목적

파티셔닝(Partitioning)은 대규모 데이터셋을 여러 작은 부분집합으로 나누어 여러 노드에 분산 저장하는 기술입니다. 이는 단일 머신으로는 처리하기 어려운 대규모 데이터나 높은 쿼리 처리량을 효과적으로 관리하기 위한 핵심 전략입니다.

주요 목적:

• 확장성: 데이터와 쿼리 부하를 여러 노드에 분산하여 시스템 전체 성능 향상
• 성능 향상: 병렬 처리를 통한 처리량 증가
• 가용성: 특정 노드 장애 시에도 다른 파티션은 정상 작동

용어 정리

동일한 개념이 시스템마다 다른 용어로 불립니다:

• 샤드(Shard): MongoDB, Elasticsearch, SolrCloud
• 리전(Region): HBase
• 태블릿(Tablet): Bigtable
• vnode: Cassandra, Riak
• vBucket: Couchbase
• 일반적으로 파티셔닝 / 샤드라 함

복제(Replication)와의 관계

파티셔닝은 일반적으로 복제와 함께 사용됩니다:

• 각 파티션은 여러 노드에 복제되어 내결함성 제공
• 각 노드는 특정 파티션의 리더이면서 다른 파티션의 팔로워 역할 수행
• 파티셔닝 방식과 복제 방식의 선택은 대체로 독립적

키-값 데이터의 파티셔닝 방식

키 범위 파티셔닝 (Key Range Partitioning)

작동 원리

• 키를 정렬하여 연속된 키 범위를 각 파티션에 할당
• 백과사전의 권 구분과 유사한 방식
• Bigtable, HBase, RethinkDB, MongoDB(2.4 이전) 등에서 사용

장점

• 효율적인 범위 쿼리: 연속된 키를 순차적으로 읽을 수 있어 범위 검색이 빠름
• 정렬된 순서 유지: 데이터가 키 순서대로 저장되어 순차 스캔 효율적

단점과 해결책

• 핫스팟 문제: 특정 키 범위에 부하가 집중될 수 있음
  • 예시: 센서에서 타임스탬프 키 사용 시 ‘오늘’ 파티션에 모든 쓰기 집중
  • 해결책: 키의 첫 번째 요소로 센서 ID 등을 추가하여 부하 분산

키 해시 파티셔닝 (Partitioning by Hash of Key)

작동 원리

• 키에 해시 함수(MD5, Murmur3 등) 적용
• 해시 값의 범위에 따라 파티션 할당
• Cassandra, MongoDB(2.4 이후 옵션), Voldemort 등에서 사용

장점

• 균등한 데이터 분산: 해시 함수가 키를 무작위로 분산시켜 핫스팟 감소
• 부하 균형: 각 파티션이 비슷한 양의 데이터 처리

단점

• 범위 쿼리 비효율: 인접한 키가 다른 파티션에 분산되어 모든 파티션 스캔 필요
• 정렬 순서 상실: 키의 원래 순서 정보 손실

일관된 해싱 (Consistent Hashing)

일관된 해싱은 데이터 객체와 노드를 가상 링 구조(해시 링)에 위치시켜 작동하는 분산 시스템 기술입니다. 이는 노드 추가/제거 시 재분배되는 데이터를 최소화합니다.

작동 원리

1. 해시 함수의 출력 범위를 원형 링으로 표현
2. 노드와 키를 모두 동일한 해시 함수로 해싱하여 링 위에 배치
3. 키는 시계 방향으로 가장 가까운 노드에 할당

가상 노드 (Virtual Nodes)

각 물리 서버를 여러 가상 노드로 표현하여 링 위에 여러 위치를 차지하게 함으로써 데이터를 더 균등하게 분산시킵니다. 즉 10개의 서버지만 노드가 100 개 있는 식으로 취급

장점:

• 노드 장애 시 부하가 여러 노드로 분산
• 노드 용량에 따라 가상 노드 수 조정 가능
• 표준편차가 평균의 5-10% 수준으로 균등 분산 달성

핫 키(Hot Key) 문제 해결

특정 키(예: 유명인의 사용자 ID)에 대한 요청이 폭증하는 경우:

해결 방법:

1. 키 분할: 핫 키에 임의의 숫자(1~100) 추가하여 여러 파티션으로 분산
2. 읽기 시 집계: 모든 분할된 키에서 데이터를 읽어 결합
3. 애플리케이션 레벨 관리: 핫 키 목록을 별도로 관리하여 특별 처리

보조 인덱스 파티셔닝

문서 기반 보조 인덱스 (Local Index)

특징

• 각 파티션이 자체 보조 인덱스 유지
• 인덱스는 해당 파티션의 문서만 포함

장점

• 쓰기 효율성: 단일 파티션만 업데이트하면 됨
• 트랜잭션 단순성: 로컬 트랜잭션으로 처리 가능

단점

• 읽기 비효율: 보조 인덱스를 사용한 쿼리 시 모든 파티션 검색 필요 (scatter/gather)
• 꼬리 지연 증폭: 가장 느린 파티션이 전체 쿼리 속도 결정

용어 기반 보조 인덱스 (Global Index)

특징

• 인덱스 자체가 파티셔닝됨
• 특정 용어의 모든 항목이 동일한 인덱스 파티션에 저장

장점

• 읽기 효율성: 단일 인덱스 파티션에서 쿼리 처리 가능
• 범위 쿼리 지원: 인덱스를 용어 범위로 파티셔닝하면 범위 검색 가능

단점

• 쓰기 복잡성: 여러 인덱스 파티션 업데이트 필요
• 일관성 문제: 비동기 업데이트 시 일시적 불일치 가능
• 분산 트랜잭션: 동기 업데이트 시 분산 트랜잭션 필요

파티션 리밸런싱 (Rebalancing)

리밸런싱이 필요한 상황

• 쿼리 처리량 증가로 CPU 추가 필요
• 데이터셋 크기 증가로 디스크와 RAM 추가 필요
• 노드 장애로 다른 노드가 역할 인계
• 부하 불균형 해소

리밸런싱 전략

고정된 수의 파티션

작동 방식:

• 노드 수보다 훨씬 많은 파티션을 미리 생성 (예: 노드당 100~1000개)
• 노드 추가 시 기존 노드들로부터 일부 파티션을 균등하게 이동
• Riak, Elasticsearch, Couchbase, Voldemort에서 사용

장점:

• 파티션 이동만으로 리밸런싱 완료
• 운영 단순성

단점:

• 초기 파티션 수 결정이 중요
• 파티션 수 변경 불가

동적 파티셔닝

작동 방식:

• 파티션 크기가 임계값을 초과하면 자동 분할
• 파티션이 너무 작아지면 인접 파티션과 병합
• HBase, RethinkDB, MongoDB에서 사용

장점:

• 데이터 양에 따라 파티션 수 자동 조정
• 초기 설정 부담 감소

단점:

• 빈 데이터베이스는 단일 파티션으로 시작 (핫스팟 가능)
• 사전 분할(pre-splitting)로 해결 가능

노드 비례 파티셔닝

작동 방식:

• 노드당 고정된 수의 파티션 유지
• 노드 추가 시 기존 파티션을 무작위로 분할하여 절반 이동
• Cassandra, Ketama에서 사용

장점:

• 노드 수 증가에 따라 파티션 크기 안정적 유지
• 데이터 양과 무관하게 일정한 성능

자동 vs 수동 리밸런싱

자동 리밸런싱:

• 장점: 운영 부담 감소, 빠른 대응
• 단점: 예측 불가능성, 네트워크 부하 급증 가능

수동 리밸런싱:

• 장점: 예측 가능한 운영, 세밀한 제어
• 단점: 운영 부담 증가, 대응 지연 가능

하이브리드 접근:

• 시스템이 파티션 할당을 제안하고 관리자가 승인
• Couchbase에서 채택

요청 라우팅 (Request Routing)

라우팅 방식

파티션이 리밸런싱되면 어떤 노드가 어떤 파티션을 담당하는지 추적 필요:

1. 클라이언트가 임의 노드에 연결
   • 노드가 요청을 올바른 노드로 전달
   • 단순하지만 추가 홉(hop) 발생
2. 라우팅 계층 사용
   • 별도의 라우팅 티어가 파티션 정보 관리
   • 클라이언트는 라우팅 계층에만 연결
3. 클라이언트가 파티션 정보 인식
   • 클라이언트가 직접 올바른 노드에 연결
   • 가장 효율적이지만 클라이언트 복잡도 증가

클러스터 메타데이터 관리

주키퍼(ZooKeeper) 사용:

• HBase, SolrCloud, Kafka 등에서 채택
• 파티션과 노드 매핑 정보를 중앙 관리
• 변경 사항을 구독자에게 알림

가십 프로토콜(Gossip Protocol):

• Cassandra, Riak에서 사용
• 노드 간 P2P 방식으로 클러스터 상태 정보 전파
• 중앙 조정자 없이 작동

병렬 쿼리 실행

대규모 병렬 처리 (MPP)

파티셔닝된 데이터베이스에서 복잡한 쿼리 처리:

• 여러 파티션의 데이터를 결합하는 조인 연산
• 그룹화, 집계, 정렬 등의 분석 쿼리
• 각 노드에서 부분 처리 후 결과 병합

성능 고려사항

• 데이터 지역성: 관련 데이터를 같은 파티션에 배치
• 브로드캐스트 조인: 작은 테이블을 모든 노드에 복제
• 파티션 프루닝: 불필요한 파티션 스캔 회피

실무 적용 시 고려사항

파티셔닝 전략 선택 기준

키 범위 파티셔닝 선택:

• 범위 쿼리가 중요한 경우
• 데이터에 자연스러운 순서가 있는 경우
• 시계열 데이터 (단, 핫스팟 주의)

해시 파티셔닝 선택:

• 균등한 부하 분산이 중요한 경우
• 범위 쿼리가 필요 없는 경우
• 핫스팟을 피하고 싶은 경우

파티션 크기 설계

• 너무 큰 파티션: 리밸런싱 비용 증가, 병렬성 감소
• 너무 작은 파티션: 메타데이터 오버헤드 증가
• 권장사항: 수 GB ~ 수십 GB 범위

모니터링과 운영

모니터링 지표:

• 파티션별 데이터 크기
• 파티션별 쿼리 부하
• 리밸런싱 빈도와 소요 시간
• 핫스팟 발생 여부

운영 베스트 프랙티스:

• 정기적인 부하 분석
• 점진적인 리밸런싱
• 백업과 복구 계획 수립
• 파티션 키 설계 문서화

주요 시스템별 구현 사례

MongoDB

• 키 범위와 해시 파티셔닝 모두 지원
• 동적 파티셔닝으로 자동 분할
• mongos 라우터를 통한 투명한 샤딩

Cassandra

• 일관된 해싱과 가상 노드 사용
• 노드당 기본 256개 가상 노드
• 가십 프로토콜로 클러스터 상태 관리

HBase

• 키 범위 파티셔닝 (리전)
• 자동 리전 분할과 병합
• 주키퍼를 통한 메타데이터 관리

Amazon DynamoDB

• 일관된 해싱을 사용하여 데이터셋을 동적으로 파티셔닝
• 가상 노드로 부하 균형
• 자동 스케일링 지원