다중 테넌시

다중 테넌시 (Multi-Tenancy)

이 페이지는 여러 팀·조직이 하나의 Kafka 클러스터를 같이 쓰는 다중 테넌트 환경을 어떻게 구성하고 관리하면 좋을지에 대한 모범 사례를 다뤄요. 토픽 네이밍 구조, 쿼터, ACL 같은 실무 노하우가 중심이에요.

출처: 문서

본문

다중 테넌시 개요 (Multi-Tenancy Overview)

고도로 확장 가능한 이벤트 스트리밍 플랫폼인 Kafka는 많은 사용자가 다양한 팀과 사업부의 광범위한 시스템·애플리케이션을 실시간으로 연결하는 중추 신경계로 사용합니다. 이러한 다중 테넌트 클러스터 환경은 서로 다른 요구의 평화로운 공존을 보장하기 위해 적절한 제어와 관리가 필요합니다. 이 섹션은 SLA/OLA를 충족하고 "소음 이웃(noisy neighbors)"이 일으키는 잠재적 부수 피해를 최소화하는 클러스터 운영에 도움이 되는 공유 환경 구성의 기능과 모범 사례를 강조합니다.

다중 테넌시는 다면적인 주제이며, 여기에는 다음이 포함되지만 이에 국한되지는 않습니다.

테넌트용 사용자 공간(namespace라고도 함) 생성.
데이터 보존 정책 등으로 토픽 구성.
암호화·인증·인가로 토픽과 클러스터 보안.
쿼터와 요율 제한으로 테넌트 격리.
모니터링과 계측(metering).
클러스터 간 데이터 공유(지리적 복제 참고).

토픽 네이밍으로 테넌트용 사용자 공간(namespace) 만들기

다중 테넌트 클러스터를 운영하는 Kafka 관리자는 보통 각 테넌트에 대한 사용자 공간을 정의해야 합니다. 이 섹션의 목적상 "사용자 공간"은 단일 엔티티나 사용자의 관리 아래 그룹화된 토픽의 모음입니다.

Kafka에서 데이터의 주요 단위는 토픽입니다. 사용자는 각 토픽을 만들고 이름을 지을 수 있습니다. 삭제도 할 수 있지만, 토픽 이름을 직접 바꾸는 것은 불가능합니다. 토픽 이름을 바꾸려면 새 토픽을 만들고 원래 토픽에서 새 토픽으로 메시지를 옮긴 다음 원래 토픽을 삭제해야 합니다. 이를 고려해 계층적 토픽 네이밍 구조에 기반한 논리적 공간을 정의하는 것이 권장됩니다. 이 설정을 접두사 ACL(Pre Fixed ACL) 같은 보안 기능과 결합하면 다른 공간과 테넌트를 격리하면서도 클러스터의 데이터 보안을 위한 관리 오버헤드를 최소화할 수 있습니다.

이러한 논리적 사용자 공간은 여러 방식으로 그룹화할 수 있으며, 구체적인 선택은 조직이 Kafka 클러스터를 어떻게 사용하는 것을 선호하는지에 따라 달라집니다. 가장 흔한 그룹화는 다음과 같습니다.

팀 또는 조직 단위로: 여기서 팀이 주요 집계 단위입니다. 팀이 Kafka 인프라의 주요 사용자인 조직에서는 이 그룹화가 가장 좋을 수 있습니다.

예시 토픽 네이밍 구조:

<organization>.<team>.<dataset>.<event-name> (예: "acme.infosec.telemetry.logins")

프로젝트 또는 제품 단위로: 여기서 팀이 하나 이상의 프로젝트를 관리합니다. 프로젝트마다 자격 증명이 다르므로 모든 제어와 설정은 항상 프로젝트와 관련됩니다.

예시 토픽 네이밍 구조:

<project>.<product>.<event-name> (예: "mobility.payments.suspicious")

일반적으로 시간이 지나며 바뀔 가능성이 있는 정보(예: 의도된 컨슈머 이름)나, 다른 곳에서 이미 알 수 있는 기술 세부 사항·메타데이터(예: 토픽의 파티션 수와 기타 구성 설정) 같은 것은 토픽 이름에 넣지 않아야 합니다.

토픽 네이밍 구조를 강제하려면 여러 옵션이 있습니다.

접두사 ACL(KIP-290 참고)을 사용해 토픽 이름의 공통 접두사를 강제. 예를 들어 팀 A는 이름이 payments.teamA.로 시작하는 토픽만 만들도록 허용될 수 있음.
커스텀 CreateTopicPolicy(KIP-108 및 설정 create.topic.policy.class.name 참고)를 정의해 엄격한 네이밍 패턴을 강제. 이러한 정책은 가장 유연하며 조직의 요구에 맞는 복잡한 패턴과 규칙을 다룰 수 있음.
ACL로 일반 사용자의 토픽 생성을 거부해 비활성화하고, 외부 프로세스(예: 스크립팅 또는 선호하는 자동화 툴킷)가 사용자를 대신해 토픽을 만들도록 의존.
또한 브로커 구성에서 auto.create.topics.enable=false로 설정해 Kafka의 요청 시 토픽 자동 생성 기능을 비활성화하는 것도 유용할 수 있음. 단, 이 옵션에만 의존해서는 안 됨.

