입문

Amazon SQS의 성능을 검증했습니다.
얻은 결과에 따르면 실시 전 나에게 잘 알려지지 않은 부분에 따라 가장 좋은 설정으로 여겨졌다.

전제 & 주의사항

2020년 12월 아마존 SQL의 성능 결과입니다.물론 앞으로 개량되고 규격도 바뀌겠죠.

TL;DR

짧은 폴링이 아니라 긴 폴링(20초)

처리량의 성능이 50[req/sec]이면 FIFO 대기열이 성능 병목이 될 수 있음

출대 측면에서 가능하다면 병행 처리

컨텐츠 및 결과 확인

내용은 SQL에 가입할 때의 시간 스탬프와 SQLS에서 팀을 나갈 때의 시간 스탬프의 시간 차이를 계산하고 분석하는 것이다.

【요점1】 긴 윤회 조회

이번 검증 결과 긴 폴링이 짧은 폴링보다 1.5배 정도 좋은 것으로 나타났다.
AWS 공식에서도 긴 휠체어를 추천합니다. 성능과 비용 원가가 모두 좋아서 그런 것 같습니다.
긴 폴링의 설정은 1초에서 20초까지 선택할 수 있지만 시스템이 문제없이 작동하면 20초마다 선택할 수 있다.
짧은 폴링은 AWS 콘솔에서 작성될 때 기본값이므로 주의해야 합니다.

그럼 짧은 윤문이 필요합니까?

시스템 구성이 여러 SQL에서 행렬된 프로그램을 한 라인에서 실행할 수 있도록 허용하는 경우 하나의 대기열에서만 대기할 수 있으므로 짧은 폴링을 선택해야 합니다.
자세한 내용은 [공식] SQL FAQ 을 참조하십시오.

[요점 2] Random SQS에 비해 FIFO SQS의 처리량이 좋지 않음

이번 검증 결과에 따르면 FIFO SQS의 처리량은 Random에 비해 상당히 좋지 않다.
다음은 다른 동일한 조건에서 50req/sec에서 입대 20초만 불러올 때의 랜덤과 FIFO 결과입니다.

Random

위의 그림과 같이 Random은 응답 시간이 안정적임을 나타냅니다.

FIFO

한편, 다음과 같이 FIFO에서 부하 시간이 흐르면 응답 시간이 증가하고 불안정해진다.

AWS 공식(2020년 12월시)에서 300req/sec까지의 입단 중 FIFO는 대응(Random 무제한)이지만 안쪽 처리에서 50req/sec를 초과해도 출대 OK까지 앞당기는 시간이 늘어난다.

【점3】 출대 측은 여러 개의 라인으로 처리할 수 있어 물동량이 좋아진다

이것은 자명하다. 검증된 결과도 여러 개의 스레드(Go를 이용한goroutine)로 대응하는 성능이 좋아질 것이다.가능하다면 병행 처리를 통해 팀을 내면 성능이 높아진다.일
무작위 대기열이라면 순서와 중복을 보장하지 않기 때문에 후속 시스템이 멱등성을 유지할 수 있는지를 고려해야 한다.  ↩