Athena

Athena는 Amazon S3 버킷에 저장된 데이터 분석에 사용하는 서버리스 쿼리 서비스로 데이터를 분석하려면 표준 SQL 언어로 파일을 쿼리해야 한다.
Athena는 SQL 언어를 사용하는 Presto 엔진에 빌드된다.
사용자가 S3 버킷에 데이터를 로드하거나 우리 S3 버킷에 데이터를 로드하면 Athena 서비스를 사용해 이동하지 않고 Amazon S3에서 데이터를 쿼리하고 분석할 수 있다.
CSV, JSON, ORC, Avro Parquet 등 다양한 형식을 지원하고 가격 책정은 스캔된 데이터의 TB당 고정 가격을 지불하면 된다.
전체 서비스가 서버리스여서 데이터베이스를 프로비저닝 할 필요가 없다.
Athena는 Amazon QuickSight라는 도구와 함께 사용하는 일이 많다. 이를 통해 보고서와 대시보드를 생성한다.
QuickSight는 S3 버킷에 연결된 Athena 다음에 배치된다.
Amazon Athena의 사용 사례로는 임시 쿼리 수행이나 비즈니스 인텔리전스 분석 및 보고가 있고 AWS 서비스에서 발생하는 모든 로그를 쿼리하고 분석할 수 있다. (VPC 흐름 로그, 로드 밸런서 로그 CloudTrail 추적 등)
시험에선 서버리스 SQL 엔진을 사용한 Amazon S3 데이터 분석이 나오면 Athena를 떠올리자.

성능 향상

1. 비용을 지불할 때 스캔된 데이터의 TB당 가격을 지불하므로 데이터를 적게 스캔할 유형의 데이터를 사용하는 것
   열 기반 데이터 유형을 사용하면 필요한 열만 스캔하므로 비용을 절감할 수 있다.
   따라서 Amazon Athena에 권장하는 형식은 Apache Parquet과 ORC다.
   파일을 Apache Parquet나 ORC 형식으로 가져오려면 대표적으로 Glue를 사용해야 한다.
   또한 더 적은 데이터를 스캔해야 하므로 데이터를 압축해 더 적게 검색해야 한다. (bzip2, gzip, lz4, snappy, zlip, zstd등)

2. 특정 열을 항상 쿼리한다면 데이터 세트를 분할하면 된다. (S3 버킷에 있는 전체 경로를 슬래시로 분할한다는 뜻)
   각 슬래시에 다른 열 이름을 붙여 열별로 특정 값을 저장한다.
   데이터를 쿼리할 때 Amazon S3의 어떤 폴더 즉, 어떤 경로로 데이터를 스캔할지 정확히 알 수 있다.

3. 큰 파일을 사용해서 오버헤드를 최소화하면 성능을 향상할 수 있다.
   S3에 작은 파일이 너무 많으면 Athena는 큰 파일이 있을 때보다 성능이 떨어진다.
   파일이 클수록 스캔과 검색이 쉬우므로 128MB 이상의 파일을 사용해야 한다.

연합 쿼리

Athena는 S3뿐만 아니라 어떤 곳의 데이터도 쿼리할 수 있다. (SQL, NOSQL, 사용자 커스텀 등)
AWS나 온프레미스에 데이터가 있다면 데이터 원본 커넥터를 사용하면 된다.
데이터 원본 커넥터는 Lambda 함수로 다른 서비스에서 연합 쿼리를 실행한다.
CloutWacth Logs, DyanamoDB RDS 등에서 실행하며 매우 강력하다.
데이터 원본 커넥터당 하나의 Lambda 함수를 가지며 Amazon Athena을 통해 ElastiCache, DocumentDB DynamoDB, Redshift와 Aurora, SQL 서버, MySQL EMR 서비스의 HBase에서 쿼리를 실행할 수 있고 Athena에서 바로 Amazon S3뿐만 아니라 모든 온프레미스 데이터베이스를 쿼리할 수 있으며 쿼리를 조인할 수 있다.
쿼리 결과는 사후 분석을 위해 Amazon S3 버킷에 저장할 수 있다.

Redshift

