워크로드 그룹을 기반으로 한 Apache Doris의 부하 격리 기능|심층 분석

작성자: SelectDB 기술팀

오늘날 기업의 데이터 쿼리 요구 사항은 지속적으로 증가하고 있습니다. 동일한 클러스터를 공유할 때 여러 비즈니스 라인 또는 여러 분석 로드의 동시 쿼리에 동시에 직면해야 하는 경우가 많습니다. 제한된 리소스 조건에서 쿼리 작업 간의 리소스 선점은 성능 저하 및 심지어 클러스터 불안정으로 이어질 수 있으므로 부하 관리의 중요성은 자명합니다.

비즈니스 시나리오에서 시작하여 사용자 로드 관리에 대한 요구 사항은 주로 다음 측면에서 비롯됩니다.

여러 비즈니스 부서 또는 테넌트가 동일한 클러스터를 공유할 수 있는 경우, 서로 다른 테넌트 간의 로드 상호 작용을 피하기 위해 각 테넌트의 리소스 사용 독립성과 성능 안정성을 보장해야 합니다.
비즈니스마다 쿼리 작업의 응답성 및 우선순위에 대한 요구 사항이 다릅니다. 실시간 데이터 분석, 온라인 트랜잭션 등과 같은 주요 비즈니스 또는 우선 순위가 높은 작업의 경우 이러한 작업이 충분한 리소스를 확보하고 확보할 수 있는지 확인해야 합니다. 리소스 경쟁을 피하기 위해 우선적으로 실행됩니다.
사용자는 리소스 할당 및 관리에 관심을 가질 뿐만 아니라 비용 제어 및 리소스 활용에도 주의를 기울입니다. 부하 관리 솔루션은 격리 요구 사항을 충족하는 동시에 낮은 사용 비용과 높은 리소스 활용도에 대한 사용자 요구를 실현해야 합니다.

초기 버전에서 Apache Doris는 클러스터 내의 노드 수준 리소스 그룹 분할 및 개별 쿼리에 대한 리소스 제한을 포함하여 리소스 태그를 기반으로 하는 격리 솔루션을 출시하여 여러 사용자 간의 리소스를 물리적으로 격리했습니다. 사용자에게 보다 완전한 로드 관리 솔루션을 제공하기 위해 Apache Doris는 버전 2.0부터 Workload Group 기반 관리 솔루션을 출시했습니다. 이는 CPU 리소스의 소프트 제한을 실현하고 사용자에게 더 높은 리소스 활용도를 제공합니다. 새로 출시된 버전 2.1은 Linux 커널에서 제공하는 CGroup 기술을 기반으로 하며, CPU 리소스에 대한 엄격한 제한을 추가로 구현하고 사용자에게 더 나은 쿼리 안정성을 제공합니다.

Resource Tag 기반의 물리적 격리 솔루션

Apache Doris에는 FE와 BE의 두 가지 유형의 노드가 있습니다. FE 노드는 메타데이터 저장, 클러스터 관리, 사용자 요청 액세스, 쿼리 계획 분석 등을 담당하고 BE 노드는 데이터 저장 및 계산을 담당합니다. 쿼리 실행 프로세스와 관련된 주요 리소스 소비는 BE 노드이므로 Apache Doris 부하 격리 솔루션은 BE 노드용으로 설계되었습니다.

리소스 태그 리소스 물리적 격리 솔루션에서는 동일한 클러스터의 BE 노드에 태그를 설정할 수 있습니다. 동일한 태그를 가진 BE 노드는 리소스 그룹(리소스 그룹)을 형성하며 리소스 그룹은 데이터 저장 단위로 간주될 수 있습니다. 그리고 컴퓨팅. 데이터베이스에 데이터가 입력되면 리소스 그룹 구성에 따라 데이터의 복사본이 다른 리소스 그룹에 기록됩니다. 쿼리 시 해당 리소스 그룹의 컴퓨팅 리소스는 리소스 그룹 구분에 따라 계산에 사용됩니다.

참조 문서: https://doris.apache.org/zh-CN/docs/2.0/admin-manual/resource-admin/multi-tenant

일반적인 읽기-쓰기 분석 시나리오를 예로 들어 보겠습니다. 클러스터에 3개의 BE가 있다고 가정합니다. 구체적인 사용 단계는 다음과 같습니다.

