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

서비스 조회와 분석 쿼리를 한 플랫폼에서 처리하려고 StarRocks를 실시간 OLAP 엔진으로 도입했다. 하지만 하나의 클러스터에 서비스, 배치, 적재, 대시보드 쿼리가 함께 쌓이면서 운영의 핵심은 평균 성능보다도 "어떤 쿼리를 먼저 보호할 것인가"가 됐다.

운영 중인 클러스터는 성격이 크게 달랐다. 서비스형 클러스터는 24시간 평균 약 69 qps, 1주 평균 87 qps의 조회 트래픽을 처리했고, 모니터링·배치형 클러스터는 24시간 평균 약 20 qps의 쿼리와 더 무거운 배치 작업을 함께 감당했다. 이런 환경에서 Resource Group으로 워크로드를 분류하고 CPU 우선순위를 설계하는 작업이 필요했다.

기본 전략은 cpu_weight였다. 경쟁이 발생할 때만 비율대로 CPU를 나눠 갖게 하므로, 일반적인 멀티테넌트 환경에서는 서비스, 배치, 대시보드 같은 워크로드의 상대 우선순위를 부드럽게 조절할 수 있다.

• service_wg: 서비스 쿼리용, 가장 높은 우선순위
• batch_wg: 서버 배치용, 중간 우선순위
• dashboard_wg: Grafana·Tableau·Redash 같은 조회용, 낮은 우선순위

하지만 서비스 수준의 레이턴시 SLA가 중요한 경우에는 exclusive_cpu_cores가 필요했다. 이 옵션은 물리 CPU 코어를 전용으로 예약하고, 내부적으로 스레드를 코어에 바인딩하며 전용 ThreadPool까지 분리해 공유 풀과의 경합을 없앤다. 토스쇼핑 사례에서는 먼저 cpu_weight를 조정해 서비스 쿼리를 우선 보호했고, 이후에도 응답 시간 튐이 반복되자 서비스 계정을 별도 그룹으로 분리해 exclusive_cpu_cores를 적용했다. 그 결과 배치 워크로드가 겹쳐도 서비스 응답 시간의 스파이크가 사라졌다.

Classifier 설계에서는 user 또는 db 기반 매칭이 가장 안정적이었다. db 조건은 가중치가 특히 커서 거의 항상 우선되므로, 서로 다른 규칙이 겹치지 않게 설계하는 것이 중요했다. 동시에 Resource Group이 직접 관리하는 대상은 일반 쿼리, INSERT INTO, Broker Load까지이며, Routine Load와 Stream Load는 직접 제어되지 않는다.

CPU 외 제어도 함께 썼다. concurrency_limit는 리소스 그룹 내 동시 실행 쿼리 수를 제한해 초과분을 큐에 쌓고, big_query는 BE 노드 기준으로 CPU time, scan rows, memory usage가 임계치를 넘는 쿼리를 강제 종료한다. mem_limit은 각 그룹의 상한이지 예약이 아니어서 여러 그룹의 합이 100%를 넘을 수 있고, spill_mem_limit_threshold는 스필을 검토하기 시작하는 기준일 뿐 실제 동작에는 enable_spill, spill_mode, 연산자 지원 여부가 함께 맞아야 한다.

운영에서 가장 중요한 함정은 Docker 배포 환경이었다. BE와 CN을 컨테이너로 돌릴 때 --cpus만으로는 부족하고 --cpuset-cpus를 함께 설정해야 bind_cpus와 cpu_borrowing이 기대대로 동작한다. cpuset이 빠지면 전용 코어를 빌려 쓰는 구조가 깨져서, exclusive_cpu_cores의 효율이 크게 떨어질 수 있다.

실제 적용 사례에서는 load_wg에 exclusive_cpu_cores=50을 주어 92코어 BE에서 CPU 점유를 약 60% 수준으로 제한했지만, INSERT 작업 시간은 약 380~457초로 늘었다. 전용 코어를 줄인 만큼 느려지는 트레이드오프는 있었지만, 클러스터 전체가 밀리는 상황은 막을 수 있었다. 핵심은 cpu_weight로 시작해 필요할 때만 exclusive_cpu_cores로 올리고, 그 위에 classifier, concurrency_limit, big_query, mem_limit을 겹쳐서 멀티테넌트 워크로드를 단계적으로 통제하는 것이었다.