데이터베이스 소개
데이터를 구조에 따라 저장하고자 할 때 데이터베이스를 이용하게 된다. 이때 이 구조를 통해 효과적인 쿼리와 데이터 검색을 위한 인덱스를 구축할 수 있다. 시험에는 질문에 나온 사례로 어떤 데이터베이스가 가장 적합할 지 판단하는 문제가 나온다.
관계형 데이터베이스
오늘날까지 흔히 보이는 관계형 데이터베이스이다. Excel과 비슷하게 생겼지만 관계형 데이터베이스에서는 (외래키를 통한) 각 테이블의 연결 고리를 볼 수 있다.
관계형 데이터베이스에서는 SQL 언어를 사용하여 쿼리가 가능하다.
비관계형 데이터베이스
NoSQL이라고도 불리는 비관계형 데이터베이스는 좀 더 현대식의 데이터베이스로 특정 데이터 모델을 염두에 두고 특정한 목적을 위해 구축되어 현재 애플리케이션 구현을 위해 유연한 데이터의 모양을 가지고 있다.
비관계형 데이터베이스는 유연성이 높다는 장점으로 데이터 모델을 개선하기 쉽고, 확장이 가능하여 분산 서버를 추가하면 스케일 아웃이 가능하도록 설계되었다. 즉, 수평 확장이 가능하다. 또한 고성능을 자랑하며 특정 데이터 모델에 최적화 되어 있다. 고기능으로 해당 모델에 대해 최적화된 유형이다.
예시로 키-값 데이터베이스, 문서, 그래프, 인메모리, 검색 데이터베이스를 들 수 있다.
데이터베이스 공동 책임 모델
- AWS를 통해서 여러 데이터베이스를 관리할 수 있다.
- 얻는 이점들은 다음과 같다.
- 빠른 프로비저닝이 가능하고, 높은 가용성과, 수직/수평 스케일링을 쉽게 할 수 있다.
- 운영 및 업그레이드뿐만 아니라 데이터베이스 자동 백업 및 복원을 수행하는 일부 유틸리티도 포함된다.
- 기본 인스턴스의 운영 체제를 패치해야 하는 경우 이는 사용자의 책임이 아닌 AWS의 책임이다.
- 모니터링과 알림 또한 통합된다.
EC2 인스턴스에 자체적으로 데이터베이스를 놓을 순 있지만 이 경우 복원, 백업, 패치 등 관련된 모든 사항을 직접 처리해야 한다.
RDS & Aurora 개요
RDS - Relational Database Service
RDS는 관계형 데이터베이스 서비스를 의미하고, SQL 언어를 사용한다. 따라서 SQL을 쿼리 언어로 사용하는 데이터베이스를 위한 관리형 데이터베이스 서비스이다.
이를 통해 AWS에서 관리할 데이터베이스를 클라우드에 생성할 수 있으며, 여기엔 다음과 같이 다양한 종류가 있다.
- Postgres
- MySQL
- MariaDB
- Oracle
- Microsoft SQL Server
- IBM DB2
- Aurora (AWS 독점 데이터베이스)
RDS를 사용하는 이유
- RDS는 관리형 데이터베이스 서비스로써 다음과 같은 이점을 갖는다
- 데이터베이스 배정이 자동으로 이뤄진다.
- AWS가 운영 체제 패치를 수행한다.
- 특정 시점 복원이 가능하다.
- 모니터링 대시보드를 갖게 된다.
- 읽기 복제본을 생성하여 읽기 규모를 확장하고 읽기 성능을 향상시킬 수 있다.
- 재해 복구 계획으로써 다중 가용 영역을 설정하는 방법을 갖게 된다.
- 업그레이드를 위한 유지 관리 창구를 설정한다.
- 수직 및 수평으로 확장할 수 있다.
- 스토리지는 EBS를 활용한다.
AWS가 사용자를 위해 데이터베이스 전체를 관리해준다. 하지만 RDS 인스턴스에 SSH를 통해 연결할 수 없다. 즉, SSH 유틸리티를 사용하여 데이터베이스에서 무슨 일이 일어나고 있는지 확인할 수 없다.
Amazon Aurora
Aurora는 AWS가 만든 데이터베이스 기술로 오픈 소스가 아니며 RDS와 동일한 방식으로 작동되고, Postgres와 MySQL을 지원한다.
Aurora는 AWS 클라우드에 최적화되어 있으며, RDS 상의 MySQL보다 5배, Postgres보다 3배 이상 성이 향상된다고 말한다. 그리고 스토리지가 10GB 단위로 최대 128TB까지 자동으로 증가하기 때문에 스토리지에 대해 걱정할 필요가 없다.
따라서 Aurora가 RDS보다 20% 더 비싸지만 더 효율적이기 때문에 비용적인 측면에서도 더 효율적일 것이다. 추가적으로 RDS는 프리 티어에 포함되지만 Aurora는 프리 티어에 포함되지 않는다.
시험 관점에서 RDS와 Aurora
시험 관점에서 RDS와 Aurora는 AWS에서 관계형 데이터베이스를 생성하는 두 가지 방법이 될 것이다. 둘 다 관리형이지만 Aurora는 보다 클라우드 기반이 될 것이고, RDS는 관리형 서비스로서 직접 기술을 실행할 것이다.
Amazon Aurora Serverless
Amazon Aurora를 위한 서버리스 옵션도 있다. 여기서 데이터베이스 인스턴스가 자동화된다. 데이터베이스의 실제 사용량을 기반으로 한 자동 확장 기능도 있다. Postgres와 MySQL 모두 지원된다.
사용자가 서버를 관리하지 않기 때문에 어떤 종류의 용량 계획도 구상할 필요 없고, 초당 비용을 지불하게 된다. 따라서 Aurora 클러스터를 직접 배정하는 것보다 더 비용 효율적일 수도 있다.
만약 사용자의 작업 부하가 드물거나 간헐적이며 예측할 수 없는 경우 유용하다. 작동 방식은 Aurora가 관리하는 프록시 플릿을 통해 클라이언트와 연결된다. 백엔드에서는 필요에 따라 Aurora 인스턴스가 자동으로 생성되고, 이 인스턴스들은 서버리스 방식으로 동작하여 워크로드에 맞게 확장/축소된다. 그리고 이러한 Aurora 데이터베이스는 무슨 일이 있어도 동일한 스토리지 크기를 공유하게 된다.
따라서 관리 오버헤드가 없는 Aurora라는 표현을 보면 Aurora Serverless를 떠올리면 된다.
RDS 배포 옵션
다양한 배포 옵션을 통해 RDS 데이터베이스를 배포할 수 있다. 그것들 중 사용자가 직접 선택해야 한다.
읽기 전용 복제본
메인 RDS 데이터베이스로부터 읽기 작업을 수행하는 애플리케이션의 경우 더 많은 애플리케이션이 RDS로부터 더 많은 데이터를 읽어 들여야 하기 때문에 읽기 워크로드를 확장해야 한다. 이때 읽기 전용 복제본을 생성해서 이를 해결할 수 있다.
읽기 전용 복제본은 RDS 데이터베이스의 복제본이 생성된다는 뜻이다. 또한 이로써 애플리케이션이 해당 읽기 전용 복제본으로부터 읽기 작업을 할 수 있다는 의미가 된다. 따라서 이 읽기 권한을 여러 RDS 데이터베이스에 분산시키게 된다.
최대 5개의 읽기 전용 복제본을 생성할 수 있으며, 쓰기 작업의 경우 오직 메인 데이터베이스에서만 이뤄지므로 애플리케이션은 오직 메인 RDS 한 곳에서만 데이터를 기록할 수 있다.
다중 가용 영역
다중 가용 영역의 경우 가용 영역 운영 정지와 같은 장애 조치가 발생했을 때 유용하게 사용된다. 가용 영역에서 문제가 발생했을 때 높은 가용성을 보장해 준다.
메인 RDS에서 읽고 쓰기 작업을 수행하고, 가용 영역을 넘나드는 복제본을 다른 가용 영역에 설정하고자 할 때, 해당 복제본은 장애 조치 데이터베이스가 되고 다른 가용 영역에 존재하기 때문에 다중 가용 영역이라고 불린다.
모종의 이유로 메인 RDS에 문제가 생겼을 경우 RDS에서 장애 조치가 트리거된다. 이때 애플리케이션은 다른 가용 영역의 개발자 데이터베이스에서 장애 조치를 실시한다. 따라서 다중 가용 영역의 경우 데이터는 메인 데이터베이스에서만 읽고 쓸 수 있으며, 장애 조치 데이터베이스는 수동적 데이터베이스로 메인 데이터베이스에 문제가 발생하기 전까지는 액세스할 수 없다.
마지막으로 단 하나의 가용 영역만 장애 조치 가용 영역으로 설정할 수 있다.
다중 리전
다중 리전 또한 읽기 전용 복제본을 다루지만, 한 개의 리전이 아닌 여러 리전을 걸치게 된다.
예시로 eu-west-1 에 RDS가 있고, eu-east-2 에 읽기 전용 복제본을 생성했을 경우 us-east-2 에 있는 애플리케이션을 읽기 전용 복제본을 통해 로컬에서 읽을 수 있다. 하지만 해당 애플리케이션에 데이터 쓰기 작업을 할 경우 리전 간 쓰기 작업을 수행해야 한다. 즉, eu-west-1 에서 데이터를 써야 한다.
다중 리전을 사용하는 이유는 다음과 같다.
- 한 리전에 문제가 생겼을 때를 대비한 재해 복구 전략이 필요하기 때문이다.
- 서로 다른 리전에 있는 애플리케이션도 로컬 데이터베이스로부터 읽어 들이기 때문에 지연 시간이 짧기 때문이다.
리전 간 데이터를 복제할 때는 리전 간 복제된 데이터를 네트워크를 통해 전송하는 비용이 발생한다.
ElastiCache
ElastiCache를 사용하여 관리형 Redis 또는 Memcached를 이용할 수 있다. 이와 같은 캐시는 높은 성능과 짧은 지연 시간을 자랑하는 인 메모리 데이터베이스이며, 시험에서 인 메모리 데이터베이스가 나올 경우 바로 일래스티 캐시를 떠올려야 한다.
ElastiCache는 읽기 집중적인 워크로드의 데이터베이스로부터 워크로드를 줄일 때 사용된다. RDS에서는 많은 쿼리 작업을 수행하는데 이때 항상 동일한 쿼리가 매번 수행되게 될 경우 RDS에 막대한 부하가 걸리게 된다.
대신에 캐시를 사용하게 되면 ElastiCache를 통해 인 메모리 데이터베이스로 캐시가 직접 전송되도록 하여 RDS의 부하를 줄일 수 있다. 즉, ElastiCache를 이용하는 목적은 RDS의 부하를 줄이고 이를 ElastiCache와 나눠 처리하며, 작업이 인 메모리에서 이뤄지기 때문에 속도가 빠르기 때문이다. 또한 쿼리를 따로 저장하여 언제든 사용할 수 있고, 액세스도 쉬워진다.
또한 ElastiCache는 관리형 데이터베이스로 AWS가 모든 운영체제의 유지 보수와 패치 작업, 최적화 설정, 구성, 모니터링, 장애 회복 및 백업을 담당한다.
DynamoDB
DynamoDB는 완전 관리형 고가용성 데이터베이스로 세 개의 가용 영역에 걸쳐 복제본을 두고 운영된다. 비관계형 데이터베이스이며 AWS의 대표 상품 중 하나이다.
DynamoDB는 막대한 작업량도 소화할 수 있고, 분산된 서버리스 데이터베이스이기 때문에 RDS나 ElastiCache를 이용해서 서버에 프로비저닝할 필요가 없다.
DynamoDB는 초당 수백만 건의 요청, 조 단위가 넘는 행, 수백 테라바이트 스토리지까지 확장해도 신속하고 한결같은 성능을 보여준다. 따라서 검색 지연 시간이 한 자릿수 밀리초인 성능을 필요로 할 경우 DynamoDB가 적합한 데이터베이스일 것이다. 또한 보안, 인증, 관리가 IAM과 통합되어 있으며 비용이 적고 오토 스케일링 기능을 갖추고 있다.
마지막으로 비용 절감을 위해 데이터를 분류하는 방식에 따른 Standard & Infrequent Access (IA) 테이블 클래스가 있다.
시험에서는 서버리스라는 키워드나 한 자릿수 밀리초의 지연 시간과 같은 저지연 시간을 나타내는 키워드를 찾아보면 된다.
DynamoDB 데이터 타입
DynamoDB는
key-value데이터베이스로 데이터는 기본 키(파티션 키 + 정렬 키)와 속성으로 나뉘며, 모든 아이템은 행으로 저장된다.
DynamoDB Accelerator - DAX
DAX는 DynamoDB를 위한 완전 관리형 인 메모리 캐시이다. ElastiCache와는 다르게 DynamoDB 전용 캐시이며 애플리케이션이 DynamoDB 속 DynamoDB 테이블에 액세스하려고 할 때 가장 최근에 읽힌 객체를 캐시에 저장하려면 DAX를 캐시로 사용해야 한다.
DAX는 오직 DynamoDB 전용으로 ElastiCache를 이용할 수는 있지만, 완벽히 통합된 DAX를 사용하는 것이 낫다. DynamoDB 테이블에 액세스할 때마다 마이크로초 지연 시간을 볼 수 있을 것이며 보안도 완벽하고, 확장성과 가용성 모두 높다.
ElastiCache와의 차이점으로는 ElastiCache는 다른 데이터베이스에서도 캐시 저장에 사용할 수 있지만, DAX는 DynamoDB와 완벽히 통합되어 있어 DynamoDB에서만 사용한다.
DynamoDB 글로벌 테이블
DynamoDB 글로벌 테이블은 DynamoDB의 테이블을 여러 리전에 복제하여 운영할 수 있게 하는 서비스이다. 애플리케이션은 데이터베이스에 접근할 때, 자동으로 지리적으로 가까운 리전에 복제된 DynamoDB 테이블에 접근되도록 한다.
원하는 경우 10개의 리전에 대해서도 설정이 가능하며, 사용자들이 해당 테이블이 있는 모든 리전에서 이 두 테이블의 복제본에 대한 읽기/쓰기 작업을 할 수 있다.
해당 글로벌 테이블이 있는 모든 AWS 리전에서 읽기/쓰기 액세스가 가능하다는 점은 곧 액티브-액티브 복제라는 뜻이 된다. 즉, 어느 리전이든 직접 쓰고 해당 내용은 바로 다른 리전에 복제된다는 의미를 나타낸다.
Redshift
Redshift는 PostgreSQL 기반의 데이터베이스이지만 OLTP(OnLine Transaction Processing)에는 사용되지 않고, OLTP(OnLine Analytical Processing)에 특화되어 있다. Redshift를 이용하면 데이터를 지속적으로 로드하지 않고 1시간 등의 간격으로 로드하게 된다.
Redshift의 장점은 데이터를 분석하는 것과 계산하는 일에 매우 특화되어 있다. 다른 데이터 웨어하우스들의 10배의 성능을 자랑하며 용량은 PB 단위까지 확장된다. 데이터는 열 저장 방식으로 저장되기 때문에 행 기반에 반대되는 열 기반 스토리지로 불려진다. 또한 Redshift MPP(Massively Parallel Processing) 엔진이라는 것을 가지고 있어 계산을 빨리 해낼 수 있다.
사용자가 공급한 인스턴스에 따라 비용이 청구되며 조회는 SQL 인터페이스를 통해서 한다. Bussiness Intelligence(BI) 도구(QuickSight, Tableau)와 통합되어 있다. 그래서 데이터 웨어하우스에 대시보드를 생성하고자 할 때 유용하다.
데이터 웨어하우스는 데이터 셋에 대한 계산과 분석 및 시각화를 대시보드를 통해 실행하는 데 사용된다. 이런 용도를 위해선 Redshift가 최적이다.
Redshift Serverless
Redshift Serverless를 사용하면 Redshift를 실행하면서도 데이터 창고의 크기 조정 또는 공급을 걱정할 필요가 없다. AWS에서 대신 해 줄 것이다.
분석 작업만을 실행하고 데이터 창고의 기반은 관리하지 않기 때문에 매우 편리하다. 그리고 사용한 만큼만 돈이 청구되기 때문에 비용도 절약할 수 있다. 그러므로 보고서 작성, 대시보드 애플리케이션 또는 실시간 분석에 어울린다.
사용자의 계정에서 Amazon Redshift Serverless를 활성화하고 Redshift Query Editor 또는 다른 도구를 이용하여 쿼리를 작성하면 Redshift Serverless는 자동으로 조회를 시작하며 쿼리와 작업량에 따라 알아서 저장 공간을 제공하고 크기를 조정할 것이다. 근본적인 용량과 Redshift Serverless 데이터베이스의 기반을 관리할 필요가 없게 되는 것이다.
마지막으로 비용은 분석 중인 작업량과 사용된 저장 공간에 대해서만 청구되기 때문에 Redshift를 운영하는 아주 가성비 좋은 방법이다.
Amazon EMR
EMR은 Elastic MapReduce를 나타낸다. 즉, 실제 데이터베이스가 아니라 AWS에서 빅 데이터를 작업하고자 할 때 사용하는 Hadoop 클러스터를 생성한다.
이때 Hadoop 클러스터는 방대한 양의 데이터를 분석하고 처리하는 데 이용되는 오픈 소스 기술로 클러스터에서 작동하는 여러 서버를 통해 데이터를 함께 분석할 수 있다.
따라서 EMR을 사용하면 수백 개의 EC2 인스턴스로 구성된 클러스터를 생성하여 데이터 분석을 위해 동시에 사용할 수 있다. Hadoop 생태계(=빅 데이터 생태계) 에는 Apache Spark, HBase Presto, Flink 등 다양한 프로젝트가 있는데 이들 모두 Hadoop 클러스터를 이용해서 작업한다.
EMR은 모든 EC2 인스턴스의 프로비저닝과 구성을 담당하며 이들 모두 원활히 작동하여 빅 데이터 관점에서 데이터를 분석할 수 있도록 지원한다. 또한 오토 스케일링이 가능하고 스팟 인스턴스와 통합된다. EMR은 데이터 처리와 머신 러닝 웹 인덱싱 또는 일반적으로 빅 데이터에 대해 사용할 수 있다.
시험에 Hadoop 클러스터가 나온다면 Amazon EMR을 선택하면 된다.
Amazon Athena
Athena는 서버리스 쿼리 서비스로 S3 저장된 객체에 대한 분석을 수행한다. 따라서 SQL 쿼리 언어를 통해 해당 파일을 생성하면 이들을 따로 로드할 필요 없이 S3에 그대로 두면 Athena가 분석을 수행하는 것이다. CSV, JSON, ORC Avro, Parquet 등 파일의 형식은 다양할 수 있다. 참고로 Athena는 Presto 엔진을 이용해 구축되었다.
Athena의 비용은 스캔된 데이터 TB당 5달러로 책정되어 있다. 압축된 데이터나 열 형식으로 저장된 데이터를 다룰 때에는 데이터 스캔을 줄일 수 있으므로 비용을 절감할 수 있다. 이러한 Athena는 비즈니스 인텔리전스(BI)나 분석, 보고 또는 VPC 흐름 로그나 ELB 로그, Cloudtail 로그, 플랫폼 로그 등 모든 AWS 로그 분석 시에 사용된다.
시험에서는 서버리스 SQL을 이용하여 S3 내의 데이터를 분석한다고 하면 Amazon Athena를 바로 떠올리면 된다.
작동 원리
- 사용자가 S3에 데이터를 로드
- Athena가 쿼리 작업 수행하고 데이터를 분석
- 원하는 경우 Athena에 대한 보고를 Amazon QuickSight를 통해 살펴볼 수 있다
Amazon QuickSight
QuickSight는 서버리스 머신 러닝 방식의 비즈니스 인텔리전스 서비스로 대화형 대시보드를 생성한다. QuickSight에서 기억할 점은 데이터베이스에 대시보드를 만들어서 데이터를 시각적으로 나타내고 비즈니스 사용자가 원하는 인사이트를 보여 준다는 것이다.
QuickSight를 이용하면 위와 같은 그래프나 도표를 생성할 수 있다. 속도가 빠르고 자동으로 확장되며 내장 설정이 가능하며 세션별로 가격을 책정하여 서버를 프로비저닝할 필요가 없다.
QuickSight는 RDS 데이터베이스나 Aurora, Athena, Redshift, Amazon S3 등의 기반에서도 작동하며 비즈니스 분석이나 시각화 구축, 임시 분석을 수행할 때, 데이터를 이용한 비즈니스 인사이트 도출 시에 활용한다.
DocumentDB
DocumentDB는 MongoDB의 Aurora 버전과 다름 없다. MongoDB는 비관계형 데이터베이스의 한 종류이다.
DocumentDB는 비관계형 데이터베이스이고 MongoDB 기술에 기반해있기 때문에 호환 가능하다. MongoDB는 JSON 데이터를 저장, 쿼리, 인덱스하기 위해 사용되며 Aurora와 비슷한 배포 개념을 가진다.
완전히 관리되는 고가용성의 데이터베이스이고, 데이터는 3개의 가용 영역에 걸쳐 복제되며 스토리지는 10GB 단위로 자동 확장한다. DocumentDB는 초당 수백만 개의 요청을 작업할 수 있게 확장되도록 설계되어 있다.
시험에서 MongoDB에 관련된 것을 본다면 DocumentDB나 NoSQL 데이터베이스에 관련된 것을 생각하면 된다.
Amazon Neptune
Neptune은 완전 관리형 그래프 데이터베이스이다. 그래프 데이터 셋의 예시로는 소셜 네트워크를 들 수 있다.
Neptune은 3개의 가용 영역에 최대 15개 읽기 전용 복제본을 가질 수 있고, 소셜 네트워크와 같이 고도로 연결된 데이터 셋을 다루는 애플리케이션을 구축 및 실행할 때 사용된다.
Neptune은 이처럼 그래프 데이터 셋에 복잡하고 어려운 쿼리를 실행하는 것에 최적화되어 있다. 최대 수십억 개의 관계를 데이터베이스에 저장할 수 있으며 밀리초 안에 그래프를 쿼리할 수 있다.
애플리케이션 가용성을 다중 가용 영역에 걸쳐 지원하고 있으며 지식 그래프를 저장할 때 그 활용도가 뛰어나다. 사기 탐지, 추천 엔진 그리고 소셜 네트워크에서도 활용된다.
시험에서 그래프 데이터베이스와 관련된 내용이 나오면 Neptune을 답으로 고르면 된다.
Amazon Timestream
Timestream은 이름에서부터 알 수 있듯이, 시계열(time series)을 위한 서비스이다. 즉, 시계열 데이터를 저장하고, 완전한 관리를 받으며 빠르고, 규모 조정이 가능한 서버리스 데이터베이스이다. 여기서 시계열이란 시간에 따라 계속적으로 변화하는 데이터이다.
Timestream은 데이터 용량과 요구되는 계산량에 따라 자동으로 크기가 조정된다. 시계열의 형태로 하루의 수조 개의 이벤트를 저장하고 분석할 수 있다. 관계형 데이터베이스에 비해 1000배 빠르지만 비용은 1/10이다.
실시간으로 시계열 데이터를 분석하고자 한다면 시계열 분석 기능을 통해 데이터베이스로부터 패턴을 찾아낼 수 있다. 그러므로 시험에 시계열 데이터가 등장할 때마다 Amazon Timestream을 떠올리면 된다.
Amazon QLDB
QLDB는 Quantum Ledger Database의 약자로 금융 거래를 기록하는 장부의 역할을 한다.
완전 관리형 데이터베이스로 서버리스에 고가용성이며, 3개의 가용 영역에 걸쳐 데이터의 복제본을 갖는다. 또한 시간이 지남에 따라 발생한 애플리케이션 데이터의 모든 변경 내역을 살펴볼 때 사용하므로 Ledger(원장, 장부)라는 이름이 붙었다.
변경이 불가능한 시스템이기 때문에 데이터베이스에 작성하고 나면 그후 삭제하거나 수정할 수 없다. 또한 삭제된 사항이 없음을 인증하는 암호 서명을 설정할 수 있다. 이 기능은 금융 거래가 데이터베이스로부터 사라진 바가 없도록 확인할 수 있으므로 클라우드에서 QLDB를 유용한 장부 데이터베이스로 사용할 수 있는 이유가 되어 준다.
QLDB는 일반적인 원장 블록체인 프레임워크에 비해 2~3배 더 뛰어난 성능을 가지고 있고 데이터를 다룰 때 SQL을 사용할 수도 있다.
Amazon Managed Blockchain과의 차이점으론 Managed Blockchain은 탈중앙화 요소가 있지만 QLDB는 중앙집중형 요소가 있다는 것이다.
시험에서는 금융 거래나 원장이라는 단어가 보이면 QLDB를 떠올리면 된다.
작동 원리
- 보이지 않는 저널이 존재하는데, 이때 저널은 일련의 수정 사항을 갖는다.
- 수정이 발생할 때 암호화 해시가 연산돼서 삭제 또는 수정된 사항이 없음을 보장하게 된다.
Amazon Managed Blockchain
블록체인이란 신뢰할 수 있는 중앙 기관 없이도 여러 당사자의 트랜잭션 실행이 가능한 애플리케이션을 구축할 수 있는 기술이 되어 준다. 블록체인에는 탈중앙화라는 개념이 있는 것이다.
Managed Blockchain은 공용 블록체인 네트워크에 가입하거나 AWS 내에서 확장 가능한 블록체인 네트워크를 생성할 수 있는 서비스이다. 지금까지는 Hyperledger Fabric 프레임워크와 Ethereum 프레임워크 두 가지 블록체인과 호환이 가능하다.
시험에서는 블록체인 관련 내용이나 Hyperledger Fabric 혹은 Ethereum이 나오면 탈중앙화된 블록체인인 Amazon Managed Blockchain을 떠올리면 된다.
AWS Glue
Glue는 관리형 추출, 변환 및 로드 서비스로 줄여말하면 ETL 서비스가 된다.
ETL은 데이터 셋에 대한 분석을 수행할 때 그 형식이 올바르지 않거나 원하는 형식이 아닐 때에 유용하게 쓰인다. ETL 서비스를 통해 데이터를 준비하고 변환할 수 있는 것이다.
기존에는 서버를 사용했지만 완전 서버리스인 Glue를 통해서도 할 수 있다. 실제 데이터 변환에만 신경 쓰고 나머지는 Glue에게 맡기면 되는 것이다. Glue는 모든 변환이 가능하며 이를 어떤 장소에든 로드할 수 있다.
Glue에는 Glue ETL 말고도 Glue Data Catalog가 있다. 이름에서 알 수 있듯이 AWS 인프라 내 데이터 셋의 카탈로그를 제공한다. Glue Data Catalog에는 열 이름, 필드 이름, 필드 유형 등 모든 항복에 대한 참조가 있으며 Athena, Redshift, EMR 등의 서버에서 데이터 셋을 검색하고 이에 적합한 스키마를 구축할 때 쓰일 수 있다.
DMS
DMS는 Database Migration Service의 약자로 데이터베이스 간 데이터의 마이그레이션 서비스이다.
먼저 소스 데이터베이스에서 데이터를 추출하기 위해 DMS 소프트웨어를 실행하는 EC2 인스턴스를 실행한 다음, 소스 데이터베이스로부터 데이터를 추출하면 DMS가 다시 해당 데이터를 다른 위치에 있는 대상 데이터베이스로 입력한다.
따라서 DMS를 이용하면 데이터베이스를 AWS로 빠르게 마이그레이션하여 복원과 자가 복구를 수행할 수 있다. 또 다른 이점으로 마이그레이션 작업 중에도 소스 데이터베이스를 사용할 수 있다.
여러 마이그레이션을 지원하는데 그 중 하나는 동종 마이그레이션으로 소스와 대상 데이터베이스가 동일한 데이터베이스 기술을 사용할 때 해당된다. 이기종 마이그레이션도 지원하는데 이는 소스와 대상 데이터베이스가 서로 다른 데이터베이스 기술을 이용할 때 DMS가 소스에서 대상으로 데이터를 변환하는 작업을 수행해 준다.