BE 노드 바인딩 리소스 태그: 두 개의 BE를 태그 읽기에 바인딩하여 읽기 로드를 제공합니다. 하나의 BE를 태그 쓰기에 바인딩하여 쓰기 로드를 제공합니다. 읽기 워크로드와 쓰기 워크로드는 읽기 및 쓰기 격리를 달성하기 위해 서로 다른 머신에 위치합니다.
데이터 복사본은 리소스 태그에 바인딩됩니다. 표 1에는 복사본 3개가 있고, 복사본 2개는 태그 읽기에 바인딩되고, 복사본 1개는 태그 쓰기에 바인딩됩니다. 복제본 3에 기록된 데이터는 복제본 1 및 복제본 2에 자동으로 동기화됩니다. 동기화 프로세스는 BE 1 및 BE 2의 컴퓨팅 리소스를 너무 많이 차지하지 않습니다.
워크로드는 리소스 태그에 바인딩됩니다. 쿼리 SQL에 의해 전달된 태그가 읽기인 경우 쿼리는 실행을 위해 태그를 읽기로 사용하여 머신(BE 1, BE 2)으로 자동 라우팅됩니다. 로드에 추가되고 지정된 태그가 Write 인 경우 스트림 로드는 태그가 Write(BE 3)인 시스템으로 라우팅됩니다. 이 프로세스에서는 복제본 동기화 중에 발생하는 오버헤드 외에도 쿼리와 가져오기 간의 리소스 경쟁이 더 이상 발생하지 않습니다.

Resource Tag.png 기반의 물리적 격리 솔루션

리소스 태그는 다중 테넌트 기능도 구현할 수 있습니다. 예를 들어, 상호 영향을 피하기 위해 독립적인 테넌트를 생성하려는 UserA와 UserB라는 두 명의 사용자가 있습니다. 그런 다음 UserA의 컴퓨팅 및 스토리지 리소스를 UserA라는 태그에 바인딩하고 UserB의 컴퓨팅 및 스토리지 리소스를 UserA라는 태그에 바인딩할 수 있습니다. 가 UserB의 태그인 경우 두 사용자는 BE 측 테넌트 간에 리소스 격리를 달성합니다.

Resource Tag-2.png 기반의 물리적 격리 솔루션

리소스 태그의 핵심은 BE 노드를 그룹화하여 리소스 격리를 달성하는 것입니다. 이 솔루션의 장점은 다음과 같습니다.

우수한 격리, 여러 테넌트가 물리적 시스템을 통해 격리되고 CPU, 메모리 및 IO가 완전히 격리됩니다.
오류 격리는 한 테넌트에서 문제가 발생하는 경우(예: 프로세스 충돌) 다른 테넌트에 전혀 영향을 미치지 않습니다.

이 기술을 기반으로 일부 사용자는 동일한 도시에 있는 두 컴퓨터실의 활성-활성 운영을 달성하기 위해 서로 다른 물리적 컴퓨터실에 서로 다른 리소스 그룹을 배치합니다.

그러나 다음과 같은 특정 제한 사항도 있습니다.

읽기-쓰기 격리 시나리오에서 쓰기 로드가 중지되면 태그 쓰기가 있는 시스템이 유휴 상태가 되어 전체 클러스터의 리소스 활용도가 감소합니다. 이는 분명히 전체 리소스 활용에 대한 사용자의 기대를 충족할 수 없습니다.
다중 테넌트 시나리오에서는 동일한 테넌트 내의 여러 비즈니스 당사자의 로드도 서로 영향을 미칩니다. 각 비즈니스 당사자별로 별도의 물리적 시스템을 구성하여 격리를 달성할 수 있더라도 이는 높은 비용과 낮은 리소스 활용도 등의 문제를 야기합니다.
유연성이 떨어지며 실제로 테넌트 수는 복제본 수에 묶여 있습니다. 5개의 테넌트를 설정하려면 최소 5개의 복제본이 필요하므로 어느 정도 저장 공간이 낭비됩니다.

Workload Group 기반의 부하 관리 솔루션

위의 문제를 해결하기 위해 Apache Doris는 보다 세분화된 리소스 격리 메커니즘-프로세스 내 리소스 격리를 지원하는 Workload Group 기반 관리 솔루션을 출시했습니다. 격리는 프로세스 내에서 리소스 경쟁을 효과적으로 방지하고 리소스 활용도를 향상시킵니다.

