본문 바로가기
스터디/데이터 중심 애플리케이션 설계

[데이터 중심 애플리케이션 설계] 06. 파티셔닝

by 디토20 2023. 1. 2.
반응형

 

 

 

 

 

[데이터 중심 애플리케이션 설계] 06. 파티셔닝

1. 복제 VS 파티셔닝

복제

  • 동일한 데이터 복사본 여러 개를 다른 노드에 저장

파티셔닝

  • 데이터셋이 매우 크거나 질의 처리량이 매우 높아 복제만으로는 부족할 때
  • 데이터를 파티션으로 나누어 저장 (= 샤딩)

복제와 파티셔닝의 혼합

  • 보통 복제와 파티셔닝을 함께 적용해 각 파티션의 복사본을 여러 노드에 저장한다.
    • 각 레코드는 정확히 한 파티션에 속하더라도 이를 여러 다른 노드에 저장해서 내결함성을 보장할 수 있다.
  • 한 노드에 여러 파티션을 저장할 수도 있다.
  • 리더 팔로워 복제 모델의 파티셔닝과 복제의 조합
  • 각 파티션의 리더는 하나의 노드에 할당되고 팔로워들은 다른 노드에 할당된다.
  • 각 노드는 어떤 파티션에게는 리더이면서 다른 파티션에게는 팔로워가 된다.

2. 키-값 데이터 파티셔닝

  • 파티셔닝의 목적은 데이터와 질의 부하를 노드 사이에 고르게 분산시키는 것
  • 파티셔닝이 고르게 이뤄지지 않아 데이터가 많거나 질의를 많이 받는 파티션이 있다면 쏠렸다고 한다.
  • 불균형하게 부하가 높은 파티션을 핫스팟 이라고 부름

핫스팟을 회피하는 가장 단순한 방법

  • 레코드를 할당할 노드를 무작위로 선택하는 것
  •  데이터가 노드 사이에 매우 고르게 분산된다.
  • 그러나 조회 시 해당 레코드가 어느 노드에 저장됐는지 알 수 없으므로 모든 노드에서 병렬적으로 질의를 실행해야 함

더 좋은 키-값 데이터 모델

  • 항상 기본키를 통해 레코드에 접근한다.
  • 모든 항목이 키로 정렬되어 있으므로 빠른 조회 가능

2.1 키 범위 기준 파티셔닝

  • 각 파티션에 연속된 범위의 키를 할당하는 것이다.
  • 각 범위들 사이의 경계를 알면 어떤 키가 어느 파티션에 속하는지 쉽게 찾을 수 있다.
  • 어떤 파티션이 어느 노드에 할당됐는지 알면 적절한 노드로 요청을 직접 보낼 수 있다.
  • 데이커가 고르게 분포하지 않을 수 있기 때문에 키 범위 크기가 반드시 동일 할 필요는 없음.

키 범위 기준 파티셔닝의 장점

  • 각 파티션 내에서는 키를 정렬된 순서로 저장할 수 있다.
  • 이렇게 하면 범위 스캔이 쉬워지는 이점이 있고, 키를 연쇄된 색인으로 간주해서 질의 하나로 관련 레코드 여러 개를 읽어오는 데 사용할 수 있다.

키 범위 기준 파티셔닝의 단점

  • 특정한 접근 패턴이 핫스팟을 유발하는 단점이 있음

2.2 키의 해시값 기준 파티셔닝

  • 쏠림과 핫스팟의 위험 때문에 많은 분산 데이터 스토어는 키의 파티션을 정하는 데 해시 함수를 사용한다.
  • 키에 적합한 해시 함수를 구했다면 각 파티션에 해시 값 범위를 할당하고, 해시 값이 파티션의 범위에 속하는 모든 키를 그 파티션에 할당하면 된다.

장점

  • 키를 파티션 사이에 균일하게 분산시키는 데 좋음.
  • 파티션 경계는 크기가 동일하도록 나눌 수도 있고 무작위에 가깝게 선택할 수 있다. (일관성 해싱이라고 부름)

단점

  • 범위 질의를 효율적으로 실행할 수 없음.
  • 정렬 순서가 유지되지 않는다.

