참고
Amazon Kinesis
NOTE
실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석할 수 있는 서비스!
•
Kinesis Data Streams
◦
데이터 스트림을 수집하여 처리하고 저장
•
Kinesis Data Firehouse
◦
데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 불러옴
•
Kinesis Data Analytics
◦
SQL 언어나 Apache Flink를 활용하여 데이터 스트림을 분석
Fan out pattern
NOTE
SNS 주제로 한 번 메세지를 전송하면 원하는 숫자 만큼의 SQS 대기열들이 SNS 주제를 구독해서 SNS로 전송된 모든 메시지들을 수신할 수 있도록 하는 것!
SNS로 하나의 메세지를 보내면 SQS대기열 2개가 모두 메세지를 읽을 수 있게됨!
•
SQS는 SNS의 Sub가 되는 것!
Kinesis Data Streams(KDS)
NOTE
샤드에 데이터 분배!
Partition Key값 = truck_id (동일 shard로 데이터를 보내므로 시간순으로 받음)
•
샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정한다.
•
보존기간은 1~365일 사이로 결정 가능
•
데이터가 Kinesis로 들어오면 삭제 불가능, 불변성
•
메세지를 전송하면 파티션 키가 추가되고, 메세지들은 키를 기반으로 같은 파티션 데이터끼리 정렬
•
생산자
◦
Application, SDK, KPL(Kinesis Producer Library), Kinesis Agnet
•
소비자
◦
KCL(Kinesis Consumer Library), SDK를 써서 직접 데이터 작성 가능, Labmda 활용가능
Kinesis Data Firehouse(KDF)
NOTE
완전 관리형 서비스로 자동으로 크기가 조정되는 서버리스 서비스
•
여러 데이터 형식과 데이터 전환, 변환, 압축 지원
•
실시간에 가까운 근 실시간 서비스(완전한 배치가 아닌경우 최소 60초의 지연시간 지님)
•
모든 데이터를 백업 S3 버킷에 전송 가능
KDS vs KDF
NOTE
KDS
•
데이터를 대규모로 수집할 때 쓰는 스트리밍 서비스
•
생산자와 소비자에 대해 커스텀 코드 사용 가능
•
실시간으로 이루어지며 약 70~200ms 정도의 지연시간 발생
•
제공한 용량만큼 큰 비용을 지불
•
반복작업 가능
KDF
•
Amazon S3, HTTP 엔드포인트 DataDog 등에 스트리밍
•
완전 관리형 서비스이며 서버리스
•
근 실시간 서비스
•
자동으로 용량 조정
•
반복작업 불가능
SQS vs SNS vs Kinesis
NOTE
SQS
•
소비자가 SQS 대기열에서 메세지를 요청해서 가져오는 pull 모델
•
데이터를 처리한 후 소비자가 대기열에서 삭제해야 함
•
작업자와 소비자 수의 제한은 없음
•
순서 보장을 위해 FIFO 대기열 활성화 가능
SNS
•
Pub/Sub 모델
•
다수의 구독자에게 데이터를 푸시하면 메세지의 복사본을 받을 수 있음
•
SNS 주제 별로 1200만명의 이상의 구독자 가능
•
처리량에 대해 프로비저닝 할 필요 없음
•
팬아웃 아티텍쳐 패턴을 이용하여 SNS와 SQS 결합 가능
Kinesis
•
소비자가 Kinesis로부터 데이터를 가져오는 pull 표준 모드 - 샤드 당 2MB/s 속도
•
Kinesis가 소비자에게 데이터를 보내는 push 향상된 팬아웃 모드 - 샤드 하나에 소비자 당 2MB/s 속도
•
KDS에서 데이터가 지속되기 때문에 반복 작업 가능
•
실시간 빅 데이터 분석에 활용
Amazon MQ
NOTE
•
RabbitMQ와 ActiveMQ를 위한 관리형 메세지 브로커 서비스
•
MQTT, AMQP, STOMP 등과 같은 메시지 프로토콜 지원
•
SQS, SNS처럼 확장성이 크지 않음
•
고가용성을 위해 장애 조치와 함께 다중 AZ 설정
•
SQS처럼 보이는 대기열 기능과, SNS 처럼 보이는 주게 기능을 단일 브로커의 일부로 제공