Amazon Redshift 병렬 확장 가이드 및 테스트 결과

Skyeng에서는 병렬 확장을 포함하여 Amazon Redshift를 사용하므로 dotgo.com의 창립자인 Stefan Gromoll이 intermix.io에 대해 쓴 이 기사가 흥미로웠습니다. 번역 후 데이터 엔지니어 Daniyar Belkhodzhaev의 약간의 경험을 들려드립니다.

Amazon Redshift 아키텍처 클러스터에 새 노드를 추가하여 확장할 수 있습니다. 최대 요청 수를 처리해야 하면 노드가 과도하게 프로비저닝될 수 있습니다. 동시성 확장은 새 노드를 추가하는 것과 달리 필요에 따라 컴퓨팅 성능을 증가시킵니다.

Amazon Redshift 병렬 확장은 Redshift 클러스터에 최대 요청 볼륨을 처리할 수 있는 추가 용량을 제공합니다. 이는 백그라운드에서 요청을 새로운 "병렬" 클러스터로 이동하는 방식으로 작동합니다. 요청은 WLM 구성 및 규칙에 따라 라우팅됩니다.

병렬 확장 가격은 프리 티어가 포함된 크레딧 모델을 기반으로 합니다. 무료 크레딧 이상에서는 병렬 확장 클러스터가 요청을 처리하는 시간을 기준으로 결제가 이루어집니다.

저자는 내부 클러스터 중 하나에서 병렬 확장을 테스트했습니다. 이 게시물에서 그는 테스트 결과에 대해 이야기하고 시작하는 방법에 대한 팁을 제공할 것입니다.

클러스터 요구 사항

병렬 조정을 사용하려면 Amazon Redshift 클러스터가 다음 요구 사항을 충족해야 합니다.

- 플랫폼: EC2-VPC;
— 노드 유형: dc2.8xlarge, ds2.8xlarge, dc2.large 또는 ds2.xlarge;
— 노드 수: 2~32(단일 노드 클러스터는 지원되지 않음)

허용되는 요청 유형

병렬 확장은 모든 유형의 쿼리에 적합하지 않습니다. 첫 번째 버전에서는 다음 세 가지 조건을 충족하는 읽기 요청만 처리합니다.

— SELECT 쿼리는 읽기 전용입니다(더 많은 유형이 계획되어 있음).
— 쿼리가 INTERLEAVED 정렬 스타일을 사용하는 테이블을 참조하지 않습니다.
- 쿼리는 외부 테이블을 참조하기 위해 Amazon Redshift Spectrum을 사용하지 않습니다.

병렬 확장 클러스터로 라우팅하려면 요청이 대기열에 있어야 합니다. 또한 대기열에 적합한 쿼리 SQA(단문 쿼리 가속), 병렬 규모 클러스터에서는 실행되지 않습니다.

대기열 및 SQA에는 적절한 구성이 필요합니다 Redshift 워크로드 관리(WLM). 먼저 WLM을 최적화하는 것이 좋습니다. 이렇게 하면 병렬 확장의 필요성이 줄어듭니다. 병렬 확장은 특정 시간 동안만 무료이기 때문에 이는 중요합니다. AWS는 97%의 고객에게 병렬 확장이 무료라고 주장하는데, 이로 인해 가격 문제가 발생합니다.

병렬 확장 비용

AWS는 병렬 확장을 위한 신용 모델을 제공합니다. 각 활성 클러스터 아마존 레드 시프트 시간당 크레딧이 누적되며 하루 최대 XNUMX시간의 무료 병렬 확장 크레딧이 제공됩니다.

병렬 확장 클러스터 사용량이 받은 크레딧 금액을 초과하는 경우에만 비용을 지불합니다.

비용은 무료 요금 이상으로 사용되는 병렬 클러스터에 대해 초당 온디맨드 요금으로 계산됩니다. 요청 기간에 대해서만 요금이 부과되며 병렬 조정 클러스터가 활성화될 때마다 최소 XNUMX분의 요금이 부과됩니다. 초당 주문형 요율은 일반 가격 책정 원칙에 따라 계산됩니다. 아마존 레드 시프트즉, 노드 유형과 클러스터의 노드 수에 따라 달라집니다.

병렬 확장 시작

병렬 확장은 WLM 대기열별로 실행됩니다. AWS Redshift 콘솔로 이동하여 왼쪽 탐색 메뉴에서 워크로드 관리를 선택합니다. 다음 드롭다운 메뉴에서 클러스터의 WLM 매개변수 그룹을 선택합니다.

각 대기열 옆에 "동시성 확장 모드"라는 새 열이 표시됩니다. 기본값은 "비활성화"입니다. "편집"을 클릭하면 각 대기열의 설정을 변경할 수 있습니다.

구성

병렬 확장은 적절한 요청을 새로운 전용 클러스터로 전달하여 작동합니다. 새 클러스터는 기본 클러스터와 동일한 크기(노드 유형 및 수)를 갖습니다.

병렬 확장에 사용되는 기본 클러스터 수는 1개이며, 최대 총 10개의 클러스터를 구성할 수 있습니다.
병렬 확장을 위한 총 클러스터 수는 max_concurrency_scaling_clusters 매개변수로 설정할 수 있습니다. 이 매개변수의 값을 늘리면 추가 중복 클러스터가 제공됩니다.

모니터링

AWS Redshift 콘솔에는 몇 가지 추가 그래프가 있습니다. 구성된 최대 동시성 조정 클러스터 차트는 시간 경과에 따른 max_concurrency_scaling_clusters 값을 표시합니다.