2.3 쏠린 작업부하와 핫스팟 완화

  •  
  • 키를 해싱해서 파티션을 정하면 핫스팟을 줄이는 데 도움이 되지만 완벽히 핫스팟을 제거할 수는 없다.
  • 애플리케이션에서 쏠림을 완화해야 한다. (예를 들어 요청이 매우 많이 쏠리는 키를 발견했을 때 각 키의 시작이나 끝에 임의의 숫자를 붙이는 것)

3. 파티셔닝과 보조 색인

  • 보조 색인은 보통 레코드를 유일하게 식별하는 용도가 아니라 특정한 값이 발생한 항목을 검색하는 수단이다.
  • 보조 색인은 관계형 데이터베이스의 핵심 요소이며 문서 데이터베이스에서도 흔하다.
  • 보조색인은 솔라나 ElasticSearch 같은 검색 서버에서는 존재의 이유다.
  • 보조 색인은 파티션에 깔끔하게 대응되지 않는 문제점이 있다.
  • 보조 색인이 있는 데이터베이스를 파티셔닝 하는 데 널리 쓰이는 두 가지 방법
    • 문서 기반 파티셔닝
    • 용이 기반 파티셔닝

3.1 문서 기준 보조 색인 파티셔닝

  • 각 파티션은 완전히 독립적으로 동작한다.
  • 각 파티션은 자신의 보조 색인을 유지하며 그 파티션에 속하는 문서만 담당한다.


장점

  • 데이터베이스에 쓰기 작업을 할 경우 쓰려고 하는 문서 ID의 파티션만 다루면 되므로, 지역 색인(local index)라고도 한다.

단점

  • 문서 기반 파티셔닝에서 보조 색인을 읽으려면 모든 파티션에 걸쳐서 scatter/getter를 실행해야 한다.
    (scatter/getter 방식은 모든 파티션으로 질의를 보내서 얻을 결과를 모두 모으는 것을 의미한다)
  • 이러한 이유로 보조 색인을 써서 읽는 질의는 큰 비용이 들 수 있다.

3.2 용어 기준 보조 색인 파티셔닝

  • 각 파티션이 자신만의 보조 색인을 갖게 하는 대신, 모든 파티션의 데이터를 담당하는 전역 색인을 만들 수 있다.
  • 색인된 값을 사용해서 보조 색인을 별도로 파티셔닝
  • 찾고자 하는 용어에 다라 색인의 파티셔닝이 결정되므로 용어 기준으로 파티셔닝 했다고 함


장점

  • 모든 파티션에 스캐터/개터를 실행할 필요 없이, 원하는 용어를 포함하는 파티션으로만 요청을 보내면 되므로, 읽기가 효율적이다.

단점

  • 쓰기가 느리고 복잡하다는 단점이 존재.
  • 단일 문서를 쓸 때 해당 색인의 여러 파티션에 영향을 줄 수 있기 때문이다.
  • 이상적으로는 색인은 항상 최신 상태에 있고 데이터베이스에 기록된 모든 문서는 바로 색인에 반영돼야 한다. 하지만 용어 파티셔닝 색인을 사용할 때 그렇게 하려면 쓰기에 영향을 받는 모든 파티션에 걸친 분산 트랜잭션을 실행해야 하는데, 모든 데이터베이스에서 분산 트랜잭션을 지원하지는 않는다.
  • 현실에서는 전역 보조 색인은 대개 비동기로 갱신 (쓰기를 실행한 후 바로 색인을 읽으면 변경 사항이 색인에 반영되지 않을 수 있음)

4. 파티션 재균형화

시간이 지나면 데이터베이스에 변화가 생겨 데이터와 요청이 다른 노드로 옮겨져야 한다.

  • 질의 처리량이 증가해서 늘어난 부하를 처리하기 위해 CPU를 더 추가한다.
  • 데이터셋 크기가 증가해서 데이터셋 저장에 사용할 디스크와 램을 추가한다.
  • 장비에 장애가 발생해서 그 장비가 담당하던 역할을 다른 장비가 넘겨받아야 한다.

클러스터에서 한 노드가 담당하던 부하를 다른 노드로 옮기는 과정을 재균형화(리밸런싱)라고 한다.

4.1 리밸런싱 최소 요구사항

파티셔닝 방식과 무관하게 재균형화가 실행될 때 보통 만족시킬 것으로 기대되는 최소 요구사항이 있다.

  • 리밸런싱 이후, 부하가 클러스터 내에 있는 노드들 사이에 균등하게 분배돼야 한다.
  • 리밸런싱 도중에도 데이터베이스는 읽기 쓰기 요청을 받아들여야 한다.
  • 리밸런싱이 빨리 실행되고, 네트워크와 디스크 I/O 부하를 최소화할 수 있도록 노드들 사이에 데이터가 필요 이상으로 옮겨져서는 안 된다.

