AWS 전문가를 위한 Google Cloud: 빅데이터

업데이트: 2019년 10월 30일

이 문서에서는 Amazon에서 Amazon Web Services(AWS)를 통해 제공하는 빅데이터 서비스와 Google에서 Google Cloud를 통해 제공하는 빅데이터 서비스를 비교 설명합니다.

이 문서에서는 다음 서비스 유형을 설명합니다.

  • 수집 서비스 - 소스 환경의 데이터를 안정적인 대상 환경 또는 데이터 유형으로 수집하는 데 사용됩니다.
  • 변환 및 준비 서비스 - 데이터를 필터링 또는 추출하거나 한 데이터 유형 또는 모델에서 다른 데이터 유형 또는 모델로 변환할 수 있습니다.
  • 웨어하우징 및 분석 서비스 - 처리된 데이터를 저장, 분석, 시각화, 상호작용할 수 있습니다.

수집 서비스

이 섹션에서는 AWS와 Google Cloud에서 각각 데이터를 수집하는 방법을 비교합니다.

연결

일부 초기 마이그레이션의 경우, 특히 데이터 수집을 진행 중인 경우에는 일반적으로 대상 클라우드와 다른 네트워크 간에 고대역폭 네트워크 연결을 사용합니다. 다음 표에는 AWS 및 Google Cloud 연결 옵션이 요약되어 있습니다.

기능 AWS Google Cloud
가상 사설망(VPN) 사이트 간 VPN Cloud VPN
Virtual Private Cloud(VPC) 네트워크에 대한 비공개 연결 Direct Connect Dedicated Interconnect
Partner Interconnect
다른 클라우드 서비스에 대한 고속 연결 Direct Connect 다이렉트 피어링
이동통신사 피어링

Google Cloud 옵션에 대한 자세한 내용은 AWS 전문가를 위한 Google Cloud: 네트워킹다른 네트워크에 대한 비공개 연결 섹션을 참조하세요.

스트림 수집

각각의 클라우드 환경으로 데이터 스트림을 수집하는 데 Amazon Kinesis Data StreamsGoogle Pub/Sub를 사용할 수 있습니다. 그러나 각 서비스는 서로 다른 서비스 모델을 사용하여 이 작업을 수행합니다.

서비스 모델 비교

다음 표에서는 Amazon Kinesis Data Streams와 Pub/Sub의 기능을 비교합니다.

기능 Amazon Kinesis Data Streams Pub/Sub
배포 단위 스트림 주제
프로비저닝 단위 샤드 해당 사항 없음(완전 관리형)
데이터 단위 레코드 메시지
데이터 소스 제작자 게시자
데이터 목적지 소비자 구독자
데이터 파티션 나누기 사용자 제공 파티션 키 해당 사항 없음(완전 관리형)
보관 기간 최대 7일 최대 7일
데이터 전송 순서 서비스 제공 시퀀스 키(최대한 노력) 서비스 제공 게시 시간(최대한 노력)
최대 데이터 크기 1MB 10MB
배포 지역 리전 전역
가격 책정 모델 샤드-시간당, PUT 페이로드 단위, 선택적 데이터 보관 메시지 수집 및 전송, 선택적 메시지 보관
Amazon Kinesis Data Streams

Amazon Kinesis Data Streams은 스트리밍 모델을 사용하여 데이터를 수집합니다. 이 모델에서는 제작자가 데이터를 샤드별로 만들고 프로비저닝하는 스트림으로 전송합니다. 스트림의 각 샤드는 초당 최대 1MiB의 입력 대역폭과 초당 1,000회의 데이터 입력을 제공합니다.

사용자는 하위 수준의 REST API나 상위 수준의 Kinesis Producer Library(KPL)를 사용하여 데이터를 Amazon Kinesis Data Streams로 전송합니다. 이 데이터는 다음으로 구성된 데이터 레코드에 저장됩니다.

  • 증분 시퀀스 번호
  • 사용자 제공 파티션 키
  • 데이터 blob

파티션 키는 사용 가능한 샤드에 걸쳐 레코드를 부하 분산하는 데 사용됩니다. 기본적으로 레코드는 24시간 동안 보관됩니다. 그러나 사용자는 이 보관 기간을 최대 7일까지 늘릴 수 있습니다.

사용자는 샤드별로 데이터 레코드를 스트림에서 검색한 후 처리하는 소비자 애플리케이션을 설정합니다. 애플리케이션은 사용 가능한 샤드 간 멀티플렉싱을 담당합니다. Amazon Kinesis Client Library를 애플리케이션에 통합하면 샤드 간 멀티플렉싱이 간소화되며 소비자 애플리케이션 노드 클러스터 전반의 부하 분산과 장애 관리도 관리됩니다.

Pub/Sub

Pub/Sub는 게시자/구독자 모델을 사용하는 메시징 서비스를 제공합니다. Pub/Sub 주제를 만든 후 이 주제에 데이터를 게시할 수 있으며, 주제를 구독하는 각 애플리케이션은 주제에서 수집된 데이터를 검색할 수 있습니다. 이 방식에서는 샤드 수처럼 특정 용량을 정의할 필요가 없습니다.

Pub/Sub에 등록된 각 애플리케이션은 푸시 모델 또는 풀 모델을 사용하여 메시지를 검색할 수 있습니다.

  • 푸시 모델에서는 Pub/Sub 서버가 미리 구성된 URL 엔드포인트에서 구독자 애플리케이션에 요청을 보냅니다.
  • 풀 모델에서는 구독자 애플리케이션이 서버에서 메시지를 요청한 후 메시지가 도달하면 수신을 확인합니다. 풀 구독자는 비동기 또는 동기식으로 메시지를 검색할 수 있습니다.

