브로커 격리

브로커 격리 (Isolate brokers)

Pulsar에서 네임스페이스(보다 정확히 네임스페이스 번들)가 브로커에 동적으로 할당될 때, 네임스페이스 격리 정책은 할당에 사용할 수 있는 브로커 집합을 제한해요. 토픽이 브로커에 할당되기 전에 primary 또는 secondary 정규식을 사용해 네임스페이스 격리 정책을 설정해 원하는 브로커를 선택할 수 있어요.

출처: 문서

본문

Pulsar에서 네임스페이스(보다 정확히 네임스페이스 번들)가 브로커에 동적으로 할당될 때, 네임스페이스 격리 정책은 할당에 사용할 수 있는 브로커 집합을 제한해요. 토픽이 브로커에 할당되기 전에 primary 또는 secondary 정규식을 사용해 네임스페이스 격리 정책을 설정해 원하는 브로커를 선택할 수 있어요.

브로커 주소 매칭 (Match broker addresses)

--primary와 --secondary 정규식은 등록된 브로커 ID의 호스트 이름 또는 주소 부분(포트 제외)과 매칭돼요. 이는 모듈식(modular)과 확장 가능한(extensible) 로드 매니저 모두에 적용돼요. 표현식은 전체 주소와 일치해야 해요. 리스너 이름, URL 스킴, 포트, Kubernetes 라벨은 매칭의 일부가 아니에요.

advertisedListeners는 연결 엔드포인트를 정의하고, internalListenerName은 클러스터 내부 통신용 리스너를 선택해요. 둘 다 격리 정책 매칭에 사용되는 주소를 바꾸지 않아요. 리스너 URL의 호스트 이름도 브로커의 등록된 정체성과 일치하지 않는 한 그 URL로 정규식을 만들지 마세요. advertisedAddress의 끝에 있는 점(trailing dot)은 브로커 ID를 만들 때 제거돼요.

예를 들어 다음 브로커 설정을 생각해볼게요.

advertisedAddress=broker-0.brokers.example.com
internalListenerName=internal
advertisedListeners=internal:pulsar://broker-0.internal.example.com:6650,external:pulsar://broker-0.public.example.com:6650

격리 정규식은 broker-0.brokers.example.com과 일치해야 해요. 예를 들어 broker-[0-9]+[.]brokers[.]example[.]com이요. broker-0.internal.example.com이나 broker-0.public.example.com에는 매칭되지 않아요. advertisedAddress를 비워 두면 같은 리스너 구성에서도 브로커의 해석된 표준 호스트 이름을 대신 사용해요.

정책을 만들기 전에 실제 등록된 ID를 확인해요.

pulsar-admin brokers list my-cluster

broker-0.brokers.example.com:8080 같은 ID라면 broker-0.brokers.example.com과 일치시켜요. Kubernetes에서는 기본 표준 호스트 이름을 쓸 때 보통 파드별 FQDN이에요. 특정 DNS 접미사를 가정하지 말고 출력을 확인해요.

네임스페이스 격리 정책 구성 (Configure a namespace isolation policy)

브로커 예약 (Broker reservation)

정책의 primary 정규식과 일치하는 브로커는 격리 정책이 없는 네임스페이스의 정상 번들 할당에서 제외돼요. secondary 브로커는 정책이 그들을 primary로 나열하지 않는 한 공유 풀에 남아요. 다른 격리 정책이 명시적으로 그 네임스페이스들을 같은 브로커에 허용할 수 있으므로 겹치는 브로커 선택을 확인해요.

롤아웃 예시는 Test the replacement with canary namespaces를 참고해요.

브로커 클러스터의 네임스페이스 격리 정책을 설정하려면 다음 방법 중 하나를 사용할 수 있어요.

pulsar-admin CLI · REST API · Java admin API

pulsar-admin ns-isolation-policy set options

pulsar-admin ns-isolation-policy set options 명령에 대한 자세한 내용은 Pulsar admin docs를 참고해요.

예제:

Apache Pulsar Helm 차트 릴리스가 Kubernetes 네임스페이스 pulsar에 이름 pulsar로 있고, 기본 컴포넌트 이름과 클러스터 도메인 cluster.local을 쓴다고 가정해요. production Pulsar 클러스터의 finance/payments 네임스페이스를 위해 브로커 pulsar-broker-0.pulsar-broker-headless.pulsar.svc.cluster.local과 pulsar-broker-1.pulsar-broker-headless.pulsar.svc.cluster.local을 예약하고, 브로커 오디널(ordinal) 2~19는 secondary 그룹으로 하려면:

pulsar-admin ns-isolation-policy set production payments-brokers \
  --auto-failover-policy-type min_available \
  --auto-failover-policy-params min_limit=1,usage_threshold=80 \
  --namespaces 'finance/payments' \
  --primary 'pulsar-broker-[01][.]pulsar-broker-headless[.]pulsar[.]svc[.]cluster[.]local' \
  --secondary 'pulsar-broker-([2-9]|1[0-9])[.]pulsar-broker-headless[.]pulsar[.]svc[.]cluster[.]local'

따옴표로 감싼 정규식은 완전한 광고 주소로 브로커 오디널 0과 1을 primary로, 2~19를 secondary로 선택해요. [.]는 리터럴 점과 일치해요. secondary 그룹은 정책이 페일오버를 허용할 때 폴백을 제공하고, 다른 정책이 그 브로커를 primary로 예약하지 않는 한 일반 네임스페이스에 계속 사용 가능해요. 클러스터, 네임스페이스, 브로커 주소는 자신의 것으로 바꾸세요.

