RBAC과 Workload Management

ClickHouse 분류

Feature

Type

Lab

작성자

Ken

데이터 플랫폼을 운영하다 보면 누구나 한 번쯤 이런 상황을 겪게 됩니다. 분석가가 실행한 무거운 ad-hoc 쿼리가 실시간 대시보드를 느리게 만들거나, 개발자가 실수로 운영 테이블을 삭제하거나, 특정 사용자가 민감한 고객 정보에 무단으로 접근하는 상황 말입니다.

ClickHouse는 이러한 문제를 해결하기 위해 강력한 RBAC(Role-Based Access Control)와 워크로드 매니지먼트 기능을 제공합니다. 이 글에서는 ClickHouse Cloud 환경에서 실제로 이 기능들을 구현하고 테스트한 경험을 바탕으로, 권한 제어부터 리소스 관리까지 테스트해보았습니다.

왜 권한 제어와 워크로드 관리가 필요한가?
ClickHouse RBAC 구조 이해하기
실습 환경과 시나리오
Role 생성과 권한 부여
사용자 생성과 역할 할당
Row-Level Security 구현
Column-Level Security 구현
Settings Profile로 쿼리 리소스 제한하기
Quota로 시간 기반 사용량 제한하기
Workload Scheduling으로 리소스 우선순위 관리하기
모니터링과 트러블슈팅
Best Practices
RBAC Best Practices
Workload Management Best Practices
정리
참고 자료

왜 권한 제어와 워크로드 관리가 필요한가?

현대의 데이터 플랫폼은 다양한 역할의 사용자들이 동시에 접근합니다. 데이터 엔지니어는 ETL 파이프라인을 운영하고, 분석가는 복잡한 쿼리를 실행하며, BI 개발자는 대시보드를 구축하고, 외부 파트너는 제한된 데이터에만 접근해야 합니다.

이런 환경에서 발생할 수 있는 문제들을 살펴보면, 첫째로 보안 문제가 있습니다. 민감한 고객 정보(이메일, 전화번호 등)가 권한 없는 사용자에게 노출될 위험이 있습니다. 둘째로 성능 문제입니다. 무거운 분석 쿼리가 실시간 서비스에 영향을 줄 수 있습니다. 셋째로 운영 안정성 문제입니다. 실수로 인한 데이터 삭제나 변경이 발생할 수 있습니다.

ClickHouse는 이 모든 문제를 해결할 수 있는 도구를 제공합니다. RBAC로 세분화된 권한을 제어하고, Settings Profile로 쿼리 리소스를 제한하며, Quota로 사용량을 제한하고, Workload Scheduling으로 CPU와 IO 리소스를 분배할 수 있습니다.

ClickHouse RBAC 구조 이해하기

ClickHouse의 접근 제어는 여러 구성요소가 계층적으로 연결되어 작동합니다.

User(사용자) 는 개별 사용자 또는 애플리케이션 계정입니다. 비밀번호, SHA256, SSL 인증서, LDAP, Kerberos 등 다양한 인증 방식을 지원하며, HOST 제한으로 접속 IP를 제어할 수 있습니다.
Role(역할) 은 권한의 논리적 그룹입니다. 역할은 상속이 가능하여 계층 구조를 만들 수 있습니다. 권장되는 방식은 권한을 Role에 부여하고, Role을 User에게 할당하는 것입니다.
Privilege(권한) 는 SELECT, INSERT, ALTER, DROP, CREATE 등의 세분화된 작업 권한입니다. 데이터베이스, 테이블, 심지어 컬럼 수준까지 제어가 가능합니다.
Row Policy(행 수준 보안) 는 특정 조건에 맞는 행만 접근할 수 있도록 제한합니다. 멀티 테넌트 환경에서 데이터를 격리할 때 특히 유용합니다.
Settings Profile은 쿼리 실행 관련 설정의 그룹으로, max_memory_usage나 max_execution_time 등을 제한할 수 있습니다.
Quota는 시간 기반 사용량 제한으로, 쿼리 수, 결과 행 수, 읽기 바이트 등을 기간별로 제한하여 리소스 남용을 방지합니다.

실습 환경과 시나리오

이 글의 모든 예제는 ClickHouse Cloud v25.8.1 환경에서 테스트되었습니다. 실습을 위해 가상의 데이터 분석 조직을 설정했습니다.

조직 구조는 다음과 같습니다. Data Engineers는 전체 접근 권한을 가지며 ETL 파이프라인을 담당합니다. Data Analysts는 읽기와 제한된 쓰기 권한으로 데이터 분석을 수행합니다. BI Developers는 읽기 전용 권한으로 대시보드를 개발합니다. External Partners는 특정 데이터에만 제한적으로 접근하여 협업합니다.

