Programming
[AWS, Certified Developer Associate] SQS, SNS
빠쿤
2024. 5. 18. 17:54
Amazon SQS (Simple Queue Service)
- 완전 관리형 대기열(Queue) 서비스
- 애플리케이션 분리에 사용 (Decouple Applications)
- 무제한 처리량 / 무제한 메세지 queueing
- 메시지는 기본 4일, 최대 14일까지 존재 가능
- 낮은 지연 (발행 및 소비에 대해 < 10ms)
- 메시지의 크기는 작아야함 (256KB 미만)
SQS - 메시지 발행
- 생산자는 SDK (SendMessage API)를 통해 256KB 미만의 메시지 전송
- 메시지는 소비자가 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지
SQS - 메시지 소비
- 소비자는 SQS 메시지를 폴링
- 폴링한 메시지에 대해 소비자는 작업(처리) (ex) RDS DB에 데이터 저장)
- 처리가 완료된 후 소비자는 SDK (DeleteMessage API)를 통해 대기열에서 메시지 삭제
- 메시지는 최소 한번 전송 (At least once Delivery)
- 메시지를 빠르게 삭제하지 않으면 다른 소비자도 메시지를 수신할 수 있음
SQS - ASG와 연동
- ASG의 스케일링 조건에 Queue length를 통해 큐에 메시지가 많이 쌓여있는 경우 스케일링 처리 가능
- CloudWatch Metric - Queue Length (ApproximateNumberOfMessages)
- 급증한 트래픽에 대해 Auto Scaling이 적용되어 메시지 처리량 높아짐
SQS - 애플리케이션 간 분리
- ex) 비디오 처리 작업
- Front-end web app에서 모든 작업 처리시 웹사이트가 느려질 수 있음
- 비디오 처리 작업 request가 들어오면 Front-end web app은 SQS에 해당 메시지를 전송
- SQS의 소비자인 Back-end processing application이 해당 메시지를 수신해 비디오 처리 (S3 버킷 저장)
- Front, Back Application은 각각 독 립적인 ASG 내 위치하여 독립적인 확장이 가능
- Front, Back EC2 인스턴스가 각각 최적 유형의 인스턴스 생성이 가능 (GPU 유형 등)
SQS - Queue 액세스 정책 (Access Policy)
- 교차 계정 액세스 허용
- 다른 계정의 EC2 인스턴스가 SQS에서 데이터를 polling 할 수 있도록 설정 가능
- Publish S3 Event Notificatons To SQS Queue
- S3에 객체가 업로드 되면 -> SQS에 자동으로 메시지 전송 가능하도록 가능
- 이를 위해 S3가 SQS에 write 할 수 있도록 정책 설정 필요 (SendMessage)
SQS - 메시지 가시성 시간초과 (Message Visibility Timeout)
- 소비자가 메시지를 폴링해서 가져오게 되면 Visibility Timeout 시작 (기본 30초)
- 해당 Visibility Timeout 시간 동안 다른 소비자의 폴링 요청에 대해 해당 메시지는 수신되지 않음
- = Visiblity Timeout 내 메시지 처리 및 삭제가 되어야 함
- Timeout이 지나면 동일 소비자 or 다른 소비자가 해당 메시지를 다시 수신 가능
- 소비자가 Timeout 시간 내 처리가 불가능 할 것 같다면 ChangeMessageVisibility API를 호출해 시간을 더 가질 수 있음
- 기본값을 매우 높은 값으로 설정 시 소비자가 충돌했을 때 해당 메시지가 다시 visible 될 때까지 몇시간이 걸릴 수 있음
- 기본값을 매우 낮은 값으로 설정 시 소비자가 처리할 시간이 충분하지 않아 메시지가 중복 수신 및 중복 처리될 수 있음
- 애플리케이션 특성에 맞추어 적절한 값으로 설정 후 소비 시간이 필요할 시 ChangeMessageVisibility API를 호출하는 식으로 해야함
SQS - 배달 못한 메시지 Queue (DLQ, Dead Letter Queue)
- 소비자가 Visibility Timeout 내 처리 못할 시 메시지는 다시 대기열로 들어감
- 해당 이슈가 계속 반복된다면 문제 (메시지가 잘못됨 / 컨슈머가 메시지를 처리하지 못함)
- 이를 대비해 최대 수신 수 임곗값 설정 가능 (MaximumReceives)
- 해당 임곗값 초과 수신 시 표준 Queue에서 제거되고 DLQ에 메시지 보내짐
- DLQ는 디버깅 시 유용
- FIFO 대기열은 DLQ도 FIFO 대기열 / 표준 대기열은 DLQ도 표준 대기열 이어야 함
- DLQ 내 메시지는 만료 시간 내에 처리되어야 함
- DLQ 만료 시간은 길게 설정하는 것이 좋음
- DLQ - 소스로 리드라이브
- DLQ에 보내진 메시지를 디버깅 (소비자 코드 수정 등)
- 디버깅 완료 이후 소스 SQS 대기열로 리드라이브 가능
SQS - Delay Queue
- 소비자들이 메시지를 즉각적으로 보지 못하도록 메시지를 지연 (최대 15분 지연 가능)
- 기본값 0초 (메시지 보낸 직후 수신 가능)
- 대기열 레벨에서 모든 메시지에 대한 지연 시간 설정 가능
- 메시지에 DelaySeconds 파라미터를 통해 메시지 별 지연 시간 설정 가능
SQS - Long Polling
- 소비자가 SQS로부터 메시지 요청 시 대기열이 비어있을 경우 특정 시간동안 메시지를 기다리도록 하는 것
- SQS 대기열로 보내는 API 호출을 줄이기 위한 목적 (효율성 증대, 비용감소, CPU 연산 감소)
- SQS 대기열에 메시지 도착 시 즉시 소비자에게 메시지가 수신 (지연시간 감소)
- 1 ~ 20초 설정 가능 (보통은 20초 선호, 길수록 좋음)
- 대기열 레벨에서 설정 가능
- 소비자가 SQS 대기열에 API 호출 시 WaitTimeSeconds 파라미터로 API 호출 레벨에서 설정 가능
SQS - Extended Client
- 최대 메시지 전송 크기(256KB)를 초과하는 메시지를 보내기 위해 Java 라이브러리인 SQS Extended Client 사용 가능
- 생산자는 실제 Large Message를 S3에 보냄
- 생산자는 S3 버킷에 들어간 메시지의 Small MetaData (대용랑 메시지에 대한 포인터) 를 SQS에 보냄
- 소비자는 Extended Client 라이브러리를 통해 수신한 SQS 메시지를 읽음 (MetaData)
- 소비자는 해당 메시지를 통해 S3로부터 대용량 메시지 수신 및 처리
- 흔히 비디오 파일 처리 시 사용
SQS - FIFO Queue
- 메시지 순서가 FIFO
- 표준 대기열보다 순서 보장
- 순서가 보장되므로 제한된 처리량을 가짐
- 묶음이 아닐 경우 초당 300개 메시지 처리
- 묶음인 경우 초당 3000개 메시지 처리
- 중복 제거 기능(Deduplication) 이 있어 메시지를 정확히 한번만 보냄
- 중복제거 적용 간격은 5분
- 내용 기반 중복제거 : 메시지 본문에 대해 SHA-256 통해 해시 계산 -> 해당 해시가 동일 수신되는 경우 거부
- 메시지 중복제거 ID 명시 : 메시지에 대해 중복제거 ID 명시 -> 동일 ID 수신되는 경우 거부
- 메시지 그룹핑
- FIFO Queue에서 메시지 필수값인 MessageGroupID를 동일한 값으로 설정할 경우 해당 ID에 대해서는 한명의 소비자만 가짐
- 한명의 소비자를 기준으로 메시지가 그룹 내에서 순서대로 정렬
- 각 ID마다 다른 소비자를 가짐 (따라서 FIFO Queue는 병렬 처리가 가능)
- 여러 그룹에 걸쳐 정렬은 불가능
- 메시지 수신 순서 유지가 필요할 때 사용
Amazon SNS
- AWS에서 제공하는 Pub/Sub (발행/구독) 서비스
- FIFO
- 이벤트 생산자(발행자)는 하나의 SNS topic에만 메시지를 보냄
- 이벤트 수신자(구독자)는 해당 topic에 대한 SNS 알림을 받으려는 사람
- 이벤트 수신자는 해당 topic에 전송된 메시지를 모두 받음
- topic 별 최대 1200만 이상의 구독자 가능
- 계정 당 가질 수 있는 topic 수는 최대 10만 개
- 주제를 구독하는 구독자는 다양한 액션이 가능
- SNS에서 직접 이메일 전송 / SMS 알림 / HTTP 엔드포인트로 데이터 전송 가능
- SQS 메시지를 대기열로 직접 보냄 / 메시지 수신 후 람다 함수 실행 / Firehose 데이터를 S3나 Redshift에 보냄
- AWS 서비스가 AWS 이벤트에 대해 SNS에 지정된 토픽에 직접 발행도 가능
SNS - 발행(publish)
- Topic Publish (SDK)를 통해 SNS에 메시지 게시
- 토픽 생성
- 하나 또는 여러개의 구독 생성
- 토픽에 게시
- 모든 구독자가 자동으로 메시지 수신
- Direct Publish (직접 게시, 모바일용 SDK)
- 플랫폼 애플리케이션 생성
- 플랫폼 엔드포인트 생성
- 플랫폼 엔드포인트에 게시
- 수신 가능 대상 : Google GCM, Apple APNS, Amazon ADM (모바일 애플리케이션으로 알림 수신)
SQS + SNS (Fan Out 패턴)
- 여러 SQS에 메시지를 보내려고 할 때 사용
- SNS 주제에 대해 Push -> 이 주제를 구독하는 모든 SQS에 메시지 수신
- 완전한 분리, 데이터 손실 X
- SQS는 데이터 보존, 지연처리, 작업 재실행 지원
- 해당 패턴으로 더 많은 SQS 구독자를 쉽게 추가 가능
- SQS 큐 액세스 정책을 설정해 SNS가 SQS write 허용하도록 해야함
- 리전 간 전달 지원 (SNS 주제를 구독하는 다른 리전의 SQS에도 메시지 전송 가능, 보안정책에서 허용 필요)
- 사용사례 1) 구매 서비스에서 2개의 SQS 큐에 메시지 보내려고 함
- 2개의 SQS에 직접 메시지를 보내는 대신 SNS Topic에 메시지 보냄
- SNS Topic을 구독하는 2개의 SQS 큐가(사기방지 서비스, 배송 서비스) 모두 메시지 수신
- 사용사례 2) S3 이벤트를 여러 SQS 큐에서 수신
- S3의 경우 객체 생성과 같은 event type과 'image/' 같은 접두사 혼용 시 하나의 이벤트 규칙만 가지도록 제한됨
- 이 때 팬아웃 패턴 사용
- S3 버킷에 객체 생성
- 객체 생성 이벤트를 SNS Topic에 발행
- 해당 Topic을 구독하는 여러 SQS Queue (이메일, 람다함수 등 다른 종류 타입도 구독 가능) 에서 모두 이벤트 수신
- 사용사례 3) Kinesis Data Firehose(KDF)를 통해 SNS에서 S3로 직접 데이터 전송
- SNS Topic과 KDF를 연결
- 구매 서비스에서 SNS Topic에 발행
- KDF가 정보를 받아들임
- KDF는 S3로 직접 전송 (KDF가 지원하는 다른 곳, 다양한 목적지로도 전송가능)
- FIFO Fan-out도 가능
- FIFO Topic은 SQS FIFO Queue만 구독 가능
- 정렬 / 중복제거가 필요한 팬아웃 시 사용
SNS - Message Filtering
- SNS Topic을 구독중인 큐에 보내는 메시지를 필터링하는 JSON 정책
- 필터링 정책이 없다면 큐는 기본설정으로 모든 메시지를 수신
- 사용사례)
- 구매서비스 -> SNS -> 배송준비 SQS Queue / 배송중 SQS Queue
- 구매서비스가 SNS Topic에 State:배송준비 메시지 발행
- 배송준비 SQS Queue는 필터링 정책을 통해 해당 메시지 수신
- 구매서비스가 SNS Topic에 State:배송중 메시지 발행
- 배송준비 SQS Queue는 필터링 정책을 통해 해당 메시지 수신 X
Reference