토스는 서비스 조회와 대규모 분석 쿼리를 하나의 플랫폼에서 처리하기 위해 StarRocks를 실시간 OLAP 엔진으로 도입하고, 다양한 워크로드가 공존하는 환경에서 리소스 그룹(Resource Group)을 통해 안정적인 운영 체계를 구축했습니다. 특히 CPU 우선순위 설정과 전용 코어 할당 방식을 전략적으로 선택하여, 대규모 배치 작업이 진행되는 중에도 서비스 쿼리의 응답 속도(SLA)를 일관되게 유지하는 최적의 격리 구조를 설계했습니다.

비즈니스 중요도에 따른 워크로드 분류

워크로드의 성격에 따라 서비스 쿼리, 서버 배치, 대규모 적재·백필, 모니터링·사용자 도구 순으로 우선순위를 정의했습니다.
실시간 응답이 필수적인 서비스 쿼리는 가장 먼저 보호하고, 클러스터 전체에 부하를 줄 수 있는 대규모 적재나 단순 모니터링 조회는 하위 순위나 상한선을 두어 관리합니다.

가중치 기반의 유연한 리소스 분배 (cpu_weight)

CPU 경합이 발생할 때 설정된 비율에 따라 리소스를 분배하는 방식으로, Linux CFS(Completely Fair Scheduler)와 유사한 자체 스케줄링 메커니즘을 사용합니다.
리소스가 여유로울 때는 다른 그룹의 남는 자원을 빌려 쓸 수 있어(Borrowing), 일반적인 멀티테넌트 환경에서 리소스 효율성을 극대화하는 기본 설정으로 활용됩니다.
내부적으로 파이프라인 드라이버가 100ms 타임 슬라이스 단위로 양보하며 동작하므로, 중요도가 높은 그룹이 더 많은 CPU 시간을 확보하게 됩니다.

물리적 코어 예약을 통한 배타적 격리 (exclusive_cpu_cores)

높은 SLA가 요구되는 특정 서비스의 경우, 물리적 코어를 전용으로 예약하여 다른 워크로드의 간섭을 완전히 차단합니다.
이 설정은 단순히 논리적 할당에 그치지 않고, pthread_setaffinity_np를 통해 스레드를 코어에 바인딩하며 쿼리 실행을 위한 3벌의 ThreadPool(Driver, Scan, ConnectorScan)을 별도로 생성합니다.
공유 리소스 풀과의 경합이 원천적으로 제거되므로, 헤비 배치 작업과 서비스 조회가 겹치는 상황에서도 응답 시간이 튀는 현상을 방지할 수 있습니다.

토스쇼핑 사례를 통한 단계적 최적화

초기에는 cpu_weight 조정을 통해 서비스 계정에 높은 우선순위를 부여했으나, 대규모 배치 작업 시 서비스 응답 속도가 불안정해지는 한계가 있었습니다.
이를 해결하기 위해 서비스 전용 리소스 그룹에 exclusive_cpu_cores를 적용하여 물리적인 리소스 벽을 세웠습니다.
결과적으로 분당 1,500건 이상의 서비스 요청이 발생하는 구간에서도 배치 작업의 영향 없이 안정적인 레이턴시를 확보하는 데 성공했습니다.

정교한 쿼리 매칭을 위한 Classifier 설계

user, role, query_type, db 등의 속성을 기반으로 쿼리를 적절한 리소스 그룹에 할당하는 Classifier 규칙을 수립했습니다.
운영 안정성을 위해 가급적 user 또는 db 단위로 그룹을 묶는 패턴을 권장하며, 이를 통해 특정 서비스나 배치 주체가 정해진 리소스 범위 내에서만 동작하도록 강제합니다.
CPU 제어 외에도 mem_limit과 concurrency_limit을 병행 설정하여 풀 스캔 쿼리의 메모리 독점이나 과도한 동시 접속으로 인한 클러스터 마비를 방지합니다.

실용적인 운영 제언 가장 효율적인 운영 전략은 기본적으로 cpu_weight를 사용하여 리소스 효율을 높이되, 실시간 서비스와 같이 지연 시간에 민감한 워크로드에 한해서만 exclusive_cpu_cores를 단계적으로 도입하는 것입니다. 또한 리소스 그룹 설정 시 실제 물리 코어 수와 워크로드 간의 의존 관계를 면밀히 검토해야 예상치 못한 성능 저하를 막을 수 있습니다.