데이터 스트림이 오는 유스 케이스가 있으며 동일한 속도로 사용할 수 없으며 버퍼가 필요합니다. 이것은 SNS-SQS 대기열을 사용하여 해결할 수 있습니다. Kinesis가 동일한 목적을 해결한다는 것을 알게되었으므로 차이점은 무엇입니까? Kinesis를 선호해야하는 이유는 무엇입니까?
답변
표면적으로는 모호하게 유사하지만 사용 사례에 따라 적절한 도구가 결정됩니다. IMO, SQS를 통해 얻을 수 있다면 원하는 것을 수행하면 더 간단하고 저렴하지만 두 가지 도구에 대한 적절한 사용 사례의 예를 제공하는 AWS FAQ의 더 나은 설명이 있습니다. 당신이 결정하는 데 도움이 :
답변
이 답변은 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를 선택하려면 강력한 사례가 필요합니다.
답변
Kinesis는 여러 소비자 기능을 지원합니다. 즉, 서로 다른 소비자에서 동일한 데이터 레코드를 동시에 처리하거나 24 시간 이내에 다른 시간에 처리 할 수 있습니다. SQS에서 유사한 동작은 여러 대기열에 기록하여 달성 할 수 있으며 소비자는 여러 대기열에서 읽을 수 있습니다. 그러나 여러 대기열에 다시 쓰면 시스템에서 1 초 미만 ({밀리 초)의 대기 시간이 추가됩니다.
둘째, Kinesis는 특정 EC2 인스턴스로 처리 할 수 있고 마이크로 배치 계산 {Counting & Aggregation}을 가능하게하는 파티션 키를 사용하여 여러 샤드로 선택적으로 데이터 레코드를 라우팅하는 라우팅 기능을 제공합니다.
모든 AWS 소프트웨어 작업은 쉽지만 SQS를 사용하는 것이 가장 쉽습니다. Kinesis를 사용하면 스파이크로드를 관리하기 위해 샤드 수를 동적으로 증가시키고 관리에 필요한 비용을 절감하기 위해 샤드 수를 사전에 충분히 프로비저닝해야합니다. 그것은 Kinesis의 고통입니다. SQS에는 그러한 것들이 필요하지 않습니다. SQS는 무한대로 확장 가능합니다.
답변
이러한 기술의 의미는 다른 시나리오를 지원하도록 설계 되었기 때문에 다릅니다.
- SNS / SQS : 스트림의 항목 이 서로 관련 이 없습니다.
- 운동성은 : 스트림의 항목이 되어 서로 관련
예를 들어 차이점을 이해합시다.
- 각 주문마다 재고를 확보하고 배송 일정을 정해야하는 주문 흐름이 있다고 가정합니다. 완료되면 스트림에서 항목을 안전하게 제거하고 다음 주문 처리를 시작할 수 있습니다. 우리는 완벽하게되어 수행 우리가 다음 일을 시작하기 전에 이전 주문과 함께.
- 다시 한 번, 동일한 주문 흐름이 있지만 이제 목표는 대상별로 주문을 그룹화하는 것입니다. 예를 들어, 같은 장소에 10 개의 주문이 있으면 주문을 함께 제공하려고합니다 (배송 최적화). 이제 이야기가 다릅니다. 스트림에서 새 항목을 가져 오면 처리를 완료 할 수 없습니다. 오히려 우리는 목표를 달성하기 위해 더 많은 아이템이 오기를 “기다립니다”. 또한 프로세서 프로세스가 중단되면 상태를 “복원”해야합니다 (따라서 순서가 손실되지 않습니다).
한 항목의 처리를 다른 항목의 처리와 분리 할 수없는 경우 모든 경우를 안전하게 처리하려면 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를 직접 트리거 할 수 있습니다
