AWS - 데이터베이스 및 분석

Database Intro

• 디스크에 데이터를 저장할때 EFS, EBS, EC2 인스턴스 스토리지, S3등을 이용할때는 제한이 있다.
• 데이터를 구조에 따라 저장하고자 한다면 데이터 베이스를 이용하게 된다.
• 이때 이 구조를 이용하여 효과적인 쿼리와 데이터 검색을 위한 인덱스를 구축할 수 있다.
• EFS, EBS, EC2 인스턴스 스토리지, S3를 이용하면 데이터베이스를 이용한 파일별 작업이 가능하므로 더 체계회될 것이다.
• 데이터셋간의 관계를 정의할 수도 있음
• 오늘날 데이터베이스는 모두 목적에 맞게 최적화되어서 서로 다른 기능과 모양, 제약을 갖추고 나온다.
• 시험에는 질문에 있는 사례에  어떤 데이터베이스가 가장 적합할지 판단하는 문제가 출제됨

Ralational Databases

• Excel을 사용해 봤다면 Excel 스프레드시트와 동일하다고 볼 수도 있겠으나 여기서는 각 테이블의 연결고리를 볼 수 있다.
• 관계형 데이터베이스에서는 SQL 언어를 사용하여 쿼리 또는 조회가 가능하다는 점이 특색이다.
• 따라서 SQL이 나올때는 관계형 데이터베이스를 떠올리면 된다.

NoSQL Databases

• NosQL = non-SQL = non relational databases
• 좀더 현대식의 데이터베이스로 특정 데이터 모델을 염두에 두고  특정한 목적을 위해 구축되어 현대 애플리케이션 구현을 위해 유연한 스키마를 갖고 있다. (스키마란 데이터의 모양을 의미한다)
• NoSQL 데이터베이스는 유연성이 높다는 것이 장점으로 데이터 모델을 개선하기도 쉽고 확장이 가능하여 분산 서버를 추가하면 스케일 아웃이 가능하도록 설계되어 있다.
• 이전에 본 관계형 데이터베이스는 서버를 추가해서 확장하기 어려워 수직으로 확장하는 방법뿐인데 NoSQL 데이터베이스에서는 수평 확장이 가능하다.
• 또한 고성능을 자랑하며 특정 데이터 모델에 최적화되어 있다.
• 고기능으로 해당 모델에 대해 최적화된 유형이다.
• 마지막으로 NoSQL 데이터베이스의 예시는 몇 가지 살펴보면, 키 값 데이터베이스와 문서, 그래프, 인 메모리 혹은 검색 데이터베이스를 들 수 있다.

NoSQL data example : JSON

• JSON은 자바스크립트 객체 표기법을 뜻하며 IAM 정책을 정의할 때에 본 적이 있는 언어이다.
• JSON은 NoSQL 모델에 맞추어져 있는 데이터 형식
• 데이터는 중첩될 수 있으며 필드도 추가될 수 있다.
• 배열과 같은 새로운 타입도 지원 가능하다.

Databases & Shared Responsibilty on AWS

• AWS를 통해서 여러 데이터베이스를 관리할 수 있다.
• 관리 형 데이터베이스의 장점
  • 빠른 프로비저닝이 가능하다는데에 있다. 일반적으로 데이터베이스는 설계시에 고가용성을 염두에 두는데, 따라서 데이터베이스를 확장하려고 하면 수직이든 수평이든 쉽게 스케일링 할 수 있다.
  • 또한 운영 및 업그레이드 뿐만 아니라 데이터 베이스 자동 백업 및 복원을 수행하는 일부 유틸리티도 포함된다.
  • 더불어 기본 인스턴스의 운영체제를 패치해야 하는 경우 이는 사용자의 책임이 아니라 AWS의 책임이 된다. AWS가 전체 데이터베이스의  패치작업을 전담한다.
  • 모니터링과 알람또한 통합된다.
• 물론 EC2 인스턴스에 자체적으로 데이터베이스 기술을 실행할 수도 있으나 그럴 경우 복원력, 백업, 패치 작업, 고가용성, 내결합성, 스케일링 등과 관련된 모든 사항을 직접 처리해야 한다. 
• 이런점 때문에 관리형 데이터베이스를 선택하는것이 많은 사용 사례에서 도움이 되는 이유임

Amazon RDS Overview

• RDS(Relational Database Service)는 관계형 데이터베이스 서비스를 의미한다.
• 따라서 SQL을 쿼리 언어로 사용하는 데이터 베이스를 위한 관리형 데이터베이스 서비스
• 이를 통해 AWS에서 관리할 데이터베이스를 클라우드에 생성할 수 있다.
• 이러한 데이터베이스는 다양한 종류가 있을 수 있다.
  • Postgres
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • IBM DB2
  • Aurora (AWS Proprietary)

Advantage over using RDS versus deploying DB on EC2

