Google Cloud Platform - Get Certified Program (Storage in the Cloud)

# Cloud Storage

클라우드 스토리지는 내구성과 높은 가용성을 제공하는 오브젝트 스토리지 서비스이다. 오브젝트 스토리지란, 데이터를 오브젝트 단위로 저장하는 컴퓨터 데이터 저장 아키텍처를 말한다. 이는 데이터를 파일 / 폴더 계층 구조(파일 스토리지)나 블록 단위(블록 스토리지)로 관리하는 방식과는 다르다.

오브젝트는 패키지 형식으로 저장되는데, 해당 패키지에는 아래와 같은 정보들이 포함된다.

실제 데이터(바이너리 형태)
메타데이터 (생성 날짜, 작성자, 리소스 유형, 권한 등)
전역 고유 식별자 (일반적으로 URL 형식의 키 형태로 제공)

오브젝트 스토리지에는 주로 동영상, 이미지, 오디오 녹음 유형의 파일들이 저장된다. 사용자가 원하는 만큼의 데이터를 저장하고 필요한 만큼 데이터를 조회할 수 있다.

클라우드 스토리지는 완전 관리형이고 확장 가능한 서비스이다. 주된 용도는 바이너리 대형 객체(BLOB, Binary Large Object) 저장이 필요한 경우이다. 클라우드 스토리지는 아래와 같이 다양한 용도로 활용될 수 있다.

웹사이트 컨텐츠 제공
아카이빙 및 재해복구용 데이터 저장
대용량 데이터 객체를 사용자가 직접 다운로드하는 방식으로 배포

클라우드 스토리지 파일들은 버킷 단위로 구성된다. 버킷 생성 시에는 전 세계에서 고유한 이름과 저장될 특정 지리적 위치를 지정해야 한다. 버킷의 이상적인 위치는 지연을 최소화할 수 있는 위치이다.

클라우드 스토리지에서 제공하는 저장 객체는(Storage Object) 불변이다. 이는 객체를 직접 수정하는 것이 아니라 변경이 발생할 때마다 새로운 버전이 생성된다는 것을 의미한다.

관리자는 새로운 버전이 **기존 버전을 완전히 덮어쓰게(Overwrite)**할지, 버킷 내 버전관리 기능을 활성화하여 특정 객체에 대한 모든 변경 사항을 추적할지 선택할 수 있다.

버저닝 옵션을 선택하면 버킷 내 모든 객체에 대한 수정 및 삭제 작업의 상세 변경 이력을 유지하게 된다. 버저닝 활성화 시 아래와 같은 작업들이 가능하다.

객체의 보관된 버전 목록 확인
- 버저닝 활성화 시 객체를 수정하거나 삭제하면 해당 객체는 그냥 삭제되지 않고 Archived 상태로 변경된다.
객체를 이전 상태로 복원
특정 객체 버전을 영구적으로 삭제

클라우드 스토리지는 객체에 대한 수명 관리가 가능하며 특정 날짜, 생성일 기준 지난 날짜, 최근 N개 버전만 유지하는 등 다양한 정책을 설정할 수 있다.

많은 경우 개인 식별정보가 데이터 객체에 포함될 수 있다. 따라서 저장된 데이터에 대한 접근을 제어하는 것은 보안 및 프라이버시 유지에 필수적이다. IAM과 액세스 제어 목록(ACL, Access Control List)를 사용하면 보안에 있어 베스트 프랙티스를 준수할 수 있다. (사용자는 필요한 권한까지만 부여되고 그 이상은 부여되지 않음)

객체 및 버킷에 대한 사용자 접근을 위해서는 아래 몇 가지 방법을 사용한다.

대부분 IAM으로 충분 (IAM 역할은 프로젝트 -> 버킷 -> 객체로 상속)
세밀한 제어를 위해 ACL 생성. ACL은 아래 두 가지 정보로 구성
- 범위(Scope): 해당 객체 또는 버킷에 누가 액세스 가능한지 정의 (특정 사용자 or 사용자 그룹)
- 권한(Permission): 어떤 행동을 수행할 수 있는지 정의 (읽기, 쓰기)

