네임스페이스 번들
네임스페이스 번들 (Namespace bundles)
네임스페이스는 번들(bundle)로 샤딩되며, 번들은 로드 매니저가 브로커에 할당하는 단위예요. 각 번들은 네임스페이스의 32비트 해시 공간 범위를 소유해요. 토픽은 전체 토픽 이름(예: persistent://my-tenant/my-namespace/my-topic)의 해시가 포함된 범위의 번들에 속해요. 파티션 토픽의 경우 각 파티션이 별도로 해시되므로 한 토픽의 파티션들이 번들과 브로커에 걸쳐 퍼져요.
출처: 문서
본문
네임스페이스는 번들로 샤딩되고, 번들은 로드 매니저가 브로커에 할당하는 단위예요. 각 번들은 네임스페이스의 32비트 해시 공간 범위를 소유해요. 토픽은 전체 토픽 이름(예: persistent://my-tenant/my-namespace/my-topic)의 해시가 포함된 범위의 번들에 속해요. 파티션 토픽의 경우 각 파티션이 별도로 해시되므로 한 토픽의 파티션들이 번들과 브로커에 걸쳐 퍼져요.
번들 수는 네임스페이스의 토픽이 몇 개의 브로커에 걸쳐 분산될 수 있는지를 결정해요. 이 페이지는 그 숫자가 어떻게 선택되는지, 번들이 무엇을 비용으로 하는지, 네임스페이스를 어떻게 크기 조정하는지 설명해요. 할당·분할·언로드의 메커니즘은 Broker load balancing | Concepts를 참고해요.
네임스페이스가 얻는 번들 수 (How many bundles a namespace gets)
번들 수는 네임스페이스를 만들 때 고정되며, 이후에는 분할에 의해서만 늘어날 수 있어요.
| Namespace | Created by | Number of bundles |
|---|---|---|
pulsar-admin namespaces create, REST API 또는 Java admin 클라이언트로 명시적 번들 수 없이 만든 모든 네임스페이스 |
Broker | broker.conf의 defaultNumberOfNamespaceBundles, 기본 32 (Pulsar 5.0.0 이전에는 4) |
위와 같지만 pulsar-admin namespaces create ... --bundles N으로 |
Broker | N |
public/default |
pulsar initialize-cluster-metadata |
--default-namespace-bundle-number, 기본 32 (Pulsar 5.0.0 이전에는 16) |
pulsar initialize-namespace로 만든 네임스페이스 |
CLI 도구 | 32 |
pulsar/system |
pulsar initialize-cluster-metadata 또는 pulsar initialize-transaction-coordinator-metadata |
--system-namespace-bundle-number, 기본 64 (Pulsar 5.0.0 이전에는 16) |
pulsar/system, 시작 시 아직 존재하지 않을 때 |
Broker(확장 가능한 로드 매니저) 또는 pulsar standalone |
broker.conf의 defaultNumberOfSystemNamespaceBundles, 기본 64 (Pulsar 5.0.0 이전: defaultNumberOfNamespaceBundles) |
public/default |
pulsar standalone |
defaultNumberOfNamespaceBundles |
| 각 브로커의 하트비트 네임스페이스 | Broker | 1 (전체 해시 범위) |
Pulsar 5.0 마일스톤
표의 기본값은 5.0.0-M1/M2 마일스톤 이후의 Pulsar 5.0.0을 설명해요. 그 마일스톤 빌드는 브로커가 만든 네임스페이스에 여전히 4개 번들을, 클러스터 메타데이터 초기화 중 만든 네임스페이스에 16개 번들을 사용해요. 이들은 defaultNumberOfSystemNamespaceBundles 또는 --system-namespace-bundle-number를 제공하지 않으며, 브로커가 만든 시스템 네임스페이스는 defaultNumberOfNamespaceBundles를 사용해요. 업그레이드 시 기존 네임스페이스는 번들 수를 유지해요.
네임스페이스의 번들을 보려면:
pulsar-admin namespaces bundles my-tenant/my-namespace
토픽의 번들을 찾으려면:
pulsar-admin topics bundle-range persistent://my-tenant/my-namespace/my-topic
번들이 무엇을 비용으로 하는지 (What a bundle costs)
번들은 그 안의 토픽이 한 번 룩업된 후에만 비용이 들어요. 번들 소유권은 지연(lazy) 획득돼요. 번들 안의 토픽을 처음 룩업하면 로드 매니저가 번들을 브로커에 할당하고, 그때부터 번들은 다음을 갖게 돼요.
- 메타데이터 스토어의 소유권 엔트리(모듈식 로드 매니저에서는 임시 노드, 확장 가능한 로드 매니저에서는 소유권 시스템 토픽의 엔트리)
- 소유 브로커 로드 보고서의 엔트리
- 소유 브로커가 종료되거나 번들이 이동될 때의 언로드 단계 하나
아무도 룩업하지 않은 번들은 네임스페이스 정책의 경계일 뿐이에요. 32개 번들과 두 토픽이 있는 네임스페이스는 많아야 두 개의 소유된 번들을 가져요. 나머지 30개는 비용이 들지 않아요. 따라서 네임스페이스의 비용은 활성 번들 수에 따라 확장되며, 이는 활성 토픽 수에 의해 제한되고 구성된 번들 수와는 무관해요.
그 결과 넉넉한 기본값은 작은 네임스페이스에 저렴하고 큰 네임스페이스에 이득이 돼요. 모든 번들을 차지할 만큼 충분한 토픽이 있는 네임스페이스는 어차피 자동 번들 분할로 유사한 번들 수로 분할됐을 것이고, 더 많은 번들로 시작한다는 것은 그 토픽들이 일련의 분할·언로드 주기 후가 아니라 처음부터 브로커에 걸쳐 분산된다는 뜻일 뿐이에요.
번들 수 선택 (Choose the number of bundles)
로드 매니저는 번들을 옮겨 브로커를 균형 잡으므로, 네임스페이스는 토픽이 고르게 분산되기 위해 브로커 수보다 많은 번들이 필요해요. 번들이 브로커보다 적으면 일부 브로커는 네임스페이스의 번들을 전혀 얻지 못하고, 브로커 수에 가까우면 토픽이 번들로 해시되면서 브로커별 몫이 불균등해져요.
- 토픽과 트래픽을 미리 아는 네임스페이스는 생성 시
--bundles로 크기를 정해요. 번들은 분할할 수는 있지만 병합할 수는 없으므로, 예상 토픽 수가 정당화하는 것보다 훨씬 멀리 가지 마세요. 경험칙으로 1000개 토픽이 있는 네임스페이스는 64개 번들이 16개 브로커에 걸쳐 좋은 분산을 달성해요. - 나머지 모든 것에는 기본 32가 수십 개까지의 브로커 클러스터를 커버해요.
defaultNumberOfNamespaceBundles를 낮추는 것은 네임스페이스를 아주 많이 만들고 네임스페이스당 활성화될 수 있는 번들 수를 상한으로 제한하고 싶을 때만 해요. pulsar/system네임스페이스는 작고 고정된 토픽 집합을 담아요. transaction_coordinator_assign 파티션, 트랜잭션 로그, 확장 가능한 로드 매니저의 내부 토픽, 리소스 사용량 토픽이요. 기본 64개 번들은 트랜잭션 코디네이터를 위해 선택됐어요. 코디네이터는 그 transaction_coordinator_assign 파티션의 번들을 소유한 브로커가 소유해요. 64는 기본 16개 코디네이터 각각이 자체 번들로 해시되는 가장 작은 번들 수여서, 코디네이터가 최대 16개 브로커에 분산되고 한 번에 하나씩 이동될 수 있어요. 16개 번들이면 8개 번들로만 해시돼요. 더 많은 코디네이터(--initial-num-transaction-coordinators)를 실행한다면 클러스터를 초기화할 때--system-namespace-bundle-number로 시스템 네임스페이스를 그에 맞게 크기 조정해요.
번들 분할 (Split bundles)
번들의 부하가 broker.conf의 임계값(loadBalancerNamespaceBundleMaxTopics, loadBalancerNamespaceBundleMaxSessions, loadBalancerNamespaceBundleMaxMsgRate, loadBalancerNamespaceBundleMaxBandwidthMbytes)을 넘어 자라면 로드 매니저가 번들을 둘로 분할하고, 기본적으로 두 절반을 언로드해 다른 브로커에 할당될 수 있게 해요. 자동 분할은 기본적으로 켜져 있고(loadBalancerAutoBundleSplitEnabled=true, loadBalancerAutoUnloadSplitBundlesEnabled=true), 네임스페이스당 loadBalancerNamespaceMaximumBundles(128)개 번들에서 멈춰요. 수동으로도 분할할 수 있어요.
pulsar-admin namespaces split-bundle my-tenant/my-namespace --bundle 0x00000000_0x08000000
분할은 영구적이에요. 번들을 병합하는 연산은 없어요. 분할 알고리즘과 그 임계값은 Bundle splitting과 Split namespace bundles를 참고해요.
번들과 브로커 재시작 (Bundles and broker restarts)
브로커가 종료되면 소유한 모든 번들을 해제해요. 모듈식 로드 매니저에서는 브로커가 소유한 번들을 하나씩 언로드하므로(번들 안의 토픽은 병렬로 닫힘) 브로커의 정상 종료 시간은 소유한 번들 수에 따라 늘어나요. 확장 가능한 로드 매니저에서는 브로커가 동적 설정 loadBalancerServiceUnitStateMaxConcurrentOverrides(기본 64)가 제어하는 동시 소유권 재정의 배치를 사용해 소유권을 새 소유자에게 전송해요. 이는 재정의 배치 크기를 제한하지 초당 전송 속도나 모든 클라이언트 재연결을 제한하지는 않아요. 소유된 번들만 언로드되므로 사용되지 않는 번들은 종료 시간에 추가되지 않아요. 재시작과 그로 인한 리밸런싱을 통제하에 두는 방법은 Rolling upgrade of brokers를 참고해요.
더 알아보기 (Learn more)
- 할당·분할·언로드의 메커니즘은 Broker load balancing | Concepts 문서를 참고해요.
- 분할 알고리즘과 임계값은 Bundle splitting 문서를 참고해요.
- 브로커 재시작이 번들에 미치는 영향은 Rolling upgrade of brokers 문서를 참고해요.
- 네임스페이스와 번들의 개념은 핵심 개념 문서를 참고해요.