AWS CCP - 7 (데이터베이스)

AWS Database

 

Relational Databases (관계형 데이터베이스)

 

테이블간의 관계를 이용해서 또 다른 연결고리를 찾을 수 있습니다.

관계형 데이터베이스는 SQL 언어를 사용하여 쿼리 또는 조회가 가능합니다 (SQL을 사용한다 -> 관계형 데이터베이스)

Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, Aurora 

 

EC2 대신 RDS를 사용하는 이유는 RDS가 관리형 DB라서 데이터베이스 공급이 자동으로 이루어집니다.

 

OS 패치는 AWS에서 해줄 것이며, 지속적인 백업과 특정 시점으로의 복원(PITR)도 가능합니다.

DB의 상태를 확인하기 위한 모니터링 대시보드, 읽기 전용 복제본을 통한 부하 분산과 읽기 속도 개선, Mulit-AZ 설치를 통한 가용성 영역 다운에 대비한 재해 복구 계획 마련, 수직 수평 확장이 모두 가능하며 저장 공간은 EBS가 지원합니다.

 

RDS 데이터베이스 인스턴스에 SSH는 할 수 없습니다. 

서비스를 이용할 뿐 이며 DB관리는 AWS가 하기에 SSH 유틸리티를 이용하여 DB 상황을 보는것은 불가능합니다.

웹으로부터 요청을 받는 ELB ---  에플리케이션 로직을 실행하는 EC2 인스턴스 ----     데이터를 읽고 쓰는 DB레이어

 

 

EC2 인스턴스의 데이터를 어딘가에 저장 및 공유해야 합니다. 이 데이터는 정형데이터로 EBS, EFS, EC2 인스턴스 스토어를 이용하지않고 DB를 이용합니다. EC2 인스턴스들은 DB에 연결하여 모두 동시에 읽기와 쓰기를 합니다.

(백엔드에서 데이터를 실시간 공유)

 

 

Amazon Aurora

AWS가 만든 DB 기술

오픈 소스가 아니며 RD와 같은 방식으로 운영됩니다.

EC2 인스턴스는 Amazon Aurora에 직접 연결이 됩니다.

 

Aurora는 두가지의 DB 기술을 지원하며, PostgreSQL과 MySQL입니다.

Qurora는 클라우드 최적화를 목표로 하며, RDS에 비하여 MySQL에서 5배, PostgreSQL에서는 3배 성능이 더 좋습니다.

 

Aurora DB는 용량이 자동으로 확장됩니다 (10GB단위, 최대 128TB)

기본 RDS보다 약 20% 비싸지만, 더 효율적이므로 가격 대비 성능도 더 높을 것입니다.

Amazon Aurora는 프리티어에는 포함되지 않습니다만 기본 RDS는 프리티어에 포함됩니다.

 

Aurora 정리

AWS에 관계형 데이터베이스를 생성할 수 있는 두 가지 방법인데 두 개 모두 관리를 받으며, 클라우드에 최적화된 것은 Aurora입니다

반면에 RDS는 관리되는 서비스로서 이미 익숙한 기술을 직접 사용할 수 있습니다.

또한 Amazon Aurora는 서버리스라는 선택지도 있습니다 서버리스에서는 데이터베이스 인스턴스화가 자동화되며

데이터베이스의 실제 사용 정도에 기반해 자동 확장이 됩니다.

 

PostgreSQL와 MySQL 둘 다 Aurora 서버리스 데이터베이스의 엔진으로 기능할 수 있습니다/

 

용량을 사전에 계획하여 놓을 필요가 전혀 없습니다. 서버가 없으므로 관리도 할 필요가 없으며 비용은 초 단위로 계산되어

직접 Aurora 클러스터를 준비하는 것에 비하여 비용이 크게 절약될 수 있습니다.

이러한 장점들은

작업량이 간헐적으로나 가끔 발생하거나, 예상하기 어려울 때 가장 유용합니다

그러면 원리는 무엇일까요?

 

고객의 입장에서는 아주 간단합니다 Aurora에서 관리하는 프록시 플릿에 연결하면 Aurora는 보이지 않는 곳에서 규모 확장 또는 축소가 필요할 때 데이터베이스 인스턴스를 만들거나 없앱니다.

 

