[SAA] SQS vs SNS vs Kinesis

SQS vs SNS vs Kinesis

• SQS 모델
  - 소비자가 SQS 대기열에서부터 요청 메시지를 보내고 데이터를 끌어옴
  - 데이터가 처리된 이후에 소비자는 대기열에서 해당 데이터를 삭제하여 다른 소비자가 읽을 수 없게 해야 함
  - 원하는 만큼의 소비자를 가질 수 있고 대기열에서 모든 메시지를 소비하고 삭제하도록 모든 소비자가 함께 작업
  - 관리형 서비스이므로 미리 처리량을 프로비저닝할 필요 없고 방대한 수의 메시지를 빠르게 스케일링할 수 있음
  - FIFO Queues는 FIFO 대기열을 사용할 수 없는 경우에만 사용할 수 있으며 먼저 들어온 것이 먼저 나오는 유형의 큐
  - 개별 메시지 지연 능력이 있어서 특정 시간 후에 대기열의 소비자가 메시지를 확인하도록 할 수 있음
• SNS 모델
  - Pub/Sub 모델이라고 하면 여러 구독자에 데이터를 푸시하면 보내는 메시지 사본을 모두가 수신할 수 있음
  - SNS Topic 당 최대 구독자는 12500000명이고 데이터가 SNS로 보내진 후에는 더 이상 지속되지 않음
  - 데이터가 전달되지 않는 경우에는 손실된 가능성이 있음
  - Topic은 1000000개로 제한됨
  - 처리량을 프로비저닝할 필요 없고 팬아웃 아키텍처 패턴을 이용해 SQS와 결합할 수 있음
  - SNS FIFO Topic을 SQS FIFO 대기열에 있는 SNS와 결합할 수 있음
• Kinesis 모델
  - 스탠다드형(공유)과 소비 메커니즘의 향상된 팬아웃(소비)으로 두 가지 소비 모델이 존재
  - 소비자가 Kinesis에서 데이터를 끌어오는 스탠다드형은 샤드당 1초에 2MB를 얻음
  - 소비 메커니즘의 향상된 팬아웃은 Kinesis가 소비자에 데이터를 푸시할 수 있으므로 각 소비자 샤드당 1초에 2MB를 얻음
  - 소비 메커니즘은 처리량이 훨씬 많고 Kinesis Data Steams에서 읽을 수 있는 애플리케이션의 양도 늘어나게 됨
  - Kinesis Data Steams 안에 데이터가 지속되니 다시 재생할 수 있음
  - 실시간 빅데이터, 분석, ETL에 사용됨
  - 샤드 레벨에서 순서가 지정되므로 미리 Kinesis Data Steams당 필요한 샤드를 지정해야며 직접 샤드를 스케일링
  - 데이터는 만료되며 기록 시점에 데이터 보존 일자를 1일에서 365일 사이로 지정 가능
  - 처리량을 프로비저닝해야 하며 Kinesis는 샤드로 구성되어 있어 처리량이 많아질수록 샤드를 추가해야 함
  - 오토 스케일링을 사용할 수 없어 AWS의 맞춤 솔루션을 통해 활성화시켜야 함