브로커 간 로드 밸런싱

브로커 간 로드 밸런싱 (Load balance across brokers)

Pulsar는 수평 확장 가능한 메시징 시스템이라서, 논리적 클러스터의 트래픽은 가능한 한 모든 Pulsar 브로커에 고르게 분산되어야 해요. 이것이 핵심 요구 사항이에요. 이 페이지에서는 Pulsar에서 트래픽이 어떻게 관리되는지, 그리고 로드 밸런싱 프레임워크를 활용해 분산을 조정하는 방법을 설명해요.

출처: 문서

본문

Pulsar는 수평 확장 가능한 메시징 시스템이므로 논리적 클러스터의 트래픽은 가능한 한 모든 Pulsar 브로커에 고르게 분산되어야 하는데, 이것이 핵심 요구 사항이에요.

여러 설정과 도구로 트래픽 분산을 제어할 수 있어요. Pulsar에서 트래픽이 어떻게 관리되는지 이해하려면 약간의 맥락이 필요해요. 대부분의 경우 위에서 말한 핵심 요구 사항은 기본적으로 충족되므로 걱정할 필요는 없어요.

다음 섹션에서는 로드 밸런싱 할당이 Pulsar 브로커 간에 어떻게 동작하는지, 그리고 프레임워크를 활용해 조정하는 방법을 소개해요. Pulsar는 두 가지 로드 매니저를 제공해요. 모듈식(modular) 로드 매니저(loadManagerClassName=org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl, 기본값)와 확장 가능한(extensible) 로드 매니저(org.apache.pulsar.broker.loadbalance.extensions.ExtensibleLoadManagerImpl)예요. 달리 표시되지 않는 한 이 페이지는 둘 모두에 적용돼요. 차이점은 Broker load balancing | Types에서, 그리고 하나에서 다른 하나로 옮기는 것은 Broker load balancing | Migration에서 설명해요.

이 페이지의 pulsar-admin 명령은 admin REST API의 얇은 래퍼예요. 여기 보이는 모든 연산은 자신의 자동화에서 직접 호출할 수 있어요. 자세한 내용은 Automate with the REST API를 참고해요.

동적 할당 (Dynamic assignments)

토픽은 클러스터의 모든 브로커의 부하 조건에 따라 브로커에 동적으로 할당돼요. 토픽의 브로커 할당은 토픽 수준이 아니라 번들(bundle) 수준(더 높은 수준)에서 이뤄져요. 개별 토픽 할당 대신 각 브로커가 네임스페이스의 토픽 부분집합을 소유해요. 이 부분집합을 번들이라 부르며, 실질적으로 이 부분집합은 샤딩 메커니즘이에요.

즉, 각 네임스페이스는 "관리" 단위이고 번들 목록으로 샤딩되며, 각 번들은 네임스페이스 전체 해시 범위의 일부를 포함해요. 토픽은 토픽 이름의 해시를 취해서 그 해시가 어느 번들에 들어가는지 확인해 특정 번들에 할당돼요. 각 번들은 서로 독립적이므로 다른 브로커에 독립적으로 할당돼요.

할당 세분성이 주는 이점은 추적해야 할 정보량을 분산시킬 수 있다는 것이에요(번들이 무엇을 비용으로 하는지는 Namespace bundles 참고). CPU, 메모리, 트래픽 부하 및 기타 지표에 기반해 토픽이 특정 브로커에 동적으로 할당돼요. 예를 들어:

  • 클라이언트가 어떤 브로커에도 할당되지 않은 새 토픽을 사용하기 시작하면, 부하 조건에 따라 이 토픽의 소유권을 가져갈 가장 적합한 브로커를 선택하는 프로세스가 트리거돼요.
  • 토픽을 소유한 브로커가 과부하가 되면 토픽은 부하가 덜한 브로커에 재할당돼요.
  • 토픽을 소유한 브로커가 크래시하면 토픽은 다른 활성 브로커에 재할당돼요.

tip

파티션 토픽의 경우 서로 다른 파티션이 서로 다른 브로커에 할당돼요. 여기서 "토픽"은 비-파티션 토픽 또는 토픽의 파티션 하나를 의미해요.

할당된 번들로 네임스페이스 생성 (Create namespaces with assigned bundles)

새 네임스페이스를 만들면 일정 수의 번들이 네임스페이스에 할당돼요. 이 숫자는 conf/broker.conf 파일에서 설정할 수 있어요.

