AWS에서 ElastiCache를 통해 SQS (Simple Queue Service)를 사용해야하는 이유

Question

SQS는 사용하기가 매우 쉽지만 메시지 크기 제한이 있습니다 (예 : 256KB 메시지 크기 (실제로는 아주 작음). 반면에, ElasticCache는 더 하이 엔드 인 것 같습니다? 이 가정이 맞는지 확실하지 않습니다. 제발 저를 시정하십시오.

하나 또는 다른 유형의 메시지 전달 (및/또는 캐싱) 시스템을 사용하여 AWS 사용에 응용 프로그램을 배포하는 중입니다. 어떤 상황에서 다른 상황을 하나씩 선택합니까?

Answer 1

SQS와 ElastiCache를 비교하는 것은 엽서를 파일 캐비닛과 비교하는 것과 다소 비슷합니다.

"어느 것이 더 좋습니까?"

당신이 성취하고자하는 바에 달려 있으며, 두 가지 경우 모두 기능을 일시적으로 정보를 저장한다는 사실 외에도 기능의 중복이 거의 없습니다.

ElastiCache와 같은 캐시는 신뢰할 수있는 출처 (종종 데이터베이스)에서 정보를 반복적으로 가져 오는 것이 일반적으로 자원이나 시간면에서 비용이 많이 드는 경우 자주 액세스하는 정보를 저장할 수있는 곳입니다. 캐시에서 가져 오는 것보다 훨씬 낫습니다. 캐시는 열린 문서가있는 파일 캐비닛과 비슷합니다.이 캐비닛은 새 문서를 저장할 필요가있을 때마다 오래된 문서를 분쇄기로 자동 배출합니다. 이를 캐시에서 축출이라고합니다. 그 목적 때문에 캐시에 저장된 정보는 일반적으로 내구성이있는 것으로 간주되지 않습니다. 노드가 실패하거나 데이터가 제거되고 더 이상 저장하지 않은 노드가 없습니다. 또한

“ 암시 적 캐시가 가득 차면 그들이 너무 나이가 될 경우, 또는 캐시가 만료되거나 값을 퇴거 할 수 있다는 사실이다.

— http://aws.amazon.com/blogs/aws/amazon-elasticache-distributed-in-memory-caching/

문제 없음 ”

캐시는 신뢰할 수있는 데이터 소스 아니었다 ...하지만 데이터가있는 동안, 당신은 매우 신속하게 액세스 할 수 있기 때문이다. 캐시를 찾지 못하고 캐시에 캐시가 없다면 데이터에 대한 신뢰할 수있는 소스로 이동하고 캐시의 사본을 캐시로 다시 보내 캐시에 캐시 할 수 있도록 요청할 수 있습니다 .

캐시에서 원하는 것을 찾으려면 구체적으로 요청하십시오.

반면에 SQS (Simple Queue Service)와 같은 대기열은 엽서와 비슷하거나 대기열 메시지와 비슷합니다. 메시지를 작성하여 대기열로 보내면 다른 쪽 끝이 팝업됩니다 (일반적으로 한 번). 메일 주문은 보장되지 않지만 메일은 guaranteed to be delivered "at least once"입니다. (일반적으로 복제 된 메일은 드뭅니다. 여전히 대규모의 분산 인프라이므로 중복 된 전송이 가능합니다.) .

대기열에서 원하는 것을 선택하면 다음 메시지를 한 줄로 보냅니다. 그 중 하나를 선택하지 않습니다.

임의, 빠른 및 반복 검색을 위해 정보를 캐시해야하고 그 정보가 일회용이며 재사용이 가능한 경우 물론 ElastiCache가이 두 가지를 선택합니다.

독립적으로 또는 다른 속도로 실행되는 시스템의 두 부분간에 메시지를 보내야하는 경우 SQS와 같은 메시지 대기열을 찾고 있습니다. 일반적으로 대기열 메시지 자체에 데이터 블록을 전송할 필요가 없기 때문에 작은 페이로드 크기 제한이 충분합니다. 대신 트랜잭션 테이블의 데이터, 포인터, "ID"또는 웹 액세스 가능한 객체 (아마도 S3에 저장 됨)에 대한 참조를 보내면 대기열 사용자는 해당 데이터에서 참조하는 데이터 청크를 가져올 수 있습니다. 대기열 메시지를 작성하고 이에 대한 조치를 취하십시오.

Answer 2

경험을 통해 사용 사례를 얻었습니다. 약 2 년 전에 AWS에 실제로 배포 된 코드. SQS는 클라우드 애플리케이션의 두 부분을 연결하는 데 필요한 인터페이스이기 때문에 사용했습니다. 그리고 실제로 ... 256KB는 충분한 크기 이상입니다.