토픽 구성: 데이터 보존 그 이상

Kafka의 구성은 세분성이 매우 높아 유연하며, 관리자가 다중 테넌트 클러스터를 설정하는 데 도움이 되는 수많은 토픽별 구성 설정을 지원합니다. 예를 들어 관리자는 종종 retention.bytes(크기)와 retention.ms(시간) 같은 설정으로 토픽에 데이터가 얼마나, 얼마나 오래 저장될지 제어하는 데이터 보존 정책을 정의해야 합니다. 이는 클러스터 내 저장 공간 소비를 제한하고 GDPR 같은 법적 요구 사항을 준수하는 데 도움이 됩니다.

클러스터와 토픽 보안: 인증, 인가, 암호화

문서에 모든 Kafka 배포에 적용되는 보안 전용 챕터가 있으므로, 이 섹션은 다중 테넌트 환경에 대한 추가 고려 사항에 초점을 맞춥니다.

Kafka의 보안 설정은 관계형 데이터베이스와 전통적인 메시징 시스템 같은 다른 클라이언트-서버 데이터 시스템을 관리자가 보호하는 방식과 유사한 세 가지 주요 범주로 나뉩니다.

Kafka 브로커와 Kafka 클라이언트 사이, 브로커 사이, 브로커와 기타 선택 도구 사이에 전송되는 데이터의 암호화.
Kafka 브로커에 대한 Kafka 클라이언트·애플리케이션 연결 및 브로커 간 연결의 인증.
토픽 생성·삭제·구성 변경, 토픽에 이벤트 쓰기·읽기, ACL 생성·삭제 같은 클라이언트 작업의 인가. 관리자는 CreateTopicPolicy와 AlterConfigPolicy 같은 추가 제한을 두기 위한 커스텀 정책도 정의할 수 있음(설정 create.topic.policy.class.name, alter.config.policy.class.name 참고).

다중 테넌트 Kafka 환경을 보호할 때 가장 흔한 관리 작업은 세 번째 범주(인가), 즉 특정 토픽과 클러스터 내 사용자가 저장한 데이터에 대한 접근을 허용하거나 거부하는 사용자/클라이언트 권한을 관리하는 것입니다. 이 작업은 주로 접근 제어 목록(ACL) 설정을 통해 수행됩니다. 특히 다중 테넌트 환경의 관리자는 이전 섹션에서 설명한 계층적 토픽 네이밍 구조를 도입함으로써 큰 혜택을 얻습니다. 접두사 ACL(--resource-pattern-type Prefixed)로 토픽 접근을 편리하게 제어할 수 있기 때문입니다. 이는 다중 테넌트 환경에서 토픽 보안의 관리 오버헤드를 크게 줄여줍니다. 관리자는 더 높은 개발자 편의성(더 관대한 권한, 더 적고 넓은 ACL 사용)과 더 강한 보안(더 엄격한 권한, 더 많고 좁은 ACL 사용) 사이에서 자신만의 트레이드오프를 선택할 수 있습니다.

다음 예제에서 ACME 기업 InfoSec 팀의 새 구성원인 Alice 사용자에게 이름이 "acme.infosec."으로 시작하는 모든 토픽(예: "acme.infosec.telemetry.logins"와 "acme.infosec.syslogs.events")에 대한 쓰기 권한을 부여합니다.

# Grant permissions to user Alice
$ bin/kafka-acls.sh \
    --bootstrap-server localhost:9092 \
    --add --allow-principal User:Alice \
    --producer \
    --resource-pattern-type prefixed --topic acme.infosec.

같은 공유 클러스터에서 서로 다른 고객을 격리하는 데도 이 접근 방식을 사용할 수 있습니다.

테넌트 격리: 쿼터, 요율 제한, 스로틀링

다중 테넌트 클러스터는 일반적으로 쿼터(quota)로 구성해야 합니다. 쿼터는 사용자(테넌트)가 매우 높은 데이터 볼륨을 쓰거나 읽거나, 브로커에 과도하게 높은 속도로 요청을 만들어 클러스터 리소스를 과도하게 소비하는 것을 방지합니다. 이는 네트워크 포화를 일으키고 브로커 리소스를 독점하며 다른 클라이언트에 영향을 줄 수 있습니다. 공유 환경에서 이러한 현상은 모두 피하고 싶은 것입니다.