주제에 게시되는 각 데이터 메시지는 base64로 인코딩되고 크기가 10MB 이하여야 합니다. Pub/Sub는 데이터를 수집할 때 messageId 속성과 publishTime 속성을 각 데이터 메시지에 추가합니다. messageId 속성은 주제 내에서 고유함이 보장되는 메시지 ID이고, publishTime 속성은 데이터 수집 시점에 시스템에서 추가되는 타임스탬프입니다. 게시자는 키-값 쌍 형식으로 속성을 데이터에 추가할 수 있습니다.

데이터 순서

이 섹션에서는 소비자 또는 구독자 애플리케이션에서 요청하는 데이터 순서가 Amazon Kinesis Data Streams와 Pub/Sub에서 어떻게 관리되는지 설명합니다.

Amazon Kinesis Data Streams

기본적으로 Amazon Kinesis Data Streams에서는 파티션 키와 시퀀스 번호를 사용하여 데이터 순서를 유지합니다. 제작자는 스트림에 레코드를 추가할 때 레코드가 전송되는 샤드를 결정하는 파티션 키를 제공합니다. 샤드는 레코드에 증분 시퀀스 번호를 추가한 후 레코드를 안정적으로 저장합니다.

소비자 애플리케이션은 샤드별로 레코드를 요청하고 시퀀스 번호 순서대로 수신합니다. 이 모델에서는 샤드별 순서가 보장되지만 소비자 애플리케이션이 여러 샤드에 요청하는 경우에는 보장되지 않습니다. 또한 한 레코드가 2회 이상 소비자에게 전달될 수 있으므로 정확히 1번만 전달되도록 명시적으로 애플리케이션을 설계해야 합니다. 자세한 내용은 Amazon Kinesis Data Streams 문서의 중복 레코드 처리를 참조하세요.

Pub/Sub

Pub/Sub는 최대한 시스템에서 제공하는 publishTime 속성을 사용하여 게시된 순서대로 메시지를 전송합니다. Pub/Sub는 1회 전송 또는 순서에 따른 전송을 보장하지 않으므로 경우에 따라 한 메시지가 2회 이상 전송되고 순서가 바뀔 수도 있습니다. 구독자는 메시지를 처리할 때 멱등성을 갖고 있어야 하며 필요한 경우 잘못된 순서로 수신된 메시지를 처리할 수 있어야 합니다.

애플리케이션에서 제공하는 시퀀스 번호를 사용하고 소비된 메시지를 버퍼링하면 순서를 더욱 엄격하게 지킬 수 있습니다. 데이터의 최종 대상이 Firestore나 BigQuery와 같은 시간 기반 쿼리를 지원하는 영구 스토리지 서비스라면 타임스탬프를 기준으로 쿼리를 정렬하여 엄격한 순서로 데이터를 확인할 수도 있습니다. 대상이 Dataflow인 경우 레코드 ID를 사용하여 단 한 번 처리를 설정할 수 있습니다.

작업

이 섹션에서는 각 서비스의 프로덕션 워크로드의 작업과 유지보수 오버헤드를 살펴봅니다.

Amazon Kinesis Data Streams

Amazon Kinesis Data Streams 사용자는 수동으로 샤드 크기를 확장 또는 축소해야 하므로 Amazon CloudWatch로 사용량을 모니터링하고 필요에 따라 크기를 수정해야 할 수 있습니다. 이 확장 프로세스를 재샤딩이라 하며 각 샤드별로만 실행할 수 있습니다. 재샤딩은 두 가지 작업을 지원합니다. 즉, 샤드를 샤드 두 개로 분할하거나 샤드 두 개를 단일 샤드로 병합할 수 있습니다. 따라서 N개 샤드의 용량을 2배로 늘리려면 개별 샤드 분할 작업 N개가 필요합니다.

샤드의 고정 특성으로 인해 설계 시 각 샤드 용량을 개별적으로 고려해야 합니다. 예를 들어 단일 샤드에 대한 트래픽을 급증시키는 파티션 키를 선택하면 트래픽 급증 시 샤드의 수집 용량이 과도하게 커질 수 있습니다. 이 문제는 나중에 재샤딩해도 해결되지 않을 수 있습니다. 이와 같은 경우에 문제를 영구적으로 해결하는 유일한 방법은 애플리케이션을 다른 파티션 키로 재설계하는 것입니다.

Kinesis Data Firehose를 사용하면 Kinesis Data Streams의 샤드 관리를 피할 수 있습니다. Kinesis Data Firehose는 스트림 데이터를 Amazon S3 또는 Amazon Redshift로 집계하는 한 가지 특정 사용 사례에서 Kinesis 스트림의 관리, 모니터링, 확장을 자동화합니다. 사용자가 S3 버킷 또는 Redshift 클러스터를 지정하면 Kinesis Firehose가 사용자 대신 스트림을 만들고 관리하면서 지정된 간격으로 지정된 위치에 데이터를 배치합니다.

Amazon Kinesis는 리전 서비스이므로 스트림 범위가 특정 리전으로 설정됩니다. 따라서 수집된 모든 데이터는 스트림이 정의된 리전으로 이동해야 합니다.

Pub/Sub

Pub/Sub에는 프로비저닝이 필요 없으며 샤딩, 복제, 확장이 자동으로 처리됩니다.

또한 Pub/Sub에서 데이터 파티션 나누기가 자동으로 관리되므로 파티션 키를 사용할 필요가 없습니다. 이러한 기능은 관리 오버헤드를 대폭 낮춰주지만 Pub/Sub가 메시지 순서에 대해 보장할 수 있는 부분이 더 적어진다는 점을 의미하기도 합니다.

Pub/Sub는 Google HTTP(S) 부하 분산기를 사용하여 전 세계 모든 Google Cloud 리전에서 데이터를 수집할 수 있습니다. 게시자가 데이터를 Pub/Sub에 게시하면 Google HTTP(S) 부하 분산기가 자동으로 트래픽을 적절한 리전의 Pub/Sub 서버로 전달하므로 지연 시간이 최소화됩니다.

비용