먼저 테스트용 데이터베이스와 테이블을 생성합니다.

CREATE DATABASE IF NOT EXISTS rbac_demo;

CREATE TABLE rbac_demo.sales (
    id UInt64,
    region String,
    product String,
    amount Decimal(18,2),
    sale_date Date,
    customer_id UInt64
) ENGINE = MergeTree()
ORDER BY (region, sale_date);

CREATE TABLE rbac_demo.customers (
    id UInt64,
    name String,
    email String,      -- 민감 정보
    phone String,      -- 민감 정보
    region String,
    created_at DateTime
) ENGINE = MergeTree()
ORDER BY id;

샘플 데이터는 APAC, EMEA, AMERICAS 세 지역에 걸쳐 8건의 판매 데이터와 5건의 고객 데이터를 삽입했습니다.

Role 생성과 권한 부여

각 역할에 맞는 권한을 정의합니다. 핵심 원칙은 최소 권한 원칙(Principle of Least Privilege)입니다.

-- 읽기 전용 역할 (BI 개발자용)
CREATE ROLE IF NOT EXISTS rbac_demo_readonly;
GRANT SELECT ON rbac_demo.sales TO rbac_demo_readonly;
GRANT SELECT ON rbac_demo.customers TO rbac_demo_readonly;

-- 분석가 역할 (읽기 + 임시 테이블)
CREATE ROLE IF NOT EXISTS rbac_demo_analyst;
GRANT SELECT ON rbac_demo.* TO rbac_demo_analyst;
GRANT CREATE TEMPORARY TABLE ON *.* TO rbac_demo_analyst;

-- 데이터 엔지니어 역할 (전체 권한)
CREATE ROLE IF NOT EXISTS rbac_demo_engineer;
GRANT SELECT, INSERT, ALTER, CREATE TABLE, DROP TABLE,
      TRUNCATE, OPTIMIZE ON rbac_demo.* TO rbac_demo_engineer;

-- 외부 파트너 역할 (특정 컬럼만)
CREATE ROLE IF NOT EXISTS rbac_demo_partner;
GRANT SELECT(id, region, product, amount, sale_date)
      ON rbac_demo.sales TO rbac_demo_partner;

여기서 주목할 점은 파트너 역할입니다. SELECT(컬럼명) 문법으로 특정 컬럼에만 접근 권한을 부여했습니다. 이렇게 하면 customer_id 같은 내부 정보는 파트너에게 노출되지 않습니다.

ClickHouse Cloud에서는 GRANT ALL이 일부 SYSTEM 권한을 포함하지 않을 수 있으므로, 필요한 권한을 명시적으로 나열하는 것이 좋습니다.

사용자 생성과 역할 할당

이제 각 역할에 맞는 사용자를 생성합니다.

CREATE USER IF NOT EXISTS demo_bi_user
    IDENTIFIED BY 'SecurePass123!'
    DEFAULT ROLE rbac_demo_readonly;

CREATE USER IF NOT EXISTS demo_analyst
    IDENTIFIED WITH sha256_password BY 'AnalystPass456!'
    DEFAULT ROLE rbac_demo_analyst;

CREATE USER IF NOT EXISTS demo_engineer
    IDENTIFIED BY 'EngineerPass789!'
    DEFAULT ROLE rbac_demo_engineer;

CREATE USER IF NOT EXISTS demo_partner
    IDENTIFIED BY 'PartnerPass000!'
    HOST IP '0.0.0.0/0'
    DEFAULT ROLE rbac_demo_partner;

프로덕션 환경에서는 HOST IP를 반드시 특정 IP 대역으로 제한해야 합니다. 예를 들어 HOST IP '192.168.1.0/24'와 같이 설정하면 해당 네트워크에서만 접속이 가능합니다.

Row-Level Security 구현

Row Policy는 ClickHouse RBAC의 가장 강력한 기능 중 하나입니다. 사용자가 쿼리를 실행할 때 자동으로 필터 조건이 적용되어, 허용된 데이터만 볼 수 있습니다.

-- 파트너는 APAC 지역 데이터만 접근 가능
CREATE ROW POLICY IF NOT EXISTS apac_only_policy
ON rbac_demo.sales
FOR SELECT
USING region = 'APAC'
TO rbac_demo_partner;

