[AWS] aws 강의 섹션 19 - 2 (SNS, Kinesis 분석)

SNS

• 메시지 하나를 여러 수신자에게 보내고 싶을 때 Direct intergration을 쓸 수 있다.
  • 구매 서비스를 예로 들면,
    구매시 email 알림 서비스, 배송 서비스, SQS 대기열에 메시지를 보낼 수 있다.
  • 매번 보낼 때마다 이들을 통합해서 메시지를 보내는 건 번거로울 수 있다.
• 대신 Pub/Sub 즉, 게시/구독이라는 개념을 사용할 수 있다.
  • 구매 서비스가 메시지를 AWS SNS로 보내는 것이다.
  • SNS Topic에 게시를 하면 해당 Topic를 구독한 많은 구독자들은 메시지를 수신한다.

• 이벤트 생산자는 오직 한 SNS Topic에 메시지를 보낸다.
• 이벤트 수신자 즉, 구독자는 해당 주제와 관련된 공지를 받으려는 사람이다. 
  • 구독자는 해당 SNS Topic으로 전송된 메시지를 모두 받게 된다.
    • 메시지 필터링 기능도 존재한다.
• 한 Topic 별 최대 구독자 수는 1,250만이다.
• 계정당 가질 수 있는 주제 수는 최대 10만 개이다.

SNS에서 주제로 게시할 수 있는 것은 뭐가 있을까?

• 이메일
• sms 및 모바일 알림
• 지정된 Http/s 엔드 포인트로 직접 데이터를 보낼 수도 있다.
• SQS 같은 특정 AWS 서비스와 결합하여, 메시지를 대기열로 보낼 수도 있고
• 메시지를 수신한 후 함수가 코드를 수행하도록 람다에 보낼 수도 있다.
• Firehorse를 통해 S3나 RedShift로 보낼 수도 있다.

SNS는 다양한 AWS 서비스와 통합이 가능하다

많은 AWS 서비스가 SNS로 알림을 보낼 수 있다.

SNS - How to publish

• SDK를 사용하여 주제를 게시할 수 있다.
  1. 주제를 만든다
  2. 구독자를 만든다
  3. 주제에 게시할 것을 올린다.
  4. 구독자들은 해당 메시지를 받게 된다.
• 모바일 앱 전용 SDK Direct Publish 방식이 있다.
  1. 플랫폼 애플리케이션을 만든다
  2. 플랫폼의 엔드포인트를 만든다
  3. 엔드포인트에 메시지를 게시한다
  4. 수신 가능 대상은 Google, GCM, Apple APNS 등이 있다. 
  5. 모두 모바일 애플리케이션으로 알림을 수신하게 된다.

SNS - Security

• SQS와 동일하다.
• 전송중 암호화
  • HTTPS API를 사용
• 대기중 암호화
  • KMS 키를 사용
• 클라이언트 암호화
  • 알아서 해야한다.
• Access Controls
  • IAM 정책으로 SNS API 접근을 제어한다.
• SNS Access Policies
  • S3 버킷 정책과 매우 유사하다.
    • 버킷 단위로 접근을 제한하는 버킷 정책
  • SNS topic에 교차 계정 액세스 권한을 주거나 
  • 다른 서비스에서 SNS topic에 메시지를 게시할 수 있도록 권한을 부여하는데 유용하다.

SNS + SQS: Fan Out 패턴

• 다수의 SQS 대기열로 메시지를 보내려 할 때, 모든 SQS 대기열에 개별적으로 전송하면
  비효율 적이고, 수신자가 많아질수록 발신자의 부담이 늘어난다.
• 따라서 SNS topic에 게시만 하고, SQS 대기열들을 구독 시키면,
  전송 과정은 모두 SNS에서 부담하니, 애플리케이션의 부하가 준다.
  • SQS를 사용하므로 데이터 지속성, 지연 처리, 작업 재시도 등의 효과를 얻을 수 있다.
  • SQS 큐에 대해 SNS 가 전송할 수 있도록 권한을 허용해줘야 한다. 
• 교차 리전 전송
  • SNS topic에서 다른 지역의 큐로 메시지를 보내는 것도 가능하다.

S3 Events to multiple queues