그리고 이 Aurora 데이터베이스들은 그 어떤 경우에도 같은 저장 공간을 공유합니다

 

만약 시험 응시 중에 Aurora에게 아무런 관리 오버헤드가 보이지 않는다면 서버리스 Aurora라고 생각하시면 됩니다.

 

NoSQL 데이터베이스 (비관계형 데이터베이스)

특정 데이터 모델이나 특정한 목적을 위해 구축되어 애플리케이션 구현을 위한 유연한 스키마를 가지고 있습니다.

유연성이 높은게 장점이고, 데이터 모델을 개선하기 쉬우며, 확장이 가능하며 분산 서버를 추가하여 스케일 아웃이 가능합니다.

관계형 데이터베이스는 서버를 추가해서 확장하기가 어려워 수직으로 확장하는 방법뿐이지만 NoSQL에서는 수평 확장이 가능합니다.

 

NoSQL 데이터베이스에서는 JSON 형식의 데이터를 사용할 수 있습니다.

JSON은 자바 스크립트 객체 표기법을 뜻하며 Excel 문서 같은 모습이 아닙니다.

위와같이 필드, 이름, 유형등이 있습니다.

 

AWS 데이터베이스의 공동 책임 모델

 

관리형 데이터베이스 사용 시 장점 :

• Quick Provisioning, High Avilability, Vertical and Horizontal Scaling
• 운영, 업그레이드, 데이터베이스 자동 백업 및 복원
• 기본 인스턴스의 운영 체제를 패치해야 하는 경우, AWS의 책임(패치 작업 전담)
• 모니터링, 알람

EC2 인스턴스에 자체적으로 데이터베이스 기술을 실행할 수도 있으나

그럴 경우에는 복원력, 백업, 패치 작업, 고가용성, 내결함성, 스케일링 등과 같은 관련된 모든 사항을 직접 처리해야한다.

 

 

RDS 에서 스냅샷에서 DB를 생성하여 더 큰 규모의 DB 생성, DB의 복사본 생성, 해당 DB의 다른 설정을 생성하기 위해서 스냅샷으로 수행할 수 있습니다. 스냅샷 복제로 다린 리전에 복사할 수 있습니다.

 

포트는 3306을 사용하여 DB 인스턴스를 연결할 수 있습니다.

 

관리형 DB는 클라우드를 이용하는 방식에 큰 차이를 만들고 인프라를 관리하는 일이 줄어들어 사용속도가 증가합니다.

 

RDS DB 배포 

 

RDS 읽기 전용 복제본을 사용하는 방식

메인 RDS DB로부터 읽기 작업을 수행하는 애플리케이션을 예로 들면 RDS 읽기 전용 DB를 복제하여 애플리케이션에서 읽을 때, 부하를 분산시킬 수 있습니다. 

데이터 쓰기 작업의 경우 오직 메인 DB에서만 이루어지므로 애플리케이션은 오직 중앙 RDS DB에서만 데이터를 기록할 수 있습니다. 

 

 

다중 가용영역을 사용하는 방식

Failover (장애조치)

 

AZ에 장애가 발생했을 때 유용하게 쓰입니다. (충돌이 발생했을 때 높은 가용성을 보장)

 

메인 RDS DB에서 읽고 쓰기 작업을 수행하며 이때, AZ를 넘나드는 복제본을 다른 가용영역에 설정합니다.

이때 복제본은 장애 조치 DB가 되는데, 다른 가용영역에 있어서 다중 AZ라고 불립니다.

 

메인 RDS DB가 충돌하면 다른 db가 대체작동합니다. 또한 단 하나의 AZ만 장애 조치 AZ로 설정할 수 있습니다.

 

다중 리전을 사용하는 방식

 

이 또한 읽기 전용 복제본을 한 리전이 아닌 여러리전에 걸쳐 복제합니다.

 

그럼 각 리전에서는 읽기 전용 복제본을 통해 로컬에서 읽을 수 있습니다.

하지만 해당 애플리케이션에 데이터를 써야 할 때는, 리전 간 쓰기 작업을 수행해야 합니다.

 

왜 다중 리전 배포를 수행할까요?

한 리전에 문제가 생겼을 때를 대비한 재해 복구 전략이 필요하기 때문에 사용합니다.