클라이언트 쿼터: Kafka는 (사용자 별 principal) 클라이언트 쿼터의 여러 유형을 지원합니다. 클라이언트의 쿼터는 클라이언트가 어떤 토픽에 쓰고 읽는지와 무관하게 적용되므로, 다중 테넌트 클러스터에서 리소스를 할당하는 편리하고 효과적인 도구입니다. 예를 들어 요청율 쿼터는 해당 사용자에 대한 브로커의 요청 처리 경로에 브로커가 쓰는 시간을 제한해 사용자의 브로커 CPU 사용 영향력을 제한하는 데 도움이 되며, 그 이후에는 스로틀링이 발동합니다. 많은 상황에서 요청율 쿼리로 사용자를 격리하는 것은 입·출력 네트워크 대역폭 쿼터를 설정하는 것보다 다중 테넌트 클러스터에서 더 큰 영향력을 가집니다. 요청 처리를 위한 과도한 브로커 CPU 사용이 브로커가 서비스할 수 있는 유효 대역폭을 줄이기 때문입니다. 또한 관리자는 토픽 작업(create, delete, alter)에 대한 쿼터도 정의해, 매우 높은 동시성의 토픽 작업에 Kafka 클러스터가 압도되는 것을 방지할 수 있습니다(KIP-599와 쿼터 유형 controller_mutation_rate 참고).

서버 쿼터: Kafka는 브로커 측 쿼터의 여러 유형도 지원합니다. 예를 들어 관리자는 브로커가 새 연결을 수락하는 속도에 제한을 두거나, 브로커당 최대 연결 수를 설정하거나, 특정 IP 주소에서 허용되는 최대 연결 수를 설정할 수 있습니다.

자세한 내용은 쿼터 개요와 쿼터 설정 방법을 참고하세요.

모니터링과 계측 (Monitoring and Metering)

모니터링은 문서의 다른 곳에서 다루는 더 넓은 주제입니다. 모든 Kafka 환경의 관리자, 특히 다중 테넌트 환경의 관리자는 이 지침에 따라 모니터링을 설정해야 합니다. Kafka는 실패한 인증 시도 속도, 요청 지연시간, 컨슈머 랙, 총 컨슈머 그룹 수, 이전 섹션에서 설명한 쿼터에 대한 지표 등 광범위한 지표를 지원합니다.

예를 들어 모니터링은 토픽-파티션의 크기(JMX 지표 kafka.log.Log.Size.<TOPIC-NAME>)를 추적하도록 구성할 수 있으며, 따라서 토픽에 저장된 총 데이터 크기도 추적할 수 있습니다. 그런 다음 공유 클러스터의 테넌트가 너무 많은 저장 공간을 사용하려 할 때 알림을 정의할 수 있습니다.

다중 테넌시와 지리적 복제 (Multi-Tenancy and Geo-Replication)

Kafka는 서로 다른 지리적 지역, 데이터센터 등에 위치할 수 있는 서로 다른 클러스터 간에 데이터를 공유하게 해줍니다. 재해 복구 같은 사용 사례 외에도, 이 기능은 다중 테넌트 설정이 클러스터 간 데이터 공유를 요구할 때 유용합니다. 자세한 내용은 지리적 복제(교차 클러스터 데이터 미러링) 섹션을 참고하세요.

추가 고려 사항 (Further considerations)

데이터 계약: 클러스터에서 데이터의 프로듀서와 컨슈머 사이에 이벤트 스키마를 사용한 데이터 계약을 정의해야 할 수도 있습니다. 이는 Kafka에 기록된 이벤트가 항상 올바르게 읽힐 수 있게 보장하고, 잘못된 형식이거나 손상된 이벤트가 기록되는 것을 방지합니다. 이를 달성하는 가장 좋은 방법은 소위 스키마 레지스트리(schema registry)를 클러스터와 함께 배포하는 것입니다. (Kafka에는 스키마 레지스트리가 포함되어 있지 않지만, 타사 구현을 사용할 수 있습니다.) 스키마 레지스트리는 이벤트 스키마를 관리하고 스키마를 토픽에 매핑하므로, 프로듀서는 어떤 토픽이 어떤 타입(스키마)의 이벤트를 받는지, 컨슈머는 토픽의 이벤트를 어떻게 읽고 파싱하는지 알 수 있습니다. 일부 레지스트리 구현은 스키마 진화, 모든 스키마의 히스토리 저장, 스키마 호환성 설정 같은 추가 기능을 제공합니다.

더 알아보기 (Learn more)

계층적 토픽 네이밍과 접두사 ACL 조합이 다중 테넌트 보안의 핵심이에요.
쿼터를 설정해 "소음 이웃"이 클러스터 리소스를 독점하지 못하게 막을 수 있어요.
클러스터 간 데이터 공유는 지리적 복제에서 다뤄요.