• S3 이벤트를 여러 개의 대기열로 보낼 때를 가정해보자
• S3는 같은 이벤트 타입과 접두사 내에서 오직 한 개의 이벤트 규칙을 만들 수 있다.
  • 예를 들어, 
  • 이벤트 타입: S3 객체가 생성될 때
  • 접두사: images/
  • 규칙: 이미지 저장
  • 같은 규칙으로 하나의 이벤트 타입과 접두사에 대해 하나의 규칙만 만들 수 있다.
• 만약, 여러 개의 대기열로 동일한 S3 이벤트 알림을 보내고 싶다면 어떻게 해야 할지 알아보자.

• 이 때도 fan out 패턴을 사용해야 한다.
• 예를 들어 버킷이 생성되어 이벤트가 발생했을 때
  • 이벤트를 SNS 주제로 전송하고 
  • 여러 개의 큐가 SNS 주제를 구독하게 하면 된다.
  • 이 fan out 형태를 사용해서 이메일이나 람다 함수 등도 구독 시켜
  • 서로 다른 목적지로 안전하게 전송할 수 있다.

SNS에서 Firehose를 사용하여 S3로 데이터 보내기

• SNS와 Kinesis Data Firehose(KDF)가 직접적으로 통합되어있기 때문에
  • SNS에서 KDF로 메시지를 바로 보내고
  • KDF에서 S3 버킷으로 메시지를 보낼 수 있다. 
    • 아니면 지원되는 KDF 특정 목적지 어디든 가능하다.
    • 이렇게 전송 범위를 늘릴 수 있다.

SNS - FIFO Topic

• SNS에는 FIFO 기능이 있다.
• 구독자는 SQS FIFO 대기열로 순서대로 메시지를 받는다.
• 이제 SQS 큐에서 각 애플리케이션이 메시지를 가져가 기능을 수행할 수 있다.

SNS - Message Filtering

• SNS topic 구독자들에게 전송할 메시지를 필터링하는 정책이다.
• Json으로 작성한다.
• 만약 구독에 필터링 정책을 설정 안 했다면, 기본적으로 모든 메시지를 수신하게 된다.

• 위와 같이 큐마다 다른 필터링 조건을 설정해서 보낼 수 있다.
  • 위의 예시는 state를 기준으로 필터링을 했다.

Kinesis

• 키네시스는 실시간 데이터 스트리밍을 처리하고 분석할 수 있는 관리형 서비스다.
  • 다양한 유형의 데이터를 수집하고 처리한 뒤 다른 서비스로 전달할 수 있다.
  • 대규모 데이터 스트리밍을 처리해야 하는 애플리케이션에 유용하다.
• 사용 예시:
  • 실시간 분석 대시보드
    • 수많은 클릭 데이터를 kinesis로 수집하고, 실시간으로 처리하여 대시보드에 표시
  • Iot 데이터 처리
    • 센서에서 수집된 데이터를 키네시스에서 실시간으로 모니터링 후 특정 조건에서 알림 처리
  • 로그 분석
    • 여러 서버에서 생성되는 로그를 키네시스로 수집하고 분석
• 다음과 같은 종류의 서비스가 존재한다.
  1. Kinesis Data Streams: 데이터 스트림을 입력, 처리하고 저장한다.
  2. Kinesis Data Firehose: 수집한 데이터를 지정된 저장소로 전달하는 서비스
  3. Kinesis Data Analytics: SQL 등으로 데이터를 분석하는 서비스 

Kinesis Data Streams

• 시스템의 빅 데이터를 스트리밍 하는 기능이다.
• 키네시스 데이터 스트림은 번호가 매겨진 여러 샤드로 구성된다.
  • 샤드는 사전에 공급되어 있어야 한다.
  • Kinesis 데이터 스트림을 시작할 때 미리 6개의 샤드가 있는 스트림을 만드는 식이다.
• 모든 샤드에 걸쳐 데이터가 분할 되고, 샤드가 수집 및 소비율에 맞춰 스트림 용량을 정의한다.
• 여러 생산자가 데이터 스트림에 데이터를 보낼 것이다.
  • 생산자들은 모두 Kinesis Data Streams 레코드를 생성하고 보낸다.
  • 레코드는 두 가지로 구성된다.
    1. 파티션 키 : 레코드가 어느 샤드로 아동할지 정의 
    2. 최대 1MB 크기의 데이터 blob
  • 생산자가 키네시스 데이터 스트림으로 데이터를 보낼 때는,
    샤드당 1MB/s 로 데이터가 전송된다. 
    • 샤드가 6개라면 총 6MB/s 속도인 것이다. 