클라우드 스토리지는 파일 시스템은 아니지만 버킷을 일반적인 리눅스 / MacOS 디렉터리처럼 사용할 수 있도록 버킷을 마운트해주는 서드파티 도구를 통해 파일 시스템처럼 접근이 가능하다.

gcsfuse: 버킷을 리눅스 / MacOS 디렉터리로 마운트
rclone: 다양한 클라우드 스토리지를 마운트 / 동기화 / 백업할 수 있는 도구
Cloud Storage FUSE: 구글 공식 관리버전 마운트 도구

클라우드 스토리지에는 네 가지 주요 스토리지 클래스가 존재한다. 저장 데이터는 소속 클래스에 따라 다르게 관리 및 과금된다.

Standard Storage
- 자주(Frequently) 액세스되는 핫 데이터에 적합
- 짧은 기간 동안만 저장되는 데이터에도 적합
Nearline Storage
- 가끔(Infrequently) 액세스되는 데이터에 적합 (ex - 월 1회)
- 데이터 백업, 장기 보관 멀티미디어 콘텐츠(Long-tail Multimedia Content), 데이터 아카이빙 등
Coldline Storage
- 가끔 액세스되는 데이터용 / 저렴한 옵션
- Nearline보다 더 적은 빈도로 사용되는 데이터에 적합 (평균 90일에 한 번 이하로 데이터 읽기 및 수정)
Archive Storage
- 가장 저렴한 비용으로 제공
- 데이터 아카이빙 / 온라인 백업 / 재해 복구 용도
- 연 1회 이하로 데이터 접근 계획 시 적합
- 데이터 접근 및 작업 비용이 높고 365일 최소 저장 기간이 적용

더 자주 접근 가능한 저장소일수록 작업비용이 커진다. 저장비용과 작업비용이 반비례한다고 보면 된다.

위의 스토리지들은 공통으로 적용되는 여러 특징들이 있다.

무제한 저장 용량 제공 (최소 객체 크기 제한 X)
전 세계 어디서든 접근 가능, 다양한 위치에서 서비스 제공
낮은 지연 시간 / 높은 내구성
보안 / 도구 / API 사용 경험이 일관적 (스토리지 클래스 여부에 상관없음)
다중리전 / 듀얼리전에 저장하는 경우 지리적 중복성 제공 (데이터 중복 저장)
- 대규모 재해 / 자연재해 대비
- 트래픽 로드밸런싱 제공

클라우드 스토리지는 Autoclass 기능도 제공한다. 각 객체 접근패턴에 따라 적절한 스토리지 클래스로 자동 전환해준다.

자주 접근되지 않은 데이터는 더 저렴한 스토리지 클래스로 이동시켜 스토리지 비용 절감
자주 접근되는 데이터는 standard storage로 이동시켜 접근 및 작업 성능 최적화

my-bucket (하나의 버킷)

├── photo1.jpg → Standard
├── photo2.jpg → Nearline
├── video1.mp4 → Coldline
├── backup.tar.gz → Archive

버킷 스토리지 클래스를 Autoclass로 지정하는 경우 각 객체별로 스토리지 클래스가 위와 같이 달라질 수 있다. 버킷 기본 옵션을 Nearline이라고 지정하면 기본적으로 객체 저장 시에는 Nearline으로 저장되지만, 저장시 명시적으로 클래스를 다르게 오버라이딩 가능하다.

클라우드 스토리지는 아래와 같은 과금 및 보안구조를 갖는다.

No minimum fee - 사전 용량 예약 불필요
- 클라우드 스토리지는 선불 구조가 아님
- 실제로 저장한 데이터 용량 기준으로 과금 (월단위 청구, 초단위 사용량 기록)
서버 측 암호화
- 클라우드 스토리지에 저장되는 모든 데이터는 자동으로 암호화된다. (구글 자체 제공)
- 추가 비용 없음
HTTPS/TLS를 통한 전송 중 암호화
- 사용자 기기에서 구글 Cloud로 데이터 전송하는 경우에도 TLS 기반 HTTPS 연결을 사용한다.

