Amazon Redshift: 벤치마크 기반의 가격대비 성능 비교

이 글은 AWS Big Data Blog에 게시된 Amazon Redshift: Lower price, higher performance by tefan Gromoll, Aamer Shah, Orestis Polychroniou, Ravi Animi, and Sanket Hase 을 한국어 번역 및 편집하였습니다.

다른 모든 고객과 마찬가지로 여러분도 가능한 한 적은 비용으로 최상의 성능을 원할 것입니다. 이는 가격 대비 성능에 집중해야 한다는 것을 의미합니다. Amazon Redshift를 사용하면 두 마리 토끼를 모두 잡을 수 있습니다! Amazon Redshift는 실제 워크로드에서 수백 명의 동시 사용자를 지원하기 위한 동시성 확장, 더 빠른 쿼리 성능을 위한 향상된 문자열 인코딩, Amazon Redshift Serverless 성능 향상 등의 고급 기술을 사용하여 다른 클라우드 데이터 웨어하우스에 비해 최대 4.9배 낮은 사용자당 비용과 최대 7.9배 더 나은 가격 대비 성능을 제공합니다. 가격 대비 성능이 중요한 이유와 Amazon Redshift의 가격 대비 성능이 특정 수준의 워크로드 성능을 얻는 데 드는 비용, 즉 성능 ROI(투자자본수익률)를 나타내는 지에 대해 계속 읽어보세요.

가격과 성능 모두 가격 대비 성능 계산에 포함되므로, 가격 대비 성능을 바라보는 두 가지 방식이 있습니다. 첫 번째 방식은 가격을 고정하는 것입니다. 1달러를 사용할 수 있다면 데이터 웨어하우스에서 얼마만큼의 성능을 얻을 수 있을까요? 가격 대비 성능이 높은 데이터베이스는 지출된 1달러당 더 나은 성능을 제공합니다. 따라서 두 데이터 웨어하우스의 비용이 동일할 때 가격을 일정하게 유지하고 비교하면, 가격 대비 성능이 더 높은 데이터베이스가 쿼리를 더 빨리 실행할 것입니다. 가격 대비 성능을 바라보는 두 번째 방식은 성능 고정하는 것입니다. 워크로드를 10분 내에 완료해야 한다면 비용은 얼마일까요? 가격 대비 성능이 높은 데이터베이스는 10분 내에 더 낮은 비용으로 워크로드를 실행할 것입니다. 따라서 두 데이터 웨어하우스의 크기를 동일한 성능을 제공하도록 설정하고 성능을 일정하게 유지하여 비교할 때, 가격 대비 성능이 높은 데이터베이스가 비용이 낮아 돈을 절약할 수 있습니다.

마지막으로 가격 대비 성능의 또 다른 중요한 측면은 예측 가능성입니다. 데이터 웨어하우스 사용자 수가 증가함에 따라 데이터 웨어하우스 비용이 얼마나 될지 알고 있는 것이 계획 수립에 매우 중요합니다. 데이터 웨어하우스는 지금 당장 가장 좋은 가격 대비 성능을 제공하는 것을 넘어서서 더 많은 사용자와 워크로드가 추가되도 예측가능하게 확장되어 가장 좋은 가격 대비 성능을 지속적으로 제공해야 합니다. 이상적인 데이터 웨어하우스는 선형 확장이 가능해야 합니다. 즉, 쿼리 처리량을 두 배로 확장하려면 비용도 두 배 정도(혹은 그 이하)만 들어야 합니다.

이 글에서는 Amazon Redshift가 주요 클라우드 데이터 웨어하우스들에 비해 훨씬 더 나은 가격 대비 성능을 제공한다는 것을 보여주는 성능 결과를 공유합니다. 다시 말해, Amazon Redshift에 다른 데이터 웨어하우스와 동일한 금액을 지출한다면 Amazon Redshift에서 더 나은 성능을 얻을 수 있습니다. 또는 Redshift 클러스터의 크기를 동일한 성능을 제공하도록 설정한다면 이러한 대체품에 비해 낮은 비용을 지불하게 됩니다.

실제 워크로드에 대한 가격 대비 성능