• 소비자가 레코드를 수신할 때는 파티션 키와 함께
  레코드가 샤드에 있었던 위치를 나타내는 시퀀스 번호 그리고
  데이터 블롭을 받는다.
  • 레코드를 수신하는 처리량은
  • 2MB/s 이다.

Kinesis Data Streams - attributes

• 1~365일 사이의 보유 기간을 설정할 수 있다.
  • 긴 보유 기간을 통해 데이터를 다시 사용할 수 있다는 의미다.
• Kinesis에 삽입된 데이터는 삭제가 불가능하다.
• Kinesis Data Strema으로 데이터를 보내면 파티션 키가 추가되는데
  같은 파티션 키를 공유하는 메시지는, 동일한 샤드로 이동한다.
• 생산자는 AWS SDK, Kinesis Producer Library (KPL), Kinesis Agent 등으로 
  키네시스에 데이터를 보낼 수 있다.
• 소비자는 Kinesis Client Library, AWS SDK,
  Lambda, Kinesis Data Firehose, Kinesis Data Analytics 등으로 받을 수 있다.

Kinesis Data Streams - Capacity Modes

• provisioned mode:
  • 몇 개의 샤드 프로비저닝을 선택해서 만들고, 수동으로 또는 APi를 사용해서 확장하는 방법이다.
  • 샤드당 1MB/s 의 속도를 가진다. or 1초당 1000개의 레코드 
  • 출력의 경우는 샤드당 2MB/s 이다.
  • 시간당 샤드 비용이 나간다. 
• On-demand mode
  • 용량을 프로비전할 필요가 없다.
  • 수요에 맞춰 알아서 조정된다.
  • 4MB/s or 4000 레코드/ s 의 처리량을 가진다
  • 지난 30일 간의 피크 처리량에 기반해 오토 스케일링이 수행된다.
  • 시간당 스트림 비용 그리고 들어오고 나가는 GB 단위로 비용이 청구된다.

Kinesis Data Streams - Security

• 리전 내부에서 배포한다.
• IAM 정책을 사용해 샤드 생성 및 읽기, 액세스에 대한 권한을 정할 수 있다.
• 암호화
  • 전송중 암호화 : HTTPS
  • 저장중 암호화: KMS 키
  • 클라이언트 측 암호화
• VPC 엔드 포인트도 Linesis에 적용할 수 있다. 
  • 인터넷을 거치지 않고 VPC 내부 Private 서브넷에서 VPC 엔드 포인트를 통해 Kinesis에
    직접 액세스가 가능해진다.
• Cloud Trail로 모든 API 호출을 모니터링 할 수 있다. 

Kinesis - Producer

• 데이터를 데이터 스트림에 보낸다.
• 데이터 레코드 구성
  • 시퀀스 넘버: 파티션 키 별로 고유값을 가진다.
  • 파티션 키: 레코드를 스트림에 넣을 때 반드시 지정해야 한다.
    어느 샤드에 레코드를 저장할지 지정하는 역할이다.
  • 데이터 블롭: 최대 1MB 이다. 보내려는 값이 들어간다.
• 생산자
  • AWS SDK
  • Kinesis Producer Library (KPL): 각종 언어 지원
    SDK 위에 구축 되는데, 배치 처리, 압축, 재시도 등의 고급 기능을 지원한다.
  • Kinesis Agent: 라이브러리 위에 구축되는데, 로그 파일을 모니터링 하고
    이 로그 파일을 보낼 때 사용한다.
• 쓰기 처리량
  • 1MB/s,    1000records/s    per 샤드
• PutRecord API 를 통해 키네시스에 데이터를 보낼 수 있다.
  • PutRecord API의 배치를 이용하면 비용을 절감할 수 있고
    처리량을 늘릴 수 있다.