Redshift는 PostgreSQL 기술 기반이지만 온라인 트랜잭션 처리(OLTP)에 사용되지 않는다.
온라인 분석 처리를 의미하는 OLAP 유형의 데이터베이스이며 분석과 데이터 웨어하우징에 사용한다.
다른 어떤 데이터 웨어하우징보다 성능이 10배 이상 좋고 데이터가 PB 규모로 확장되므로 모든 데이터를 Redshift에 로드하면 Redshift에서 빠르게 분석할 수 있다.
Redshift는 성능 향상이 가능한데 이는 열 기반 데이터 스토리지를 사용하기 때문 (행 기반이 아니라 병렬 쿼리 엔진)
Redshift 클러스터에서 프로비저닝한 인스턴스에 대한 비용만 지불하면 된다.
쿼리를 수행할 때 SQL 문을 사용할 수 있고, Amazon Quicksight 같은 BI 도구나 Tableau 같은 도구와 통합 가능

Athena vs Redshift

Redshift는 먼저 Amazon S3에서 모든 데이터를 Redshift에 로드해야 한다.
Redshift에 데이터를 로드하고 나면 Redshift의 쿼리가 더 빠르고 조인과 통합을 훨씬 더 빠르게 할 수 있다. (Redshift에는 인덱스가 있기에)
Redshift는 데이터 웨어하우스가 높은 성능을 발휘하도록 인덱스를 빌드한다.
Amazon S3의 ad hoc(즉선)쿼리라면 Athena가 좋은 사용 사례가 되지만, 쿼리가 많고 복잡하며 조인하거나 집계하는 등 집중적인 데이터 웨어하우스라면 Redshift가 더 좋다.

Redshift Cluster

Redshift 클러스터에는 두 노드가 있다.
리더 노드(쿼리 계획과 결과 집합을 시킴)와 계산노드(Compute Node)가 존재한다.
리더 노드에 쿼리를 SQL 형식으로 제출하면 백엔드에서 쿼리가 발생한다.
리더 노드는 쿼리를 계획하고 결과를 집계하며 계산 노드는 실제로 쿼리를 실행하고 결과를 리더 노드에 보낸다.
Redshift 클러스터는 노드 사이즈를 사전에 프로비저닝해야 하고 비용을 절감하려면 예약 인스턴스를 사용하면 된다.

Snapshots & DR

Redshift는 대부분의 클러스터에 대해 싱글 AZ이지만 특정 클러스터 유형에 대해 멀티 AZ모드가 있다.
그래서 멀티 AZ가 있다면 피해 복구가 잘 되겠지만, 싱글 AZ라면 재해 복구 전략을 적용하려면 스냅샷을 사용해야 한다.
스냅샷은 클러스터의 지정 시간 백업으로 Amazon S3 내부에 저장되며 증분한다. 변경된 사항만 저장 -> 많은 저장 공간 절약
새로운 Redshift 클러스터에 스냅샷을 복원할 수 있으며 스냅샷에는 두 가지 모드가 있다. (수동, 자동)
스냅샷이 8시간마다 또는 5GB마다 자동으로 생성되도록 일정을 예약할 수 있고 자동화된 스냅샷의 보존 기간을 설정할 수 있다.
수동 스냅샷을 사용할 경우 직접 스냅샷을 삭제하기 전까지 스냅샷이 유지된다.

Redshift는 자동이든 수동이든 클러스터의 스냅샷을 다른 AWS 리전에 자동으로 복사하도록 Redshift를 구성하여 재해 복구 전략을 적용할 수 있다는 점.

원본 Redshift 클러스터와 다른 리전이 있을 때 스냅샷을 생성하면 새로운 리전에 자동으로 복사되고 복사된 스냅샷에서 새 Redshift 클러스터를 복원할 수 있다.

데이터 수집 방법

Amazon Kinesis Data Firehose

Firehose가 다양한 소스로부터 데이터를 받아서 Redshift에 보내는 것
먼저 Amazon S3 버킷에 데이터를 써야겠죠
그러면 자동으로 Kinesis Data Firehose가 S3 복사 명령을 실행해 Redshift에 데이터가 로드됩니다

S3 using COPY command