Amazon Redshift를 사용하여 복잡한 추출, 변환, 로드(ETL) 기반 보고서의 배치 처리에서부터 실시간 스트리밍 분석, 1초 이하의 응답 시간으로 수백 또는 수천 명의 사용자를 동시에 서비스해야 하는 저지연 비즈니스 인텔리전스(BI) 대시보드에 이르기까지 매우 다양한 워크로드를 실행할 수 있습니다. 고객을 위한 가격 대비 성능을 지속적으로 개선하는 방법 중 하나는 Redshift 플릿(fleet)의 소프트웨어 및 하드웨어 성능 원격 측정을 지속적으로 검토하고 Amazon Redshift 성능을 더욱 개선할 수 있는 기회와 고객 사용 사례를 찾는 것입니다.

플릿 원격 측정을 기반으로 한 성능 최적화의 최근 사례는 다음과 같습니다.

• 문자열 쿼리 최적화 – Redshift 플릿에서 Amazon Redshift가 다양한 데이터 유형을 처리하는 방식을 분석한 결과, 문자열 중심 쿼리를 최적화하면 고객 워크로드에 상당한 혜택을 줄 수 있음을 발견했습니다. (이 글 후반부에서 자세히 설명하겠습니다.)
• 자동화된 구체화된 뷰(Automated Materialized Views) – Amazon Redshift 고객이 공통적인 서브쿼리 패턴이 있는 쿼리를 많이 실행한다는 것을 발견했습니다. 예를 들어 서로 다른 여러 쿼리가 동일한 조인 조건으로 세 개의 테이블을 조인할 수 있습니다. 이제 Amazon Redshift는 자동으로 구체화된 뷰를 생성하고 관리하면서 기계 학습 기반으로 쿼리 요청시 구체화된 뷰를 자동으로 재작성하여 실행합니다. 이 기능이 활성화되면 자동화된 구체화된 뷰는 사용자 개입 없이 반복 쿼리에 대한 쿼리 성능을 투명하게 높일 수 있습니다. (이 글에서 논의된 벤치마크 결과에는 자동화된 구체화된 뷰가 사용되지 않았음을 참고하세요).
• 높은 동시성 워크로드 – 또 다른 사용 사례는 Amazon Redshift를 사용한 대시보드 유형의 워크로드가 증가한 것입니다. 이러한 워크로드는 수 초 또는 그 이하로 쿼리 응답 시간을 요구하고, 수십 또는 수백 명의 동시 사용자가 동시에 쿼리를 실행하며 스파이크가 있고 자주 예측 불가능한 사용 패턴으로 특징지어집니다. 이 유형의 전형적인 예는 Amazon Redshift 기반 BI 대시보드로, 월요일 아침 많은 사용자들이 한 주를 시작할 때 트래픽 급증이 발생합니다.

특히 높은 동시성 워크로드는 매우 광범위한 적용 가능성이 있습니다. 대부분의 데이터 웨어하우스 워크로드는 동시성이 요구되며, 수백 또는 수천 명의 사용자가 동시에 Amazon Redshift에서 쿼리를 실행하는 것은 드문 일이 아닙니다. Amazon Redshift는 쿼리 응답 시간이 예측 가능하고 빠르도록 설계되었습니다. Redshift Serverless는 필요에 따라 컴퓨팅 리소스를 자동으로 추가하고 제거하여 쿼리 응답 시간을 빠르고 예측 가능하게 유지해 줍니다. 즉, Redshift Serverless 기반 대시보드는 한두 명의 사용자가 액세스할 때 뿐만 아니라 많은 사용자가 동시에 로드할 때에도 계속해서 빨리 로드됩니다.

