Cost-Effective Data Analytics across Multiple Cloud Regions

ABSTRACT

지리적으로 분산된 클라우드 지역에 저장된 데이터를 가장 저렴한 비용으로 처리하기위한 클라우드 네이티브 데이터 분석엔진을 제안,4개 지역 공용 클라우드 설정에 대한 의사 결정 지원 쿼리의 경우 비용이 15.1% 감소했다.

INTRODUCTION

• 보통 지리적으로 가까운 region에서 더 빠르기 때문에 여러 기업에서는 region별로 서비스를 제공한다.
• 예를들어서 아시아에 저장된 고객리스트, 미국에 저장된 고객 리스트등 흩어진 데이터들을 모아서 분석하기위해 , 다중 regions 에 포함된 데이터들에 대해 분석쿼리를 실행하는것은 비싸고 비효율적
• 여기서 문제가 발생 : 여러 region에 걸친 데이터들을 모두모아 단일 지역에 복제하기위해 옮겨야하는데 추가적인 전송비용 + 데이터 저장비용이 발생, 또 시간적으로도 매우 많은 시간이 걸림 (ex: 케이프타운 region → 시드니리전으로 1gb 전송하는데 평균5분걸림)
• 목표 : 비용 최적화
• **대역폭과 대기시간을 고려한 네트워크를 통한 작업배치에 대한 연구 관련Suraj Pandey, Adam Barker, Kapil Kumar Gupta, and Rajkumar Buyya. 2010. Minimizing Execution Costs when Using Globally Distributed Cloud Services. In 2010 24th IEEE International Conference on Advanced Information Networking and Applications. 222–229. https://doi.org/10.1109/AINA.2010.30
• Tarek Elgamal. 2018. Costless: Optimizing cost of serverless computing through function fusion and placement. In 2018 IEEE/ACM Symposium on Edge Computing (SEC). IEEE, 300–312.
• **JCT 최적화 관련Raajay Viswanathan, Ganesh Ananthanarayanan, and Aditya Akella. 2016. CLARINET: WAN-Aware Optimization for Analytics Queries. In 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI 16). USENIX Association, Savannah, GA, 435–450. https://www.usenix.org/conference/osdi16/ technical-sessions/presentation/viswanathan
• Qifan Pu, Ganesh Ananthanarayanan, Peter Bodik, Srikanth Kandula, Aditya Akella, Paramvir Bahl, and Ion Stoica. 2015. Low Latency Geo-Distributed Data Analytics. SIGCOMM Comput. Commun. Rev. 45, 4 (Aug. 2015), 421–434. https://doi.org/10.1145/2829988.2787505

이러한 문제를 해결하고 목표를 달성하기 위해 살펴보아야할 특징들과 발생가능한 문제점들

• region 별로 다른 가격 ( EC2 m5.2xlarge 인스턴스 비용은 버지니아 북부 지역보다 상파울루 지역에서 약 59% 더 비싸다)
• region 별로 다른 데이터 전송비용 (아프리카 및 남미와 같은 대륙에서 데이터를 전송하는 경우 AWS의 경우 북미에서 전송하는 비용보다 최대 13배 더 비싸다)
• 데이터 전송 시간은 region 을 이동할때 10배 이상이며 항상 변동된다.
• 분석 쿼리를 실행하는 데 몇 시간이 걸리는 것이 일반적이다.
• 데이터 세트의 크기와 가용성은 언제든지 변경가능

2 SYSTEM ARCHITECTURE

• 비용최적화라는 목표를 위해, region별로 비용과 성능에 영향을 미치는 모든 요소들을 지속적으로 모니터링하고 주어진 JCT 요구사항에 따라 최대한 비용 효율적인 실행계획을 도출하려고자함 ( = cross-region analytics job 을 가지고 가격 효율적인 plan 을 찾는다 )

• 

Status retriever

• 각 리전마다 job scheduling 에 대한 필수정보들을 수집하고 제어하는 status retriever가 있다.
• 이것이하는일은b) 다른 region과 주기적으로 통신하여 네트워크 대역폭내역 수집 (대역폭이 중요한 이유:c) 해당 지역 데이터세트의 metadata 수집
• we may want to set a limit on job completion time)
• a) api를 통해 각 cloud vendor 로 부터 가격 책정

→ 가장 중요한 parameters 는 region 별 데이터 전송가격과 각 지역별로 컴퓨팅 리소스가격이다.

• 모든 region의 status retriever 는 p2p 네트워크를 통해 데이터를 동기화해야할 각 지역의 작업 스케쥴러가 결정을 내릴 충분한 정보를 수집해준다.

Job scheduler

• Spark SQL 에서 Catalyst optimizer 와 동일한 역할을 함(Spark SQL에서는 Catalyst Optimizer가 최적화를 대신해준다)
• 소스데이터셋의 메타데이터와 데이터 쿼리를 입력으로 받아서 물리적 실행 계획을 생성
• 또한 설계에서 계획을 선택할 때 비용과 네트워크 대역폭을 고려.대부분 작업 배치 및 중간 결과가 로컬 I/O 작업 대신 지배적인 요소가 됩니다. (?)

Job manager

• Job manager 는 Job scheduler 에 의해 생성된 현재 실행계획과 각 Job에 대한 해당작업상태를 유지, 그리고 다른 region에 execution plan과 다른 job plan을 전파합니다.
• 각 job manager는 execution plan 에 따라 하나이상의 하위작업을 실행한다
• 이작업이 완료되면 작업 관리자는 작업 스케쥴러를 호출해서 재평가하고 작업상태와 잠재적인 계획변경을 브로드캐스트한다
• 변경된 계획으로 인해 작업관리자가 하위작업실행을 중단할수 있다.