또한 서로 다른 리전에 있는 애플리케이션들이 로컬 DB로 부터 읽어 들이기 때문에 지연시간이 짧다는 장점이 있습니다.

하지만 리전 간 데이터를 복제할 때에는, 리전 간 복제된 데이터를 네트워크를 통하여 전송하는 비용이 발생합니다.

 

Amazon ElastiCashe 

일래스티 캐시를 사용하여 관리형 레디스(Redis) 또는 멤캐시트 DB를 이용해 보겠습니다.

 

이와 같은 캐시는 높은 성능과 짧은 지연 시간을 자랑하는 인 메모리 데이터베이스 입니다.

인 메모리 데이터베이스가 나온다? -> 일래스티 캐시

 

RDS DB에서 많은 쿼리 작업을 동일한 쿼리에서 진행하면 많은 부하가 발생하는데, 

캐시를 사용하면 일래스티 캐시를 통해 인 메모리 데이터베이스로 캐시가 직접 전송되도록 하여 DB의 부하를 줄일 수 있습니다.

 

이 서비스 또한 관리형 DB로 AWS가 모든 운영 체제 유지 보수와 패치 작업, 최적화 설정, 구성, 모니터링, 장애 회복 및 백업을 담당합니다

 

캐시에 대한 솔루션 아키텍쳐

 

 

ELB가 EC2 인스턴스로 갑니다, 아마 ASG일 확률이 높습니다

이때 RDS DB로부터 데이터를 읽고 쓰는데 이때 속도가 느릴 수 있습니다.

그래서 가능한 경우에 일부 값을 일래스티 캐시 DB에 캐싱 처리하게 되는데 이 작업은 인 메모리에서 이루어지므로 속도가 빠르며 일래스티 캐시를 이용하기 때분에 RDS DB의 부하를 줄일 수 있습니다.

 

DynamoDB

DynamoDB는 완전 관리형 고가용성 DB로 세 개의 가용 영역에 걸쳐 복제본을 두고 운영됩니다.

 

NoSQL 데이터베이스 이므로 비관계형 DB입니다.

AWS의 대표 상품 중 하나이며, 막대한 작업량도 소화할 수 있고, 분산된 서버리스 데이터베이스 입니다.

 

즉 RDS나 ElastiCache를 이용해서 서버에 프로비저닝을할 필요가 없습니다.

원래라면 인스턴스 유형에 프로비저닝이 필요하겠지만 DynamoDB에서는 필요가 없습니다. (서버리스)

 

DynamoDB의 장점은

초당 수백만 건의 요청, 조 단위가 넘는 행, 수백 TB의 스토리지까지 확장해도

신속하고 한결같은 성능을 보여주기 때문입니다.

따라서 검색 지연 시간이 한 자릿수 밀리초인 성능을 필요로 할 경우에는 DynamoDB가 적합한 데이터베이스 입니다.

 

시험에는 서버리스, 한 자릿수 밀리초의 지연시간 같은 저지연시간을 나타내는 키워드로 문제를 구별합니다.

 

보안, 인증, 관리상 IAM과 통합되어 있으며, 비용이 적고 오토 스케일링 기능을 갖추고 있습니다.

비용절금을 위해 Standard & IA테이블 클래스가 있습니다.

 

DynamoDB는 키/값으로 저장됩니다.

기본키가 있고, 하나 혹은 두 개의 열로 파티션 키, 정렬키로 구성되어 있습니다.

우측에 있는 속성은 사용자의 데이터에 대해 열을 임의로 정의할 수 있습니다.

모든 아이템은 행으로 저장됩니다.

 

정리하면 Dynamo DB는 NoSQL 데이트베이스로서, 데이터 검색의 지연 시간이 짧고 서버리스 데이터베이스에 대한 액세스가 가능합니다.

 

 

DynamoDB Accelerator, DAX 

DynamoDB를 위한 완전 관리형 인 메모리 캐시, ElastiCache와는 달리 DynamoDB전용 캐시입니다.

 

DAX는 오직 DynamoDB전용이고, ElastiCashe를 사용할 수 있지만, 이미 완벽히 통합된 전용 캐시를 쓰는게 성능이 10배 향상됩니다.