• 우리가 EC2에서 자체 데이터베이스를 배치하는 대신 RDS를 사용하는 이유는 무엇일까?
• RDS는 관리형 데이터베이스 서비스이다.
  • 자동으로 프로비저닝해주고 OS를 패치해준다.
  • 지속적인 백업 및 복원 옵션이 제공된다. 특점 시점에 복원이 가능하다.
  • 데이터베이스가 제대로 작동하는지 확인하기 위해 모니터링 대시보드를 갖게 된다.
  • 읽기 복제본을 생성하여 읽기 규모를 확장하고 읽기 성능을 향상시킬 수 있다.
  • 하나의 가용영역(AZ) 전체가 다운되는 경우를 대비한 재해 복구 계획으로써 다중 AZ를 설정하는 방법을 갖게 될 것임
  • 업그레이드를 위한 유지 관리 창구를 설정
  • 수직 및 수평으로 확장할 수 있다. 
  • 스토리지는 EBS의 지원을 받음
• RDS 데이터베이스로 할 수 없는 유일한 일은 RDS 데이터베이스 인스턴스에 SSH를 통해 연결할 수 없다는 것이다. 우리는 단지 서비스를 이용하면 된다. AWS가 우리를 위해 데이터베이스 전체를 관리한다. 
• 단지 SSH 유틸리티를 사용하며 데이터베이스 내에서 무슨 일이 일어나고 있는지 확인할 수는 없다.

RDS Solution Architecture

• RDS는 우리의 솔루션 아키텍처 내에서 어디에 적합할까?
  1. 우리는 로드밸런서를 보유하고 있으며 이것은 여러 백엔드 EC2 인스턴스를 마주하고 있다. 
  2. 그리고 이 인스턴스들은 자동 스케일링 그룹에 있을 수 있다.
  3. 그들은 데이터를 어딘가에 저장하고 공유해야 하며 이것은 구조화된 데이터이다.
  4. 따라서 이 인스턴스들은 EBS, EFS 또는 EC2 인스턴스 스토어를 사용하지 않을 것이다.
  5. 이 예시에서는 관계형 데이터베이스이고 따라서 SQL에 기반하고 있고, 이 EC2 인스턴스들은 동시에 데이터베이스에 연결하고 읽기 및 쓰기 작업을 수행한다. 
  6. 따라서 그들은 백엔드에서 데이터베이스를 공유하게 된다.
  7. 이는 RDS 뿐만 아니라 모든 종류의 데이터베이스에 적용되는 고전적인 솔루션 아키텍처임
  8. 웹 요청을 받아들일 로드 밸런서 계층, 애플리케이션 논리를 수행하는 백엔드 EC2 인스턴스가 있고, 데이터 읽기 및 쓰기를 수행하는 데이터베이스 계층이 있다.

Amazon Aurora

• Aurora는 AWS가 만든 데이터베이스 기술이고 오픈소스가 아니다.
• RDS와 동일한 방식으로 작동한다.
• 아마존 Aurora에 직접 연결되는 EC2 인스턴스가 있고 Aurora는 두 가지 종류의 데이터베이스 기술을 지원한다. 즉 PostgreSQL과 MySQL을 지원한다.
• Aurora의 아이디어는 클라우드에 최적화 된다는 것이다. 따라서 RDS상의 MySQL보다 5배 성능이 향상되고 RDS상의 Postgre보다 3배 성능이 향상된다.
• 무엇보다도 Aurora 데이터베이스의 스토리지에 대해 걱정할 필요가 없다. 스토리지가 10GB 단위로 최대 128TB까지 자동으로 증가하기 떄문이다.
• Aurora가 RDS보다 약 20% 더 비싸더라도 더 효율적일 것이므로 더 비용 효율적일 것이다.
• Aurora는 AWS의 프리 티어에 포함되지 않지만, RDS는 포함된다.
• 시험관점에서 볼때 RDS와 Aurora는 AWS에서 관계형 데이터베이스를 생성하는 두 가지 방법이 될 것이다. 둘 다 관리형인데, Aurora는 보다 클라우드 기반이 된다. 반면 RDS는 관리형 서비스로서 직접 기술을 실행할 것이다.

Amazon Aurora Servicess

• 아마존 Aurora를 위한 서버리스 옵션도 있다.
• 여기서 데이터베이스 인스턴스화가 자동화 된다. 또한 데이터베이스의 실제 사용량을 기반으로 한 자동 확장 기능도 있다.
• PostgreSQL과 MySQL 모두 Aurora 서버리스 데이터베이스의 엔진으로써 지원된다.
• 어떤 종류의 용량 계획도 수행할 필요가 없다.
• 우리가 서버를 관리하지 않아 관리 부담이 없고 초당 비용을 지불하게 된다. 따라서 Aurora 클러스터를 직접 배정하는 것보다 훨씬 비용 효율적일 수 있다.
• 우리의 작업 부하가 드물거나 간헐적이거나 예측할 수 없는 경우 유용할 것이다.
• 그러면 어떻게 작동할까?
  1. 클라이언트 관점에서 매우 쉽다.
  2. Aurora가 관리하는 프록시 플릿에 연결한다.
  3. 그러면 Aurora가 데이터베이스를 확장하거나 축소해야 할 경우 배후에서 데이터베이스 인스턴스를 인스턴스화 한다.
  4. 그리고 이러한 Aurora 데이터베이스는 무슨 일이 있어도 동일한 스토리지 크기를 공유하게 된다.
  5. 따라서 시험을 칠때 관리 오버헤드가 없는 Aurora라는 표현을 본다면 Aurora 서버리스를 떠올리면 된다.

RDS Deployments: Read Replicas, Multi-AZ

