반응형
[데이터 중심 애플리케이션 설계] 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. 요청 라우팅
- 클라이언트에서 요청을 보내려고 할 때 어느 노드로 접속해야 하는지 어떻게 알 수 있을까?
- 파티션이 리밸런싱 되면 노드에 할당되는 파티션이 바뀐다.
접근 방법
- 클라이언트가 아무 노드에나 접속하게 해서 만약 해당 노드에 요청을 적용할 파티션이 있다면 거기서 요청을 직접 처리하고 그렇지 않은 경우 올바른 노드로 전달해서 응답을 받고 클라이언트에게 응답을 전달
- 클라이언트의 모든 요청을 라우팅 계층으로 먼저 보내서, 라우팅 계층에서 해당 노드로 요청을 전달하는 방식
- 클라이언트가 파티셔닝 방법과 파티션이 어느 노드에 할당됐는지를 알고 노드로 직접 접속하는 방식
- 모든 경우에 핵심 문제는 라우팅 결정을 내리는 구성 요소가 노드에 할당된 파티션의 변경 사항을 어떻게 아느냐다.
- 많은 분산 데이터 시스템은 클러스터 메타데이터를 추적하기 위해 Zookeeper 같은 별도의 코디네이터 서비스를 사용한다.
- 각 노드는 주키퍼에 자신을 등록하고 주키퍼는 파티션과 노드 사이의 신뢰성 있는 할당 정보를 관리한다.
- 라우팅 계층이나 파티션 인지 클라이언트 같은 다른 구성요소들은 주키퍼에 있는 정보를 구독할 수 있다.
728x90
반응형
'스터디 > 데이터 중심 애플리케이션 설계' 카테고리의 다른 글
[데이터 중심 애플리케이션 설계] 08. 분산 시스템의 골칫거리 (0) | 2023.01.15 |
---|---|
[데이터 중심 애플리케이션 설계] 07. 트랜잭션 (1) | 2023.01.02 |
[데이터 중심 애플리케이션 설계] 05. 분산 데이터와 복제 (0) | 2022.12.29 |
[데이터 중심 애플리케이션 설계] 04. 부호화와 발전 (0) | 2022.12.28 |
[데이터 중심 애플리케이션 설계] 03. 저장소와 검색 (2) | 2022.12.21 |
댓글