Amazon Kinesis Data Streams의 가격은 샤드 시간, 데이터 볼륨, 데이터 보관 기간을 기준으로 산정됩니다. 기본적으로 데이터는 24시간 동안 보관됩니다. 보관 기간을 늘리면 추가 비용이 발생합니다. Amazon Kinesis Data Streams에서는 프로비저닝 모델을 사용하므로 리소스를 사용하지 않더라도 프로비저닝한 리소스에 대한 비용을 지불해야 합니다.

Amazon Kinesis Data Firehose 가격은 데이터 볼륨을 기준으로 산정됩니다.

Pub/Sub 가격은 데이터 볼륨을 기준으로 산정됩니다. Pub/Sub에는 리소스 프로비저닝이 필요 없으므로 소비한 리소스에 대한 비용만 지불하면 됩니다.

일괄 수집

각각의 클라우드 환경으로 데이터를 일괄 수집하는 데 AWS Snowball과 Google Transfer Appliance가 사용됩니다.

AWS Snowball은 50TB(북미 지역만) 버전과 80TB 버전으로 제공됩니다. Transfer Appliance는 TA100으로 알려진 100TB 버전과 TA480으로 알려진 480TB 버전으로 제공됩니다.

비교 요약

다음 표에서는 AWS Snowball과 Google Transfer Appliance의 기능을 비교합니다.

기능 AWS Snowball Transfer Appliance
단위당 용량 50TB 또는 80TB 100TB 또는 480TB
최대 전송 속도 10Gbps TA100의 경우 20Gbps
TA480의 경우 40Gbps
둘 다 모두 자동 링크 집계 제공
이메일 상태 업데이트 여부 아니요
랙 마운트 가능 여부 아니요 TA100의 경우 예
TA480의 경우 아니요
사용 요금 50TB에 $200
80TB에 $250
TA100에 $300
TA480에 $1,800
일일 요금 10일 후 $15/일 TA100의 경우 10일 후 $30/일
TA480의 경우 25일 후 $90/일
전송 모드 푸시 푸시 또는 풀
객체 스토리지 외부로 데이터 전송 여부 아니요

작업

두 서비스는 비슷한 워크플로(배송 수령, 설정, 전송, 데이터 이전, 반송)를 사용하지만 서비스 설정 및 서비스에 데이터 로드 방식에서 몇 가지 중요한 차이점이 있습니다.

AWS Snowball은 랙 마운트를 지원하지 않습니다. 대신 ATX PC 케이스와 비슷한 독립형 버전입니다. Transfer Appliance TA100 모델은 데이터 센터용으로 2U 랙 마운트형으로 제공됩니다. TA480 모델은 캐스터와 함께 자체 케이스에 제공되며 랙 마운트를 지원하지 않습니다.

AWS Snowball과 Transfer Appliance 간의 가장 큰 차이점은 네트워킹 처리량입니다. 둘 다 RJ-45 연결을 통해 1Gbps 또는 10Gbps를 지원하고 광섬유 연결을 통해 10Gbps를 지원합니다. 하지만 두 Transfer Appliance 모델 모두 적응형 부하 분산 링크 집계 기능과 함께 10Gbps 이더넷 포트 4개를 제공하므로 10Gbps보다 훨씬 높은 멀티 스트림 처리량을 제공할 수 있습니다.

터치식 전자잉크 화면을 사용하여 Snowball을 설정합니다. Transfer Appliance에서는 웹 콘솔을 구성하기 위해 콘솔에 액세스하려면 VGA 디스플레이와 USB 키보드가 필요합니다. 그런 다음에는 웹 브라우저를 사용하여 원격으로 모든 관리 작업을 수행합니다.

데이터를 기기에 가져올 수 있도록 Snowball과 Transfer Appliance 모두 워크스테이션 클라이언트 푸시 모델을 제공합니다. 또한 Snowball에서는 Amazon S3 API push를 제공하고 Transfer Appliance에서는 NFS Pull(NFS 클라이언트 역할) 및 NFS Push(NFS 서버 역할) 전송 모드를 모두 제공합니다.

Snowball과 Transfer Appliance 모두 배송업체를 통해 기기를 반송합니다.

마지막으로 데이터가 객체 스토리지에 로드될 때 AWS 기기와 Google 기기 간에 중요한 차이점 한 가지가 있습니다. Snowball에서는 기기 데이터 복호화가 서비스에 포함됩니다. Transfer Appliance 고객은 rehydrator Compute Engine 가상 어플라이언스를 사용하여 기기 데이터를 복호화해야 합니다. rehydrator 인스턴스에는 일반 Compute Engine VM 가격이 적용됩니다.

객체 스토리지 전송

AWS에서 Google Cloud로 빅데이터 워크로드 이동을 고려하고 있다면 Google의 Storage Transfer Service가 유용할 수 있습니다. Storage Transfer Service를 사용하여 Amazon S3 버킷에서 Google Cloud Storage 버킷으로 데이터를 복사하는 일회성 작업 또는 반복 작업을 만들 수 있습니다. 다른 데이터 소스도 지원됩니다.

변환 및 준비

데이터를 클라우드 환경에 수집한 후 필요에 따라 데이터를 변환, 필터링, 처리할 수 있습니다.

이 문서에서는 이 작업을 수행하는 부분 관리형 ETL, 완전 관리형 ETL, 스트림 변환 등 세 가지 서비스 카테고리를 설명합니다.

부분 관리형 ETL

데이터 변환 작업을 위한 일반적인 접근 방법은 대개 유연하고 확장 가능한 일괄 처리를 제공하는 Apache-Hadoop 기반 도구를 사용하는 것입니다. Google Cloud와 AWS 모두 관리형 Hadoop 서비스를 제공합니다. Google DataprocAmazon Elastic MapReduce(EMR) 모두 자동 프로비저닝 및 구성, 간단한 작업 관리, 정교한 모니터링, 유연한 가격을 제공합니다. 스트림 기반 데이터의 경우 Dataproc 및 Amazon EMR 모두 Apache Spark Streaming을 지원합니다.

