SQS, SNS 연동

동기식 - 어플리케이션 간에 직접적으로 연결, 데이터 양이 증가하거나 예측이 불가할 경우, 어플리케이션을 분리 계층 확장(대기열 - SQS, pub/sub 모델 - SNS, 실시간 스트리밍 - Kinesis)

비동기식/이벤트 기반 - 미들웨어가 어플리케이션 간 연결

 

SQS - 대기 서비스, 대기열에 메시지 포함, SQS 대기열에 메시지를 보내는 주체가 Producer, 한개나 그 이상, 메시지를 수신하는 대상이 Consumer, Poll message(대기열에 수신자에게 온 메시지가 있는지 확인), 메시지를 처리하고 대기열에서 메시지 삭제, 대기열 서비스는 Producer와 Consumer를 분리하는 버퍼 역할

 

- Amazone SQS

- Standard Queue : 완전 관리형 서비스, 어플리케이션 분리, 무제한 처리량, 무제한 대기열 메시지 수, 각 메시지의 수명은 짧음(4일~14일), 짧은 지연 시간(10밀리초 ), 메시지당 256KB, 중복 메시지 존재, 메시지가 충분히 빠르게 처리되지 않으면 다른 consumer에게 전달(최소 1번은 전송) -> 메시지 순서 지정 필요, 처리량을 늘리려면 consumer 추가 및 수평 확장 가능, ASG에 있는 EC2 연결 가능, 대기열의 길이를 ASG 지표로 사용, ApproximateNumberOfMessages가 cloudwatch 지표, HTTPS API 사용, 클라이언트측 암호화도 원하면 가능, SQS API에 대한 접근 제어로 IAM 정책 적용 가능, SQS 대기열에 대한 교차 계정 접근을 수행하거나, 다른 서비스가 SQS 대기열에 S3 이벤트를 쓸 수 있도록 허용하는 정책 적용 가능

 

     - Producer : SDK 활용, SendMessage API, 메시지 전송하면 consumer가 읽고 삭제할 대까지 SQS 대기열에 유지

 

     - Consumer : AWS의 가상 서버에서 실행 가능, 대기열에 메시지 최대 10개 한번에 확인 가능, 코드를 통해 메시지 처리 후 대기열에서 삭제, DeleteMessage API, 메시지 삭제 안하면 다른 consumer가 확인 가능

 

      - Message Visibility Timeout : consumer가 메시지를 폴링하면 다른 사용자에게는 보이지 않음, 기본 30초, 30초 내에 메시지가 처리되어야 함, ReceiveMessage Request를 하면 메시지가 반환되지 않음, 시간 내에 다른 요청이 와도 반환되지 않음 -> 메시지가 다른 사용자에게 보이지 않음, 시간이 지나도 메시지가 삭제되지 않으면 다시 대기열에 넣음, 그럼 다른 사용자가 메시지 받을 수 있음(메시지가 2번 처리될 수 있음), 처리 시간이 부족해 처리하지 못 할 경우 ChangeMessageVisibility API 호출해 SQS에 전달, 메시지가 보이지 않도록

 

      - Long Polling : 소비자가 대기열에서 메시지를 요청하는데 없을 경우 대기 하는 것, 지연 시간을 줄이고, SQS로 보내는 API 호출 숫자를 줄이기 위해 사용, 1~20초 설정, 대기열 레벨에서 구성해 아무 소비자로부터 롱 폴링 활성화하거나, WaitTimeSeconds API를 사용해 소비자 스스로 롱 폴링 하도록 설정 가능

 

- FIFO Queue : First In, First Out, Standard Queue보다 순서가 확실히 보장됨, 처리량 제한(초당 300개 메시지, 묶음일 경우 초당 3000개 메시지), 중복 제거 가능, 분리나 메시지 순서를 유지해야 할 때 사용, 생성할 때 이름 뒤에 .fifo 붙여야 생성 가능

 

- Auto Scaling Group : DB에서 처리량이 많은 경우, SQS 대기열에 먼저 쓸 수 있음, 어플리케이션에 요청 전송되고 메시지로써 대기열에 전달, 유실되는 요청 없음, 메시지가 DB에 삽입되면 SQS 대기열에서 해당 메시지 삭제, SQS를 버퍼로 사용해 모든 트랜잭션이 DB에 쓰이도록 할 수 있음

 

-Amazon SNS : SQS 대기열을 사용하면 서비스를 추가할 때마다 다시 통합하고 작성해야 함, pub/sub 방식을 사용하면 메시지를 주제로 게시 가능, 많은 구독자들은 SNS 주제에서 메시지를 수신하고 보관 가능, Event Producer(1개 SNS 주제에만 메시지 전송), Event Receiver(해당 주제와 관련된 SNS 알림 수신), Subscriber(해당 주제로 전송된 메시지 모두 수신), 주제별 1,200만 구독자, 계정당 가능한 주제 수는 최대 10만개, 이메일, SMS나 모바일 알람, HTTPS 엔드포인트로 직접 데이터 전송 가능, AWS 서비스와 결합해 메시지를 대기열로 전송하거나 메시지 수신 후 함수가 코드를 수행하도록 Lamdba에 보낼 수 있음, Firehorse를 통해 데이터를 S3나 Redshift로 전송 가능, 토픽 생성해 구독을 만들고 SNS 주제에 게시, 플랫폼 어플리케이션을 만들고 플랫폼 엔드 포인트를 만들어 게시(모바일 알람), HTTPS 암호화, KMS키, 클라이언트측 암호화 가능, SNS API IAM 정책 적용 가능, SNS 주제에 교차 계정 엑세스 권한 부여, S3 등의 서비스가 SNS 주제에 작성할 수 있도록 권한 부여

 

- SNS + SQS Fan Out : 다수의 SQS 대기열로 메시지를 전송할 때, SNS 주제로 한번 메시지를 전송하고, 원하는만큼 SQS 대기열을 SNS 주제에 구독시키는 Fan out 방식 사용, 완전히 분리된 모델, 데이터 손실 없음, 데이터 지속성, 지연 처리, 작업 재시도 가능, SQS 대기열을 구독자로 추가 가능, SNS 토픽이 SQS 대기열에 쓸 수 있도록 허용해야 함, 한 리전의 SNS 토픽이 다른 리전의 SQS 대기열에 메시지 전송 가능, S3 버킷에 객체가 생성된 이벤트가 발생하면 이벤트를 SNS 주제로 전송하고 여러 대기열에 SNS 주제에 fan out 패턴으로 구독, Kenesis를 통해 SNS에서 S3로 직접 데이터 전송 가능, FIFO 가능

      - Message Filtering : SNS 주제 구독자에게 전송할 메시지를 필터링하는 JSON 정책, 기본은 모든 메시지 수신