Apache Pulsar의 엔터프라이즈 수준 기능 - 멀티 테넌시 소개

Apache Pulsar는 원래 Yahoo에서 탄생했습니다. 이는 Yahoo 내의 다양한 부서 간의 데이터 조정 문제를 해결하기 위한 것이었습니다. 따라서 Pulsar는 다중 테넌트 기능이 매우 중요했습니다. 탄생 이후부터 임차권 특성을 고려하고, 이후 구현 과정에서 이를 지속적으로 개선해 나갈 것입니다. 멀티 테넌시(Multi-tenancy) 기능을 통해 데이터를 운영하기 위해 별도의 시스템을 구축하지 않고도 여러 부서가 동일한 데이터를 공유할 수 있어 부서 간 데이터 일관성이 보장되고 유지 관리 비용이 단순화됩니다.

Pulsar 다중 테넌시를 도입하기 전에 일반 시스템이 다중 테넌시를 구현하기 위해 무엇을 해야 하는지 살펴보겠습니다.

Pulsar의 다중 테넌시 설계는 위의 요구 사항을 충족합니다.

p>

아래 그림과 같이 Pulsar 클러스터에는 세 가지 개념이 있습니다. 테넌트(그림의 속성은 이전 이름이었으며 지금은 이를 호출하는 것이 더 일반적입니다. 테넌트), 네임스페이스 및 주제입니다. 이는 pulsar의 주제 이름 지정 구성에서 반영될 수도 있습니다(예: persist://tenant/namespace/topic). Pulsar에서는 테넌트, 네임스페이스 및 주제 이름을 사용하여 주제를 고유하게 식별합니다.

테넌트는 리소스의 격리 단위인 테넌트 이름을 나타냅니다. 하나의 테넌트 아래에 여러 네임스페이스가 있을 수 있습니다. 네임스페이스는 자신이 속한 주제를 관리하는 데 사용됩니다. 보존, 백로그, 속도 제한 등 네임스페이스 수준에서 주제에 해당하는 정책을 설정할 수 있습니다. 네임스페이스 아래에는 여러 주제가 있을 수 있으며 해당 권한도 위에서 아래로 지정됩니다. Pulsar의 멀티 테넌시는 테넌트, 네임스페이스, 토픽을 통해 다단계 관리 시스템을 구성합니다.

서두에서 언급했듯이 멀티 테넌트 시스템은 테넌트 내에서 시스템 수준의 보안을 제공해야 하며, 크게 보면 다음 두 가지로 분류할 수 있습니다.

Pulsar에서는 인증 및 권한 부여 메커니즘을 통해 다중 테넌트 보안이 달성됩니다. 클라이언트가 pulsar 브로커에 연결되면 브로커는 인증 플러그인을 사용하여 클라이언트의 신원을 확인한 다음 문자열 유형의 역할 토큰을 할당합니다. 역할 토큰은 주로 다음과 같은 기능을 가지고 있습니다:

Pulsar는 현재 두 가지 유형의 신원 인증을 지원합니다:

물론 사용자는 자신의 신원 인증 절차를 사용할 수도 있습니다.

신원 인증 시스템이 클라이언트의 역할 토큰을 인식하면 Pulsar 브로커는 인증 시스템을 사용하여 클라이언트에게 현재 수행할 수 있는 작업을 알려줍니다. 인증 작업은 테넌트 수준에서 구성됩니다. 즉, Pulsar 클러스터에서 사용자는 다양한 역할을 기반으로 여러 인증 체계를 설정할 수 있습니다. 특정 권한 작업은 네임스페이스 수준에서 설정되고 관리됩니다. 예를 들어 주제에 생성 또는 소비 권한이 있는지 여부는 네임스페이스 수준에서 제어됩니다. 즉, 테넌트 수준에서 사용자는 어떤 종류의 역할이 어떤 테넌트에 대해 작동할 권한이 있는지 구성할 수 있습니다. 네임스페이스 수준에서 사용자는 특정 주제에 대해 현재 역할이 갖는 권한을 구성할 수 있습니다. 예, 네임스페이스는 주로 포함된 주제의 속성을 관리하는 데 사용됩니다.

인증 및 권한 부여 시스템을 통해 테넌트와 토픽 간의 실행 권한과 같은 문제를 교묘하게 분리하여 테넌트 내에서 시스템 수준 보안을 충족한다는 목적을 달성합니다.

격리는 크게 다음 두 가지 유형으로 나뉜다.

Pulsar에서는 좋은 확장성을 보장하기 위해 스토리지와 컴퓨팅을 분리하는 아키텍처 설계를 채택하고, 스토리지(부키) 컴퓨팅(브로커)은 생산 및 소비가 공유하는 리소스입니다. 더 나은 격리를 달성하기 위해 Pulsar는 스토리지 및 컴퓨팅 계층에서 각각 다른 처리를 수행합니다.

스토리지 측면에서 Apache Pulsar는 또 다른 Apache 최상위 프로젝트인 Bookkeeper를 스토리지 계층으로 사용합니다. Bookie는 Bookkeeper의 인스턴스입니다. Bookie에는 여러 개의 원장이 있으며 각 원장은 Pulsar의 주제에 해당합니다. Bookkeeper 자체의 I/O 분리는 이를 매우 잘 지원할 수 있습니다. 단일 Bookie에는 저널 로그 파일(보통 저널 파일 작성을 위한 전용 저널 디스크가 있음)(LSMTree의 WAL 파일과 유사)이 있으며 모든 쓰기 작업은 내부 추가 형식으로 추가됩니다. . 쓰기가 완료되면 별도의 스레드가 백그라운드에서 정기적으로 저널 파일 데이터를 디스크에 플러시합니다. 이 I/O 아키텍처의 설계는 쓰기 작업과 읽기 작업 간의 격리를 달성하므로 테넌트가 가능한 한 빨리 데이터를 읽을 수 있는 동시에 쓰기 처리량과 대기 시간은 읽기 작업의 영향을 받지 않습니다.

I/O 격리 외에도 다양한 테넌트가 다양한 네임스페이스에 대해 다양한 스토리지 할당량을 구성할 수 있습니다. 테넌트 내의 메시지 크기가 저장 할당량 제한에 도달하면 Pulsar는 메시지 생성 방지, 예외 발생 또는 메시지 삭제 등의 적절한 조치를 취합니다.

SLA를 충족하기 위해 Pulsar는 브로커 수준에서 여러 메커니즘도 제공합니다. 우선, Pulsar 브로커의 모든 작업은 비동기식으로 수행됩니다. 각 브로커가 사용하는 메모리 리소스에는 상한이 있습니다. 브로커가 구성된 CPU 또는 메모리 사용량 임계값에 도달하면 Pulsar는 처리를 위해 더 적은 부하로 트래픽을 브로커로 신속하게 전송합니다. Pulsar에는 이러한 상황을 처리하기 위해 특별히 설계된 구성요소 로드 관리자 구성요소가 있으며, 이는 컴퓨팅과 스토리지의 분리라는 Pulsar의 탁월한 아키텍처 설계의 이점을 활용합니다. 이로 인해 브로커는 거의 무상태 상태가 되며, 브로커 자체에는 어떠한 데이터도 저장하지 않으므로 이 트래픽 부하의 전송 비용이 매우 작고 빠르므로 전송 중에 테넌트의 특성이 훼손될까 걱정할 필요가 없습니다. 교통 부하.

둘째, Pulsar는 메시지 생성과 소비 모두에서 흐름 제어를 구현합니다. 생산자 측에서 테넌트는 현재 메시지가 브로커 및 마권업자에게 전송되는 속도를 구성하여 현재 사용자가 시스템 자체의 메시지 처리 능력보다 더 빠르게 메시지를 보내는 것을 방지할 수 있습니다. 소비자 측에서 테넌트는 현재 브로커가 소비자에게 보낼 수 있는 미해결 메시지 수를 구성할 수 있습니다. 또한 Pulsar는 소비자의 소비 용량이 현재 브로커의 처리 용량보다 커지는 것을 방지하기 위해 브로커가 지정된 속도로 소비자에게 메시지를 전달하도록 제한할 수도 있습니다.

소프트 격리에 언급된 메커니즘은 Pulsar가 브로커 및 마권업자 리소스를 공유할 때 적절한 격리를 보장할 수 있도록 보장합니다. 그러나 경우에 따라 애플리케이션에 물리적 리소스 격리도 필요합니다. Pulsar를 사용하면 특정 브로커로부터 특정 테넌트 또는 네임스페이스를 격리할 수 있습니다. 이렇게 하면 해당 테넌트 또는 네임스페이스가 특정 브로커의 리소스를 완전히 활용할 수 있습니다.

이 옵션은 다양한 구성을 테스트하고 디버그하며 프로덕션에서 발생하는 예상치 못한 상황에 신속하게 대응하는 데도 사용할 수 있습니다. 예를 들어 현재 브로커에서 다른 테넌트의 성능에 영향을 미칠 수 있는 잘못된 동작을 유발할 수 있는 사용자가 있습니다. 이 경우 특정 테넌트를 물리적으로 격리한 다음 식별하거나 교정할 수 있습니다.

브로커의 트래픽을 물리적으로 격리하는 것 외에도 스토리지 관련 서비스도 격리할 수 있습니다. 이 목표를 달성하기 위해 네임스페이스 수준에서 관련 배치 정책을 구성할 수 있습니다.