AWS SQS – SNS – Kinesis

[ThanhQuyen]

AWS SQS – SNS – Kinesis


Khi triển khai hệ thống có nhiều ứng dụng, chúng ta bắt buộc phải có cách để các ứng dụng giao tiếp với nhau. Có hai kiểu giao tiếp chính:

• Giao tiếp đồng bộ (Synchronous): Ứng dụng gọi trực tiếp đến ứng dụng khác.

• Giao tiếp bất đồng bộ (Asynchronous / Event-based): Ứng dụng gửi thông điệp vào một hàng đợi (queue), sau đó ứng dụng khác lấy ra và xử lý.

Khi hệ thống gặp lượng truy cập tăng đột biến – ví dụ bình thường xử lý 10 video nhưng hôm nay 1.000 video – giao tiếp trực tiếp sẽ gây nghẽn. Vì vậy AWS cung cấp 3 dịch vụ cực kỳ quan trọng để “giải phóng tải” và “tách rời ứng dụng”:

• AWS SQS: Hàng đợi (queue) – xử lý thông điệp theo lượt.

• AWS SNS: Pub/Sub – gửi một thông điệp cho nhiều nơi cùng lúc.

• AWS Kinesis: Xử lý dữ liệu streaming thời gian thực.

Ba dịch vụ này giúp hệ thống chống nghẽn, tự mở rộng, và vận hành ổn định ngay cả khi lưu lượng tăng mạnh. 1. Amazon SQS – Hàng đợi tin nhắn

SQS Standard Queue


Đây là dịch vụ lâu đời – hoạt động hơn 10 năm – dùng để tách rời các ứng dụng.
Đặc điểm chính:

• Không giới hạn số tin nhắn và không giới hạn throughput.

• Tin nhắn lưu trữ mặc định 4 ngày, tối đa 14 ngày.

• Độ trễ cực thấp (≈10 ms).

• Kích thước mỗi tin nhắn tối đa 256 KB.

• Có thể trùng lặp tin nhắn.

• Không đảm bảo thứ tự tuyệt đối.

Cách sản xuất (produce) tin nhắn


Ứng dụng gửi tin nhắn vào SQS bằng API SendMessage.
Tin nhắn nằm trong SQS cho đến khi consumer xử lý xong và gọi DeleteMessage.
Ví dụ tin nhắn: orderId, customerId, thông tin đơn hàng… Cách tiêu thụ (consume) tin nhắn


Consumer có thể là EC2, server on-premise hoặc Lambda.
Consumer sẽ:

• Poll SQS để nhận tin nhắn (tối đa 10 tin/lần).

• Xử lý (ví dụ ghi vào RDS).

• Gọi DeleteMessage để xóa tin nhắn khỏi hàng đợi.

Nhiều consumer chạy song song → tăng tốc xử lý → scaling theo chiều ngang. SQS + Auto Scaling


Bạn có thể dựa vào chỉ số ApproximateNumberOfMessages trong CloudWatch để tự động tăng/giảm số lượng EC2 theo tải. Tách rời frontend – backend bằng SQS


Frontend chỉ gửi yêu cầu vào hàng đợi.
Backend tự động mở rộng và xử lý khi có tin nhắn. Bảo mật SQS

• Mã hóa khi truyền: HTTPS API.

• Mã hóa khi lưu trữ: KMS.

• IAM policy để kiểm soát truy cập.

• Queue Access Policy giống S3 bucket policy – cho phép cross-account hoặc cho SNS, S3 ghi vào queue.

Message Visibility Timeout


Sau khi consumer nhận tin nhắn, tin đó “tạm ẩn” trong một thời gian gọi là visibility timeout (mặc định 30 giây).
Nếu consumer xử lý lâu hơn thời gian này, tin nhắn sẽ xuất hiện lại → bị xử lý lần nữa.
Consumer có thể gọi ChangeMessageVisibility để kéo dài thời gian xử lý.
Timeout quá thấp → dễ sinh duplicate.
Timeout quá cao → nếu consumer chết, tin phải chờ rất lâu để xử lý lại. Long Polling


Consumer có thể chờ tin nhắn trong tối đa 20 giây.
Long Polling giúp:

• giảm số lần gọi API

• giảm chi phí

• tăng hiệu quả và giảm latency

FIFO Queue – hàng đợi đảm bảo thứ tự


SQS FIFO đảm bảo:

• Đúng thứ tự vào → đúng thứ tự ra

• Exactly-once (loại bỏ trùng lặp)

• Throughput giới hạn: 300 msg/s, hoặc 3000 msg/s nếu batching

2. Amazon SNS – Gửi một tin cho nhiều nơi (Pub/Sub)