• 다양한 아키텍처를 통해 RDS 데이터베이스를 배포할 수 있고 그 것중 우리가 직접 선택해야 한다.
  
  • RDS 읽기 전용 복제본을 사용하는 방식이 있다.
    1. 메인 RDS 데이터베이스로부터 읽기 작업을 수행하는 애플리케이션으로 예를들어 보자
    2. 이때 읽기 워크로드를 확장해야 하는데, 더 많은 애플리케이션들이 RDS로부터 더 많은 데이터를 읽어 들여야 하기 때문이다. 
    3. 읽기 전용 복제본을 생성해서 이를 해결할 수 있는데, 즉 RDS 데이터베이스의 복사본과 복제본이 생성된다는 뜻이다.
    4. 또한 이로써 애플리케이션이 해당 읽기 전용 복제본으로부터 읽기 작업을 할 수 있다는 의미가 된다.
    5. 따라서 이 읽기 권한을 여러 RDS 데이터베이스에 분산시키게 된다.
    6. 최대 5개의 읽기 전용 복제본을 생성할 수 있는데, 이 예시에서는 메인 RDS 데이터베이스와 더불어 2개의 읽기 전용 복제본이 있다고 하자. 그리고 이 애플리케이션은 해당 복제본을 모두 읽을 수 있다.
    7. 데이터 쓰기 작업의 경우, 쓰기 작업은 오직 메인 데이터베이스에서만 이루어지므로 애플리케이션은 오직 중앙 RDS 데이터베이스 한곳에만 데이터를 기록할 수 있다.
    8. 이렇게 읽기 전용 복제본은 읽기 작업을 확장하는데 쓰인다.
  • 다음으로 Muti-AZ (다중 AZ)가 있다.
    1. 이는 AZ 운영 정지와 같은 장애 조치가 발생했을때 유용하게 쓰인다. 가용 영역에서 충돌이 발생했을 때 높은 가용성을 보장해 준다.
    2. 예를 들어 애플리케이션이 동일한 메인 RDS 데이터베이스에서 읽고 쓰기 작업을 수행한다고 하자.
    3. 이때 AZ를 넘나드는 복제본을 다른 가용 영역에서 설정하려 한다.
    4. 이때 복제본은 장애 조치 데이터베이스가 되는데, 다른 AZ에 존재하기 때문에 다중 AZ라고 불린다.
    5. 문제가 있거나 AZ 상에 오류가 발생하는 등, 모종의 이유로 메인 RDS 데이터베이스가 충돌하면 RDS에서 장애 조치가 트리거 된다.
    6. 이때 애플리케이션은 다른 AZ의 개발자 데이터베이스에서 장애 조치를 실시한다.
    7. 따라서 이 경우에 데이터는 메인 데이터베이스에서만 읽고 쓸 수 있으며 장애 조치 DB는 수동적 DB로 메인 데이터베이스에 문제가 발생하기 전까지는 액세스 할 수 없다.
    8. 또한 단 하나의 AZ만 장애 조치 AZ로 설정할 수 있다.

RDS Deployments: Multi-Region

• 마지막 배포 방법으로는 다중 리전을 들 수 있다.
  1. 이 또한 Multi-Region (Read Replicas) 읽기 전용 복제본을 다루는데, 이번에는 한 리전이 아닌 여러 리전을 걸치게 된다.
  2. 예를들어 eu-west-1에 RDS 데이터베이스가 있고, eu-east-2에 읽기 전용 복제본을 생성해 본다고 생각해보자.
  3. 이제 us-east-2에 있는 애플리케이션을 본 읽기 전용 복제본을 통해 로컬에서 읽을 수 있다.
  4. 하지만 해당 애플리케이션에 데이터를 써야 할때는 리전 간 쓰기 작업을 수행해야 한다. (Main DB에 write해야 하므로)
  5. 즉 eu-west-1에서 데이터를 써야 한다.
  6. 또한 호주에 있는 ap-southest-2에 읽기 전용 복제본이 있을 때에도 동일한 원리를 적용한다.
  7. 그렇다면 왜 다중 리전 배포를 수행하려는 걸까?
     
     • 첫 번째로 한 리전에 문제가 생겼을때를 대비한 재해 복구 전략이 필요하기 때문이다. eu-west-1 리전에 문제가 생겼을 시 ap-southeast-2나 us-east-2에 백업이 되어있다. 이렇게 재해 복구 전략을 수립하는 것이다.
     • 또한 서로 다른 리전에 있는 애플리케이션도 로컬 데이터베이스로부터 읽어들이기 때문에 지연 시간이 짧다는 장점이 있다.
     • 하지만 하나 알고 있어야 할 점은, 리전 간 데이터를 복제할 때에는 리전 간 복제된 데이터를 네트워크를 통하여 전송하는 비용이 발생한다. 

Amazon ElastiCache Overwiew