워크로드 그룹은 워크로드를 그룹 단위로 관리하여 메모리 및 CPU 리소스를 정밀하게 관리하고 제어합니다. 사용자가 실행한 쿼리를 작업 부하 그룹과 연결하여 단일 BE 노드에서 단일 쿼리의 CPU 및 메모리 리소스 비율을 제한합니다. 동시에 메모리 리소스 제한을 구성하고 활성화할 수 있습니다. 클러스터 리소스가 부족한 경우 그룹에서 메모리 사용량이 높은 쿼리는 자동으로 종료되어 부담을 덜어줍니다. 리소스가 유휴 상태이면 여러 워크로드 그룹이 유휴 리소스를 공유하고 자동으로 제한을 돌파하여 안정적인 쿼리 실행을 보장합니다.

CPU 리소스 제한은 소프트 제한과 하드 제한으로 나눌 수 있습니다. CPU 소프트 제한은 리소스 활용도가 더 높고 리소스가 유휴 상태일 때 리소스를 유연하게 할당할 수 있는 반면, CPU 하드 제한은 성능 안정성을 보장하고 그룹을 보장하는 데 더 중점을 둡니다. 부하 변화로 인해 서로 간섭하지 마십시오.

( CPU 하드 제한과 소프트 제한의 두 가지 격리 방법은 서로 다른 사용 시나리오와 일치할 수 있지만 동시에 적용할 수는 없습니다. 사용자는 필요에 따라 유연하게 선택할 수 있습니다.)

Workload Group.png 기반 부하 관리 솔루션

워크로드 그룹과 리소스 태그 솔루션의 주요 차이점은 다음과 같습니다.

컴퓨팅 리소스의 관점에서 볼 때, 워크로드 그룹은 BE 프로세스 내에서 CPU와 메모리 리소스를 더욱 분할하여 동일한 BE에서 리소스를 두고 경쟁해야 합니다. 리소스 태그 그룹 BE 노드와 서로 다른 비즈니스 당사자의 로드는 리소스 격리를 달성하기 위해 서로 다른 그룹의 BE로 전송됩니다. 서로 다른 BE 그룹의 비즈니스 로드 간에는 직접적인 리소스 경쟁이 없습니다.
스토리지 리소스 관점에서 워크로드 그룹은 스토리지 리소스에 주의를 기울일 필요가 없으며 단일 BE 내의 컴퓨팅 리소스 할당에만 중점을 둡니다. 리소스 태그에는 격리해야 하는 비즈니스 측 데이터가 다른 BE에 배포되도록 데이터의 그룹화 복사본이 필요합니다.

01 CPU 소프트 제한

CPU 우선순위는 주로 cpu_share매개변수를 통해 반영되는데, 이는 가중치 개념에 비유될 수 있다. 동일한 기간 동안 가중치가 높은 그룹은 더 많은 CPU 시간을 얻을 수 있습니다.

그룹 A와 그룹 B를 예로 들어 보겠습니다. 그룹 A가 cpu_share1로 구성되고 그룹 B가 9로 구성 되면 cpu_share10초의 시간이 제공됩니다. 두 로드가 모두 포화되면 가중치가 더 높은 그룹 B는 9초(전체 자원의 90%) 동안 CPU 시간을 얻을 수 있고, 그룹 A는 1초(전체 자원의 10%) 동안 CPU 시간을 얻을 수 있습니다. 실제 사용 시 모든 서비스가 풀로드로 실행되는 것은 아닙니다. 그룹 B의 부하가 낮거나 부하가 없는 경우 그룹 A는 10초 동안 CPU 시간을 독점할 수 있습니다. 이 방법은 더 높은 리소스 할당 유연성을 제공하여 클러스터 CPU 리소스의 전반적인 활용도를 향상시킬 수 있습니다.

CPU

02 CPU 하드 제한