# When a namespace is created without specifying the number of bundles, this
# value will be used as the default. Default is 32 from 5.0.0.
# The 5.0.0-M1/M2 milestones and earlier versions default to 4.
defaultNumberOfNamespaceBundles=32

또는 Pulsar admin으로 새 네임스페이스를 만들 때 값을 재정의할 수 있어요.

bin/pulsar-admin namespaces create my-tenant/my-namespace --clusters us-west --bundles 64

위 명령으로 64개의 초기 번들이 있는 네임스페이스를 만들 수 있어요. 따라서 이 네임스페이스의 토픽은 즉시 최대 64개 브로커에 분산될 수 있어요.

일반적으로 예상 트래픽과 토픽 수를 미리 안다면, 시스템이 분산을 자동 보정하도록 기다리기보다 합리적인 번들 수로 시작하는 것이 좋아요.

마찬가지로 토픽이 번들로 분산되는 방식의 해싱 특성 때문에 브로커 수보다 많은 번들로 시작하는 것이 유리해요. 예를 들어 1000개 토픽이 있는 네임스페이스에서는 64개 정도의 번들을 사용하면 16개 브로커에 걸쳐 트래픽을 잘 분산할 수 있어요. 룩업된 적이 없는 번들은 비용이 들지 않으므로 넉넉한 수가 작은 네임스페이스를 불리하게 하지 않아요.

pulsar/system 네임스페이스와 public/default는 pulsar initialize-cluster-metadata가 자체 번들 수(--system-namespace-bundle-number, 기본 64, --default-namespace-bundle-number, 기본 32)로 만들어요. 5.0.0-M1/M2 마일스톤은 두 네임스페이스 모두 여전히 16을 기본값으로 하고 --system-namespace-bundle-number를 제공하지 않아요. 번들이 무엇을 비용으로 하는지와 트랜잭션 코디네이터를 위해 시스템 네임스페이스를 어떻게 크기 조정하는지 포함해 전체 그림은 Namespace bundles를 참고해요.

네임스페이스 번들 분할 (Split namespace bundles)

번들 안의 토픽 부하는 시간이 지나며 바뀔 수 있고 부하를 예측하기 어려울 수 있으므로, 번들 분할이 이런 문제를 해결하도록 설계됐어요. 브로커가 번들을 둘로 분할하고 새로 생긴 작은 번들을 다른 브로커에 재할당할 수 있어요.

Pulsar는 다음 번들 분할 알고리즘을 지원해요(자세한 내용은 Bundle splitting algorithms 참고).

  • range_equally_divide(기본): 번들을 같은 해시 범위 크기의 두 부분으로 분할
  • topic_count_equally_divide: 번들을 같은 토픽 수의 두 부분으로 분할
  • specified_positions_divide: 지정된 위치로 번들을 여러 부분으로 분할
  • flow_or_qps_equally_divide: 번들을 같은 메시지 비율 또는 처리량의 두 부분으로 분할

tip

  • specified_positions_divide 알고리즘은 admin API에서만 사용을 지원하고 defaultNamespaceBundleSplitAlgorithm에 설정하는 것은 지원하지 않아요.
  • 분할은 영구적이에요. 번들은 분할할 수 있지만 병합할 수 없어요. 분할을 덜 필요로 하도록 초기 번들 수를 고르는 방법은 Namespace bundles를 참고해요.

번들 분할을 활성화하려면 broker.conf 파일에서 다음 설정을 구성하고 필요에 따라 defaultNamespaceBundleSplitAlgorithm을 설정해야 해요.

loadBalancerAutoBundleSplitEnabled=true
loadBalancerAutoUnloadSplitBundlesEnabled=true
defaultNamespaceBundleSplitAlgorithm=range_equally_divide

분할 임계값에 대한 더 많은 파라미터를 구성할 수 있어요. 임계값 중 하나를 초과하는 기존 번들은 분할 후보예요. 기본적으로 새로 분할된 번들은 트래픽 분산을 위해 즉시 다른 브로커에 재할당돼요.

# maximum topics in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxTopics=1000

# maximum sessions (producers + consumers) in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxSessions=1000

# maximum msgRate (in + out) in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxMsgRate=30000

# maximum bandwidth (in + out) in a bundle, otherwise bundle split will be triggered
loadBalancerNamespaceBundleMaxBandwidthMbytes=100

