DEVELOPyo

- When we start deploying multiple applications, they will inevitably need to communicate with one another

- There are two patterns of application communication

1. Synchronous communications (application to application)

2. Asynchronous / Event based (application to queue to application)

Synchronous between applications can be problematic if there are sudden spikes of traffic

What if you need to suddenly encode 1000 videos but usually it's 10?

In that case, it's better to decouple your applications

1) using SQS: queue model

2) using SNS: pub/sub model

3) using Kinesis: real-time streaming model

These services can scale independently from our application

[ 1. SQS (Simple Queuing service) ]

- Oldest offering (over 10 years old)

- Fully managed service, used to decouple applications

- Attributes :

  1) unlimited throughput, unlimited number of messages in queue

  2) Short-lived : Default retention of messages in Queue for 4days, maximum of 14days

  3) Low latency (<10ms on publish and receive)

  4) Limitation of 256KB per message sent

- Can have duplicate message (at least one delivery, occasionally)

- Can have out of order messages (best effort ordering)

1) SQS : Producing Messages 

- Produced to SQS using the SDK (SendMessage API)

- The message is persisted in SQS until a consumer deletes it

- Message retention: default 4 days, up to 14 days

- unlimited throughput

2) SQS : Consuming Messages 

- Consumers (running on EC2 instances, servers, or AWS Lambda)

- Poll SQS for messages (receive up to 10 messages at a time)

- Process the messages (ex: insert the message into an RDS database)

- Delete the messages using the DeleteMessage API

3) Multiple EC2 Instances Consumers 

- Consumers receive and process messages in parallel

- At least once delivery

- Best-effort(최선을 다 하지만 책임은 지지않는) message ordering

- Consumers delete messages after processing them

- We can scale consumers horizontally to improve throughput of processing

4) SQS with Auto Scaling Group (ASG)

queue length go over a certain level, set CloudWatch Alarm, then increase the capacity of Auto Scaling Group

5) SQS to decouple between application tiers

오래걸리는 작업은 두개의 프로세스로 쪼개어 SQS Queue 를 사용하여 Decoupling

6) SQS -Security

- Encryption 

  1) In-flight encryption using HTTPS API

  2) At-rest encryption using KMS keys

  3) Client-side encryption if the client wants to perform encryption/decryption itself

- Access Controls : IAM policies to regulate access to the SQS API

- SQS Access Policies (similiar to S3 bucket policies)

  Useful for cross-account access to SQS queues

  Useful for allowing other services (SNS, S3...) to write to an SQS queue

7) Message Visibility Timeout **

특정 서버가 message 를 poll해가면, default 값인 30 초 동안 다른 서버는 해당 message 에 접근 할 수 없음

- After a message is polled by a consumer, it becomes invisible to other consumers

- By default, the message visibility timeout is 30 seconds

- That means the message has 30 seconds to be processed

- After the message visibility timeout is over, the message is "visible" in SQS

- If a message is not processed within the visibility timeout, it will be processed twice

- A consumer could call the ChangeMessageVisibility API to get more time

- If visibility timeout is high (hours), and consumer crashes, re-processing will take time

- If visibility timeout is too short, we may get duplicates

8) Dead Letter Queues

- If a consumer fails to process a message within the Visibility Timeout, the message goes back to the queue

- We can set a threshold(문턱(리밑)) of how many times a message can go back to the queue

- After the MaximumReceives threshold is exceeded, the message goes into a dead letter queue(DLQ)

* Useful for debugging

* make sure to process the messages in the DLQ before they expire: Good to set a retention of 14 days in the DLQ

9) Delay Queue

- Delay a message (consumers don't see it immediately) up to 15 mins

- Default is 0 seconds (message is available right away)

- Can set a default at queue level

- Can override the default on send using the DelaySeconds parameter

10) SQS - FIFO Queue

선입선출 방식의 큐로 초당 전송량 제한이 없는 SQS와 달리, 전송량에 한계가 있음

- First In First Out (ordering of messages in the queue)

- Limited throughput : 300 msg/s without batching, 3000 msg/s with

- Exactly-once send capability (by removing duplicates)

- Messages are processed in order by the consumer