SNS phù hợp khi một sự kiện phải được gửi đến nhiều dịch vụ.
Ví dụ khi khách hàng mua hàng:

• gửi email

• gửi thông tin cho hệ thống Fraud

• gửi thông tin cho Shipping

• gửi vào SQS để xử lý nền

Điểm mạnh:

• Một producer → nhiều subscriber

• 12,5 triệu subscription/topic

• 100.000 topic

• Tích hợp nhiều dịch vụ AWS (S3 events, CloudWatch, Auto Scaling, DMS…)

SNS có thể publish đến:

• SQS

• Lambda

• Email

• HTTP endpoint

• Kinesis Firehose

• Mobile push (GCM, APNS…)

SNS Security

• HTTPS

• KMS

• IAM

• Topic Policy (giống S3 bucket policy)

Fan-out: SNS + SQS


SNS push 1 lần → các SQS nhận cùng thông điệp.
Ưu điểm:

• Không mất dữ liệu

• Có thể retry

• Thêm queue mới dễ dàng

• Cross-region

SNS Filtering


Subscription lọc tin nhắn theo điều kiện JSON (ví dụ trạng thái đơn hàng: placed, declined, cancelled).
Giúp mỗi dịch vụ chỉ nhận tin mình cần. 3. Amazon Kinesis – Xử lý dữ liệu streaming thời gian thực


Dùng khi cần xử lý dữ liệu liên tục, tốc độ cao như:

• log hệ thống

• clickstream

• dữ liệu IoT

• dữ liệu cảm biến

• dữ liệu phân tích real-time

Kinesis gồm:

• Kinesis Data Streams – thu thập và lưu data streaming.

• Kinesis Data Firehose – đổ dữ liệu vào S3, Redshift, OpenSearch…

• Kinesis Data Analytics – xử lý real-time bằng SQL/Flink.

• Kinesis Video Streams – xử lý video thời gian thực.

Kinesis Data Streams


Luồng dữ liệu chia thành nhiều shard.
Một shard có:

• 1 MB/s ghi hoặc 1000 record/s

• 2 MB/s đọc (hoặc 2 MB/s/consumer nếu enhanced fan-out)

Dữ liệu trong stream:

• lưu tối đa 1–365 ngày

• không bị xóa giữa chừng

• có khả năng replay

• dữ liệu có cùng Partition Key → vào cùng shard → giữ được thứ tự

Producers gồm: SDK, KPL, Kinesis Agent…
Consumers: SDK, Lambda, Firehose, Analytics, KCL… Capacity Mode

Provisioned:

• Tự chọn số shard

• Tự scale hoặc dùng API

• Trả tiền theo shard

On-demand:

• Không cần quản lý shard

• Scale tự động

• Thanh toán theo data in/out

Bảo mật

• IAM

• HTTPS

• KMS

• VPC Endpoint

• Giám sát bằng CloudTrail

4. Kinesis Data Firehose – Đổ dữ liệu vào S3/Redshift/OpenSearch


Đặc điểm:

• Serverless hoàn toàn

• Không cấu hình, không shard

• Ghi vào nhiều nơi: S3, Redshift, ES, Datadog, MongoDB…

• Hỗ trợ chuyển đổi dữ liệu qua Lambda

• Gửi dữ liệu lỗi vào S3

• Gần real-time (tối thiểu 60 giây hoặc 1MB)

5. So sánh nhanh SQS – SNS – Kinesis

• SQS dùng khi ứng dụng cần tách rời, consumer tự kéo dữ liệu, có retry, tối ưu cho xử lý nền.

• SNS dùng khi cần một tin gửi cho nhiều dịch vụ, không lưu tin, realtime push.

• Kinesis dùng khi cần xử lý streaming real-time, lưu data 1–365 ngày, có replay.

6. Amazon MQ – dành cho hệ thống on-premises muốn lên cloud


Một số hệ thống cũ dùng các giao thức như MQTT, AMQP, STOMP…
Thay vì rewrite để dùng SQS/SNS, AWS cung cấp Amazon MQ, một message broker có cả queue lẫn topic.
Amazon MQ:

• không scale mạnh như SQS/SNS

• nhưng hỗ trợ giao thức chuẩn

• hoạt động Multi-AZ

• có failover

• lưu dữ liệu trên EFS

Nếu bạn muốn:

• Hiểu sâu về SQS – SNS – Kinesis

• Biết cách thiết kế hệ thống chống nghẽn

• Học thực hành deploy, auto scaling, event-driven

• Tập làm bài lab SAA / DVA / SCS cho AWS Certification

Hãy tham gia ngay khóa học “AWS” tại VnPro và inbox ngay để VnPro tư vấn lộ trình học!