스토리지에 데이터를 전송하기 위해서는 Google Cloud SDK의 gcloud storage 명령어를 사용하거나 Google Cloud 콘솔을 통해 웹 브라우저에서 드래그 앤 드롭 기능을 사용하면 데이터를 쉽게 옮길 수 있다.

만약 테라바이트 / 페타바이트 규모의 데이터를 업로드 해야 하는 경우 Storage Transfer Service를 사용하면 된다. 해당 서비스는 대량 온라인 데이터를 스토리지로 빠르고 비용 효율적으로 가져올 수 있는 서비스이다.

아래와 같은 경우에 배치 전송을 예약하고 관리할 수 있도록 지원한다.

다른 클라우드 업체에서 클라우드 스토리지로 데이터 이전
다른 클라우드 스토리지 리전 간 데이터 이전
HTTP(S) 엔드포인트에서 클라우드 스토리지로 데이터 이전

또, Transfer Applicance라는 옵션도 존재하는데, 이는 구글 클라우드로부터 임대할 수 있는 고용량의 랙 장착형 스토리지 서버이다. 해당 장비를 네트워크에 연결한 뒤 데이터를 로컬로 복사하여 저장한다. 해당 장비를 구글이 업로드 시설에 직접 배송하면 구글 스토리지로 데이터가 업로드된다.

단일 Transfer Appliance한 대로 최대 1페타바이트 데이터 전송이 가능하다.

클라우드 스토리지는 다른 서비스들과 긴밀하게 통합되어 있기 때문에 데이터를 스토리지로 가져오는 다른 방법들이 많다.

빅쿼리 및 Cloud SQL로부터 테이블을 가져오거나 내보내기
App Engine 로그 / Firestore 백업 / App Engine 어플리케이션에서 사용하는 객체 저장
Compute Engine 인스턴스 시작 스크립트 / Compute Engine 이미지 / Compute Engine 어플리케이션에서 사용하는 객체 저장

# Cloud SQL

Cloud SQL은 MySQL, PostgreSQL, SQL Server를 포함한 완전 관리형 (Fully Managed) 관계형 데이터베이스를 서비스 형태로 제공한다. 이 서비스는 반복적이지만 필수적이고 많은 시간이 소요되는 작업들을 구글이 대신 관리하도록 설게되었다.

Patch / Update 적용
백업관리
DB 복제 구성

클라우드 SQL은 아래와 같은 장점들을 갖는다.

별도 소프트웨어 설치 및 유지 관리가 필요없음
최대 128 프로세스 코어 / 864GB RAM / 64TB까지 스케일업 가능
자동 복제 시나리오 제공
- 클라우드 SQL 기본(Primary) 인스턴스로부터 복제
- 외부 기본(Primary) 인스턴스로부터 복제
  - Primary 인스턴스는 유일한 데이터 원본 역할을 하는 인스턴스를 말한다.
- 외부 MySQL 인스턴스로부터 복제
관리형 백업 지원
- 백업데이터의 안전한 보관 / 필요 시 복원
- 인스턴스 비용 자체에 최대 7개 백업 포함
구글 내부 네트워크 / DB 테이블 / 임시 파일 / 백업 데이터는 모두 암호화
각 DB 인스턴스에 네트워크 방화벽 포함 (접근 제어)

Cloud SQL는 다른 서비스에서도 접근이 가능하다.

App Engine과 함께 사용 가능
파이썬의 MySQLdb같은 표준 DB드라이버를 사용하면 연결 가능 => 애플리케이션 데이터베이스로 쉽게 활용이 가능하다.

표준 DB 드라이버란?

애플리케이션(코드)이 데이터베이스와 통신할 수 있도록 도와주는 소프트웨어 구성 요소이다. 개발자가 작성한 코드(SQL 쿼리 등)을 네트워크 프로토콜로 변환하여 DB서버에 전달하고, DB 서버 응답을 받아 다시 애플리케이션에서 사용할 수 있는 형태로 바꿔줌.