이러한 유형의 워크로드를 시뮬레이션하기 위해 우리는 100GB 데이터 세트를 사용하는 TPC-DS에서 파생된 벤치마크를 사용했습니다. TPC-DS는 다양한 일반적인 데이터 웨어하우스 쿼리를 포함하는 업계 표준 벤치마크입니다. 100GB 규모의 비교적 작은 규모를 바탕으로 벤치마크의 쿼리는 Redshift Serverless에서 평균 몇 초 내에 실행되는데, 이는 대화형 BI 대시보드를 로드하는 사용자가 기대하는 시간과 유사합니다. 우리는 이 벤치마크의 1~200개의 동시성 테스트를 실행했는데, 이는 1~200명의 사용자가 동시에 대시보드를 로드하려 하는 것을 시뮬레이션한 것입니다. 또한 자동 스케일 아웃을 지원하는 몇 가지 인기 있는 다른 클라우드 데이터 웨어하우스에 대해서도 테스트를 반복했습니다(혹시 이전 글인 Amazon Redshift의 가격 대비 성능 리더쉽을 보셨다면, 자동 스케일 업을 지원하지 않는 Competitor A는 포함시키지 않았습니다). 우리는 평균 쿼리 응답 시간, 즉 사용자가 쿼리가 완료되거나 대시보드가 로드되는 데 기다려야 하는 시간을 측정했습니다. 결과는 다음 차트에 나와 있습니다.

Competitor B는 약 64개의 동시 쿼리까지는 잘 확장되지만, 그 이후에는 추가 컴퓨팅 리소스를 제공할 수 없어 쿼리가 대기열에 들어가게 되어 쿼리 응답 시간이 증가합니다. Competitor C는 자동 확장이 가능하지만, Amazon Redshift와 Competitor B보다 낮은 수준의 쿼리 처리량으로 확장되며 쿼리 실행 시간을 낮게 유지할 수 없습니다. 또한 컴퓨팅 리소스가 부족해지면 쿼리 대기열을 지원하지 않아 약 128명의 동시 사용자 이상으로 확장할 수 없습니다. 그 이상의 쿼리를 보내면 시스템에 의해 거부됩니다.

여기서 Redshift Serverless는 수백 명의 사용자가 동시에 쿼리를 실행해도 약 5초 정도의 비교적 일정한 쿼리 응답 시간을 유지할 수 있습니다. Competitor B와 C의 평균 쿼리 응답 시간은 데이터 웨어하우스의 부하가 증가함에 따라 꾸준히 증가하여, 데이터 웨어하우스가 바쁠 때 사용자가 쿼리 결과를 기다려야 하는 시간이 최대 16초까지 늘어납니다. 이는 사용자가 대시보드를 새로고침(재로드 시 여러 개의 동시 쿼리가 제출될 수 있음)하려고 할 때, Amazon Redshift가 훨씬 더 일관된 대시보드 로드 시간을 유지할 수 있으며 심지어 수십에서 수백 사용자가 동시에 대시보드를 로드하더라도 마찬가지입니다.

Amazon Redshift는 (Amazon Redshift의 가격 대비 성능 리더쉽에서 설명한 바와 같이) 짧은 쿼리에 대해 매우 높은 쿼리 처리량을 제공할 수 있기 때문에, 더 효율적으로 확장하여 이러한 높은 동시성을 처리할 수 있으며, 비용이 상당히 낮습니다. 이를 정량화하기 위해 앞서 언급한 테스트에서 각 데이터 웨어하우스에 대한 공개된 온디맨드 가격으로 가격 대비 성능을 살펴보면 다음 차트와 같습니다. 프로비저닝된 클러스터에서 Amazon Redshift를 실행하는 데 있어 예약 인스턴스(RI)를 사용하는 것이 가장 낮은 비용이 발생한다는 점을 주목할 필요가 있습니다. 특히 3년 RI를 전액 선납하는 옵션이 가장 우수한 가격 대비 성능을 제공합니다.

그래서, Amazon Redshift는 더 높은 동시성에서 뛰어난 성능을 제공할 뿐만 아니라, 상당히 낮은 비용으로 사용할 수 있습니다. 가격 대비 성능 차트의 각 데이터 포인트는 특정 동시성에서 벤치마크를 실행하는 비용입니다. 가격 대비 성능이 선형적이기 때문에 임의의 동시성에서 벤치마크를 실행하는 비용을 동시성(이 차트에서는 동시 사용자 수)으로 나누면 이 벤치마크에 새로운 사용자를 추가하는 비용을 알 수 있습니다.