• 이 예시의 경우 파티션 키는 디바이스 ID 로 설정했다.
  • 파티션 키는 해시함수를 거쳐 샤드 넘버로 변환된다.
  • 해시함수를 통해 같은 디바이스 ID는 같은 샤드에 저장된다.
• 데이터가 한 샤드에 몰리지 않게 파티션 키를 잘 분배하자 

Kinesis - ProvisionedThroughputExceeded

• 데이터가 한 샤드에 과도하게 몰리면 이러한 예외가 발생한다.
  • 샤드당 1MB/s 라는 프로비저닝된 처리량을 초과했기 때문이다.
• 해결 방법은
  1. 피티션 키를 잘 분산해서 데이터가 몰리지 않게 하기
  2. exponential 백오프를 사용해서 예외가 발생했을 때 재시도 할 수 있게 만들어야 한다.
  3. 샤드 스케일링: 샤드를 늘려 처리량 문제를 해결한다.
     샤드가 늘어나면 샤드 1개당 1MB/s 만큼 처리량이 상승하기 때문이다.

Kinesis - Consumers

• 스트림으로부터 레코드를 가져와서 처리한다.

등으로 레코드를 가져올 수 있다.

Consumer - Classic 과 Enhanced 소비자의 차이점 

• Shared (Classic) Fan-out Consumer 
  • 모든 소비자가 샤드당 2MB/s의 처리량을 나눠 가진다.

• 이 예시에서 A, B, C의 소비자들은 한 샤드를 공유하고 있기 때문에
  각각, 666KB/s 의 처리량을 가진다. 
• Enhanced Fan-out Consumer
  • 클래식과 달리 샤드당 2MB/s 의 처리량을 가진다. 처리량을 공유하지 않는다.

• 여기서 샤드 하나의 처리량은 6MB/s가 된다. 

classic, enhanced 요약

• Shared(Classic) Fan-out Consumer
  • pull 모델로 소비하는 어플리케이션이 적을 경우에 유용하다. 
  • 처리량은 샤드당 2MB/s를 모든 사용자가 공유한다.
  • 샤드별로 초당 최대 5개의 GetRecords API를 호출할 수 있다.
  • API 호출의 지연 시간은 약 200ms이다.
  • 비용을 절감할 때 사용한다.
  • 사용자는 GetRecords API 호출을 통해 키네시스로부터 레코드를 직접 pull하고
    데이터를 최대 10MB까지 반환한다. 
• Enhanced Fan-out Consumer
  • push 모델로 소비하는 어플리케이션을 여러 개 가질 수 있다.
  • 각 소비자는 샤드별로 2MB/s 의 처리량을 가진다.
  • 지연 시간은 약 70ms 이다.
    • 샤드 자체에서 데이터를 소비자로 푸시하기 때문에 지연시간이 적다.
  • 비싸다
  • HTTP/2 프로토콜을 활용해서 데이터가 푸시된다. 
    • Subscribe ToShard API를 호출한다.
      • 이 API를 호출하면 특정 샤드에 구독을 하는 것이다.
      • 이후 자동으로 데이터를 푸시받는다. 
  • 스트림당 최대 5개의 소비자 어플리케이션을 사용할 수 있다는 제약이 있다. 
    • 돈 더 내면 늘릴 수 있다.

Kinesis Consumers - Lambda

• 람다 함수가 소비자가 되는 경우다
• GetBatch() 함수를 통해 배치로 레코드를 읽는다.
  • 배치 크기와 배치 window를 구성할 수 있다.
• Classic과 Enhanced 모드 둘 다 지원한다.
• 오류가 발생한다면, 성공할 때까지 람다가 재시도하거나
  키네시스에서 데이터가 만료될 것이다.
• 동시에 샤드당 최대 10개의 배치를 처리할 수 있다.

Kinesis Client Library (KCL)

• KCL은 키네시스 데이터 스트림에서 읽기 작업을 하는 소비 애플리케이션이 많을 때,
  해당 작업을 쉽게 도와주는 라이브러리다.
• 각 샤드는 KCL 인스턴스에 의해서만 읽힌다.
  • 4개의 샤드가 있다면 최대 4개의 KCL 인스턴스가 존재한다.