Task executor

• computes resources로 이루어져있다.
• It is built on top of existing cloud offerings to remove the resource constraints of some previous works [12]. Because there is no stable access pattern, and each job requires a different amount of resources, leveraging serverless functions (e.g., AWS Lambda[2]) as the main executor improves resource utilization [14]. Using spot VM instances to run the queries may save cost when incoming workloads can be well predicted.

Transient datastore

• 하위 작업의 결과는 임시 데이터 저장소에 저장됩니다. 임시 데이터는 나중 단계에서 사용될 수 있으므로 다음 하위 작업으로 전달된 직후에 삭제되지 않습니다. 작업 관리자는 데이터 저장소를 정기적으로 스캔하여 일정 시간이 지나면 실행 계획에서 참조하지 않는 임시 데이터를 식별하고 불필요한 저장 비용을 피하기 위해 제거합니다.

3 PRELIMINARY RESULTS

• 제안된 시스템의 효율성을 검증하기 위해 AWS에서 실험을 진행
• 10GB의 TPC-DS[16] 데이터 세트를 생성. 데이터 세트 중 한 region의 Amazon S3 [1] 버킷에 4개의 비교적 작은 테이블을 놓고 4개 region 모두에 큰 테이블을 고르게 배포했습니다.
• We simulated Query 7 of TPC-DS test suite in Python programs on EC2 c5d.2xlarge spot instances.
• 4가지 전략
  1. Aggregation ) 모든 데이터를 비용적은 region으로 몰아넣고 모든 계산수행
  2. In-place ) 데이터이동 X , 각 region 에서 가능한 많은 계산을 수행한다음, 해당 영역 중 하나에서 중간결과를 집계 (지역별로 컴퓨팅 가격이 다르다는걸 고려하지 않음)
  3. Optimized In-place ) 각 region 마다 계산수행하기전에 작은 테이블을 모든 region 에 배포(최적화)(the WAN-usage optimal solution)
  4. Hybrid a+c ) 컴퓨팅및 데이터 전송가격으로 결정 (이게 가장좋은 결과를 도출) - 15프로나 좋아짐 가격만 따지면 가장좋은 방법이됨.
  • ** WAN  
    • WAN 최적화가 중요한 이유?다양한 비즈니스 프로세스가 느린 네트워크의 영향을 받습니다. 직원이 파일에 액세스하는 것과 같은 간단한 작업도 허용할 수 없을 정도로 느려질 수 있습니다. 네트워크가 끌리는 경우 비즈니스 전체 파일 관리자를 로드하는 데 시간이 걸리고 파일을 여는 데 더 오래 걸릴 수 있습니다. 2분의 작은 작업처럼 보이지만 이러한 문제는 빠르게 누적됩니다.
    • 한편 관리자는 비효율적이고 대기 시간이 긴 네트워크 인프라와 싸우는 경우 네트워크를 효과적으로 관리 및 모니터링하고 네트워크 보안을 보장하는 데 어려움을 겪을 수 있습니다. WAN 최적화는 잠재적으로 관리자( 및 해당 소프트웨어 도구) 가 모든 장치와 최종 사용자를 보다 효과적으로 보호 할 수 있도록 합니다 .
    • 기업은 클라우드 컴퓨팅, 애플리케이션 및 웹 포털과 같은 기타 네트워크 전체 기술의 사용 증가로 인해 WAN 설정에 대한 압박을 점점 더 많이 받고 있습니다. 이러한 복잡성과 볼륨을 사전에 관리하지 않으면 네트워크 속도 저하가 주요 문제가 될 수 있으므로 WAN 전반에 걸친 관련 트래픽 증가 는 WAN 최적화를 더욱 중요하게 만듭니다.
    • WAN 최적화에는 더 많은 대역폭을 수신하기 위해 네트워크의 특정 부분에 우선 순위를 지정하는 작업이 포함됩니다. 예를 들어 중요한 데이터 처리 작업과 관련된 네트워크 부분에 더 많은 처리량과 대역폭을 할당하여 작업이 빨리 완료되도록 할 수 있습니다. 네트워크에 대한 물리적 또는 논리적 변경을 통해 많은 WAN 개선을 달성할 수 있습니다.
    • https://ledgku.tistory.com/17

  

4 DISCUSSION(고찰)

Challenge#1 Design an efficient job scheduling algorithm.

• Catalyst같은 기존 쿼리 옵티마이저는 최상의 실행계획을 검색하는데, 단점으로는 실행시간이 너무많이 걸리고 상당한 오버헤드발생가능성이 있다.
• 또 실제비용과 네트워크대역폭을 고려하면 문제가 더 복잡해진다
• 이렇듯 이런 단점을 해결할 빠르게 찾을수 있는 알고리즘이 필요함

Challenge#2 Estimate required resources for subtasks. Both

• 스팟 vm과 서버리스 모두 일정수준의 프로비저닝이 필요한데 오버프로비저닝,언더프로비저닝 모두 피해야함.
• 메모리를 적당히 사용하기위해 sub 잡작업에 필요한 최소메모리추정을 위해 프로그램 분석기술을 적용가능

Challenge#3 Manage job states between regions

• 교차지역 데이터 분석 엔진은 내결함성이 있어야함.
• 모든 작업상태는 작업관리자간에 공유됨
• region의 작업관리자가 제대로 작동하지않으면 다른 region에서 알아채고 인계받아야함
• 한마디로 문제가 생긴다면 기존작업을 다른지역으로 마이그레이션해야함

Challenge#4 Avoid unnecessary execution plan switchin

• 런타임에 새로운 실행계획이 너무자주 발생하지않도록 함