이전 결과를 직접 다시 확인하는 방법은 간단합니다. 벤치마크에 사용된 모든 쿼리는 GitHub 저장소에서 확인할 수 있으며, 성능은 데이터 웨어하우스를 실행하고, Amazon Redshift에서 동시성 스케일링을 활성화하거나(다른 웨어하우스에서는 해당 자동 스케일링 기능), 데이터를 로드하고(수동 튜닝이나 데이터베이스 특화 설정 없이), 각 데이터 웨어하우스에서 동시성 1~200 범위에서 32단계로 동시 쿼리 스트림을 실행하여 측정합니다. 앞서 말씀드린 GitHub 저장소에서는 공식 TPC-DS 데이터 생성 키트를 사용하여 Amazon Simple Storage Service(Amazon S3)에서 다양한 규모의 미리 생성된(수정되지 않은) TPC-DS 데이터를 참조할 수 있습니다.

문자열 중심 워크로드 최적화

앞서 언급했듯이 Amazon Redshift 팀은 고객에게 더 나은 가격 대비 성능을 제공할 수 있는 새로운 기회를 지속적으로 모색하고 있습니다. 최근에 출시된 개선 사항 중 하나는 문자열 데이터에 대한 쿼리 성능을 크게 향상시킨 최적화입니다. 예를 들어 SELECT sum(price) FROM sales WHERE city = 'New York'와 같은 쿼리로 뉴욕시에 있는 소매점에서 발생한 총 수익을 찾고 싶을 수 있습니다. 이 쿼리는 문자열 데이터(city = 'New York')에 대한 조건을 적용합니다. 이미 아시겠지만, 문자열 데이터 처리는 데이터 웨어하우스 애플리케이션에서 매우 일반적인 사용 사례입니다.

고객 워크로드가 얼마나 자주 문자열을 활용하는지 정량화하기 위해, 우리는 Amazon Redshift에서 관리하는 수만 개의 고객 클러스터의 플릿 원격측정을 사용하여 문자열 데이터 타입 사용에 대한 자세한 분석을 수행했습니다. 분석 결과 90%의 클러스터에서, 문자열 컬럼이 최소 30% 이상을 차지했고, 50%의 클러스터에서는 문자열 컬럼이 최소 50% 이상을 차지했습니다. 더욱이 Amazon Redshift 클라우드 데이터 웨어하우스 플랫폼에서 실행되는 대부분의 쿼리가 최소 하나의 문자열 열에 접근합니다. 또 다른 중요한 요인은 문자열 데이터가 매우 자주 낮은 카디널리티[1](low cardinality)라는 것입니다. 이는 컬럼이 상대적으로 적은 수의 고유한 값을 갖고 있다는 의미입니다. 예를 들어, 수십억 개의 행을 포함하는 판매 데이터를 나타내는 주문 테이블이 있더라도, 그 테이블 내의 order_status 컬럼에는 대기 중, 진행 중, 완료 등 고유한 값이 몇 개만 있을 수 있습니다.

이 글을 작성하는 시점에서 Amazon Redshift의 대부분의 문자열 열은 LZO 또는 ZSTD 알고리즘으로 압축됩니다. 이들은 훌륭한 범용 압축 알고리즘이지만, 낮은 카디널리티의 문자열 데이터의 이점을 가져가도록 설계되지 않았습니다. 특히 이들은 데이터에 연산을 수행하기 전에 압축을 해제해야 하며, 하드웨어 메모리 대역폭을 효율적으로 사용하지 못합니다. 낮은 카디널리티의 데이터에는 BYTEDICT라는 다른 유형의 인코딩이 더 최적화될 수 있습니다. 이 인코딩은 데이터베이스 엔진이 먼저 압축을 해제할 필요 없이 압축된 데이터에 직접 연산을 수행할 수 있는 사전기반 인코딩(dictionary-encoding) 스키마를 사용합니다.

문자열 작업이 많은 워크로드에 가격 대비 성능을 더욱 개선하기 위해, Amazon Redshift는 이제 BYTEDICT로 인코딩된 낮은 카디널리티 문자열 컬럼에 대한 스캔(scan)과 조건자 평가(predicate evaluation) 속도를 5~63배 더 빠르게(다음 섹션의 결과 참조) 하는 추가 성능 향상 기능을 제공합니다. 이는 LZO 또는 ZSTD와 같은 대체 압축 인코딩 방식과 비교했을 때의 속도입니다. Amazon Redshift는 가볍고, CPU 효율적인 BYTEDICT로 인코딩된 낮은 카디널리티 문자열 컬럼에 대한 스캔을 벡터화하여 이러한 성능 개선을 달성합니다. 이러한 문자열 처리 최적화를 통해 최신 하드웨어가 제공하는 메모리 대역폭을 효과적으로 활용하여 문자열 데이터에 대한 실시간 분석이 가능해집니다. 새로 도입된 이러한 기능은 낮은 카디널리티(고유한 문자열 값이 몇 백 개 미만) 문자열 컬럼에 최적화되어 있습니다.