• KCL은 데이터스트림에서 데이터를 읽어올 때 어디까지 읽었나 하는 체크포인트를 DynamoDB에 남긴다.
  • 따라서 KCL을 실행하는 애플리케이션은 DynamoDB에 IAM 액세스가 필요하다.
  • Dynamo DB 덕분에 KCL 애플리케이션의 다른 작업자를 추적하고 
    여러 샤드에 걸쳐 작업을 공유할 수 있다.
• KCL은 EC2, 일래스틱 빈 스톡, 온 프레미스 서버 어디서도 사용 가능하다.
• 레코드는 샤드단위로 읽힌다.
• 버전은 두 개가 있다.
  • KCL 1.x (Classic [Shared]만 지원)
  • KCL 2.x (Classic, enhanced 둘 다 지원)

• 다음과 같이 두 개의 KCL 애플리케이션에서 각기 다른 샤드를 읽고 있었을 때
  Dynamo DB 덕분에 체크 포인트를 공유할 수 있다.
  • 만약 한 개의 애플리케이션이 종료했다 하더라도,
    다른 애플리케이션에서 체크 포인트를 통해 나머지 샤드를 다 읽을 수 있다.

• 만약 샤드가 4개에서 6개로 갑자기 조정됐다해도, 체크포인트를 통해 
  인스턴스에 작업을 적절하게 분배할 수 있다.

Kinesis - 샤드 분할

• 샤드 분할은 샤드를 2개로 분할할 때 사용한다.
  • 스트림의 용량을 늘릴 때 사용한다.
  • 샤드당 1MB/s 데이터 전송량 획득
• 한 샤드에 데이터가 많이 몰릴 때도 사용한다.

• 그러나 샤드 개수가 늘어났기 때문에 비용도 늘어난다.
• 기존에 존재하던 샤드2는 닫히고 데이터는 기간이 다 지나고 나면 삭제된다.
• 키네시스에서 자동 스케일링은 존재하지 않는다. 
  • 이를 위한 솔루션 아키텍쳐가 따로 존재하긴 하나, 키네시스 내부에선 지원하지 않는다.
  • 수동으로 용량을 늘리거나, 줄여야 한다.
• 한 번에 샤드를 두 개 이상으로 분할할 수 없다.
  • 여러 개로 샤드를 분할하고 싶다면 여러 번 샤드 분할을 시도해야 한다.

Kinesis - 샤드 병합

• 트래픽이 적은 2개의 샤드를 묶어 하나의 샤드로 만든다.
• 용량과 비용을 줄일 때 사용한다.
• 기존 샤드는 종료되고, 기간이 다 지나고 나면 데이터가 삭제된다.
• 한 번에 2개 이상의 샤드를 병합할 수 없다.

Kinesis Data Firehose

• 마찬가지로 생산자로부터 데이터를 가져올 수 있는 기능이다.
• 생산자는 여러가지가 가능한데, Kinesis Data Streams도 생산자가 될 수 있다.
  • 이후 들어온 데이터를 람다 함수를 이용해 데이터 변환도 진행할 수 있지만,
    이는 선택 사항이다.
  • 이후 데이터를 일괄적으로 대상에 저장할 수 있다. 
• AWS에서 데이터가 저장되는 장소는 총 세 가지가 있다.
  1. 아마존 S3
  2. Redshift (웨어하우징 데이터베이스) - 아마존 S3의 데이터를 복사해서 저장한다
  3. 아마존 OpenSearch 
     
     • 이 외에 타사 파트너 수신처가 있어서
     • Datadog, Splunk, New Relic, MongoDB로 데이터를 보낼 수 있다.
     • 추가로 HTTP 엔드포인트가 있는 자체 API가 있는 경우 ,
       해당 지정 수신처로 데이터를 보낼 수 있다.
• 모든 데이터를 백업으로 S3 버킷으로 보낼 수도 있고,
  수신처에 기록하기를 실패한 데이터를 S3 버킷으로 보낼 수도 있다.

다시 정리

• 완전 관리형 서비스다.
• 관리가 필요 없으며 자동 스케일링에 서버리스이므로 관리해야할 서버가 없다.
  
  • Redshift, S3, OpenSearch 같은 AWS 수신처로 데이터를 보낼 수 있다.
  • 타사 파트너에도 보낼 수 있고
  • 특정 엔드포인트에도 보낼 수 있다.
    • 이 경우는 firehose를 통과하는 데이터에 대해서만 비용을 지불한다.