DBMS(데이터베이스 관리 시스템)와 통신하기 위해 업계 표준으로 사용되는 공식 드라이버

Compute Engine 인스턴스는 Cloud SQL 인스턴스에 접근할 수 있도록 권한부여가 가능하다. 또한 Cloud SQL 인스턴스를 가상머신과 같은 Zone에 구성하는 것도 가능하다.

Cloud SQL은 SQL Workbench, Toad와 같은 외부 애플리케이션과도 호환된다.

# Spanner

Spanner는 완전 관리형 관계형 데이터베이스 서비스이다. 수평 확장이 가능하고 강력한 일관성을 제공하며 SQL로 쿼리가 가능하다. 강력한 일관성이란 다중 노드 리전 환경에서도 최신 데이터 상태가 모든 노드에 동기화 되어 제공됨을 말한다.

Spanner는 아래 요구사항을 필요로 하는 어플리케이션에 적합하다.

Join및 보조인덱스를 지원하는 SQL 기반 RDBMS가 필요한 경우
내장된 고가용성이 필요한 경우 (장애가 발생해도 지속 가능한 서비스)
전역적으로 강력한 일관성이 필요한 경우
초당 수만건 이상의 높은 I/O 작업 처리량이 필요한 경우

기본(Primary) 인덱스 vs 보조(Secondary) 인덱스

우선 인덱스란, DB에서 조회를 빠르게 하기 위한 데이터 구조이다.

기본 인덱스(Primary Index or Clustered Index)
- 테이블의 Primary Key 대해 자동으로 생성
- 데이터 자체가 Primary Key 순서대로 정렬되어 저장
- Primary Key 기준으로 검색할 때 가장 빠름
보조 인덱스(Secondary Index or Non-Clustered Index)
- Primary Key가 아닌 다른 컬럼에 대해 생성한 인덱스
- 해당 컬럼으로 빠르게 검색하기 위한 추가적인 인덱스 구조가 별도로 만들어짐

# Firestore

파이어스토어는 유연하고, 수평 확장이 가능하고, NoSQL 클라우드 DB이다. 파이어스토어는 데이터를 도큐먼트 구조로 저장한다. 도큐먼트들은 컬렉션으로 정리된다. 도큐먼트들은 하나의 레코드처럼 동작하는 객체이고, 고유한 아이디를 가지며, 키밸류 집합으로 구성된다.

문서 안에 또 다른 컬렉션을 가질 수도 있고 해당 컬렉션을 서브컬렉션이라 부른다. 문서 내의 필드는 단순 문자열 / 숫자뿐 아니라 중첩 객체도 가능하다.

레코드란 RDB나 일반적인 데이터 구조에서 자주 사용되는 용어로, 어떤 엔티티(객체)의 속성값들이 하나로 묶인 단위를 말한다.

{
  "firstname": "경준",
  "lastname": "Kim",
  "age": 28
}

{
  "name": "경준",
  "address": {
    "city": "Seoul",
    "zip": "12345"
  }
}

NoSQL이란?

고정된 스키마 없이 유연하게 데이터를 저장할수 있고, 수평적 확장이 용이하며, 대규모 데이터를 고속으로 처리할 수 있는 비관계형 데이터베이스이다.

기존 관계형 데이터베이스는 DB 스키마가 있어 변화에 유연하지 않고, 대규모 데이터처리에 적합하지 않으며, 분산 시스템 구축에 어려움이 있다.

대규모 데이터 처리에 적합하지 않은 이유는 아래와 같다.

스케일 업 구조 중심
- 대부분의 RDBMS는 수직 확장에 초점을 맞춰 설계
- 일정 수준 이상의 CPU / 메모리 / 스토리지를 초과하면 확장 한계에 도달
  - 수억건 데이터 테이블에 대해 조인 - 서브쿼리 실행 시 처리시간 급격히 증가
- (NoSQL): 수평 확장이 용이
조인 연산 중심 구조
- 관계형 DB는 테이블 간 정규화와 조인 중심으로 설계됨.
  - 정규화란: 관계형 DB 설계 시 중복 제거, 데이터 무결성 유지를 위해 테이블을 구조적으로 나누는 것