• AWS의 데이터베이스 유형 중 두번째로 ElastiCache를 살펴보자
• RDS를 관리형이자 관계형 데이터베이스에 사용했던 것처럼 ElastiCache를 사용하여 관계형 Redis(레디스) 또는 Memcached 데이터베이스를 이용해 볼 것이다.
• 이와 같은 캐시는 높은 성능과 짧은 지연 시간을 자랑하는 인 메모리 데이터베이스이다. 따라서 인 메모리 데이터베이스가 시험에 출제될 시에는 바로 ElastiCache를 떠올려야 한다.
• ElastiCache는 읽기 집중적인 워크로드의 데이터베이스로부터 워크로드를 줄일 때에 용이하게 쓰인다. RDS의 데이터베이스에서는 많은 쿼리 작업을 수행하는데, 항상 동일한 쿼리를 다루게 되면 RDS 데이터베이스에 막대한 부하가 발생한다. 대신에 캐시를 사용하면 ElastiCache를 통해 인 메모리 데이터베이스로  캐시가 직접 전송되도록 하여 데이터베이스 부하를 줄 일 수 있다.
• 또한 이는 관리형 데이터베이스로 AWS가 모든 운영 체제 유지 보수와 패치작업, 최적화 설정, 구성, 모니터링, 장애 회복 및 백업을 담당한다.

ElastiCache Solution Architecture - Cache

• 이미 시험에 나올 캐시에 대해서는 많은 내용을 배웠지만, 인 메모리 데이터베이스와 관련해서도 알 필요가 있다.
• 캐시에 대한 솔루션 아키텍처는 다음과 같다.
  1. Elasic 로드 밸런서가 EC2 인스턴스로 간다. ASG일 확률이 높을 것이다.
  2. 이때 우리의 Amazon RDS 데이터베이스로부터 데이터를 읽고 쓰게 되는데, 이때는 속도가 느릴 것이다.
  3. 그리고 가능한 경우에는 일부 값을 Amazon ElastiCache 데이터베이스에 캐싱 처리하게 되는데, 이 작업은 인 메모리에서 이루어 지므로 속도가 빠르다. 
  4. 따라서 ElastiCache를 이용하면 RDS 데이터베이스의 부하를 줄이고 이를 ElastiCache 데이터베이스와 나눠 처리하는 것이 캐시를 이용하는 목적이라고 할 수 있다.
  5. 또한 쿼리를 따로 저장하여 언제든 사용할 수 있고 액세스도 쉬워지며 메인 데이터베이스의 부하를 줄일 수도 있다.

DynamoDB

• DynamoDB는 완전 관리형 고가용성 데이터베이스로 세 개의 가용 영역을 걸쳐 복제본을 두고 운영된다.
• NoSQL 데이터베이스이므로 비관계형 데이터베이스이다.
• DynamoDB는 AWS의 대표 상품 중 하나라고 할 수 있다. 
• 막대한 작업량도 소화할 수 있고, 분산된 서버리스 데이터베이스이다.
• 즉 RDS나 ElastiCache를 이용해서 서버에 프로비저닝할 필요가 없다.
• 원래라면 인스턴스 유형에 프로비저닝이 필요하겠지만, DynamoDB에서는 필요가 없다.
• 그래서 서버리스 데이터베이스라 불린다. 벡엔드에 서버가 있긴 하지만 우리 눈에는 보이지 않는다.
• DynamoDB가 훌륭한 이유는 초당 수백만 건의 요청, 조 단위가 넘는 행, 수백 TB의 스토리지까지 확장해도 신속하고 한결같은 성능을 보여주기 때문이다.
• 따라서 검색 지연 시간이 한 자릿수 밀리초인 성능을 필요로 할 경우에는 DynamoDB가 적절한 데이터베이스이다. 
• 시험에는 서버리스라는 키워드나 한 자릿수 밀리초의 지연 시간과 같이 저 지연시간을 나타내는 키워드를 잘 찾아보면 좋다.
• 보안, 인증, 관리상 IAM과 통합되어 있다.
• 비용이 적고 오토 스케일링 기능을 갖추고 있다.
• 비용 절감을 위해 데이터를 분류하는 방식에 따른 Standard & Infrequent Access(IA) 테이블 클래스가 있다.

DynamoDB - type of data

• 그렇다면 DynamoDB에는 어떤 데이터가 저장될까?
• 이는 키/값 데이터베이스로 데이터는 다음과 같은 양상으로 저장된다.
  • 먼저 기본키가 있고, 하나 혹은 두개의 열로 파티션 키, 정렬 키로 구성되어 있고 이것은 고정이다.
  • 그리고 나머지 열들은 임의로 정의할 수 있다.
  • 모든 아이템은 행으로 저장되고 이것이 DynamoDB의 운영방식이라고 할 수 있다.
• DynamoDB는 NoSQL 데이터베이스로서 데이터 검색의 지연 시간이 짧고 서버리스 데이터베이스에 대한 액세스가 가능하다.

DynamoDB Accelerator -DAX

• 시험에서는 DynamoDB Accelerator 와 DAX 두 단어를 혼용해서 쓴다.
• 이는 DynamoDB를 위한 완전 관리형 인 메모리 캐시이다.
• ElastiCache와는 달리 DynamoDB 전용 캐시이며 애플리케이션이 DynamoDB 속 DynamoDB 테이블에 액세스하려고 할 때, 가장 최근에 읽힌 객체를 캐시에 저장하려면 DAX나 DynamoDB Accelerator를 캐시로 사용해야 한다.
• DAX는 오직 DynamoDB 전용으로 ElastiCache를 이용할 필요가 없다. 물론 이용할 수는 있지만 이미 DynamoDB와 완벽히 통합된 DAX를 쓰는게 낫다. 성능이 10대는 향상될테니 말이다.
• DynamoDB 테이블에 액세스 할때마다 한자릿수 밀리초 지연 시간이 아니라 마이크로초 지연 시간을 볼 수 있다. 
• 보안도 완벽하며 확장성과 가용성 모두 높다.
• ElastiCache와의 또 다른 차이점으로는 DAX는 DynamoDB와 완벽히 통합되어 있어 DynamoDB에서만 사용하나 ElastiCache는 다른 데이터베이스에서도 캐시 저장에 사용할 수 있다.

