SQS 대 RabbitMQ


88

처리 할 대기열을 만들어야합니다. 대기열 자체는 상대적으로 적은 양입니다. 시간당 약 1,000 개의 쓰기가있을 수 있습니다. 각 작업의 실행에는 각각 약 1 분이 소요될 수 있으며 항목이 대기열에 추가되는 즉시 처리됩니다.

Amazon SQS와 같은 기성품 대신 RabbitMQ를 구현하고 싶은 이유가 있습니까? 응용 프로그램에 SQS와 같은 것 대신 자체 대기열 시스템이 필요한 이유는 무엇입니까?


시간당 1000 회 쓰기가 좋습니다. 시간과 충분한 지식이 있다면 RabbitMq 인스턴스를 직접 실행하면 Amazon SQS 서비스와 비교할 때 비용도 절약됩니다. SQS의 경우 바로 거기에있었습니다. 편리하고 간단하며 합리적으로 빠르게 코딩 할 수있었습니다.
BMW는

SQS를 사용하면 Lambda 트리거의 확장 성과 확장 성을 얻을 수 있습니다.
Donato

답변:


98

처음에 Amazon SQS는 의사 대기열입니다. 즉, 모든 메시지 (대기열에 도달 한 경우)의 전달이 보장되지만 일반적으로 대기열에서 발생하는 FIFO 방식이 아닙니다.

메시지 순서가 중요하고 대기열이 FIFO 방식으로 작동하기를 원하는 경우 Amazon SQS 문서에는 Amazon SQS의 메시지가 순서에 상관없이 도달하므로 애플리케이션 로직에서이를 처리하도록 명시되어 있습니다.

이것에 비해 내가 아는 한 RabbitMQ에서 작업자 큐를 구현할 수 있습니다. 애플리케이션 수준에서 큐 메시지 시퀀스를 구현하지 않아도된다면 이것이 더 바람직한 옵션이 될 것입니다.

다음은 어느 것을 선택할지 결정하는 데 도움이되는 몇 가지 요소입니다.

  1. 위에서 언급 한 큐 메시지 시퀀스.

  2. RabbitMQ로 자체 서버를 설정할 수 있지만 Amazon SQS의 경우에는 비용이 여기에 포함됩니다.

  3. 자신의 서버를 설정하려면 주제에 대한 충분한 지식이 필요하므로 모서리를 그대로 두지 마십시오. Amazon SQS는 시작하는 것이 매우 빠르기 때문에 그렇지 않습니다.

  4. 자체 RabbitMQ 서버는 Amazon SQS의 경우가 아닌 유지 관리 비용을 의미합니다.

업데이트 :

  1. Amazon SQS는 이제 FIFO 대기열을 지원합니다.

5
"Amazon SQS는 거의 모든 주요 플랫폼에서 폭 넓은 이식성을 가지고 있지만 RabbitMQ의 경우는 확실하지 않습니다."라는 의미는 무엇입니까? RabbitMQ는 모든 주요 플랫폼 (Windows, Linux 및 Mac)과 모든 주요 언어 (Java, .Net, PHP, Python, Ruby 등)에서 실행됩니다
old_sound

6
@old_sound 차이점은 RabbitMQ를 실행하는 동안 사용량 (메시지 전송 및 수신)에 대해서만 지불하는 SQS를 실행하면 서비스가 앱과 기본을 포함하여 실행, 모니터링 및 패치되었는지 확인하는 숨겨진 비용 (EC2 사용량 이상)이 있다는 것입니다. 운영 체제. SQS를 사용하면 AWS가 "분할되지 않은 무거운 작업"을 모두 처리하므로 앱에만 집중할 수 있습니다.
JaredHatfield jul.

27
Amazon SQS는 이제 FIFO를 지원합니다
rocketspacer 2016

6
내가 그 읽을 때, 나는 거의 읽는 중지 지금 FIFO 큐를 지원하는지 보여주기 위해 포스트의 상단을 업데이트하십시오
앤디 맥 컬러