- 대규모 데이터 조인 시 디스크 I/O 및 메모리 사용량 급증
- (NoSQL): 빅데이터 환경에서는 Key-Value 접근 방식이 효율적
트랜잭션 강박 (ACID)
- RDBMS는 ACID(원자성, 일관성, 고립성, 지속성) 원칙을 철저히 지키도록 설계
- 모든 작업에 대해 트랜잭션 로그 및 락 메커니즘 사용 - 성능 부하 (절대적 일관성을 중요시)
- (NoSQL): 대규모 데이터 수집 환경에서는 절대적 일관성보다 속도와 가용성이 우선

또한, 분산 시스템 구축이 어려운 이유는 아래와 같다.

데이터 분산 처리에 취약한 구조
- 전통적인 RDBMS는 단일 인스턴스 기반으로 설계 (마스터 - 슬레이브)
- 데이터 샤딩과 파티셔닝을 수동으로 구성해야 함.
  - 파티셔닝: 하나의 데이터베이스 테이블을 내부적으로 분리해서 관리하는 방법. (논리적으로는 하나의 테이블, 물리적으로는 여러 부분)
    - 하나의 DB 인스턴스 내부에서 처리
  - 샤딩: 데이터베이스 자체를 여러개로 나눔. 데이터를 여러 DB 서버에 물리적으로 분산 저장
    - 각 샤드(Shard)는 완전히 독립된 DB 인스턴스, 샤드 간 조인이 어렵고 관리가 복잡하다
- (NoSQL): 처음부터 분산 환경을 가정하고 설계
노드 간 일관성 유지 부담
- 분산 환경에서는 여러 노드 간 데이터 일관성 문제가 발생
- RDBMS는 강한 일관성 모델을 따름
  - 분산 환경에서 동기화 비용이 매우 큼. (성능 병목 발생)
- (NoSQL): 가용성, 분할 내성을 우선으로 하는 경우가 많음
장애 허용 설계 부족
- 전통 RDBMS는 단일 인스턴스 기반 설계로 인해 단일 장애 지점이 될 수 있음.
- 복제나 장애 조치를 수동으로 구성, 클러스터링 구성이 복잡
  - 클러스터링 구성이 복잡하다: 여러 서버 (노드)를 하나의 시스템처럼 동작하게 만들기 위한 구성과 관리가 어렵다는 것을 의미
- (NoSQL): 자동 장애조치 (Failover) / 리플리케이션을 내장 기능으로 제공

NoSQL 쿼리는 아래 방식으로 동작한다.

특정 문서 조회: 문서 ID를 통해 단일 문서를 직접 조회
조건에 맞는 여러 문서 조회: 컬렉션 내에서 쿼리 조건을 지정하여 일치하는 문서들만 조회 가능 (age > 25 && city == "Seoul")
필터와 정렬 조건을 조합 가능: 여러 필터를 체이닝하여 연속 지정 가능 / 정렬과 결합 가능
인덱싱 기반 조회: Firestore는 쿼리에 사용되는 필드들을 자동으로 인덱싱
- 문서의 모든 필드가 자동 인덱싱 되기 때문에 테이블 풀 스캔을 하지 않음.
- 반면 MySQL은 인덱싱을 해두지 않으면 테이블 풀 스캔이 이루어짐.

Firestore는 모든 디바이스에 대해 데이터를 동기화하는 기능을 사용하지만, 일회성 쿼리도 효율적으로 처리된다. 데이터 동기화는 여러 디바이스로부터 DB가 지속적인 연결을 유지하고, 변경사항을 추적하고, 자동으로 업데이트 해야하기 때문에 무거운 작업이다. 반면 일회성 쿼리는 특정 시점에 한 번만 데이터를 요청하기에 가볍고 빠르게 실행된다.

이러한 동작은 아래 방식을 통해 구현된다.