DynamoDB - Global Tables

• 짧은 지연 시간으로 DynamoDB 테이블에 액세스할 수 있도록 하는 기능이며 여러 리전에서 가능하다는 점이 중요하다.
• 예시를 들면
  1. us-east-1에 DynamoDB 테이블이 하나 있고 이 테이블은 글로벌 테이블이 된다.
  2. 기본적으로 사용자는 N.Virginia(us-east-1)리전의 DynamoDB 테이블에 대한 읽기와 쓰기 작업을 할 수 있다.
  3. 이때 해당 글로벌 테이블에 대한 복제본을 설정할 수 있는데, Paris(eu-west-3) 리전에 글로벌 테이블을 생성해서 이 두 테이블에 양방향 복제 작업이 이루어졌다고 지정할 텐데 이는 곧 us-east-1과 eu-west-3의 데이터가 동일하며 파리 리전에 가까이 있는 사용자는 해당 리전에서 짧은 지연 시간을 거쳐 글로벌 테이블에 액세스할 수 있다. 원하는 경우 10개의 리전에 대해서도 이와 같은 설정이 가능하다.
  4. 이처럼 글로벌 테이블은 진정한 의미의 글로벌 됨을 자랑하며 사용자들이 해당 테이블에 있는 모든 리전에서 이 두 테이블의 복제본에 대한 읽기와 쓰기에 대한 작업을 할 수 있다.
• 해당 글로벌 테이블이 있는 모든 AWS 리전에서 읽기/쓰기 액세스가 가능하다는 점은 곧 액티브 - 액티브 복제라는 뜻이 된다. 즉 어느 리전이든 직접 쓰고 해당 내용은 바로 다른 리전에 복제된다는 의미를 나타낸다.

Redshift Overview

• Redshift는 PostgreSQL 기반의 데이터베이스이지만 OLTP에는 사용되지 않는다. OLTP는 OnLine Transacion Processing의 약자이다.  OLTP는 RDS가 잘하는 것이었다.
• Redshift는 대신 OLAP(Online Analytical Processing)에 특화되었다. 이것은 분석과 데이터 웨어하우스에 사용된다.
• 따라서 시험중에 데이터베이스가 데이터 웨어하우스와 분석 역할을 가질 때에는 Redshift가 정답일 것이다.
• Redshift를 이용하면 데이터를 지속적으로 로드하지 않는다. 1시간 등의 간격으로 로드하게 되며 Redshift의 장점은 데이터를 분석하는 것과 계산하는 일에 매우 특화되어 있다는 것이다.
• 다른 데이터 웨어하우스들의 10배 성능을 자랑하며 용량은 PB 단위까지 확장된다.
• 데이터는 열 저장 방식으로 저장된다. 행 기반에 반대되는 Columnar 스토리지로 불려진다.
• 그러므로 Columnar(열 기반)이라는 말이 보이면 Redshift를 떠올리면 된다.
• 또한 Redshiftsms MPP(Massively Parallel Processing) 엔진이라는 것을 가지고 있어 이러한 계산들을 엄청나게 빨리 해낼 수 있다. 
• 우리는 공급한 인스턴스에 따라 비용이 청구된다.
• 조회는 SQL 인터페이스를 통해 한다.
• 마지막으로 BI(Business Intelligence) 도구, 예를 들어 QuickSight나 Tableau 등과 통합되어 있다. 그래서 데이터 웨어하우스에 대시보드를 생성하고자 할때 유용하다. 
• 데이터 웨어 하우스는 Data set에 대하여 계산과 분석 및 시각화를 대시보드를 통하여 실행하는데 사용된다. 그러므로 그러한 용도를 위해서는 Redshift가 최적이다.

Redshift Serverless

• 또 Redshift의 기능 중에는 Redshift Serverless가 있다.
• 이것을 이용하면 Redshift를 실행하면서도 데이터 창고의 크기 조정 또는 공급을 걱정할 필요가 없다. AWS에서 대신 해줄 것이다. 이름에 Serverless가 붙은 이유이다.
• 분석 작업만을 실행하고 데이터 창고의 기반은 관리하지 않는다는 발상으로, 그래서 매우 편리하다.
• 그리고 사용한 만큼만 돈이 청구되기 때문에 비용도 절약할 수 있다.
• 그러므로 적절한 사용 예는 보고서 작성, 대시보드 애플리케이션, 또는 실시간 분석 등이다. 물론 근본적인 용량과 Redshift Serverless 데이터베이스의 기반은 관리할 필요 없이 말이다.
• 그렇다면 이는 어떻게 가능한 것일까?
  1. 우리는 우리의 계정에서 Amazon Redshift Serverless를 활성화하면 된다.
  2. 그 다음 Redshift Query Editor 또는 다른 도구를 이용하여 쿼리를 작성하면 된다.
  3. 그러면 Redshift Serverless는 자동으로 조회를 시작하며 쿼리와 작업량에 따라 알아서 저장 공간을 제공하고 크기를 조정할 것이다.
  4. 마지막으로, 비용은 분석 중인 작업량과 사용된 저장 공간에 대해서만 청구되며 Redshift를 운영하는 아주 가성비 좋은 방법이다.