• 매우 합리적인 가격이며 거의 실시간으로 작동한다.
  
  • 데이터를 버퍼에 잠시 저장해두고 나중에 전달하기 때문이다.
    • 버퍼에 데이터를 모아 크기 기준 도는 시간 기준으로 수신처로 전송한다.
      • 예를 들어, 5MB의 데이터가 모이거나, 1분이 지나면 데이터를 전송하도록 할 수 있다.
      • 버퍼 사이즈는 최소 1MB이다.
      • 시간은 0초에서 최대 900초까지 설정할 수 있다.
      • 사이즈 조건과 시간 조건을 동시에 설정할 수도 있다.
    • 버퍼링이 잘 되어 있으면 거의 실시간 서비스가 된다.
• 여러 데이터 형식과 전환, 변환, 압축을 지원하며
  • 필요한 경우 람다를 사용하여 자체적인 변환도 쓸 수 있다.
• 실패한 모든 데이터를 백업 S3 버킷으로 보낼 수 있다. 

Data Streams와 Firehose의 차이점

• data Streams
  • 대규모 데이터를 수집하는 데 사용되는 스트리밍 서비스이며
  • producer와 consumer를 위한 내부 처리 코드는 직접 작성한다.
  • 실시간으로 지연시간은 70ms 또는 200ms이다.
  • 스케일링은 수동으로 해야 한다.
  • 규모와 처리량을 늘리고 줄이기 위해 샤드 분할과 샤드 병합을 수행한다.
  • 데이터 저장 기간은 1~365일까지 설정할 수 있다.
  • 여러 소비자가 동일한 스트림에서 읽을 수 있게 지원한다.
• Firehose
  • 데이터 수집 서비스로 각종 저장소로 보낸다.
  • 완전히 관리된다.
  • 실시간 서비스는 아니지만 거의 근접히다
  • 자동 스케일링이 된다.
  • firehose를 통과하는 것에만 비용을 지불한다.
  • 데이터 스토리지가 없으므로 firehose에서 데이터를 재생할 수 없다.

Kinesis Data Analytics for SQL applications

• 키네시스 데이터 스트림, firehose로 부터 데이터를 가져온다
• 분석을 위해 SQL 구문을 넣어둔다.
  • 필요하다면 부가 데이터를 S3에서 가져올 수 있다.
• 이후 분석 데이터를 다양한 목적지로 보낼 수 있는데 방식은 두 가지다.
  1. 키네시스 데이터 스트림
  2. 키네시스 데이터 firehose

• 데이터 소스는 데이터 스트림과 파이어 호스다.
• 데이터를 가져오기 위해 서버는 필요하지 않다. 완전 관리 시스템이다.
• 자동으로 스케일링 된다.
• 실제 소비량에 따라 돈을 지불한다.
• 출력
  • 데이터 스트림이나 파이어호스를 사용하먄 된다.
• 사용 예시
  • 시분할 분석
  • 실시간 대시보드
  • 실시간 측정

Kinesis Data Amalytics for Apache Flink

• 아파치 Flimk를 위한 것이다.
• flink를 사용할 때 자바나 스칼라 또는 SQL을 이용해 애플리케이션을 만들어
  데이터 처리 및 분석을 할 수 있다.
  • 이 flink 애플리케이션은 키네시스 데이터 분석 전용 클러스터에서 실행이 되는데
    모두 백그라운드에서 실행된다.
• 데이터 소스는 Kinesis Data Streams 와 Amazon MSK다
  • 이 두 개를 통해 AWS의 클러스터에서 아파치 Flink 애플리케이션을 구동할 수 있다.
    즉, SQL보다 훨씬 많은 것을 구현하고 실행할 수 있다.
• 컴퓨팅 자원 프로비저닝이 가능하고, 병렬 계산 및, 오토 스케일링도 가능하다.
  • 체크 포인트나 스냅샷으로 구현되는 애플리케이션 백업이 가능해지고 
  • 아파치 Flink 프로그래밍 기능도 다 사용 가능하다.
• firehose는 사용이 불가능하다.
  • 이를 원한다면 SQL 버전을 사용해야 한다.