수동으로도 가능하다.
S3에 데이터를 로드하고 Redshift에서 복사 명령을 실행하면 IAM 역할을 사용해 S3 버킷에서 Amazon Redshift 클러스터로 데이터를 복사한다.
인터넷을 사용할 수 있다. S3 버킷은 인터넷과 연결돼 있기 때문
데이터가 인터넷을 통해 다시 Redshift 클러스터로 이동하게 되는데 향상된 VPC 라우팅 없이도 가능하다.
모든 네트워크를 가상 프라이빗 클라우드에 비공개 상태로 유지하고 싶다면 모든 데이터가 VPC로 완전히 이동되도록 향상된 VPC 라우팅을 사용하면 된다.

JDBC 드라이버

애플리케이션에 Redshift 클러스터에 써야 하는 EC2 인스턴스가 있을 때 이 방법을 사용
이때 Amazon Redshift에 큰 배치로 데이터를 쓰는 것이 좋다.
이 유형의 데이터베이스에 한 번에 한 행씩 쓰는 건 비효율적

Spectrum

Redshift Spectrum은 Amazon S3에 있는 데이터를 Redshift를 사용해 분석은 하고싶지만 Redshift에 로드하고 싶지 않을때 사용할 수 있다.
또는 더 많은 처리 능력을 사용하고 싶을 때 사용할 수 있다.
Redshift Spectrum을 사용하려면 쿼리를 시작할 수 있는 Redshift 클러스터가 있어야 한다.
일단 쿼리를 시작하면 S3에 있는 데이터에 쿼리를 실행할 수천 개의 Redshift Spectrum 노드에 쿼리가 제출된다.
Spectrum이 자동으로 시작되고 쿼리는 Amazon S3에서 데이터를 읽고 집계하는 수천 개의 Redshift Spectrum 노드에 제출된다.
제출이 완료되면 결과가 Amazon Redshift 클러스터를 통해 쿼리를 시작한 곳으로 전송된다.
이 기능을 사용하면 Amazon S3에서 Redshift로 데이터를 로드하지 않아도 되므로 클러스터에서 프로비저닝한 것보다 더 많은 처리 능력을 활용할 수 있습니다

OpenSearch Service

Amazon OpenSearch는 Amazon ElasticSearch의 후속 서비스. 서버리스 X
기본 키나 데이터베이스의 인덱스로만 데이터를 쿼리할 수 있는 DynamoDB와 비교해 보면 OpenSearch로는 부분적으로 일치하는 필드를 포함해 모든 필드를 검색할 수 있다.
그래서 OpenSearch는 애플리케이션에서 검색 기능을 제공할 때 많이 사용되고 일반적으로 다른 데이터베이스를 보완하는데 사용
OpenSearch는 검색에 사용되지만 OpenSearch를 사용하면 쿼리를 분석할 수도 있다.
OpenSearch 클러스터를 프로비저닝하는데 두 가지 모드가 있다.
사용자가 직접 물리적인 인스턴스를 프로비저닝, 서버리스 경로를 선택해 서버리스 클러스터를 생성(AWS에서 스케일링~운영까지)
자체 쿼리 언어가 있지만 SQL을 지원하지 않고 Kinesis Data Firehose AWS IoT, CloudWatch Logs나 사용자 지정 애플리케이션의 데이터를 주입하여 SQL 호환성을 활성화할 수 있다.
Cognito, IAM과 통합해 제공하는 보안을 통해 저장 데이터 암호화와 전송 중 암호화가 가능하다.
OpenSearch Dashboards로 OpenSearch 데이터를 시각화할 수 있다.
DynamoDB, CloudWatch Logs로 OpenSearch에 데이터를 주입할 수도 있다.

EMR

EMR은 Elastic MapReduce의 약어로 AWS에서 빅 데이터 작업을 위한 하둡 클러스터 생성에 사용된다.
방대의 양의 데이터를 분석하고 처리할 수 있다.
하둡 클러스터는 프로비저닝해야 하며 수백 개의 EC2 인스턴스로 구성될 수 있다.
EMR은 빅 데이터 전문가가 사용하는 여러 도구와 함께 제공된다.
Apache Spark, HBase, Presto Apache Flink는 설정이 어려운데 Amazon EMR이 상기 서비스에 관한 프로비저닝과 구성을 대신 처리해 준다.
전체 클러스터를 자동으로 확장할 수 있고 스팟 인스턴스와 통합되므로 가격 할인 혜택을 받을 수도 있다.

