[amazon-web-services] SQS 대 RabbitMQ

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

짧은 대답은 특정 코너 케이스가 없으면 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.