DynamoDB 테이블에 액세스 할 때마다 한 자릿수 밀리초 지연시간이 아니라 마이크로초 지연 시간을 볼 수 있습니다.

보안도 완벽하며 확장성과 가용성 모두 높습니다.

 

DAX = DynamoDB전용

ElastiCashe = 다른 DB에서도 캐시 저장에 사용 가능

 

DynamoDB - GlobalTables

짧은 지연 시간으로 DynamoDB 테이블에 액세스할 수 있도록 하는 기능, 여러 리전에서 사용 가능합니다.

 

버지니아와 가까이 있는 사용자는 해당 리전에서 짧은 지연 시간을 거쳐 글로벌 테이블에 액세스할 수 있고, 

파리 리전에 가까이 있는 사용자는 파리 리전의 글로벌 테이블에 액세스할 수 있습니다.

글로벌 테이블이 있는 모든 AWS 리전에서 읽기/쓰기 액세스가 가능하다는 점은, 즉 액세스한 내용이 바로 다른 리전에 복제가 된다는 뜻입니다 (액티브-액티브 복제)

 

Redshift

Redshift는 PostgreSQL 기반의 DB이며, OLTP 에는 사용되지 않습니다.

OLTP? OnLine transaction Processing

 

Redshift는 OLAP(OnLine Analytical Processing)에 특화되었습니다.

이것은 분석과 데이터 웨어하우스에 사용됩니다. 

DB의 역할이 분석과 데이터 웨어하우스다? -> Redshift

 

Redshift는 데이터를 지속적으로 로드하지않고, 1시간 등의 간격으로 로드하게 됩니다.

 

Redshift의 장점은 데이터를 분석하는 것과 계산하는 일에 매우 특화되어 있습니다.

다른 DB 웨어하우스들의 10배 성능을 자랑하며 용량은 PB단위까지 확장됩니다.

데이터는 열 저장 방식으로 저장됩니다. 행 기반에 반대되는 Coumnar(열 기반)입니다.

 

Redshift는 MPP(Massiverly Parallel Processing) 엔진이라는 것을 가지고 있어, 이러한 계산들을 빨리 할 수 있습니다.

사용자가 공급한 인스턴스에 따라 비용이 청구되며, 조회는 SQL 인터페이스를 통하여 합니다.

 

BI(Business Intelligence)도구 들과 통합되어 있습니다.

-> 데이터 웨어하우스에 대시보드를 생성하고자 할 때 유용합니다.

 

데이터 웨어하우스는 data set에 대하여 계산과 분석 및 시각화를 대시보드를 통하여 실행하는 데 사용됩니다.

 

Redshift Serverless

이것을 사용하면 Redshift를 실행하면서도 데이터 창고의 크기 조정 또는 공급을 걱정할 필요가 없습니다.

AWS에서 대신 해 줄 것입니다 이름에 Serverless(서버리스)가 붙은 이유입니다.

 

분석 작업만을 실행하고 데이터 창고의 기반은 관리하지 않는다는 발상으로, 그래서 매우 편리합니다.

그리고 사용한 양만큼만 돈이 청구되기 때문에 비용도 절약할 수 있습니다.

그러므로 적절한 사용 예는 보고서 작성, 대시보드 애플리케이션 또는 실시간 분석 등입니다

 

비용은 분석 중인 작업량과 사용된 저장 공간에 대해서만 청구되어 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 엔진을 이용해 구축되었습니다

작동 원리를 보면 사용자가 Amazon S3에 데이터를 로드하면 Amazon Athena가 이에 대해 쿼리 작업을 수행하고 데이터를 분석하는 간단한 원리입니다

 

원하는 경우 Athena에 대한 보고를 살펴볼 수 있는데, 이 경우에는 Amazon QuickSight를 이용합니다.

Athena는 스캔 된 데이터 TB당 5달러로 책정되어 있습니다 압축된 데이터나 열 형식으로 저장된 데이터를 다룰 때에는

데이터 스캔을 줄일 수 있으므로 비용을 절감할 수 있습니다.

 

Athena는 다양한 경우에 활용되는데 비즈니스 인텔리전스나 분석, 보고 또는 VPC 흐름 로그나 ELB 로그 Cloudtail 로그플랫폼 로그 등 모든 AWS 로그의 분석 시에 Athena를 이용하면 좋습니다.

