로드 밸런싱 관련 설정

ClickHouse가 분산 쿼리 처리에서 레플리카를 선택하는 알고리즘을 지정하는 load_balancing 설정과 관련된 내용을 소개해요. 랜덤, 가장 가까운 호스트명, levenshtein 거리 등 다양한 알고리즘을 쓸 수 있답니다. 이 설정들은 system.settings 테이블에서 확인할 수 있고 소스 코드에서 자동 생성된 값들이에요.

출처: 문서

본문

이 설정들은 system.settings에서 확인할 수 있고, 소스 코드에서 자동 생성된 값들이에요.

load_balancing

분산 쿼리 처리에 사용되는 레플리카 선택 알고리즘을 지정해요.

ClickHouse는 레플리카를 선택하는 다음 알고리즘들을 지원해요:

Random (기본값)
Nearest hostname
Hostname levenshtein distance
Hostname longest common prefix
Hostname longest common suffix
In order
First or random
Round robin

함께 보기:

distributed_replica_max_ignored_errors

Random (기본값)

load_balancing = random

각 레플리카에 대해 오류 수가 셈해져요. 쿼리는 오류가 가장 적은 레플리카로 보내지고, 그런 레플리카가 여러 개면 그 중 아무 데나 보내져요.

단점: 서버 근접도가 고려되지 않아요. 레플리카들이 서로 다른 데이터를 가지면 다른 데이터를 얻게 되죠.

Nearest Hostname

load_balancing = nearest_hostname

각 레플리카에 대해 오류 수가 셈해져요. 5분마다 오류 수가 정수로 2로 나눠져요. 따라서 오류 수는 지수 평활화로 최근 시간에 대해 계산돼요. 오류 수가 최소인 레플리카가 하나이면(즉 최근에 다른 레플리카에서 오류가 발생했다면) 쿼리가 그 레플리카로 보내져요. 같은 최소 오류 수를 가진 레플리카가 여러 개면, 쿼리는 구성 파일의 서버 호스트명과 가장 유사한 호스트명을 가진 레플리카로 보내져요(같은 위치의 다른 문자 수 기준, 두 호스트명의 최소 길이까지).

예를 들어 example01-01-1과 example01-01-2는 한 위치가 다르고, example01-01-1과 example01-02-2는 두 곳이 달라요.

이 방법은 원시적으로 보일 수 있지만 네트워크 토폴로지에 대한 외부 데이터가 필요 없고, IPv6 주소에서는 복잡할 IP 주소를 비교하지도 않아요. 따라서 동등한 레플리카가 있으면 이름상 가장 가까운 것이 우선돼요.

또한 같은 서버에 쿼리를 보낼 때, 실패가 없으면 분산 쿼리도 같은 서버로 간다고 가정할 수 있어요. 그래서 레플리카에 서로 다른 데이터가 배치되어 있어도 쿼리는 대부분 같은 결과를 반환해요.

Hostname levenshtein distance

load_balancing = hostname_levenshtein_distance

nearest_hostname과 같지만 호스트명을 levenshtein 거리 방식으로 비교해요. 예:

example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3

Hostname longest common prefix

load_balancing = hostname_longest_common_prefix

nearest_hostname과 같지만 로컬 호스트명과 가장 긴 공통 접두사를 공유하는 레플리카가 우선돼요(공통 접두사가 길수록 우선순위가 높음). nearest_hostname이 위치별로 다른 문자 수를 세는 것과 달리, 이 전략은 숫자 세그먼트 길이가 다른 호스트명에도 혼동되지 않아요. 예를 들어 로컬 호스트명 sfe301에 대해:

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

여기서 sfe10101이 sfe301과 가장 긴 공통 접두사(sfe, 길이 3)를 공유하므로 우선돼요.

공통 접두사 길이가 같은 레플리카는 무작위로 선택돼요. 특히 어떤 레플리카도 로컬 호스트명과 접두사를 공유하지 않으면(모든 공통 접두사 길이가 0이면) 이 전략은 random과 정확히 동일하게 동작해요.

Hostname longest common suffix

load_balancing = hostname_longest_common_suffix

hostname_longest_common_prefix와 같지만 접두사 대신 가장 긴 공통 접미사를 비교해요. 데이터 센터 정체성이 호스트명의 접미사로 인코딩되어 있을 때 유용해요. 예를 들어 로컬 호스트명 et46gtghn.qc.localdomain에 대해:

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

여기서 ab999.qc.localdomain이 et46gtghn.qc.localdomain과 가장 긴 공통 접미사(.qc.localdomain, 길이 15)를 공유하므로 우선돼요.

공통 접미사 길이가 같은 레플리카는 무작위로 선택돼요. 특히 어떤 레플리카도 로컬 호스트명과 접미사를 공유하지 않으면 이 전략은 random과 정확히 동일하게 동작해요.

In Order

load_balancing = in_order

오류 수가 같은 레플리카는 구성에 지정된 것과 같은 순서로 접근돼요. 어떤 레플리카가 우선인지 정확히 알 때 적합한 방법이에요.

First or Random

load_balancing = first_or_random

이 알고리즘은 집합에서 첫 번째 레플리카를 선택하거나, 첫 번째를 사용할 수 없으면 무작위 레플리카를 선택해요. 크로스-레플리케이션 토폴로지 구성에서 효과적이지만 다른 구성에서는 쓸모없어요.

first_or_random 알고리즘은 in_order 알고리즘의 문제를 해결해요. in_order에서는 레플리카 하나가 다운되면 다음 레플리카가 이중 부하를 받고 나머지 레플리카는 평소 트래픽을 처리하거든요. first_or_random 알고리즘을 사용하면 부하가 여전히 사용 가능한 레플리카들에 고르게 분산돼요.

load_balancing_first_offset 설정으로 첫 번째 레플리카를 명시적으로 정의할 수 있어요. 이는 레플리카 간 쿼리 워크로드를 리밸런싱하는 데 더 많은 제어를 줘요.

Round Robin

load_balancing = round_robin

이 알고리즘은 오류 수가 같은 레플리카에 대해 라운드-로빈 정책을 사용해요(round_robin 정책이 있는 쿼리만 계산됨).

load_balancing_first_offset

FIRST_OR_RANDOM 로드 밸런싱 전략을 사용할 때 쿼리를 선호적으로 보낼 레플리카를 나타내요.

로드 밸런싱 관련 설정