# maximum number of bundles in a namespace (for auto-split)
loadBalancerNamespaceMaximumBundles=128

자동 로드 셰딩 (Shed load automatically)

자동 로드 셰딩 지원은 Pulsar의 로드 매니저에 있어요. 리더 브로커가 주기적으로 브로커의 부하를 비교하고, 구성된 셰딩 전략이 분산이 불균등하다고 판단하면 너무 많이 감당하는 브로커에서 일부 번들을 "언로드"해서 덜 감당하는 브로커에 재할당되게 해요. 어떤 브로커가 너무 부하가 많은지, 몇 개 번들이 이동하는지, 어디로 가는지는 전략에 따라 달라져요.

tip

  • 자동 로드 셰딩은 기본적으로 활성화돼 있어요. 비활성화하려면 loadBalancerSheddingEnabled를 false로 설정해요. 이 설정은 동적이라, 예를 들어 브로커 롤링 업그레이드 중에 pulsar-admin brokers update-dynamic-config로 셰딩을 일시적으로 중지할 수도 있어요.
  • 자동 로드 셰딩 외에 수동으로 번들을 언로드할 수도 있어요.

셰딩에 적용되는 추가 설정:

# Load shedding interval. Broker periodically checks whether some traffic should be offload from
# some over-loaded broker to other under-loaded brokers
loadBalancerSheddingIntervalMinutes=1

# Prevent the same topics to be shed and moved to other brokers more than once within this timeframe
loadBalancerSheddingGracePeriodMinutes=30

전략은 loadBalancerLoadSheddingStrategy로 선택돼요. 모듈식 로드 매니저는 다음 전략을 지원해요.

  • AvgShedder (Pulsar 5.0.0부터 기본)
  • ThresholdShedder (Pulsar 2.10부터 4.x까지와 5.0.0-M1/M2의 기본)
  • OverloadShedder
  • UniformLoadShedder

확장 가능한 로드 매니저는 TransferShedder를 사용해요.

note

  • Pulsar 5.0.0부터 모듈식 로드 매니저의 기본 셰딩 전략은 AvgShedder이며, 배치 전략(loadBalancerLoadPlacementStrategy)으로도 AvgShedder와 짝을 이뤄요. Pulsar 2.10부터 4.x까지와 5.0.0-M1/M2 마일스톤 빌드는 LeastLongTermMessageRate 배치와 함께 ThresholdShedder를 기본으로 해요.
  • 셰딩 전략을 동적으로 업데이트하면 브로커를 재시작해야 해요.

AvgShedder

이 전략은 가장 부하가 많은 브로커와 가장 부하가 적은 브로커를 짝짓고, 둘 사이의 리소스 사용량 점수 차이가 연속된 여러 검사에서 임계값을 초과하면 전자에서 후자로 번들을 이동해요: loadBalancerAvgShedderLowThreshold(15점)가 loadBalancerAvgShedderHitCountLowThreshold(8) 검사 동안, 또는 loadBalancerAvgShedderHighThreshold(40점)가 loadBalancerAvgShedderHitCountHighThreshold(2) 검사 동안요. 반복 검사는 짧은 부하 스파이크를 걸러내요. 차이가 클수록 전략이 더 빨리 작동하므로, 브로커 롤링 업그레이드나 브로커 추가 후 클러스터를 빠르게 안정화시켜요.

AvgShedder는 또한 언로드하는 모든 번들의 목적지를 계획해서, 번들의 배치가 셰딩 결정을 되돌릴 수 없게 해요. 이를 위해 셰딩과 배치 전략 모두로 구성되어야 하는데, 이것이 기본이에요.

loadBalancerLoadSheddingStrategy=org.apache.pulsar.broker.loadbalance.impl.AvgShedder
loadBalancerLoadPlacementStrategy=org.apache.pulsar.broker.loadbalance.impl.AvgShedder

# Share of the load difference between the two brokers to move in one cycle. 0.5 equalizes the pair.
maxUnloadPercentage=0.5

아래 고전적 셰딩 전략 중 하나를 구성하면서 loadBalancerLoadPlacementStrategy를 기본값으로 두면, 브로커는 Pulsar 5.0 이전에 그 셰딩 전략과 짝을 이루던 LeastLongTermMessageRate 배치 전략으로 폴백하고 경고를 기록해요. 알고리즘의 자세한 내용은 로드 밸런싱 개념에서 AvgShedder를 참고해요.