CPU 소프트 시간 제한을 사용하면 시스템 부하가 높거나 CPU 리소스가 부족한 경우 쿼리 성능이 변동될 수 있습니다. 안정적인 쿼리 성능에 대한 사용자의 높은 요구 사항을 충족하기 위해 Apache Doris는 최신 버전 2.1에서 작업 그룹의 CPU 하드 제한을 구현했습니다. 현재 물리적 시스템의 전체 CPU가 유휴 상태인지 여부에 관계없이 최대 CPU 사용량은 하드 제한으로 구성된 그룹은 사전 구성된 제한 값을 초과할 수 없습니다.

그룹 A와 그룹 B를 예로 들어 보겠습니다 . 그룹 A를 구성하면 cpu_hard_limit=10%그룹 B가 됩니다. cpu_hard_limit=90%두 단일 시스템의 CPU 리소스가 포화 상태에 도달하면 그룹 A의 CPU 사용률은 10%이고 그룹 B의 CPU 사용률은 90%입니다. 이는 CPU 소프트 제한과 동일합니다. 그러나 그룹 B의 부하가 감소하거나 부하가 없는 경우 그룹 A의 쿼리 부하가 증가하더라도 최대 CPU 사용률은 여전히 10%로 엄격하게 제한되어 더 많은 리소스를 얻을 수 없습니다. 이 접근 방식은 리소스 할당의 유연성을 희생하지만 쿼리 성능의 안정성도 보장합니다.

하드 제한

03 메모리 리소스 제한

사용 지침: BE 노드 메모리는 주로 다음 부분으로 나뉩니다.

운영 체제는 메모리를 예약합니다.

BE 프로세스에서 쿼리가 아닌 메모리 부분은 당분간 워크로드 그룹에서 계산할 수 없습니다.

BE 프로세스(가져오기 작업 포함) 내 쿼리 부분의 메모리는 워크로드 그룹에서 계산하고 관리할 수 있습니다.

메모리 리소스 제한은 주로 memory_limit매개변수(사용 가능한 BE 메모리 비율 설정)에 의해 제한됩니다. 미리 구성된 메모리 사용량을 설정할 수 있을 뿐만 아니라 오버커밋 후 메모리 반환 우선순위에도 영향을 미칠 수 있습니다.

초기 상태에서는 우선 순위가 높은 리소스 그룹에 더 많은 메모리가 할당되고, 우선 순위가 낮은 리소스 그룹에는 더 적은 메모리가 할당됩니다. 메모리 활용도를 향상시키기 위해 enable_memory_overcommit리소스 그룹의 메모리 소프트 제한을 활성화할 수 있습니다. 시스템에 여유 메모리 리소스가 있으면 제한을 초과하여 사용할 수 있습니다.

시스템의 안정적인 작동을 보장하기 위해 시스템의 전체 메모리 리소스가 부족한 경우 시스템은 과다 할당된 메모리 리소스를 회수하기 위해 많은 양의 메모리를 차지하는 작업을 취소하는 데 우선 순위를 둡니다. 이 프로세스 동안 시스템은 우선 순위가 높은 리소스 그룹의 메모리 리소스를 예약하려고 시도하며 우선 순위가 낮은 리소스 그룹의 초과 메모리는 더 빠르게 회수됩니다.

메모리 리소스 제한

04 쿼리 큐

비즈니스 부하가 시스템의 상한을 초과하는 경우 계속해서 새 쿼리를 제출하면 효과적으로 실행되지 않을 뿐만 아니라 실행 중인 쿼리에도 영향을 미칩니다. 이 문제를 방지하기 위해 워크로드 그룹은 쿼리 대기열을 지원합니다. 쿼리가 미리 설정된 최대 동시성에 도달하면 새 제출 계획이 대기열 논리에 들어갑니다. 대기열이 가득 차거나 대기 시간이 초과되면 부하가 높은 시스템에 대한 부담을 완화하기 위해 쿼리가 거부됩니다.

쿼리 대기열.png

쿼리 대기열 기능에는 주로 세 가지 속성이 있습니다.

max_concurrency: 현재 그룹에서 동시에 실행할 수 있는 최대 SQL 문 수입니다. 최대 수를 초과하면 대기열 논리가 입력됩니다.
max_queue_size: 대기열에 허용되는 최대 쿼리 수입니다. 대기열이 가득 차면 쿼리가 거부되고 실행이 실패합니다.
queue_timeout: 큐에 대기하는 시간 제한입니다. 시간이 초과되면 바로 실패합니다. 단위는 밀리초입니다.