앱에서 사용중인 데이터를 로컬에 캐시
- 오프라인 환경에서도 데이터를 읽고 쓰고 구독 및 쿼리
오프라인 지원
- 오프라인 상태에서도 캐시된 데이터를 기반으로 로컬 변경사항을 저장
동기화 처리
- 다시 온라인 상태가 되면 로컬 변경사항을 클라우드 Firestore에 자동으로 동기화
- 충돌 발생 시 Firestore가 자동으로 해결하거나 앱이 처리하도록 이벤트 제공

파이어스토어는 구글 클라우드의 인프라를 활용하여 여러 기능을 제공한다.

자동 다중 지역 데이터 복제 (automatic multi-region data replication)
- 데이터를 여러 리전에 자동 복제, 고가용성 및 재해 복구 능력 확보
강력한 일관성 보장 (strong consistency guarantees)
- 어떠한 디바이스나 클라이언트에서 데이터를 읽더라도 가장 최신 상태 데이터를 보장
원자적 일괄 작업 (atomic batch operations)
- 여러 데이터 쓰기 및 수정 작업을 하나의 단위로 처리 / 일부만 반영되는 일이 없음 (모두 성공하거나 모두 실패)
실제 트랜잭션 기능
- 여러 문서를 대상으로 하는 트랜잭션 처리 가능 / 복잡한 동시성 문제에도 안정적으로 동작

트랜잭션이란?

트랜잭션이란 여러 작업을 하나의 묶음(단위)로 처리하는 방식이다. 이 묶음 안의 작업은 모두 성공하거나 / 전부 실패로 처리되며, 실패의 경우 묶음 내 작업이 하나라도 실패하는 경우에도 해당된다.

# Bigtable

빅테이블은 구글의 NoSQL 빅데이터 데이터베이스 서비스이다. 해당 DB는 구글 검색 / 애널리틱스 / 지도 / 메일 등 핵심 서비스 구동하는 데에 사용되는 것과 동일한 시스템이다. 빅테이블은 일관된 저지연 (low latency), 높은 처리량으로 대규모 워크로드를 처리하도록 설계되어 있다.

빅테이블을 선택하는 이유는 아래와 같다.

1TB 이상의 반정형 / 정형 데이터를 다룰때
데이터가 빠르게 생성되거나 (고처리량), 빠르게 변경되는 경우
NoSQL 데이터를 다룰때 (강력한 관계형 트랜잭션 특성이 필요하지 않을때)
데이터가 시계열이거나 자연스러운 순서를 가지는 경우
빅데이터를 다루면서 비동기 배치 처리 / 실시간 처리를 수행하는 경우
머신러닝 알고리즘을 적용하고 있는 경우

전체적으로 실시간 대규모 데이터 처리 및 시계열 데이터 처리 시 주로 사용된다는 것을 알 수 있다.

빅테이블은 다른 Google Cloud 서비스 및 타사 클라이언트와도 상호작용 할 수 있다. API를 통해 Managed VM, HBase REST서버, HBAse 클라이언트를 사용하는 자바 서버와 같은 데이터 서비스 계층을 통해 데이터를 읽고 쓸 수 있다. 이러한 방식은 애플리케이션, 대시보드, 데이터 서비스에 데이터를 서빙하는 데 사용된다.

Managed VM: Google App Engine Flexible Environment에서 제공하는 VM을 관리형으로 제공하는 서비스
- 내부적으로는 Compute Engine 가상머신이지만 구글이 관리해주기 때문에 사용자가 직접 VM을 다룰 필요가 없음. Managed VM 내에서 실행되는 앱이 빅테이블 API를 호출하는 것이 가능
HBase REST 서버: Apache HBase는 하둡 기반의 분산형 NoSQL 데이터베이스이다. HBase REST 서버는 HTTP/REST API를 통해 HBase와 통신할 수 있게 해주는 서버 컴포넌트이다.
- 빅테이블은 HBase API와 호환되는 인터페이스를 제공, HBase REST 서버를 사용하면 빅테이블과도 통신이 가능
HBase 클라이언트를 사용하는 자바 서버: Apache HBase에서 제공하는 자바 기반 클라이언트 라이브러리를 사용하는 서버 애플리케이션.
- 빅테이블 사용 시 HBase 자바 API와의 호환성 보장 / 서버 애플리케이션 수정을 거의 하지 않고도 빅테이블 연결 가능
데이터 서비스 계층: 클라이언트와 데이터 저장소 사이에서 중간 역할을 하는 계층
- API 요청을 받아 DB 쿼리로 변환 / 데이터 가공 및 필터링 후 클라이언트 전달 등
- REST API 서버 / GraphQL 서버 등등이 이 계층에 해당한다.

