SQS (Simple Queue Service) P1

SQS Queue

Luồng hoạt động:

• Producer gửi message:
  • Các producer push các message vào SQS queue.
  • Gửi là asynchronous, producer không cần chờ consumer xử lý xong.
    • Điều này giúp giảm độ trễ và tránh bị “nghẽn cổ chai”.
• Queue lưu trữ message:
  • Queue hoạt động như một buffer giúp tách biệt thời gian gửi và thời gian xử lý.
  • Queue có thể scale theo số lượng message lớn mà không ảnh hưởng đến producer.
• Consumer poll message:
  • Các consumer sẽ thực hiện poll hàng đợi để lấy message về xử lý.
  • Việc này có thể thực hiện theo kiểu pull hoặc long polling để giảm chi phí và tăng hiệu quả.
• Message delivery:
  • Message được đảm bảo ít nhất một lần (at-least-once) sẽ được gửi tới consumer (Standard Queue).
  • Nếu dùng FIFO Queue thì có thể đảm bảo cả thứ tự và duy nhất một lần (exactly-once).

Standard Queue

• Service lâu đời nhất (trên 10 năm).
• Là service hoàn toàn được quản lý (fully managed service), dùng để tách rời (decouple) các ứng dụng.
• Thông lượng (throughput) không giới hạn, số lượng message trong hàng đợi là không giới hạn.
• Thời gian lưu trữ mặc định của message: 4 ngày, tối đa có thể cấu hình lên 14 ngày.
• Độ trễ thấp: dưới 10 mili-giây khi gửi (publish) và nhận (receive) message.
• Giới hạn kích thước message: mỗi message gửi vào queue không vượt quá 256KB.
• Có thể xảy ra trùng lặp message (duplicate message)
  • Mô hình đảm bảo là at-least-once delivery, tức là message sẽ được đảm bảo giao một lần trở lên.
  • Điều đó đồng nghĩa là: cùng một message có thể được gửi đến nhiều lần cho consumer, nếu AWS nghi ngờ rằng message trước đó chưa được xử lý thành công (timeout, chưa xóa,...).
  • 💡 Giải pháp kỹ thuật:
    • Consumer nên implement idempotency: xử lý message trùng lặp sao cho không gây ảnh hưởng.
    • Ví dụ: kiểm tra messageId, hoặc dùng Redis/cache để đánh dấu các message đã xử lý.
• Có thể bị sai thứ tự message
  • Với Standard Queue, message được xử lý theo dạng "best effort ordering", nghĩa là AWS sẽ cố gắng giữ thứ tự, nhưng không đảm bảo tuyệt đối.
  • Điều này xảy ra vì hệ thống có thể phân tán message sang nhiều phân vùng (shards) để tối ưu throughput.
  • 💡 Giải pháp kỹ thuật:
    • Nếu yêu cầu strict order, hãy sử dụng FIFO Queue thay vì Standard Queue.
    • Nếu vẫn dùng Standard, cần thiết kế luồng xử lý không phụ thuộc thứ tự message, hoặc dùng messageGroupId (chỉ với FIFO).

Producing Messages

• Gửi message vào SQS sử dụng SDK (thông qua SendMessage API).
• Message sẽ được lưu trữ (persisted) trong hàng đợi SQS cho đến khi consumer xóa nó (sau khi xử lý xong).
• Thời gian lưu trữ (retention): mặc định là 4 ngày, có thể cấu hình tối đa là 14 ngày.
• Ví dụ: Gửi một đơn hàng (order) để xử lý
  • Gửi 1 message chứa:
    • orderId
    • customerId
    • Bất kỳ attribute nào bạn cần (ví dụ: amount, productCode, timestamp,...)
      ➡️ Các thuộc tính này sẽ được đóng gói trong message và gửi vào hàng đợi SQS.
• SQS Standard hỗ trợ thông lượng không giới hạn (unlimited throughput):
  • Nghĩa là bạn có thể gửi hàng trăm ngàn message mỗi giây mà không cần quan tâm đến scaling.
  • Điều này giúp nó phù hợp với các hệ thống event-driven, microservice scale lớn.

Consuming Messages

• Các consumer (chạy trên EC2, server tự host, hoặc AWS Lambda) sẽ poll hàng đợi SQS để lấy message.
• Consumer có thể nhận tối đa 10 message mỗi lần gọi Poll.
• Sau khi nhận, consumer sẽ xử lý message. Ví dụ minh hoạ là chèn dữ liệu vào cơ sở dữ liệu Amazon RDS.
• Sau khi xử lý xong, message cần được xóa khỏi hàng đợi SQS bằng cách gọi API DeleteMessage.

Multiple EC2 Instances Consumers

• Consumers nhận và xử lý message song song (in parallel).
• Đảm bảo cơ chế “at least once delivery” – mỗi message ít nhất sẽ được xử lý một lần (nhưng có thể bị xử lý lặp nếu không xóa đúng cách).
• Không đảm bảo thứ tự tuyệt đối, chỉ cố gắng giữ thứ tự tốt nhất có thể (best-effort message ordering).
• Consumer chịu trách nhiệm xóa message khỏi hàng đợi sau khi xử lý xong (dùng DeleteMessage API).
• Có thể scale horizontal các consumer để tăng thông lượng xử lý message (ví dụ: tăng thêm EC2 instance → tăng throughput).

SQS with Auto Scaling Group (ASG)

1. Producer gửi message vào SQS Queue.
2. CloudWatch Metric ghi nhận độ dài queue (số lượng message còn trong hàng đợi).
3. Nếu message backlog vượt threshold → CloudWatch Alarm bật lên.
4. Alarm kích hoạt ASG scale-out → tăng số lượng EC2 instance.
5. EC2 instances mới poll message từ queue → xử lý → giảm backlog.
6. Khi message backlog giảm → Alarm hạ nhiệt → ASG scale-in (giảm số EC2 nếu cần).

SQS to decouple between application tiers

• Đây là mô hình chuẩn của event-driven microservices hoặc asynchronous task processing trong các hệ thống lớn.
• Mục tiêu chính của mô hình này:

Security

• Encryption
  • Mã hóa trong quá trình truyền tải (In-flight encryption) sử dụng HTTPS API
    • Đây là mã hóa dữ liệu khi đang truyền từ client đến SQS hoặc từ SQS đến client.
    • Sử dụng giao thức HTTPS (SSL/TLS) để đảm bảo dữ liệu không bị rò rỉ hoặc bị can thiệp giữa chừng.
  • Mã hóa khi lưu trữ (At-rest encryption) sử dụng khóa KMS (KMS keys)
    • Đây là mã hóa dữ liệu khi message đã nằm trong SQS
    • Bạn có thể chọn dùng khóa mặc định của AWS hoặc tự tạo KMS key riêng để kiểm soát.
  • Mã hóa phía client (Client-side encryption) nếu phía client muốn tự thực hiện mã hóa/giải mã
    • Ở đây, ứng dụng tự mã hóa nội dung message trước khi gửi đến SQS, và khi nhận về, ứng dụng cũng phải tự giải mã.
    • Mục đích: Bạn không tin tưởng 100% vào AWS, hoặc muốn kiểm soát hoàn toàn việc mã hóa.
• Kiểm soát truy cập (Access Controls)
  • Sử dụng IAM policies để điều tiết quyền truy cập vào SQS API
• SQS Access Policies
  • Hữu ích cho việc truy cập hàng đợi SQS từ tài khoản khác (cross-account access)
  • Hữu ích cho việc cho phép các dịch vụ khác (ví dụ: SNS, S3, …) ghi dữ liệu vào hàng đợi SQS