-- 다른 역할들은 모든 지역 접근 가능
CREATE ROW POLICY IF NOT EXISTS all_regions_policy
ON rbac_demo.sales
FOR SELECT
USING 1 = 1
TO rbac_demo_analyst, rbac_demo_engineer, rbac_demo_readonly;

이 설정의 결과로 demo_partner가 SELECT * FROM rbac_demo.sales를 실행하면, ClickHouse는 내부적으로 WHERE region = 'APAC' 조건을 자동으로 추가합니다. 전체 8건의 데이터 중 APAC 지역의 4건만 반환됩니다.

중요한 점은 사용자가 이 필터가 적용된 것을 알 수 없다는 것입니다. 쿼리 결과만 보면 마치 테이블에 APAC 데이터만 있는 것처럼 보입니다. 이런 투명성 덕분에 멀티 테넌트 환경에서 데이터 격리를 구현할 때 이상적입니다.

Column-Level Security 구현

민감한 정보를 보호하기 위해 컬럼 수준의 접근 제어도 구현할 수 있습니다. 분석가가 고객 이름과 지역은 볼 수 있지만, 이메일과 전화번호는 볼 수 없도록 설정합니다.

-- 분석가와 BI 사용자의 customers 테이블 권한 재설정
REVOKE SELECT ON rbac_demo.customers FROM rbac_demo_analyst;
REVOKE SELECT ON rbac_demo.customers FROM rbac_demo_readonly;

-- 민감 정보를 제외한 컬럼만 접근 허용
GRANT SELECT(id, name, region, created_at)
      ON rbac_demo.customers TO rbac_demo_analyst;
GRANT SELECT(id, name, region, created_at)
      ON rbac_demo.customers TO rbac_demo_readonly;

이제 분석가가 SELECT * FROM rbac_demo.customers를 실행하면 권한 에러가 발생합니다. 하지만 SELECT id, name, region FROM rbac_demo.customers는 정상적으로 실행됩니다.

데이터 엔지니어는 모든 컬럼에 접근할 수 있으므로, PII(개인식별정보) 관련 작업이 필요할 때 적절한 권한을 가진 인원만 처리할 수 있습니다.

Settings Profile로 쿼리 리소스 제한하기

Settings Profile은 단일 쿼리의 리소스 사용량을 제한합니다. 역할별로 적절한 제한을 설정하면 한 사용자의 무거운 쿼리가 전체 시스템에 영향을 주는 것을 방지할 수 있습니다.

-- 분석가용 프로필
CREATE SETTINGS PROFILE IF NOT EXISTS demo_analyst_profile
SETTINGS
    max_memory_usage = 10000000000,    -- 10GB
    max_execution_time = 300,           -- 5분
    max_threads = 4,
    max_rows_to_read = 100000000,       -- 1억 행
    max_result_rows = 1000000,          -- 100만 행
    readonly = 1;

-- BI 사용자용 프로필 (더 제한적)
CREATE SETTINGS PROFILE IF NOT EXISTS demo_bi_profile
SETTINGS
    max_memory_usage = 5000000000,      -- 5GB
    max_execution_time = 60,            -- 1분
    max_threads = 2,
    max_result_rows = 100000,           -- 10만 행
    readonly = 1;

-- 데이터 엔지니어용 프로필 (관대함)
CREATE SETTINGS PROFILE IF NOT EXISTS demo_engineer_profile
SETTINGS
    max_memory_usage = 50000000000,     -- 50GB
    max_execution_time = 3600,          -- 1시간
    max_threads = 16;

-- 파트너용 프로필 (가장 제한적)
CREATE SETTINGS PROFILE IF NOT EXISTS demo_partner_profile
SETTINGS
    max_memory_usage = 2000000000,      -- 2GB
    max_execution_time = 30,            -- 30초
    max_threads = 2,
    max_result_rows = 10000,            -- 1만 행
    readonly = 1;

프로필을 역할에 적용합니다.

ALTER ROLE rbac_demo_analyst SETTINGS PROFILE demo_analyst_profile;
ALTER ROLE rbac_demo_readonly SETTINGS PROFILE demo_bi_profile;
ALTER ROLE rbac_demo_engineer SETTINGS PROFILE demo_engineer_profile;
ALTER ROLE rbac_demo_partner SETTINGS PROFILE demo_partner_profile;

이제 분석가가 접속하여 SELECT getSetting('max_memory_usage')를 실행하면 10000000000(10GB)이 반환됩니다. 만약 10GB를 초과하는 메모리를 사용하는 쿼리를 실행하면 자동으로 중단됩니다.

Quota로 시간 기반 사용량 제한하기

Settings Profile이 단일 쿼리를 제한한다면, Quota는 일정 기간 동안의 총 사용량을 제한합니다.

