[논문 리뷰] Starling: A Scalable Query Engine on Cloud Function Services

Matthew Perron, Raul Castro Fernandez외 2명|arXiv (Cornell University)|2019. 11. 26.

Cloud Computing and Resource Management참고 문헌 8인용 수 6

한 줄 요약

Starling은 AWS Lambda와 같은 클라우드 함수 플랫폼 위에 구축된 서버리스 쿼리 엔진으로, 클라우드 스토리지에 저장된 데이터에 대해 저비용이고 고확장성 있는 인터랙티브 분석을 가능하게 한다. 세분화된 병렬 처리, 객체 스토리지 기반 최적화된 데이터 셔플링, 느린 실행자(스트래글러) 대응 기법을 통해, 저~중간 수준의 쿼리 워크로드에 대해 프로비저닝된 시스템과 유사한 지연 시간을 유지하면서도 낮은 비용을 달성한다.

ABSTRACT

Much like on-premises systems, the natural choice for running database analytics workloads in the cloud is to provision a cluster of nodes to run a database instance. However, analytics workloads are often bursty or low volume, leaving clusters idle much of the time, meaning customers pay for compute resources even when unused. The ability of cloud function services, such as AWS Lambda or Azure Functions, to run small, fine granularity tasks make them appear to be a natural choice for query processing in such settings. But implementing an analytics system on cloud functions comes with its own set of challenges. These include managing hundreds of tiny stateless resource-constrained workers, handling stragglers, and shuffling data through opaque cloud services. In this paper we present Starling, a query execution engine built on cloud function services that employs number of techniques to mitigate these challenges, providing interactive query latency at a lower total cost than provisioned systems with low-to-moderate utilization. In particular, on a 1TB TPC-H dataset in cloud storage, Starling is less expensive than the best provisioned systems for workloads when queries arrive 1 minute apart or more. Starling also has lower latency than competing systems reading from cloud object stores and can scale to larger datasets.

연구 동기 및 목표

• 클라우드 환경에서 돌발적이거나 저용량의 분석 워크로드에 대해 고정된 클러스터를 프로비저닝하는 데 발생하는 비효율성을 해결한다.
• 특정 형식으로 사전 로딩하거나 전용 클러스터를 준비하지 않아도 인터랙티브 쿼리 성능을 제공한다.
• 서버리스 함수의 세분화되고 즉시 실행 가능한 실행 모델을 활용해 쿼리당 비용을 낮춘다.
• 서버리스 환경에서 발생하는 무상태 워커, 투명한 데이터 셔플링, 스트래글러 효과 등의 과제를 극복한다.
• 임의의 분석 쿼리에 대해 비용과 성능 간의 조정 가능한 트레이드오프를 제공한다.

제안 방법

• 쿼리 연산자를 서버리스 함수 호출로 매핑하여 세분화된 병렬 처리와 즉시 확장 가능한 스케일링을 가능하게 한다.
• 중간 결과를 함수 간 전달하기 위해 클라우드 객체 스토리지(예: Amazon S3)를 셔플 매체로 사용한다.
• 요청 기반 청구 모델 하에서 스토리지 비용을 줄이고 처리량을 향상시키기 위해 중간 결과 형식을 최적화한다.
• 저속 기능 호출이 쿼리 지연 시간에 미치는 영향을 줄이기 위해 스트래글러 감지 및 대응 모델을 구현한다.
• 각 쿼리 단계당 함수 호출 수를 제어할 수 있는 튜닝 장치를 제공하여 비용 또는 지연 시간 최적화를 가능하게 한다.
• Redshift 기반 쿼리 최적화기로 효율적인 조인 순서를 선택하고 전체 계산 비용을 줄인다.

실험 결과

연구 질문

• RQ1 저~중간 수준의 쿼리 워크로드에 대해 서버리스 쿼리 엔진이 프로비저닝된 시스템보다 낮은 비용과 인터랙티브 지연 시간을 달성할 수 있는가?
• RQ2 무상태이자 자원이 제한된 클라우드 함수에서 스트리밍 및 집계와 같은 상태 기반 연산을 어떻게 효율적으로 구현할 수 있는가?
• RQ3 투명하고 고지연 시간을 보이는 스토리지 백엔드를 갖춘 서버리스 환경에서 스트래글러 효과를 어느 정도까지 완화할 수 있는가?
• RQ4 서버리스 함수 기반으로 구축된 시스템이 임의의 쿼리에 대해 기존의 클라우드 네이티브 분석 데이터베이스보다 비용 효율성이 뛰어나게 될 수 있는가?
• RQ5 서버리스 플랫폼의 쿼리당 실행 기반 청구 모델이 클러스터 기반 모델과 비교해 총 소비된 코어-초 수 측면에서 어떻게 다를까?

주요 결과

• 클라우드 객체 스토리지에 저장된 1TB의 TPC-H 데이터셋에서, 쿼리가 1분 이상 간격으로 도착할 경우 Starling은 최고의 프로비저닝된 시스템보다 비용이 저렴하다.
• 대부분의 쿼리에 대해 Starling은 16노드의 Presto 클러스터(presto-16)보다 낮은 총 컴퓨팅 코어-초를 소비하여 더 높은 계산 효율성을 보였다.
• Starling의 쿼리 지연 시간은 데이터 사전 로딩 없이도 클라우드 스토리지에서 직접 읽는 상황에서도 프로비저닝된 시스템과 경쟁 가능한 성능을 보였다.
• 시스템은 명시적인 프로비저닝 결정이나 클러스터 관리 없이도 더 큰 데이터셋에 대해 확장 가능함을 입증했다.
• 스트래글러 대응 기법은 느린 함수 호출이 종합 쿼리 지연 시간에 미치는 영향을 크게 줄였다.
• 객체 스토리지에 최적화된 중간 결과 형식을 사용함으로써 스토리지 비용은 낮추면서도 높은 집합 처리량을 유지할 수 있었다.