여러분은 Amazon Redshift 데이터 웨어하우스에서 자동 테이블 최적화를 활성화하면 이와같은 새로운 고성능 문자열 향상의 장점을 자동으로 얻을 수 있습니다. 테이블에 자동 테이블 최적화가 활성화되어 있지 않다면, Amazon Redshift 콘솔의 Amazon Redshift Advisor에서 문자열 컬럼에 대한 BYTEDICT 인코딩 적합성 권장사항을 받을 수 있습니다. 또한 낮은 카디널리티 문자열 컬럼에 BYTEDICT 인코딩을 적용한 새 테이블을 정의할 수 있습니다. Amazon Redshift의 문자열 향상 기능은 현재 Amazon Redshift를 사용할 수 있는 모든 AWS 리전에서 이용할 수 있습니다.

성능 결과

문자열 향상 기능의 성능 영향을 측정하기 위해 저희는 낮은 카디널리티 문자열 데이터로 구성된 10TB(테라바이트) 데이터셋을 생성했습니다. 짧은 문자열, 중간 문자열, 긴 문자열의 세 가지 버전을 생성했는데 각각 Amazon Redshift 플릿 원격측정의 25번째, 50번째, 75번째 백분위수 문자열 길이에 해당합니다. 이 데이터를 Amazon Redshift에 두 번 로드했으며, 첫 번째 경우에는 LZO 압축을, 다른 한 경우에는 BYTEDICT 압축을 사용하여 인코딩했습니다. 마지막으로 이 낮은 카디널리티 문자열 데이터셋에 대해 많은 행(테이블의 90%), 중간 수의 행(테이블의 50%), 몇 개의 행(테이블의 1%)을 반환하는 스캔 중심 쿼리의 성능을 측정했습니다. 성능 결과는 다음 차트에 요약되어 있습니다.

이 내부 벤치마크에서 많은 행과 일치하는 조건자를 가진 쿼리는 새로운 벡터화된 BYTEDICT 인코딩을 사용했을 때 LZO에 비해 5~30배의 성능 향상을 보였습니다. 반면에 적은 행과 일치하는 조건자를 가진 쿼리는 10~63배의 성능 향상을 보였습니다.

Amazon Redshift Serverless의 가격 대비 성능

이 글에서 제시된 높은 동시성 성능 결과 외에도 저희는 3TB 규모의 더 큰 데이터셋을 사용하여 TPC-DS 기반 클라우드 데이터 웨어하우스 벤치마크를 통해 Redshift Serverless의 가격 대비 성능을 다른 데이터 웨어하우스와 비교했습니다. 이 경우 경쟁사의 공개된 온디맨드 가격을 기준으로 시간당 $32에서 10% 이내의 유사한 가격대의 데이터 웨어하우스를 선택했습니다. 이 결과에서 Amazon Redshift RA3 인스턴스와 마찬가지로 Redshift Serverless가 다른 주요 클라우드 데이터 웨어하우스에 비해 가격 대비 성능이 더 우수함을 보여줍니다. 항상 그렇듯이 이 결과는 GitHub 저장소의 SQL 스크립트를 사용하여 재현할 수 있습니다.

Amazon Redshift가 여러분의 데이터 분석 요구사항을 어떻게 충족시킬 수 있는지 확인하는 최선의 방법으로, 여러분만의 PoC (Proof of Concept) 워크로드를 사용하여 Amazon Redshift를 사용해보실 것을 권장합니다.

여러분의 워크로드를 위한 최적의 가격 대비 성능 찾기

이 글에서 사용된 벤치마크는 업계 표준 TPC-DS 벤치마크에서 파생되었으며 다음과 같은 특징이 있습니다.