Apache Hadoop은 대용량 데이터를 분산 저장하고 처리하기 위한 오픈소스 프레임워크이다. 해당 프레임워크는 대표적으로 두 가지 핵심 컴포넌트가 존재한다.

HDFS(Hadoop Distributed File System): 데이터를 여러 서버에 나눠 저장하는 분산 파일 시스템
MapReduce: 분산된 데이터에 대해 계산 작업을 병렬로 처리하는 프로그래밍 모델
- 큰 파일은 Map(쪼개고) 다시 Reduce(합치기) 작업이 이루어진다

데이터는 Dataflow Streaming, Spark Streaming, Storm같은 인기 있는 스트림 처리 프레임워크를 통해 스트리밍 방식으로 유입될 수 있다. 스트리밍은 데이터를 batch형태로 일괄처리하는게 아니라 실시간, 지속적으로 처리하는 방식이다. Dataflow Streaming은 구글 클라우드에서 제공하는 스트리밍 및 배치 처리 플랫폼이고, Spark Streaming은 Apache Spark 모듈 중 하나로 실시간 데이터 스트림을 처리할 수 있도록 설계된 컴포넌트이다.

스트리밍이 불가능 하더라도 배치처리를 통해 빅테이블에서 데이터를 읽고 쓸 수 있다.

빅쿼리는 데이터 저장과 데이터 처리의 경계에 위치해있다. 빅쿼리에 데이터를 저장하는 일반적인 이유는 대규모 데이터 분석 및 인터랙티브 쿼리 기능을 사용하기 위해서다. 빅쿼리는 순수한 데이터 저장 제품은 아니다.

# Comparing storage options

구글 클라우드의 여러 코어 스토리지 선택지들을 확인했는데, 이를 아래 형태로 구분하여 비교해볼 수 있다.

Cloud Storage: 10MB 이상의 Blob (큰 이미지 및 영상)을 저장해야 하는 경우 고려한다.
- 페타바이트 단위 용량을 제공하며 한 객체당 최대 5TB까지 저장 가능하다.
Cloud SQL / Spanner: 온라인 트랜잭션 처리 시스템에 대한 완전한 SQL 지원이 필요한 경우 고려
- Cloud SQL은 머신 유형에 따라 최대 64TB (웹 프레임워크 및 기존 애플리케이션에 가장 적합), 스케일 업 위주
- Spanner는 페타바이트까지 저장 용량 제공, 스케일 아웃 위주 (분산형 시스템)
Firestore: 실시간 쿼리 결과 조회 및 오프라인 쿼리 지원 / 대규모 확장성과 예측 가능한 성능이 모두 필요한 경우 고려
- 테라바이트 규모 저장 용량 제공
- 단일 엔티티당 최대 1MB 저장
- 모바일 앱 및 웹앱 데이터 저장 / 동기화 / 쿼리 처리에 적합
Bigtable: 많은 수의 정형 객체(structured object)를 저장해야 하는 경우 고려 (정형 데이터란 형식 / 스키마가 명확히 정의된 데이터를 말한다.)
- SQL 쿼리 / 다중 행 트랜잭션을 지원하지 않음
- 페타바이트 급 용량 제공
- 셀 당 최대 10MB / 행당 최대 100MB 저장 가능
- 광고기술 / 금융 데이터 / IoT 데이터와 같이 읽기 쓰기 작업이 많은 분석 데이터에 적합

← Google Cloud Platform - Get Certified Program (Virtual Machines and Networks in the Cloud) Google Cloud Platform - Get Certified Program (Containers in the Cloud) →