11
-1이 답변이 유용하려면주의가 필요합니다. 제안 : FIFO 제약을 완전히 제거하고 IaaS (확장, 구성 등) 및 메시지 전달의 차이점 (예 : 폴링)에 중점을 둡니다.
Brett

69

SQS가 RabbitMQ보다 선호되는 이유는 다음과 같습니다.

  1. SQS는 관리 형 서비스입니다. 따라서 관리, 보안, 모니터링 등 메시징 시스템 실행의 운영 측면에 대해 걱정할 필요가 없습니다. Amazon이이 작업을 수행하고 문제가 발생할 경우 지원을 제공합니다.
  2. SQS는 탄력적이며 매우 큰 속도 / 볼륨으로 확장 할 수 있습니다 (AWS에 따라 무제한).
  3. SQS의 가용성에는 9가 많이 포함되어 있으며 Amazon에서 지원하므로 애플리케이션에서 걱정할 필요가 없습니다.

그러나 RabbitMQ는 일반적으로 테스트에서 수만 TPS에서 풋 및 겟에 대해 더 빠른 응답 시간을 제공 할 수 있습니다. SQS가 이러한 종류의 처리량을 제공하려면 여러 인스턴스를 사용하여 수평 적으로 확장해야합니다. 따라서 5ms 미만의 풋을 찾고 있다면 RabbitMQ보다 약간 높은 1000s의 TPS에서 SQS 테스트에서 20ms-30ms에 가까운 시간을 보냈기 때문에 RabbitMQ를 고려할 수 있습니다.

우리는 메시징 인프라를 ActiveMQ에서 SQS로 방금 옮겼으며 더 이상 행복 할 수 없습니다. 클라우드에서 자체 ActiveMQ 클러스터를 유지하는 것보다 더 저렴하다는 사실을 알게되었습니다.

도움이 되었기를 바랍니다! 어떻게되는지 알려주세요 ..


@ssekhar 우리는 또한 activemq를 SES로 마이그레이션 할 계획입니다. 클라이언트 측의 변경 사항은 얼마나 큽니까? 우리는 java 및 최신 버전의 activemq에 있습니다.
Deepak Singhal 2016

저는 수년간 SQS 기반 앱을 풋당 약 7ms의 중간 값으로 실행 해 왔습니다. 20-30ms를 얻는다면 측정이나 테스트에서 뭔가 끔찍하게 잘못된 것입니다. 동일한 AWS 리전 / AZ 내에서 실행하고 있습니까? 어떻게 측정하고 있습니까?
Krease

1
@DeepakSinghal-귀하의 질문에 대한 답을 이미 찾았다 고 확신합니다. 여기서 질문을 잡기 위해 몇 년 늦어서 죄송합니다 :). ActiveMQ에서 SQS로 이동-다음은 우리가 처리해야하는 몇 가지 과제입니다. 1) SQS는 JMS처럼 한 번만 제공하는 것이 아니라 최소한 한 번만 제공하므로 중복 전달 문제를 해결해야했습니다 (여기에 표시된 접근 방식-> angularthinking.blogspot.com ). JMS에서와 같이 클라이언트로 푸시하면 소비가 더 쉬워집니다. 개발을 단순화하기 위해 자체 리스너 및 비동기 전달 프로세서를 구현했습니다.
ssekhar

27

실제로 상업적 환경에서 합리적으로 사용했습니다.

짧은 대답은 특정 코너 케이스가 없으면 AWS SQS를 사용하는 것이 좋습니다. (간단한 요약을 위해 아래로 건너 뛸 수 있습니다)

코딩 (Tie) : RabbitMQ와 AWS SQS 모두 라이브러리를 설정하고 많은 예제를 가지고 있습니다.