시험에서는 서버리스 SQL을 이용하여 S3 내 데이터를 분석한다고 하면 Amazon Athena를 바로 떠올리면 되겠습니다

 Amazon QuickSight

이는 서버리스 머신 러닝 방식의 비즈니스 인텔리전스 서비스로 대화형 대시보드를 생성합니다.

말은 복잡하지만 Amazon QuickSight에서 기억할 점은 데이터베이스에 대시보드를 만들어서 데이터를 시각적으로 나타내고 비즈니스 사용자가 원하는 인사이트를 보여 준다는 것입니다.

 

QuickSight를 이용하면 이처럼 멋진 그래프나 도표를 생성할 수 있습니다 속도도 빠르고 자동으로 확장되며 내장 설정이 가능하며 세션별로 가격을 책정하여 서버를 프로비저닝할 필요가 없습니다.

QuickSight는 비즈니스 분석이나 시각화를 구축하거나 임시 분석을 수행할 때 데이터를 이용한 비즈니스 인사이트 도출 시에 활용합니다 .

QuickSight는 RDS 데이터베이스나 Aurora, Athena, Redshift, Amazon S3 등의 기반에서도 작동합니다

QuickSight는 AWS에서 DI를 위한 도구라고 할 수 있겠습니다

 

DocumentDB

DocumentDB는 MongoDB의 Aurora 버전과 다름 없습니다.

 

MongoDB는, 또 하나의 NoSQL 데이터베이스이며 이것은 시험을 위해 기억하셔야 합니다.

DocumentDB는 NoSQL 데이터베이스이고 MongoDB 기술에 기반해있습니다. MongoDB와 호환 가능한 것입니다

MongoDB는 JSON 데이터를 저장, 쿼리, 인덱스하기 위해 사용되며 Aurora와 비슷한 배포 개념을 DocumentDB와 가집니다. 즉, 완전히 관리되는 데이터베이스이고 유용성 높으며 데이터는 세 개의 가용 영역에 걸쳐 복제되며 DocumentDB 스토리지는 자동적으로 10 GB까지 확장합니다.

DocumentDB는 초당 수백만개의 요청을 작업할 수 있도록 확장되도록 설계되어있습니다.

시험을 볼 때 MongoDB에 관련된 것을 보신다면 DocumentDB나 NoSQL 데이터베이스에 관련된 것을 생각하시면 됩니다.

 

Amazon Neptune

Neptune은 완전 관리형 그래프 데이터베이스입니다.

 

그래프 데이터셋의 예로는 우리 모두 익히 알고 있는 소셜 네트워크를 들 수 있겠습니다.

소셜 네트워크에서는 사람들이 친구로 연결되고 서로 코멘트를 남길 수도 있으며 사용자가 친구를 갖고 게시물에 코멘트를 남기며 코멘트나 게시물에 사용자가 좋아요를 누르거나 이를 공유하는 등 이 모든 것들이 연결되어 있으니 하나의 그래프를 생성할 수 있는 겁니다.

이것이 바로 Neptune이 그래프 데이터셋에 가장 적합한 이유입니다.

Neptune은 세 개의 AZ에 최대 15개 읽기 전용 복제본을 가질 수 있고 소셜 네트워크와 같이 고도로 연결된 데이터셋을 다루는 애플리케이션을 구축 및 실행할 때 사용됩니다.

Neptune은 이처럼 그래프 데이터셋에 복잡하고 어려운 쿼리를 실행하는 데에 최적화되어 있기 때문이죠

최대 수십억 개의 관계를 데이터베이스에 저장할 수 있으며 밀리초를 자랑하는 지연 시간 안에 그래프를 쿼리할 수 있습니다.

애플리케이션 가용성을 다중 가용 영역에 걸쳐 지원하고 있으며 지식 그래프를 저장할 때 그 활용도가 뛰어납니다.

위키피디아 데이터베이스를 지식 그래프의 예로 들 수 있는데 위키피디아 문서는 모두 상호 연결되어 있기 때문입니다.

사기 탐지, 추천 엔진 그리고 소셜 네트워크에서도 활용되죠