-- 분석가용 Quota (시간당 제한)
CREATE QUOTA IF NOT EXISTS demo_analyst_quota
FOR INTERVAL 1 hour
MAX queries = 100,
    query_selects = 80,
    result_rows = 10000000,
    read_rows = 1000000000,
    execution_time = 1800
TO rbac_demo_analyst;

-- BI 사용자용 Quota
CREATE QUOTA IF NOT EXISTS demo_bi_quota
FOR INTERVAL 1 hour
MAX queries = 200,
    result_rows = 1000000,
    execution_time = 600
TO rbac_demo_readonly;

-- 데이터 엔지니어용 Quota (일 단위)
CREATE QUOTA IF NOT EXISTS demo_engineer_quota
FOR INTERVAL 1 day
MAX queries = 1000,
    read_bytes = 1000000000000,
    execution_time = 36000
TO rbac_demo_engineer;

Settings Profile과 Quota를 함께 사용하면 효과적인 리소스 관리가 가능합니다. Settings Profile은 "이 쿼리가 너무 무겁지 않은가?"를 검사하고, Quota는 "이 사용자가 오늘 리소스를 너무 많이 사용하지 않았는가?"를 검사합니다.

Quota 사용량은 system.quota_usage 테이블에서 확인할 수 있습니다.

SELECT
    quota_name,
    queries,
    max_queries,
    execution_time,
    max_execution_time
FROM system.quota_usage
WHERE quota_name LIKE 'demo_%';

Workload Scheduling으로 리소스 우선순위 관리하기

ClickHouse 25.4부터 도입된 Workload Scheduling은 CPU 슬롯 스케줄링을 지원합니다. 이 기능을 사용하면 워크로드 간에 리소스를 공정하게 분배하고 우선순위를 설정할 수 있습니다.

-- CPU 리소스 정의
CREATE RESOURCE IF NOT EXISTS cpu (MASTER THREAD, WORKER THREAD);

-- 워크로드 계층 생성
CREATE WORKLOAD IF NOT EXISTS all;

CREATE WORKLOAD IF NOT EXISTS demo_admin IN all
SETTINGS max_concurrent_threads = 10;

CREATE WORKLOAD IF NOT EXISTS demo_production IN all
SETTINGS max_concurrent_threads = 80;

-- production 하위 워크로드들
CREATE WORKLOAD IF NOT EXISTS demo_realtime IN demo_production
SETTINGS max_concurrent_threads = 30, weight = 5;

CREATE WORKLOAD IF NOT EXISTS demo_analytics IN demo_production
SETTINGS max_concurrent_threads = 40, weight = 9;

CREATE WORKLOAD IF NOT EXISTS demo_adhoc IN demo_production
SETTINGS max_concurrent_threads = 20, weight = 1;

이 설정으로 다음과 같은 계층 구조가 만들어집니다.

all (root)
├── demo_admin (threads: 10)
└── demo_production (threads: 80)
    ├── demo_analytics (weight: 9)  ← 최고 우선순위
    ├── demo_realtime (weight: 5)   ← 중간 우선순위
    └── demo_adhoc (weight: 1)      ← 최저 우선순위

weight 값이 클수록 높은 우선순위를 가집니다. CPU 리소스가 부족할 때 demo_analytics 워크로드의 쿼리가 demo_adhoc보다 9배 더 많은 CPU 시간을 할당받습니다.

쿼리 실행 시 워크로드를 지정합니다.

-- 중요한 분석 쿼리 (높은 우선순위)
SELECT count(*) FROM large_table
SETTINGS workload = 'demo_analytics';

-- ad-hoc 탐색 쿼리 (낮은 우선순위)
SELECT * FROM large_table WHERE condition
SETTINGS workload = 'demo_adhoc';

모니터링과 트러블슈팅

설정이 올바르게 적용되었는지 확인하고 문제를 진단하기 위한 핵심 쿼리들입니다.

사용자 권한 확인은 다음과 같이 합니다.

-- 특정 사용자의 권한 확인
SHOW GRANTS FOR demo_analyst;

-- 역할별 권한 상세 조회
SELECT
    role_name,
    access_type,
    database,
    table,
    column
FROM system.grants
WHERE role_name LIKE 'rbac_demo%'
ORDER BY role_name, access_type;

Row Policy 적용 확인은 이렇게 합니다.

SELECT
    policy_name,
    short_name as table,
    select_filter,
    apply_to_all,
    apply_to_list
FROM system.row_policies
WHERE database = 'rbac_demo';