시험 측면에서 본 Amazon EMR의 사용 사례로는 데이터 처리와 기계 학습, 웹 인덱싱 빅 데이터 작업이 있는데 모든 작업은 하둡, Spark, HBase Presto, Flink와 같은 빅 데이터 관련 기술을 사용한다.

Node 유형

Amazon EMR은 EC2 인스턴스의 클러스터로 구성되며 여러 노드 유형이 있다.
마스터 노드는 클러스터를 관리하고 다른 모든 노드의 상태를 조정하며 장기 실행해야 한다.
코어 노드는 태스크를 실행하고 데이터를 저장합니다 장기 실행해야 한다.
마지막 유형은 테스트만 실행하는 태스크 노드다. 대게 스팟 인스턴스를 사용
온디맨드 EC2 인스턴스 유형을 사용하면 신뢰할 수 있고 예측 가능한 유형의 워크로드를 얻게 되고 절대 종료되지 않는다
최소 1년을 사용해야 하는 예약 인스턴스를 사용하는 경우에는 비용을 크게 절약할 수 있으며 가능한 경우에 EMR이 자동으로 예약 인스턴스를 사용한다.
예약 인스턴스는 장기 실행해야 하는 마스터 노드와 코어 노드에 적합하다.
EMR에서 배포할 때는 장기 실행 클러스터에서 예약 인스턴스를 사용하거나 임시 클러스터를 사용해 특정 작업을 수행하고 분석 완료 후에 삭제할 수 있다.

QuickSight

Amazon QuickSight는 서버리스 머신 러닝 기반 비즈니스 인텔리전스 서비스
비즈니스 인텔리전스니까 대화형 대시보드를 생성해 소유한 데이터 소스와 연결할 수 있다.
시각화할 수 있고 빠르며 오토 스케일링이 가능하다. 웹사이트에 임베드할 수 있으며 세션당 비용을 지불한다.
QuickSight의 사용 사례에는 비즈니스 분석 시각화 구현 시각화된 정보를 통한 임시 분석 수행 그리고 데이터를 활용한 비즈니스 인사이트 획득이 있다.
RDS, Aurora, Athena Redshift, S3 등 다양한 데이터 소스에 연결할 수 있다.
SPICE 엔진이라는 것이 있는데, 인 메모리 연산 엔진이며 Amazon QuickSight로 데이터를 직접 가져올 때 사용되며 Amazon QuickSight가 다른 DB에 연결돼 있을 때는 작동하지 않는다.
Amazon QuickSight의 엔터프라이즈 에디션에서는 액세스 권한이 없는 사용자에게 일부 열이 표시되지 않도록 열 수준 보안(CLS)을 설정할 수 있다.

통합

RDS 데이터베이스, Aurora 데이터 웨어하우징 서비스인 Redshift S3에서 임시 쿼리를 수행하는 Athena 데이터를 가져오기 위한 Amazon S3 OpenSearch 및 시계열 데이터를 최적할 수 있는 Timestream과 통합할 수 있다.
타사 데이터 소스와 통합할 수도 있는데, QuickSight가 지원하는 서비스형 소프트웨어여야 한다. Salesforce와 Jira가 대표적
내부적으로 JDBC 프로토콜을 사용하는 온프레미스 데이터베이스와 통합할 수 있다.
QuickSight로 직접 Excel 파일, CSV 파일 JSON 문서, TSV 파일 로그 형식의 ELF 및 CLF 등의 데이터 소스를 가져올 수 있다.
Amazon QuickSight로 데이터 소스를 가져온 다음 SPICE 엔진을 활용해 매우 빠르게 인 메모리 연산을 수행할 수 있다.
시험에는 QuickSight를 Athena나 Redshift와 함께 사용하는 문제가 자주 나오지만 다른 통합도 출제될 수 있다.