시험에서 그래프 데이터베이스와 관련된 내용이 나오면 주저 말고 Neptune을 답으로 고르면 되겠습니다

 

Amazon timestream

이름으로부터 알 수 있듯이, time series(시계열)을 위한 서비스입니다

 

즉, time series(시계열) 데이터를 저장하고, 완전한 관리를 받으며 빠르고, 규모 조정이 가능한 서버리스인 데이터베이스입니다.

그런데 time series(시계열) 데이터는 무엇일까요?

시간에 따라 계속적으로 변화하는 데이터입니다

예를 들어 이 그래프의 세로축에는 숫자 가로축에는 연도가 표시되며 연도는 옛날부터 점점 최근으로 변화합니다.

그러므로 연도가 시간에 따라 변하고 이 그래프의 데이터는 time series data set(시계열 데이터 세트)가 되는 것입니다.

Timestream은 이러한 데이터에 사용됩니다.

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를 반드시 떠올리시기 바랍니다

 

DMS - Database Migration Service

데이터의 마이그레이션 방법을 볼 차례입니다.

 

이를 위해 DMS, 즉 데이터베이스 마이그레이션 서비스를 사용할 수 있습니다.

먼저 소스 데이터베이스에서 데이터를 추출하기 위해 DMS 소프트웨어를 실행하는 EC2 인스턴스를 실행한 다음

소스 데이터베이스로부터 데이터를 추출하면 DMS가 다시 해당 데이터를 다른 위치에 있는 대상 데이터베이스로 입력합니다.

 

따라서 DMS를 이용하면 데이터베이스를 AWS로 신속하고 빠르게 마이그레이션하여 복원과 자가 복구를 수행할 수 있습니다.

 

 

또 다른 이점으로 마이그레이션 작업 동안에도 소스 데이터베이스를 사용할 수 있으므로 중단할 필요가 없습니다.

여러 마이그레이션을 지원하는데 그 중 하나는 동종 마이그레이션으로 Oracle 간 마이그레이션에 사용됩니다.

소스와 대상 데이터베이스가 동일한 데이터베이스 기술을 사용할 때에 해당되죠

 

이기종 마이그레이션도 지원하는데 이는 소스와 대상 데이터베이스가 서로 다른 데이터베이스 기술을 이용할 때

가령 Microsoft SQL Server에서 오로라로 마이그레이션일 때 DMS가 소스에서 대상으로 데이터를 변환하는 작업을 수행해 줍니다.

시험에서 데이터베이스 마이그레이션 내용이 나올 때면 DMS가 해답이라고 알면 되겠습니다

 

AWS Glue

Glue는 관리형 추출, 변환 및 로드 서비스로 줄여 말하면 ETL 서비스가 되는데 시험에서는 이 정도만 알면 됩니다만

좀 더 깊이 들어가서 작동 원리를 알아보도록 하겠습니다

ETL이 정확히 무엇일까요? ETL은 데이터셋에 대한 분석을 수행할 때에 그 형식이 올바르지 않거나 원하는 형식이 아닐 때에 유용하게 쓰입니다.

ETL 서비스를 통해서 데이터를 준비하고 변환할 수 있는 거죠 기존에는 서버를 사용하여 해당 작업을 수행하지만

완전 서버리스 서비스인 Glue를 통해서도 할 수 있습니다.

실제 데이터 변환에만 신경 쓰고 나머지는 Glue에게 맡기면 되죠

 

 

그림으로 살펴보면 Glue ETL을 가운데 두고서 S3 버킷과 Amazon RDS 데이터베이스 모두에서 데이터를 추출하고자 한다고 해 봅시다.

두 소스에 대한 데이터 추출을 위해 Glue를 사용해 볼 텐데 데이터가 추출되고 나면 Glue 서비스에서 스크립트를 작성하고 변환 단계로 넘어갑니다.

 

Glue가 데이터를 변환해 주면 이제 변환된 데이터를 분석할 차례입니다.

이를 위해 예를 들어서 해당 데이터를 Amazon Redshift DB에 로드한다고 하면 분석이 바로 수행되겠죠

Glue가 가운데에서 이를 지휘하는 거죠 Glue는 아주 강력한 도구로 모든 변환이 가능하며

이를 어떤 장소에든 로드할 수 있습니다