또한 Google Cloud는 Hadoop이 아닌 Apache Beam을 기반으로 하는 Dataflow를 제공합니다. Apache Spark Streaming은 스트리밍 데이터를 작은 일괄 작업으로 취급하지만 Dataflow는 기본 스트림 중심의 처리 엔진입니다.

서비스 모델 비교

다음 표에서는 Amazon EMR, Dataproc, Dataflow의 기능을 비교합니다.

기능 Amazon Elastic MapReduce Google Dataproc Google Dataflow
오픈소스 라이브러리 Apache Hadoop 및 Apache Spark Apache Hadoop 및 Apache Spark Apache Beam
확장 수동 또는 자동 수동 또는 자동 수동 또는 자동
배포 단위 클러스터 클러스터 파이프라인
확장 단위 노드(마스터, 코어, 태스크) 노드(마스터 및 작업자) 작업자
작업 단위 단계 작업 작업
프로그래밍 모델 맵리듀스, Apache Hive, Pig, Flink, Spark, Spark SQL, PySpark 맵리듀스, Apache Hive, Pig, Flink, Spark, Spark SQL, PySpark Apache Beam
Dataproc과 Amazon EMR

Dataproc과 Amazon EMR은 유사한 서비스 모델을 사용합니다. 각각은 확장 가능한 데이터 필터링 및 집계 플랫폼이며 Apache Hadoop, Apache Spark, Apache Hive, Apache Pig를 포함한 Apache 빅데이터 도구 및 서비스와 긴밀하게 통합됩니다.

Dataproc과 Amazon EMR 모두에서 다수의 노드로 구성된 클러스터를 만듭니다. 서비스는 마스터 노드 한 개와 여러 개의 워커 노드를 만듭니다. Amazon EMR은 워커 노드를 코어 노드와 작업 노드로 추가 분류합니다.

클러스터가 프로비저닝되면 사용자는 클러스터에서 실행할 애플리케이션(Dataproc 및 Amazon EMR에서 작업이라 함)을 제출합니다. 사용자는 일반적으로 Dataproc에서는 초기화 작업, Amazon EMR에서는 부트스트랩 작업이라 하는 커스텀 Bash 스크립트를 사용하여 애플리케이션 종속 항목을 클러스터 노드에 추가합니다. 애플리케이션은 일반적으로 Amazon S3, Cloud Storage, HDFS와 같은 안정적인 스토리지에서 데이터를 읽은 후 Apache 데이터 처리 도구 또는 서비스를 사용하여 처리합니다. 데이터가 처리된 후에 결과 데이터를 추가로 처리하거나 안정적인 스토리지로 다시 푸시할 수 있습니다.

Dataflow

Dataflow는 Apache Beam 프로그래밍 모델을 사용하여 일괄 처리 및 스트림 처리를 수행합니다. 이 모델은 특히 실시간 데이터 처리 면에서 Amazon EMR과 Dataproc에 사용되는 Apache Spark 모델보다 향상된 유연성과 표현성을 제공합니다.

Dataflow에서는 Dataflow SDK 라이브러리를 통해 병렬 처리 및 집계에 필요한 기본 요소를 제공하여 개요 파이프라인을 지정합니다. 파이프라인을 지정할 때 사용자는 변환 집합을 정의합니다. 그러면 변환 집합은 파이프라인에서 실행될 수 있도록 제출됩니다. 이러한 변환은 Dataflow에서 실행되도록 프로비저닝되고 구성되는 워커 노드 집합으로 매핑됩니다. 일부 노드는 Pub/Sub에서 데이터를 읽는 데 사용될 수 있으며 일부 노드는 다른 다운스트림 변환을 수행할 수 있습니다. 세부 사항은 Dataflow 런타임에 의해 관리됩니다.

Dataflow 모델, SDK, 파이프라인 실행기는 Apache Beam으로 Apache 오픈소스 인큐베이터에 수락되었습니다. 이는 Dataflow 애플리케이션을 Flink 또는 Spark 클러스터 또는 로컬 개발 환경에서도 실행할 수 있다는 의미입니다.

Apache Beam과 Apache Spark 프로그래밍 모델의 자세한 비교는 Dataflow/Beam 및 Spark: 프로그래밍 모델 비교를 참조하세요.

확장

이 섹션에서는 Amazon EMR, Dataproc, Dataflow를 사용하여 확장을 관리하는 방법을 설명합니다.

Dataproc과 Amazon EMR

Amazon EMR과 Dataproc을 사용하면 클러스터가 시작된 후 클러스터의 노드 수를 수동 또는 자동으로 조정할 수 있습니다. 수동 확장의 경우 클러스터의 성능과 사용량을 모니터링해서 확장 작업과 클러스터 크기를 결정하여 클러스터 관리 방법을 지정할 수 있습니다. 두 서비스 모두에서 사용자는 프로비저닝된 노드 수에 따라 비용을 지불합니다.

Dataflow

Dataflow를 사용하면 자동 확장이 기본적으로 사용 설정됩니다. 최대 노드 수를 지정하면 Dataflow 런타임 시스템이 노드를 자동 확장하여 노드 프로비저닝을 적극적으로 관리하고 필요에 따라 파이프라인의 여러 부분에 할당합니다. 확장을 수동으로 관리할 수도 있습니다.

비용

이 섹션에서는 Amazon EMR, Dataproc, Dataflow의 비용 평가 방법을 설명합니다.

Amazon EMR과 Dataproc

Amazon EMR과 Dataproc 모두 주문형 가격 책정 모델과 단기 및 장기 사용을 위한 할인을 지원합니다. 두 서비스 모두 가격은 초 단위로 산정됩니다. 노드 비용을 줄이기 위해 Amazon EMR 사용자는 예약 인스턴스를 사전에 구매할 수 있습니다. Dataproc은 지속 사용 할인을 자동으로 제공합니다.

