카우치베이스 애널리틱스에서 입장 제어 쿼리하기

카우치베이스 애널리틱스는 일반적으로 메모리에 들어갈 수 있는 것보다 더 많은 데이터를 처리하는 애드혹 분석 쿼리를 수행하도록 최적화되어 있습니다. 이 엔진은 Couchbase 클러스터에서 분석 서비스를 실행 중인 특정 노드에서 사용 가능한 처리 능력을 최대한 활용하려고 시도하는 대규모 병렬 처리(MPP) 엔진을 사용합니다. 동시에 이 엔진은 각 노드의 Analytics 서비스에 할당된 메모리 예산 내에서 작동하도록 보장합니다. 이를 위해 애널리틱스 서비스에는 동시에 실행할 수 있는 쿼리를 결정하는 쿼리 허용 제어 기능이 있습니다. 이 문서에서는 애널리틱스 쿼리 허용 제어 메커니즘의 작동 방식에 대한 기본 사항을 설명하고 몇 가지 예를 제공합니다.

애널리틱스 쿼리 허용 컨트롤러는 새로 수신된 쿼리를 즉시 실행할 수 있는지, 대기해야 하는지 또는 거부해야 하는지를 결정합니다. 이러한 결정은 1) Analytics 서비스에 사용할 수 있는 리소스와 2) 특정 쿼리에 필요한 리소스를 기반으로 이루어집니다. 각 리소스가 계산되는 방법은 다음에 설명되어 있습니다.

애널리틱스 사용 가능한 리소스:

애널리틱스에서는 다음과 같은 리소스 풀을 유지 관리합니다:

쿼리 처리에 사용할 수 있는 총 메모리:
기본적으로 애널리틱스는 각 노드에서 애널리틱스 서비스에 할당된 메모리 중 50%를 쿼리 처리를 위해 할당합니다. 나머지 50%는 스토리지 버퍼 캐시 및 수집 파이프라인과 같은 다른 영역에 사용됩니다. 각 노드에서 50%의 메모리를 더하면 애널리틱스에서 쿼리 처리에 사용할 수 있는 총 메모리가 됩니다.
예를 들어 클러스터에 각각 16GB의 메모리를 가진 애널리틱스 서비스를 실행하는 3개의 노드가 있는 경우입니다:

총 쿼리 작업자 수:
애널리틱스는 운영 체제에서 보고한 코어 수를 사용하여 각 애널리틱스 노드의 코어 수를 결정합니다. 각 노드의 코어 수를 더한 다음 각 노드의 코어 수에 코어배율 계수는 쿼리 처리에 사용할 수 있는 쿼리 워커의 총 수를 제공합니다. 애드혹 분석 쿼리는 IO에 바인딩되는 경향이 있으므로, 다른 쿼리가 IO를 기다리는 동안 CPU 코어가 다른 동시 쿼리 처리에 참여할 수 있습니다. coresMultiplier, 즉 구성 가능한 매개변수 기본값이 3인 애널리틱스 서비스에서 코어당 동시성 수준을 지정하여 각 코어가 충분한 작업을 수행하도록 할 수 있는 기능을 제공합니다.
예를 들어 클러스터에 Analytics 서비스가 있는 노드가 3개 있고 각 노드에 코어가 8개 있고 코어배율이 3으로 설정되어 있는 경우입니다:

필요한 리소스를 쿼리합니다:

Analytics 쿼리 프로세서에 새 쿼리가 수신되면 쿼리 컴파일러는 메모리 및 쿼리 작업자 측면에서 쿼리를 처리하는 데 필요한 리소스를 결정합니다:

필요한 메모리:
특정 쿼리에 필요한 메모리는 쿼리의 성격에 따라 다릅니다. 예를 들어, 결과를 정렬해야 하는 쿼리는 일반적으로 컬렉션의 문서 수만 계산하거나 특정 필드에 대한 작은 범위의 값으로 문서를 검색하는 단순한 쿼리보다 더 많은 메모리가 필요합니다. Analytics 쿼리 컴파일러는 쿼리에 관련된 모든 작업을 검사하여 각 쿼리에 필요한 최대 메모리를 결정합니다.

필수 쿼리 작업자:
일반적인 Analytics 배포에는 각 노드에 코어당 데이터 파티션(샤드)이 있습니다. Analytics는 클러스터의 모든 데이터 파티션에서 데이터를 병렬로 처리하려고 시도하므로 데이터 액세스가 필요한 모든 쿼리에 필요한 쿼리 워커는 데이터 파티션 수와 같습니다.