Glue ETL를 살펴봤는데 여기에 또 다른 서비스인 Glue Data Catalog가 있는데 시험에 출제되지는 않겠지만

Glue 제품군의 일부로서 알아 두는 것이 좋으니 살펴보도록 하죠

 

Glue Data Catalog는 이름에서 알 수 있듯이 AWS 인프라 내 데이터셋의 카탈로그를 제공합니다.

Glue Data Catalog에는 열 이름, 필드 이름, 필드 유형 등 모든 항목에 대한 참조가 있습니다

 

그리고 이 서비스는 Athena 레드시프트, EMR 등의 서버에서 데이터셋을 검색하고 이에 적합한 스키마를 구축할 때에 쓰일 수 있습니다.

 

AWS 데이터베이스와 분석 요약

어떤 DB가 어느 상황에 대응되는지 알아야 할 것

Relational Database에다가 OLTP, 즉 online transaction process(온라인 트랜잭션 처리)가 있다면

RDS와 Aurora를 떠올리셔야 합니다

 

이 두 가지 데이터베이스 모두 데이터 조회에 SQL 언어를 지원합니다

또한 RDS에 대해서는 Multi-AZ, 읽기 전용 복제본, 그리고 다중 리전 간의

차이를 이해하고 각각의 이용 사례 역시 알고 있어야 합니다

 

인 메모리 데이터베이스 또는 인 메모리 캐시를 찾아야 할 때는 ElastiCache,

키-값 데이터베이스를 찾고 있다면 서버리스 데이터베이스인 DynamoDB를 떠올리시고

 

DynamoDB를 위한 캐시 기술이 필요하다면 DAX 기술을 사용하여야 합니다.

DynamoDB만을 위하여 만들어진 캐시입니다

 

웹 데이터 창고 또는 OLAP(온라인 분석 처리) 할 방법을 찾아야 한다면,

데이터 웨어하우스 기술인 Redshift를 생각하셔야 합니다

또한 Redshift에 있는 데이터는 SQL 언어로 조회할 수 있습니다

 

빅데이터 분석을 위하여 Hadoop 클러스터를 구축할 때는 EMR 서비스가 사용됩니다

Amazon S3의 데이터를 서버리스 방식으로 SQL 언어를 사용하여 조회할 때는 Athena를 사용합니다.

 

QuickSight는 상호작용 가능한 시각 요소를 가진 대시보드 등을 생성할 수 있습니다.

데이터와의 서버리스 상호작용 역시 가능합니다그런 것이 필요할 떄는 비즈니스 인텔리전스에도 사용되는 Amazon QuickSight를 이용해야 합니다

 

DocumentDB는 "MongoDB의 Aurora"라고 부를 수 있습니다.

그러므로 MongoDB가 보일 때마다 DocumentDB를 떠올리시면 되며

DocumentDB는 JSON 유형의 데이터세트를 사용합니다.

또한 이것은 NoSQL 데이터베이스이기도 합니다 즉 DynamoDB 외의 또 다른 NoSQL 데이터베이스가 되겠습니다.

 

그 다음에는 금융 거래 장부인 Amazon QLDB가 있습니다

금융 거래, 변경 불가능한 저널 또는

암호 기법으로 인증 가능한 것이 보이면 Amazon QLDB를 생각하십시오

Amazon QLDB는 중앙 데이터베이스인데,이와 반대로 분산 데이터베이스로

Amazon Managed Blockchain이 있습니다

이것을 이용하여 Hyperledger Fabric과 Etherium 블록체인을 AWS 상에서 관리 받도록 할 수 있습니다

 

마지막으로, 관리형 ETL(Extract, Transform, Load, 추출 변환 로드) 도구가 필요하다면

Glue를 이용하면 되며, Glue는 데이터 카탈로그 서비스도 있어

AWS에 있는 데이터베이스들로부터 data set(데이터 세트)를 찾아낼 수 있습니다

데이터베이스 간에 데이터를 옮겨야 한다면 데이터 이전 서비스인 DMS를 이용하고

 

그래프 데이터베이스가 필요하다면 Neptune을 사용하여야 합니다

 

그리고 time series(시계열) 데이터베이스를 사용하고자 한다면 Amazon Timestream이 필요합니다