또한 두 서비스 모두 잔여 컴퓨팅 용량을 할인된 가격으로 구매할 수 있는 옵션을 제공합니다. Amazon EMR은 Amazon EC2 Spot 인스턴스를 사용한 노드 프로비저닝을 지원합니다. 이 때 사용되지 않은 용량은 단기 증분으로 사용자에게 경매로 제공됩니다. 이러한 노드는 EC2에 의해 회수될 수 있지만 클러스터는 노드가 추가 또는 제거됨에 따라 계속해서 처리를 수행합니다. Dataproc은 이와 비슷하게 언제든지 회수할 수 있는 선점형 VM을 지원합니다. 선점형 VM은 시장을 통해 경매로 판매되지 않습니다. 대신 각 Compute Engine 머신 유형에 시간별 고정 할인을 제공합니다.

Google Cloud와 AWS를 포함한 일반적인 클라우드 환경용 관리형 Hadoop의 가격 책정에 대한 상세 비교는 클라우드 가격 책정 이해: 빅데이터 처리 엔진을 참조하세요.

Dataflow

Dataflow 가격은 Dataflow 작업자 유형에 따라 시간별로 산정됩니다. 자세한 내용은 Dataflow 가격 책정을 참조하세요.

완전 관리형 ETL

AWS와 Google Cloud 모두 작업의 상당 부분을 자동화하고 변환 파이프라인을 생성하여 변환 구성 작업을 줄여주는 서비스를 제공합니다.

AWS에서는 데이터 카탈로그 및 데이터 준비 작업이 단일 서비스로 결합된 완전 관리형 AWS 서비스인 AWS Glue를 사용할 수 있습니다. AWS Glue는 사용자 정의 크롤러를 사용하여 다양한 데이터 소스에서 AWS Glue Data Catalog를 자동으로 채웁니다. Data Catalog가 채워지면 AWS Glue 작업을 정의할 수 있습니다. 작업을 만들면 Apache Spark와 호환되는 Python 또는 Scala 스크립트가 생성되어 맞춤설정할 수 있습니다. AWS Glue 작업은 시간 일정에 따라 실행하거나 이벤트에 따라 시작할 수 있습니다.

Google Dataprep은 Trifacta에서 운영되며 Cloud 프로젝트 및 데이터와 손쉽게 통합되는 완전 관리형 서비스입니다. Dataprep을 사용하여 추가 분석을 위해 확인한 데이터를 탐색하고 삭제할 수 있습니다. 데이터는 구조화되거나 구조화되지 않을 수 있고 Google Cloud Storage, BigQuery 또는 파일 업로드에서 발생할 수 있습니다. 작업은 흐름을 중심으로 구성되며, 흐름은 소스 데이터 세트, 변환, 준비된 데이터 세트 한 개 이상을 나타냅니다. Dataprep에는 정보를 검색하고 변환 흐름을 계획할 수 있는 GUI가 제공됩니다. 이러한 변환은 Wrangle 도메인 관련 언어로 지정되며 GUI를 통해 수동으로 지정할 수도 있습니다. 흐름은 완전 관리형 Dataflow에서 실행되어 변환을 수행합니다.

스트림 변환

AWS와 Google Cloud 모두에는 데이터 스트림을 변환하는 데 사용할 수 있는 몇 가지 서비스가 있습니다.

Dataproc과 Amazon EMR

Amazon EMR은 데이터 수집 방법으로 Amazon Kinesis Data Streams를 지원하여 기본적으로 스트리밍 데이터 모델을 구현합니다. 이 모델에서 애플리케이션은 일부 시간 값에 사용 가능한 새 데이터가 없을 때까지 스트림에 저장된 사용 가능한 데이터를 읽습니다. 모든 샤드가 분명해지면 작업 축소 단계가 시작되고 데이터가 집계됩니다. Amazon EMR은 Apache Spark Streaming 기본 구현을 통해 Apache Kafka와 같은 타사 서비스의 스트리밍도 지원합니다.

Dataproc은 Pub/Sub에서 직접 스트리밍 데이터를 읽을 수 없지만 모든 Dataproc 클러스터에는 Apache Spark가 사전 설치되어 제공됩니다. 따라서 Dataproc을 사용하면 Apache Kafka의 스트리밍 데이터를 읽을 수 있습니다. 또한 Dataflow를 사용하여 Pub/Sub에서 스트리밍 데이터를 읽고 처리할 수 있습니다.

Google Dataflow와 Amazon Kinesis Data Firehose

Dataflow는 앞에서 설명한 것처럼 일괄 처리 외에 스트림 처리도 지원합니다. 스트리밍 엔진은 배치와 마찬가지로 Apache Beam을 실행하며 코드를 변경하지 않고도 배치 소스와 스트림 소스 모두에 변환을 적용할 수 있습니다. Pub/Sub는 스트리밍 모드에서 Dataflow와 함께 사용되는 유일한 이벤트 소스이며 메시지를 최대 10MB까지 처리할 수 있습니다. 일괄 변환과 마찬가지로 Dataflow 스트리밍 변환은 완전 관리형이고 자동 확장되며, 변환 파이프라인의 구성요소에서 독립적으로 확장이 수행됩니다.

Amazon Kinesis Data Firehose는 AWS Lambda 함수를 스트림에 연결하여 스트림 변환을 수행할 수 있습니다. 이 함수는 입력을 최대 6MB까지 처리할 수 있으며 데이터를 최대 6MB까지 반환할 수 있습니다. Google Cloud에서 Pub/Sub 및 Cloud Functions를 사용하여 이 방식을 미러링할 수 있습니다.

웨어하우징 및 분석

데이터를 수집 및 변환한 후 데이터 분석을 수행하고 데이터에서 시각화를 만들 수 있습니다. 일반적으로 분석 준비가 완료된 데이터는 다음 두 위치 중 하나에 저장됩니다.

  • Amazon S3 또는 Google Cloud Storage와 같은 객체 스토리지 서비스
  • Amazon Redshift 또는 Google BigQuery와 같은 관리형 데이터 웨어하우스