참조 문서: https://doris.apache.org/zh-CN/docs/admin-manual/workload-group

워크로드 그룹 사용 테스트

다음으로 워크로드 그룹의 CPU 소프트 제한과 하드 제한에 대한 자세한 테스트를 수행하여 동일한 하드웨어 조건에서 이 두 제한의 로드 관리 효과와 성능을 사용자에게 명확하게 보여줍니다.

테스트 환경: 16코어 64G 메모리 단일 물리적 머신
배포 방법: FE 1개, BE 1개
테스트 데이터 세트: 클릭벤치, TPCH
스트레스 측정 도구: JMeter

01 CPU 소프트 리미트 테스트

두 개의 클라이언트(1, 2)를 시작하여 각각 CPU 소프트 제한을 사용/사용하지 않고 부하 관리에 대한 CPU 소프트 제한의 효과를 테스트합니다. 이 테스트에서는 페이지 캐시가 테스트 결과에 영향을 미치므로 이상적인 테스트 결과를 얻으려면 페이지 캐시를 꺼야 합니다.

CPU 소프트 리미트 테스트.png

두 가지 테스트에서 클라이언트 처리량 데이터를 비교하고 분석하여 다음과 같은 결론을 내릴 수 있습니다.

워크로드 그룹이 없으면 두 클라이언트의 처리량 비율은 1:1입니다. 이는 동일한 런타임 동안 동일한 CPU 리소스를 수신함을 나타냅니다.
워크로드 그룹을 사용하고 이를 각각 cpu_share2048과 1024로 설정한 후 결과는 처리량 비율이 2:1이 되는 것을 보여줍니다. 이는 더 큰 매개변수를 가진 클라이언트 1이 동일한 실행 시간에 cpu_share더 높은 비율의 CPU 리소스를 얻는다는 것을 보여줍니다.

02 CPU 하드 리미트 테스트

위의 소개에서 볼 수 있듯이 CPU 하드 제한은 로드가 높을 때 우수한 격리를 보장할 수 있습니다. 따라서 우리는 하드 제한을 사용하여 CPU 사용량을 50%( cpu_hard_limit=50%)로 제한하고 동시성 수가 1, 2, 4일 때 동일한 클라이언트를 사용하여 q23 쿼리 테스트를 실행합니다(각 테스트가 실행됨). 5분 동안.

CPU 하드 제한 test.jpeg

위의 테스트 결과에서 동시 쿼리 수가 증가함에 따라 CPU 사용률은 항상 800% 내외로 안정적임을 알 수 있습니다(16코어 시스템에서 800%는 8개 코어를 사용하는 것을 의미하며 실제 CPU 사용률은 50%입니다). % ). CPU 리소스는 엄격하게 제한되어 있으므로 동시성이 증가하면 tp99 대기 시간도 늘어날 것으로 예상됩니다.

03 생산 환경 테스트 시뮬레이션

실제 프로덕션 환경에서 사용자는 순수한 처리량보다 쿼리 대기 시간 성능에 더 많은 관심을 기울이는 경우가 많습니다. 실제 애플리케이션 시나리오에 더 가깝고 성능을 정확하게 평가하기 위해 지연 시간이 약 1초인 일련의 쿼리 SQL(CKBench의 q15, q17, q23 및 TPCH의 q3, q7, q19 포함)을 선택하여 SQL 세트를 구성했습니다. 이러한 쿼리는 단일 테이블 집계, 조인 계산 등 다양한 기능을 다루며, 사용되는 TPCH 데이터 세트 크기는 100G입니다.

우리는 각각 워크로드 그룹이 없는 시나리오와 워크로드 그룹이 있는 시나리오를 시뮬레이션하기 위해 두 가지 테스트 세트를 설계했습니다. tp90 및 tp99의 대기 시간에 초점을 맞춰 클라이언트 1과 클라이언트 2에서 4가지 테스트가 수행되었습니다.

프로덕션 환경 테스트 테스트.png

위 표의 네 가지 테스트에서 쿼리 지연을 관찰하면 다음과 같은 결론을 내릴 수 있습니다.

