AWS SAA-C02(decoupling)

two patterns of application communication

queue model : SQS

- 여러 producer가 queue에 message를 보낸다, 모든 메세지가 queue에 들어감,

- consumer는 queue polling하여 message를 가져가서 작업을 처리함, queue 가 버퍼가 됨

- 어플리케이션을 분리하는데 도움됨, 메세지는 4일동안 queue에 저장됨, 컨슈머가 가져가고 queue에서 삭제

- sqs 256kb 미만이어야 한다. 재정렬에 노력해야함, 

- producer는 sdk를 이용하여 message를 보냄,

- consumer는 sqs message 가져가고 -> 처리함 -> 그리고 deleteMessageApi를 이용하여 message없앰(at least once delevery)

Visibility timeout : 특정 기간안에 process가 끝나지 않으면 다시 큐에 들어옴. 최대 12시간 이시간동안 다른 consumer가 message못봄

DLQ(dead letter queue) : 일정 횟수이상 처리 안되면 일로옴

delevery delay : 메세지가 send되고 한동안 컨슈머가 message를 못봄

Long polling : consumer가 sqs로 접근 횟수를 줄임 메세지가 queue에 있는 대기시간이 줄어듬

 

SQS 가시성 제한 시간은 Amazon SQS가 다른 소비자가 메시지를 다시 수신 및 처리하지 못하도록 하는 기간입니다. Visibility Timeout에서 메시지는 Queues에서 소비된 후에만 숨겨집니다. 표시 시간 초과를 늘리면 소비자가 메시지를 처리하고 메시지의 중복 읽기를 방지하는 데 더 많은 시간을 할애할 수 있습니다. (기본값: 30초, 최소: 0초, 최대: 12시간)

 

SQS FIFO(선입선출) Queues에는 SQS 표준 Queues의 모든 기능과 함께 다음 두 가지 기능이 있습니다. 첫째, 메시지를 보내고 받는 순서는 엄격하게 유지되며 메시지는 한 번 배달되고 소비자가 처리하고 삭제할 때까지 사용할 수 있습니다. 둘째, 중복된 메시지는 Queues에 포함되지 않습니다.

 

SQS 배달 못한 편지 Queues은 다른 SQS Queues(소스 Queues)이 성공적으로 처리(소비)되지 않은 메시지를 보낼 수 있는 곳입니다. 문제가 있는 메시지를 격리하여 처리가 성공하지 못한 이유를 디버깅할 수 있으므로 디버깅에 유용합니다.

 

이것은 하나의 메시지만 SNS 주제로 보낸 다음 여러 SQS Queues로 "팬아웃"되는 일반적인 패턴입니다. 이 접근 방식에는 다음과 같은 기능이 있습니다. 완전히 분리되고 데이터 손실이 없으며 시간이 지남에 따라 더 많은 SQS Queues(더 많은 애플리케이션)을 추가할 수 있습니다.

SQS policy

 

• Standard Queue : order 미보존, 한 번 이상 (무한 tps)
• FIFO Queue : order 보존, 중복메세지 제거 정렬함 (300 tps)

SQS auto scaling

Synchronous and Asynchronous AWS Decoupling 검색단어

동기 elb는 elb와 연결된 vpc에 엑세스 할 수 있는 클라이언트의 요청만 라우팅 가능 -> 사용자가 즉각적인 응답을 기다리는 시스템에 적용

비동기식 디커플링 sqs는 요청에 즉시 응답하지 않아도 되고, 큐의 길이를 기반으로 서버의 수를 조절, 필요한 규모를 정확하게 측정할수있고, 모든 요청은 큐에 저장되기 때문에 부하가 커도 손실되지 않는다. -> 대기열과 함께 작동하도록 코드 수정이 필요, 

 

pub/sub model : SNS

- fifo 기능 가지고 있음

- multiple AZ 가능

- (SQS와 다르게) push-based

- message filtering 가능 정책과 일치한 queue로만 구독가능

 

Amazon SNS는 HTTP(S), SQS, Lambda, 모바일 푸시, 이메일 또는 SMS Endpoint에 메시지를 게시할 수 있습니다.

 

sqs fan-out pattern

실시간 스트리밍 : kinesis

- 스트리밍 데이터 실시간 분석

Streaming data

3 타입

• Kinesis Stream : 여러 샤드에 데이터 보관 (24h ~ 7days 보관)
• Kinesis Firehose : 바로 분석
• Kinesis Analytics : 위 두개에 같이 사용

Kinesis 데이터 스트림의 용량 제한은 데이터 스트림 내의 샤드 수로 정의됩니다. 데이터 처리량 또는 읽기 데이터 호출 수로 인해 제한을 초과할 수 있습니다. 각 샤드는 1MB/s의 들어오는 데이터와 2MB/s의 나가는 데이터를 허용합니다. 충분한 용량을 제공하려면 데이터 스트림 내의 샤드 수를 늘려야 합니다.

 

Kinesis Data Stream은 각 데이터 레코드와 연결된 파티션 키를 사용하여 주어진 데이터 레코드가 속한 샤드를 결정합니다. 각 사용자의 ID를 파티션 키로 사용하면 각 사용자의 데이터가 정렬되어 동일한 샤드로 전송됩니다.

 

이것은 거의 실시간 데이터를 S3 및 Redshift에 로드하기 위한 기술의 완벽한 조합입니다. Kinesis Data Firehose는 AWS Lambda를 사용한 사용자 지정 데이터 변환을 지원합니다.

 

Amazon MQ

- managed apache activeMQ

- 온프레미스에서 클라우드로 재설계 없이 mqtt 프로토콜을 사용하고있으면 아마존mq가 답

 

Amazon MQ는 JMS 및 NMS와 같은 업계 표준 API와 AMQP, STOMP, MQTT 및 WebSocket을 포함한 메시징 프로토콜을 지원합니다.