관리형 데이터 웨어하우스

이 섹션에서는 Amazon Redshift와 Google BigQuery의 네이티브 스토리지를 집중적으로 설명합니다.

서비스 모델 비교

다음 표에서는 Amazon Redshift와 Google BigQuery의 기능을 비교합니다.

기능 Amazon Redshift Google BigQuery
배포 단위 클러스터 해당 사항 없음(완전 관리형)
프로비저닝 단위 노드 해당 사항 없음(완전 관리형)
노드 스토리지 유형 HDD/SSD 해당 사항 없음(완전 관리형)
컴퓨팅 확장 수동, 최대 128개 노드 자동 조정, 무제한
쿼리 확장 모든 사용자 정의 큐에서 동시 쿼리 최대 50개 동시 쿼리 최대 1,000개
테이블 확장 대형 노드 유형의 경우 최대 20,000개 테이블 무제한. 데이터세트당 테이블이 50,000개 미만일 때 성능 최적화 무제한 데이터세트.
백업 관리 스냅샷 해당 사항 없음(완전 관리형)
배포 지역 영역 리전
가격 책정 모델 시간별 저장소 및 쿼리 볼륨별
쿼리 언어 PostgreSQL 호환 기존 BigQuery SQL 또는 표준 SQL
머신러닝 기본 제공 여부 아니요
Amazon Redshift

Amazon Redshift는 프로비저닝된 노드 클러스터에 걸쳐 대규모 병렬 처리 아키텍처를 사용하여 고성능 SQL을 실행합니다. Amazon Redshift를 사용하는 경우 데이터는 클러스터 노드 간에 자동으로 복제되는 열 형식 데이터베이스에 저장됩니다. 데이터는 클러스터에 상주하므로 데이터를 보존하려면 클러스터가 계속 실행되어야 합니다. 하지만 Amazon Redshift에서 Amazon S3로 데이터를 내보낸 후 Amazon Redshift 클러스터로 새로고치면 나중에 쿼리할 수 있습니다. 또는 Amazon Redshift의 확장 프로그램인 Spectrum을 사용하여 Amazon S3에서 지원되는 형식으로 저장된 데이터를 직접 쿼리할 수도 있습니다.

위에 언급했듯이 Amazon Redshift에서는 프로비저닝된 모델을 사용합니다. 이 모델에서는 인스턴스 유형을 선택한 후 필요에 따라 특정 개수의 노드를 프로비저닝합니다. 프로비저닝이 완료되면 클러스터에 연결한 후 원하는 PostgreSQL 호환 커넥터를 사용하여 데이터를 로드하고 쿼리할 수 있습니다.

Amazon Redshift는 부분 관리형 서비스입니다. 사용량이 적은 기간의 비용을 줄이거나 사용량이 많은 기간의 리소스를 늘리는 등과 같이 클러스터를 확대 또는 축소하려면 수동으로 이를 수행해야 합니다. 또한 Amazon Redshift에서는 배포 키와 정렬 키를 정의 및 관리해야 하며 데이터 삭제와 단편화 삭제 프로세스를 수동으로 수행해야 합니다.

Google BigQuery

BigQuery는 완전 관리형입니다. 리소스를 프로비저닝할 필요가 없으며, 데이터를 BigQuery로 푸시한 후 바로 쿼리할 수 있습니다. BigQuery는 필수 리소스를 관리하고 적절하게 자동으로 확장합니다. 또한 BigQuery는 통합 쿼리를 지원합니다. 여기에는 Cloud Storage 또는 Google 드라이브에 오픈소스 형식으로 저장된 데이터와 Cloud Bigtable에 기본적으로 저장된 데이터가 포함됩니다.

BigQuery는 Google이 내부에서 사용하는 서비스와 동일한 강력한 전역 규모 서비스를 사용합니다.

  • Google의 최신 세대 분산형 파일 시스템인 Colossus를 사용하여 데이터를 저장, 암호화, 복제합니다.
  • Google의 대규모 클러스터 관리 시스템인 Borg를 사용하여 태스크를 처리합니다.
  • Google의 내부 쿼리 엔진인 Dremel을 사용하여 쿼리를 실행합니다.

자세한 내용은 Google Cloud 블로그의 BigQuery Under the Hood 게시물을 참조하세요.

BigQuery 테이블에서는 추가만 가능하며 실수를 수정하기 위한 삭제가 제한적으로 지원됩니다. 사용자는 대화형 쿼리를 수행할 수 있으며 일괄 쿼리 작업을 만들고 실행할 수 있습니다. BigQuery는 다음과 같은 두 가지 쿼리 언어를 지원합니다.

  • Legacy SQL: BigQuery 전용 SQL 언어
  • 표준 SQL: SQL 2011 표준을 준수하며 중첩 및 반복 데이터를 쿼리할 수 있는 확장 프로그램을 포함합니다.

또한 BigQuery는 수집, 분석, 시각화, 개발을 위해 다양한 타사 도구, 커넥터, 파트너 서비스와 통합됩니다.

머신러닝

BigQuery는 머신러닝을 기본적으로 지원합니다. BigQuery ML에서는 일반적인 비즈니스 질문을 해결하는 다양한 모델을 제공합니다. 판매 예측용 선형 회귀, 분류용 바이너리 로지스틱 회귀(예: 고객의 구매 여부) 등이 그 예입니다. BigQuery 데이터세트 여러 개를 모델 학습 및 예측 모두에 사용할 수 있습니다.

확장

Amazon Redshift는 단일 노드에서 다양한 유형의 노드(최대 32개 또는 128개까지)로 확장할 수 있습니다. Redshift는 Dense Storage 노드를 통해 데이터를 최대 2PB까지 저장할 수 있는 용량(복제 데이터 포함)을 제공합니다. Amazon Redshift의 수집과 쿼리 메커니즘은 동일한 리소스 풀을 사용하므로 대량 데이터를 로드하면 쿼리 성능이 저하될 수 있습니다.