대시보드와 분석

QuickSight에는 세 가지 개념이 있다.
대시보드 및 분석 그리고 사용자가 있다.
스탠다드 버전에서는 사용자를 정의할 수 있고 그룹은 엔터프라이즈 버전에서만 사용할 수 있다.
QuickSight의 사용자와 그룹은 QuickSight 서비스 전용
IAM 사용자와는 다르다. IAM 사용자는 관리용으로만 사용된다.
QuickSight 내에서 사용자와 그룹을 정의하고 대시보드를 생성하면 된다.
대시보드는 읽기 전용 스냅샷이며 분석 결과를 공유할 수 있다. 또한 분석의 구성을 저장한다.
분석을 위해 설정한 필터 또는 매개변수 제어, 정렬 옵션 등이 저장되어 대시보드에 표시된다.
따라서 분석이 좀 더 충실하며 특정 사용자 또는 그룹과 분석 결과나 대시보드를 공유할 수 있다.
액세스 권한이 있는 사용자는 기본 데이터를 볼 수도 있다.
QuickSight에서는 분석 및 대시보드를 생성해야 하고요 특정 사용자나 그룹과 공유할 수 있다.

Glue

Glue는 추출과 변환 로드 서비스를 관리하며 ETL 서비스이자 완전 서버리스 서비스다.
분석을 위해 데이터를 준비하고 변환하는 데 매우 유용하다.

고급 기능

Glue 작업 북마크

새 ETL 작업을 실행할 때 이전 데이터의 재처리를 방지한다.

Glue Elastic Views

SQL을 사용해 여러 데이터 스토어의 데이터를 결합하고 복제한다.
가령 RDS 데이터베이스와 Aurora 데이터베이스 Amazon S3에 걸친 뷰를 생성하는 것
커스텀 코드를 지원하지 않으며 Glue가 원본 데이터의 변경 사항을 모니터링한다.
서버리스 서비스
또한 여러 데이터 스토어에 분산된 구체화된 뷰인 가상 테이블을 생성할 수 있다.

Glue DataBrew

사전 빌드된 변환을 사용해 데이터를 정리하고 정규화한다.

Glue Studio

Glue에서 ETL 작업을 생성, 실행 및 모니터링하는 GUI

Glue 스트리밍 ETL

Apache Spark Structured Streaming 위에 빌드되며 ETL 작업을 배치 작업이 아니라 스트리밍 작업으로 실행할 수 있다.
Kinesis Data Streaming Kafka 또는 AWS의 관리형 Kafka인 MSK에서 Glue 스트리밍 ETL을 사용해 데이터를 읽을 수 있다.

Lake Formation

데이터 레이크란 데이터 분석을 위해 모든 데이터를 한곳으로 모아 주는 중앙 집중식 저장소다.
Lake Formation은 데이터 레이크 생성을 수월하게 해 주는 완전 관리형 서비스
Lake Formation은 데이터 레이크에서의 데이터 검색, 정제, 변환 주입을 돕는다.
게다가 데이터 수집, 정제나 카탈로깅, 복제 같은 복잡한 수작업을 자동화하고 기계 학습(ML) 변환 기능으로 중복제거를 수행한다.
데이터 레이크에서는 정형 데이터와 비정형 데이터 소스를 결합할 수 있으며 블루프린트를 제공한다.
내장된 블루프린트는 데이터를 데이터 레이크로 이전(migrate)하는 것을 도와주며 Amazon S3, Amason RDS 온프레미스에서 실행되는 관계형 데이터베이스 NoSQL 데이터베이스 등에서 지원된다.
Lake Formation을 설정하는 이유는 모든 데이터를 한곳에서 처리하는 것 외에도 애플리케이션에서 행, 열 수준의 세분화된 액세스 제어를 할 수 있기 때문
AWS Lake Formation에 연결된 애플리케이션에서는 세분화된 액세스 제어가 가능
Lake Formation은 AWS Glue 위에 빌드되는 계층이긴 하지만 Glue와 직접 상호 작용하지 않는다.
Lake Formation은 Amazon S3에 저장되는 데이터 레이크의 생성을 돕는다.
데이터 소스로는 Amazon S3 RDS, Aurora SQL, NoSQL 같은 온프레미스 데이터베이스가 있고 Lake Formation의 블루프린트를 통해 데이터를 주입한다.
Lake Formation에는 소스 크롤러와 ETL 및 데이터 준비 도구 데이터 카탈로깅 도구가 포함됩니다
Glue의 기본 서비스에 해당되고요
데이터 레이크의 데이터를 보호하는 보안 설정과 액세스 제어도 포함된다.
Lake Formation을 활용하는 서비스로는 Athena, Redshift, EMR Apache Spark 프레임워크 같은 분석 도구가 있다.
사용자는 이와 같은 서비스를 통해 Lake Formation 및 데이터 레이크에 연결합니다

