#AWS Certified Developer Associate
257. Kinesis 개요
철저히 숙지해야할 중요한 파트라고 함;;
(카이니시스라고 발음하네 ㅇㅅㅇ)
kinesis는 스트리밍 데이터를 실시간으로 수집, 처리, 분석하도록 도와주는 서비스
실시간 데이터 - 애플리케이션 로그, 지표, 웹사이트, 클릭스트림, ioT 원격 데이터 등
kinesis를 구성하는 4개의 서비스
- kinesis data streams : 데이터 스트림을 입력, 처리하고 저장함
- kinesis data firehose : 데이터 스트림을 aws 내부 또는 외부의 데이터 스토어로 로드함
- kinesis data analytics : sql 언어 또는 apache flink 를 통해 데이터 스트림을 분석하기 위한 서비스
- kinesis video streams : 비디오 스트림을 입력, 처리, 저장하는 서비스
258. Kinesis Data Streams 개요
시스템에 빅 데이터를 스트리밍하는 방법
kinesis data streams 는 번호가 매겨진 여러 샤드로 구성됨
- 샤드는 사전에 프로비저닝 되어있어야 함
- 모든 샤드에 걸쳐 데이터가 분할됨
- 샤드가 수집 및 소비율에 맞춰 스트림 용량을 정의함
여러 형태의 생산자(producer)가 kinesis data streams 에 데이터를 보내게 됨
- 생상자 : 애플리케이션, 데스크톱, 모바일 등의 클라이언트
- 좁은 의미 : SDK 에 의존해 kinesis data streams 레코드를 생성
- 레코드
- partition key : 레코드가 어느 샤드로 이동할지를 정의해 줌
- data blob(최대 1MB) : 값 자체
제작자가 kinesis data streams 로 데이터를 보낼 때는 샤드당 1MB/sec 또는 1,000MPS(msg/sec) 로 데이터가 전송됨
- 샤드가 6개라면 총 6MB/sec or 6,000MPS
이렇게 전송된 데이터가 kinesis data streams 에 도착하면 많은 소비자(consumers)가 이를 소비할 수 있음
- 소비자 : SDK, Kinesis Client Library(KCL) 에 의존하는 애플리케이션 , Lambda, Kinesis Data Firehose , Kinesis Data Analytics
소비자가 레코드를 수신할 때는 파티션 키와 함께 레코드가 샤드에 있었던 위치를 나타내는 시퀸스 번호도 받음 ( data blob 도 함께)
kinesis data streams 의 다양한 소비 모드
- 처리량을 공유할 때 : 전체 소비자가 샤드당 2MB/sec
- 향상된 소비자 모드(enhanced) 향상된 팬아웃을 활성화 : 소비자별로 샤드당 2MB/sec
kinesis data streams properties
1일 ~ 365일 사이의 보유 기간을 설정할 수 있음
기본적으로 데이터를 재처리하거나 반복할 수 있음
kinesis 에 삽입된 데이터는 삭제가 불가능함 (불변성-immutability)
kinesis data streams 로 데이터를 보내면 파티션 키가 추가되는데 같은 파티션 키를 공유하는 메세지는 동일한 샤드로 이동해 키 기반 순서를 제공함 (ordering)
생산자(producers) 는 AWS SDK, Kinesis Producer Library(KPL), Kinesis Agent 를 사용해 데이터를 전송할 수 있음
소비자(consumers) : 직접 작성할 수 있음
- kinesis client library (KCL)
- AWS SDK
- Managed(관리형 소비자) : aws lambda, kinesis data firehose, kinesis data analytics
Kinesis Data Streams - Capacity Modes (용량 모드)
두개의 옵션이 있다고 함
- Provisioned mode (기록 용량 모드)
몇개의 샤드 프로비저닝을 선택한 후 수동 혹은 API 를 사용해 확장하는 것
in(입력) - kinesis data streams 의 각 샤드는 1MB/sec 또는 1,000RPS(records per second) 의 속도
out(출력) - 샤드당 2MB/sec (클래식 또는 팬아웃 소비자에 해당함)
시간당 샤드 프로비저닝에 따른 비용 발생
- On-demand mode
용량을 프로비저닝하거나 관리할 필요가 없는 모드
용량이 수요에 맞춰 시간 흐름에 따라 조정됨
4MB/s 또는 4,000RPS 의 기본 용량 프로비저닝이 있음
지난 30일간 피크 처리량에 기반해 오토 스케일링이 수행됨
이 모드에서는 시간당 스트림마다, 데이터 입출력 GB당 스트림마다 데이터 입출력에 따른 비용이 발생됨
미리 용량이 예측되지 않는다면 온디멘드 모드를, 용량 이벤트 계획이 가능하다면 프로비저닝 모드를 추천한다고 함
Kinesis Data Streams Security
리전 내에서만 배포하게 됨
IAM 정책을 사용해 샤드 생성 및 읽기에 대한 액세스 제어 가능
전송중 암호화 - HTTPS / 저장중 암호화 - KMS
클라이언트 측 암호화 및 복호화 하도록 구현할 수도 있음
VPC 엔드 포인트도 kinesis 에 적용할 수 있음
- 인터넷을 거치지 않고 프라이빗 서브넷의 ec2 인스턴스에서 직접 kinesis 에 엑세스 가능
CloudTrail 로 모든 api 호출을 모니터링 할 수 있음
(1.10 시작)
259. Kinesis 생산자(producers)
Producer
kinesis 에서 데이터를 가져오는 방법
1. 데이터를 데이터 스트림에 보냄
2. 데이터 레코드는 일련번호로 이루어져 있음
- 샤드 내 파티션 마다 고유함
- 파티션 키 : 레코드를 스트림에 넣을 때 반드시 지정해야 함
- data blob (up to 1MB)
3. Producers (생산자)
- AWS SDK : simple producer
- Kinesis Producer Library(KPL) : C++, Java, batch(배치처리) / compression(압축), retries(재시도) 등의 고급 기능을 API 로 사용 가능
- Kinesis Agent : kinesis 에 데이터를 보내는 다른 방법, kinesis 생산자 라이브러리 위에 구축되어 있음 / 로그 파일을 모니터링 + kinesis data streams 에 이들을 스트리밍 할 때 사용함
4. 쓰기 처리량 (write throughput) : 1 MB/sec or 1000 records/sec per shard
5. PutRecord API : kinesis 에 데이터를 보내는 API
- PutRecord API 의 배치를 이용하면 비용을 절감할 수 있고 처리량을 늘릴 수 있음
파티션 키와 kinesis data streams 를 만드는 방식
- 예를 들어 n 개의 샤드가 있는 스트림이 있고 IoT 단말을 가진 생성자가 있다고 할 때
샤드 당 1초에 1MB 또는 1초에 1000 레코드의 비율로 데이터를 보냄
- 장치 id 는 111222333 일때 파티션 키를 장치 id로 선택함 - 이 id 는 해시 함수를 거치게 됨 - 그러면 어떤 샤드로 데이터를 보내야 할지 알 수 있음 - 즉 같은 파티션 키를 공유하는 모든 데이터는 같은 샤드로 보내지게됨
- 다른 단말 id (444555666)가 있다고 할 때 이 데이터 블롭은 다른 파티션 키를 갖게 되고 같은 해시 함수를 거치게 됨
- 위 사례 처럼 한 단말에서 샤드로 보내는 데이터가 많으면 샤드를 압도할 수 있음
- 핫 파티션이라는 것을 피하고자 파티션 키를 잘 분배해야 함 - 하나의 샤드의 처리량 다른 샤드에 비해 너무 많아지고 불균형을 가져올 수 있기 때문
Kinesis - ProvisionedThroughputExceeded (프로비저닝 처리량 초과)
한 샤드에 전송되는 데이터량이 처리량을 초과할 때 예외가 발생함
Solution
- 매우 잘 분산된 파티션 키 사용 (use highly distributed partition key)
- 기하급수적인 백오프를 통해 재시도를 구현 (예외 상황을 재시도 할 수 있게 함)
- 샤드 스케일링(샤드 분할) - 샤드를 분할해서 처리량을 증가시킴
259. Kinesis 소비자(Consumers)
소비자는 스트림으로부터 레코드를 가져오고 처리함
소비자 종류
- AWS Lambda
- Kinesis Data Analytics
- Kinesis Data Firehose
- Custom Consumer(AWS SDK) - Classic or Enhanced Fan-Out (향상된 팬아웃)
- Kinesis Client Library(KCL) : 데이터 스트림에서 읽어오는 것을 간편하게 해주는 클라이언트 라이브러리
공유된(Classic) 팬아웃 소비자와 향상된(Enhanced) 팬아웃 소비자의 차이점
Sared(Classic) Fan-Out Consumer
- 공유된 처리량 방식으로 소비자를 쓰면
많은 샤드를 가진 kinesis data streams 가 있고 전체 소비자에 걸쳐 각 샤드당 1초당 2MB 의 처리 속도를 얻을 수 있음 (2 MB/sec per shard across all consumers)
- 예를들어 샤드 1에서 소비자 앱 A 와 GetRecords API 호출을 통해 샤드 1에서 레코드를 가져올 수 있다.
- 같은 kinesis data streamas 를 읽는 다양한 애플리케이션을 가질 수 있음 - B,C 앱 에서 샤드1의 레코드를 가져올 수 있음
- 모든 소비자에 걸쳐 사드당 1초당 2MB 를 공유함 - 즉 위 예시에서 인스턴스에 3명의 소비자가 있고 초당 2MB 를 공유함 - 한 소비자는 최대 약 666KB 의 데이터를 얻음
그러므로 kinesis data의 소비자 수에는 한계가 있음 - 더 많은 애플리케이션을 추가할수록 더 많은 처리량 한계가 생김
Enhanced Fan-out Consumer
위 예시의 단점을 보완한 새로운 소비 모드
소비자당, 샤드 당 1초당 2MB 를 얻음 ( 2MB/sec per consumer per shard) - 전체 소비자에 걸쳐서가 아닌 각 소비자와 샤드에 할당됨
즉 소비자 앱 A가 새로운 api 인 SubscribeToShard() 를 사용해 초당 2MB의 비율로 데이터를 푸시 받을 때, 만약 두번째 소비자 앱 B가 다른 SubscribeToShard() 를 호출하면 앱 B 역시 샤드에 의해 초당 2MB의 비율로 데이터를 받을 수 있음
즉 위 예시에서 샤드 하나의 처리량은 초당 6MB 가 됨
위 Shared 모델은 pull 모델이고 Enhanced 모델은 push 모델임
정리 (Kinesis Consumers Types)
Shared(Classic) Fan-out Consumer - pull
- 소비하는 애플리케이션이 적을 경우에 유용함
- 읽기 처리량(Read throughput) : 전체 소비자에 걸쳐 샤드당 1초당 2MB (2MB/sec per shard across all consumers)
- 샤드당 제한 : 초당 최대 5개의 GetRerods API 호출 가능
- API 호출의 지연시간 약 200ms
- 비용을 절감할 때 사용함
- 소비자는 GetRecords API 호출을 이용하여 kinesis 로부터 직접 풀하고 데이터를 최대 10MB 까지 반환함 (반환 후 5초동안 또는 10,000 레코드를 스로틀링 함)
Enhanced Fan-out Consumer - push
- 소비하는 애플리케이션을 같은 스트림에서 여러개 가질 수 있음
- 각 소비자는 샤드 당 1초에 2MB 를 얻음 (2MB/sec per consumer per shard)
- API 호출의 지연시간 약 70ms (샤드 자체에서 데이터를 소비자로 푸시하기 때문에 지연시간이 더 짧음)
- Higher Costs
- HTTP/2 라는 스트리밍 방식을 사용하여 데이터가 푸시됨
- 데이터 스트림 당 5개의 소비자 애플리케이션이라는 제약이 있음 (aws 에 티겟을 올려 올릴 수 있다고 함)
Kinesis Consumers - AWS Lambda
서버를 이용하지 않고 데이터를 소비하는 방식
예를 들어 kinesis data stremas 에 3개의 샤드가 있다고 가정
람다 함수 - 레코드를 처리하고 dynamoDB 에 레코드를 저장하는 역할
람다함수는 kinesis data streams 에 GetBatch 를 호출함
데이터는 파티션 키에 의해 람다함수로 전송되어 처리됨
람다 함수는 데이터를 dynamoDB 에 보냄
람다 함수는 클래식과 향상된 팬아웃 소비자 모드를 둘 다 지원함
배치(batches) 로 레코드를 읽게 됨
배치 크기와 배치 영역을 구성할 수 있음
오류가 발생한다면 성공할 때까지 람다가 재시도 하거나 kinesis data streams 에서 데이터가 만료될 것
동시에 샤드당 최대 10개의 배치까지 처리할 수 있음
261. Kinesis Data Streams 실습
용량 모드를 선택할때 온디멘드 모드와 프로비저닝 모드를 선택해서 사용할 수 있음
write 되는 레코드의 양이 예측 가능할때 샤드 수를 권장해주는 샤드 계산기
kinesis data stream 은 프리티어가 없어 요금이 부과되므로 이번 실습에서 빠르게 생성하고 삭제한다고 한다
생산자와 소비자의 종류와 github 를 확인할 수 있다
이후 간단한 읽기 쓰기를 실습하는데 AWS CLI 를 사용한다고 한다
aws cloudshell 접속
kinesis-data-streams.sh
#!/bin/bash
# get the AWS CLI version
aws --version
# PRODUCER
# CLI v2
aws kinesis put-record --stream-name test --partition-key user1 --data "user signup" --cli-binary-format raw-in-base64-out
# CLI v1
aws kinesis put-record --stream-name test --partition-key user1 --data "user signup"
# CONSUMER
# describe the stream
aws kinesis describe-stream --stream-name test
# Consume some data
aws kinesis get-shard-iterator --stream-name test --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON
aws kinesis get-records --shard-iterator <>aws cli 의 버전에 따라 kinesis data streams 에 쓸 두가지 명령이 있다고 함
aws 버전을 확인해주고 버전에 맞게 aws put-record 명령을 사용하면 된다고 함
위 명령에서 스트림 이름만 바꿔주고 실행
aws kinesis put-record --stream-name DemoStream --partition-key user1 --data "user signup" --cli-binary-format raw-in-base64-out
cloudshell 이 자동으로 iam 자격 증명을 구성한다고 함
강의에선 us-east-1 에서 실습이 진행된다고 함
data 내 문자를 몇번 바꿔가면서 명령을 입력해줬다
위처럼 데이터를 생성할 수 있다
이제 kinesis data streams 에서 데이터를 소비한다고 함
먼저 describe-stream 으로 스트림 구성 정보를 얻어와야 한다고 한다
위처럼 스트림 구성 정보를 얻어오면 샤드는 1개 있는걸로 확인되고
shardID 를 기억해놔야한다고 한다
스트림을 읽어올때 사용한다고 함
Kinesis client Library 를 사용한다면 이 과정은 라이브러리에서 처리된다고 함
샤드를 얻어올때 stream-name 과 shardID 를 입력해줘야 함
--shard-iterator-type 은 TRIM_HORIZON 인데 이는 샤드 반복자 유형으로 스트림의 처음부터 읽는다는 뜻 - 가장 처음 전송된 것부터 모든 레코드를 읽는다고 함
명령을 입력하게 되면 샤드 반복자가 반환되는데 샤드 반복자는 레코드를 소비할 때 다시 사용할 수 있다고 함
위 실습의 소비는 하위 수준 API 를 사용하여 스트림을 설명하고 샤드 반복자와 레코드를 얻어서 공유된 소비 모델을 이용한다
- 향상된 팬아웃을 사용하지 않음
kinesis client library 를 사용해서 좋은 API 를 활용하는게 바람직함
명령을 입력하면 batch 를 얻을 수 있음
파티션 키는 입력해준 user1 이고 base64 로 인코딩 되어있는 data 가 확인된다
base64 를 디코딩 할 수 있는 웹페이지로 가서 디코딩해보면
디코딩이 잘 되는걸 확인할 수 있다
아래 NextShardIterator 는 소비가 멈춘 곳을 의미하며 이 인자값을 사용해야 소비가 중지된 곳에서부터 소비를 시작할 수 있다고 한다
262. Kinesis Client Library (KCL)
시험에서는 시나리오 문제로 나올 수 있다고 함
java 라이브러리는 kinesis data streams 에서 읽기 워크로드를 공유하는 분산 애플리케이션의 레코드를 읽을 때 도움을 줌
각 샤드는 KCL 인스턴스에 의해서만 읽혀짐
- 4개의 샤드가 있다면 최대 4개의 KCL 인스턴스가 있고 6개의 샤드가 있다면 최대 6개의 KCL 인스턴스가 있다.
kinesis 클라이언트 라이브러리는 kinesis data streams 로 부터 데이터를 읽음
- 얼마나 읽었는지에 대한 진행상황을 dynamoDB 에 체크포인트로 남김 ( KCL 을 사용하는 인스턴스에 dynamoDB 에 IAM 권한이 필요함)
DynamoDB 덕분에 KCL 애플리케이션의 다른 작업자를 추적하고 샤드에 걸쳐 작업을 공유할 수 있음
KCL 은 원하는 어디에서든 실행할 수 있음 (ec2, beanstalk, on-premises)
레코드는 샤드 수준에서 순차적으로 읽게 됨
version -
KCL 1.x : 공유된 소비자만을 지원
KCL 2.x : 공유된 소비자와 향상된 팬아웃 소비자 모드를 모두 지원함
예시 (4 shards)
4개의 샤드가 있고 dynamoDB 테이블이 진행 상황을 확인함
동일한 KCL 애플리케이션 2개 ec2 에서 실행함
첫번째 앱은 샤드 1,2 에서 데이터를 읽고 , 두번째 앱은 샤드 3,4 에서 데이터를 읽을때
- data streams 를 읽은 진행 상황은 dynamoDB 에 체크포인트로 남김
예시2 (4 shards , scaling KCL app)
샤드가 4개 있고 4개 애플리케이션이 실행되며 각 샤드에 하나씩 읽는 상황일 때
인스턴스를 최대 4개까지 확장할 수 있음
샤드 수보다 인스턴스가 많아질 수는 없음 - 아무일도 하지 않는 애플리케이션 발생
263. Kinesis Operation
kinesis 를 스케일링하는 방법 (샤드 분할과 샤드 병합)
Shard Splitting (샤드 분할)
샤드를 2개로 분할할 때 사용함 - 즉, 더 많은 샤드를 갖는데 스트림의 용량을 늘릴 때 사용함
늘리는 샤드 당 초당 1MB 의 처리량을 얻을 수 있음
'hot shard' 를 나누고 싶을 때 사용함
위 예시에서 hot shard 인 샤드2를 분할해 샤드4,5 를 생성하고 결과적으로 스트림 처리량은 3MB/sec 에서 4MB/sec 으로 증가하게 된다
기존의 샤드는 종료되고 기존 데이터는 일정 시간 후에 만료됨
샤드가 늘어나는 만큼 용량도 늘어나지만 비용도 증가함
kinesis data streams 에 오토스케일링은 없음 - 솔루션 아키텍트를 통해 자신만의 오토 스케일링 기능을 만들 수 있지만 kinesis 에서 제공하는 오토스케일링 기능은 없음 - 수동)
한번에 샤드를 2개 이상으로 분할할 수는 없음
Merging Shards (샤드 병합)
용량을 줄이거나 비용을 절감하려 할 때 사용
트래픽이 적은 2개의 'cold shard' 를 그룹으로 묶어 하나의 새로운 샤드로 병합함
기존 샤드는 종료되고 데이터가 샤드에서 만료되면 삭제됨
한번에 2개 이상 샤드를 병합할 수는 없음
264. Kinesis Data Firehose 개요
생산자로부터 데이터를 가져옴
- 이때 생산자는 어떤 것이든 될 수 있음
생산자가 kinesis data firehose 에 레코드를 보내면 선택적으로 람다함수를 이용해 데이터를 변환함
데이터가 선택적으로 변환되면 도착지에 배치로 쓰임
kinesis data firehose 의 3가지 도착지
- AWS 도착지 : S3, Amazon Redshift(COPY through S3), Amazon ElasticSearch
- 3rd-party Partner Destinations : DataDog, Splunk, NewRelic, MongoDB
- Custom Destination : HTTP 엔드포인트가 있는 자체 API 를 사용한 사용자 정의 도착지
데이터를 모든 도착지에 보낸 후 2가지 옵션
- 모든 데이터를 s3 버킷에 보내 백업함
- 도착지에서 쓰기 실패한 데이터를 실패한 s3 버킷에 보낼 수 있음
요약
kinesis data firehose 는 완전 관리 서비스 - 관리 기능 없음, 오토 스케일링, 서버리스
- AWS : Redshift / S3 / ElasticSearch
- 3rd party partner : Splunk / MongoDB / DataDog / NewRelic / ...
- Custom : send to any HTTP endpoint
Firehose 를 통한 데이터에만 비용을 지불함
실시간에 가까움
- firehose 에서 도착지까지 배치로 데이터를 쓰기 때문
- 전체 배치가 아닌 경우, 최소 60초의 대기 시간이 필요함
- 데이터를 도착지에 보내려면 한번에 최소 32MB 이상의 데이터를 기다려야 함
- 실시간 서비스는 아니고 실시간에 가까운 서비스임 (Near Real Time)
다양한 데이터 형식, 변환, 압축을 지원함
원한다면 AWS Lambda 를 이용하여 자체 데이터 변환을 만들 수도 있음
실패한 데이터 또는 모든 데이터를 백업 s3 버킷에 보낼 수 있음
kinesis data streams VS firehose
- kinesis data streams
kinesis data streams 은 데이터를 대규모로 수집하는 스트리밍 서비스
생산자와 소비자 관련 자체 사용자 정의 코드를 작성함
200ms 또는 70ms 로 실시간임
스케일링은 자체적으로 관리 (샤드 분할이나 샤드 병합)
프로비저닝한 용량만큼 비용을 지불
데이터 저장은 1일~365일까지 가능
같은 스트림에서 여러 소비자를 읽을 수 있고 리플레이 기능을 지원함
- kinesis data firehose
데이터를 s3, Redshift, ElasticSearch, 3rd party, custom HTTP 스트리밍 하기 위한 수집 서비스
완전히 관리되기 때문에 관리할 서비스가 없고 실시간에 근접하지만 실시간은 아님
오토 스캐일링
kinesis data firehose 를 거치는 것의 비용만 지불
kinesis data firehose 의 데이터를 리플레이 할 수 있는 데이터 소스가 없음 - 리플레이 기능 없음
265. Kinesis Data Firehose 실습
firehose 실습을 위해 이전에 만들었던 데이터 스트림에서 전송 스트림(delivery stream) 에 들어가준다
create delivery stream 에 들어가보면 firehose 작동 방식을 확인할 수 있다
소스는 이전에 만들었던 data streams 를 선택해주고 대상(도착지) 는 s3 로 설정해줬다
s3 말고도 위 설명과 같이 redshift 나 elasticsearch 같은 aws 서비스와 3rd party 앱, custom http endpoint 가 있다
소스 설정으로 이전에 만들었던 stream 을 선택해주면 전송 스트림 이름은 자동으로 생성된다
레코드 변환은 선택 사항인데
이 부분에서 변환, 필터링, 압축 해제, 소스 레코드를 처리함
s3 버킷을 새로 만들고 선택해준다
이후 다른 옵션은 건들지 않고 다음
아래의 advanced settings 에서 버퍼 힌트, 압축, 암호화가 중요하다고 한다
버퍼는 kinesis data firehose 에서 대상에 전달하기 전에 레코드를 축적하는 방법이다
기본값으로 kinesis 는 대상인 s3 에 보내기 전에 데이터의 5MB 를 버퍼에 쓴다
버퍼를 효율적으로 만들기 위해 버퍼 용량을 줄이거나 키울 수 있다
버퍼 간격은 버퍼 크기가 채워지지 않은 경우, 대상에 얼마나 빨리 보내야 하는지를 나타내는 값이다
만약 300으로 입력하면 버퍼 크기를 채울때 까지 5분이 걸릴 것이다. - 5분뒤에도 버퍼 크기가 채워지지 않으면 아무것도 보내지 않을 것
데이터 레코드를 압축 할 수 있는데 4개의 방식으로 압축할 수 있다
암호화를 예/아니요 로 설정할 수 있다
이후 고급설정에서 IAM 역할을 생성할 수 있는데
기존 iam 역할을 선택하거나 새로 생성해준다 - 생성되는 iam 역할은 amazon s3 에서 쓰기에 필요한 모든 권한을 가지고 있음
이후 스트림 생성
이렇게 kinesis data streams 를 소스로 가진 kinesis data firehose 가 생성되었다
이제 데이터를 보내 테스트 한다고 한다
3개의 다른 메세지를 데이터 스트림으로 보내고 s3 에 데이터가 존재하는지 확인해본다고 한다
데이터를 위와 같이 보내주고 s3 버킷으로 가보면
객체가 없을 수 있는데 버퍼가 60초라 1분 기다리면 된다고 함
이후 기다리면 디렉토리가 보이고
타고 타고 들어가서 kinesis 파일을 들어가서 열기를 누르면 텍스트 에디터로 열리는데
이렇게 위에서 보냈던 데이터들이 차례대로 써져있다
띄어쓰기가 안되어있다 ㅋㅋ
이후 실습이 끝났는지 delivery stream 과 data streams 를 모두 삭제해 줬다
266. Kinesis 데이터 분석
sql 애플리케이션을 통한 kinesis 데이터 분석
kinesis 데이터 분석은 스트리밍 데이터 소스의 정보를 사용함
data streams 나 data firehose 의 소스에 sql 을 이용해 데이터를 분석
데이터 분석이 완료되면 출력 결과로 스트리밍이 발생하며 데이터 싱크로 이동하고 싱크는 새로운 스트림이 된다.
요약
실시간 분석을 수행할 수 있음
완전 관리형이라 서버 프로비저닝이 필요없음
오토 스케일링 덕분에 kinesis 데이터 분석 애플리케이션을 사용한 만큼만 비용이 청구됨
실시간 쿼리를 통해 스트림을 만들 수 있음
usecase:
- 시계열 분석(time-series analytics)
- 실시간 대시보드(real-time dashboards)
- 실시간 지표(real-time metrics)
267. SQS vs SNS vs Kinesis
SQS, SNS, Kinesis 의 차이점
SQS
소비자가 SQS 대기열에서부터 요청 메세지를 보내고 데이터를 끌어옴 (pull data)
데이터가 처리된 이후에 소비자는 대기열에서 해당 데이터를 삭제하여 다른 소비자가 다시는 읽을 수 없게 해야 함
원하는 만큼의 작업자(소비자)를 가질 수 있음
관리형 서비스 - 미리 처리량을 프로비저닝 할 필요 없음
방대한 수의 메세지를 빠르게 스케일링 할 수 있음
메세지 순서를 보장하려면 FIFO 대기열이라고 하는 선입 선출 방식을 사용하지 않아야 함
개별 메세지 지연 능력 - 특정시간 후에 대기열의 소비자가 메세지를 확인하도록 할 수 있음
SNS
Pub/Sub 모델이라고 하며 여러 구독자에 데이터를 푸시하면 보내는 메세지 사본을 모두가 수신할 수 있음
sns 토픽 당 최대 구독자는 12,500,000 명
데이터가 sns 로 보내진 후에는 더 이상 지속되지 않음 - 데이터가 전달되지 않는 경우 데이터를 손실할 수 있음
토픽 갯수는 10만개 제한
처리량을 프로비저닝 할 필요 없음
SQS 와 결합하는것도 가능함 - Fan-out 아키텍처 패턴을 사용
SNS FIFO 토픽을 SQS FIFO 대기열에 있는 SNS 와 결합할 수 있음
Kinesis
두가지 소비 모델
소비자가 kinesis 에서 데이터를 끌어오는 standard 형(pull data)
- 샤드당 1초에 2MB
소비 매커니즘의 향상된 팬아웃(enhanced fan-out) (push data)
- 각 소비자 샤드당 1초에 2MB
리플레이 가능
실시간 빅데이터, 분석, ETL 에 사용됨
샤드 레벨에서 순서가 지정됨 - 미리 kinesis 데이터 스트림 당 필요한 샤드를 지정해야 함 - 직접 스케일링 해야 함
기록시점에서 데이터 보존은 1일~365일 이다
처리량을 프로비저닝 해야 함
268. Kinesis 에 대한 데이터 정렬 vs SQS FIFO
개념과 기술이 비슷하지만 서로 다른 서비스라고 함
kinesis 정렬
가정 :
만약 100대의 트럭이 도로에 있고 gps 추적을 정기적으로 aws 에 보냄
당신은 트럭의 이동 경로 파악을 위해 트럭의 정렬된 데이터를 소비하길 원한다
해답 :
파티션 키 사용 - 파티션 키 값은 트럭 id 가 됨
- 같은 파티션 키를 지정하면 해당 키가 언제나 동일한 샤드로 전달됨
sqs 정렬
sqs 표준 방식에는 순서가 없음
sqs fifo 라는 선입 선출 방식을 사용, 이 sqs fifo 의 그룹 id 를 사용하지 않으면 모든 메세지가 소비되는 방식은 보내진 순서에 따르며 소비자는 하나만 존재함
만약 소비자층을 스케일링하고 싶다면 그룹 id 를 사용 - 파티션 키와 개념이 비슷함
- 그룹 id를 사용하면 fifo 내부에 두개 그룹이 생기고 정의한 그룹마다 각각 소비자를 가질 수 있게 됨
- 두개의 소비자인 소비자 1과 소비자 2는 독자적으로 그룹1과 그룹2를 읽기 할 수 있음
- 그룹 id가 많을 수록 소비자도 많아짐
Kinesis 정렬 vs SQS 정렬
가정 : 100대의 트럭, kinesis 샤드가 5개 sqs fifo 대기열이 1개
kinesis data streams 에서 평균적으로 가지는 값
- 샤드 당 트럭 20대
- 각 트럭 데이터는 각 샤드에 순서대로 정렬됨
- 하지만 동시에 가질 수 있는 최대 소비자 개수는 5개 뿐
- kinesis 데이터 스트림은 샤드가 5개인 경우 초당 최대 5MB 의 데이터를 수신할 수 있음 (처리량이 꽤 많은 편)
- 예를들어 트럭 10,000 대가 많은 데이터를 전송하고 또 kinesis 데이터 스트림에 샤드당 데이터를 정렬할 때 적합한 모델
SQS FIFO 의 경우
- sqs fifo 대기열은 하나 뿐
- 각 트럭id 에 상응하는 그룹 id를 100개 생성
- 소비자도 최대 100개가 될 수 있음 - 각 소비자가 특정한 그룹 id와 연결됨
- sqs fifo 에서 최대 초당 300개, 혹은 배치를 사용하면 3,000개 메세지를 가짐
- 그룹 id 숫자에 따른 동적 소비자 수를 원할 때 적합한 모델