브로커 롤링 업그레이드 중에 AvgShedder는, 리더가 부하 보고서를 갖고 셰딩이 활성화된 후에는 셰딩된 번들을 부하가 적은 교체 브로커로 보낼 수 있어요. 계획된 목적지는 셰딩용으로 선택된 번들에 적용돼요. 그러한 계획이 없는 일반 할당은 적격 후보 중에서 무작위 선택을 사용하므로, 셰딩을 중지한다고 해서 해제된 번들이 가장 부하가 적은 브로커로 간다는 보장은 없어요.

ThresholdShedder

이 전략은 리소스 사용량이 클러스터의 브로커 평균 리소스 사용량을 지정된 임계값만큼 초과하는 브로커에서 번들을 셰딩해요.

브로커의 현재 사용량은 CPU, 직접 메모리(direct memory), 인바운드 처리량, 아웃바운드 처리량 값 중 최댓값으로 정의돼요. 이 값은 브로커 로드 밸런싱 목적의 계산된 리소스 사용량을 산출하기 위해 과거 관측값으로 지수적으로 평활화돼요.

브로커의 리소스 사용량이 클러스터의 모든 브로커 평균 리소스 사용량을 최소 임계값 loadBalancerBrokerThresholdShedderPercentage만큼 초과하면 그 브로커는 과부하로 간주돼요. 과부하 브로커의 번들은 브로커의 예상 처리량이 클러스터 평균보다 5% 아래일 때까지 전송돼요. 또한 브로커는 번들 언로드에 적격하려면 총 현재 처리량(in + out)이 충분히 높아야 해요. 브로커의 예상 처리량 감소가 절대값 loadBalancerBundleUnloadMinThroughputThreshold을 초과하지 않으면 언로드되지 않아요.

최근에 언로드된 번들은 다시 언로드되지 않는 점을 유의해요.

ThresholdShedder 전략

예를 들어 브로커 3개가 있고 broker1의 평균 사용량이 40%, broker2와 broker3의 평균 사용량이 10%라면 클러스터 평균 사용량은 20%((40% + 10% + 10%) / 3)예요. loadBalancerBrokerThresholdShedderPercentage를 10으로 설정하면 broker1의 평균 사용량이 클러스터 평균 사용량(20%)과 loadBalancerBrokerThresholdShedderPercentage(10%)의 합보다 크므로 broker1의 특정 번들만 언로드돼요.

하지만 일부 특수한 경우 위 기본 전략은 저부하 또는 유휴 머신의 리소스를 활용하지 못할 수 있어요.

예를 들어:

11개 브로커가 있는데 그중 10개가 80%로 부하가 걸리고 1개가 0%라고 해요. 평균 부하는 80% * 10 / 11 = 72.73%이고, 언로드 임계값은 72.73% + 10% = 82.73%예요. 80% < 82.73%이므로 언로드가 트리거되지 않고, 부하가 0%인 유휴 브로커가 하나 남아요.

저부하 또는 유휴 머신의 리소스를 활용하려면 ThresholdShedder 위에 lowerBoundarySheddingEnabled 파라미터를 구성할 수 있어요. lowerBoundarySheddingEnabled를 true로 설정하면 리더가 부하의 하한 경계를 결정해요. current usage가 average usage - lower boundary load보다 작으면, 예를 들어 0% < (82.73% - 10%)라면, 가장 높은 부하의 브로커에서 언로드가 트리거돼요.

ThresholdShedder 전략을 사용하려면 이 값으로 브로커를 구성해요.

loadBalancerLoadSheddingStrategy=org.apache.pulsar.broker.loadbalance.impl.ThresholdShedder

conf/broker.conf 파일에서 브로커별로 각 리소스의 가중치를 구성할 수 있어요.

# The BandWithIn usage weight when calculating new resource usage. The range is between 0 and 1.0.
loadBalancerBandwithInResourceWeight=1.0

# The BandWithOut usage weight when calculating new resource usage. The range is between 0 and 1.0.
loadBalancerBandwithOutResourceWeight=1.0

# The CPU usage weight when calculating new resource usage. The range is between 0 and 1.0.
loadBalancerCPUResourceWeight=1.0

# The heap memory usage weight when calculating new resource usage. The range is between 0 and 1.0.
loadBalancerMemoryResourceWeight=1.0