중앙화된 권한

회사가 데이터 분석에 Athena와 QuickSight를 사용할 때 사용자는 허용된 데이터만 볼 수 있어야 하고 읽기 권한이 있어야 한다.
Athena에 보안을 설정하거나 QuickSight에서 사용자 수준의 보안을 설정할 수 있다.
S3 버킷 정책이나 사용자 정책에 보안 설정을 할 수도 있다. RDS, Aurora도 마찬가지.
이렇게 보안을 관리할 곳이 많아지면 엉망이 될 텐데, 이럴때는 Lake Formation이 답이다.
액세스 제어 기능과 열 및 행 수준 보안이 있기 때문이다.
Lake Formation에 주입된 모든 데이터는 중앙 S3 버킷에 저장되지만 모든 액세스 제어와 행, 열 수준 보안은 Lake Formation 내에서 관리된다.
따라서 Lake Formation에 연결하는 서비스는 읽기 권한이 있는 데이터만 볼 수 있게 된다.
Athena, QuickSight 등 어떤 도구를 사용하든 Lake Formation에 연결하면 한곳에서 보안을 관리할 수 있다.

Kinesis Data Analytics

SQL 애플리케이션용 Kinesis Data Analytics

중앙에 위치하여 Kinesis Data Streams와 Kinesis Data Firehose 데이터 소스에서 데이터를 읽는다.
둘 중 한군데서 데이터를 읽어 온 다음 SQL 문에 적용하여 실시간 분석을 처리할 수 있다.
Amazon S3 버킷의 데이터를 참조해 참조 데이터를 조인할 수도 있다. 그리고 여러 대상에 데이터를 전송한다.
Kinesis Data Streams는 Kinesis Data Analytics의 실시간 쿼리로 스트림을 생성한다.
Kinesis Data Firehose로 바로 보내면 Amazon S3 Amazon Redshift이나 Amazon OpenSearch 또는 기타 Firehose 대상에 전송된다.
Kinesis Data Streams에 보내면 EC2에서 실행하는 애플리케이션이나 AWS Lambda로 스트리밍하는 데이터를 실시간으로 처리할 수 있다.
Amazon S3로 데이터를 강화할 수 있고 완전 관리형 서비스이므로 서버를 프로비저닝하지 않는다.
오토 스케일링이 가능하며 Kinesis Data Analytics에 전송된 데이터만큼 비용을 지불한다.
Kinesis Data Streams나 Kinesis Data Firehose에 데이터를 출력할 수 있고 사용 사례로는 시계열 분석과 실시간 대시보드와 실시간 지표가 있다.

Apache Flink용 Kinesis Data Analytics

