AWS 기술 블로그
Amazon Redshift의 가격 대비 성능 벤치 마크 결과
데이터는 전략자산입니다. 적시에 데이터로부터 가치를 얻기 위해서는 비용을 낮게 유지하면서도 규모에 맞는 성능을 제공할 수 있도록 고성능 시스템이 필요합니다. Amazon Redshift는 가장 유명한 클라우드 데이터 웨어하우스로 수만 명의 고객이 매일 엑사바이트 규모의 데이터를 분석하는 데 사용합니다. 고객들은 Amazon Redshift 환경으로 더욱더 많은 데이터를 가져오기 때문에, 저희는 가격 대비 성능의 비율을 개선하기 위한 기능을 지속해서 추가하고 있습니다.
이 글은 Amazon Redshift 플릿의 텔레메트리 데이터(telemetry data)로 바라본 분석 워크로드 트렌드, Amazon Redshift의 가격 대비 성능을 높이기 위해 발표된 새로운 기능들, TPC-DS와 TPC-H에서 파생된 벤치마크 결과를 포함하고 있습니다.
데이터 기반의 성능 최적화
여러분이 사용하고 있는 실제 워크로드에 지속해서 개선된 성능을 체감할 수 있도록 저희는 끊임없이 Amazon Redshift의 가격 대비 성능의 향상에 집중하고 있습니다. 이를 위해 Amazon Redshift 팀은 성능 최적화를 위한 데이터 기반 접근법을 이용하고 있습니다. Werner Vogels는 Amazon Redshift 그리고 클라우드에서의 성능 최적화 기술에서 우리의 방법론에 대해 설명했습니다. 또한 저희는 대규모 고객 기반의 원격 성능 분석을 통해 고객에게 가장 중요한 Redshift 성능 향상에 집중해 왔습니다.
이쯤에서, 여러분은 왜 가격 대비 성능이 중요한지 물을 수도 있을 것입니다. 데이터 웨어하우스의 중요한 측면 중 하나는 데이터가 증가함에 따라 어떻게 규모를 확장하는가입니다. 데이터가 증가할수록 TB당 더 큰 비용을 지불하시겠습니까? 아니면 비용이 일관되고 예측할 수 있는 상태로 사용하시겠습니까? 저희는 여러분의 데이터가 증가해도 Amazon Redshift가 높은 성능뿐만 아니라 일관적인 가격 대비 성능을 가질 수 있도록 노력하고 있습니다.
높은 동시성, 낮은 지연 시간 워크로드 최적화
저희는 고객들이 낮은 지연시간과 높은 동시성 쿼리를 요구하는 분석 애플리케이션을 점점 더 만들고 있다는 트렌드를 발견했습니다. 데이터 웨어하우징의 맥락에서는 수백 또는 수천 명의 사용자가 5초 이하의 응답시간 SLA (Service-Level Agreement)로 쿼리를 실행한다는 것을 의미합니다.
일반적인 사용사례로 많은 분석가들에게 Amazon Redshift 기반 비즈니스 인텔리전스(business intelligence) 대시보드로 분석을 제공할 수 있습니다. 고객이 Amazon Redshift 기반 대시보드를 이용해 환율을 기반한 데이터를 처리하고, 이 데이터로부터의 인사이트를 그들의 사용자에게 전달하는 것을 예로 들 수 있습니다. 이 사용자들은 평균적으로 동시에 200개의 쿼리를 Amazon Redshift에 생성하며, 이는 1.5초의 SLA를 가진 P90 쿼리로 마켓의 개장과 폐장 시 1,200개로 급증할 수 있습니다. Amazon Redshift는 이 요구사항을 충족할 수 있으므로 고객은 비즈니스 SLA를 충족하고 사용자에게 가능한 최고의 서비스를 제공할 수 있습니다.
우리가 추적하는 세부 지표는 단기 실행 쿼리(런타임이 1초 미만인 쿼리)를 수행한 모든 클러스터의 런타임 비율입니다. 작년 한 해 동안, 아래의 차트에서 볼 수 있는 것처럼 Amazon Redshift 플릿에서 단기 실행 쿼리가 아주 큰 폭으로 상승했습니다.
저희는 이런 워크로드를 Amazon Redshift가 어떻게 실행했는지 확인하는 과정에서 성능을 최적화할 기회를 찾았으며 이에 따라 단기 실행 쿼리 실행 시 더 나은 스루풋(throughput)을 제공할 수 있습니다.
- 저희는 Amazon Redshift의 쿼리 계획 오버헤드(query-planning overhead)를 아주 큰 폭으로 줄였습니다. 비록 큰 변화는 아니지만 단기 실행 쿼리 런타임에 있어서는 중요할 수 있습니다.
- 동시에 작동하는 프로세스들이 같은 리소스를 사용하기 위해 경쟁하는 상황이 생길 것을 대비해 일부 코어 컴포넌트의 성능을 개선했습니다. 이에 따라 추가로 쿼리 오버헤드를 줄였습니다.
- 저희는 Amazon Redshift가 쿼리 병렬처리를 개선하기 위해 단기 실행 쿼리들이 더욱 효율적으로 동시성 확장 클러스터에 버스트(burst) 하도록 개선했습니다.
이러한 기술적 개선이 이루어지고 난 후 저희는 Amazon Redshift가 어떻게 변했는지 확인하기 위해 TPC-DS에서 파생된 클라우드 데이터 웨어하우스 벤치마크를 내부적으로 실행했습니다(GitHub에서 사용할 수 있는 벤치마크에 대한 자세한 설명은 이 게시물의 뒷부분 섹션을 참조하십시오). 높은 동시성과 낮은 지연시간의 워크로드를 시뮬레이션하기 위해, 10GB의 작은 데이터를 이용해 모든 쿼리가 수 초 안에 실행이 될 수 있도록 했습니다. 또한 다른 클라우드 데이터 웨어하우스에도 동일한 벤치마크를 실행했습니다. 이 테스트에서는 Amazon Redshift의 동시성 확장과 같은 자동 스케일링 기능을 활성화하지 않았습니다. 왜냐하면 모든 데이터 웨어하우스가 이를 지원하는 것은 아니기 때문입니다.
저희는 ra3.4xlarge의 Amazon Redshift 클러스터를 사용했고 다른 웨어하우스는 온디맨드 요금을 기준으로 가장 비슷한 가격의 구성으로 조정했습니다. 아래의 차트에 나와있는 것처럼 Amazon Redshft는 낮은 지연과 높은 동시성을 가진 단기 실행 쿼리가 주로 필요한 분석 애플리케이션에서 최대 8배 이상의 더 나은 성능을 제공합니다.
Amazon Redshift의 동시성 확장을 이용하면, 사용자의 동시성이 증가함에 따라서 자연스럽게 스루풋은 추가적인 Amazon Redshift 클러스터로 확장됩니다. 우리의 원격 측정 데이터를 보면 많은 고객이 이런 분석 애플리케이션을 만들기 위해 Amazon Redshift를 이용하는 것을 알 수 있습니다.
이는 데이터 기반 접근방식을 이용하여 성능을 개선하고 비용을 줄일 수 있도록 지원하기 위한 우리 팀의 내부적인 엔지니어링 개선 내용 중 아주 일부만 드러내고 있습니다.
가격 대비 성능을 향상시키는 새로운 기능
계속해서 진화하는 데이터 환경에 따라, 사용자는 모든 워크로드와 애플리케이션에 규모에 따른 최고성능과 낮은 비용을 적용할 수 있도록 계속해서 새로운 기능을 지원하는 고성능 데이터 웨어하우스를 원합니다. 저희는 여러분이 모든 비즈니스 문제를 해결할 수 있도록, 추가 비용 없이 Amazon Redshift의 가격 대비 성능을 월등히 높여주는 새로운 기능들을 추가해 왔습니다. AWS Nitro System을 이용한 동급 대비 최고 하드웨어, AQUA를 이용한 하드웨어 가속, 구체화된 뷰(Materialized view)를 이용하여 더 빠른 실행을 위한 자동 재작성 쿼리(auto-rewriting query), 스키마 최적화를 위한 자동 테이블 최적화 작업(Automatic Table Optimization, ATO), 다이내믹한 동시성과 리소스 활용 최적화를 위한 자동 워크로드 관리(Automatic Workload Management, WLM), 단기 실행 쿼리 가속, 자동 구체화된 보기(Automatic materialized view), 벡터화 및 단일 명령 다중 데이터(single instruction/multiple data, SIMD) 처리와 같은 기능들이 추가되어왔습니다. 여러분이 분석 애플리케이션 개발과 같은 더욱 의미 있는 일에 집중하고 성능관리에 들어가는 노력을 최소화하실 수 있도록 Amazon Redshift는 스스로 학습하고 튜닝하는 데이터 웨어하우스로 진화해왔습니다.
최신 Amazon Redshift의 성능 향상을 검증하기 위해 다른 클라우드 데이터 웨어하우스와 비용 대비 성능 벤치마크를 실행했습니다. 이 테스트는 10개의 ra3.4xlarge 노드로 Amazon Redshift 클러스터를 구성하여 TPC-DS와 TPC-H에 기반한 벤치마크를 실행했습니다. 다른 데이터 웨어하우스에 이 벤치마크를 실행하기 위해서, 각 데이터 웨어하우스의 온디맨드 요금을 기준으로 Amazon Redshift 클러스터와 비용적으로 가장 비슷한(시간당 $32.60) 웨어하우스 크기를 선택했습니다. Amazon Redshift는 자동으로 튜닝되는 웨어하우스이므로 모든 테스트가 “바로 가능”합니다. 즉, 수동적인 튜닝과 특별한 데이터베이스 설정을 적용하지 않았으며 클러스터를 생성하고 바로 벤치마크를 실행했습니다. 벤치마크의 실행 비용을 계산하기 위해 시간당 비용(USD)과 벤치마크 실행시간을 곱해서 비용 대비 성능 값을 계산했습니다.
TPC-DS 및 TPC-H 기반 테스트 모두에서 Amazon Redshift가 일관되게 최고의 가격 대비 성능을 제공하는 것을 확인할 수 있었습니다. 아래의 차트는 TPC-DS 기반의 벤치마크 결과를 나타냅니다.
아래의 차트는 TPC-H 기반의 벤치마크 결과를 나타냅니다.
이 벤치마크들은 Amazon Redshift가 다른 데이터 웨어하우스와 비교했을 때 최고의 가격 대비 성능을 가졌다는 것을 다시 확인시켜주지만, Amazon Redshift가 여러분의 데이터 니즈를 어떻게 충족시킬 수 있는지 확인하기 위해 여러분의 PoC(Proof of concept) 워크로드를 이용해서 Amazon Redshift를 사용해보기를 항상 권장합니다.
워크로드에 가장 적합한 가격 대비 성능 찾기
이 게시물에 이용된 벤치마크는 업계 표준 TPC-DS와 TPC-H 벤치마크에서 파생되었으며 아래와 같은 특징을 가집니다.
- TPC-DS와 TPC-H에서 수정되지 않은 상태로 스키마와 데이터를 사용했습니다.
- TPC-DS와 TPC-H에서 수정되지 않은 상태로 쿼리를 사용했습니다. 만약 웨어하우스가 기본 TPC-DC 또는 TPC-H 쿼리의 SQL dialect를 지원하지 않는경우 TPC에서 승인한 변형 쿼리를 사용합니다.
- 테스트는 99개의 TPC-DS와 22개의 TPC-H SELECT 쿼리를 사용했습니다. 관리와 스루풋 과정은 포함되지 않습니다.
- TPC-DS와 TPC-H 키트의 기본 랜덤 시드를 이용해 생성된 쿼리 매개변수를 이용하여 3개의 power run(single stream)이 실행됐습니다.
- 가격 대비 성능을 계산할 때 전체 쿼리 런타임 중 주요 메트릭을 사용했습니다. 런타임은 3개의 실행 중 최고 결과를 이용했습니다.
- 벤치마크를 실행시키기 위한 비용을 계산하기 위해 시간당 비용(USD)과 벤치마크 실행시간을 곱한 비용대비 성능값을 계산했습니다. 모든 데이터 웨어하우스의 공식 온디맨드 가격을 이용했습니다.
저희는 이 벤치마크를 Cloud Data Warehouse Benchmark라 부르며, Github에 있는 스크립트, 쿼리, 데이터를 이용해 손쉽게 같은 결과를 도출할 수 있습니다. 이전에 설명한 것처럼 TPC-DS와 TPC-H 벤치마크에서 파생되었지만, 우리의 테스트 결과가 해당 사양과 일치하지 않으므로 공개된 TPC-DS 또는 TPC-H 결과와 비교될 수는 없습니다.
모든 워크로드는 독특한 특징을 가지고 있습니다. 여러분이 만약 처음 시작하는 것이라면, PoC는 Amazon Redshift가 어떻게 여러분의 요구사항을 충족시키는지 이해할 수 있는 최고의 수단입니다. 여러분이 PoC을 수행한다면, 쿼리 스루풋(시간당 쿼리수)과 가격 대비 성능 같은 올바른 지표에 집중하는 것이 중요합니다. 여러분 스스로 또는 AWS의 도움 혹은 시스템 통합/컨설팅 파트너와 함께 PoC을 진행하여 데이터 기반 의사결정을 할 수 있습니다.
결론
이 게시물은 Amazon Redshift 고객으로부터 파악한 분석 워크로드 트렌드, Amazon Redshift의 가격 대비 성능을 개선하기 위한 새로운 기능들, 최신 벤치마크의 결과를 설명했습니다.
이미 Amazon Redshift 고객이시라면, 저희에게 연락하여 무료 최적화 세션과 AWS re:Invent 2021에 발표된 새로운 기능에 대한 브리핑을 받아보세요. Amazon Redshift의 최신정보를 놓치지 않도록 Amazon Redshift 피드에서 What’s New를 팔로우하세요.
– Stefan Gromoll, Senior Performance Engineer, AWS
– Ravi Animi, Senior Product Management Leader, AWS
– Florian Wende, Performance Engineer, AWS