워크로드 그룹이 사용되지 않음(테스트 1 및 2) : 클라이언트 2의 동시성이 1에서 4로 증가하면 클라이언트 1과 2의 쿼리 지연이 크게 증가합니다. 클라이언트 1의 성능을 비교하면 중앙값인 tp90 및 tp95 쿼리 응답 시간이 2~3배 증가했습니다.
워크로드 그룹 사용(테스트 3, 4): 다음 두 테스트에는 CPU 하드 제한이 적용되었습니다. Set Client 1 cpu_hard_limit=90%, Client 2 cpu_hard_limit=90%. 테스트 결과에서 알 수 있듯이 클라이언트 2의 동시성이 증가하더라도 클라이언트 1의 쿼리 지연은 약간만 증가하며 이는 테스트 2의 성능보다 훨씬 좋습니다. 이 결과는 워크로드 그룹의 로드 격리 및 성능 안정성 보장 효과를 충분히 보여줍니다.

결론

현재 리소스 태그 및 작업 그룹 기능은 여러 커뮤니티 사용자의 프로덕션 서비스에 출시되었으며 대규모로 검증되었습니다. 리소스 격리가 필요한 사용자에게 권장됩니다.

리소스 태그든 워크로드 그룹이든, 목표는 리소스 격리의 독립성과 리소스 활용 사이의 균형을 맞추는 것 입니다 . 전자는 보다 철저한 격리 솔루션을 채택하는 반면, 후자는 리소스의 전체 활용을 보장하면서 격리를 달성하고 시스템 안정성을 더욱 보장합니다. 쿼리 대기열 및 작업 대기열 메커니즘을 통한 높은 작업 부하 시나리오.

리소스 격리를 실제로 사용할 때 비즈니스 시나리오에 따라 두 가지 솔루션을 결합하고 적용하는 것이 좋습니다.

동일한 클러스터가 시스템/비즈니스 부서 간에 공유되고 리소스와 데이터를 물리적으로 격리하려는 경우 리소스 태그 솔루션을 채택할 수 있습니다.
동일한 클러스터에서 동시에 여러 유형의 쿼리 부하가 발생하는 경우 워크로드 그룹을 통해 서로 다른 부하를 구분할 수 있으며, 유연한 리소스 할당을 통해 다양한 쿼리 부하가 적절한 리소스를 얻을 수 있는지 확인할 수 있습니다.

우리는 후속 기능 개선을 위한 많은 계획을 아직 가지고 있습니다.

현재 메모리 제한은 쿼리 취소를 통해 메모리를 해제하는 데 사용됩니다. 향후 연산자 배치를 통해 대규모 쿼리의 안정성을 더욱 향상시키고 리소스가 부족할 때 쿼리 작업 실패를 방지할 수 있습니다.
현재 BE 프로세스의 메모리 모델에서는 일부 비쿼리 메모리가 계산되지 않아 BE 프로세스의 메모리와 사용자가 보는 워크로드 그룹에서 사용하는 메모리 간에 차이가 발생할 수 있으므로 이를 해결하도록 노력하겠습니다. 향후 버전에서 문제가 발생합니다.
쿼리 큐잉 기능은 최대 동시 쿼리 수를 기반으로 한 큐잉만 지원하며, 향후 최대 동시 쿼리 수는 BE의 리소스 사용량에 따라 제한되므로 클라이언트에 대한 자동 배압이 형성되어 Doris의 가용성이 향상됩니다. 클라이언트가 계속해서 높은 로드를 제출하는 경우.
리소스 태그 기능은 BE 시스템 리소스를 분할하는 것이고, 워크로드 그룹은 단일 시스템 프로세스 내에서 리소스를 분할하는 것입니다. 이 두 가지 리소스 분할 방법 모두 BE 노드의 개념을 사용자에게 노출시킵니다. 사용자가 리소스 관리 기능을 사용할 때 기본적으로 전체 세트에서 사용 가능한 리소스의 양과 자신의 작업 부하에 대한 리소스 할당 우선 순위에만 주의하면 됩니다. 앞으로는 사용자의 이해와 사용 비용을 줄이기 위해 자원을 분할하는 새로운 방법을 모색할 것입니다.

감사의 말

워크로드 그룹 기능은 오픈 소스 커뮤니티에서 공동으로 개발한 프로젝트입니다. Luo Zenglin(luozenglin), Liu Lijia(liutang123), Zhao Liwei(levy5307)의 기여에 감사드립니다.