가시성 제한 시간 (SQS) : SQS가 RabbitMQ를 통해 제공하는 한 가지는 가시성 제한 시간에 대한 광범위한 개념입니다. RabbitMQ에서 소비자가 응답하기 전에 죽으면 메시지가 큐에 다시 들어갑니다. 그러나 SQS는 특정 발신자와 관련이없는보다 광범위한 가시성 제한 시간 개념을 가지고 있습니다. 따라서 작업 단위를 시작하고, 긴 시간 제한 (최대 12 시간)으로 가시성을 설정하고, 연결을 끊고, 다른 작업자가 완료하도록하고 승인 할 수 있습니다. 제 설계에서는이를 광범위하게 활용하고 잠재적으로 큰 '진행중인'페이로드를 관리하기 위해 추가 서비스 / 스토리지를 제거했습니다.

배달 못한 편지 처리 (RabbitMQ- '토끼'에 의해) SQS는 배달 못한 편지 대기열 (다른 큐)로 메시지를 덤프하는 "재 드라이브 정책"이라고 부르는 기본 배달 못한 편지 처리를 제공합니다. 기본이며 메시지 수의 개념 만 있습니다. RabbitMQ에는 만료 될 때 DLE에서 푸시되는 메시지를 제공하는 배달 못한 편지 교환이 있습니다. 그러나 이것은 "서비스와 메시지가 만료되는 것을 보지 않으면 DLE에 도착할 것입니다"라는 아이디어로 일종의 논쟁입니다. 내가 그 인수 카운터가 직관적이라는 것을 알기 때문에 RabbitMQ에게는 약간의 승리입니다. 서비스가 아닌 대기열을 모니터링하는 이유는 무엇입니까? (만약 있다면, 그 반대입니다)

관리 (SQS) : SQS에 대한 관리가 없습니다. API 호출 비용 만 지불하면됩니다. OS / 앱 보안 패치, 확장 (노드 추가), 디스크와 같은 모든 일반적인 골칫거리는 AWS 팀에서 처리합니다. 또한 FedRamp를 준수합니다 (정부 용). 진정한 '설정 후 잊어 버리기'시스템입니다. RabbitMQ에 일반적인 OS / 서비스 패치, AMI, 클러스터링, 보안 강화 등이 필요한 곳. 극히 드물지만 AMI가 다운되거나 때때로 이동해야하므로 클러스터링이 즉시 필요합니다. SQS는 이러한 모든 두통을 제거합니다.

비용 (SQS) : 단일 SQS API 호출에는 '최대 10 개의 메시지 / 256k 크기'일괄 처리가 포함될 수 있으며 '긴 폴링'은 비용을 대폭 절감 할 수 있습니다. 또한 비용을 추가로 줄이기 위해 단일 페이로드로 수십 개의 메시지를 전송할 수있는 메시지 압축과 같은 전략이 있습니다. 그리고 이것은 사람들이 문제를 모니터링 / 패칭 / 수정하는 데 소비하는 시간을 고려하기 전입니다. SQS는 유휴 상태에서 비용이 들지 않는 것처럼 'poc 프로젝트'에도 좋습니다.

FIFO (TIE) : 2016 년 AWS는 ~ 0.01 / 백만 API 호출의 추가 비용으로 FIFO 지원을 도입했습니다 (할인 전 API 호출 백만 개당 0.04 달러 대 0.04 달러). FIFO 사용 여부를 선택할 수 있습니다. 비 FIFO의 경우 중복 메시지가 거의 표시되지 않습니다.

스토리지 (SQS) : AWS는 스토리지 비용을 청구하지 않지만 14 일로 제한됩니다. RabbitMQ에서는 최대 스토리지 용량과 추가 버퍼가 필요한 디스크 공간을 할당, 확장 및 관리해야합니다. 그것은 더 많은 두통입니다.

지표 (SQS) : SQS는 즉시 사용 가능한 지표를 제공합니다. AWS에 추가 할 수는 있지만 더 많은 작업이 필요합니다.

지역 개발 (넥타이) : 대부분의 현대 상점은 지역 환경을 좋아합니다. 이제 RabbitMQ 및 SQS의 도커를 허용하는 몇 가지 옵션이 있습니다.