Amazon Redshift Spectrum은 이 용량을 확장해줍니다. 하지만 Redshift Spectrum을 사용할 경우 이 데이터에 쿼리를 실행하려면 Amazon Redshift 클러스터가 실행 중이어야 합니다. 쿼리는 두 레이어(Amazon Redshift와 Redshift Spectrum) 사이에서 처리되며, 각 레이어를 가장 효율적으로 사용할 수 있도록 쿼리를 구성해야 합니다.

반면 BigQuery에는 실질적으로 저장된 데이터세트의 크기를 제한하지 않습니다. 수집 리소스는 신속하게 확장되며 수집 자체도 매우 빠릅니다. BigQuery API를 사용하면 초당 수백만 개의 행을 BigQuery로 수집할 수 있습니다. 또한 수집 리소스와 쿼리 리소스가 분리되어 있으므로 수집 부하로 인해 쿼리 부하 성능이 저하되지 않습니다. BigQuery는 Google Cloud Storage에 저장된 데이터 쿼리도 수행할 수 있습니다. 이 경우 데이터가 다른 테이블로 표시될 뿐이므로 쿼리를 달리 작성하지 않고도 통합 쿼리가 가능합니다.

작업

이 섹션에서는 Amazon Redshift와 Google BigQuery를 사용할 경우의 운영 고려사항을 비교합니다.

Amazon Redshift

Amazon Redshift는 부분 관리형으로, 데이터 웨어하우스를 실행하는 데 필요한 운영 세부 사항의 상당 부분이 자동으로 처리됩니다. 이러한 세부 사항에는 데이터 백업, 데이터 복제, 장애 관리, 소프트웨어 배포와 구성이 포함됩니다. 하지만 성능 관리, 확장, 동시 실행 등 몇 가지 운영 세부 사항은 여전히 개발자의 몫입니다.

성능을 높이려면 테이블을 만들 때 정적 배포 키를 정의해야 합니다. 이러한 배포 키는 쿼리를 병렬로 수행할 수 있도록 시스템에서 여러 노드에 데이터를 샤딩하는 데 사용됩니다. 배포 키는 쿼리 성능에 큰 영향을 미치므로 사용자는 신중하게 이러한 키를 선택해야 합니다. 배포 키를 정의한 후에는 키를 변경할 수 없습니다. 다른 키를 사용하려면 새 키를 사용하여 새 테이블을 만들고 이전 테이블의 데이터를 복사해야 합니다.

또한 Amazon에서는 개발자가 일관된 쿼리 성능을 유지할 수 있도록 정기적인 유지보수를 수행할 것을 권장합니다. 업데이트 및 삭제를 통해 디스크의 데이터가 자동으로 압축되지 않으므로 결과적으로 성능 병목현상이 발생할 수 있습니다. 자세한 내용은 Amazon Redshift 문서의 테이블 청소를 참조하세요.

Amazon Redshift에서는 최종 사용자와 애플리케이션을 신중하게 관리해야 합니다. 예를 들어 사용자는 수행되는 동시 실행 쿼리 수를 세밀하게 조정해야 합니다. 기본적으로 Amazon Redshift는 동시 실행 쿼리를 최대 5개까지 수행합니다. 동시 쿼리 수를 최대 50개까지 늘릴 수 있습니다. 그러나 리소스가 사전에 프로비저닝되므로 이 한도를 늘리면 성능과 처리량이 영향을 받을 수 있습니다. 자세한 내용은 Amazon Redshift 문서에서 수동 WLM 구현동시 실행 수준 섹션을 참조하세요.

전체적인 데이터 크기, 쿼리 성능, 동시 사용자 수를 지원하도록 클러스터 크기를 조정해야 합니다. 클러스터를 확장할 수는 있지만 프로비저닝 모델에서는 사용량에 상관없이 프로비저닝하는 만큼 비용을 지불하게 됩니다.

마지막으로 Amazon Redshift 클러스터는 기본적으로 단일 영역으로 제한됩니다. 가용성이 높은 멀티 리전 Amazon Redshift 아키텍처를 만들려면 다른 영역에 추가 클러스터를 만든 후 클러스터 간 일관성이 제공되도록 메커니즘을 빌드해야 합니다. 자세한 내용은 Amazon 빅데이터 블로그의 Building Multi-AZ or Multi-Region Amazon Redshift Clusters 게시물을 참조하세요.

Amazon Redshift 할당량 및 제한에 대한 자세한 내용은 Amazon Redshift의 제한을 참조하세요.

BigQuery

BigQuery는 완전 관리형으로, 개발자 입장에서 운영상 부담이 거의 또는 전혀 없습니다.

  • BigQuery는 샤딩을 자동으로 처리합니다. 배포 키를 만들고 유지보수할 필요가 없습니다.
  • BigQuery는 프로비저닝되는 서비스가 아닌 주문형 서비스입니다. 병목 현상을 유발할 수 있는 언더프로비저닝 또는 불필요한 비용을 발생시킬 수 있는 오버프로비저닝에 대해 걱정할 필요가 없습니다.
  • BigQuery는 전역 관리형 데이터 복제를 제공합니다. 배포를 여러 개 설정하고 관리할 필요가 없습니다.
  • BigQuery는 성능 또는 처리량에 영향을 주지 않고 동시 실행 대화형 쿼리를 최대 50개까지 지원합니다.

BigQuery의 할당량 및 제한에 대한 자세한 내용은 BigQuery 문서의 할당량 정책 페이지를 참조하세요.

비용

Amazon Redshift에서는 주문형 가격과 예약 인스턴스 가격 등 두 가지 유형을 제공합니다. 가격은 프로비저닝된 인스턴스 수와 유형에 따라 산정됩니다. 예약 인스턴스를 미리 구매하면 할인을 적용받을 수 있습니다. Amazon은 1년 및 3년 예약 기간을 제공합니다. 자세한 내용은 Amazon Redshift 가격 책정 페이지를 참조하세요.

