Read Original
#Backend

StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기

StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기
01

Summary

"누구의 쿼리를 먼저 살릴 것인가?" 토스의 StarRocks 멀티테넌트 생존 전략

SLA 사수를 위한 CPU 우선순위 설계부터 물리 코어 격리까지, OLAP 운영의 정수를 담다

토스 Data Online Processing 팀이 실시간 OLAP 엔진인 StarRocks를 운영하며 겪은 리소스 격리 최적화 과정을 상세히 다룹니다. 서비스 쿼리와 배치 작업이 충돌하는 멀티테넌트 환경에서 Resource Group을 통해 시스템 안정성을 확보한 실무 노하우를 공유합니다.

  • 01워크로드 성격에 따른 서비스, 배치, 모니터링 그룹 분류 체계 수립
  • 02Linux CFS 기반의 cpu_weight와 하드 격리인 exclusive_cpu_cores의 차이 분석
  • 03전용 3벌 ThreadPool 분리를 통한 물리적 CPU 선점 메커니즘 설명
  • 04토스쇼핑 사례를 통한 점진적 리소스 격리 강화 단계 제시
  • 05Classifier 매칭 로직의 함정과 가중치 계산 방식의 중요성 강조

RECOMMENDATION

멀티테넌트 환경에서 쿼리 간섭으로 고통받는 데이터 엔지니어나, StarRocks의 리소스 제어 메커니즘을 깊이 있게 이해하고 싶은 운영자에게 추천합니다.

The Problem

하나의 StarRocks 클러스터에서 실시간 서비스 조회, 대규모 배치 작업, 모니터링 등 성격이 다른 워크로드가 공존하면서 리소스 경합이 발생하고 서비스 SLA 준수가 어려워지는 문제가 있었습니다.

The Solution

Resource Group 기능을 도입하여 워크로드별로 CPU 우선순위(cpu_weight)를 지정하고, 엄격한 레이턴시 보장이 필요한 서비스에는 전용 물리 코어를 할당하는 exclusive_cpu_cores 방식을 단계적으로 적용했습니다.

The Result

헤비 배치 워크로드와 서비스 조회가 겹치는 상황에서도 서비스 쿼리의 응답 시간이 튀는 현상을 해결하고 안정적인 레이턴시 성능을 확보하는 데 성공했습니다.

Trade-off

exclusive_cpu_cores는 강력한 격리를 제공하지만 유휴 리소스의 유연한 공유를 제한하며, Classifier 설정 시 DB 기반 조건이 다른 조건보다 가중치가 매우 높아 의도치 않은 그룹 배정이 발생할 수 있는 운영상 주의점이 있습니다.

03

Key Concepts

Concept · 01

Resource Group

DB 엔진 내부에서 컴퓨팅 리소스를 논리적으로 분할하여 특정 워크로드나 사용자에게 할당하는 관리 단위입니다.

  • StarRocks에서 BE와 CN의 리소스를 분할하여 멀티테넌트 환경을 구축하는 데 활용됩니다.
Concept · 02

Exclusive CPU Cores

물리적 CPU 코어를 특정 리소스 그룹에 전용으로 예약하고, 스레드 어피니티를 통해 하드웨어 수준의 격리를 제공하는 설정입니다.

  • Driver, Scan, ConnectorScan을 위한 전용 3벌 ThreadPool을 별도로 생성하여 공유 풀과의 경합을 원천 차단합니다.
Concept · 03

Classifier

사용자, 역할, 쿼리 타입 등 쿼리의 속성을 기반으로 해당 쿼리를 어떤 Resource Group에서 실행할지 결정하는 매칭 규칙입니다.

  • DB, User, Source IP 등의 조건에 부여된 가중치(Matching Degree)를 계산하여 가장 적합한 그룹을 선발합니다.