• 스키마와 데이터는 TPC-DS에서 수정되지 않은 상태로 사용됩니다.
• 쿼리는 TPC-DS 키트의 기본 랜덤 시드를 사용하여 생성된 쿼리 매개변수로 공식 TPC-DS 키트를 사용하여 생성됩니다. 데이터 웨어하우스가 기본 TPC-DS 쿼리의 SQL dialect을 지원하지 않는 경우 TPC 승인 쿼리 변형이 사용됩니다.
• 이 테스트에는 99개의 TPC-DS SELECT 쿼리가 포함됩니다. 유지 관리(maintenance) 및 처리량(throughput) 단계는 포함되지 않습니다.
• 3TB 단일 동시성 테스트의 경우 3개의 파워 런(Power Run)이 실행되며 각 데이터 웨어하우스에 대해 최고 실행 결과가 선택됩니다.
• TPC-DS 쿼리에 대한 가격 대비 성능은 시간당 비용(USD)에 벤치마크 런타임(시간)을 곱하여 계산되며, 이는 벤치마크를 실행하는 비용입니다. 모든 데이터 웨어하우스에 대해 앞서 언급한 대로 예약 인스턴스(Reserved Instance) 가격이 아닌 최신으로 공개된 온디맨드(on-demand) 가격이 사용됩니다.

우리는 이것을 클라우드 데이터 웨어하우스 벤치마크라고 부르며, GitHub 저장소에 있는 스크립트, 쿼리 및 데이터를 사용하여 앞서 언급한 벤치마크 결과를 쉽게 재현할 수 있습니다. 이 스크립트, 쿼리, 데이터는 앞서 설명한 대로 TPC-DS 벤치마크에서 파생된 것이지만, 우리 테스트 결과가 TPC-DS의 공식적인 스펙과 다르므로 게시된 TPC-DS 결과와는 비교할 수 없습니다.

결론

Amazon Redshift는 다양한 워크로드에 대해 업계 최고의 가격 대비 성능을 제공하기 위해 노력하고 있습니다. Redshift Serverless는 선형적으로 확장되며 최고(가장 낮은 비용) 가격 대비 성능을 지원하여 수백 명의 동시 사용자를 지원하면서도 일관된 쿼리 응답 시간을 유지합니다. 이 글에서 논의된 테스트 결과에 따르면 Amazon Redshift는 동일한 동시성 수준에서 가장 성능상 비슷한 경쟁업체(경쟁업체 B)보다 최대 2.6배 더 나은 가격 대비 성능을 보입니다. 앞서 언급했듯이 3년 전액 선납 옵션으로 예약 인스턴스를 사용하면 Amazon Redshift를 가장 낮은 비용으로 실행할 수 있으므로 이 게시물에서 사용한 온디맨드 인스턴스 가격과 비교할 때 상대적인 가격 대비 성능이 더욱 좋아집니다. 지속적인 성능 개선을 위한 AWS의 접근 방식에는 고객 사용 사례 및 관련 확장성 병목 현상을 이해하려는 고객 집착(customer obsession)과 지속적인 플릿 데이터 분석을 통해 상당한 성능 최적화를 할 기회를 식별하는 독특한 조합이 포함됩니다.

각 워크로드는 고유한 특성이 있으므로 시작 단계라면 Amazon Redshift가 비용을 절감하면서도 더 나은 성능을 제공하는 방식을 이해하는 최선의 방법은 PoC를 하는 것입니다. 직접 PoC를 할 때는 쿼리 처리량(시간당 쿼리 수), 응답 시간, 가격 대비 성능과 같은 적절한 메트릭에 초점을 맞추는 것이 중요합니다. 이를 직접하시거나 AWS의 지원 또는 시스템 통합 및 컨설팅 파트너의 지원을 받아 프로토타입을 구축함으로써 데이터 기반 의사결정을 내릴 수 있습니다.

Amazon Redshift의 최신 개발 사항을 지속적으로 확인하려면 Amazon Redshift 새소식 피드를 팔로우하세요.

[1] 특정 컬럼에서 사용한 문자열에서 유니크한 값이 적다는 의미입니다. 데이터 웨어하우스에서 사용하는 문자열 컬럼은 다양한 자연어 형태로 입력하기보다는 주로 분류 등을 위한 역할로 사용하기 때문입니다.