BigQuery에서는 사용량만큼 요금이 청구됩니다. 가격은 스토리지 크기, 쿼리 계산 비용, 스트리밍 삽입에 따라 산정됩니다. 테이블이 90일 연속 업데이트되지 않으면 데이터 스토리지 가격이 절반으로 인하됩니다. 쿼리는 처리된 데이터의 테라바이트 단위로 청구됩니다. BigQuery는 주문형 요금과 정액제로 가격이 책정되므로 예측 가능한 워크로드의 경우 비용을 크게 절약할 수 있습니다. BigQuery에서는 스토리지를 최대 20GB까지, 쿼리 읽기를 월간 1TB까지 무료로 사용할 수 있습니다. 자세한 내용은 BigQuery 가격 책정 페이지를 참조하세요.

객체 스토리지 웨어하우스

객체 저장소는 또 다른 일반 빅데이터 스토리지 메커니즘입니다. Amazon S3와 Google Cloud Storage는 서로 비슷한 완전 관리형 객체 스토리지 서비스입니다. 두 서비스에 대한 자세한 내용은 스토리지 비교 문서의 분산형 객체 스토리지 섹션을 참조하세요.

자주 액세스하지 않는 대량 데이터의 경우 Amazon Glacier 스토리지와 비슷한 Google Cloud Storage Coldline을 선택하는 것이 좋습니다. 두 서비스에 대한 자세한 내용은 AWS 전문가를 위한 Google Cloud: Storage를 참조하세요.

객체 스토리지 분석

이 섹션에서는 Amazon Athena와 Google BigQuery의 객체 스토리지 호환성을 집중적으로 설명합니다.

서비스 모델

AWS Athena는 서버리스 객체 스토리지 분석 서비스입니다. Amazon S3에서 스키마가 정의된 데이터에 SQL 쿼리를 실행할 수 있습니다. BigQuery 통합 쿼리는 이와 비슷한 서비스로, Google Cloud Storage, Google 드라이브, Cloud Bigtable 데이터를 지원합니다.

Cloud Storage의 BigQuery와 Athena 모두 자동 확장이 포함된 완전 관리형으로, 서비스 모델이 서로 비슷합니다.

확장

데이터 확장면에서 Amazon S3와 Cloud Storage 모두 엑사바이트급 규모의 스토리지를 제공합니다. Amazon S3은 버킷을 계정당 100개로 제한합니다. Cloud Storage는 버킷 생성 속도를 2초마다 버킷 1개로 제한하지만 프로젝트, 폴더 또는 조직의 버킷 수에는 제한이 없습니다.

쿼리 확장면에서 Athena 쿼리는 30분 후에 타임아웃되지만 BigQuery 쿼리는 6시간 후에 타임아웃됩니다. Athena에는 한 번에 DDL 쿼리와 DML 쿼리를 각각 최대 20개까지 처리할 수 있는 소프트 한도가 있습니다. BigQuery는 성능 또는 처리량에 영향을 주지 않고 동시 실행 대화형 쿼리를 최대 50개까지 지원합니다. 테스트 실행 쿼리는 이 한도에 계산되지 않습니다. 이 한도는 프로젝트 수준에서 발생할 수 있습니다.

Athena 쿼리 문자열은 262,144바이트로 제한됩니다. BigQuery의 legacy SQL 쿼리는 256KB 미확인으로 제한되지만 표준 SQL 쿼리는 1MB 미확인으로 제한됩니다. 확인이 끝나면 쿼리에서 참조하는 뷰 및 와일드 카드 테이블이 전체 쿼리 크기로 확장되어 두 BigQuery SQL 언어 한도가 12MB가 됩니다.

작업

Athena와 BigQuery 모두 완전 관리형으로, 개발자 입장에서 운영상 부담이 거의 또는 전혀 없습니다.

비용

Google Cloud Storage와 Amazon S3의 스토리지 비용은 비슷하며, 전송 및 스토리지 비용이 비용 대부분을 차지합니다. 안정적인 비용이 요구되는 Cloud Storage 고객은 스토리지 그로스 플랜에 등록하면 매월 동일한 금액만 지불하면 됩니다.

AWS Athena와 BigQuery(주문형 가격) 모두 쿼리 비용으로 테라바이트당 $5가 청구됩니다. 하지만 테라바이트 측정 방식이 두 서비스 간에 서로 다릅니다. Athena에서는 Amazon S3에서 읽은 바이트 수에 대해 요금이 청구되므로 압축된 데이터의 쿼리 비용이 압축되지 않은 데이터의 쿼리 비용보다 저렴합니다. BigQuery에서는 처리된 바이트 수에 대해 비용이 청구되므로 데이터 저장 위치나 방법에 관계없이 비용이 동일합니다.

두 서비스 모두 쿼리당 최소 10MB의 요금이 청구됩니다. 두 서비스 모두 실패한 쿼리에는 서비스 요금이 청구되지 않지만 취소된 쿼리에 수행된 작업에는 요금이 청구됩니다.

Athena에는 무료 등급이 없습니다. BigQuery에서는 계정 기간 동안 매월 첫 1TB가 무료로 제공됩니다.

데이터 시각화

AWS QuickSight를 사용할 경우 Google 데이터 스튜디오에서 비슷한 기능을 찾을 수 있습니다. 가장 큰 차이점은 가격입니다. 데이터 스튜디오는 무료지만 QuickSight는 세션당 요금이 청구됩니다. 또한 데이터 스튜디오는 Google Workspace와 통합되어 문서, 스프레드시트, 프레젠테이션과 마찬가지로 조직 내 공유가 쉬워집니다.

또한 보다 강력한 관리나 과학 연구를 위해 Google은 Jupyter 메모장을 사용하여 BigQuery와 통합되고 설정이 필요 없는 무료 서비스인 Colaboratory를 제공합니다.