Amazon EMR

• EMR은 Elastic MapReduce를 뜻한다.
• 즉 EMR은 실제 데이터베이스가 아니라, AWS에서 빅 데이터를 작업하고자 할 때, 사용하는 Hadoop 클러스터를 생성하며, 이 때 Hadoop 클러스터란 방대한 양의 데이터를 분석하고 처리하는데 이용된다. Hadoop은 오픈 소스 기술로 클러스터에서 작동하는 여러 서버를 통해 데이터를 함께 분석할 수 있다.
• 따라서 EMR을 사용하면 수 백개의 EC2 인스턴스로 구성된 클러스터를 생성하여 데이터 분석을 위해 동시에 사용할 수 있다.
• Hadoop 생태계, 즉 빅 데이터 생태계에는 Apache Spark, HBase, Presto, Flink 등 다양한 프로젝트가 있는데 이들 모두 Hadoop 클러스터를 이용해서 작업한다. 
• 그렇다면 EMR이란 뭘까? EMR은 모든 EC2 인스턴스의 프로비저닝과 구성을 담당하며, 이들 모두 원활히 작동하여 빅 데이터 관점에서 데이터를 분석할 수 있도록 지원한다.
• 또한 오토 스케일링이 가능하고 스팟 인스턴스와 통합된다.
• EMR은 데이터 처리와 머신 러닝 웹 인덱싱(Indexing) 또는 일반적으로 빅 데이터에 대해 사용할 수 있다. 
• 따라서 시험에 Hadoop 클러스터가 나온다면 Amazon EMR을 선택하면 된다.

Amazon Athena

• Amazon Athena는 서버리스 쿼리 서비스로 Amazon S3에 저장된 객체에 대한 분석을 수행한다.
• 따라서 SQL 쿼리 언어를 통해 해당 파일을 생성하면, 이들을 따로 로드할 필요 없이 S3에 그대로 두면 Athena가 분석을 수행하는 것이다.
• CSV, JSON, ORC Avro, Parquet 등 파일의 형식을 다양할 수 있다.
• 참고로 Athena는 Presto 엔진을 이용해 구축되었다.
• 작동 원리를 알아보자
  1. 사용자가 Amazon S3에 데이터를 로드하면
  2. Amazon Athena가 이에 대해 쿼리 작업을 수행하고 데이터를 분석하는 간단한 원리이다.
  3. 원하는 경우 Athena에 대한 보고를 살펴볼 수 있는데, 이 경우에는 Amazon QuickSight를 이용한다.
• Athena는 스캔 된 데이터를 테라바이트당 5달러로 책정되어 있다.
• 압축된 데이터나 열 형식으로 저장된 데이터를 다룰 때에는 데이터 스캔을 줄일 수 있으므로 비용을 절감할 수 있다.
• Athena는 다양한 경우에 활용되는데 비즈니스 인텔리전스나 분석, 보고 또는 VPC 흐름 로그나 ELB 로그 Cloudtail 로그, 플렛폼 로그 등 모든 AWS 로그의 분석 시에 Athena를 이용하면 좋다.
• 시험에서는 서버리스 SQL을 이용하여 S3내 데이터를 분석한다고 하면 Amazon Athena를 바로 떠올리면 된다.

Amazon QuickSight

• 서버리스 머신 러닝 방식의 비즈니스 인텔리전스 서비스로, 대화형 대시보드를 생성한다. 말은 복잡하지만 Amazon QuickSight에서 기억 할 것은 데이터베이스에 대시보드를 만들어서 데이터를 시각적으로 만들어내고 비즈니스 사용자가 원하는 인사이트를 보여준다는 것이다. QuickSight를 이용하면 이처럼 멋진 그래프나 도표를 생성할 수 있다.
• 속도가 빠르고 자동으로 확장되며 내장 설정이 가능하며 세션별로 가격을 책정하여 서버를 프로비저닝할 필요가 없다.
• QuickSight 유저 케이스
  • 비즈니스 분석
  • 시각화 구축
  • 임시 분석 수행
  • 데이터를 이용한 비즈니스 인사이트 도출
• Quick Sight는 RDS 데이터베이스나 Aurora, Redshift, Amazon S3 등의 기반에서도 작동한다.
• QuickSight는 AWS에서 DI를 위한 도구라고 할 수 있다.

DocumentDB