4.2 재균형화 전략

4.2.1 파티션 개수 고정

  • 파티션을 노드 대수보다 많이 만들고 각 노드에 여러 파티션을 할당하는 것. ex) 노드 10대에 파티션 1000개
  • 클러스터에 노드가 추가되면 새 노드는 파티션이 다시 균일하게 분배될 때까지 기존 노드에서 파티션 몇 개를 뺏어올 수 있다. (노드가 제거되면 반대로 실행)
  • 파티션은 노드 사이에서 통째로 이동하기만 한다.
    • 파티션 개수는 바뀌지 않고 파티션에 할당된 키도 변경되지 않는다.
    • 유일한 변화는 노드에 어떤 파티션이 할당되는가 뿐이다.
    • 이 방식을 사용할 때, 보통 데이터베이스가 처음 구축될 때 파티션 개수가 고정되고 이후에 변하지 않는다.
    • 처음 설정된 파티션 개수가 사용 가능한 노드 대수의 최대치가 되므로 미래에 증가될 것을 수용하기에 충분히 높은 값으로 선택해야 한다. 그러나 개별 파티션도 관리 오버헤드가 있으므로 너무 큰 수를 선택하면 역효과를 낳을 수 있다.

4.2.2 동적 파티셔닝

  • 키 범위 파티셔닝을 사용하는 데이터베이스에서는 파티션 경계와 개수가 고정돼 있는 게 매우 불편하다.
  • 파티션 경계를 잘못 지정하면 모든 데이터가 한 파티션에 저장되고 나머지 파티션은 텅 빌 수도 있다.
  • 이러한 이유로 HBase나 리싱크 DB처럼 키 범위 파티셔닝을 사용하는 데이터베이스에서는 파티션을 동적으로 만든다.
  • 파티션 크기에 따라 파티션은 쪼개지고 합쳐진다.

4.2.3 노드 비례 파티셔닝

  • 파티션 개수가 노드 대수에 비례하게 하는 방법. (노드당 할당되는 파티션 개수를 고정하는 것)
  • 노드 대수가 변함없는 동안은 개별 파티션 크기가 데이터셋 크기에 비례해서 증가하지만 노드 대수를 늘리면 파티션 크기는 다시 작아진다.
  • 새 노드가 클러스터에 추가되면 고정된 개수의 파티션을 무작위로 선택해 분할하고 각 분할된 파티션의 절반은 그대로 두고 다른 절반은 새 노드에 할당한다.

5. 요청 라우팅

  • 클라이언트에서 요청을 보내려고 할 때 어느 노드로 접속해야 하는지 어떻게 알 수 있을까?
    • 파티션이 리밸런싱 되면 노드에 할당되는 파티션이 바뀐다.

접근 방법

  1. 클라이언트가 아무 노드에나 접속하게 해서 만약 해당 노드에 요청을 적용할 파티션이 있다면 거기서 요청을 직접 처리하고 그렇지 않은 경우 올바른 노드로 전달해서 응답을 받고 클라이언트에게 응답을 전달
  2. 클라이언트의 모든 요청을 라우팅 계층으로 먼저 보내서, 라우팅 계층에서 해당 노드로 요청을 전달하는 방식
  3. 클라이언트가 파티셔닝 방법과 파티션이 어느 노드에 할당됐는지를 알고 노드로 직접 접속하는 방식
  • 모든 경우에 핵심 문제는 라우팅 결정을 내리는 구성 요소가 노드에 할당된 파티션의 변경 사항을 어떻게 아느냐다.
  • 많은 분산 데이터 시스템은 클러스터 메타데이터를 추적하기 위해 Zookeeper 같은 별도의 코디네이터 서비스를 사용한다.
  • 각 노드는 주키퍼에 자신을 등록하고 주키퍼는 파티션과 노드 사이의 신뢰성 있는 할당 정보를 관리한다.
  • 라우팅 계층이나 파티션 인지 클라이언트 같은 다른 구성요소들은 주키퍼에 있는 정보를 구독할 수 있다.
  •  
 

 

 

 

 

 

728x90
반응형

댓글