높은 처리량 / 매우 큰 메시지 (RabbitMQ-일종의) SQS> 1000 요청 / 초를 푸시하면 SQS의 지연 시간이 늘어납니다. 이를 해결하기위한 몇 가지 전략이 있습니다. 그러나 대부분의 작업이 여러 대기열로 분할 될 수 있으므로 이러한 경우는 매우 드뭅니다. 그러나 100k / sec가 필요한 이러한 유형의 경우에는 Kafka가 더 좋습니다. (저희 작업에서도 Kafka를 사용합니다.) 짧은 대기 시간으로 초당 1000 개 이상의 요청이 필요한 단일 작업 단위를 갖는 경우는 드뭅니다. *이 설명은 아래를 참조하십시오.

요약 : AWS에서 SQS와 기꺼이 결혼하려는 경우 SQS는 생각할 필요가 없습니다. 그러나 고려해야 할 중요한 사항이 있으므로 계속 읽어야합니다.

RabbitMQ (및 기타 대기열)의 고전적인 전략은 특정 유형의 작업에 최적화 된 여러 유형의 대기열을 만드는 것입니다. 그런 다음 각 대기열을 미세 조정하고 유사한 작업을 소수 (종종 매우 큰) 대기열로 그룹화합니다. SQS에는 관리 오버 헤드가 없기 때문에 실제로 각 작업에 전용 대기열을 할당하는 것이 좋습니다. 이렇게하면 확장이 가능할뿐 아니라 대기열 포화 (작업에 문제가 생기고 다른 작업자가 빠져 나가는 작업), 작업에 대한 더 나은보기 (기본 메트릭) 등이 제거됩니다.

새로운 전략을 통해 우리 팀은 작업이 어떻게 배포되는지 더 잘 볼 수 있습니다. '더 많은 부하를 위해 인스턴스를 업그레이드'하던 시대는 지났습니다. 과거에는 다른 서비스에 부작용을 일으킬 수있는 설명 할 수없는 큰 급증을 보거나 누적 수치가 맞아 보인다고 추측했습니다. ' 이제 트래픽이 분리되었으므로 이전에는 알지 못했던 많은 문제를 실제로 발견했으며 트래픽이 어디로 가고 있는지 명확하게 설명 할 수 있습니다. 메트릭 및 도구를 구현하는 것은 매우 가능하지만 SQS는 이러한 모든 것을 즉시 제공합니다.

RabbitMQ를 심각하게 고려해야하는 좋은 사례가 여전히 있습니다.

- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.

4

비용에 민감한 경우 Amazon SQS가 더 비용이 많이들 수 있습니다. 나는 여전히 RabbitMQ 서버를 어딘가에 호스팅해야하기 때문에 아마도 말합니다. SQS는 처음 백만 건의 요청을 무료로 제공하고 그 이후에는 요청 백만 건당 0.4 달러를 청구합니다. 긴 폴링, 즉 receive_message_wait_time을 20 초로 설정하여 SQS로 비용을 줄이는 트릭이 있습니다. 이것은 메시지가 20 초마다 전송된다는 의미가 아니라, 쿼리가 비어있는 경우 (20 초마다) SQS가 '요청'을 청구하지 않음을 의미합니다.

시간당 1000 개의 요청을 사용하는 경우 한 달에 744,000 개가됩니다. 프리 티어 내에서는 무료이며 티어에서 약 0.74 * $ 0.4 = $ 0.2976입니다. 대기 시간을 활성화하여 더 줄일 수 있습니다. 따라서 귀하의 경우 SQS는 대부분의 호스팅이 최소 $ 5 이상부터 시작하므로 실제로 더 저렴하게 작동 할 수 있습니다 (AWS의 EC2 프리 티어가없는 경우). RMQ는 약 128MB 램 시작을 권장하므로 가장 작은 옵션으로도 문제가 없습니다.

나는 SQS가 훨씬 더 사용자 친화적이고 RabbitMQ가 더 기술적 인 경향이 있다고 생각합니다.

최신 정보:

실제로 AWS Simple Notification Service가 필요한 항목에 더 적합하다는 것을 발견 했습니다. https://stackoverflow.com/a/13692720/5403449는 주로 푸시 기반폴링 이 아니기 때문입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.