데이터중심 애플리케이션 설계 - 6장 [파티셔닝] 리뷰 - 3

 

이번 포스팅에서는 6장에서의 3번째 주제 파티션 재균형화에 대해 리뷰한다.

 

파티션 재균형화 

재균형화(Rebalancing)  : 특정 노드에 대한 데이터와 요청을 다른 노드로 옮기는 과정 

 

• 재균형화에 대한 요구사항 
  1. 재균형화 이후에는 부하가 클러스터의 노드들에 대해 균등하게 분배 
  2. 재균형화 도중에도 DB에 read/write 요청이 가능해야함 
  3. 재균형화는 빠르게 실행되어야하며, 네트워크, 디스크 I/O 부하를 최소화할 수 있도록 노드간의 데이터 이동은 최소로 이동 

 

 

파티션 리벨런싱 전략 

사용하면 안되는 방법 : 해시값에 mod N 연산 실행 
문제점 : 노드 개수 N 이 바뀌면, 대부분의 키의 위치가 노드 사이에서 옮겨진다. 
즉, 필요이상의 데이터가 이동하게 되므로 리벨런싱 비용이 너무 많아짐 

 

# 파티션 개수 고정 전략 

 

파티션의 크기에 따라 전체 데이터셋의 크기가 바뀐다고 이해하면 된다. 

• 파티션을 노드 대수보다 많이 만들어 각 노드에 여러 파티션을 할당한다. 
• 이 때 노드 추가/제거 시, 기존 노드에서 파티션을 뺏어오거나, 반대로 주면 된다. 

• 특징 :
  • 대부분 첫 파티션 수 설정 - 사용 가능한 노드 수의 최대치 
    
  • 이 때 파티션의 크기가 너무 작으면 오버헤드가 커지고,
    파티션의 크기가 너무 크면 리벨런싱 과정과 노드 장애 복구에 대해 비용이 크다 
• 장점  : 노드에서의 파티션 이동만 있으므로, 파티션의 개수 변화 X, 파티션에 할당된 키의 위치 변화 X 
  (= 파티션이 어느 노드에 할당되는가) 
• 단점 : 파티션 수가 고정이므로, 데이터셋 크기 변동이 잦을 경우 - 적절한 파티션 수 지정이 어렵다 

 

 

# 동적 파티셔닝 

앞선 포스팅에서 설명한 키 범위 파티셔닝에서 파티션 경계와 개수가 고정이 되어있다면 굉장히 불편하다 
만약 파티션 경계를 잘못 지정시, 모든 데이터가 한 파티션에 저장될 수 있다.
따라서 이 경우에는 경계를 수동으로 재설정해줘야한다...

이 때문에 HBase, 리싱크DB 에서는 키 범위 파티셔닝에 대해 동적 파티셔닝을 사용한다. 

파티션 개수 고정 전략과 달리, 파티션의 개수가 전체 데이터셋 용량에 맞춰진다.  

• 파티션의 크기가 설정된 값을 넘어서면 split 
• 파티션 크기가 일정 값 아래로 떨어지면 인접한 파티션과 merge (like B-Tree)

 

초기 빈 DB에는 파티션의 경계를 정하는 사전 정보가 없으므로, 파티션이 한 개
(즉, 모든 요청은 하나의 노드에서만, 다른 노드는 idle 상태)

• 이에 대한 해결책으로 빈 DB에 초기 파티션 집합 설정(사전 분할(pre-splitting))을 할 수 있게 한다 ex) MongoDB, HBase

• 장점 : 데이터의 양이 작으면 파티션 개수를 적게 운용 -> 오버헤드 작음 (데이터 양이 거대해지면 개별 파티션의 크기는 설정된 max 값) 
• 단점 : 시작 시에는 데이터가 없어, 파티션이 한 개 

 

 

 

# 노드 비례 파티셔닝 

 

노드당 할당되는 파티션 개수를 고정 (=파티션의 개수가 노드 대수에 비례하도록) 

• 노드 대수 변함없을 때 - 개별 파티션의 크기는 데이터셋 크기에 비례(노드 대수가 그대로이므로, 파티션 개수도 고정)
• 노드 대수를 증가시킬 때 - 개별 파티션의 크기는 작아짐 (증가된 노드에 할당) 

• 장점 : 개별 파티션 크기가 안정적
• 단점 : 신규 노드 추가로 인한 파티션 분할 시 무작위 분할 => 균등하지 않은 분할 가능성

물론 여러 파티션에 대하여 평균적으로 기존 노드의 부하를 새로운 노드가 균등하게 할당된다. 

 

운영 : 자동 리벨런싱 / 수동 리벨런싱 

리벨런싱 : 요청 경로 재설정 + 대량의 데이터 노드간 이동 = 오버헤드가 큰 연산 

 

자동 리벨런싱 : 편의성 / 예측 hard + 성능저하이슈 및 연쇄 장애 가능성 주의 

수동 리벨런싱 : 사람의 개입을 통해 이슈 핸들링 가능 / 느림

 

 

요청 라우팅

Service DIscovery :

 

파티션 리벨런싱에 의해 노드에 할당되는 파티션이 바뀐다면, Client에서 요청을 보내려고 할 때 어느 노드로 접속해야 하는 지 아는 방법 

 

# 1 - 각 노드에 파티션의 위치 정보가 존재 :

• 클라이언트는 아무 노드에 접속(ex_ RR)하여 파티션이 위치한 노드에 요청을 전달

#2 - 라우팅 계층에 파티션의 위치 정보가 존재 

• 클라이언트의 모든 요청을 라우팅 계층으로 먼저 보내고, 라우팅 계층에서는 해당 노드로 요청을 전달한다
  (라우팅 계층 자체는 파티션 인지(partition-aware) 로드밸런서로 동작)

# 3 - 클라이언트가 파티셔닝 방법과 어떤 노드에 할당되어있는지 알고 있도록 하여, 직접 노드로 요청 

 

 

결국 핵심적인 문제는 노드의 할당된 파티션의 변경 사항을 어떻게 알 것인가 

• 외부에 별도 코디네이션을 사용하여 변경사항에 모든 것을 관리 (ex_ 아파치 Zookeeper) 

 

 

 

• 가십 프로토콜(gossip protocol)을 통해 클러스터 상태 변화를 노드 사이에 퍼트림 
  • DB의 복잡성은 증가하지만, 외부 코디네이션 서비스에 의존적이지 않음 

 

병렬 질의 실행 

 

분석용으로 사용하는 대규모 병렬 처리(massively parallel processing, MPP) : RDB에서 지원 

• MPP 질의 최적화기가 복잡한 질의를 분해하여, 클러스터내의 각 노드에서 병렬적으로 실행을 가능하게 한다. 
  • join / filter / grouping / agg 연산