이 정책을 삭제하려면:

pulsar-admin ns-isolation-policy delete production payments-brokers

삭제가 전파되면 브로커 0과 1은 다른 정책이 여전히 그들을 primary로 예약하지 않는 한, 격리 정책이 없는 네임스페이스의 정상 번들 할당에 적격해져요. 예약된 브로커 그룹을 은퇴시킬 때, 일반 워크로드에서 제외되어야 한다면 브로커가 등록 해제될 때까지 정책을 유지해요. primary 정규식을 나머지 공유 브로커를 덮도록 바꾸는 것은 그 브로커들도 예약하는 것이므로, 정책 제거와 동등하지 않아요.

네임스페이스 격리 엔드포인트는 clusters API의 일부예요. 요청 본문, 파라미터, 응답은 OpenAPI 참고서를 보세요.

Clusters API를 사용해요. PulsarAdmin.clusters()로 접근할 수 있어요. 다음 비동기 메서드가 위 REST 연산에 대응하며, Async 접미사 없는 동기 대응 메서드도 사용할 수 있어요.

정책 업데이트 시 언로드 제어 (Control unloading when updating a policy)

정책 생성 또는 업데이트는 자동 로드 셰딩과 무관하게 네임스페이스를 즉시 언로드할 수 있어요. 이 동작을 제어하려면 ns-isolation-policy set에서 --unload-scope를 사용해요.

통제된 롤아웃을 위해 정책을 만들 때와 이후의 모든 업데이트에서 --unload-scope none을 지정하고, 정책 전파를 기다린 다음 의도한 번들을 명시적으로 이동해요. 자동 로드 셰딩을 비활성화하는 것만으로는 정책이 트리거하는 언로드를 막지 못해요. 반대로 none은 자동 셰딩을 비활성화하지도, 다른 연산이 번들을 언로드하는 것을 막지도 않아요.

changed 범위는 네임스페이스 정규식 엔트리와 primary 브로커 정규식 목록을 비교해요. 모든 기존 번들의 배치는 확인하지 않아요. secondary 브로커 목록이나 페일오버 파라미터만 바꾸면 이 범위에서 언로드가 트리거되지 않아요. 정책 변경과 전송 후 실제 소유권을 확인해요.

secondary 브로커 페일오버 이해 (Understand secondary broker failover)

--auto-failover-policy-type min_available을 사용하면, 등록된 primary 후보 수가 min_limit 아래일 때 모듈식과 확장 가능한 로드 매니저가 secondary 브로커를 적격하게 만들어요. min_limit=1이면 primary 후보가 없을 때 그렇게 돼요. 이 결정은 애플리케이션 상태 검사가 아니라 브로커 멤버십을 사용해요. usage_threshold는 이 후보 수 결정에 로드 기반 페일오버 검사를 추가하지 않아요.

--secondary를 생략하면 정상 할당을 primary 그룹에 국한하지만, 그 그룹을 사용할 수 없으면 네임스페이스에 적격 소유자가 없게 돼요. 정책의 primary와 secondary 그룹 밖의 임의의 공유 브로커로의 폴백은 없어요.

배치와 리밸런싱 고려 사항 (Placement and rebalancing considerations)

• 정책은 네임스페이스 전체를 선택해요. 요청의 비율이나 개별 토픽을 선택하지 않아요. 네임스페이스를 추가하면 처음에 몇 개 번들만 이동해도 그 모든 번들이 선택된 브로커에 적격해져요.
• 정책 간 네임스페이스 정규식이 겹치지 않게 해요. 일치하는 정책은 결합되지 않아요. primary와 secondary 브로커 선택도 감사해서 다른 정책이 의도하지 않은 네임스페이스를 예약된 그룹에 허용하지 않게 해요.
• 명시적 관리 목적지가 배치 필터링을 우회할 수 있어요. 어느 로드 매니저든 번들을 전송하기 전에 모든 --destinationBroker를 의도한 격리 정책에 대해 검증해요.
• 다른 배치 필터를 확인해요. preferLaterVersions 같은 비기본 설정은 혼합 버전 롤아웃 중 브로커 선택에 영향을 줄 수 있어요.
• 격리는 소유권 배치를 제어해요. Shared Services는 여전히 lookup이나 관리 요청을 예약된 브로커로 라우팅할 수 있어요. 브로커는 같은 클러스터 조정과 공유 저장소에 계속 참여해요. 네임스페이스 격리는 별도의 클러스터나 네트워크 보안 경계를 제공하지 않아요.

확장 가능한 로드 매니저는 기본적으로 격리 정책이 있는 번들의 자동 셰딩을 건너뛰는데, loadBalancerSheddingBundlesWithPoliciesEnabled=true가 아니면 그래요. 롤아웃 후 격리 정책을 유지한다면, 전역 로드 셰딩을 복원하는 것만으로는 그 번들을 리밸런싱하지 않아요.

tip

네임스페이스에 속한 모든 데이터가 원하는 부키에 저장되도록 보장하려면 네임스페이스 데이터를 사용자 정의 부키 그룹으로 격리할 수 있어요. 자세한 내용은 configure bookie affinity groups를 참고해요.

더 알아보기 (Learn more)

• 부키 수준 격리는 Isolate bookies 문서를 참고해요.
• Pulsar 격리의 개요와 배포 방식은 Pulsar isolation 문서를 참고해요.
• 격리 정책 관련 명령은 pulsar-admin의 ns-isolation-policy 명령 참고서를 확인해요.
• 롤아웃에서 격리 정책을 사용해 브로커를 교체하는 예시는 canary 네임스페이스 문서를 참고해요.