사용자별 쿼리 통계 조회는 다음 쿼리를 사용합니다.

SELECT
    user,
    count() as query_count,
    countIf(type = 'QueryFinish') as successful,
    countIf(type = 'ExceptionWhileProcessing') as failed,
    round(avg(query_duration_ms), 2) as avg_duration_ms,
    formatReadableSize(sum(memory_usage)) as total_memory
FROM system.query_log
WHERE event_time > now() - INTERVAL 1 HOUR
  AND user LIKE 'demo_%'
GROUP BY user;

일반적인 문제 해결 방법도 알아두면 좋습니다. "Access Denied" 에러가 발생하면 SHOW GRANTS FOR username으로 해당 사용자의 권한을 확인합니다. 쿼리가 예상보다 느리거나 중단되면 SELECT * FROM system.quota_usage로 Quota 한도에 도달했는지 확인합니다. Row Policy가 작동하지 않는 것 같으면 system.row_policies 테이블에서 USING 조건이 올바른지 확인합니다.

Best Practices

실제 프로덕션 환경에 적용할 때 권장되는 사항들을 정리했습니다.

RBAC Best Practices

첫째, 최소 권한 원칙을 적용합니다. 필요한 최소한의 권한만 부여하고, 정기적으로 권한을 감사하여 불필요한 권한을 제거합니다.

둘째, Role 기반으로 관리합니다. 사용자에게 직접 권한을 부여하지 말고 반드시 Role을 통해 관리합니다. 권한 변경이 필요할 때 Role만 수정하면 모든 사용자에게 적용됩니다.

셋째, 명확한 네이밍 컨벤션을 사용합니다. {env}_{team}_{access_level} 형식을 권장합니다. 예를 들어 prod_analytics_readonly, dev_engineering_admin과 같이 명명합니다.

넷째, 민감 데이터에는 Row Policy를 적용합니다. 멀티 테넌트 환경이나 지역별 데이터 격리가 필요한 경우 반드시 Row Policy를 사용합니다.

Workload Management Best Practices

첫째, 티어별로 프로필을 설계합니다. Real-time 워크로드는 5GB 메모리, 30초 제한, 4 스레드로 빠른 응답을 보장합니다. Interactive 워크로드는 20GB 메모리, 5분 제한, 8 스레드로 분석 쿼리를 지원합니다. Batch 워크로드는 100GB 메모리, 1시간 제한, 32 스레드로 ETL 작업을 처리합니다.

둘째, 이중 제한을 적용합니다. 시간당 Quota와 일당 Quota를 동시에 적용하면 버스트 사용과 지속적인 과사용을 모두 방지할 수 있습니다.

셋째, 워크로드를 분리합니다. 실시간 대시보드, 분석 쿼리, ad-hoc 탐색을 별도의 워크로드로 분리하고 적절한 우선순위를 부여합니다.

정리

이 글에서 다룬 ClickHouse의 권한 제어와 워크로드 매니지먼트 기능을 요약하면 다음과 같습니다.

RBAC는 User, Role, Privilege의 계층 구조로 권한을 관리합니다. Row Policy로 행 수준 보안을 구현하고, Column-Level Grant로 민감 정보를 보호할 수 있습니다.

Settings Profile은 단일 쿼리의 메모리, 실행 시간, 스레드 수를 제한합니다. 역할별로 다른 프로필을 적용하여 리소스 사용을 차별화할 수 있습니다.

Quota는 시간 기반으로 총 사용량을 제한합니다. Settings Profile과 함께 사용하면 효과적인 리소스 관리가 가능합니다.

Workload Scheduling은 ClickHouse 25.4 이상에서 CPU 슬롯 스케줄링을 제공합니다. weight 파라미터로 워크로드 간 우선순위를 설정할 수 있습니다.

이 모든 기능은 SQL 명령어로 관리할 수 있으며, ClickHouse Cloud에서 완벽하게 지원됩니다. 실제 프로덕션 환경에 적용할 때는 테스트 환경에서 충분히 검증한 후 점진적으로 적용하는 것을 권장합니다.

참고 자료

ClickHouse Access Rights Documentation
Settings Profiles
Quotas
Workload Scheduling
ClickHouse 25.4 Release - CPU Scheduling

활용 코드

clickhouse-hols/workload/rbac-workloadmanagement at main · litkhai/clickhouse-hols

ClickHouse Hands-on Labs . Contribute to litkhai/clickhouse-hols development by creating an account on GitHub.

github.com

clickhouse-hols/workload/rbac-workloadmanagement at main · litkhai/clickhouse-hols