# The direct memory usage weight when calculating new resource usage. The range is between 0 and 1.0.
loadBalancerDirectMemoryResourceWeight=1.0

OverloadShedder

이 전략은 과부하된, 즉 최대 시스템 리소스 사용량이 loadBalancerBrokerOverloadedThresholdPercentage를 초과하는 브로커에서 정확히 하나의 번들을 셰딩하려 해요. 최대 시스템 리소스를 결정할 때 어떤 리소스를 고려하는지는 문서를 참고해요. 다음 조건이 모두 성립하면 그 브로커에서 번들 언로드가 권장돼요. 브로커에 최소 두 개의 번들이 할당되어 있고, 브로커에 LoadBalancerSheddingGracePeriodMinutes에 따라 최근에 언로드되지 않은 번들이 최소 하나 있어야 해요. 언로드되는 번들은 최근에 언로드되지 않은 것 중 메시지 비율 기준으로 가장 비싼 번들이에요. 이 전략은 어떤 번들을 언로드할지 결정할 때 "저부하" 브로커를 고려하지 않는다는 점을 유의해요. 모든 브로커에 걸쳐 부하를 고르게 분산하는 전략을 찾고 있다면 ThresholdShedder를 참고해요.

OverloadShedder 전략

OverloadShedder 전략을 사용하려면 이 값으로 브로커를 구성해요.

loadBalancerLoadSheddingStrategy=org.apache.pulsar.broker.loadbalance.impl.OverloadShedder
브로커 과부하 임계값 (Broker overload thresholds)

브로커가 과부하인지 판단하는 것은 CPU, 네트워크, 메모리 사용량의 임계값에 기반해요. 이 메트릭 중 하나라도 임계값에 도달하면 시스템이 셰딩(활성화된 경우)을 트리거해요.

note

과부하 임계값 loadBalancerBrokerOverloadedThresholdPercentage는 OverloadShedder 셰딩 전략에만 적용돼요. 기본적으로 85%로 설정돼 있어요.

Pulsar는 시스템 메트릭에서 CPU, 네트워크, 메모리 사용량 통계를 수집해요. 일부 네트워크 사용률 경우, Linux가 보고하는 네트워크 인터페이스 속도가 정확하지 않아 수동으로 재정의해야 해요. 1Gbps NIC 속도의 AWS EC2 인스턴스가 OS에서 10Gbps 속도로 보고되는 경우가 그 예시예요.

잘못된 최대 속도 때문에 로드 매니저는 브로커가 NIC 용량에 도달하지 못했다고 생각할 수 있는데, 실제로는 브로커가 이미 모든 대역폭을 사용해 트래픽이 느려진 상태예요.

conf/broker.conf 파일에서 loadBalancerOverrideBrokerNicSpeedGbps를 설정해 최대 NIC 속도를 보정할 수 있어요. 값이 비어 있으면 Pulsar는 OS가 보고하는 값을 사용해요.

UniformLoadShedder

이 전략은 모든 브로커에 걸쳐 부하를 균일하게 분산하는 경향이 있어요. 이 전략은 가장 높은 부하의 브로커와 가장 낮은 부하의 브로커 사이의 부하 차이를 확인해요. 차이가 구성된 임계값 loadBalancerMsgRateDifferenceShedderThreshold와 loadBalancerMsgThroughputMultiplierDifferenceShedderThreshold보다 높으면, 모든 브로커에 걸쳐 트래픽을 고르게 분산하도록 언로드할 수 있는 번들을 찾아요.

UniformLoadShedder 전략

UniformLoadShedder 전략을 사용하려면 이 값으로 브로커를 구성해요.

loadBalancerLoadSheddingStrategy=org.apache.pulsar.broker.loadbalance.impl.UniformLoadShedder

TransferShedder

이 전략은 확장 가능한 로드 매니저의 기본이며 그곳에서만 사용할 수 있어요. 더 부하가 많은 브로커에서 덜 부하가 많은 브로커로 번들을 전송하며, 표준편차가 loadBalancerBrokerLoadTargetStd(0.25) 아래가 되도록 목표해요. 그 목표가 충족돼도 저부하·과부하 브로커를 확인하며, 히트 카운트와 기타 셰딩 제한이 적용돼요. 목적지는 미리 할당되어 브로커 리다이렉션을 지원하는 클라이언트가 룩업 없이 재연결할 수 있어요.

