답변:
이 답변은 2015 년 6 월에 대한 답변입니다.
동일한 질문을 염두에두고 잠시 동안 문제를 연구 한 후 메시지 순서가 중요하지 않은 한 SQS (SNS 포함)가 대부분의 사용 사례에 선호되는 것으로 나타났습니다 (SQS는 메시지에 대한 FIFO를 보장하지 않습니다).
Kinesis에는 2 가지 주요 장점이 있습니다.
SNS를 SQS에 대한 팬 아웃으로 사용하여 두 가지 장점을 모두 달성 할 수 있습니다. 즉, 메시지 생성자는 SNS에 하나의 메시지 만 보낸 다음 SNS는 각 소비자 응용 프로그램마다 하나씩 여러 SQS에 메시지를 팬 아웃합니다. 이러한 방식으로 샤딩 용량에 대해 생각하지 않고도 원하는만큼의 소비자를 확보 할 수 있습니다.
또한 14 일 동안 메시지를 보유 할 SNS에 가입 된 SQS를 하나 더 추가했습니다. 정상적인 경우이 SQS에서 아무도 읽지 못하지만 데이터를 되 감고 자하는 버그의 경우이 SQS에서 모든 메시지를 쉽게 읽고 SNS로 다시 보낼 수 있습니다. Kinesis는 7 일 보존 기간 만 제공합니다.
결론적으로 SNS + SQS는 훨씬 쉽고 대부분의 기능을 제공합니다. IMO Kinesis를 선택하려면 강력한 사례가 필요합니다.
split를 사용 SNS split the message to multiple SQSs하지 않을 것입니다.
Kinesis는 여러 소비자 기능을 지원합니다. 즉, 서로 다른 소비자에서 동일한 데이터 레코드를 동시에 처리하거나 24 시간 이내에 다른 시간에 처리 할 수 있습니다. SQS에서 유사한 동작은 여러 대기열에 기록하여 달성 할 수 있으며 소비자는 여러 대기열에서 읽을 수 있습니다. 그러나 여러 대기열에 다시 쓰면 시스템에서 1 초 미만 ({밀리 초)의 대기 시간이 추가됩니다.
둘째, Kinesis는 특정 EC2 인스턴스로 처리 할 수 있고 마이크로 배치 계산 {Counting & Aggregation}을 가능하게하는 파티션 키를 사용하여 여러 샤드로 선택적으로 데이터 레코드를 라우팅하는 라우팅 기능을 제공합니다.
모든 AWS 소프트웨어 작업은 쉽지만 SQS를 사용하는 것이 가장 쉽습니다. Kinesis를 사용하면 스파이크로드를 관리하기 위해 샤드 수를 동적으로 증가시키고 관리에 필요한 비용을 절감하기 위해 샤드 수를 사전에 충분히 프로비저닝해야합니다. 그것은 Kinesis의 고통입니다. SQS에는 그러한 것들이 필요하지 않습니다. SQS는 무한대로 확장 가능합니다.
이러한 기술의 의미는 다른 시나리오를 지원하도록 설계 되었기 때문에 다릅니다.
예를 들어 차이점을 이해합시다.
한 항목의 처리를 다른 항목의 처리와 분리 할 수없는 경우 모든 경우를 안전하게 처리하려면 Kinesis 의미 체계가 있어야합니다.
AWS 설명서 에서 발췌 :
다음과 유사한 요구 사항이있는 사용 사례에는 Amazon Kinesis Streams를 권장합니다.
스트리밍 MapReduce에서와 같이 관련 레코드를 동일한 레코드 프로세서로 라우팅합니다. 예를 들어, 주어진 키에 대한 모든 레코드가 동일한 레코드 프로세서로 라우팅되면 계산 및 집계가 더 간단 해집니다.
기록의 순서. 예를 들어, 로그 문의 순서를 유지하면서 응용 프로그램 호스트에서 처리 / 아카이브 호스트로 로그 데이터를 전송하려고합니다.
여러 애플리케이션이 동일한 스트림을 동시에 소비하는 기능 예를 들어 실시간 대시 보드를 업데이트하는 애플리케이션과 Amazon Redshift에 데이터를 아카이브하는 애플리케이션이 있습니다. 두 애플리케이션 모두 동일한 스트림의 데이터를 동시에 독립적으로 사용하기를 원합니다.
몇 시간 후에 동일한 순서로 레코드를 사용할 수 있습니다. 예를 들어, 청구 응용 프로그램과 청구 응용 프로그램보다 몇 시간 뒤에 실행되는 감사 응용 프로그램이 있습니다. Amazon Kinesis Streams는 최대 7 일 동안 데이터를 저장하므로 청구 애플리케이션 뒤에서 최대 7 일까지 감사 애플리케이션을 실행할 수 있습니다.
다음과 유사한 요구 사항이있는 사용 사례에는 Amazon SQS를 권장합니다.
메시징 의미 (예 : 메시지 수준 ack / 실패) 및 가시성 시간 초과 예를 들어, 작업 항목 큐가 있고 각 항목의 성공적인 완료를 추적하려고합니다. Amazon SQS는 ack / fail을 추적하므로 애플리케이션은 지속적인 체크 포인트 / 커서를 유지 관리 할 필요가 없습니다. Amazon SQS는 구성된 가시성 시간 초과 후 acked 메시지를 삭제하고 실패한 메시지를 재전송합니다.
개별 메시지 지연. 예를 들어, 작업 대기열이 있으며 지연된 개별 작업을 예약해야합니다. Amazon SQS를 사용하면 개별 메시지가 최대 15 분 지연되도록 구성 할 수 있습니다.
읽기시 동시성 / 처리량을 동적으로 증가시킵니다. 예를 들어, 작업 큐가 있고 백 로그가 지워질 때까지 더 많은 독자를 추가하려고합니다. Amazon Kinesis Streams를 사용하면 충분한 수의 샤드로 확장 할 수 있습니다 (단, 충분한 샤드를 미리 프로비저닝해야합니다).
Amazon SQS의 투명성 확장 기능을 활용합니다. 예를 들어, 때때로로드가 급증하거나 비즈니스가 자연스럽게 성장함에 따라 요청을 버퍼링하고로드 변경을 수행 할 수 있습니다. 버퍼링 된 각 요청을 독립적으로 처리 할 수 있으므로 Amazon SQS는 프로비저닝 지침없이로드를 처리하도록 투명하게 확장 할 수 있습니다.
나에게 가장 큰 장점은 Kinesis가 재생 가능한 대기열이고 SQS는 그렇지 않다는 사실입니다. 따라서 SQS를 사용하여 메시지가 확인되면 해당 큐에서 사라진 동일한 Kinesis 메시지 (또는 다른 시간에 동일한 소비자)의 여러 소비자를 가질 수 있습니다. SQS는 작업자 대기열 때문에 더 좋습니다.
또 다른 것은 Kinesis가 Lambda를 트리거 할 수 있지만 SQS는이를 트리거 할 수 없습니다. 따라서 SQS를 사용하면 SQS 메시지를 처리하기 위해 EC2 인스턴스를 제공하고 (실패한 경우 처리) 예약 된 Lambda (확장 또는 축소되지 않음-분당 1 개만)를 가져야합니다. .
편집 :이 답변은 더 이상 정확하지 않습니다. SQS는 2018 년 6 월 기준으로 Lambda를 직접 트리거 할 수 있습니다
가격 모델은 다르므로 사용 사례에 따라 가격이 저렴할 수 있습니다. 가장 간단한 경우 사용 (SNS 제외) :
현재 가격에 연결하고 프리 티어를 고려하지 않고 최대 메시지 크기로 하루에 1GB의 메시지를 보내면 Kinesis의 비용은 SQS보다 훨씬 더 비쌉니다 (Kinesis의 경우 월 $ 10.82 / SQS의 경우 월 $ 0.20 / 월). . 그러나 하루에 1TB를 전송하면 Kinesis가 다소 저렴합니다 (SQS의 경우 월 $ 158 / 월 대 $ 201).
세부 정보 : SQS는 백만 요청 당 0.40 달러 (각 64KB)를 청구하므로 GB 당 0.00655 USD입니다. 하루에 1GB로 월 $ 0.20 미만입니다. 하루에 1TB에서 한 달에 201 달러가 조금 넘습니다.
Kinesis는 백만 건의 요청 당 $ 0.014 (각각 25KB)를 청구하므로 GB 당 $ 0.00059입니다. 하루에 1GB로 매월 $ 0.02 미만입니다. 하루 1TB에서 월 약 18 달러입니다. 그러나 Kinesis는 샤드 시간당 0.015 USD를 청구합니다. 초당 1MB 당 최소 1 개의 샤드가 필요합니다. 하루에 1GB이면 1 개의 샤드가 충분하므로 하루에 총 $ 10.82의 비용으로 하루에 $ 0.36가 추가됩니다. 하루에 1TB에서 최소 13 개의 샤드가 필요하며, 이로 인해 하루에 4.68 달러가 추가되어 한 달에 총 $ 158의 비용이 발생합니다.
아무도 언급하지 않은 것을 하나 더 추가하겠습니다. SQS는 몇 배나 더 비쌉니다.