Apache Flink를 사용하면 Java, Scala, SQL로 애플리케이션을 작성하고 스트리밍 데이터를 처리, 분석할 수 있다.
Flink는 코드로 작성해야 하는 특별한 애플리케이션이다.
Flink 애플리케이션을 Kinesis Data Analytics의 Flink 전용 클러스터에서 실행할 수 있다. (백그라운드)
Apache Flink을 사용해 두 개의 메인 데이터 소스인 Kinesis Data Streams나 Amazon MSK의 데이터를 읽을 수 있다.
AWS의 관리형 클러스터에서 Apache Flink 애플리케이션을 실행할 수 있다.
Apaches Flink는 표준 SQL보다 훨씬 강력하기 때문에 고급 쿼리 능력이나 필요하거나 Kinesis Data Streams나 AWS의 관리형 Kafka인 Amazon MSK 같은 서비스로부터 스트리밍 데이터를 읽는 능력이 필요할 때 Apache Flink용 Kinesis Data Analytics를 사용한다.
이 서비스를 사용하면 컴퓨팅 리소스를 자동 프로비저닝할 수 있고 병렬 연산과 오토 스케일링을 할 수 있다.
체크포인트와 스냅샷으로 구현되는 애플리케이션 백업이 가능하고 Apache Flink 프로그래밍 기능을 사용할 수도 있다.
참고로 Apache Flink는 Kinesis Data Streams나 Amazon MSK의 데이터는 읽지만 Kinesis Data Firehose의 데이터는 읽지 못합니다 Kinesis Data Firehose에서 데이터를 읽고 실시간 분석하려면 SQL 애플리케이션용 Kinesis Data Analytics를 사용해야 한다.

MSK

MSK는 AWS의 완전 관리형 Kafka 클러스터 서비스로 그때그때 클러스터를 생성, 업데이트, 삭제합니다
Kafka는 Amazon Kinesis의 대안으로 두 서비스 모두 데이터를 스트리밍한다.
MSK는 클러스터 내 브로커 노드와 Zookeeper 브로커 노드를 생성 및 관리하고 고가용성을 위해 VPC의 클러스터를 최대 세 개의 다중 AZ 전역에 배포한다.
일반 Kafka 장애를 자동 복구하는 기능이 있으며 EBS 볼륨에 데이터를 저장할 수도 있다.
Amazon MSK 서버리스를 사용할 수도 있다.
MSK에서 Apache Kafka를 실행하지만 서버 프로비저닝이나 용량 관리가 필요 없다.
MSK가 리소스를 자동으로 프로비저닝하고 컴퓨팅과 스토리지를 스케일링한다.

MSK vs Kafka

Kafka는 Kinesis와 유사하지만 몇 가지 차이점이 있다.
Kinesis Data Streams에는 1MB의 메시지 크기 제한이 있다.
Amazon MSK에서는 1MB이 기본값이고 더 큰 메시지 보존을 위해 10MB로 설정할 수도 있다.
Kinesis Data Streams에선 샤드로 데이터를 스트리밍한다.
Amazon MSK에선 파티션을 이용한 Kafka 토픽을 사용한다.
Kinesis Data Streams에서 용량을 확장하려면 샤드 분할을 축소하려면 샤드 병합을 한다.
Amazon MSK에서는 파티션 추가로 주제 확장만 할 수 있다. 파티션 제거는 불가능
Kinesis Data Streams에는 TLS 전송 중 암호화 기능이 있고 Amazon MSK에는 평문과 TLS 전송 중 암호화 기능이 있다
두 클러스터 모두 저장 데이터 암호화가 가능하다.
Amazon MSK에서는 원한다면 1년 이상 데이터를 보관할 수도 있다. (EBS 스토리지 비용을 지불할 경우)

MSK vs Kafka

Kafka는 Kinesis와 유사하지만 몇 가지 차이점이 있다.
Kinesis Data Streams에는 1MB의 메시지 크기 제한이 있다.
Amazon MSK에서는 1MB이 기본값이고 더 큰 메시지 보존을 위해 10MB로 설정할 수도 있다.
Kinesis Data Streams에선 샤드로 데이터를 스트리밍한다.
Amazon MSK에선 파티션을 이용한 Kafka 토픽을 사용한다.
Kinesis Data Streams에서 용량을 확장하려면 샤드 분할을 축소하려면 샤드 병합을 한다.
Amazon MSK에서는 파티션 추가로 주제 확장만 할 수 있다. 파티션 제거는 불가능
Kinesis Data Streams에는 TLS 전송 중 암호화 기능이 있고 Amazon MSK에는 평문과 TLS 전송 중 암호화 기능이 있다
두 클러스터 모두 저장 데이터 암호화가 가능하다.
Amazon MSK에서는 원한다면 1년 이상 데이터를 보관할 수도 있다. (EBS 스토리지 비용을 지불할 경우)