Kinesis - 정렬

• 도로에 트럭이 100대가 있고 각각 트럭 id가 있다고 하자
• 모두 도로 위에 있으며, GPS를 통해 위치를 주기적으로 AWS에 보낼 것이다.
• 이제 각 트럭의 순서대로 데이터를 소비해서 트럭의 이동을 정확하게 추적하고
• 그 경로를 순서대로 확인하려고 한다.
• 어떻게 kinesis로 데이터를 전달할까?
  • 바로 파티션 키를 사용하면 된다.
  • 이 때 파티션 키 값은 트럭 ID다
  • 같은 파티션 키를 갖고 있다면 언제나 동일한 샤드로 전달이 된다.
• 간단하게 설명하면 같은 파티션 키를 사용하면
  특정 샤드에 시간대 별로 쭉 데이터가 저장 되니까 그거 순서대로 가져오면 그냥 위치 추적이 가능하다는 얘기다.

 

SQS로 데이터 보낼 때 정렬

• SQS 표준 방식에는 정렬이 없다
• 그래서 FIFO 방식이 있다.
• FIFO 방식에서 그룹 아이디를 사용하지 않으면 그저 도착한 순서대로 정렬을 한다.
  • 소비자는 하나만 존재한다.
• 모든 트럭을 FIFO 대기열로 데이터를 보내더라도 소비자는 하나뿐이다.
• 서로 연관된 메시지를 그룹화 하려면 그룹 ID가 필요하다
  • 파티션 키와 개념이 비슷하다.
  • 만약 그룹 ID를 만든다면 그룹 별로 소비자를 가질 수 있게 된다.

뭔 말인지 설명 하나도 못알아 듣겠어서 그냥 내가 이해한대로 정리

• 만약 트럭이 100대라면, 그룹 Id를 100개를 만들어 독립적으로 확실한 순서를 보장할 수 있다.

정리

• FIFO는 확실한 메시지 순서 보장이 중요한 경우에 사용하면 좋다.
• data 스트림은 많은 데이터를 처리해야 하고, 병렬 데이터 처리를 원할 때 사용하자

SQS, SNS, 키네시스의 차이점

• SQS
  • SQS는 소비자가 큐에서 메시지를 요청해서 가져오는 모델이다.
  • 데이터를 처리한 후 소비자가 대기열에서 삭제해서
    다른 소비자가 읽지 못하게 해야 한다.
  • 작업이나 소비자 수는 제한이 없다. 
  • 관리되는 서비스이므로 처리량을 프로비저닝할 필요 없다.
  • 순서를 보장하려면 FIFO 대기열을 사용하자
  • 각 메시지에 지연기능이 있어 일정 시간 후에 대기열에 나타나도록 할 수도 있다.
• SNS
  • 게시/ 구독 모델로 다수의 구독자에게 데이터를 푸시하는 것이다.
  • 주제 별로 1250만 명의 구독자까지 가능하다.
  • 데이터가 한 번 SNS에 전송되면 저장되지 않는다.
    • 즉, 중간에 데이터가 유실됐다면, 아예 잃어버릴 가능성이 있다.
  • 주제는 최대 10만개까지 가능하다.
  • 프로비저닝할 필요 없다.
  • SQS와 결합 가능하다.
    • 팬아웃 아키텍쳐를 사용해 SQS와 결합한다.
• Kinesis
  • 스탠다드 모드: 소비자가 데이터를 직접 가져오는 모드다
    • 샤드 당 2MB의 속도를 지원한다.
  • enhanced-fan out 모드: 소비자에게 데이터를 푸시한다.
    
    • 소비자 별로 2Mb/s 의 속도를 보장한다.
    • 처리량이 훨씬 높다.
    • 비용도 훨씬
  • 데이터가 저장되기 때문에 데이터를 재사용할 수 있다.
    • 따라서 실시간 빅 데이터 분석 등에 활용된다.
    • 1~365일까지 데이터를 저장할 수 있다.
  • 샤드 레벨에서 각종 옵션을 지정한다.
  • 용량 모드는 두 개가 있다.
    • 프로비저닝 모드: 미리 샤드 양을 지정하는것
    • 온디맨드: 샤드 수가 스트림에 따라 자동으로 지정된다.