• Aurora를 AWS로 PostgreSQL과 MySQL를 클라우드 네이티브 버전으로 사용했었고, DocumentDB는 MongoDB의 Aurora 버전과 다름 없다. MongoDB는 NoSQL 데이터베이스이다.
• DocumentDB는 NoSQL 데이터베이스이고 MongoDB 기술에 기반해있다.
• MongoDB는 JSON 데이터를 저장, 쿼리, 인덱스하기 위해 사용되며
• Aurora와 비슷한 배포 개념을 DocumentDB와 가진다.
• 즉 완전히 관리되는 데이터베이스이고 유용성 높으며, 데이터는 세 개의 가용 영역에 걸쳐 복제되며
• DocumentDB 스토리지는 자동적으로 10GB까지 확장된다.
• DocumentDB는 초당 수백만개의 요청을 작업할 수 있도록 확장되도록 설계되어 있다.
• 시험을 볼때 MongoDB에 관련된 것을 본다면, DocumentDB나 NoSQL 데이터베이스에 관련된 것을 생각하면 된다.

Amazon Neptune

• Neptune은 완전 관리형 그래프 데이터베이스이다.
• 그래프 데이터셋의 예로는 우리 모두 익히 알고 있는 소셜 네트워크를 들 수 있다.
  • 사용자는 친구를 가질 수 있음
  • 서로 코멘트를 남길 수 있음
  • 코멘트에 사용자가 좋아요를 누를 수 있음
  • 이를 공유할 수 있음
• 이 모든 것들이 연결되어 있으니 하나의 그래프를 생성할 수 있다. 이것이 바로 Neptune이 그래프 데이터셋에 가장 적합한 이유이다.
• Neptune은 세 개의 AZ에 최대 15개 읽기 전용 복제본을 가질 수 있다.
• 소셜 네트워크와 같이 고도로 연결된 데이터셋을 다루는 애플리케이션을 구축 및 실행할 때 사용된다. Neptune은 이처럼 그래프 데이터셋에 복잡하고 어려운 쿼리를 실행하는 데에 최적화되어 있기 때문이다.
• 최대 수십억 개의 관계를 데이터베이스에 저장할 수 있으며, 밀리초를 자랑하는 지연 시간 안에 그래프를 쿼리할 수 있다.
• 애플리케이션 가용성을 다중 가용 영역에 걸쳐 지원하고 있다.
• 자식 그래프를 저장할 때 그 활용도가 뛰어나다. 위키디피아 데이터베이스를 자식 그래프의 예로 들 수 있는데, 위키디피아 문서는 모두 상호 연결되어 있기 때문이다. 사기 탐지, 추천 엔진, 그리고 소셜 네트워크에서도 활용된다. 
• 시험에서 그래프 데이터베이스와 관련된 내용이 나오면 Neptune을 고르면 된다.

Amazon Timestream

• 이름부터 알 수 있듯이 time series(시계열)을 위한 서비스이다. 즉 time series(시계열) 데이터를 저장하고, 완전한 관리를 받으며 빠르고, 규모 조정이 가능한 서버리스 데이터베이스이다.
• 시계열 데이터란, 시간에 따라 계속적으로 변화하는 데이터이다. 
• Timestream은 데이터 용량과 요구되는 계산량에 따라 자동으로 크기가 조정된다.
• Time series(시계열)의 형태로 하루에 수 조 개의 이벤트를 저장하고 분석할 수 있다.
• 관계형 데이터베이스에 비하여 속도는 약 1000배이며 비용은 1/10이다.
• 게다가, 실시간으로 time series 데이터를 분석하고자 한다면, time series 분석 기능을 통하여 데이터베이스로부터 패턴을 찾아낼 수 있다.
• 그러므로 시험에 time series 데이터가 등장할 때마다 Amazon Timestream만 떠올리면 된다.

Amazon QLDB

• QLDB느 Quantum Ledger Database의 약자
• Ledger, 즉 원장이란 금융 거래를 기록한 장부로 QLDB도 역시 금융 거래를 기록하는 장부의 역할을 한다.
• 완전 관리형 데이터베이스로 서버리스에 고가용성을 자랑하며 세 개의 가용 영역에 걸쳐 데이터의 복제본을 갖는다.
• 또한 시간이 지남에 따라 발생한 애플리케이션 데이터의 모든 변경 내역을 살펴볼 때에 사용하므로 원장이라는 이름이 붙었다. 
• 변경이 불가능한 시스템이기 때문에, 데이터베이스에 작성하고 나면 그 후 삭제하거나 수정할 수 없다. 또한 삭제된 사항이 없음을 인증하는 암호 서명을 설정할 수 있다.
• 작동 원리는?
  • 먼저 보이지 않는 저널(Journal)이 존재하는데, 저널은 일련의 수정 사항을 갖는다. 
  • 따라서 수정이 발생할 때면, 암호화 해시가 연산되어서 삭제 또는 수정된 사항이 없음을 보장하게 되므로, 이에 해당 데이터베이스를 사용하는 모든 사용자가 이를 확인할 수 있다.
  • 따라서 이 기능은 금융 거래가 데이터베이스로부터 사라진 바가 없도록 확인할 수 있으므로 클라우드에서 QLDB를 유용한 원장 데이터베이스로 사용할 수 있는 이유가 되어 준다.