활성 확장 클러스터의 수는 "동시성 확장 활동" 섹션의 사용자 인터페이스에 표시됩니다.

쿼리 탭에는 쿼리가 기본 클러스터에서 실행되었는지 아니면 병렬 확장 클러스터에서 실행되었는지를 나타내는 열이 있습니다.

특정 쿼리가 메인 클러스터에서 실행되었는지 아니면 병렬 확장 클러스터를 통해 실행되었는지에 관계없이 stl_query.concurrency_scaling_status에 저장됩니다.

값이 1이면 병렬 규모 클러스터에서 쿼리가 실행되었음을 나타내고, 다른 값은 기본 클러스터에서 실행되었음을 나타냅니다.

예 :

동시성 확장 정보는 SVCS_CONCURRENCY_SCALING_USAGE와 같은 일부 다른 테이블 및 뷰에도 저장됩니다. 또한 병렬 확장에 대한 정보를 저장하는 카탈로그 테이블이 많이 있습니다.

조사 결과

작성자는 18년 30월 00일 약 29.03.2019:3:20(GMT)에 내부 클러스터의 한 대기열에 대한 병렬 확장을 시작했으며, 30년 00월 29.03.2019일 약 XNUMX:XNUMX:XNUMX에 max_concurrency_scaling_clusters 매개 변수를 XNUMX으로 변경했습니다.

요청 대기열을 시뮬레이션하기 위해 이 대기열의 슬롯 수를 15개에서 5개로 줄였습니다.

아래는 슬롯 수를 줄인 후 실행 중이고 대기열에 있는 요청 수를 보여주는 intermix.io 대시보드 차트입니다.

대기열의 요청 대기 시간이 증가하여 최대 시간이 5분 이상인 것을 확인할 수 있습니다.

이 기간 동안 발생한 일에 대한 AWS 콘솔의 관련 정보는 다음과 같습니다.

Redshift는 구성된 대로 3개의 병렬 확장 클러스터를 시작했습니다. 클러스터의 많은 요청이 대기열에 있음에도 불구하고 이러한 클러스터는 충분히 활용되지 않은 것으로 보입니다.

사용량 그래프는 조정 활동 그래프와 연관되어 있습니다.

몇 시간 후 작성자가 대기열을 확인한 결과 6개의 요청이 병렬 확장으로 실행 중인 것으로 나타났습니다. 또한 사용자 인터페이스를 통해 두 가지 요청을 무작위로 테스트했습니다. 여러 개의 병렬 클러스터가 동시에 활성화될 때 이 값을 어떻게 사용하는지 확인하지 않았습니다.

조사 결과

병렬 확장은 최대 로드 중에 요청이 대기열에서 소요되는 시간을 줄일 수 있습니다.

기본 테스트 결과 로딩 요청 상황이 일부 개선된 것으로 나타났다. 그러나 병렬 확장만으로는 모든 동시성 문제가 해결되지 않았습니다.

이는 병렬 확장을 사용할 수 있는 쿼리 유형에 대한 제한 때문입니다. 예를 들어, 작성자는 인터리브된 정렬 키가 있는 테이블을 많이 갖고 있으며 작업량의 대부분은 쓰기입니다.

병렬 확장은 WLM 설정을 위한 보편적인 솔루션은 아니지만 이 기능을 사용하는 것은 간단하고 간단합니다.

따라서 작성자는 WLM 대기열에 이를 사용할 것을 권장합니다. 하나의 병렬 클러스터로 시작하고 콘솔을 통해 최대 로드를 모니터링하여 새 클러스터가 완전히 활용되고 있는지 확인합니다.

AWS가 추가 쿼리 유형 및 테이블에 대한 지원을 추가함에 따라 병렬 확장은 점점 더 효율적이 될 것입니다.

Skyeng 데이터 엔지니어 Daniyar Belkhodzhaev의 의견

Skyeng에서는 병렬 확장의 새로운 가능성도 즉시 알아차렸습니다.
이 기능은 매우 매력적입니다. 특히 대부분의 사용자가 추가 비용을 지불할 필요조차 없을 것으로 AWS가 추정하고 있다는 점을 고려하면 더욱 그렇습니다.

24월 중순에 Redshift 클러스터에 대한 요청이 이례적으로 쇄도했습니다. 이 기간 동안 우리는 동시성 확장(Concurrency Scaling)을 자주 사용했으며 때로는 추가 클러스터가 중단 없이 하루 XNUMX시간 작동하는 경우도 있었습니다.

이를 통해 대기열 문제를 완전히 해결하지는 못하더라도 최소한 상황을 수용 가능하게 만들 수 있었습니다.

우리의 관찰은 intermix.io 사람들의 인상과 크게 일치합니다.

또한 대기열에 대기 중인 요청이 있더라도 모든 요청이 즉시 병렬 클러스터로 전달되지는 않는다는 사실도 확인했습니다. 분명히 이는 병렬 클러스터가 시작하는 데 여전히 시간이 걸리기 때문에 발생합니다. 결과적으로 단기적인 최대 부하 동안에는 여전히 작은 대기열이 있으며 해당 경보가 트리거될 시간이 있습니다.

XNUMX월에 비정상적인 로드를 제거한 후 AWS가 예상한 대로 우리는 자유 표준 내에서 비정기적 사용 모드에 들어갔습니다.
AWS Cost Explorer에서 병렬 확장 비용을 추적할 수 있습니다. 서비스 - Redshift, 사용 유형 - CS(예: USW2-CS:dc2.large)를 선택해야 합니다.

러시아어 가격에 대해 자세히 알아볼 수 있습니다. 여기에.

출처 : habr.com