기본적으로 TransferShedder는 격리 정책 또는 안티-어피니티 그룹이 있는 네임스페이스의 번들을 건너뛰어요. loadBalancerSheddingBundlesWithPoliciesEnabled=true를 설정해 그 번들을 배치 제약 안에서 자동 셰딩할 수 있어요. 그렇지 않으면 롤아웃 후 셰딩을 복원해도 그 번들을 자동으로 리밸런싱하지 않아요. 자세한 내용은 placement and rebalancing considerations를 참고해요.

쿨다운은 최근에 언로드된 소스 브로커의 부하 데이터가 마지막 예정된 언로드 이후 최소 loadBalanceSheddingDelayInSeconds(180)로 타임스탬프가 찍힐 때까지 셰딩을 건너뛰어요. 이는 브로커 시작부터 측정한 쿨다운이 아니에요. 셰딩은 또한 등록된 브로커에 부하 데이터가 없으면 주기를 건너뛰어요. 롤아웃 중 함의는 Rolling upgrade of brokers를 참고해요.

loadManagerClassName=org.apache.pulsar.broker.loadbalance.extensions.ExtensibleLoadManagerImpl
loadBalancerLoadSheddingStrategy=org.apache.pulsar.broker.loadbalance.extensions.scheduler.TransferShedder

자세한 내용은 로드 밸런싱 개념에서 TransferShedder를 참고해요.

토픽과 번들 언로드 (Unload topics and bundles)

Pulsar 수동 관리 연산에서 토픽을 "언로드"할 수 있어요. 언로딩은 토픽을 닫고, 소유권을 해제하고, 현재 부하에 기반해 토픽을 새 브로커에 재할당하는 것을 의미해요.

언로딩이 일어나면 클라이언트는 토픽이 재할당되는 동안 작은 지연 딸꾹질(보통 수십 밀리초)을 경험해요.

언로딩은 로드 매니저가 로드 셰딩을 수행하는 메커니즘이지만, 어떤 브로커도 과부하되기 전에 할당을 보정하고 트래픽을 재분산하기 위해 수동으로 언로딩을 트리거할 수도 있어요.

토픽을 언로드하는 것은 할당에는 영향이 없고 단지 특정 토픽을 닫고 다시 여는 것뿐이에요.

pulsar-admin topics unload persistent://tenant/namespace/topic

네임스페이스의 모든 토픽을 언로드하고 재할당을 트리거하려면:

pulsar-admin namespaces unload tenant/namespace

하나의 번들을 자신이 선택한 브로커로 이동하려면, 예를 들어 재시작 전에 브로커를 배수(drain)할 때:

pulsar-admin namespaces unload tenant/namespace --bundle 0x00000000_0x08000000 --destinationBroker broker-2.example.com:8080

장애 도메인에 안티-어피니티 네임스페이스 분산 (Distribute anti-affinity namespaces across failure domains)

애플리케이션이 여러 네임스페이스를 가질 때 그중 하나가 항상 사용 가능하길 원한다면, 그것들을 안티-어피니티 그룹으로 묶어 로드 매니저가 서로 다른 장애 도메인과 브로커에 분산하게 할 수 있어요. Anti-affinity namespaces를 참고해요.

  • Namespace bundles: 네임스페이스가 몇 개의 번들을 얻는지, 무엇을 비용으로 하는지, 어떻게 크기를 정하는지.
  • Rolling upgrade of brokers: 브로커가 중지할 때 그 브로커의 번들에 어떤 일이 생기는지, 그리고 로드 밸런서가 모든 재시작에 반응하지 않게 하는 방법.
  • Broker load balancing | Concepts: 각 셰딩 전략을 포함한 할당, 분할, 언로드를 자세히.
  • Broker load balancing | Types: 모듈식 대 확장 가능한 로드 매니저.

더 알아보기 (Learn more)

  • 네임스페이스 번들의 비용과 크기 조정은 Namespace bundles 문서를 참고해요.
  • 브로커 롤링 업그레이드 중 로드 밸런서 동작은 Rolling upgrade of brokers 문서를 참고해요.
  • 로드 밸런싱 개념과 셰딩 전략 상세는 Broker load balancing | Concepts 문서를 참고해요.
  • 모듈식·확장 가능한 로드 매니저의 차이는 Broker load balancing | Types 문서를 참고해요.