• QLDB는 일반적인 원장 블록체인 프레임워크에 비해 두 배에서 세 배 더 뛰어난 성능을 자랑하며, 데이터를 다룰 때에 SQL을 사용할 수 도 있다.
• 다음 강의에서 또다른 데이터베이스 기술인 Amazon Managed Blockchain을 볼 텐데 QLDB와 Managed Blockchain의 차이점은 QLDB에서는 탈중앙화 개념을 찾아볼 수 없다는 데에 있다. 즉 Amazon이 관리하는 중앙 데이터베이스에 접근만 할 수 있으면 이와 같은 저널을 작성할 수 있다는 의미이다. 또한 이는 많은 금융 규제와 일치한다. 따라서 QLDB와 Managed Blockchain간의 차이는 QLDB에는 중앙집중형 요소가 있으며 원장에 집중하나 Managed Blockchain은 탈중앙화 요소가 있다는 것으로 꼽을 수 있다.
• 이제 시험에서 금융 거래나 원장이라는 단어가 보이면 QLDB를 떠올리면 된다.

Amazon Managed Blockchain

• 블록체인이란 신뢰할 수 있는 중앙 기관 없이도 여러 당사자의 트랜잭션 실행이 가능한 애플리케이션을 구축할 수 있는 기술이 되어준다. 블록체인에는 탈중앙화 개념이 있기 때문이다.
• Amazon Managed Blockchain
  • 공용 블록체인 네트워크에 가입하거나
  • AWS 내에서 확장 가능한 블록체인 네트워크를 생성할 수 있다.
• 지금까지는 두 가지의 블록체인과 호환이 가능한데 Hyperledger Fabric 프레임워크와 Ethereum 프레임워크이다.
• 시험에서는 블록체인과 관련된 내용이나 Hyperledger Fabric 혹은 Ethereum이 나오면 탈중앙화된 블록체인인 Amazon Managed Blockchain을 떠올리면 된다.

Amazon Glue

• Glue는 관리형 추출, 변환 및 로드(ETL) 서비스로 줄여 말하면 ETL서비스가 되는데 시험에서는 이정도만 알면 된다.
• ETL은 정확히 무엇일까? ETL은 데이터셋에 대한 분석을 수행할 때에 그 형식이 올바르지 않거나 원하는 형식이 아닐 떄에 유용하게 쓰인다. ETL 서비스를 통해서 데이터를 준비하고 변환할 수 있는 것이다.
• 기존 서버를 사용하면 해당 작업을 수행하지만 완전 서버리스 서비스인 Glue를 통해서도 할 수 있다. 실제 데이터 변환에만 신경 쓰고 나머지는 Glue에 맡기면 된다.
  • Glue ETL을 가운데 두고서 S3 버킷과 Amazon RDS 데이터베이스 모두에서 데이터를 추출하고자 한다고 해보자
  • 두 소스에 대한 데이터 추출(Extract)을 위해 Glue를 사용해 볼텐데
  • 데이터가 Extract되고 나면 Glue 서비스에서 스크립트를 작성하고 변환(Transform) 단계로 넘어간다.
  • Glue가 데이터를 변환해주면 이제 변환된 데이터를 분석할 차례이다. 이를 위해 예를 들어서 해당 데이터를 Amazon Gedshift 데이터베이스에 Road한다고 하면 분석이 바로 수행된다.
  • Glue가 가운데에서 이를 지휘하는 것이다.
  • Glue는 아주 강력한 도구로 모든 변환이 가능하며 이를 어떤 장소에서든 로드할 수 있다.
• Glue를 살펴봤는데, 여기에 또 다른 서비스인 Glue Data Catalog가 있는데 시험에 출제되지는 않지만 잠깐 알아보자
  • Glue Data Catalog는 이름에서 알 수 있듯이 AWS 인프라 내 데이터셋의 카탈로그를 제공한다.
  • Glue Data Catalog에는 열 이름, 필드 이름, 필드 유형 등 모든 항목에 대한 참조가 있다.
  • 그리고 이 서비스는 Athena, Redshift, EMR 등의 서버에서 데이터셋을 검색하고 이에 적합한 스키마를 구축할 때에 쓰일 수 있다.

DMS - Data Migration Service

• 지금까지 데이터베이스만 알아보았지만 이제 데이터베이스 간 데이터의 마이그레이션 방법을 알아보자
• 이를 위해 DMS, 즉 데이터베이스 마이그레이션 서비스를 사용할 수 있다.
  • 먼저 Source DB에서 데이터를 추출하기 위해 DMS 소프트웨어를 실행하는 EC2 인스턴스를 실행한 다음
  • Source DB로부터 데이터를 추출하면 
  • DMS가 다시 해당 데이터를 다른 위치에 있는 Target DB로 입력한다.
• 따라서 DMS를 이용하면 데이터베이스를 AWS로 신속하고 빠르게 마이그레이션하여 복원과 자가 복구를 수행할 수 있다.
• 또 다른 이점으로 마이그레이션 작업 동안에도 소스 데이터베이스를 사용할 수 있으므로 중단할 필요가 없다.
• 여러 마이그레이션을 지원한다.
  • 동종 마이그레이션 : 예를 들어 Oracle 간 마이그레이션에 사용, Source와 Target DB가 동일한 데이터베이스 기술을 사용할 때에 해당
  • 이기종 마이그레이션 : Source와 Target DB가 서로 다른 데이터베이스 기술을 이용할 때, 예를들어 Microsoft SQL Server에서 Aurora로 마이그레이션일때 DMS가 소스에서 대상으로 데이터를 반환하는 작업을 수행해 준다.
• 시험에서 데이터베이스 마이그레이션 내용이 나오면 DMS를 고르면 된다.