SQS 대 RabbitMQ
처리 할 대기열을 만들어야합니다. 대기열 자체는 비교적 적은 양입니다. 시간당 약 1,000 개의 쓰기가있을 수 있습니다. 각 작업의 실행은 각각 약 1 분이 소요될 수 있으며 항목이 대기열에 추가되는 즉시 처리됩니다.
Amazon SQS와 같은 기성품 대신 RabbitMQ를 구현하고 싶은 이유가 있습니까? 응용 프로그램에 SQS와 같은 것 대신 자체 대기열 시스템이 필요한 이유는 무엇입니까?
처음에 Amazon SQS는 의사 대기열입니다. 즉, 모든 메시지 (대기열에 도달 한 경우)의 전달이 보장되지만 일반적으로 대기열에서 발생하는 FIFO 방식이 아닙니다.
메시지 순서가 중요하고 대기열이 FIFO 방식으로 작동하기를 원하는 경우 Amazon SQS 문서에는 Amazon SQS의 메시지가 순서에 상관없이 도달하므로 애플리케이션 로직에서이를 처리하도록 명시되어 있습니다.
이것에 비해 내가 아는 한 RabbitMQ에서 작업자 큐를 구현할 수 있습니다. 애플리케이션 수준에서 큐 메시지 시퀀스를 구현하지 않아도된다면 이것이 더 바람직한 옵션이 될 것입니다.
다음은 어느 것을 선택할지 결정하는 데 도움이되는 몇 가지 요소입니다.
위에서 언급 한 큐 메시지 시퀀스.
RabbitMQ로 자체 서버를 설정할 수 있지만 Amazon SQS의 경우에는 비용이 여기에 포함됩니다.
자신의 서버를 설정하려면 주제에 대한 충분한 지식이 필요하므로 모서리를 그대로 두지 마십시오. Amazon SQS는 시작이 매우 빠르기 때문에 그렇지 않습니다.
자체 RabbitMQ 서버는 Amazon SQS의 경우가 아닌 유지 관리 비용을 의미합니다.
업데이트 :
- Amazon SQS는 이제 FIFO 대기열을 지원합니다.
SQS가 RabbitMQ보다 선호되는 이유는 다음과 같습니다.
- SQS는 관리 형 서비스입니다. 따라서 관리, 보안, 모니터링 등을 포함하여 메시징 시스템 실행의 운영 측면에 대해 걱정할 필요가 없습니다. Amazon이이 작업을 수행하고 문제가 발생할 경우 지원을 제공합니다.
- SQS는 탄력적이며 매우 큰 속도 / 볼륨으로 확장 할 수 있습니다 (AWS에 따라 무제한).
- SQS의 가용성에는 9가 많이 포함되어 있으며 Amazon에서 지원하므로 애플리케이션에서 걱정할 필요가 없습니다.
그러나 RabbitMQ는 일반적으로 테스트에서 수만 TPS에서 풋 및 겟에 대해 더 빠른 응답 시간을 제공 할 수 있습니다. SQS가 이러한 종류의 처리량을 제공하려면 여러 인스턴스를 사용하여 수평 적으로 확장해야합니다. 따라서 5ms 미만의 풋을 찾고 있다면 RabbitMQ보다 약간 높은 1000s의 TPS에서 SQS 테스트에서 20ms-30ms에 가까운 시간을 보냈기 때문에 RabbitMQ를 고려할 수 있습니다.
우리는 메시징 인프라를 ActiveMQ에서 SQS로 방금 옮겼으며 더 이상 행복 할 수 없습니다. 클라우드에서 자체 ActiveMQ 클러스터를 유지하는 것보다 더 저렴하다는 사실을 알게되었습니다.
도움이 되었기를 바랍니다! 어떻게되는지 알려주세요 ..
실제로 상업적 환경에서 합리적으로 사용했습니다.
짧은 대답은 특정 코너 케이스가 없으면 AWS SQS를 사용하는 것이 좋습니다. (간단한 요약을 위해 하단으로 건너 뛸 수 있습니다)
코딩 (타이) : 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에서 AQS와 기꺼이 결혼하려는 경우 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.
참고 URL : https://stackoverflow.com/questions/28687295/sqs-vs-rabbitmq
'Programing' 카테고리의 다른 글
| Rails Devise : 현재 로그인 한 사용자의 객체를 얻습니까? (0) | 2020.12.11 |
|---|---|
| 마지막 줄이 누락 된 쉘 스크립트 읽기 (0) | 2020.12.11 |
| Angular 2 라우터 이벤트 리스너 (0) | 2020.12.11 |
| CURL을 통해 모든 기기에 Firebase 알림을 어떻게 보내나요? (0) | 2020.12.11 |
| 유형이 "단순"유형인지 어떻게 알 수 있습니까? (0) | 2020.12.11 |