예를 들어, 24개의 데이터 파티션이 있는 클러스터에서 컬렉션의 모든 문서를 계산하려는 쿼리는 24개의 쿼리 워커를 사용해야 합니다.

예시:

아래 예에서는 각각 16GB의 메모리와 8개의 코어를 가진 3개의 노드로 구성된 Analytics 서비스를 실행하는 Couchbase 클러스터를 가정합니다.

예 1:
코어 승수 = 3
사용 가능한 총 메모리 = 48GB
사용 가능한 총 쿼리 작업자 수 = (8 + 8 + 8) * 3 = 72명
수신된 동시 쿼리 수 = 5개(각각 2GB의 메모리와 24명의 작업자 필요)

클러스터에 사용 가능한 쿼리 작업자가 72명뿐이고 각 쿼리에는 24명의 작업자가 필요하므로 분석은 3개의 쿼리를 동시에 실행하고 쿼리 4와 5를 큐에 대기시킵니다. 처음 3개의 쿼리 중 하나가 완료되면 대기열에 있는 쿼리 중 하나가 실행됩니다. (참고: 시스템이 처음 3개의 쿼리로도 충분히 바쁘기 때문에 4번과 5번 쿼리를 대기열에 넣지 않고 즉시 승인하는 것은 성능에 도움이 되지 않습니다. 한꺼번에 더 많은 작업을 수행하려고 하면 속도가 빨라지지 않으며 오히려 비생산적인 리소스 경합으로 이어질 수 있습니다.)

예 2:
코어 승수 = 3
사용 가능한 총 메모리 = 48GB
사용 가능한 총 쿼리 작업자 수 = (8 + 8 + 8) * 3 = 72명
수신된 동시 쿼리 수 = 3개(각각 20GB의 메모리와 24명의 작업자 필요)

분석은 두 개의 쿼리를 동시에 실행하고 세 번째 쿼리를 대기열에 넣습니다. 세 쿼리를 모두 동시에 실행할 메모리가 충분하지 않기 때문입니다. (참고: 각 쿼리에 할당된 메모리를 줄여서 더 많은 작업을 수행하려고 하면 데이터가 더 많이 유출되고 IO 비용이 증가하여 성능이 저하될 가능성이 높습니다.)

예 3:
코어 승수 = 3
사용 가능한 총 메모리 = 48GB
사용 가능한 총 쿼리 작업자 수 = (8 + 8 + 8) * 3 = 72명
수신된 동시 쿼리 수 = 1(메모리 50GB, 작업자 24명 필요)

쿼리를 실행할 메모리가 충분하지 않으므로 애널리틱스에서 쿼리를 거부합니다. 클러스터에 애널리틱스 노드를 추가하면 사용 가능한 리소스가 증가하여 이러한 쿼리를 실행할 수 있을 수도 있습니다. (참고: 쿼리 힌트를 사용하여 쿼리의 연산자에게 더 적은 메모리를 할당하도록 쿼리에 지시하여 더 높은 IO 비용이 발생하더라도 쿼리를 실행할 수 있습니다.)

예 4:
코어 승수 = 5
사용 가능한 총 메모리 = 48GB
사용 가능한 총 쿼리 작업자 수 = (8 + 8 + 8) * 5 = 120명
수신된 동시 쿼리 수 = 5개(각각 2GB의 메모리와 24명의 작업자 필요)

메모리와 쿼리 워커가 충분하므로 분석에서는 5개의 쿼리를 모두 동시에 실행합니다. coresMultiplier 값을 높이면 더 많은 쿼리를 동시에 실행할 수 있지만, 기본 스토리지가 동시 IO 요청을 처리할 수 없거나 위에서 언급한 것처럼 CPU 코어가 쓰레싱을 시작하는 경우 전체적으로 처리량이 낮아질 수 있다는 점에 유의해야 합니다. 따라서 코어배율 매개변수를 조정할 때는 사용 가능한 리소스와 워크로드의 특성에 따라 신중하게 조정해야 할 수 있습니다.

결론:

이 문서에서는 애널리틱스 서비스의 쿼리 허용 제어 로직이 작동하는 방식과 쿼리 허용 결정을 내리는 데 사용하는 요소에 대해 설명했습니다. 또한 더 많은 쿼리를 동시에 실행할 수 있도록 coresMultiplier 매개 변수를 사용하는 방법과 그 값을 변경하면 어떤 결과가 발생하는지에 대해서도 설명했습니다.